wie funktioniert SASL / TLS vom Prinzip her
Hallo zusammen, ich habe mal eine grundsätzliche Frage zu SASL. Nach den Informationn welche ich finden konnte ist SASL ein dienst der Läuft und die Benutzeranmeldungen entgegen nimmt und die User/Passwort - Kombinationen in sasldb abgleicht. Habe ich das soweit richtig verstanden? Wie ist jedoch das zusammenspiel wenn die Komponenten: - LDAP - PAM noch mitspielen? Der jetzige Istzustand ist der das Der LDAP-Server (SuSE-9.1) läuft und PAM so konfiguriert ist das ein lokaler Login den User aus dem LDAP-Server benutzt. Das funktioniert schon. Nun soll das ganze jedoch abgesichert werden. Soweit ich die Unterlagen verstanden kann ich hierzu den Verbindungsaufbau mit TLS verschlüsselt abwickeln und die dananach aufgebaute Verbindung mit SSL verschlüsseln. Richtig? Kann ich das mit SASL realisieren oder ist das etwas anderes? Mir kommt es so vor als würde der Dienst SASL das gleiche macheen wie PAM. Gruß Pixel
Am Freitag, 21. Mai 2004 20:08 schrieb Sven Gehr:
ich habe mal eine grundsätzliche Frage zu SASL. Nach den Informationn welche ich finden konnte ist SASL ein dienst der Läuft und die Benutzeranmeldungen entgegen nimmt und die User/Passwort - Kombinationen in sasldb abgleicht. Habe ich das soweit richtig verstanden?
Jein. Was Du meinst ist der saslauthd. Das ist jedoch der kleinste Teil der SASL-Library und er hat nix mit der sasldb zu tun. Die SASL-Library regelt die Übertragung und den Handshake bei den verschiedenen Protokollen, wie z.B. SMTP, POP3, IMAP. Der Vollständigkeit halber bringt diese auch den Zugriff auf die Userdaten (z.B. Name und Passwort) mit. Und hierfür ist dann PAM eine Alternative. Du kannst also durchaus SASL und PAM verwenden. In aktuellen SASL-Versionen kommt dann da der saslauthd ins Spiel.
Wie ist jedoch das zusammenspiel wenn die Komponenten:
- LDAP - PAM
LDAP ist ein Netzwerkprotokoll, welches natürlich auch eine Authentifizierung erfordert und hier kommt dann SASL ins Spiel. PAM kann eine LDAP-Datenbank als Storage für die Benutzer/Passwörter verwenden.
noch mitspielen? Der jetzige Istzustand ist der das Der LDAP-Server (SuSE-9.1) läuft und PAM so konfiguriert ist das ein lokaler Login den User aus dem LDAP-Server benutzt. Das funktioniert schon.
Nun soll das ganze jedoch abgesichert werden. Soweit ich die Unterlagen verstanden kann ich hierzu den Verbindungsaufbau mit TLS verschlüsselt abwickeln und die dananach aufgebaute Verbindung mit SSL verschlüsseln. Richtig?
Kann ich das mit SASL realisieren oder ist das etwas anderes?
SSL/TLS ist eine Verschlüsselung der kompletten Leitung. Damit würde dann auch der Authentifizierungs-Handshake (SASL) verschlüsselt. SSL ist eine direkte Verschlüsselung der Leitung, meistens auf einem anderen Port. TLS ist eine Möglichkeit eine Verbindung über den normalen Port aufzubauen und wenn der Server TLS unterstüzt, nachträglich die Verschlüsselung einzuschalten. TLS hat SSL inzwischen fast verdrängt.
Mir kommt es so vor als würde der Dienst SASL das gleiche macheen wie PAM.
-- Andreas
Hallo zusammen, schrieb Andreas Winkelmann:
schrieb Sven Gehr:
Die SASL-Library regelt die Übertragung und den Handshake bei den verschiedenen Protokollen, wie z.B. SMTP, POP3, IMAP. Der Vollständigkeit halber bringt diese auch den Zugriff auf die Userdaten (z.B. Name und Passwort) mit. Und hierfür ist dann PAM eine Alternative. Du kannst also durchaus SASL und PAM verwenden. In aktuellen SASL-Versionen kommt dann da der saslauthd ins Spiel.
Das bedeutet ich kann meine User/Passwort - Kombinationen im LDAP-Verzeichnis haben, was ja auch bereits der Fall ist. Diese sind hier als MD5-Hashwert gespeichert. Als 'Login-Mechanismus' benutze ich wie ebenfalls breits eingerichtet PAM und SASL regelt nur den eigentlichen Verbindungsaufbau. Hierzu läuft der Dienst saslauth. Dieser läßt sich über den Sysconfig (Yast) auf verschiedene Werte einstellen: Option: SASL_AUTHMECH Mögliche Werte: ldap, getpwent, kerberos, pam rimap, shadow Hier ist mir nicht klar ob ich ldap oder pam einstellen muß. Dies wäre mir klar wenn ich wüßte wie sasl beim Loginspiel mit den anderen Komponenten zusammenspielt. Loginversuch -> PAM -> SLAS-Aufruf um Verbinungsaufbau zu verschlüsseln -> LDAP Dann wäre sicher SASL_AUTHMECH=pam die richtige Einstellung Wenn jedoch die Position von SASL und PAM umgekehrt wäre müßte ich doch LDAP einstellen, oder?
LDAP ist ein Netzwerkprotokoll, welches natürlich auch eine Authentifizierung erfordert und hier kommt dann SASL ins Spiel.
So wie ich es o.g. annehme?
PAM kann eine LDAP-Datenbank als Storage für die Benutzer/Passwörter verwenden.
noch mitspielen? Der jetzige Istzustand ist der das Der LDAP-Server (SuSE-9.1) läuft und PAM so konfiguriert ist das ein lokaler Login den User aus dem LDAP-Server benutzt. Das funktioniert schon.
Neben der o.g. Umgebungsvariabe finde ich kein Konfigurationsdatei für saslauthd. Wie gehe ich für die Einrichtung vor bzw. wie kann ich überprüfen ob er richtig funktioniert?
Nun soll das ganze jedoch abgesichert werden. Soweit ich die Unterlagen verstanden kann ich hierzu den Verbindungsaufbau mit TLS verschlüsselt abwickeln und die dananach aufgebaute Verbindung mit SSL verschlüsseln. Richtig?
SSL/TLS ist eine Verschlüsselung der kompletten Leitung. Damit würde dann auch der Authentifizierungs-Handshake (SASL) verschlüsselt.
SSL ist eine direkte Verschlüsselung der Leitung, meistens auf einem anderen Port. TLS ist eine Möglichkeit eine Verbindung über den normalen Port aufzubauen und wenn der Server TLS unterstüzt, nachträglich die Verschlüsselung einzuschalten. TLS hat SSL inzwischen fast verdrängt.
Ich denke mal das bei SASL noch mein Problem liegt. Wenn ich wie im Buch beschrieben den Befehl: ldapsearch -d -1 -ZZ -b "dc=kundennetz" -s sub "(&(objectclass=posixaccount) (mail=*))" direkt am Server eingebe um das Protokoll eines Verbindungaufbau betrachte zu können erhalte ich auch hier Fehlermeldungen die auf ein Zertifikat-Problem hindeuten. [...] TLS trace: SSL_connect:bevor/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello a TLS trace: SSL_connect:SSLv3 read server hello a TLS certificate verification: ....... TLS certificate verification: Error, self signed certificat [...] TLS trace: SSL3 alert write:warning:bad certificate TLS: unable to get per certificate [...] ldap_sasl_interactive_bind_s: server supports: LOGIN ldap_int_sasl_bind: LOGIN ldap_int_sasl_open: host=testserver.kundennetz SASL/LOGIN authentification started [...] sasl_client_step: 2 Please enter your passwort: [Hier gebe ich mein Passwort ein] [...] ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: checkpass failed Das deutet auf ein Problem mit SASL und dem Zertifikat hin, oder? Wenn ich z.B. am Server direkt den Befehl: ldapwhoami eingebe erhalte ich den Fehler: ldap_sasl_interactive_bind_s: No such attribut (16) Ich hoffe das jemand damit etwas anfangen kann. Viele Grüße Sven Gehr
Am Samstag, 22. Mai 2004 12:06 schrieb Sven Gehr:
Die SASL-Library regelt die Übertragung und den Handshake bei den verschiedenen Protokollen, wie z.B. SMTP, POP3, IMAP. Der Vollständigkeit halber bringt diese auch den Zugriff auf die Userdaten (z.B. Name und Passwort) mit. Und hierfür ist dann PAM eine Alternative. Du kannst also durchaus SASL und PAM verwenden. In aktuellen SASL-Versionen kommt dann da der saslauthd ins Spiel.
Das bedeutet ich kann meine User/Passwort - Kombinationen im LDAP-Verzeichnis haben, was ja auch bereits der Fall ist. Diese sind hier als MD5-Hashwert gespeichert. Als 'Login-Mechanismus' benutze ich wie ebenfalls breits eingerichtet PAM und SASL regelt nur den eigentlichen Verbindungsaufbau.
Hierzu läuft der Dienst saslauth. Dieser läßt sich über den Sysconfig (Yast) auf verschiedene Werte einstellen:
Option: SASL_AUTHMECH Mögliche Werte: ldap, getpwent, kerberos, pam rimap, shadow
Hier ist mir nicht klar ob ich ldap oder pam einstellen muß. Dies wäre mir
saslauthd -> pam -> pam_ldap -> ldap-server saslauthd -> ldap -> ldap-server Mit dem zweiten würdest Du eine Station sparen.
klar wenn ich wüßte wie sasl beim Loginspiel mit den anderen Komponenten zusammenspielt.
Das ist auch gerade in Bezug auf ldap nicht ganz einfach ;-) Ganz grob gesagt, SASL ist ein Protokoll um Passwörter zu verifizieren, normalerweise besitzt es die Schittstelle um auf eine Datenbank zuzugreifen bei LDAP halt ldap. Sobald es aber dazu benutzt wird um die eigene Verbindung SASL->LDAP-Server zu handeln wird es kompliziert ;-)
Loginversuch -> PAM -> SLAS-Aufruf um Verbinungsaufbau zu verschlüsseln -> LDAP
Dann wäre sicher SASL_AUTHMECH=pam die richtige Einstellung
Wenn jedoch die Position von SASL und PAM umgekehrt wäre müßte ich doch LDAP einstellen, oder?
Die Passwörter liegen in der ldap-datenbank. Das ist die Basis, der Weg dahin kann sehr unterschiedlich sein.
LDAP ist ein Netzwerkprotokoll, welches natürlich auch eine Authentifizierung erfordert und hier kommt dann SASL ins Spiel.
So wie ich es o.g. annehme?
PAM kann eine LDAP-Datenbank als Storage für die Benutzer/Passwörter verwenden.
noch mitspielen? Der jetzige Istzustand ist der das Der LDAP-Server (SuSE-9.1) läuft und PAM so konfiguriert ist das ein lokaler Login den User aus dem LDAP-Server benutzt. Das funktioniert schon.
Neben der o.g. Umgebungsvariabe finde ich kein Konfigurationsdatei für saslauthd. Wie gehe ich für die Einrichtung vor bzw. wie kann ich überprüfen ob er richtig funktioniert?
Wenn Du "saslauthd -a ldap" benutzen möchtest, müsste die Config bei Suse in / etc/saslauthd.conf zu finden sein. Habe aber hier kein Suse-SASL Paket mehr, der default bei Cyrus-SASL ist "/usr/local/etc/saslauthd.conf".
Nun soll das ganze jedoch abgesichert werden. Soweit ich die Unterlagen verstanden kann ich hierzu den Verbindungsaufbau mit TLS verschlüsselt abwickeln und die dananach aufgebaute Verbindung mit SSL verschlüsseln. Richtig?
SSL/TLS ist eine Verschlüsselung der kompletten Leitung. Damit würde dann auch der Authentifizierungs-Handshake (SASL) verschlüsselt.
SSL ist eine direkte Verschlüsselung der Leitung, meistens auf einem anderen Port. TLS ist eine Möglichkeit eine Verbindung über den normalen Port aufzubauen und wenn der Server TLS unterstüzt, nachträglich die Verschlüsselung einzuschalten. TLS hat SSL inzwischen fast verdrängt.
Ich denke mal das bei SASL noch mein Problem liegt. Wenn ich wie im Buch beschrieben den Befehl:
ldapsearch -d -1 -ZZ -b "dc=kundennetz" -s sub "(&(objectclass=posixaccount) (mail=*))"
direkt am Server eingebe um das Protokoll eines Verbindungaufbau betrachte zu können erhalte ich auch hier Fehlermeldungen die auf ein Zertifikat-Problem hindeuten.
[...] TLS trace: SSL_connect:bevor/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello a TLS trace: SSL_connect:SSLv3 read server hello a TLS certificate verification: ....... TLS certificate verification: Error, self signed certificat [...] TLS trace: SSL3 alert write:warning:bad certificate TLS: unable to get per certificate [...] ldap_sasl_interactive_bind_s: server supports: LOGIN ldap_int_sasl_bind: LOGIN ldap_int_sasl_open: host=testserver.kundennetz SASL/LOGIN authentification started [...] sasl_client_step: 2 Please enter your passwort: [Hier gebe ich mein Passwort ein] [...] ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: checkpass failed
Das deutet auf ein Problem mit SASL und dem Zertifikat hin, oder? Wenn ich z.B. am Server direkt den Befehl:
ldapwhoami
eingebe erhalte ich den Fehler:
ldap_sasl_interactive_bind_s: No such attribut (16)
Hast Du denn sasl überhaupt konfiguriert in der slapd.conf? -- Andreas
Am Samstag, 22. Mai 2004 14:23 schrieb Andreas Winkelmann:
schrieb Sven Gehr:
Hierzu läuft der Dienst saslauth. Dieser läßt sich über den Sysconfig (Yast) auf verschiedene Werte einstellen:
Option: SASL_AUTHMECH Mögliche Werte: ldap, getpwent, kerberos, pam rimap, shadow
Hier ist mir nicht klar ob ich ldap oder pam einstellen muß. Dies wäre mir
saslauthd -> pam -> pam_ldap -> ldap-server saslauthd -> ldap -> ldap-server
Ich denke hier konnte ich ein Fehler lokalisieren. Der Befehl: 'saslauth -v' gibt folgendes aus: saslauthd 2.1.18 authentification mechanisms: getpwent kerberos5 pam rimap shadow Also nix mit LDAP. Das dürfte wohl bedeuten ich mup den: saslauthd -> pam -> pam_ldap -> ldap-server Weg gehen, richtig? Warum jedoch im Yast/Syconfig LDAP als Auswahl angeboten wird ist mir dann nicht ganz klar. Somit habe ich als Einstellung 'pam' gewählt.
Neben der o.g. Umgebungsvariabe finde ich kein Konfigurationsdatei für saslauthd. Wie gehe ich für die Einrichtung vor bzw. wie kann ich überprüfen ob er richtig funktioniert?
Wenn Du "saslauthd -a ldap" benutzen möchtest, müsste die Config bei Suse in / etc/saslauthd.conf zu finden sein. Habe aber hier kein Suse-SASL Paket mehr, der default bei Cyrus-SASL ist "/usr/local/etc/saslauthd.conf".
Ich habe nun die Datei: /etc/saslauthd.conf angelegt und dort eingetragen: ldap_servers: ldap://testserver.kundennetz ldap_search_base: dc=kundennetz ldap_bind_dn: cn=root,dc=kundennetz ldap_bind_pw: {MD5}[MD5-Hash-Wert] ldap_auth_method: bin Desweiteren habe ich eine Datei: /usr/lib/sasl2/slapd.conf mit dem Inhalt: pwcheck_method: pam angelegt.
Hast Du denn sasl überhaupt konfiguriert in der slapd.conf?
Hier habe ich drin: [...] TLSCertificateFile /etc/openldap/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ldapkey.pem TLSCertifikateFile /etc/openldap/demoCA/cacert.pem sasl-host testserver.kundennetz sasl-realm TESTSERVER [...] Mus dieser sasl-realm vorher irgendwo definiert werden?
ldapwhoami
eingebe erhalte ich den Fehler:
ldap_sasl_interactive_bind_s: No such attribut (16)
Jedoch erhalte ich nach wie vor den gleichen Fehler. Viele Grüße Sven
Am Samstag, 22. Mai 2004 15:58 schrieb Sven Gehr:
saslauthd -> pam -> pam_ldap -> ldap-server saslauthd -> ldap -> ldap-server
Ich denke hier konnte ich ein Fehler lokalisieren. Der Befehl: 'saslauth -v' gibt folgendes aus:
saslauthd 2.1.18 authentification mechanisms: getpwent kerberos5 pam rimap shadow
Also nix mit LDAP. Das dürfte wohl bedeuten ich mup den:
saslauthd -> pam -> pam_ldap -> ldap-server
Weg gehen, richtig? Warum jedoch im Yast/Syconfig LDAP als Auswahl angeboten wird ist mir dann nicht ganz klar. Somit habe ich als Einstellung 'pam' gewählt.
Yep. Hmm, keine Ahnung, warum Suse es in der Datei anbietet. Vielleicht, weil die Datei auch zu anderen Distributionen gehört und es dort einkompiliert ist.
Neben der o.g. Umgebungsvariabe finde ich kein Konfigurationsdatei für saslauthd. Wie gehe ich für die Einrichtung vor bzw. wie kann ich überprüfen ob er richtig funktioniert?
Wenn Du "saslauthd -a ldap" benutzen möchtest, müsste die Config bei Suse in / etc/saslauthd.conf zu finden sein. Habe aber hier kein Suse-SASL Paket mehr, der default bei Cyrus-SASL ist "/usr/local/etc/saslauthd.conf".
Ich habe nun die Datei: /etc/saslauthd.conf angelegt und dort eingetragen:
ldap_servers: ldap://testserver.kundennetz ldap_search_base: dc=kundennetz ldap_bind_dn: cn=root,dc=kundennetz ldap_bind_pw: {MD5}[MD5-Hash-Wert] ldap_auth_method: bin
Die brauchst Du nicht, wenn Du saslauthd nicht direkt mit ldap benutzt. Kannst Du also wieder löschen. Mal ganz abgesehen davon hätte ein verschlüsseltes Passwort hier eh nicht funktioniert.
Desweiteren habe ich eine Datei: /usr/lib/sasl2/slapd.conf mit dem Inhalt:
pwcheck_method: pam
Hmm, das ist für Cyrus-SASL-2 falsch. "pam" gibt es da nicht mehr. Die Datei kannst Du aber auch weglassen, die wird eh nicht gebraucht.
angelegt.
Hast Du denn sasl überhaupt konfiguriert in der slapd.conf?
Hier habe ich drin:
[...] TLSCertificateFile /etc/openldap/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ldapkey.pem TLSCertifikateFile /etc/openldap/demoCA/cacert.pem
Das ist tls, nicht sasl.
sasl-host testserver.kundennetz sasl-realm TESTSERVER [...]
Mus dieser sasl-realm vorher irgendwo definiert werden?
Das kannst Du auch weglassen, ich meinte so sachen wie sasl-regexp. Damit die Tools in der Datenbank überhaupt die Userdaten finden. Zeig doch mal grob, wie Deine Datenbank aussieht, wie z.B. sieht ein User-Objekt aus? -- Andreas
schrieb Andreas Winkelmann:
Am Samstag, 22. Mai 2004 15:58 schrieb Sven Gehr:
Desweiteren habe ich eine Datei: /usr/lib/sasl2/slapd.conf mit dem Inhalt:
pwcheck_method: pam
Hmm, das ist für Cyrus-SASL-2 falsch. "pam" gibt es da nicht mehr. Die Datei kannst Du aber auch weglassen, die wird eh nicht gebraucht.
ok, werde ich machen. So ganz klar ist es mir allerdings nicht. Gibt doch 'saslauth -v' pam als möglichen Mechanismus aus. Wieso meinst du dann es hier pam niht gäbe?
Hast Du denn sasl überhaupt konfiguriert in der slapd.conf?
Hier habe ich drin:
sasl-host testserver.kundennetz sasl-realm TESTSERVER [...]
Mus dieser sasl-realm vorher irgendwo definiert werden?
Das kannst Du auch weglassen, ich meinte so sachen wie sasl-regexp. Damit die Tools in der Datenbank überhaupt die Userdaten finden. Zeig doch mal grob, wie Deine Datenbank aussieht, wie z.B. sieht ein User-Objekt aus?
Nein, sont habe ich nichts in der slapd.conf drin. "sasl-regexp" ? Dieser Parameter ist mir neu. einfach so rein schreiben? Die Verzeichnis-Datenbank sieht so aus: dn: dc=kundennetz objectClass: top objectClass: organization objectClass: dcObject dc: kundennetz o: kundennetz # root, kundennetz dn: cn=root,dc=kundennetz objectClass: top objectClass: organizationalRole cn: root # sven, kundennetz dn: uid=sven,dc=kundennetz businessCategory: gruppe1 cn: Sven Gehr description: Der erste User displayName: sven gidNumber: 1000 givenName: Sven homeDirectory: /data/home/sven initials: sg loginShell: /bin/bash mail: sven.gehr@kundennetz.de o: sven objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson preferredLanguage: deutsch shadowInactive: -1 shadowLastChange: 12557 shadowMax: 99999 shadowMin: 1 shadowWarning: 14 sn: Gehr uid: sven uidNumber: 1002 userPassword:: e21kNX1KOERWZnAxSVlPRWJvWTNKaWcyVVdBPT0 Viele Grüße Sven
Am Samstag, 22. Mai 2004 17:41 schrieb Sven Gehr:
Desweiteren habe ich eine Datei: /usr/lib/sasl2/slapd.conf mit dem Inhalt:
pwcheck_method: pam
Hmm, das ist für Cyrus-SASL-2 falsch. "pam" gibt es da nicht mehr. Die Datei kannst Du aber auch weglassen, die wird eh nicht gebraucht.
ok, werde ich machen. So ganz klar ist es mir allerdings nicht. Gibt doch 'saslauth -v' pam als möglichen Mechanismus aus. Wieso meinst du dann es hier pam niht gäbe?
Es gibt einmal den saslauthd um Passwörter zu verifizieren und dann gibt es noch die auxprop-backends wie z.B. die sasldb. An dieser Stelle sagst Du sasl welche von diesen Möglichkeiten es benutzen soll, gültige Werte wären hier "saslauthd" oder "auxprop". Da pam jetzt vom saslauthd benutzt wird, steht das hier nicht mehr zur Verfügung. Früher, bevor es den saslauthd gab, gab es hier auch den Wert "pam".
Hast Du denn sasl überhaupt konfiguriert in der slapd.conf?
Hier habe ich drin:
sasl-host testserver.kundennetz sasl-realm TESTSERVER [...]
Mus dieser sasl-realm vorher irgendwo definiert werden?
Das kannst Du auch weglassen, ich meinte so sachen wie sasl-regexp. Damit die Tools in der Datenbank überhaupt die Userdaten finden. Zeig doch mal grob, wie Deine Datenbank aussieht, wie z.B. sieht ein User-Objekt aus?
Nein, sont habe ich nichts in der slapd.conf drin. "sasl-regexp" ? Dieser Parameter ist mir neu. einfach so rein schreiben?
Nein.
Die Verzeichnis-Datenbank sieht so aus:
dn: dc=kundennetz objectClass: top objectClass: organization objectClass: dcObject dc: kundennetz o: kundennetz
# root, kundennetz dn: cn=root,dc=kundennetz objectClass: top objectClass: organizationalRole cn: root
# sven, kundennetz dn: uid=sven,dc=kundennetz businessCategory: gruppe1 cn: Sven Gehr description: Der erste User displayName: sven gidNumber: 1000 givenName: Sven homeDirectory: /data/home/sven initials: sg loginShell: /bin/bash mail: sven.gehr@kundennetz.de o: sven objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson preferredLanguage: deutsch shadowInactive: -1 shadowLastChange: 12557 shadowMax: 99999 shadowMin: 1 shadowWarning: 14 sn: Gehr uid: sven uidNumber: 1002 userPassword:: e21kNX1KOERWZnAxSVlPRWJvWTNKaWcyVVdBPT0
sasl-regexp uid=(.*),cn=.*,cn=auth uid=$1,dc=kundennetz $ ldapwhoami -U sven Falls der aktuelle Benutzer nicht so heisst. Ich habe das noch nicht mit nem Verschlüsselten Passwort eingerichtet, hoffe mal das klappt. -- Andreas
Hallo zusammen, schrieb Andreas Winkelmann: schrieb Sven Gehr: mal ein generelle Frage zwischendurch. Mein Ziel ist und war die User-Authentifizierung gegen einen LDAP-Server zu realisieren. Der LDAP-Server soll die Passwörter als MD5-Hash speichern Das hat ja auch schon funktioniert. Allerding sah meine Eingabeaufforderung an der lokalen Maschiene so aus: I have no name!@testserver:~> Im Web habe ich einen Hinweis gefunden das würde daran liegen das ich kein SASL benutzen würde. Das, und NUR das war für mich der Grund überhaupt SASL ins Spiel zu bringen. Das von mir geplante Ziel war ganz einfach die an sich funktionierende LDAP-Installation abzusichern und diesen 'kosmetischen Fehler' zu beheben. Wenn ich eueren Ausführungen so folge drängt sich mir die Vermutung auf ich hätte SASL zumindest für LDAP nicht gebraucht, richtig? Wenn ich dann den Rechner sowit habe das ich mich sowohl lokal und per ssh anmelden kann und die Benutzer aus dem LDAP-Verzeichnis mit verschlüsseltem Passwort genommen werden und diese Kommunikation auch noch verschlüsselt ist wären die Dienste: - samba - cyrus-imap - postfix - squid hinzugekommen die die User ebenfalls nehmen sollen und auch möglicht sicher bertieben werden sollen. Nur nochmal damit ich nicht den Wald vor lauter Bäumen aus den Augen verlieren. Also benötige ich SASL für den geplanten Einsatzzweck? Viele Grüße Sven Gehr
Am Sonntag, 23. Mai 2004 13:09 schrieb Sven Gehr:
mal ein generelle Frage zwischendurch. Mein Ziel ist und war die User-Authentifizierung gegen einen LDAP-Server zu realisieren. Der LDAP-Server soll die Passwörter als MD5-Hash speichern
Das hat ja auch schon funktioniert. Allerding sah meine Eingabeaufforderung an der lokalen Maschiene so aus:
I have no name!@testserver:~>
Im Web habe ich einen Hinweis gefunden das würde daran liegen das ich kein SASL benutzen würde. Das, und NUR das war für mich der Grund überhaupt SASL ins Spiel zu bringen.
Hmm, die Bash kommt an Deine Userdaten nicht heran. Die Authentifizierung geht über PAM, die Bash greift jedoch über die glibc bzw. die libnss_ldap auf die Daten zu. Kontrollier mal Deine /etc/nsswitch.conf ob da bei passwd ldap steht. Prüfe mal ob die uid stimmt $ id Lass mal mit getent die passwd anzeigen, ob da die bzw. der User aus der LDAP-Datenbank bei sind: # getent passwd Kontrollier mal die /etc/ldap.conf bzw. /etc/ldap.secret (Das Passwort darf nicht verschlüsselt sein).
Das von mir geplante Ziel war ganz einfach die an sich funktionierende LDAP-Installation abzusichern und diesen 'kosmetischen Fehler' zu beheben.
Wenn ich eueren Ausführungen so folge drängt sich mir die Vermutung auf ich hätte SASL zumindest für LDAP nicht gebraucht, richtig?
Du musst Dich selbstverständlich beim LDAP-Server authentifizieren um Daten abzufragen. Bevor OpenLDAP SASL integriert hatte, wurden die Benutzer und Passwörter bei der Anmeldung unverschlüsselt übertragen, SSL bzw. TLS jetzt mal ausser acht gelassen. Mit SASL war es nun möglich auch Authentifizierungs-Mechanismen wie DIGEST-MD5 zu benutzen, dadurch wird kein Passwort mehr übertragen, nur noch ein Hash, welcher beidn Seiten mitteilt, dass die andere Seite das Passwort kennt. Vorraussetzung für diesen Mechanismus ist allerdings das unverschlüsselte Passwort in der Datenbank. Da dies bei Dir allerdings verschlüsselt ist, kannst Du diese Mechanismen auch nicht benutzen, stattdessen musst Du PLAIN bzw. LOGIN benutzen. Grob gesagt hebelst Du damit allerdings den Vorteil von SASL aus, und es ist bei Dir relativ egal ob Du es nun benutzt oder nicht. Seit einiger Zeit setzt OpenLDAP die Benutzung von SASL allerdings vorraus. Ssprich wenn Du SASL nicht mehr benutzen möchtest, musst Du in den Tools bzw. im Server wieder zurück auf bind_v2 bzw. Version 2 zurückschalten bzw. dieses Erlauben. Im Server (slapd.conf) gibt es die Option "allow bind_v2" in den Commandline-Tools ein "-x" in Konfigurationsdateinen meist "version 2" oder "ldap_version 2". Dieter möge mich korrigieren, wenn ich mich irre.
Wenn ich dann den Rechner sowit habe das ich mich sowohl lokal und per ssh anmelden kann und die Benutzer aus dem LDAP-Verzeichnis mit verschlüsseltem Passwort genommen werden und diese Kommunikation auch noch verschlüsselt ist wären die Dienste:
- samba - cyrus-imap - postfix - squid
hinzugekommen die die User ebenfalls nehmen sollen und auch möglicht sicher bertieben werden sollen. Nur nochmal damit ich nicht den Wald vor lauter Bäumen aus den Augen verlieren.
Also benötige ich SASL für den geplanten Einsatzzweck?
SASL brauchst Du auf jedenfall für Cyrus-Imap, allerdings nicht für die Verbindung zwischen saslauthd und der LDAP-Datenbank. SASL läuft da zwischen Client und IMAP-Server ab. -- Andreas
Andreas Winkelmann
Am Sonntag, 23. Mai 2004 13:09 schrieb Sven Gehr: [...] Seit einiger Zeit setzt OpenLDAP die Benutzung von SASL allerdings vorraus. Ssprich wenn Du SASL nicht mehr benutzen möchtest, musst Du in den Tools bzw. im Server wieder zurück auf bind_v2 bzw. Version 2 zurückschalten bzw. dieses Erlauben. Im Server (slapd.conf) gibt es die Option "allow bind_v2" in den Commandline-Tools ein "-x" in Konfigurationsdateinen meist "version 2" oder "ldap_version 2".
Dieter möge mich korrigieren, wenn ich mich irre.
Im Grunde ist das schon richtig, trotzdem noch ein paar Anmerkungen. Seit OpenLDAP LDAP v3 konform ist (OpenLDAP-2.0), wird für einen 'strong bind' libsasl und ein SASL Mechanismus benötigt, steht so in RFC 2251. Wenn kein strong bind durchgeführt wird, sondern nur ein simple bind, wird dies mit den Parametern -x und -D eingeleitet. Wenn du nur -x angibst, hat das nichts mit LDAP v2 zu tun, sondern ist nur ein anonymer bind, auch das ist LDAP v3 konform. Was aber nicht mehr geht, ist eine anonyme Suche ohne bind. Der Konfigurationsparameter "allow bind_v2" bezieht sich eher auf den Bind-Mechanismus der Clients. Ich möchte hier nicht BER diskutieren, in LDAP v2 wurde der ein Bind anders definiert als in LDAP v3, das hat aber nicht mit Authentifizierung zu tun. Wer sich dafür interessiert, möge man ldap_bind(3) lesen. Es gibt noch Clients die führen einen Bind nach LDAP v2 durch, dazu gehören Netscape- und Mozilla-Adressbuch. OpenLDAP kann einen Bind nach LDAP v2 nach außen simulieren, führt aber intern einen Bind v3 durch. Mit anderen Worten, wenn du zur Authentifizierung gegenüber slapd keinen strong bind benutzt, brauchst du auch kein SASL, kannst also OpenLDAP mit mit dem Parameter --disable-cyrus-sasl kompilieren, ohne das Protokoll zu verletzen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo,
Hmm, die Bash kommt an Deine Userdaten nicht heran. Die Authentifizierung geht über PAM, die Bash greift jedoch über die glibc bzw. die libnss_ldap auf die Daten zu. Kontrollier mal Deine /etc/nsswitch.conf ob da bei passwd ldap steht. Prüfe mal ob die uid stimmt
Habe ich schon, die stimmt.
$ id
Lass mal mit getent die passwd anzeigen, ob da die bzw. der User aus der LDAP-Datenbank bei sind:
# getent passwd
Habe ich auch schon gemacht. Hier bekomme ich den User 'sven' welcher ja gar nicht in der Datei passwd existiert angezeigt.
Kontrollier mal die /etc/ldap.conf bzw. /etc/ldap.secret (Das Passwort darf nicht verschlüsselt sein).
Ist drin & Klartext
Das von mir geplante Ziel war ganz einfach die an sich funktionierende LDAP-Installation abzusichern und diesen 'kosmetischen Fehler' zu beheben.
Wenn ich eueren Ausführungen so folge drängt sich mir die Vermutung auf ich hätte SASL zumindest für LDAP nicht gebraucht, richtig?
Du musst Dich selbstverständlich beim LDAP-Server authentifizieren um Daten abzufragen. Bevor OpenLDAP SASL integriert hatte, wurden die Benutzer und Passwörter bei der Anmeldung unverschlüsselt übertragen, SSL bzw. TLS jetzt mal ausser acht gelassen. Mit SASL war es nun möglich auch Authentifizierungs-Mechanismen wie DIGEST-MD5 zu benutzen, dadurch wird kein Passwort mehr übertragen, nur noch ein Hash, welcher beidn Seiten mitteilt, dass die andere Seite das Passwort kennt. Vorraussetzung für diesen Mechanismus ist allerdings das unverschlüsselte Passwort in der Datenbank. Da dies bei Dir allerdings verschlüsselt ist, kannst Du diese Mechanismen auch nicht benutzen, stattdessen musst Du PLAIN bzw. LOGIN benutzen. Grob gesagt hebelst Du damit allerdings den Vorteil von SASL aus, und es ist bei Dir relativ egal ob Du es nun benutzt oder nicht.
Seit einiger Zeit setzt OpenLDAP die Benutzung von SASL allerdings vorraus. Ssprich wenn Du SASL nicht mehr benutzen möchtest, musst Du in den Tools bzw. im Server wieder zurück auf bind_v2 bzw. Version 2 zurückschalten bzw. dieses Erlauben. Im Server (slapd.conf) gibt es die Option "allow bind_v2" in den Commandline-Tools ein "-x" in Konfigurationsdateinen meist "version 2" oder "ldap_version 2".
Das wäre aber doch keine sichere Lösung mehr, oder? Viele Grüße Sven Gehr
Hallo,
Sven Gehr
Hallo zusammen,
schrieb Andreas Winkelmann: schrieb Sven Gehr:
mal ein generelle Frage zwischendurch. Mein Ziel ist und war die User-Authentifizierung gegen einen LDAP-Server zu realisieren. Der LDAP-Server soll die Passwörter als MD5-Hash speichern
Das hat ja auch schon funktioniert. Allerding sah meine Eingabeaufforderung an der lokalen Maschiene so aus:
I have no name!@testserver:~>
Im Web habe ich einen Hinweis gefunden das würde daran liegen das ich kein SASL benutzen würde. Das, und NUR das war für mich der Grund überhaupt SASL ins Spiel zu bringen.
Das von mir geplante Ziel war ganz einfach die an sich funktionierende LDAP-Installation abzusichern und diesen 'kosmetischen Fehler' zu beheben.
Wenn ich eueren Ausführungen so folge drängt sich mir die Vermutung auf ich hätte SASL zumindest für LDAP nicht gebraucht, richtig?
Wenn ich dann den Rechner sowit habe das ich mich sowohl lokal und per ssh anmelden kann und die Benutzer aus dem LDAP-Verzeichnis mit verschlüsseltem Passwort genommen werden und diese Kommunikation auch noch verschlüsselt ist wären die Dienste:
- samba - cyrus-imap - postfix - squid
hinzugekommen die die User ebenfalls nehmen sollen und auch möglicht sicher bertieben werden sollen. Nur nochmal damit ich nicht den Wald vor lauter Bäumen aus den Augen verlieren.
Also benötige ich SASL für den geplanten Einsatzzweck?
Eine kurze Antwort und eine längere Erklärung :- Samba braucht kein SASL cyrus-imap sollte sasl einsetzen postfix sollte sasl einsetzen squid braucht kein SASL Jetzt in der gebotenen Kürze ein Beschreibung, was denn SASL überhaupt ist. SASL steht für 'Simple Authentication and Security Layer' und ist erst einmal eine API für die C Programmierung, die libsasl. Über diese API (Application Programming Interface) können Anwendungen die Anwender-Authentifizierung vornehmen. SASL wird definiert in der RFC 2222. Die in der RFC erwähnten SASL Mechanisms müssen von der IANA autorisiert werden. Das Paket Cyrus-SASL ist eine Opensource-Enwicklung der Carnegie Mellon University und stellt neben der API (libsasl) und den diversen Plugins (Mechanismen) noch zwei Authentifizierungs-Daemons, saslauthd und pwcheck, sowie eine Anwendung und zwei API's zur Speicherung der Anwender und Paßworte bereit. Die Anwendung ist sasldb, die API's sind auxprop für die Anbindung an SQL und ldapdb. Eine Besonderheit ist, daß sasldb nicht erstellt werden muß, wenn die Anwenderdaten in LDAP gespeichert werden, das bedarf auch keiner Konfiguration, allerdings muß OpenLDAP mit dem Parameter with-spasswd kompiliert werden. Eine Anwendung die mit libsasl kompiliert wurde, findet im Verzeichnis /usr/lib/sasl2/ eine eigene Konfigurationsdatei (Ausnahme cyrus-imap), für Postfix z.B. smtpd.conf, für Sendmail Sendmail.conf, für OpenLDAP slapd.conf. In dieser Konfigurationsdatei bestimmt der Administrator auf welche Weise der Anwender authentifiziert werden soll. Die Dokumentation zu Cyrus-SASL ist mehr als bescheiden, im Quellpaket sind die relevanten RFC's und IETF-Drafts enthalten, sowie sysadmin.html, programming.html, mechanisms.html und readme.html. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo, schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Andreas Winkelmann: schrieb Sven Gehr:
Also benötige ich SASL für den geplanten Einsatzzweck?
Eine kurze Antwort und eine längere Erklärung :- Samba braucht kein SASL cyrus-imap sollte sasl einsetzen postfix sollte sasl einsetzen squid braucht kein SASL
Also das bedeutet für mich ich brauche SASL
Das Paket Cyrus-SASL ist eine Opensource-Enwicklung der Carnegie Mellon University und stellt neben der API (libsasl) und den diversen Plugins (Mechanismen) noch zwei Authentifizierungs-Daemons, saslauthd und pwcheck,
Bei mir läuft saslauthd [...]
Eine Besonderheit ist, daß sasldb nicht erstellt werden muß, wenn die Anwenderdaten in LDAP gespeichert werden, das bedarf auch keiner Konfiguration, allerdings muß OpenLDAP mit dem Parameter with-spasswd kompiliert werden.
Wie kann ich feststellen ob das von mir verwendete RPM (von Suse-9.1) so gebaut wurde?
Eine Anwendung die mit libsasl kompiliert wurde, findet im Verzeichnis /usr/lib/sasl2/ eine eigene Konfigurationsdatei (Ausnahme cyrus-imap), für Postfix z.B. smtpd.conf, für Sendmail Sendmail.conf, für OpenLDAP slapd.conf. In dieser Konfigurationsdatei bestimmt der Administrator auf welche Weise der Anwender authentifiziert werden soll.
Bei meiner SuSE-Installation gibt es in diesem Pfad nur: - smtpd.conf der Rest sind .la & .so - Dateien.
Die Dokumentation zu Cyrus-SASL ist mehr als bescheiden, im Quellpaket sind die relevanten RFC's und IETF-Drafts enthalten, sowie sysadmin.html, programming.html, mechanisms.html und readme.html.
Ok, dann weiß ich zumindest schonmal was ich benötige. Da bleibt aber wieder mein Problem. Das ganze abzusichern. Viele Grüße Sven Gehr
Sven Gehr
Hallo,
schrieb Dieter Kluenter:
Sven Gehr
writes: [...] [...] Eine Besonderheit ist, daß sasldb nicht erstellt werden muß, wenn die Anwenderdaten in LDAP gespeichert werden, das bedarf auch keiner Konfiguration, allerdings muß OpenLDAP mit dem Parameter with-spasswd kompiliert werden. Wie kann ich feststellen ob das von mir verwendete RPM (von Suse-9.1) so gebaut wurde?
cd /etc mv sasldb2 sasldb2-bak 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. ,----[ ldapwhoami ] | dieter@marin, 507:~> ldapwhoami -Y digest-md5 | SASL/DIGEST-MD5 authentication started | Please enter your password: | SASL username: dieter | SASL SSF: 128 | SASL installing layers | dn:cn=dieter kluenter,ou=partner,o=avci,c=de `---- Wohlgemerkt, ich habe keine /etc/sasldb2.
Eine Anwendung die mit libsasl kompiliert wurde, findet im Verzeichnis /usr/lib/sasl2/ eine eigene Konfigurationsdatei (Ausnahme cyrus-imap), für Postfix z.B. smtpd.conf, für Sendmail Sendmail.conf, für OpenLDAP slapd.conf. In dieser Konfigurationsdatei bestimmt der Administrator auf welche Weise der Anwender authentifiziert werden soll.
Bei meiner SuSE-Installation gibt es in diesem Pfad nur: - smtpd.conf
Ja klar, du mußt schon für die jeweilige Anwendung eine eigene Konfiguration schreiben, es wird da kein Muster vorgegeben. [...]
Ok, dann weiß ich zumindest schonmal was ich benötige. Da bleibt aber wieder mein Problem. Das ganze abzusichern.
Was möchtest du denn absichern? Das habe ich noch nicht verstanden, oder ich bin zu spät in diesen Thread eingestiegen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo, 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 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.
Ok, dass bedeutet ich ändere zuerst zunächst in der /etc/openldap/slapd.conf die von Andreas genannte sasl-regexp wie folgt: sasl-regexp uid=(.*),cn=.*,cn=auth uid=$1,dc=kundennetz und rufe anschließend: ldapwhoami -H ldap://localhost -b "dc=kundennetz" -Y digest-md5 ein. Kann ich aber auch erst Morgen machen.
Wohlgemerkt, ich habe keine /etc/sasldb2.
Eine Anwendung die mit libsasl kompiliert wurde, findet im Verzeichnis /usr/lib/sasl2/ eine eigene Konfigurationsdatei (Ausnahme cyrus-imap), für Postfix z.B. smtpd.conf, für Sendmail Sendmail.conf, für OpenLDAP slapd.conf. In dieser Konfigurationsdatei bestimmt der Administrator auf welche Weise der Anwender authentifiziert werden soll.
Bei meiner SuSE-Installation gibt es in diesem Pfad nur: - smtpd.conf
Ja klar, du mußt schon für die jeweilige Anwendung eine eigene Konfiguration schreiben, es wird da kein Muster vorgegeben
Das hatte ich, wie weiter 'vorne' im Thread erkennabr auch schon gemacht. Hat jedoch nichts geändert. Versuch's aber gerne nochmal.
Ok, dann weiß ich zumindest schonmal was ich benötige. Da bleibt aber wieder mein Problem. Das ganze abzusichern.
Was möchtest du denn absichern? Das habe ich noch nicht verstanden, oder ich bin zu spät in diesen Thread eingestiegen.
Na LDAP und die Anmeldung am selbigen. Viele Grüße Sven
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" Außerdem, müßte es jetzt nicht " ... -H ldaps://..." lauten da ich ja den LDAP nun auf Port 636 betreibe?
sasl-regexp uid=(.*),cn=.*,cn=auth uid=$1,dc=kundennetz
Habe ich 1:1 so in meine slapd.conf übernommen.
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 Da ich nun schon einige geändert habe fasse ich das hier nochmal zusammen: ** /etc/openldap/slapd.conf ** include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/yast2userconfig.schema pidfile /var/run/slapd/run/slapd.pid argsfile /var/run/slapd/run/slapd.args schemacheck on 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 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 ####################################################################### # bdb database definitions ####################################################################### database bdb checkpoint 1024 5 cachesize 10000 suffix "dc=kundennetz" rootdn "cn=root,dc=kundennetz" rootpw {MD5}K2yw4b8r4T4Hsba9HbdhGw== directory /var/lib/ldap index objectClass eq index uid,cn,sn,displayname pres,eq,sub index memberUid,uidNumber,gidNumber eq index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index default sub lastmod on ** /etc/openldap/ldap.conf ** TLS_REQCERT allow host 192.168.1.1 base dc=kundennetz ** /etc/ldap.conf ** host 127.0.0.1 base dc=kundennetz ldap_version 3 pam_password crypt ssl no pam_filter objectclass=posixAccount nss_base_passwd dc=kundennetz nss_base_shadow dc=kundennetz nss_base_group dc=kundennetz Die Dateien: - /usr/lib/sasl2/slapd.conf - /etc/saslauthd.conf welche ich zuvor angelegt hatte, habe ich wider gelöscht. saslauthd ist gestartet. LDAP ist über sysconfig auf Port 636 konfiguriert und /etc/sysconfig/saslauthd_authmech=ldap konfiguriert. Im LDAP-Verzeichnis sieht es so aus: # kundennetz dn: dc=kundennetz objectClass: top objectClass: organization objectClass: dcObject dc: kundennetz o: kundennetz # root, kundennetz dn: cn=root,dc=kundennetz objectClass: top objectClass: organizationalRole cn: root # ldapconfig, kundennetz dn: ou=ldapconfig,dc=kundennetz objectClass: top objectClass: organizationalUnit ou: ldapconfig # group, ldapconfig, kundennetz dn: cn=group,ou=ldapconfig,dc=kundennetz cn: group objectClass: top objectClass: suseModuleConfiguration objectClass: suseGroupConfiguration suseDefaultBase: dc=kundennetz suseDefaultTemplate: cn=susegrouptemplate,ou=ldapconfig,dc=kundennetz suseMaxUniqueId: 60000 suseMinUniqueId: 1000 suseNextUniqueId: 1000 suseSearchFilter: objectclass=posixgroup # users, ldapconfig, kundennetz dn: cn=users,ou=ldapconfig,dc=kundennetz cn: users objectClass: top objectClass: suseModuleConfiguration objectClass: suseUserConfiguration suseDefaultBase: dc=kundennetz suseDefaultTemplate: cn=suseusertemplate,ou=ldapconfig,dc=kundennetz suseMaxPasswordLength: 8 suseMaxUniqueId: 60000 suseMinPasswordLength: 5 suseMinUniqueId: 1000 suseNextUniqueId: 1002 susePasswordHash: MD5 suseSearchFilter: objectclass=posixaccount suseSkelDir: /etc/skel # susegrouptemplate, ldapconfig, kundennetz dn: cn=susegrouptemplate,ou=ldapconfig,dc=kundennetz cn: susegrouptemplate objectClass: top objectClass: suseObjectTemplate objectClass: suseGroupTemplate suseNamingAttribute: cn susePlugin: UsersPluginLDAPAll # suseusertemplate, ldapconfig, kundennetz dn: cn=suseusertemplate,ou=ldapconfig,dc=kundennetz cn: suseusertemplate objectClass: top objectClass: suseObjectTemplate objectClass: suseUserTemplate suseDefaultValue: homedirectory=/data/home/%uid suseDefaultValue: loginshell=/bin/bash suseDefaultValue: objectClass=person suseNamingAttribute: uid susePlugin: UsersPluginLDAPAll # grp1, kundennetz dn: cn=grp1,dc=kundennetz cn: grp1 description: unsere erste Gruppe gidNumber: 1000 memberUid: 1000 objectClass: top objectClass: namedObject objectClass: posixGroup # sven, kundennetz dn: uid=sven,dc=kundennetz cn: Sven Gehr description: erster USer displayName: sven gidNumber: 1000 givenName: Sven homeDirectory: /data/home/sven initials: sg l: sven loginShell: /bin/bash mail: sven@kundennetz o: sven objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson ou: sven preferredLanguage: deutsch shadowInactive: -1 shadowLastChange: 12557 shadowMax: 99999 shadowMin: 1 shadowWarning: 14 sn: Gehr street:: VGVzdHN0cmHDn2U= uid: sven uidNumber: 1002 userPassword:: e21kNX1KOERWZnAxSVlPRWJvWTNKaWcyVVdBPT0= # search result search: 2 result: 0 Success # numResponses: 10 # numEntries: 9 Ich weiß, ist ein bischen viel aber irgendow muß doch der Fehler liegen. Viele Grüße Sven
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
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
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
Hallo, schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Dieter Kluenter:
Sven Gehr
writes:
eines vorweg:
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
So ich entscheide mich jetz einfach für die Variante TLS also Port 389. Demzufolge muß ich jedoch wieder folgendes ändern: ***/etc/sysconfig*** von: SASL_AUTHMECH = ldap ändern auf: SASL_AUTHMECH = pam von: OPENLDAP_START_LDAPS = yes ändern auf: OPENLDAP_START_LDAPS = no In der Sysconfig gibt es derzeit folgende LDAP-relevanten Werte: BASE_CONFIG_DN = ou=ldapconfig,dc=kundennetz BIND_DN = cn=root,dc=kundennetz FILE_SERVER = yes OPENLDAP_START_LDAPS = no OPENLDAP_START_LDAPI = no OPENLDAP_SLAPD_PARAMS = OPENLDAP_USERS = ldap OPENLDAP_GROUP = ldap OPENLDAP_CHOWN_DIRS = yes OPENLDAP_RUN_DB_RECOVER = no OPENLDAP_LDAP_INTERFACES = OPENLDAP_LDAPs_INTERFACES = sind die alle so ok? *** /etc/saslauthd.conf ** von: ldap_servers: ldaps://testserver.kundennetz ldap_search_base: dc=kundennetz ändern auf: ldap_servers: ldap://testserver.kundennetz ldap_search_base: dc=kundennetz *** /etc/ldap.conf *** von: host 127.0.0.1 base dc=kundennetz ldap_version 3 pam_password md5 pam_filter objectclass=posixAccount nss_base_passwd dc=kundennetz nss_base_shadow dc=kundennetz nss_base_group dc=kundennetz ssl on ändern auf: host 127.0.0.1 base dc=kundennetz ldap_version 3 pam_password md5 pam_filter objectclass=posixAccount nss_base_passwd dc=kundennetz nss_base_shadow dc=kundennetz nss_base_group dc=kundennetz ssl start_tls In dieser Vorlagen-Datei gibt es noch jede Menge PAM- und NSS- Optionen. Sind die, die ich in meiner Config drin habe ausreichend bzw richtig? Desweiteren gibt es in dieser Datei noch folgende, auskommentierte TLS-Optionen: #tls_checkpeer yes #tls_cacertfile /etc/ssl/ca.cert #tls_cacertdir /etc/ssl/certs #tls_ciphers TLSv1 #tls_cert #tls_key Ist noch einer von diesen Parameter notwendig? Ich hoffe das wir hierdurch einen halbwegs einen definierten Zustand *hoff*
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"
Also das bleibt mir irgendwie verwehrt was dieser String macht. Ich habe bisher an dem Testsystem nur root und einen Testuser (sven). Alle Tests, von den wir die ganze Zeit reden, mache ich lokal an diesem Rechner als root. Warum soll ein SASL Realm wie in diesem Beispiel einen User enthalt (hier uid=dieter). Das fehlt mir das Verstännis für.
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.
Wie gesagt, ich mache alles im Moment lokal an dem Rechner.
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 warum nicht?
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
ok, aber was bedeutet das jetzt für mich? Ist die von mir angedachte Vorgehensweis so nicht möglich?
saslauthd ist gestartet. LDAP ist über sysconfig auf Port 636 konfiguriert und /etc/sysconfig/saslauthd_authmech=ldap konfiguriert.
ok, das ist ja wie ganz oben beschrieben (sysconfig) wieder auf pam umgestellt. Viele Grüße Sven
Sven Gehr
Hallo,
schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Dieter Kluenter:
Sven Gehr
writes:
So ich entscheide mich jetz einfach für die Variante TLS also Port 389. Demzufolge muß ich jedoch wieder folgendes ändern:
OK, gut.
***/etc/sysconfig***
von: SASL_AUTHMECH = ldap
ändern auf: SASL_AUTHMECH = pam
von: OPENLDAP_START_LDAPS = yes
ändern auf: OPENLDAP_START_LDAPS = no
In der Sysconfig gibt es derzeit folgende LDAP-relevanten Werte:
BASE_CONFIG_DN = ou=ldapconfig,dc=kundennetz BIND_DN = cn=root,dc=kundennetz FILE_SERVER = yes OPENLDAP_START_LDAPS = no OPENLDAP_START_LDAPI = no OPENLDAP_SLAPD_PARAMS = OPENLDAP_USERS = ldap OPENLDAP_GROUP = ldap OPENLDAP_CHOWN_DIRS = yes OPENLDAP_RUN_DB_RECOVER = no OPENLDAP_LDAP_INTERFACES = OPENLDAP_LDAPs_INTERFACES =
sind die alle so ok?
Ja, sieht so aus, ich kann da nicht gravierendes entdecken, bis auf den Parameter BIND_DN = cn=root,dc=kundennetz. Das kann man so machen, denn root ist im Sinne des LDAP-Servers nur ein einfacher User ohne Sonderrechte, aber da du in slapd.conf rootdn cn=root,dc=kundennetz definiert hast, würde ich das nicht machen.BIND_DN muß nur in der Lage sein, Attribute auszulesen und Authentifizierungen durchzuführen, da sind keine besonderen Privilegien notwendig. Ich würde aber eher rootdn anders definieren, einfach einen virtuellen Namen nehmen der im sonstigen System keine Rechte besitzt.
*** /etc/saslauthd.conf **
von: ldap_servers: ldaps://testserver.kundennetz ldap_search_base: dc=kundennetz
ändern auf: ldap_servers: ldap://testserver.kundennetz ldap_search_base: dc=kundennetz
*** /etc/ldap.conf ***
[...]
ändern auf: host 127.0.0.1 base dc=kundennetz ldap_version 3 pam_password md5 pam_filter objectclass=posixAccount nss_base_passwd dc=kundennetz nss_base_shadow dc=kundennetz nss_base_group dc=kundennetz ssl start_tls
In dieser Vorlagen-Datei gibt es noch jede Menge PAM- und NSS- Optionen. Sind die, die ich in meiner Config drin habe ausreichend bzw richtig?
Das ist OK, ich habe in meiner Konfiguration einen kleinen Unterschied, der aber keine Bedeutung für die prinzipielle Funktion hat, statt des Parameters host habe uri und dann noch drei zusätzliche Parameter uri ldap://127.0.0.1 scope sub pam_password exop tls_cacertfile /etc/certs/cacert.pem Wenn du TLS nutzt, muß da aber der volle Hostname stehen. Mit dieser Konfiguration bindet PAM sich anonym, das ist OK da nur Passworte geprüft werden. Wenn du aber später stengere Access Regeln einführst, solltest du einen 'binddn' definieren. [...]
Ich hoffe das wir hierdurch einen halbwegs einen definierten Zustand *hoff*
Das sollte jetzt machbar sein. [...]
Also das bleibt mir irgendwie verwehrt was dieser String macht. Ich habe bisher an dem Testsystem nur root und einen Testuser (sven). Alle Tests, von den wir die ganze Zeit reden, mache ich lokal an diesem Rechner als root. Warum soll ein SASL Realm wie in diesem Beispiel einen User enthalt (hier uid=dieter). Das fehlt mir das Verstännis für.
Ist für dich auch nicht so wichtig, da du keinen strong bind durchführenmöchtest. {...]
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)
und noch einmal
Und warum nicht?
,----[ root Eintrag ] | dn: cn=root,dc=kundennetz | objectClass: top | objectClass: organizationalRole | cn: root `---- Weil cn=root,dc=kundennetz nicht der Objektklasse Posixaccount angehört und nicht die gesuchten Attribute hat, übrigens auch kein Paßwort für einen bind.
da fehlt einiges, z.b. der folgende Auszug
supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN
ok, aber was bedeutet das jetzt für mich? Ist die von mir angedachte Vorgehensweis so nicht möglich?
Das Fehlen ist für dich zur Zeit noch ohne Bedeutung, [...] -Dieter -- Dieter Klünter | Systemberatung Tel.: +49.40.64861967 Fax : +49.40.64891521 http://www.avci.de
Hallo, um ganz sicher zu gehen das ich keine Konfigurations-Überreste an dem entsprechenden Rechner habe, habe ich alles nochmal von vorne gemacht. Um mir die Einrichtung von DNS & DHCP zu sparen habe ich in einfach hier ins Netz genommen. Der volle Name lautet testserver.komet.net IP = 192.168.111.93 Der Name, die IP ist sowohl vorwärts wie auch rückwärts auflösbar, sprich der DNS funktioniert problemlos. schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Dieter Kluenter:
Sven Gehr
writes:
***/etc/sysconfig*** SASL_AUTHMECH = pam
auch wieder so
*** /etc/saslauthd.conf **
ldap_servers: ldap://testserver.kundennetz ldap_search_base: dc=kundennetz
sinngemäß auf: ldap_servers: ldap://testserver.komet.net ldap_search_base: dc=komet,dc=net
*** /etc/ldap.conf ***
ändern auf: host 127.0.0.1 base dc=kundennetz ldap_version 3 pam_password md5 pam_filter objectclass=posixAccount nss_base_passwd dc=kundennetz nss_base_shadow dc=kundennetz nss_base_group dc=kundennetz ssl start_tls
host testserver.komet.net base dc=komet,dc=net ldap_version 3 pam_password md5 pam_filter objectclass=posixAccount nss_base_passwd dc=komet,dc=net nss_base_shadow dc=komet,dc=net nss_base_group dc=komet,dc=net ssl start_tls tls_cacertfile /Pfad/zu/meinem/Zertifikat ImVerzeichnisdienst habe ich unter anderem folgende Objekte: # komet.net dn: dc=komet,dc=net objectClass: top objectClass: organization objectClass: dcObject dc: komet o: komet.net # root, komet.net dn: cn=root,dc=komet,dc=net cn: root description: gott gidNumber: 0 homeDirectory: /root loginShell: /bin/bash objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: organizationalRole uid: root uidNumber: 0 userPassword:: e01ENX1LMnl3NGI4cjRUNEhzYmE5SGJkaEd3PT0= # sven, komet.net dn: uid=sven,dc=komet,dc=net businessCategory: test cn: Sven Gehr description: erster User displayName: sven gecos: Sven Gehr gidNumber: 1000 givenName: Sven homeDirectory: /data/home/sven initials: sg loginShell: /bin/bash o: sven objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson ou: testgru preferredLanguage: deutsch shadowInactive: -1 shadowLastChange: 12563 shadowMax: 99999 shadowMin: 1 shadowWarning: 14 sn: Gehr uid: sven uidNumber: 1000 userPassword:: e21kNX1KOERWZnAxSVlPRWJvWTNKaWcyVVdBPT0= Was mir hier auffällt ist das vor den Passwörtren kein {MD5} steht. Außerdem habe ich aus root mal einen PosixAccount gemacht. Aber das anmelden an der lokalen Maschiene funktioniert leider noch immer nicht. Im Logfile sieht es folgendermaßen aus: slapd[1748]: conn=38 fd=28 ACCEPT from IP=127.0.0.2:32812 (IP=0.0.0.0:389) slapd[1748]: conn=38 op=0 BIND dn="cn=root,dc=komet,dc=net" method=128 slapd[1748]: conn=38 op=0 BIND dn="cn=root,dc=komet,dc=net" mech=SIMPLE ssf=0 slapd[1748]: conn=38 op=0 RESULT tag=97 err=0 text= slapd[1748]: conn=38 op=1 SRCH base="dc=komet,dc=net" scope=2 deref=0 filter="(&(objectClass=pos$ slapd[1748]: conn=38 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginS$ slapd[1748]: conn=38 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[1748]: conn=38 op=2 SRCH base="dc=komet,dc=net" scope=2 deref=0 filter="(&(objectClass=pos$ slapd[1748]: conn=38 op=2 SRCH attr=cn userPassword memberUid uniqueMember gidNumber slapd[1748]: <= bdb_equality_candidates: (uniqueMember) index_param failed (18) slapd[1748]: conn=38 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= slapd[1748]: conn=38 fd=28 closed slapd[1748]: conn=39 fd=28 ACCEPT from IP=127.0.0.2:32813 (IP=0.0.0.0:389) slapd[1748]: conn=39 op=0 BIND dn="cn=root,dc=komet,dc=net" method=128 slapd[1748]: conn=39 op=0 BIND dn="cn=root,dc=komet,dc=net" mech=SIMPLE ssf=0 slapd[1748]: conn=39 op=0 RESULT tag=97 err=0 text= slapd[1748]: conn=39 op=1 SRCH base="dc=komet,dc=net" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=sven))" slapd[1748]: conn=39 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[1748]: conn=39 op=2 BIND anonymous mech=implicit ssf=0 slapd[1748]: conn=39 op=2 BIND dn="uid=sven,dc=komet,dc=net" method=128 slapd[1748]: conn=39 op=2 RESULT tag=97 err=50 text= login[2991]: pam_ldap: error trying to bind as user "uid=sven,dc=komet,dc=net" (Insufficient acc$ slapd[1748]: conn=39 op=3 BIND dn="cn=root,dc=komet,dc=net" method=128 slapd[1748]: conn=39 op=3 BIND dn="cn=root,dc=komet,dc=net" mech=SIMPLE ssf=0 slapd[1748]: conn=39 op=3 RESULT tag=97 err=0 text= slapd[1748]: conn=40 fd=29 ACCEPT from IP=127.0.0.2:32814 (IP=0.0.0.0:389) slapd[1748]: conn=40 op=0 BIND dn="cn=root,dc=komet,dc=net" method=128 slapd[1748]: conn=40 op=0 BIND dn="cn=root,dc=komet,dc=net" mech=SIMPLE ssf=0 slapd[1748]: conn=40 op=0 RESULT tag=97 err=0 text= slapd[1748]: conn=40 op=1 SRCH base="dc=komet,dc=net" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=sven))" Viele Grüße Sven
Sven Gehr
Hallo,
um ganz sicher zu gehen das ich keine Konfigurations-Überreste an dem entsprechenden Rechner habe, habe ich alles nochmal von vorne gemacht. Um mir die Einrichtung von DNS & DHCP zu sparen habe ich in einfach hier ins Netz genommen.
Der volle Name lautet testserver.komet.net IP = 192.168.111.93
slapd[1748]: conn=39 op=1 SRCH base="dc=komet,dc=net" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=sven))"
slapd[1748]: conn=39 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[1748]: conn=39 op=2 BIND anonymous mech=implicit ssf=0 slapd[1748]: conn=39 op=2 BIND dn="uid=sven,dc=komet,dc=net" method=128 slapd[1748]: conn=39 op=2 RESULT tag=97 err=50 text= login[2991]: pam_ldap: error trying to bind as user "uid=sven,dc=komet,dc=net" (Insufficient acc$ [...]
PAM versucht mit deiner Identität deinen Eintrag zu lesen, hat aber keine Berechtigung. Kontrolliere mal /etc/ldap.conf deine access Regeln in slapd.conf. Um dir bei der Formulierung der richtigen Regeln zu helfen, müßte ich jetzt die installierte OpenLDAP Version wissen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo, schrieb Dieter Kluenter:
Sven Gehr
writes: Hallo,
slapd[1748]: conn=39 op=1 SRCH base="dc=komet,dc=net" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=sven))"
slapd[1748]: conn=39 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[1748]: conn=39 op=2 BIND anonymous mech=implicit ssf=0 slapd[1748]: conn=39 op=2 BIND dn="uid=sven,dc=komet,dc=net" method=128 slapd[1748]: conn=39 op=2 RESULT tag=97 err=50 text= login[2991]: pam_ldap: error trying to bind as user "uid=sven,dc=komet,dc=net" (Insufficient acc$
PAM versucht mit deiner Identität deinen Eintrag zu lesen, hat aber keine Berechtigung. Kontrolliere mal /etc/ldap.conf deine access Regeln in slapd.conf.
an meiner /etc/ldap.conf hat sich nichts geändert: host testserver.komet.net base dc=komet,dc=net ldap_version 3 rootbinddn cn=root,dc=komet,dc=net scope sub pam_filter objectclass=posixaccount pam_password md5 ssl start_tls pam_filter objectclass=posixAccount nss_base_passwd dc=komet,dc=net nss_base_shadow dc=komet,dc=net nss_base_group dc=komet,dc=net tls_cacertfile /usr/share/ssl/misc/demoCA/cacert.pem tls_cacertdir /usr/share/ssl/misc/ Die access - Regen in der slapd.conf haben sich auch nicht geändert access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write # by users read by * read by anonymous auth
Um dir bei der Formulierung der richtigen Regeln zu helfen, müßte ich jetzt die installierte OpenLDAP Version wissen.
Ich benutze der Version 2.2.6 Viele Grüße Sven
Hallo, noch ein unterschied ist mir aufgefallen. Wenn ich (als root angemeldet) 'ldapwhami' aufrufe erhalte ich die Meldung: ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (open(/tmp/krb5cc_0): No such file or directory) evtl. bringt das was? Am Dienstag, 25. Mai 2004 16:27 schrieb Sven Gehr:
Hallo,
schrieb Dieter Kluenter:
Sven Gehr
writes: Hallo,
slapd[1748]: conn=39 op=1 SRCH base="dc=komet,dc=net" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=sven))"
slapd[1748]: conn=39 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[1748]: conn=39 op=2 BIND anonymous mech=implicit ssf=0 slapd[1748]: conn=39 op=2 BIND dn="uid=sven,dc=komet,dc=net" method=128 slapd[1748]: conn=39 op=2 RESULT tag=97 err=50 text= login[2991]: pam_ldap: error trying to bind as user "uid=sven,dc=komet,dc=net" (Insufficient acc$
PAM versucht mit deiner Identität deinen Eintrag zu lesen, hat aber keine Berechtigung. Kontrolliere mal /etc/ldap.conf deine access Regeln in slapd.conf.
an meiner /etc/ldap.conf hat sich nichts geändert:
host testserver.komet.net base dc=komet,dc=net ldap_version 3 rootbinddn cn=root,dc=komet,dc=net scope sub pam_filter objectclass=posixaccount pam_password md5 ssl start_tls pam_filter objectclass=posixAccount nss_base_passwd dc=komet,dc=net nss_base_shadow dc=komet,dc=net nss_base_group dc=komet,dc=net tls_cacertfile /usr/share/ssl/misc/demoCA/cacert.pem tls_cacertdir /usr/share/ssl/misc/
Die access - Regen in der slapd.conf haben sich auch nicht geändert
access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write # by users read by * read by anonymous auth
Um dir bei der Formulierung der richtigen Regeln zu helfen, müßte ich jetzt die installierte OpenLDAP Version wissen.
Ich benutze der Version 2.2.6
Viele Grüße Sven
Sven Gehr
Hallo,
noch ein unterschied ist mir aufgefallen. Wenn ich (als root angemeldet) 'ldapwhami' aufrufe erhalte ich die Meldung:
ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (open(/tmp/krb5cc_0): No such file or directory)
evtl. bringt das was?
Ja, als root hast du vielleicht nicht den Schalter -Y digest-md5 hinzugefügt. Du hast eine mit Heimdal kompilierte libgssapi im System und wenn kein Mechanismus angegeben wird, wird als Default GSSAPI genutzt. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo, schrieb Dieter Kluenter:
Sven Gehr
writes:
noch ein unterschied ist mir aufgefallen. Wenn ich (als root angemeldet) 'ldapwhami' aufrufe erhalte ich die Meldung:
ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (open(/tmp/krb5cc_0): No such file or directory)
evtl. bringt das was?
Ja, als root hast du vielleicht nicht den Schalter -Y digest-md5 hinzugefügt. Du hast eine mit Heimdal kompilierte libgssapi im System und wenn kein Mechanismus angegeben wird, wird als Default GSSAPI genutzt.
Ich habe das Paket 'cyrus-sasl-gssapi' einfach deinstalliert und dann kam diese Meldung nicht mehr, allerdings eine andere (siehe Mail von eben) Viele Grüße Sven Gehr
Sven Gehr
Hallo,
schrieb Dieter Kluenter:
Sven Gehr
writes: Hallo,
[...]
Die access - Regen in der slapd.conf haben sich auch nicht geändert
access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write # by users read by * read by anonymous auth
Um dir bei der Formulierung der richtigen Regeln zu helfen, müßte ich jetzt die installierte OpenLDAP Version wissen.
Ich benutze der Version 2.2.6
Das habe ich fast erwartet :-) In OpenLDAP-2.2 ist die Syntax der access Regeln geändert worden, wenn du dazu mehr wissen möchtest, man slapd.access(5). access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword by self write by anonymous auth access to dn.subtree=dc=komet,dc=net by users write by * read Das sind sehr offene Regeln, wenn alles läuft, solltest du die Regeln eingrenzen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo, Am Dienstag, 25. Mai 2004 18:00 schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Dieter Kluenter:
Sven Gehr
writes:
zunächst einmal eine gute Naricht. Ich kann mich mit dem User 'sven' an der lokalen Maschiene anmelden UND! bekomme auch die richtige Eingabeaufforderung: sven@testserver:~> gezeicht. Das sieht ja schonmal ganz gut aus. Das einzigste wo ein Fehler kommt ist wenn ich dann 'ldapwhoami' eingebe: sven@testserver:~> ldapwhoami SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database Hier scheint es noch ein Problem zu geben. [...]
In OpenLDAP-2.2 ist die Syntax der access Regeln geändert worden, wenn du dazu mehr wissen möchtest, man slapd.access(5).
access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword by self write by anonymous auth access to dn.subtree=dc=komet,dc=net by users write by * read
Das sind sehr offene Regeln, wenn alles läuft, solltest du die Regeln eingrenzen.
Wie müßte ich jetzt vorgehen um die Sache etwas sicherer zu machen? Käme jetzt der binddn ins Spiel? Viele Grüße Sven
Sven Gehr
Hallo,
Am Dienstag, 25. Mai 2004 18:00 schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Dieter Kluenter:
Sven Gehr
writes: zunächst einmal eine gute Naricht. Ich kann mich mit dem User 'sven' an der lokalen Maschiene anmelden UND! bekomme auch die richtige Eingabeaufforderung:
sven@testserver:~>
gezeicht. Das sieht ja schonmal ganz gut aus.
Dazu erst einmal meinen Glückwunsch.
Das einzigste wo ein Fehler kommt ist wenn ich dann 'ldapwhoami' eingebe:
sven@testserver:~> ldapwhoami SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database
Hier scheint es noch ein Problem zu geben.
gibt es denn jetzt 'supportedSASLMechanisms? Wenn diese angeboten werden,stimmt sasl-regexp nicht. In der Logdatei localmessages sollten Hinweise zu finden sein.
[...]
Das sind sehr offene Regeln, wenn alles läuft, solltest du die Regeln eingrenzen.
Wie müßte ich jetzt vorgehen um die Sache etwas sicherer zu machen? Käme jetzt der binddn ins Spiel?
binddn ist die eine Seite, die andere betrifft dedizierte access Regeln für die einzelnen Subtrees und Einträge. Ich denke, das dies aber später gemacht werden sollte, wenn du LDAP besser verstehst und auch genügend Einträge vorhanden sind. Um während der Laufzeit etwas mehr Informationen über den Server zu bekommen würde ich noch eine 'database monitor' einrichten.(Seite 103 in dem weltbekannten Fachbuch). Möglicherweise wird back-monitor von SuSE als Modul bereitgestellt, das solltest du prüfen und gegebenenfalls den Modulpfad noch in slapd.conf definieren. Auslesen kannst du Monitor mit ldapsearch -b "cn=monitor" -s sub + -x Die wichtigen Attribute sind als operationale Attribute definiert, diese werden durch das Pluszeichen (+) ausgelesen. -Dieter -- Dieter Klünter | Systemberatung Tel.: +49.40.64861967 Fax : +49.40.64891521 http://www.avci.de
Hallo, schrieb Dieter Kluenter:
Sven Gehr
writes: Am Dienstag, 25. Mai 2004 18:00 schrieb Dieter Kluenter:
Sven Gehr
writes: schrieb Dieter Kluenter:
Sven Gehr
writes:
so war leider Gestern den ganzen Tag bei Kunden sodas ich er heute an meinem Lebenswerk weiter machen kann ;-) Noch was anderes. Wann kommt das Buch über Autorifizierungen etc. raus? Gibt es schon ein Beschreibung welche Rückschlüsse auf den Inhalt zulassen?
Das einzigste wo ein Fehler kommt ist wenn ich dann 'ldapwhoami' eingebe: sven@testserver:~> ldapwhoami SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database Hier scheint es noch ein Problem zu geben.
gibt es denn jetzt 'supportedSASLMechanisms?
wenn ich eingebe: ldapsearch -h localhost -x -D "cn=root,dc=komet,dc=net" -b "" -s base \ supportedSASLMechanisms erhalte ich: ldap_bind: Server is unwilling to perform (53) additional info: unauthnticate bind (DN with no password) disallowed lasse ich das -x weg, also: ldapsearch -h localhost -D "cn=root,dc=komet,dc=net" -b "" -s base \ supportedSASLMechanisms erhalte ich: SASL/DIGEST-MD5 authentication started: Please enter yout password: und nach eingabe des Passwortes erhalt ich: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database
Wenn diese angeboten werden,stimmt sasl-regexp nicht. In der Logdatei localmessages sollten Hinweise zu finden sein.
In der /etc/openldap/slapd.conf hae ich ja nach wie vor: sasl-regexp uid=(.*),cn=.*,cn=auth uid=$1,dc=komet,dc=kundennetz Im Logfile finde ich zu dem Thema: slapd[1834]: conn=9 op=1 BIND dn="" method=128 slapd[1834]: conn=9 op=1 RESULT tag=97 err=0 text= slapd[1834]: conn=9 op=2 SRCH base="dc=komet,dc=net" scope=2 deref=0 filter="(&(objectClass=posi$ slapd[1834]: conn=9 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginSh$ slapd[1834]: conn=9 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[1834]: conn=9 op=3 SRCH base="dc=komet,dc=net" scope=2 deref=0 filter="(&(objectClass=posi$ slapd[1834]: conn=9 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber slapd[1834]: conn=9 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[1834]: conn=9 fd=21 closed slapd[1834]: conn=10 fd=21 ACCEPT from IP=127.0.0.2:32790 (IP=0.0.0.0:389) slapd[1834]: conn=10 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" slapd[1834]: conn=10 op=0 SRCH attr=supportedSASLMechanisms slapd[1834]: conn=10 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[1834]: conn=10 op=1 BIND dn="" method=163 ldapwhoami: DIGEST-MD5 client step 2 ldapwhoami: DIGEST-MD5 client step 2 slapd[1834]: conn=10 op=2 BIND dn="" method=163 slapd[1834]: SASL [conn=10] Error: unable to open Berkeley db /etc/sasldb2: No such file or dire$ last message repeated 2 times slapd[1834]: SASL [conn=10] Failure: no secret in database slapd[1834]: conn=10 op=2 RESULT tag=97 err=80 text=SASL(-13): user not found: no secret in data$ slapd[1834]: conn=10 fd=21 closed Fehlt evtl. in der /etc/salauthd.conf noch was ? Hier habe ich: ldap_servers: ldap://testserver.komet.net ldap_search_base: dc=komet,dc=net
binddn ist die eine Seite, die andere betrifft dedizierte access Regeln für die einzelnen Subtrees und Einträge. Ich denke, das dies aber später gemacht werden sollte, wenn du LDAP besser verstehst und auch genügend Einträge vorhanden sind.
ok. Dann werde ich daran gehen wenn alles funktionell eingerichtet ist,
Um während der Laufzeit etwas mehr Informationen über den Server zu bekommen würde ich noch eine 'database monitor' einrichten.(Seite 103 in dem weltbekannten Fachbuch). Möglicherweise wird back-monitor von SuSE als Modul bereitgestellt, das solltest du prüfen und gegebenenfalls den Modulpfad noch in slapd.conf definieren. Auslesen kannst du Monitor mit ldapsearch -b "cn=monitor" -s sub + -x
ok, das werde ich versuchen. Viele Grüße Sven Gehr
Sven Gehr
Hallo zusammen,
schrieb Andreas Winkelmann:
schrieb Sven Gehr:
Die SASL-Library regelt die Übertragung und den Handshake bei den verschiedenen Protokollen, wie z.B. SMTP, POP3, IMAP. Der Vollständigkeit halber bringt diese auch den Zugriff auf die Userdaten (z.B. Name und Passwort) mit. Und hierfür ist dann PAM eine Alternative. Du kannst also durchaus SASL und PAM verwenden. In aktuellen SASL-Versionen kommt dann da der saslauthd ins Spiel.
Das bedeutet ich kann meine User/Passwort - Kombinationen im LDAP-Verzeichnis haben, was ja auch bereits der Fall ist. Diese sind hier als MD5-Hashwert gespeichert. Als 'Login-Mechanismus' benutze ich wie ebenfalls breits eingerichtet PAM und SASL regelt nur den eigentlichen Verbindungsaufbau.
Wenn du SASL Mechanismen nutzt und du die Anwender in einem Verzeichnisdienst speicherst, MUSS das Passwort im LDAP-Server als PLAINTEXT enthhalten sein, nicth mit irgendeinr Verschlüselung.
Hierzu läuft der Dienst saslauth. Dieser läßt sich über den Sysconfig (Yast) auf verschiedene Werte einstellen:
Option: SASL_AUTHMECH Mögliche Werte: ldap, getpwent, kerberos, pam rimap, shadow
Hier ist mir nicht klar ob ich ldap oder pam einstellen muß. Dies wäre mir klar wenn ich wüßte wie sasl beim Loginspiel mit den anderen Komponenten zusammenspielt.
Wenn die Anwender mit 'uid' und password im Verzeichnisdienst enthalten sind, mußt du saslauthd mit -a ldap starten. Zur entsprechenden Konfiguration siehe die Doku zu cyrus-sasl.
Loginversuch -> PAM -> SLAS-Aufruf um Verbinungsaufbau zu verschlüsseln -> LDAP
Dann wäre sicher SASL_AUTHMECH=pam die richtige Einstellung
SASL kennt keinen Mechanismus PAM, alle SASL Mechanismen müssen von der IANA genehmigt werden. Siehe http://www.iana.org/assignments/sasl-mechanisms [...]
noch mitspielen? Der jetzige Istzustand ist der das Der LDAP-Server (SuSE-9.1) läuft und PAM so konfiguriert ist das ein lokaler Login den User aus dem LDAP-Server benutzt. Das funktioniert schon.
Neben der o.g. Umgebungsvariabe finde ich kein Konfigurationsdatei für saslauthd. Wie gehe ich für die Einrichtung vor bzw. wie kann ich überprüfen ob er richtig funktioniert?
saslauthd wird üblicherweise über (/usr/local)/etc/saslauthd.conf konfiguriert, sieh dazu auch die Doku "/usr/share/doc/packages/cyrus-sasl/LDAP_SASLAUTHD". In diesem Dokument werden die Parameter für LDAP beschrieben.
Nun soll das ganze jedoch abgesichert werden. Soweit ich die Unterlagen verstanden kann ich hierzu den Verbindungsaufbau mit TLS verschlüsselt abwickeln und die dananach aufgebaute Verbindung mit SSL verschlüsseln. Richtig?
SSL/TLS ist eine Verschlüsselung der kompletten Leitung. Damit würde dann auch der Authentifizierungs-Handshake (SASL) verschlüsselt.
SSL ist eine direkte Verschlüsselung der Leitung, meistens auf einem anderen Port. TLS ist eine Möglichkeit eine Verbindung über den normalen Port aufzubauen und wenn der Server TLS unterstüzt, nachträglich die Verschlüsselung einzuschalten. TLS hat SSL inzwischen fast verdrängt.
Ich denke mal das bei SASL noch mein Problem liegt. Wenn ich wie im Buch beschrieben den Befehl:
Welches Buch? doch nicht etwa meinem? :-) [...] Die TLS Fehler sollten noch einmal gesondert behandelt werden, das ist nur ein CA Fehler.
sasl_client_step: 2 Please enter your passwort: [Hier gebe ich mein Passwort ein] [...] ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: checkpass failed
Da fehlt der Mechanismus.
Das deutet auf ein Problem mit SASL und dem Zertifikat hin, oder? Wenn ich z.B. am Server direkt den Befehl:
ldapwhoami
eingebe erhalte ich den Fehler:
ldap_sasl_interactive_bind_s: No such attribut (16)
Das bezieht sich auf das Attribut 'uid' der Wert des Attributes kann nicht durch sasl-regexp in einen DN gewandelt werden.
Ich hoffe das jemand damit etwas anfangen kann.
Ja, ich kann was damit anfangen :-) Lass noch mal von vorne beginnen, ich lese erst seit zwei Stunden wieder diese Liste, die letzten 3 Wochen war ich abwesend. Wo ist dein Problem? (Konfiguration und Logauszüge) -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Am Sonntag, 23. Mai 2004 01:11 schrieb Dieter Kluenter:
Wenn du SASL Mechanismen nutzt und du die Anwender in einem Verzeichnisdienst speicherst, MUSS das Passwort im LDAP-Server als PLAINTEXT enthhalten sein, nicth mit irgendeinr Verschlüselung.
Wieso? Habe es heute mal interessehalber mit nem {MD5}-Passwort probiert und es hat auch anstandslos geklappt.
Loginversuch -> PAM -> SLAS-Aufruf um Verbinungsaufbau zu verschlüsseln -> LDAP
Dann wäre sicher SASL_AUTHMECH=pam die richtige Einstellung
SASL kennt keinen Mechanismus PAM, alle SASL Mechanismen müssen von der IANA genehmigt werden. Siehe http://www.iana.org/assignments/sasl-mechanisms [...]
Hiermit ist nicht der SASL-Mechanismus gemeint, der zwischen Server und Client sichtbar ist. Beim saslauthd heissen die Optionen "-a pam", "-a ldap",... genialerweise ebenfalls Auth-Mechs. -- Andreas
Andreas Winkelmann
Am Sonntag, 23. Mai 2004 01:11 schrieb Dieter Kluenter:
Wenn du SASL Mechanismen nutzt und du die Anwender in einem Verzeichnisdienst speicherst, MUSS das Passwort im LDAP-Server als PLAINTEXT enthhalten sein, nicth mit irgendeinr Verschlüselung.
Wieso? Habe es heute mal interessehalber mit nem {MD5}-Passwort probiert und es hat auch anstandslos geklappt.
Was hast du denn versucht? Der SASL Mechanismus DIGEST-MD5 benötigt ein plaintext Password um aus den ascii Werten eine Challange zu generieren, das würde nicht mit einem, Base64 kodierten, verschlüsselten Paßwort möglich sein. [...]
SASL kennt keinen Mechanismus PAM, alle SASL Mechanismen müssen von der IANA genehmigt werden. Siehe http://www.iana.org/assignments/sasl-mechanisms [...]
Hiermit ist nicht der SASL-Mechanismus gemeint, der zwischen Server und Client sichtbar ist. Beim saslauthd heissen die Optionen "-a pam", "-a ldap",... genialerweise ebenfalls Auth-Mechs.
Ach so, ein susespezifischer Parameter in einer Konfigurationsdatei. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Am Sonntag, 23. Mai 2004 09:33 schrieb Dieter Kluenter:
Wenn du SASL Mechanismen nutzt und du die Anwender in einem Verzeichnisdienst speicherst, MUSS das Passwort im LDAP-Server als PLAINTEXT enthhalten sein, nicth mit irgendeinr Verschlüselung.
Wieso? Habe es heute mal interessehalber mit nem {MD5}-Passwort probiert und es hat auch anstandslos geklappt.
Was hast du denn versucht?
Der SASL Mechanismus DIGEST-MD5 benötigt ein plaintext Password um aus den ascii Werten eine Challange zu generieren, das würde nicht mit einem, Base64 kodierten, verschlüsselten Paßwort möglich sein.
Nein, mit digest-md5 bzw. cram-md5 geht das natürlich nicht, die brauchen das Klartext-Passwort. Das geht nur mit plain oder login. Damit habe ich es gemacht.
[...]
SASL kennt keinen Mechanismus PAM, alle SASL Mechanismen müssen von der IANA genehmigt werden. Siehe http://www.iana.org/assignments/sasl-mechanisms [...]
Hiermit ist nicht der SASL-Mechanismus gemeint, der zwischen Server und Client sichtbar ist. Beim saslauthd heissen die Optionen "-a pam", "-a ldap",... genialerweise ebenfalls Auth-Mechs.
Ach so, ein susespezifischer Parameter in einer Konfigurationsdatei.
Nicht ganz: # saslauthd -v saslauthd 2.1.18 authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap ^^^^^^^^^^^^^^^^^^^^^^^^^^ Eher Cyrus-Spezifisch ;-) -- Andreas
participants (3)
-
Andreas Winkelmann
-
Dieter Kluenter
-
Sven Gehr