Sven Gehr
Hallo,
schrieb Sven Gehr:
schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Dieter Kluenter:
Sven Gehr
writes: Wie kann ich feststellen ob das von mir verwendete RPM (von Suse-9.1) so gebaut wurde?
cd /etc mv sasldb2 sasldb2-bak
Die Datei gibt es nicht. Die einzigste Datei die es hier zu SASL gab war saslauthd.conf. Dies hatte ich jedoch selbst angelegt und habe sie wieder, wie Andreas gesagt hat, gelöscht.
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
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?
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 "uid=dieter,cn=avci,cn=GSSAPI,cn=auth" ist eine Variante, die ander ist "uid=dieter,cn=GSSAPI,cn=auth" In /var/log/localmessages sollte sich der SASL String finden.
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. 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' 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. Aber du willst ja eh kein SASL zur Authentifizierung nutzen, daher ist das nicht zu wichtig.
Da ich nun schon einige geändert habe fasse ich das hier nochmal zusammen:
** /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
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,
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.
####################################################################### # bdb database definitions #######################################################################
database bdb checkpoint 1024 5 cachesize 10000
cachesize ist Quatsch bei back-bdb, das ist nur für das veraltete back-ldbm
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.
** /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.
** /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. [...]
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.
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.
Im LDAP-Verzeichnis sieht es so aus: [...]
# search result search: 2 result: 0 Success
# numResponses: 10 # numEntries: 9
Ich weiß, ist ein bischen viel aber irgendow muß doch der Fehler liegen.
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) 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? -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de