Hallo, Am Montag, 24. Mai 2004 10:43 schrieb Dieter Kluenter:
Sven Gehr
writes:
ldapwhoami -H ldap://my.host -b "deine suchbase" -Y digest-md5, das richtige Ergebnis bekommst du aber nur, wenn du entsprechende sasl-regexp in /etc/openldap/slapd.conf definierst.
Das scheint ein Fehler drin zu sein. Ich erhalte die Meldung:
".... invalid option -- b"
Nwein, mein Beispiel ist schon richtig :-) Sieh dir mal die Fehlermeldung genau an und vergleiche diese mit meinem Beispiel. Aber das ist ein Fehler, den ich anfangs auch häufig gemacht habe, zwischen den Schaltern z.B. (b) und den Anführungszeichen muß ein Leerraum sein, auch Space genannt
Das Leerzeichen war schon drin. Ein 'ldapwhami --help" gibt ebenfalls keine Option -b aus.
Außerdem, müßte es jetzt nicht " ... -H ldaps://..." lauten da ich ja den LDAP nun auf Port 636 betreibe?
Dann muß das so sein, aber warum nutzt du das veraltete SSL over LDAP Protokoll, daß eh nicht mehr unterstützt wird, anstelle der Funktion ldap_start_tls über Port 389?
Tue ich das? Wie benutze ich denn: 'ldap_start_tls über Port 389' ?
sasl-regexp uid=(.*),cn=.*,cn=auth uid=$1,dc=kundennetz
Habe ich 1:1 so in meine slapd.conf übernommen.
Den SASL-Authentifizierungsstring solltest du prüfen, der kann richtig sein, kann aber auch um den SASL Realm erweitert sein. Ich habe hier auf zwei Systemen auch unterschiedliche Strings
Leider weiß ich nicht einmal was diese drei Zeilen bedeuten. Das macht es für mich schwierig den String zu überprüfen
"uid=dieter,cn=avci,cn=GSSAPI,cn=auth" ist eine Variante, die ander ist "uid=dieter,cn=GSSAPI,cn=auth"
Weiter unten habe ich ja den Inhalt aus meinem LDAP-Verzeichnis gepostet. Wie müßte das bei mir lauten?
In /var/log/localmessages sollte sich der SASL String finden.
Also so wirklich fnden tue ich da nichts. Hier das Ende der der Datei. Ich habe nur die LDAP-Meldungen herauskopiert: slapd[2367]: conn=54 fd=31 ACCEPT from IP=127.0.0.1:32832 (IP=0.0.0.0:389) slapd[2367]: conn=54 op=0 BIND dn="" method=128 slapd[2367]: conn=54 op=0 RESULT tag=97 err=0 text= slapd[2367]: conn=54 op=1 SRCH base="dc=kundennetz" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=root))" slapd[2367]: conn=54 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass slapd[2367]: conn=54 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= slapd[2367]: conn=54 op=2 SRCH base="dc=kundennetz" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=root))" slapd[2367]: conn=54 op=2 SRCH attr=cn userPassword memberUid uniqueMember gidNumber slapd[2367]: conn=54 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= slapd[2367]: conn=54 fd=31 closed slapd[2367]: conn=55 fd=31 ACCEPT from IP=127.0.0.1:32833 (IP=0.0.0.0:389) slapd[2367]: conn=55 op=0 BIND dn="" method=128 slapd[2367]: conn=55 op=0 RESULT tag=97 err=0 text= slapd[2367]: conn=55 op=1 SRCH base="dc=kundennetz" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=root))" slapd[2367]: conn=55 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass slapd[2367]: conn=55 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= May 24 10:30:00 testserver slapd[2367]: conn=55 op=2 SRCH base="dc=kundennetz" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=root))" slapd[2367]: conn=55 op=2 SRCH attr=cn userPassword memberUid uniqueMember gidNumber slapd[2367]: conn=55 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= slapd[2367]: conn=55 fd=31 closed
und rufe anschließend: ldapwhoami -H ldap://localhost -b "dc=kundennetz" -Y digest-md5
Ich habe einfach mal: ldapwhoami -H ldaps://localhost -Y digest-md5 eingegeben. Da erhalte ich die Meldung: ldap_sasl_interacive_bind_s: Unknon authentification method (-6) additional info: SASL(-4): no mechanism avalibal: No worthy mechs found
Die Fehlermeldung kann drei Ursachen haben, 1. slapd ist mit einer falschen libsasl gelinkt, das findest du raus, indem du ins Verzeichnis von slapd wechselst, das ist bei SuSE glaube ich /usr/sbin, dann als root 'ldd sladp' eingibst, es werden dir dann alle gelinkten Libraries angezeigt.
Also ich denke 'sladp' ist ein Buchstabendreher und muß slapd lauten. Diee habe ich gefunden. Zwar nicht in /usr/sbin, dafür jedoch in /usr/lib/openldap. Ein ldd slapd gibt aus: linux-gate.so.1 => (0xffffe000) libldap_r.so.199 => /usr/lib/libldap_r.so.199 (0x4001e000) liblber.so.199 => /usr/lib/liblber.so.199 (0x40057000) libdb-4.2.so => /usr/lib/tls/libdb-4.2.so (0x40064000) libslp.so.1 => /usr/lib/libslp.so.1 (0x4013a000) libm.so.6 => /lib/tls/libm.so.6 (0x4014f000) libnsl.so.1 => /lib/libnsl.so.1 (0x40171000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x40186000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x4019b000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x401cb000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x402bc000) libresolv.so.2 => /lib/libresolv.so.2 (0x402ed000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0x402ff000) libdl.so.2 => /lib/libdl.so.2 (0x40306000) libwrap.so.0 => /lib/libwrap.so.0 (0x40309000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40311000) libc.so.6 => /lib/tls/libc.so.6 (0x40322000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
2. OpenLDAP ist ohne SASL Support kompiliert worden, Da hilft dann 'ldapsearch -H ldap://localhost -b "" -s base + -x' es sollten dir dann alle operationalen Attribute angzeigt werden, auch die Attribute für 'supportedSASLMechanisms'
Ich denke mal da fehlt schon etwas. Dieser Befehl erzeugt die Ausgabe: # extended LDIF # # LDAPv3 # base <> with scope base # filter: (objectclass=*) # requesting: + # # dn: structuralObjectClass: OpenLDAProotDSE namingContexts: dc=kundennetz supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.1413 supportedControl: 1.2.840.113556.1.4.1339 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
3. In frühen OpenLDAP (openldap-2.1.1 bis 2.1.8) und Cyrus-SASL (2.1.4 bis 2.1.12) Versionen waren die SASL Mechanisms 'Case Sensitive' 'digest-md5' wurde nicht gefunden, wohl aber 'DIGEST-MD5', vielleicht ist das bei dir auch der Fall.
Nein. Das ändert nichts an der Fehlermeldung.
Aber du willst ja eh kein SASL zur Authentifizierung nutzen, daher ist das nicht zu wichtig.
Bei mir wird die Verwirrung jetzt aber immer größer. Warum möchte ich jetzt kein SASL mehr benutzen. Oder ist damit etwas anderes gemeint wie SASLAUTHD ?
** /etc/openldap/slapd.conf **
include /etc/openldap/schema/yast2userconfig.schema
pidfile /var/run/slapd/run/slapd.pid argsfile /var/run/slapd/run/slapd.args
schemacheck on
Das ist Quatsch, die Variable schemacheck ist veraltet, du kannst die Prüfung nicht mehr unterbinden. Es sei denn, du hast noch eine uralte Version OpenLDAP
Nein die Version ist ja recht aktuell Ich habe den Parameter raus genommen.
modulepath /usr/lib/openldap/modules
TLSCertificateFile /etc/openldap/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ldapkey.pem TLSCACertificateFile /etc/openldap/demoCA/cacert.pem
sasl-regexp uid=(.*),cn=.*,cn=auth uid=$1,dc=kundennetz
#TLSCipherSuit HIGH:MEDIUM:+SSLv2 #TLSVerifyClient allow
Das solltest du schon aktivieren, wenn du /SSL/TLS nutzt,
Ok, habe sie aktiviert. Ich habe die Kommentare nur drin gelassen weil im Buch stand ich solle die erst raus nehmen wenn alles zufriedenstellend läuft.
access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by users read by anonymous auth
Das könnte noch ein Problem sein, 'users read' bedeuted, daß nur authentifizierte User lesen dürfen, da du aber noch keine Bind Funktionen einsetzt, du auch nicht durch andere Mechanismen einsetzt um dich dzu authentifizieren, kannst du auch nicht lesend auf den Server zugreifen. Setze das erst einmal auf 'by * read', das kannst du später wieder ändern.
Wie soll ich das ändern: by users read -> by * read ? Ist so drin.
cachesize ist Quatsch bei back-bdb, das ist nur für das veraltete back-ldbm
auch raus.
lastmod on Das ist default daher unnötig, 'lastmod' steht für 'last modify', es soll also ein Timestamp bei einer Veränderung des Eintrages gesetzt werden. Ohne Timestamp währe aber der Datensatz nicht konsistent.
auch raus
** /etc/openldap/ldap.conf **
TLS_REQCERT allow host 192.168.1.1 base dc=kundennetz
Da fehlt zwingend TLS_CACERT und Pfad. Der Client muß in der Lage sein, das Zertifikat des Servers mit dem cacert.pem zu prüfen.
Also 'TLS_CACERT /etc/openldap/demoCA' In diesem Pfad liegt die cacert.pem ?
** /etc/ldap.conf ** host 127.0.0.1 base dc=kundennetz ldap_version 3 pam_password crypt ssl no
Wenn slapd nur auf Port 636 lauscht, kann PAM so nicht funktionieren, denn du schaltest ja SSL aus und PAM versucht Port 389.
Wie muß ich es dann ändern? ssl on ? So habe ich es jetzt mal geändert. Außerdem, muß pam_password nicht md5 lauten bei mir?
Die Dateien:> - /usr/lib/sasl2/slapd.conf - /etc/saslauthd.conf welche ich zuvor angelegt hatte, habe ich wider gelöscht.
Die brauchst du ja auch nicht, da du kein SASL einsetzen möchtest.
Hatten wir nicht festgestellt das ich SASL brauche oder ist hier wieder nicht SASLAUTHD gemeint?
saslauthd ist gestartet. LDAP ist über sysconfig auf Port 636 konfiguriert und /etc/sysconfig/saslauthd_authmech=ldap konfiguriert.
Das kann ja nicht funktionieren, saslathd.conf gelöscht, saslauthd soll aber die Authentifzierung über ldap vornehmen, der Default Port ist 389 und nicht 636. Wenn du das beibehalten willst, mußt du saslauth konfigurieren.
Ok, welche der beiden Dateien: /usr/lib/sasl2/slapd.conf /etc/saslauthd.conf muß ich wieder anlegen? Nur die saslauthd.conf? Und noch viel wichtiger was muß drin stehen? Ich habe die Datei /etc/saslauthd.con mit diesem Inhalt angelegt: ldap_servers: ldaps://testserver.kundennetz ldap_search_base: dc=kundennetz Ist das ok?
An den Einträgen konnte ich keine Mängel entdecken, außer das ich mich mal wieder über SuSE aufrege, die scheinbar ohne RFC's und Drafts zu lesen, eigene Schemas entwickeln. Beim nächsten Update muß dann alles wieder geändert werden und die alte Installation funktioniert nicht mehr. (z.B. draft-beherea-ldap-password-policy)
Das kann ich nicht beurteilen, dazu fehlt mir das Detailwissen.
Die Daten hast du ja mit ldapsearch ausgelesen, also scheint das ja im Prinzip zu funktionieren. /etc/nsswitch.conf ist geändert, /etc/ldap.conf existiert, 'getent passwd' zeigt die richtigen Einträge an, was funktioniert denn noch nicht?
Nach den nun durchgeführten Änderungen startet saslauthd nicht mehr: saslauthd[2979]: set_auth_mech: unknown authentication mechanism: ldap Ein Login als User 'sven' funktioniert natürlich auch nicht mehr. Ich habe das Gefühl ich bewege mich im Kreis? Viele Grüße Sven