eJabberd User mit Gruppenzugehörigkeit aus LDAP holen

[Lookbehind]

Hallo zusammen,

ich werd noch blöde hier. Ich versuche einen ejabberd-Server mit einem LDAP zu verknüpfen. Die Nutzer-Authentifizierung soll über den LDAP laufen. Der LDAP läuft, ist eingerichtet und versorgt unter anderem einen Samba-Server mit Authentifizierung.
Will ich einfach nur die Nutzer in ejabberd authentifizieren, wie sie sind, funktioniert das auch absolut problemlos. Aber dann habe ich ALLE User aus dem LDAP automatisch auch im ejabberd drin. Ich hätte gerne nur die Nutzer im ejabberd, die in der Gruppe "jabberusers" sind. Und daran verzweifel ich jetzt seit einigen Stunden.
In der Dokumentation, an diversen Stellen auf StackOverflow und anderen Seiten, die ich per Google finde ist es überall mehr oder weniger gleich beschrieben. Der Parameter "ldap_filter" in der Config muss mit folgendem String gefüttert werden:

Code: Alles auswählen

ldap_filter: "(&(objectClass=shadowAccount)(memberOf=cn=jabberusers,ou=Groups,dc=example,dc=com))"

Lasse ich diese Zeile in der Config weg, kann ich in ejabberd Nutzer per LDAP authentifizieren. Leider aber ALLE Nutzer im LDAP, nicht nur die in der Gruppe jabberusers.
Kürze ich die Zeile auf:

Code: Alles auswählen

ldap_filter: "(objectClass=shadowAccount)"

funktioniert das auch. Allerdings wieder mit ALLEN Nutzern. Der DN zur Gruppe passt auch! Den hab ich mir vor lauter Verzweiflung schon per extra dafür installierter GUI aus dem LDAP kopiert. (Alles noch n Test-Setup in einer VM, GUI kommt bei der Neuinstallation definitiv nicht wieder drauf.)
Hab ich aber die Zeile drin, wie sie laut allen von mir gefundenen Erklärungen sein müsste, und meiner Meinung nach auch logisch aussieht, taucht im Log sowas auf:

Code: Alles auswählen

2018-03-04 01:05:29.063 [debug] <0.388.0>@eldap:send_command:789 {searchRequest,{'SearchRequest',<<"dc=example,dc=com">>,wholeSubtree,neverDerefAliases,0,0,false,{and,[{equalityMatch,{'AttributeValueAssertion',<<"uid">>,<<"xmppadmin">>}},{and,[{equalityMatch,{'AttributeValueAssertion',<<"objectClass">>,<<"shadowAccount">>}},{equalityMatch,{'AttributeValueAssertion',<<"memberOf">>,<<"cn=jabberusers,ou=Groups,dc=example,dc=com">>}}]}]},[<<"uid">>]}}
2018-03-04 01:05:29.066 [debug] <0.388.0>@eldap:recvd_packet:849 {searchResDone,{'LDAPResult',success,<<>>,<<>>,asn1_NOVALUE}}
2018-03-04 01:05:29.066 [warning] <0.495.0>@ejabberd_web_admin:process:246 Access of <<"xmppadmin@jabber.example.com">> from <<"192.168.178.15">> failed with error: <<"inexistent-account">>

Der User xmppadmin ist definitiv Mitglied der Gruppe jabberusers.

Code: Alles auswählen

root@jabber:~# getent group jabberusers
jabberusers:*:10002:demouser01,xmppadmin,demouser02

So, wo is der eine Punkt, das fehlende Semikolon oder der grandiose Denkfehler, der mich hier echt zum Haare raufen bringt?
Und welche weiteren Infos braucht ihr, um das beurteilen zu können?

TIA

Look

[habakug]

Hallo,

hast du es denn mal so

Code: Alles auswählen

ldap_filter: "(memberOf=cn=jabberusers,ou=Groups,dc=example,dc=com)"

probiert?

Gruss, habakug

[bluestar]

Kannst du mal einen LDAP Dump eines Users und einer Gruppe posten.

[Lookbehind]

Hallo zusammen.

Hallo,

hast du es denn mal so

Code: Alles auswählen

ldap_filter: "(memberOf=cn=jabberusers,ou=Groups,dc=example,dc=com)"

probiert?

Gruss, habakug

Gleiches (schlechtes) Ergebnis. Funfact: Ich hab in letzter Sekunde vorm Abschicken des ersten Beitrags noch gemerkt, dass die Fehlerausgabe die ich da rein kopiert hatte, von genau dieser Konfiguration kam, und habs noch schnell ausgetauscht. ... der Verweis auf ObjectClass fehlt dann natürlich in der Fehlerausgabe.

Kannst du mal einen LDAP Dump eines Users und einer Gruppe posten.

Aber Klar doch!

Code: Alles auswählen

# ldapsearch -x -LLL -H ldapi:/// -b dc=example,dc=com 'cn=xmppadmin'
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: xmppadmin
gidNumber: 10003
displayName: xmppadmin
sambaGroupType: 2
sambaSID: S-1-5-21-2092326337-827323919-3161327660-20005
memberUid: xmppadmin

dn: uid=xmppadmin,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
cn: xmppadmin
sn: xmppadmin
uid: xmppadmin
uidNumber: 10001
gidNumber: 10003
homeDirectory: /home/xmppadmin
loginShell: /bin/false
gecos: System User
givenName: xmppadmin
shadowLastChange: 17593
shadowMax: 45

# ldapsearch -x -LLL -H ldapi:/// -b dc=example,dc=com 'cn=jabberusers'
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: jabberusers
gidNumber: 10002
sambaGroupType: 2
sambaSID: S-1-5-21-2092326337-827323919-3161327660-20004
displayName: jabberusers
memberUid: demouser01
memberUid: xmppadmin
memberUid: demouser02

[Lookbehind]

*Ausbuddel*
Hat hier inzwischen vielleicht jemand einen Tipp für mich?
Ich hab mich zugegebener weise die letzten zwei Wochen um was anderes gekümmert, und bei der Gelegenheit die Test-Maschine voll vor die Wand gefahren *hust* Gut dass das nur ne VM ist.
Bin gerade dabei das Test-System neu auf zu setzen, und würde mich gerne auch wieder um dieses Thema kümmern. Hat da jemand einen Hinweis für mich, wie der Filter korrekt aussehen muss?

Gruß

Look

[bluestar]

Wie hast du denn memberOf konfiguriert?

Soweit mir bekannt ist greift das nämlich nur, wenn die Gruppe im LDAP als objectclass = groupOfNames angelegt ist.

Schau mal hier: https://www.adimian.com/blog/2014/10/ho ... -openldap/

[Lookbehind]

Hm, du hast recht. Damit gehts. Is nur leider etwas unschön, weil ich eigentlich mit PosixGroups arbeiten wollte. *kratz*
Na ich werde mal versuchen da was zu basteln, und gegebenenfalls berichten.

Danke auf jeden Fall schon mal bluestar. Das hilft schon mal weiter.

[bluestar]

Ich glaube hier findest du die Lösung: https://www.heinlein-support.de/blog/ho ... x-gruppen/

[Lookbehind]

Hallo bluestar,

ja prinzipiell scheinst du recht zu haben. Damit soll es gehen. Leider zeichnet die Praxis ein anderes Bild. Oder ich bin einfach zu blöd. Was ich nicht ausschließen möchte.

Einfaches hinzufügen des Schemas schlägt fehl, weil es quasi alle Elemente des rfc2307bis-Schemas bereits im nis-Schema gibt, nur mit anderer Konfiguration. Google findet diverse Möglichkeiten das zu beheben. Bloß funktioniert irgendwie keine davon.
- Das nis-Schema per ldapdelete zu entfernen schlägt fehl. Stellt sich raus, das ldapdelete seit slapd 2.4 für Änderungen an der Config quasi nutzlos geworden ist.
- Das der grandiose Tipp, das nis-Schema einfach aus der /etc/ldap/slapd.d/cn\=config/cn\=schema/ zu löschen/durch die rfc2307bis zu ersetzen, und dann slapd neu zu starten, in die Hose geht, hatte ich mir schon fast gedacht. Versucht habe ichs trotzdem, mit erwartetem Ergebnis. slapd startet nicht mehr, weil die Config in der Datenbank nicht mehr mit den Schemas zusammen passt.
- Am vielversprechendsten sah mir die Lösung aus, die /usr/share/slapd/slapd.init.ldif an zu passen, und dort das Include für das nis durch ein Include für rfc2307bis zu ersetzen, und dann mit dpkg-reconfigure slapd neu ein zu richten. Ebenfalls ein Schlag ins Wasser, weil sich das erst ändern lässt, nachdem slapd bereits installiert wurde. Dann ist die slapd.init.ldif aber schon angewendet worden, und das Update der Datenbank durch das reconfigure schlägt dann eben auch fehl.

Es könnte evtl erfolgreich sein, wenn ich für slapd ein eigens deb-Paket baue, mit einer slapd.init.ldif, die schon beim ersten installieren das rfc2307 beinhaltet. Aber die müsste ich dann auch langfristig maintainen. Da habe ich eigentlich so gar keine Lust drauf.

Insgesamt wundert es mich ohnehin, dass es dafür noch kein Patentrezept gibt. Es scheinen ja doch recht viele Anwendungen rfc2307bis zu brauchen, und nicht wenige damit Probleme zu haben. Dass es da noch nix von Ratiopharm gibt. *kratz*

Oder gibts doch was, und ich stell mich nur wieder viel zu blöd an?

Gruß

Look

[scientific]

Hi

Ich beschäftige mich momentan auch gerade mit LDAP. Das Thema ist neu für mich.

Aber ich hab ein super Tutorial gefunden, mit dem ich einmal meine Grundstruktur hinbekommen habe, in der ich jetzt spielen kann, um genauer zu verstehen, was da passiert.

https://devopsideas.com/openldap-linux- ... tegration/

Hier legt er ein neues Schema an, welches auf posixGroup aus dem nis-Schema basiert, welches die selben eigenschaften wie das Structural-Schema hat, außer dass es auxiliary ist. Damit kannst du es mit dem STRUCTURAL Schema groupofnames gemeinsam verwenden und musst nich manuell ein vorinstalliertes Schema austauschen.

Ich experimentiere grad damit herum und muss sagen, dass das ganz gut klappt. Bin allerdings auf ein anderes Problem gestoßen, wofür ich aber einen neuen Thread aufmache.

Danke für die beiden Links!

[bluestar]

Ich hab mal kurz geschaut, ein Samba AD-Server liefert dir einen LDAP-Baum mit rfc2307

[Lookbehind]

Hallo zusammen,

ich hab das Projekt wieder ein paar Wochen schleifen lassen. Hab leider hin und wieder auch noch was anderes zu tun

Ich hab mich noch mal ein wenig zurück gelehnt, und überlegt, was denn nun mein eigentliches Problem ist. Damit habe ich mich wieder ein Stück von LDAP entfernt, und wieder mehr auf eJabberd konzentriert. Und siehe da, es gibt eine Lösung. Das geht nur eben nicht in einer einzelnen LDAP-Abfrage, sondern es werden 2 benötigt.

Code: Alles auswählen

ldap_filter: "(objectClass=shadowAccount)"
ldap_dn_filter:
  "(&(objectclass=posixGroup)(cn=jabberusers)(memberUid=%u))": ["cn=jabberusers,ou=Groups,dc=example,dc=com"]

Der erste Filter prüft, ob es überhaupt einen User mit der UID gibt, und ob das Passwort stimmt. Der zweite Filter prüft, ob es ein LDAP-Objekt vom Typ posixGroup mit dem CommonName jabberusers gibt, welches die UID des Users als memberUID enthält, und legt fest, dass die Ergebnis-Liste ein Objekt cn=jabberusers,ou=Groups,dc=example,dc=com enthalten muss. (Was eigentlich doppelt gemoppelt ist, aber was solls ...)

Damit kann mein eJabberd nun auch endlich vernünftig gegen LDAP authentifizieren und ich kann anfangen den Kram produktiv zu holen. Auch ohne groupOfNames und rfc2307bis.

... was ne schwere Geburt. Ich danke allen Beteiligten für die Mühen und Versuche mir zu helfen.

Gruß

Look