Sven Gehr
Hallo,
Am Montag, 24. Mai 2004 10:43 schrieb Dieter Kluenter:
Sven Gehr
writes: [...] 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
Unter SASL wird üblicherweise die C API libsasl verstanden, d.h. eine Bibliothek, die in mit C progammierten Programmen eingebunden werden kann. Um einer Anwendung (in diesem Falle slapd) eine erfolgreiche Authentifizierung mitzuteilen, wird eine Zeichenkette erzeugt in der Form eines Distinguished Names, diese Zeichenkette besteht aus der uid, dem Mechanismus und dem Wort auth, gegebenenfalls ist noch der sasl realm in dieser Zeichenkette enthalten. Nachstehend habe ich zwei Bespiele einer solchen Zeichenkette aufgezeigt.
"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?
So sieht der Logauszug bei mir aus ,----[ Auszug aus localmessages ] | [1928]: slap_sasl_regexp: converting SASL name uid=dieter,cn=gssapi,cn=auth | [1928]: slap_sasl_regexp: converted SASL name to ldap:///o=avci,c=de??sub?uid=dieter | [1928]: slap_parseURI: parsing ldap:///o=avci,c=de??sub?uid=dieter | [1928]: getdn: dn:id converted to cn=dieter kluenter,ou=partner,o=avci,c=de `----
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))"
Aha, eine Verbindung über localhost. hier wird root als Suchfilter benutzt
slapd[2367]: conn=54 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Die obigen Attribute für root werden gesucht
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
es wurde kein Eintrag für root gefunden, (nentries=0)
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))"
und noch einmal [...]
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.
Ja.
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)
libsasl wird eingebunden, also ist OpenLDAP mit libsasl kompiliert. [...]
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:
[...]
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
da fehlt einiges, z.b. der folgende Auszug supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN
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 ?
Ich habe schon einige Male versucht, den Unterschied zu erklären, SASL ist die API und die Sammlung von Mechanismen zu Authentifizierung, saslauthd ist ein Daemon zu Authentifierung, der auf unterschiedliche Weise Anwender authentifizieren kann, SASL ungleich saslauth
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.
Das ist zwar richtig, aber es muß auch getestet werden, ob die Clients überhaupt TLS nutzen können.
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.
OK
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 ?
Keine Ahnung in welchem Verzeichnis cacert.pem bei dir liegt, vermutlich aber in /etc/openldap/demoCA, wenn du meiner Beschreibung folgst.
** /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?
Wenn du mit md5 verschlüsseln möchtest, ja, dann muß das geändert werden.
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?
Richtig, du möchtest saslauthd zur Authentifizierung durch Postfix u.a. nutzen, da du kein strong bind mit OpenLDAP durchführen möchtest, brauchst du keine SASL-Mechanismen, das sind die Bibliotheken, die unter /usr/lib/sasl2/ liegen.
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?
nur saslauthd.conf
Ich habe die Datei /etc/saslauthd.con mit diesem Inhalt angelegt:
ldap_servers: ldaps://testserver.kundennetz ldap_search_base: dc=kundennetz
Ist das ok?
Ja, das ist OK, und sollte vorerst ausreichen. [...]
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?
Irgendwie schon. Ich will das noch einmal zusammenfassen. TLS wird über den Standardport 389 und der URI LDAP:// durchgeführt. SSL wird über Port 636 und der URI LDAPS:// durchgeführt, du mußt dich da entscheiden was du möchtest, du kannst auch beide nehmen, dann sollte der Befehl 'ps ax' etwa folgende Zeilen zeigen ,----[ Prozesstabelle ] | 0:00 /usr/local/libexec/slapd -h ldap:/// ldaps:/// -u ldap -g ldap | 0:00 /usr/local/libexec/slapd -h ldap:/// ldaps:/// -u ldap -g ldap | 0:00 /usr/local/libexec/slapd -h ldap:/// ldaps:/// -u ldap -g ldap `---- Das SuSE-Schema enthält Attribute für eine Authentifizierung durch PAM, dem Plugable Authentication Module, die Authentifizierung für das System geht über PAM, also auch login u.a. statt der Datei /etc/passwd und /etc/shadow wird das Protokoll LDAP und damit der Server slapd als Datenbank für Password und Identität genutzt Andere Anwendungen wie z.B. Postfix und cyrus-sasl authentifizieren nicht direkt durch PAM, sondern durch saslauthd. Saslauthd kann auf unterschiedliche Methoden zu Authentifizierung zurückgreifen. Sofern Cyrus-SASL mit dem experimentellen Parameter --with-ldap kompiliert wurde, kann saslauthd auch auf einen Verzeichnisdienst zurückgreifen. Auf einer SuSE-9.0 habe ich gerade mal die in saslauthd eingebundenen Libraries geprüft und da ist keine libldap dabei ,----[ /usr/sbin/saslauthd ] | # ldd saslauthd | libgssapi.so.1 => /usr/lib/libgssapi.so.1 (0x4002d000) | libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x4003b000) | libasn1.so.6 => /usr/lib/libasn1.so.6 (0x40079000) | libroken.so.16 => /usr/lib/libroken.so.16 (0x400a0000) | libcrypt.so.1 => /lib/libcrypt.so.1 (0x400b3000) | libcom_err.so.2 => /lib/libcom_err.so.2 (0x400e5000) | libresolv.so.2 => /lib/libresolv.so.2 (0x400e8000) | libpam.so.0 => /lib/libpam.so.0 (0x400fa000) | libc.so.6 => /lib/i686/libc.so.6 (0x40102000) | libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x40235000) | libdb-4.1.so => /usr/lib/libdb-4.1.so (0x40328000) | libdl.so.2 => /lib/libdl.so.2 (0x403ec000) | /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) `---- Demnach kann der von SuSE-9.0 gelieferte saslauthd nicht die Authentifizierung über ldap vornehmen, aber über pam. Wenn du also an saslauthd den Parameter pam übergibst, wird PAM die Authentifizerung über LDAP vornehmen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de