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 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

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

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

Andreas Winkelmann writes:

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, Sven Gehr writes:

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

Sven Gehr writes:

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 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

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

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

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

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 writes:

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

Sven Gehr writes:

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

Sven Gehr writes:

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

Sven Gehr writes:

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

Andreas Winkelmann writes:

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