Hallo,
Tobias Hofmann
Zusammenfassung: Ein Client sendet eine Reihe von Anfragen an meinen LDAP-Server - er will wissen, ob es den Nutzer gibt, und ob er in einer bestimmten Gruppe ist.
Das Suchen, Finden und Authentifizieren des Nutzers scheint kein Problem zu sein, funktioniert wie soll.
Das Finden der Gruppe(n), in denen der Nutzer Mitglied ist, scheitert, wenn der Eintrag des Nutzers in die Gruppe durch Setzen des Attributes memberUid=uid=username,ou=Unitname,dc=medien,dc=uni-weimar,dc=de derart geschieht, dass vor der search base (dc=medien...) _kein_ Leerzeichen steht.
Der folgende Befehl:
holix:~ # ldapsearch -x "(&(objectClass=posixGroup)(memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de))
Der Suchstring sieht etwas seltsam aus.
den ich fuer analog der Suche meiner Applikation halte (sh. gefundener filter aus debug-log), fuehrt nur zu einem Suchergebnis, wenn ich vor der search base das blank einfuege (per slapcat kontrolliert). Dabei spielt es keine Rolle, ob im dn der Gruppe Blanks eingetragen sind oder nicht, lediglich dass eine Mistblank vor der Search Base macht den Unterschied...
Ich erkenne langsam den Zusammenhang :-) Der Suchstring von ldapsearch setzt sich folgendermaßen zusammen ld/base/scope/filter/attribute Der Suchstring kann auch geschrieben werden /*/*/*/filter, oder ///filter Dein Suchstring wird nur als Filter erkannt, die Base wird auf default gesetzt, was vermutlich (dc=medien,dc=uni-weimar,dc=de) ist, scope wird ebenfalls auf Default gesetzt, das ist sub. Warum bei dir ein SPACE einen Unterschied macht, kann ich nicht nachvollziehen. Ich habe mal deinen Suchstring, für mein System umgesetzt, -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. marin:/usr/local/bin # ./ldapsearch -x "(&(objectClass=posixGroup)(memberUid=uid=dieter,ou=Partn r, ou=users,o=avci,c=de))" # extended LDIF # # LDAPv3 # filter: (&(objectClass=posixGroup)(memberUid=uid=dieter,ou=Partner, ou=users,o=avci,c=de)) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Mit, oder ohne Space an den unterschiedlichen Stellen, der Filter wird nicht erkannt. In meinen Logfiles steht dazu -.-.-.-.--.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. Sep 4 21:21:25 marin slapd[1025]: daemon: conn=197 fd=16 connection from IP=192.168.100.95:4983 7 (IP=:: 389) accepted. Sep 4 21:21:25 marin slapd[1053]: conn=197 op=0 BIND dn="" method=128 Sep 4 21:21:25 marin slapd[1053]: conn=197 op=0 RESULT tag=97 err=0 text= Sep 4 21:21:25 marin slapd[1054]: conn=197 op=1 SRCH base="o=avci,c=de" scope=2 filter="(&(obje ctClass=posixGroup)(memberUid=uid=dieter,ou=Partner, ou=users,o=avci,c=de))" Sep 4 21:21:25 marin slapd[1054]: <= bdb_equality_candidates: index_param failed (18) Sep 4 21:21:25 marin slapd[1054]: conn=197 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 4 21:21:25 marin slapd[1052]: conn=197 op=2 UNBIND Sep 4 21:21:25 marin slapd[1052]: conn=197 fd=16 closed -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--.-.-.-.-.-.-.- Wie du siehst, ist Default Searchbase o=avci,c=de, scope=2, das ist sub und default. Die Meldung 'equality candidates: index_param failed' sagt, daß der Index für objectclass eq verlangt und dafür keine Indexparameter vorhanden sind. Aber ich nutze auch die objectclass posixGroup. Das ist noch keine Wertung, erst einmal eine Feststellung. Jetzt können wir der Sache schon näher kommen. :-)
[...]
Ich habe das mit den Leerzeichen immer noch nicht verstanden. Sendet denn der Client die Anfrage mit den "fehlerhaften" Leerzeichen in der dn ?
Yep, genauso wie oben geschrieben - vor "dc=medien,..." ist ein space. Wenn ich einen Link haette, der bestaetigt, dass Spaces in solchen Anfragen nix koennen, wuerde ich den gerne dem Hersteller der Soft geben... :) Mir hat die Lektuere von RFC 2254 und 2252 nicht sehr weitergeholfen.
Kann es sein, daß der Client für Active Directory geschrieben ist? Das würde einiges erklären, insbesondere die seltsame Positionierung der Base, ans Ende des Suchstrings. Sofern dc=medien ... als Base definiert ist.
Für das LDIF Format ist ja auch RFC 2849 zuständig.
... den ich mittlerweile gelesen habe - Dank fuer Hinweis! :)
Zwei Fragen dazu:
Zum Einen kam von Dir und Harry der Hinweis, im dn sollen keine Blanks stehen, die Beispiele unter http://www.faqs.org/rfcs/rfc2849.html haben aber alle ein Blank drin? Gibts da was neueres? Ich fand auch keine Aussagen zu den Strings...
Jein. OPenLDAP ist da sensibler, und sagt, wenn in einem String ein SPACE als füllendes Element gesetzt wird, liegt das in der Verantwortung des Administrators. SPACES werden nicht komprimiert, sprich nicht als 'nicht vorhanden' behandelt. Die Gefahr besteht, daß zwei oder mehr SPACES gesetzt werden, dies bedeutet dann, daß der Rest des Strings BASE64 kodiert werden kann, oder auch andere mehrdeutige Interpretationen zuläßt. So steht es aber auch in RFC 2849, z.B. zum Thema dn specification. (SPACE = FILL)
Zum Anderen habe ich mich von rfc 2849 zu rfc 2253 durchgehangelt und dort folgenden Absatz gefunden:
Implementations MUST allow a semicolon character to be used instead of a comma to separate RDNs in a distinguished name, and MUST also allow whitespace characters to be present on either side of the comma or semicolon. The whitespace characters are ignored, and the semicolon replaced with a comma.
Hu? Steht das in einem ganz anderen Kontext und ich verhau da was?
Die Definition von 'Whitespace' ist nicht eindeutig. Das könnte SPACE oder TAB bedeuten. RFC 2849 spricht eindeutig nur von SPACE, ASCII Zeichen 0x20. Auch die Formulierung 'ignore'ist nicht eindeutig. Es könnte beuten, als 'nicht gesetzt' betrachten, oder aber auch als 'übernehmen aber nicht weiter berücksichtigen'. OpenLDAP übernimmt die Interpretationsmöglichkeit 'übernehmen, aber nicht weiter berücksichtigen'. Dies kann aber dann in einigen Fällen zu Konflikten führen, wie oben angedeutet.
Um das zum Ende zu bringen: Damit ich habe, was ich will (User werden den Gruppen zugeordnet) kann ich entweder haendisch immer das hier benoetigte blank einfuegen (baeh) oder updaten (sh. Hinweise der openldap-mailingliste - wenn die Recht haben... :).
Das mit dem Blank scheint mir eine schlechte Lösung zu sein. Ich denke, dann kann eine sinnvolle und systemkonforme Lösusng gefunden werden. Harry und ich werden dir mit Rat und Tat zur Seite stehen.
Deswegen fuerchte ich, dass ich entweder versuchen sollte, die openldap2-2.0.23-111.i386.rpm fuer die 8.0 auf meiner 7.3 zum laufen zu bekommen, oder ich baue mir entweder 2.0.25 oder 2.1.4 selber - stimmt das so?
Ich habe hier zu Testzwecken vier verschieden OpenLDAP Versionen, 1.2.11, 2.0.23, 2.1.2., 2.1.3. Mein bevorzugtes Testobjekt ist die Version 2.1.3, auf 2.0.23 laufen noch ein paar Anwendungen, 1.2.11 ist für meinen Mailserver und 2.1.2 wird nicht mehr genutzt. ein update auf eine andere 2.0.x Version halte ich nicht für sinnvoll. Wenn du unbedingt aufrüsten möchtest, dann 2.1.3. Die Version 2.1.4 scheint bei einigen Leuten Probleme zu bringen. Aber ich warne dich, ein update kann Probleme bringen, wenn die Datensätze nicht RFC konform sind. Ein simples slapcat zur Erzeugung eines *.ldif und dann ein ldapadd auf 2.1.x kann katastrophal werden. Nicht das das Problem unlösbar wäre, aber vermutlich verwendest du unwissentlich inkompatible objectclasses in einem Datensatz, hast bei der ursprünglichen Erstellung des Datensatzes am Ende eines Strings kein CR durchgeführt, oder ähnliches. Wenn du updatest, solltest du auch Berkeley DB Version 4.x verwenden, am besten auch gleich cyrus-sasl-2.1.x, wie sieht es mit Kerberos aus? PAM könnte auch die neuste Version vertragen :-) Im Ernst, wir sollten erst einmal versuchen, deinen Suchstring so zu formulieren, daß auch gefunden wird, was du suchst.
Dank fuer euer Feedback und euren Langmut,
Ich freu mich immer noch auf feedback,
Ich spreche jetzt mal für Harry mit, denn ich glaube er wird meine Worte unterstützen :-) Wir freuen uns über jeden Aspiranten, der sich OpenLDAP zuwendet und versuchen ihn im Rahmen unseres Wissens und unserer Freizeit (manchmal auch darüber hinaus) zu unterstützen. (das war das Wort zum Sonntag :-)) -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour