Hallo Leute, ich hab einen Linux-Client so konfiguriert das Authentifizierung und Benutzerinformationen mit Hilfe von nss_ldap und pam_ldap über Windows Active Directory funktionieren. Die AD-Schema-Erweiterung wurde mit Hilfe von SFU 3.0 erreicht. Soweit so gut funktioniert das auch. Aber wenn ich einen zweiten oder mehrere Server in der /etc/ldap.conf eintrage bekomme ich immer folgenden Fehler bei der Authentifizierung: login: cyrus.c:469: ldap_int_sasl_open: Assertion `lc->lconn_sasl_ctx == ((void *)0)' failed was bewirkt das ich mich überhaupt mit gar keinem Account mehr einloggen kann. Das nss_ldap modul funktioniert ohne Probleme mit mehreren Servern, was ich mit getent passwd nachprüfe. Ich benutze als Basis SuSE 9.0, hab es aber auch mit 8.2 probiert ohne erfolg. Auch die aktuelle Version 169 von pam_ldap bringt keine Besserung Ich will mehrere Server eintragen, damit ich bei Ausfall eines LDAP-Servers weiter erreichbar bin. Danke für jede Antwort Gruss Patrick PS: Meine ldap.conf (diskrete Daten hab ich mit .... überschrieben) : # Bind/connect timelimit bind_timelimit 3 # Reconnect policy: hard (default) will retry connecting to # the software with exponential backoff, soft will fail # immediately. bind_policy soft I want to add a second or third server to be more reliable if one of the AD-Server has an error or failure. Thank you for every answer Patrick Klaus URI ldaps://watt.mydomain.de/ ldaps://bell.mydomain.de/ tls_checkpeer no base ou=.................... ldap_version 3 scobe sub tls_cacertfile wattca.pem tls_cacertdir /etc/ssl/certs sasl_secprops maxssf=0 #PAM pam_filter objectclass=User pam_login_attribute msSFU30Name pam_password ad idle_timelimit 3600 pam_min_uid 10000 referrals no binddn cn=ldapsearch,ou=Assistenten,ou=............ bindpw ...... nss_base_passwd ............ nss_base_group ............ nss_base_shadow ............ # User Object Mapping #nss_map_attribute userPassword msSFU30Password nss_map_attribute uid msSFU30Name nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute gecos displayName nss_map_attribute cn msSFU30Name nss_map_attribute uniqueMember member nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute posixGroup msSFU30Name nss_map_objectclass shadowAccount User nss_map_objectclass posixAccount User nss_map_objectclass posixGroup Group
Hallo,
Patrick Klaus
Hallo Leute,
ich hab einen Linux-Client so konfiguriert das Authentifizierung und Benutzerinformationen mit Hilfe von nss_ldap und pam_ldap über Windows Active Directory funktionieren. Die AD-Schema-Erweiterung wurde mit Hilfe von SFU 3.0 erreicht.
Soweit so gut funktioniert das auch. Aber wenn ich einen zweiten oder mehrere Server in der /etc/ldap.conf eintrage bekomme ich immer folgenden Fehler bei der Authentifizierung:
login: cyrus.c:469: ldap_int_sasl_open: Assertion `lc->lconn_sasl_ctx == ((void *)0)' failed
Moment, wieso trägst du mehrere Server in /etc/ldap.conf ein? Das ist die Konfiguration für PAM. Wenn dann der Authentifizierungserver nicht eindeutig ist, kann das ja nicht funktionieren, insbesondere wenn, wie in deinem Beispiel, PAM über SASL authentifiziert. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
ja bitte kannst du näheres berichten wie du authentifizierung auf ein AD system zusammen bekommst? thx! lg Andreas Am Die, den 30.03.2004 schrieb Oliver Wiemer um 09:58:
Hallo,
ich hab einen Linux-Client so konfiguriert das Authentifizierung und Benutzerinformationen mit Hilfe von nss_ldap und pam_ldap über Windows Active Directory funktionieren. Die AD-Schema-Erweiterung wurde mit Hilfe von SFU 3.0 erreicht
Was ist SFU 3.0?
Viele Grüße
Olli
Oliver Wiemer schrieb:
Was ist SFU 3.0? http://www.google.de/search?q=SFU+3.0&sourceid=mozilla-search&start=0&start=0 Windows Services for UNIX (SFU)
;-) Hans
Oliver Wiemer schrieb:
Hallo,
ich hab einen Linux-Client so konfiguriert das Authentifizierung und Benutzerinformationen mit Hilfe von nss_ldap und pam_ldap über Windows Active Directory funktionieren. Die AD-Schema-Erweiterung wurde mit Hilfe von SFU 3.0 erreicht
Was ist SFU 3.0?
Services for Unix von Microsoft: http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/43648&words=SFU SFU erweitert das Schema von AD so, das man unter Eigenschaften jedes User Unix-Daten wie homeverzeichnis, Shell, UID, GID ... eintragen kann. Auch windows Gruppen kann man über Eigenschaften transparent zu einer Unix-Group machen. Das ist meiner Meinung auch das einzige was gut funktioniert. Der Server for NIS ist ein Krampf haben hier noch im Einsatz wollen das aber durch LDAP ersetzen. http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=4900629&forum_id=51740 Was LDAP angeht kann man sich auch: http://www.oo-services.com/de/articles/sso.html Allerdings wurde hier die Schema Erweiterung nicht mit SFU gemacht sondern mit einen freien Tool, im Prinzip macht das keinen Unterschied. Falls noch Infos fehlen einfach fragen. :-) Gruss Patrick
Dieter Kluenter schrieb: Hallo Dieter, vielen Dank für deine Antwort,
ich hab einen Linux-Client so konfiguriert das Authentifizierung und Benutzerinformationen mit Hilfe von nss_ldap und pam_ldap über Windows Active Directory funktionieren. Die AD-Schema-Erweiterung wurde mit Hilfe von SFU 3.0 erreicht.
Soweit so gut funktioniert das auch. Aber wenn ich einen zweiten oder mehrere Server in der /etc/ldap.conf eintrage bekomme ich immer folgenden Fehler bei der Authentifizierung:
login: cyrus.c:469: ldap_int_sasl_open: Assertion `lc->lconn_sasl_ctx == ((void *)0)' failed
Moment, wieso trägst du mehrere Server in /etc/ldap.conf ein? Das ist die Konfiguration für PAM. Wenn dann der Authentifizierungserver nicht eindeutig ist, kann das ja nicht funktionieren, insbesondere wenn, wie in deinem Beispiel, PAM über SASL authentifiziert.
laut /usr/share/doc/packages/pam_ldap/ldap.conf ============================================================= # Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. How long nss_ldap takes to failover depends on # whether your LDAP client library supports configurable # network or connect timeouts (see bind_timelimit). host 127.0.0.1 # The distinguished name of the search base. base dc=padl,dc=com # Another way to specify your LDAP server is to provide an # uri with the server name. This allows to use # Unix Domain Sockets to connect to a local LDAP Server. #uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/ =============================================================== sollte das ja gehen ! der grund ist, das ich bei Ausfall und nicht erreichbarkeit eines Servers weiterhin zwar mit zeitverzögern (BIND_TIMELIMIT) einen funktionierenden Linux-Server hab. Alles andere wäre fatal. Man bedenke z.B. das einkommende E-Mails abgewiesen werden weil über NSS der Benutzername nicht mehr aufgelöst werden kann. Wie schon erwähnt, nss_ldap kommt mit mehreren Hosts zurecht. Wenn ich einen Ausfall simuliere und an erster Stelle eine falsche IP eintrage, holt er automatisch nach der gesetzten BIND_TIMELIMIT -Zeit den nächsten Server. Stichwort SASL: Ich will überhaupt gar kein SASL benutzen sondern simple Authentification, warum zum Geier er SASL benutzt weiss ich nicht. Wo kann ich das abstellen? Finde das nirgendswo! Eventuell versuch ich mal das Modul zu kompilieren ohne installierte cyrus-sasl2 Bibliotheken. Weiterhin bekomme ich auch in den Log-Meldungen schon mit einem eingetragenen Server: Mar 30 19:06:51 raid sshd[6983]: pam_ldap: ldap_simple_bind Can't contact LDAP server Ich kann ich das nicht nachvollziehen warum es nicht funktioniert, schließlich klappt es ja mit nss_ldap welches ja die gleiche ldap.conf benutzt, ohne Probleme ! Irgendwelche Ideen? Ich bin am verzweifeln :-( Gruss Patrick
Patrick Klaus schrieb: Hi,
Stichwort SASL: Ich will überhaupt gar kein SASL benutzen sondern simple Authentification, warum zum Geier er SASL benutzt weiss ich nicht. Wo kann ich das abstellen? Finde das nirgendswo! Eventuell versuch ich mal das Modul zu kompilieren ohne installierte cyrus-sasl2 Bibliotheken.
Das funktioniert nicht, sasl muss installiert sein.
Weiterhin bekomme ich auch in den Log-Meldungen schon mit einem eingetragenen Server:
Mar 30 19:06:51 raid sshd[6983]: pam_ldap: ldap_simple_bind Can't contact LDAP server
Diese Meldungen kommen nur wenn sich lokal angelegte Nutzer über pam anmelden wollen. Bei Nutzern im LDAP kommt diese Fehlermeldung nicht.
Ich kann ich das nicht nachvollziehen warum es nicht funktioniert, schließlich klappt es ja mit nss_ldap welches ja die gleiche ldap.conf benutzt, ohne Probleme !
Hmm :-( Gruss Patrick
Hallo,
Patrick Klaus
Dieter Kluenter schrieb:
Hallo Dieter,
vielen Dank für deine Antwort,
ich hab einen Linux-Client so konfiguriert das Authentifizierung und Benutzerinformationen mit Hilfe von nss_ldap und pam_ldap über Windows Active Directory funktionieren. Die AD-Schema-Erweiterung wurde mit Hilfe von SFU 3.0 erreicht.
Soweit so gut funktioniert das auch. Aber wenn ich einen zweiten oder mehrere Server in der /etc/ldap.conf eintrage bekomme ich immer folgenden Fehler bei der Authentifizierung:
login: cyrus.c:469: ldap_int_sasl_open: Assertion `lc->lconn_sasl_ctx == ((void *)0)' failed Moment, wieso trägst du mehrere Server in /etc/ldap.conf ein? Das ist die Konfiguration für PAM. Wenn dann der Authentifizierungserver nicht eindeutig ist, kann das ja nicht funktionieren, insbesondere wenn, wie in deinem Beispiel, PAM über SASL authentifiziert.
laut
Ich kenne die Doku, das funktioniert aber nur in einer Failover-Umgebung.
# Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. How long nss_ldap takes to failover depends on # whether your LDAP client library supports configurable # network or connect timeouts (see bind_timelimit). host 127.0.0.1
Ist das die Adresse des Servers?
# The distinguished name of the search base. base dc=padl,dc=com
Ist das deine Suchbasis? [...]
Wie schon erwähnt, nss_ldap kommt mit mehreren Hosts zurecht. Wenn ich einen Ausfall simuliere und an erster Stelle eine falsche IP eintrage, holt er automatisch nach der gesetzten BIND_TIMELIMIT -Zeit den nächsten Server.
Das Modul nss_ldap ist ja nur das Serviceswitch-Modul, nicht das Authentifizierungsmodul.
Stichwort SASL: Ich will überhaupt gar kein SASL benutzen sondern simple Authentification, warum zum Geier er SASL benutzt weiss ich nicht. Wo kann ich das abstellen? Finde das nirgendswo! Eventuell versuch ich mal das Modul zu kompilieren ohne installierte cyrus-sasl2 Bibliotheken.
Das wird nicht gehen, da pam_ldap und nss_ldap mit liblap von OpenLDAP kompiliert wurden, daher auch als dynamische Bibliothek geladen wird, libldap wird aber mit cyrus-sasl kompiliert.
Weiterhin bekomme ich auch in den Log-Meldungen schon mit einem eingetragenen Server:
Mar 30 19:06:51 raid sshd[6983]: pam_ldap: ldap_simple_bind Can't contact LDAP server
Das Modul kann sich nicht an ActivDirectory binden, welchen Distinguished Name hast denn als binddn oder rootbinddn in /etc/ldap.conf eingetragen? Ist dieser DN auch in ActiveDirectory vertreten? Und hat dieser DN auch das Recht Passworte zu authentifizieren? Da ein simple bind nicht funktioniert, versucht pam_ldap ein strong bind mittels sasl.
Ich kann ich das nicht nachvollziehen warum es nicht funktioniert, schließlich klappt es ja mit nss_ldap welches ja die gleiche ldap.conf benutzt, ohne Probleme !
Mache ein ldapsearch -d3 -H ldap://dein.host -b "dc=blah.dc=blub" -x -D "cn=dein,was,weiß,ich" -w passwort -s sub "(objectclass=posixaccount)" Wichtig ist dabei nur die Ausgabe des Debugging-Modus, da kannst du nochvollziehen, was passiert. Dann kannst du noch mittels ldapcompare das Passwort vergleichen lassen. Was klappt mit nss_ldap? -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Dieter Kluenter schrieb: Hallo, vielen Danke für deine Antwort
Ich kenne die Doku, das funktioniert aber nur in einer Failover-Umgebung.
genau dies will ich erreichen.
# Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. How long nss_ldap takes to failover depends on # whether your LDAP client library supports configurable # network or connect timeouts (see bind_timelimit). host 127.0.0.1
Ist das die Adresse des Servers?
nein ist nur ein Auszug aus der standard-Conf die beim Paket dabei ist nur um zu sagen das dort steht, daß es mit mehreren Hosts gehen soll.
# The distinguished name of the search base. base dc=padl,dc=com
Ist das deine Suchbasis?
Hänge meine ldap.conf noch mal unten dran (wie bei der ersten mail)
Stichwort SASL: Ich will überhaupt gar kein SASL benutzen sondern simple Authentification, warum zum Geier er SASL benutzt weiss ich nicht. Wo kann ich das abstellen? Finde das nirgendswo! Eventuell versuch ich mal das Modul zu kompilieren ohne installierte cyrus-sasl2 Bibliotheken.
Das wird nicht gehen, da pam_ldap und nss_ldap mit liblap von OpenLDAP kompiliert wurden, daher auch als dynamische Bibliothek geladen wird, libldap wird aber mit cyrus-sasl kompiliert.
Danke, wieder schlauer geworden.
Weiterhin bekomme ich auch in den Log-Meldungen schon mit einem eingetragenen Server:
Mar 30 19:06:51 raid sshd[6983]: pam_ldap: ldap_simple_bind Can't contact LDAP server
Das Modul kann sich nicht an ActivDirectory binden, welchen Distinguished Name hast denn als binddn oder rootbinddn in /etc/ldap.conf eingetragen? Ist dieser DN auch in ActiveDirectory vertreten? Und hat dieser DN auch das Recht Passworte zu authentifizieren? Da ein simple bind nicht funktioniert, versucht pam_ldap ein strong bind mittels sasl.
Ja wie schon erwähnt, die Meldung kommt NUR dann auf, wenn ich mit einem lokalen Account mich anmelde, die Authentifizierung funktioniert aber trotz Fehlermeldung dann auch. Und die Authentifizierung funktioniert auch ohne Fehlermeldung mit AD Accounts. Die Anmeldung und Authentifizierung funktioniert bereits über pam_ldap und nss_ldap aber NUR wenn ich oben nur einen Host eingetragen habe. Wenn ich einen zweiten eintrage funktioniert nichts mehr. Dann kommt halt die SASL-Fehlermeldung, ich kann mich im System nirgends mehr einloggen. login: cyrus.c:469: ldap_int_sasl_open: Assertion `lc->lconn_sasl_ctx == ((void *)0)' failed
Ich kann ich das nicht nachvollziehen warum es nicht funktioniert, schließlich klappt es ja mit nss_ldap welches ja die gleiche ldap.conf benutzt, ohne Probleme !
Mache ein ldapsearch -d3 -H ldap://dein.host -b "dc=blah.dc=blub" -x -D "cn=dein,was,weiß,ich" -w passwort -s sub "(objectclass=posixaccount)"
das funktioniert einbahnfrei, wie erwartet.
Wichtig ist dabei nur die Ausgabe des Debugging-Modus, da kannst du nochvollziehen, was passiert.
Dann kannst du noch mittels ldapcompare das Passwort vergleichen lassen.
Was klappt mit nss_ldap?
Ich gehe mal von aus wenn ich mit "getent passwd" alle Accounts bekomme die es im AD gibt, dann sollte das richtig funktionieren oder? Auch halt wenn ich mehrere Hosts eingebe, gibt es keine Probleme. Um es nochmal auszudrücken. Meiner Meinung funktioniert alles so wie es soll, solange ich nur einen Host in die ldap.conf eintrage. Bei einen zweiten oder mehreren Host funktioniert das pam_ldap nicht mehr. Mit getent passwd kann ich weiterhin alle Accounts einsehen. Deswegen schiebe ich den Fehler auf pam_ldap. Warum das halt nicht funktioniert ist meine Frage und mein Problem :-( Meine ldap.conf (habe sicherheitsrelvante Daten mit sub.mydomain ersetzt) ================================================================ # Bind/connect timelimit bind_timelimit 3 # Reconnect policy: hard (default) will retry connecting to # the software with exponential backoff, soft will fail # immediately. bind_policy soft URI ldaps://watt.sub.mydomain.de/ ldaps://bell.sub.mydomain.de/ tls_checkpeer no base ou=sub,dc=sub,dc=mydomain,dc=de ldap_version 3 scope sub tls_cacertfile wattca.pem tls_cacertdir /etc/ssl/certs sasl_secprops maxssf=0 #PAM pam_filter objectclass=User pam_login_attribute msSFU30Name pam_password ad idle_timelimit 3600 pam_min_uid 10000 referrals no binddn cn=ldapsearch,ou=Assistenten,ou=sub,dc=sub,dc=mydomain,dc=de bindpw mysecretpassword nss_base_passwd ou=sub,dc=sub,dc=mydomain,dc=de?sub nss_base_group cn=Users,dc=sub,dc=mydomain,dc=de?sub nss_base_shadow ou=sub,dc=sub,dc=mydomain,dc=de?sub # User Object Mapping nss_map_attribute userPassword msSFU30Password nss_map_attribute uid msSFU30Name nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute gecos displayName nss_map_attribute cn msSFU30Name nss_map_attribute uniqueMember member nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute posixGroup msSFU30Name nss_map_objectclass shadowAccount User nss_map_objectclass posixAccount User nss_map_objectclass posixGroup Group =================================================================== Hoffe ich hab meinen Problemfall gute genug geschildert, wenn nicht, bitte nochmal fragen ! ;-) Vielen Dank schonmal. Gruss Patrick
Hallo,
Patrick Klaus
Dieter Kluenter schrieb:
Hallo,
vielen Danke für deine Antwort
Ich kenne die Doku, das funktioniert aber nur in einer Failover-Umgebung.
genau dies will ich erreichen. [...]
Die Anmeldung und Authentifizierung funktioniert bereits über pam_ldap und nss_ldap aber NUR wenn ich oben nur einen Host eingetragen habe. Wenn ich einen zweiten eintrage funktioniert nichts mehr. Dann kommt halt die SASL-Fehlermeldung, ich kann mich im System nirgends mehr einloggen. [...] Ich gehe mal von aus wenn ich mit "getent passwd" alle Accounts bekomme die es im AD gibt, dann sollte das richtig funktionieren oder? Auch halt wenn ich mehrere Hosts eingebe, gibt es keine Probleme.
Ja.
Um es nochmal auszudrücken. Meiner Meinung funktioniert alles so wie es soll, solange ich nur einen Host in die ldap.conf eintrage. Bei einen zweiten oder mehreren Host funktioniert das pam_ldap nicht mehr. Mit getent passwd kann ich weiterhin alle Accounts einsehen. Deswegen schiebe ich den Fehler auf pam_ldap.
Warum das halt nicht funktioniert ist meine Frage und mein Problem :-(
Ich kann deinen Fehler nicht nachvollziehen und prüfen, da ich nur einen Win2003 Server zu Testzwecken hier laufen habe. Deine Frage ist zu spezifisch für mich, frage einmal auf der Mailingliste 'pamldap@padl.com' nach, zum Anmelden siehe http://www.padl.com -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Dieter Kluenter schrieb: Hallo, danke für deine Antwort,
Ich kann deinen Fehler nicht nachvollziehen und prüfen, da ich nur einen Win2003 Server zu Testzwecken hier laufen habe. Deine Frage ist zu spezifisch für mich, frage einmal auf der Mailingliste 'pamldap@padl.com' nach, zum Anmelden siehe http://www.padl.com
hab ich schon gemacht, aber bisher keine Antwort bekommen :-( . Dummerweise kann ich die Mailingliste auch nicht mehr nach alten Nachrichten browsen, weil das nicht mehr geht dort. Den Fehler kannst Du aber auch bei dir einfach simulieren, indem Du den Server einfach mit der selben IP oder Adresse zweimal einträgst oder einen nicht existierenden Server einträgst. also URI ldaps://bell.mydomain.de/ ldaps://bell.mydomain.de/ Möglicherweise könnte ja auch eine Mail an die Openldap Liste nichts schaden. Vielen Dank nochmal, werde mal dein Buch in der FH empfehlen, über LDAP fehlt noch ein Buch in der Bücherei und die Kritiken sind ja ganz gut. ;) Gruss Patrick
Hallo,
Patrick Klaus
Dieter Kluenter schrieb:
Hallo,
danke für deine Antwort, [...] . Dummerweise kann ich die Mailingliste auch nicht mehr nach alten Nachrichten browsen, weil das nicht mehr geht dort.
Den Fehler kannst Du aber auch bei dir einfach simulieren, indem Du den Server einfach mit der selben IP oder Adresse zweimal einträgst oder einen nicht existierenden Server einträgst.
Das kann ich mal versuchen lassen. Das ist ein Thema für meinen Praktikanten :-)
Möglicherweise könnte ja auch eine Mail an die Openldap Liste nichts schaden.
Lieber nicht, pam_ldap und dann noch mit ActiveDirectory ist da absolut off topic. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Dieter Kluenter schrieb: Hallo, danke für deine Antwort,
Das kann ich mal versuchen lassen. Das ist ein Thema für meinen Praktikanten :-)
soso arbeiten lassen, ne feine Sache ;-).
Möglicherweise könnte ja auch eine Mail an die Openldap Liste nichts schaden.
Lieber nicht, pam_ldap und dann noch mit ActiveDirectory ist da absolut off topic.
So ich bin um eine Erkenntnis weiter, beide Module machen Probleme beim mehreren Hosts, hab die zwei so kompiliert das sie beide auf unterschiedliche ldap.confs zugreifen. --with-ldap-conf-file=/etc/ldap_nss.conf \ - nss bringt die sasl-Fehlermeldung, login: cyrus.c:469: ldap_int_sasl_open: Assertion `lc->lconn_sasl_ctx > == ((void *)0)' failed - pam authentifizierung funktioniert nicht, pam_unix2: pam_sm_authenticate() called danach kommt gar nichts mehr. Weiterhin funktionieren mehrere HOSTS wenn alles OHNE SSL gemacht wird. Also anstatt ldaps:// ldap:// Das bringt natürlich wieder neue Fragen auf. Fällt Dir vielleicht ein Tip ein???? Möglicherweise sind ja hier die openldap Bibliotheken betroffen die den Fehler produzieren !? Danke im Vorraus Gruss Patrick
Patrick Klaus
Dieter Kluenter schrieb:
Hallo,
danke für deine Antwort, [...] So ich bin um eine Erkenntnis weiter, beide Module machen Probleme beim mehreren Hosts, hab die zwei so kompiliert das sie beide auf unterschiedliche ldap.confs zugreifen.
--with-ldap-conf-file=/etc/ldap_nss.conf \
- nss bringt die sasl-Fehlermeldung, login: cyrus.c:469: ldap_int_sasl_open: Assertion `lc->lconn_sasl_ctx
== ((void *)0)' failed
- pam authentifizierung funktioniert nicht, pam_unix2: pam_sm_authenticate() called danach kommt gar nichts mehr.
Weiterhin funktionieren mehrere HOSTS wenn alles OHNE SSL gemacht wird. Also anstatt ldaps:// ldap://
Das bringt natürlich wieder neue Fragen auf. Fällt Dir vielleicht ein Tip ein????
Möglicherweise sind ja hier die openldap Bibliotheken betroffen die den Fehler produzieren !?
Nein, eher openssl. Du stellst ja eigentlich SSL Verbinddungen her ohne daß nach einem Zertifikat verlangt wird, ist zwar nicht die feine Sache, aber mit AD wohl nicht anders zu realisieren. % openssl s_client -connect dein.host:636 -showcerts sollte dir zeigen, ob das Zertifikat gelesen werden kann. sonste versuche mal mit ldapsearch -d3 -H ldaps://dein.host usw. da werden die Verbindungsdaten ausgewiesen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Dieter Kluenter schrieb:
Nein, eher openssl. Du stellst ja eigentlich SSL Verbinddungen her ohne daß nach einem Zertifikat verlangt wird, ist zwar nicht die feine Sache, aber mit AD wohl nicht anders zu realisieren.
% openssl s_client -connect dein.host:636 -showcerts
================================================================= openssl s_client -connect 143.xxx.xxx.2:636 -showcerts CONNECTED(00000003) depth=0 /CN=bell.sub.mydomain.de verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=bell.sub.mydomain.de verify error:num=27:certificate not trusted verify return:1 depth=0 /CN=bell.sub.mydomain.de verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=bell.sub.mydomain.de i:/Email=Frank.Ausserlechner@sub.mydomain.de/C=DE/ST=RLP/L=domain/O=FH/OU =sub/CN=watt1012 -----BEGIN CERTIFICATE----- MIIGVDCCBf6gAwIBAgIKLb9zgwAAAAAAAzANBgkqhkiG9w0BAQUFADCBkTE0MDIG CSqGSIb3DQEJARYlRnJhbmsuQXVzc2VybGVjaG5lckBldWkuZmgta29ibGVuei5k ZTELMAkGA1UEBhMCREUxDDAKBgNVBAgTA1JMUDEQMA4GA1UEBxMHS29ibGVuejEL MAkGA1UEChMCRkgxDDAKBgNVBAsTA0VVSTERMA8GA1UEAxMId2F0dDEwMTIwHhcN MDQwMzE3MDk0NDA5WhcNMDYwMzE3MDk1NDA5WjAhMR8wHQYDVQQDExZiZWxsLmV1 aS5maC1rb2JsZW56LmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi59hl +c7VUKBHXhISWIDw6mtTtsTAnuHydpsfurQRQ9feBvvlf6IuzOcFyGxF7erzrn4w nAPVI8KZYrRnOs2M3XNzD8mdDkIXyyjPnymathSKvBarr8uF0oKYWAsyre66tL8Q hoBKmVE16ZYXbrl2aT7NK/a8mT83QtVmySJ28QIDAQABo4IEYTCCBF0wCwYDVR0P BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAvBgkrBgEEAYI3 FAIEIh4gAEQAbwBtAGEAaQBuAEMAbwBuAHQAcgBvAGwAbABlAHIwHQYDVR0OBBYE FAXKI5gZlu66ItdG2NXJq0b7zzcIMIHNBgNVHSMEgcUwgcKAFIdodhaJY5BPD/C/ nR96ApAC6zN/oYGXpIGUMIGRMTQwMgYJKoZIhvcNAQkBFiVGcmFuay5BdXNzZXJs ZWNobmVyQGV1aS5maC1rb2JsZW56LmRlMQswCQYDVQQGEwJERTEMMAoGA1UECBMD UkxQMRAwDgYDVQQHEwdLb2JsZW56MQswCQYDVQQKEwJGSDEMMAoGA1UECxMDRVVJ MREwDwYDVQQDEwh3YXR0MTAxMoIQaRAXykqW2pVOTf8Y6FQqOjCCAUoGA1UdHwSC AUEwggE9MIG+oIG7oIG4hoG1bGRhcDovLy9DTj13YXR0MTAxMixDTj13YXR0LENO PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPWV1aSxEQz1maC1rb2JsZW56LERDPWRlP2NlcnRpZmlj YXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludDA7oDmgN4Y1aHR0cDovL3dhdHQuZXVpLmZoLWtvYmxlbnouZGUvQ2Vy dEVucm9sbC93YXR0MTAxMi5jcmwwPaA7oDmGN2ZpbGU6Ly9cXHdhdHQuZXVpLmZo LWtvYmxlbnouZGVcQ2VydEVucm9sbFx3YXR0MTAxMi5jcmwwggF7BggrBgEFBQcB AQSCAW0wggFpMIGwBggrBgEFBQcwAoaBo2xkYXA6Ly8vQ049d2F0dDEwMTIsQ049 QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNv bmZpZ3VyYXRpb24sREM9ZXVpLERDPWZoLWtvYmxlbnosREM9ZGU/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwWAYI KwYBBQUHMAKGTGh0dHA6Ly93YXR0LmV1aS5maC1rb2JsZW56LmRlL0NlcnRFbnJv bGwvd2F0dC5ldWkuZmgta29ibGVuei5kZV93YXR0MTAxMi5jcnQwWgYIKwYBBQUH MAKGTmZpbGU6Ly9cXHdhdHQuZXVpLmZoLWtvYmxlbnouZGVcQ2VydEVucm9sbFx3 YXR0LmV1aS5maC1rb2JsZW56LmRlX3dhdHQxMDEyLmNydDBCBgNVHREEOzA5oB8G CSsGAQQBgjcZAaASBBAhHOcXFJxDQKTT8Xjat2qgghZiZWxsLmV1aS5maC1rb2Js ZW56LmRlMA0GCSqGSIb3DQEBBQUAA0EAsu2oxYCWkgqfwlu8g5uXV8iaQX75IR0g V0ooZp5M38EQtVZ1sjW3Vr0QcsQ20DYQT2HzvqQ4D8SiQ3ryHWzGgw== -----END CERTIFICATE----- --- Server certificate subject=/CN=bell.sub.mydomain.de issuer=/Email=Frank.Ausserlechner@sub.mydomain.de/C=DE/ST=RLP/L=domain/O=FH/ OU=sub/CN=watt1012 --- Acceptable client certificate CA names /Email=Frank.Ausserlechner@sub.mydomain.de/C=DE/ST=RLP/L=domain/O=FH/OU=sub/ CN=watt1012 /Email=Frank.ausserlechner@sub.mydomain.de/C=DE/ST=rlp/L=domain/O=watt1012/O U=watt1012/CN=watt1012 /C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority - G2/O U=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network /C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/O U=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - F or authorized use only/CN=VeriSign Class 3 Public Primary Certification Authori ty - G3 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - F or authorized use only/CN=VeriSign Class 1 Public Primary Certification Authori ty - G3 /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Freemail CA/Email=personal-freemail@thawte.com /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Premium CA/Email=personal-premium@thawte.com /C=US/O=First Data Digital Certificates Inc./CN=First Data Digital Certificates Inc. Certification Authority /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Basic CA/Email=personal-basic@thawte.com /C=DK/O=KMD/OU=KMD-CA/CN=KMD-CA Server/0.9.2342.19200300.100.1.3=infoca@kmd-ca. dk /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - F or authorized use only/CN=VeriSign Class 2 Public Primary Certification Authori ty - G3 /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority /O=eSign Australia/OU=Public Secure Services/CN=Primary Utility Root CA /O=eSign Australia/OU=Public Secure Services/CN=eSign Imperito Primary Root CA /C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c ) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/O U=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network /C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLo ck Uzleti (Class B) Tanusitvanykiado /O=Entrust.net/OU=www.entrust.net/SSL_CPS incorp. by ref. (limits liab.)/OU=(c) 2000 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority /C=CO/L=Carrera 9 16-21 Bogota/O=Certicamara S.A. Entidad de Certificacion/CN=C ertificado Empresarial Clase-A /C=BR/O=ICP-Brasil/OU=Instituto Nacional de Tecnologia da Informacao - ITI/L=Br asilia/ST=DF/CN=Autoridade Certificadora Raiz Brasileira /C=US/O=GTE Corporation/CN=GTE CyberTrust Root /C=BE/O=Belgacom/OU=E-Trust/CN=Belgacom E-Trust Root CA for qualified certifica tes /C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo Root Certificate Authority /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Glo bal Root /C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c ) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority /C=AT/O=A-Trust/OU=A-Trust-nQual-01/CN=A-Trust-nQual-01 /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Ro ot Authority /C=DK/O=KMD/OU=Root CA/CN=KMD-CA Root /C=HU/ST=Hungary/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiad ok/CN=NetLock Kozjegyzoi (Class A) Tanusitvanykiado /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/O U=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network /C=DK/O=KMD/OU=KMD-CA/CN=KMD-CA Kvalificeret Person /C=IE/O=An Post/OU=Post.Trust Ltd./CN=Post.Trust Root CA /C=BE/O=Belgacom/OU=E-Trust/CN=Belgacom E-Trust Root CA for normalised certific ates /O=eSign Australia/OU=Gatekeeper PKI/CN=Gatekeeper Root CA /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - F or authorized use only/CN=VeriSign Class 4 Public Primary Certification Authori ty - G3 /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority /O=Entrust.net/OU=www.entrust.net/GCCA_CPS incorp. by ref. (limits liab.)/OU=(c ) 2000 Entrust.net Limited/CN=Entrust.net Client Certification Authority /C=US/O=Entrust.net/OU=www.entrust.net/Client_CA_Info/CPS incorp. by ref. limit s liab./OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Client Certification Aut hority /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Roo t /C=HK/O=Hongkong Post/CN=Hongkong Post Root CA /C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLo ck Expressz (Class C) Tanusitvanykiado /C=AT/O=Telekom-Control-Kommission/CN=Telekom-Control-Kommission Top 1 /C=AT/O=\x00A\x00-\x00T\x00r\x00u\x00s\x00t\x00 \x00G\x00e\x00s\x00.\x00 \x00f\ x00\xFC\x00r\x00 \x00S\x00i\x00c\x00h\x00e\x00r\x00h\x00e\x00i\x00t\x00s\x00s\x 00y\x00s\x00t\x00e\x00m\x00e\x00 \x00i\x00m\x00 \x00e\x00l\x00e\x00k\x00t\x00r\ x00.\x00 \x00D\x00a\x00t\x00e\x00n\x00v\x00e\x00r\x00k\x00e\x00h\x00r\x00 \x00G \x00m\x00b\x00H/OU=A-Trust-Qual-01/CN=A-Trust-Qual-01 /C=es/O=Servicio de Certificacion del Colegio de Registradores (SCR)/OU=Certifi cado Propio/OU=Certificado Raiz/CN=Certificado de la Clave Principal/2.5.4.9=Pr incipe de Vergara 72 28006 Madrid/Email=scr@registradores.org --- SSL handshake has read 8900 bytes and written 318 bytes ---koblenz New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 1024 bit SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: F11E0000C972A21E46A2948832A022D42499CB7203CDFE84F914B619711D2D0 4 Session-ID-ctx: Master-Key: 4E145EAFDEAA028782426E188F235D4A31374E1786D7DA0C431E61430C8A8D4 24057E20487D9E01E5D40E2E93D082631 Key-Arg : None Start Time: 1080763661 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) =====================================================================
sollte dir zeigen, ob das Zertifikat gelesen werden kann.
sonste versuche mal mit ldapsearch -d3 -H ldaps://dein.host usw. da werden die Verbindungsdaten ausgewiesen.
Jo, das selbe spiel es klappt ja mit einem eingetragenen Host in der ldap.conf aber nur nicht mit zwei. Nach googlen hab ich auch das hier gefunden, sollte dir ja bekannt sein. ;-) http://www.openldap.org/lists/openldap-software/200403/msg00330.html Hilft mir auch nicht weiter, nur das einer das gleiche Problem hat, vielleicht schreib ich ihm einfach mal, vielleicht hat er das Problem gelöst bekommen. Viele Dank im Vorraus Gruss Patrick
Hallo, Am Wed, 31 Mar 2004, Patrick Klaus schrieb:
-----BEGIN CERTIFICATE----- MIIGVDCCBf6gAwIBAgIKLb9zgwAAAAAAAzANBgkqhkiG9w0BAQUFADCBkTE0MDIG [..] V0ooZp5M38EQtVZ1sjW3Vr0QcsQ20DYQT2HzvqQ4D8SiQ3ryHWzGgw== -----END CERTIFICATE-----
Sach ma, hat dir dä Didää ins Hirn geschissen, oder warum kommst du nicht selbst auf die Idee sowas zu kuerzen? -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Patrick Klaus
Dieter Kluenter schrieb:
[...]>
Hilft mir auch nicht weiter, nur das einer das gleiche Problem hat, vielleicht schreib ich ihm einfach mal, vielleicht hat er das Problem gelöst bekommen.
Irgendwo habe ich mal geschrieben, daß die Lektüre des Quellcodes erhellend sein kann, das trifft auch hier mal wieder zu. :-) Ich habe mal den Quellcode pam_ldap.c gelesen und eine Codeschnipsel sind mir dabei aufgefallen: 1. die Auflistung mehrerer Hosts wird nur dann genötigt, wenn die authentifizierenden Verzeichnisdienste jeweils nur einen Teil der Suchbasis verwalten, also bei verteilten Systemen. 2. Bei einer TLS/SSL Verbindung wird die Sitzung nicht beendet, sondern aufrecht erhalten (persistant), das Zertifikat wird zu diesem Zweck im Cache gespeichert. Ich denke du verstehst, was das bedeutet, übrigens, daß ist kein Aprilscherz :-) Dein Failover Szenario muß also anders konstruiert werden. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Dieter Kluenter schrieb: Hallo,
Irgendwo habe ich mal geschrieben, daß die Lektüre des Quellcodes erhellend sein kann, das trifft auch hier mal wieder zu. :-) Ich habe mal den Quellcode pam_ldap.c gelesen und eine Codeschnipsel sind mir dabei aufgefallen:
jo, mir liegt die C-Sprache nicht so gut, sowas lernt man auf ner FH nicht mehr genügend, eher Win32-API, Java, C#. Respekt für deinen guten Durchblick.
1. die Auflistung mehrerer Hosts wird nur dann genötigt, wenn die authentifizierenden Verzeichnisdienste jeweils nur einen Teil der Suchbasis verwalten, also bei verteilten Systemen. 2. Bei einer TLS/SSL Verbindung wird die Sitzung nicht beendet, sondern aufrecht erhalten (persistant), das Zertifikat wird zu diesem Zweck im Cache gespeichert.
Vielen Dank, dass erklärt natürlich einiges. Sowas sollte man doch auch in die Doku von pam_ldap und nss_ldap reinschreiben oder? Das bedeutet das bei TLS Verbindungen nur ein Host da zu stehen hat. Sehe ich das falsch ?
Ich denke du verstehst, was das bedeutet, übrigens, daß ist kein Aprilscherz :-)
Ja besser ist die grausame Wahrheit ;-)
Dein Failover Szenario muß also anders konstruiert werden.
Nach ein bissl improvisieren fiel mir noch eine Möglichkeit ein, die prompt funktionierte. Denkbar einfach: Habe in /etc/hosts einfach alle AD-ServerIPs einem Namen zugeordnet. 143.xxx.xxx.2 ldaphosts 143.xxx.xxx.3 ldaphosts 143.xxx.xxx.4 ldaphosts 143.xxx.xxx.5 ldaphosts in die /etc/ldap.conf entsprechend ldaps://ldaphosts/ eingetragen. Funktioniert prächtig, fällt einer aus, wird mit Zeitverzögerung der nächste geholt. Da alle Server den selben Verzeichnisinhalt haben, reicht das ja auch. Ich bedanke mich recht herzlich, weil Du mich auf den richtigen Weg gebracht hast ;-). Alles gute noch! Gruss Patrick
Hallo,
Patrick Klaus
Dieter Kluenter schrieb:
Hallo,
Irgendwo habe ich mal geschrieben, daß die Lektüre des Quellcodes erhellend sein kann, das trifft auch hier mal wieder zu. :-) Ich habe mal den Quellcode pam_ldap.c gelesen und eine Codeschnipsel sind mir dabei aufgefallen:
jo, mir liegt die C-Sprache nicht so gut, sowas lernt man auf ner FH nicht mehr genügend, eher Win32-API, Java, C#. Respekt für deinen guten Durchblick.
1. die Auflistung mehrerer Hosts wird nur dann genötigt, wenn die authentifizierenden Verzeichnisdienste jeweils nur einen Teil der Suchbasis verwalten, also bei verteilten Systemen. 2. Bei einer TLS/SSL Verbindung wird die Sitzung nicht beendet, sondern aufrecht erhalten (persistant), das Zertifikat wird zu diesem Zweck im Cache gespeichert.
Vielen Dank, dass erklärt natürlich einiges. Sowas sollte man doch auch in die Doku von pam_ldap und nss_ldap reinschreiben oder? Das bedeutet das bei TLS Verbindungen nur ein Host da zu stehen hat. Sehe ich das falsch ? [...]
Da sind wir bei meinem Lieblingsthema TLS vs. SSL. :-) Um eines vorweg zu nehmen, mit ordentlich aufgesetztem TLS wäre das nicht passiert. Der Grund liegt darin, daß bei TLS der Client eine Kopie da CA Zertifikats hat und die Identität des Servers damit prüfen kann, bei wechselnden Server-Zertifikaten kann der Client immer noch anhand des CN prüfen, ob der Server auch vertrauenswürdig ist. Um auf deine Frage zurückzukommen, bei TLS sollten eigentlich mehrere Server identifziert und authentifiziert werden können, interessante Aufgabe für meinen Pratikanten, der möchte ja etwas lernen. Aber das ist ein weites Feld und ein anderes Thema.
Ich bedanke mich recht herzlich, weil Du mich auf den richtigen Weg gebracht hast ;-). Alles gute noch!
War mir ein Vergnügen, so kann ich meinem Schülerpraktikaten eine interessante Aufgabe stellen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
participants (6)
-
David Haller -
Dieter Kluenter -
Hans Moser -
Mrvka Andreas -
Oliver Wiemer -
Patrick Klaus