ldap/nscd: kein Einloggen möglich
Hallo, ich habe opensuse 11.3 auf x86_64 installiert und prompt Probleme. Soll heißen es ist eigentlich nur eins: ldap tut nicht. Erst mal vorneweg: Bis einschließlich opensuse 11.2 (32- und 64-bit) hat ldap einwandfrei funktioniert. Die Installation ist dieselbe wie auf den opensuses <= 11.2. Hier sind die Pakete, die auf opensuse 11.3 installiert sind: ~> rpm -qa | grep ldap libldap-2_4-2-32bit-2.4.21-9.1.x86_64 nss_ldap-32bit-265-4.2.x86_64 yast2-ldap-2.17.3-12.2.x86_64 nss_ldap-265-4.2.x86_64 libldap-2_4-2-2.4.21-9.1.x86_64 libldapcpp1-0.2.1-3.2.x86_64 openldap2-2.4.21-9.1.x86_64 pam_ldap-185-4.2.x86_64 openldap2-client-2.4.21-9.1.x86_64 pam_ldap-32bit-185-4.2.x86_64 yast2-ldap-client-2.19.2-1.4.noarch openldap2-devel-2.4.21-9.1.x86_64 ~> rpm -qa | grep pam gnome-keyring-pam-2.30.1-2.11.x86_64 pam-modules-32bit-11.2-8.1.x86_64 pam-modules-11.2-8.1.x86_64 pam-32bit-1.1.1.90-1.6.x86_64 pam_apparmor-2.3-57.1.x86_64 pam-config-0.73-2.10.x86_64 pam_apparmor-32bit-2.3-57.1.x86_64 gnome-keyring-pam-32bit-2.30.1-2.11.x86_64 pam-1.1.1.90-1.6.x86_64 pam_ldap-185-4.2.x86_64 pam-devel-1.1.1.90-1.6.x86_64 pam_ldap-32bit-185-4.2.x86_64 yast2-pam-2.19.1-3.2.noarch ~> rpm -qa | grep nscd libnscd-2.0.2-113.1.x86_64 nscd-2.11.2-2.4.x86_64 libnscd-32bit-2.0.2-113.1.x86_64 Seit ich im /etc/ldap.conf die Zeile tls_cacertdir /etc/ssl/certs das Kommentarzeichen weggemacht habe, geht wenigstens 'getent passwd' (alle ldap-Benutzer werden angezeigt) Beim Einloggen tun lokale Benutzer einwandfrei. Wenn ich mich als ldap-Benutzer einloggen will, kommt im /var/log/messages: nss_ldap: could not search LDAP server - Server is unavailable gkr-pam: error looking up user information for: [hier steht der Benutzername] User not known to the underlying authentication module Der Login tut nicht. Witzigerweise kann ich mich doch einloggen, wenn ich eines von beiden tue: Im /etc/ldap.conf die Zeile tls_checkpeer no setzen. Dann wird aber das Zertifikat nicht geprüft. Dies ist für uns keine Dauerlösung. oder ich setze im /etc/nscd.conf enable-cache passwd no (Unabhängig ob ich nscd oder unscd installiert habe) Auch das ist keine Lösung, weil dann bei jeder ldap-Anfrage, und sei es nur 'ls -l' der Netzwerkverkehr steigt, weil der Klient nicht im Cache nachschauen kann. Mir ist bekannt, dass opensuse 11.3 ein nscd-Problem hat. Aber das, was ich bisher dazu gefunden habe, hilft mir nicht weiter. Die Frage ist auch, ob ich ein ldap- oder ein nscd-Problem habe. Weiß jemand, was ich falsch gemacht habe, oder bin ich auf einen Bug gestoßen? Gruß und Dank, Ulrich PS: Hier noch /etc/nscd.conf und ldap.conf: /etc/nscd.conf: logfile /var/log/nscd.log debug-level 4 paranoia no enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes max-db-size passwd 33554432 auto-propagate passwd yes enable-cache group yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes persistent group yes shared group yes max-db-size group 33554432 auto-propagate group yes enable-cache hosts yes positive-time-to-live hosts 600 negative-time-to-live hosts 0 suggested-size hosts 211 check-files hosts yes persistent hosts no shared hosts yes max-db-size hosts 33554432 enable-cache services yes positive-time-to-live services 28800 negative-time-to-live services 20 suggested-size services 211 check-files services yes persistent services yes shared services yes max-db-size services 33554432 /etc/ldap.conf: host unser-server base o=xxxxxxxx ldap_version 3 bind_policy soft pam_lookup_policy yes pam_check_host_attr yes pam_password crypt ssl start_tls ldap_version 3 pam_filter objectclass=posixAccount nss_base_passwd ou=xxxxx,o=xxxxx nss_base_shadow ou=xxxxx,o=xxxxx nss_base_group ou=xxxxx,o=xxxxx tls_cacertdir /etc/ssl/certs -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Tue, 20 Jul 2010 10:05:13 +0200 schrieb Ulrich Hiller <hiller@mpia-hd.mpg.de>:
Hallo, ich habe opensuse 11.3 auf x86_64 installiert und prompt Probleme. Soll heißen es ist eigentlich nur eins: ldap tut nicht.
Was bedeutet 'ldap tut nicht'?
Erst mal vorneweg: Bis einschließlich opensuse 11.2 (32- und 64-bit) hat ldap einwandfrei funktioniert.
Was meinst du damit, pam_ldap und nss_ldap haben funktioniert, oder OpenLDAP hat funktioniert. [...] Zu pam_ldap und nss_ldap kann ich wenig sagen, denn das sind LDAP Clients. Versuche doch erst einmal OpenLDAP als Fehlerquelle auszuschließen. Dazu startest du slapd mit dem Parameter -d384 auf der Konsole. Sieh dir die Debugging Ausgaben an und versuche, die Fehlerquelle zu erkennen. Dann sehen wir weiter. -Dieter -- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, tut mir Leid, dass ich mich so missverständlich ausgedrückt habe. Hier nochmal das Problem: Wir verwalten unsere Benutzer über einen ldap server, was bisher immer sehr gut geklappt hat. Jetzt wurde eine opensuse 11.3 x86_64 Kiste aufgesetzt. Ich versuche mich als so ein Benutzer einzuloggen. Das schlägt fehl. In /var/log/messages sehe ich: nss_ldap: could not search LDAP server - Server is unavailable gkr-pam: error looking up user information for: [hier steht der Benutzername] User not known to the underlying authentication module Es gibt 3 Workarounds: 1. Benutzer lokal anlegen, ohne ldap 2. Im /etc/ldap.conf tls_checkpeer no 3. Im /etc/nscd.conf enable-cache passwd no oder 'rcnscd stop' Alle 3 Workarounds sind für uns nicht gangbar. 1. Wir wollen unsere Benutzer zentral verwalten 2. Wir hätten gerne einen tls-Zertifikatscheck 3. Ohne nscd entsteht schon bei einfachen Kommandos wie 'ls -l' eine Netzwerklast Richting ldap-Server Übrigens: 'getent passwd' zeigt alle ldap-Benutzer an. Und .... bis opensuse 11.2 hat alles super funktioniert. Gruß, ulrich On 07/20/2010 10:01 PM, Dieter Kluenter wrote:
Am Tue, 20 Jul 2010 10:05:13 +0200 schrieb Ulrich Hiller<hiller@mpia-hd.mpg.de>:
Hallo, ich habe opensuse 11.3 auf x86_64 installiert und prompt Probleme. Soll heißen es ist eigentlich nur eins: ldap tut nicht. Was bedeutet 'ldap tut nicht'?
Erst mal vorneweg: Bis einschließlich opensuse 11.2 (32- und 64-bit) hat ldap einwandfrei funktioniert. Was meinst du damit, pam_ldap und nss_ldap haben funktioniert, oder OpenLDAP hat funktioniert. [...]
Zu pam_ldap und nss_ldap kann ich wenig sagen, denn das sind LDAP Clients. Versuche doch erst einmal OpenLDAP als Fehlerquelle auszuschließen. Dazu startest du slapd mit dem Parameter -d384 auf der Konsole. Sieh dir die Debugging Ausgaben an und versuche, die Fehlerquelle zu erkennen. Dann sehen wir weiter.
-Dieter
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ulrich Hiller [21.07.2010 14:59]:
Hallo, tut mir Leid, dass ich mich so missverständlich ausgedrückt habe. Hier nochmal das Problem: Wir verwalten unsere Benutzer über einen ldap server, was bisher immer sehr gut geklappt hat. Jetzt wurde eine opensuse 11.3 x86_64 Kiste aufgesetzt. Ich versuche mich als so ein Benutzer einzuloggen. Das schlägt fehl. In /var/log/messages sehe ich:
nss_ldap: could not search LDAP server - Server is unavailable gkr-pam: error looking up user information for: [hier steht der Benutzername] User not known to the underlying authentication module
Es gibt 3 Workarounds: 1. Benutzer lokal anlegen, ohne ldap 2. Im /etc/ldap.conf tls_checkpeer no 3. Im /etc/nscd.conf enable-cache passwd no oder 'rcnscd stop'
Alle 3 Workarounds sind für uns nicht gangbar. 1. Wir wollen unsere Benutzer zentral verwalten 2. Wir hätten gerne einen tls-Zertifikatscheck 3. Ohne nscd entsteht schon bei einfachen Kommandos wie 'ls -l' eine Netzwerklast Richting ldap-Server
Übrigens: 'getent passwd' zeigt alle ldap-Benutzer an. Und .... bis opensuse 11.2 hat alles super funktioniert.
Gruß, ulrich
Zunächst einmal ist TOFU[1] böse. Ich sitze hier an einer openSUSE 11.3 x86_64 und melde mich ohne Probleme am LDAP an. Allerdings nutze ich keine SSL-Verschlüsselung. Und keinen openLDAP-Server, wir haben hier eine Farm von SUN Java Directory Servern stehen. Man kann trefflich im Web suchen (z. B. nach "ldaps ssl passwd") und alle möglichen (Teil-)Ursachen finden, z. B. <http://www.ozzu.com/de/unix-linux-forum/openldap-ssl-tls-problem-mit-pam-nss-t98282.html> oder <http://old.nabble.com/Can%27t-get-SSL-working-properly-with-openSUSE-LDAP-client-%28works-with-ldapsearch-%2b-SSL-though%29-td13686328.html>. Vielleicht helfen die Seiten Dir auch weiter? HTH Werner [1] http://de.wikipedia.org/wiki/TOFU -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxG9J4ACgkQk33Krq8b42O4BwCeJ06r2DKPZY54fPIQi+/j8/LP Gr0Anj0iYErxQJTA7brELCfGZdN7Uczz =Lnay -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, hier ist jetzt der debug output vom ldap server mit -d384. Was mir auffällt ist (TLS negotiation failure) und später TLS established Aber sonst? Im client kommt nachwievor nss_ldap: could not search LDAP server - Server is unavailable gkr-pam: error looking up user information for: [hier steht der Benutzername] User not known to the underlying authentication module Gruß, Ulrich ================================================= Jul 21 15:09:57 ldap-server slapd[81273]: slapd starting Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 fd=21 ACCEPT from IP=nnn.nnn.nnn.nnn:51789 (IP=0.0.0.0:389) Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 op=0 STARTTLS Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 op=0 RESULT oid= err=0 text= Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 fd=21 closed (TLS negotiation failure) Jul 21 15:10:08 ldap-server slapd[81273]: conn=1008 fd=21 ACCEPT from IP=nnn.nnn.nnn.nnn:51790 (IP=0.0.0.0:389) Jul 21 15:10:08 ldap-server slapd[81273]: conn=1008 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 21 15:10:08 ldap-server slapd[81273]: conn=1008 op=0 STARTTLS Jul 21 15:10:08 ldap-server slapd[81273]: conn=1008 op=0 RESULT oid= err=0 text= Jul 21 15:10:08 ldap-server slapd[81273]: conn=1008 fd=21 closed (TLS negotiation failure) Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 fd=23 ACCEPT from IP=nnn.nnn.nnn.nnn:51791 (IP=0.0.0.0:389) Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=0 STARTTLS Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=0 RESULT oid= err=0 text= Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 fd=23 TLS established tls_ssf=256 ssf=256 Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=1 BIND dn="" method=128 Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=1 RESULT tag=97 err=0 text= Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=2 SRCH base="ou=xxxxx,o=xxxxx" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=[Benutzername]))" Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=2 SRCH attr=host authorizedService shadowExpire shadowFlag shadowInactive shadowLastChange shadowMax shadowMin shadowWarning uidNumber Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: search access to "ou=xxxxx,o=xxxxx" "entry" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [3] attr entry Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "ou=xxxxx,o=xxxxx", attr "entry" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to all values by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: * Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] applying read(=rscxd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] mask: read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: search access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: search access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: search access to "uid=[Benutzername],ou=xxxxx,o=xxxxx" "objectClass" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [3] attr objectClass Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "uid=[Benutzername],ou=xxxxx,o=xxxxx", attr "objectClass" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to value by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: * Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] applying read(=rscxd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] mask: read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: search access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: search access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: search access to "uid=[Benutzername],ou=xxxxx,o=xxxxx" "uid" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [3] attr uid Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "uid=[Benutzername],ou=xxxxx,o=xxxxx", attr "uid" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to value by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: * Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] applying read(=rscxd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] mask: read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: search access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: search access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access to "uid=[Benutzername],ou=xxxxx,o=xxxxx" "entry" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [3] attr entry Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "uid=[Benutzername],ou=xxxxx,o=xxxxx", attr "entry" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to all values by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: * Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] applying read(=rscxd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] mask: read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: result not in cache (shadowLastChange) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access to "uid=[Benutzername],ou=xxxxx,o=xxxxx" "shadowLastChange" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [3] attr shadowLastChange Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "uid=[Benutzername],ou=xxxxx,o=xxxxx", attr "shadowLastChange" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to value by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: * Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] applying read(=rscxd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] mask: read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: result not in cache (uidNumber) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access to "uid=[Benutzername],ou=xxxxx,o=xxxxx" "uidNumber" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [3] attr uidNumber Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "uid=[Benutzername],ou=xxxxx,o=xxxxx", attr "uidNumber" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to value by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: * Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] applying read(=rscxd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] mask: read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: result not in cache (host) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access to "uid=[Benutzername],ou=xxxxx,o=xxxxx" "host" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [3] attr host Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "uid=[Benutzername],ou=xxxxx,o=xxxxx", attr "host" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to value by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: * Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] applying read(=rscxd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] mask: read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: result not in cache (shadowMax) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access to "uid=[Benutzername],ou=xxxxx,o=xxxxx" "shadowMax" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [3] attr shadowMax Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "uid=[Benutzername],ou=xxxxx,o=xxxxx", attr "shadowMax" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to value by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: * Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] applying read(=rscxd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] mask: read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: result not in cache (shadowWarning) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access to "uid=[Benutzername],ou=xxxxx,o=xxxxx" "shadowWarning" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [3] attr shadowWarning Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "uid=[Benutzername],ou=xxxxx,o=xxxxx", attr "shadowWarning" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to value by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: * Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] applying read(=rscxd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [1] mask: read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: read access granted by read(=rscxd) Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=3 BIND dn="uid=[Benutzername],ou=xxxxx,o=xxxxx" method=128 Jul 21 15:10:11 ldap-server slapd[81273]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: result not in cache (userPassword) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: auth access to "uid=[Benutzername],ou=xxxxx,o=xxxxx" "userPassword" requested Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [1] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => dn: [2] ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] matched Jul 21 15:10:11 ldap-server slapd[81273]: => acl_get: [2] attr userPassword Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: access to entry "uid=[Benutzername],ou=xxxxx,o=xxxxx", attr "userPassword" requested Jul 21 15:10:11 ldap-server slapd[81273]: => acl_mask: to value by "", (=0) Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: uid=[Benutzername],ou=xxxxx,o=xxxxx Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: self Jul 21 15:10:11 ldap-server slapd[81273]: <= check a_dn_pat: anonymous Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [3] applying auth(=xd) (stop) Jul 21 15:10:11 ldap-server slapd[81273]: <= acl_mask: [3] mask: auth(=xd) Jul 21 15:10:11 ldap-server slapd[81273]: => slap_access_allowed: auth access granted by auth(=xd) Jul 21 15:10:11 ldap-server slapd[81273]: => access_allowed: auth access granted by auth(=xd) Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=3 BIND dn="uid=[Benutzername],ou=xxxxx,o=xxxxx" mech=SIMPLE ssf=0 Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=3 RESULT tag=97 err=0 text= Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=4 BIND anonymous mech=implicit ssf=0 Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=4 BIND dn="" method=128 Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=4 RESULT tag=97 err=0 text= Jul 21 15:10:14 ldap-server slapd[81273]: conn=1004 op=18 SEARCH RESULT tag=101 err=0 nentries=0 text= Jul 21 15:10:14 ldap-server slapd[81273]: conn=1011 op=5 UNBIND Jul 21 15:10:14 ldap-server slapd[81273]: conn=1011 fd=23 closed On 07/20/2010 10:01 PM, Dieter Kluenter wrote:
Am Tue, 20 Jul 2010 10:05:13 +0200 schrieb Ulrich Hiller<hiller@mpia-hd.mpg.de>:
Hallo, ich habe opensuse 11.3 auf x86_64 installiert und prompt Probleme. Soll heißen es ist eigentlich nur eins: ldap tut nicht. Was bedeutet 'ldap tut nicht'?
Erst mal vorneweg: Bis einschließlich opensuse 11.2 (32- und 64-bit) hat ldap einwandfrei funktioniert. Was meinst du damit, pam_ldap und nss_ldap haben funktioniert, oder OpenLDAP hat funktioniert. [...]
Zu pam_ldap und nss_ldap kann ich wenig sagen, denn das sind LDAP Clients. Versuche doch erst einmal OpenLDAP als Fehlerquelle auszuschließen. Dazu startest du slapd mit dem Parameter -d384 auf der Konsole. Sieh dir die Debugging Ausgaben an und versuche, die Fehlerquelle zu erkennen. Dann sehen wir weiter.
-Dieter
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Ulrich Hiller <hiller@mpia-hd.mpg.de> writes:
Hallo, hier ist jetzt der debug output vom ldap server mit -d384. Was mir auffällt ist (TLS negotiation failure) und später TLS established Aber sonst? Im client kommt nachwievor nss_ldap: could not search LDAP server - Server is unavailable gkr-pam: error looking up user information for: [hier steht der Benutzername] User not known to the underlying authentication module Gruß, Ulrich
================================================= Jul 21 15:09:57 ldap-server slapd[81273]: slapd starting
Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 fd=21 ACCEPT from IP=nnn.nnn.nnn.nnn:51789 (IP=0.0.0.0:389) Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 op=0 STARTTLS Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 op=0 RESULT oid= err=0 text= Jul 21 15:10:08 ldap-server slapd[81273]: conn=1007 fd=21 closed (TLS negotiation failure)
OK, ich kenne die Client-Konfiguration nicht, aber es wird ein startTLS auf Port 389 versucht, aufgrund einer Unstimmigkeit der Zertifikate, wird die startTLS Operation abgebrochen. Wenn nun in der Client-konfiguration steht: 'TLS_REQCERT try' oder 'allow', wird die Sitzung ohne TLS forgesetzt. Die Logs zeigen ja auch ein erfolgreiches Rebind als User. [...]
Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=3 BIND dn="uid=[Benutzername],ou=xxxxx,o=xxxxx" mech=SIMPLE ssf=0 Jul 21 15:10:11 ldap-server slapd[81273]: conn=1011 op=3 RESULT tag=97 err=0 text= [...]
Wenn nun nss_ldap trotzdem meldet, dass 'Server unavailable ist, dass liegt es an der nss_ldap Konfiguration. Ich vermute, dass irgendwo in /etc/ldap.conf der URI ldaps:/// steht, das bedeutet eine TLS-Session über Port 636, während startTLS eine TLS-Session über Port 389 ist. Prüfe die Zertifikate und die Konfiguration auf richtige Session-Initiierung. -Dieter -- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, nach etlichen Tagen probieren muss ich doch nochmal auf das Thema ldap über tls auf opensuse 11.3 zurückkommen. Ich habe unten nochmal die /etc/ldap.conf ohne die auskommentiereten Zeilen. Ein URI ldaps:/// gibt es da nicht. (siehe unten) So war unsere client-Konfiguration bis opensuse 11.2. Ab 11.3 ist kein Einloggen über ldap mehr möglich. Mit 'getent passwd' bekomme ich aber trotzdem alle ldap-user angezeigt. Meldung im /var/log/messages bei Einlogversuchen: nss_ldap: could not search LDAP server - Server is unavailable gkr-pam: error looking up user information for: [hier steht der Benutzername] User not known to the underlying authentication module Es sei denn, ich schalte nscd ab oder schreibe ins /etc/ldap.conf "tls_checkpeer no". Dann tut es. Was hat sich zwischen opensuse 11.2 und opensuse 11.3 geändert? Hat jemand noch Ideen? (Und: ja, ich habe schon gegoogelt. Aber das hat mich alles nicht weiter gebracht) Gruß und Dank für die bisherige Hilfe, Ulrich /etc/ldap.conf: base o=xxxxx uri ldap://unser.ldap.server ldap_version 3 port 389 bind_policy soft pam_lookup_policy yes pam_check_host_attr yes pam_password crypt ssl start_tls ldap_version 3 pam_filter objectclass=posixAccount nss_base_passwd ou=xxxxx,o=xxxxx nss_base_shadow ou=xxxxx,o=xxxxx nss_base_group ou=xxxxx,o=xxxxx tls_checkpeer yes tls_cacertdir /etc/ssl/certs On 07/21/2010 06:29 PM, Dieter Kluenter wrote:
OK, ich kenne die Client-Konfiguration nicht, aber es wird ein startTLS auf Port 389 versucht, aufgrund einer Unstimmigkeit der Zertifikate, wird die startTLS Operation abgebrochen. Wenn nun in der Client-konfiguration steht: 'TLS_REQCERT try' oder 'allow', wird die Sitzung ohne TLS forgesetzt. Die Logs zeigen ja auch ein erfolgreiches Rebind als User.
Wenn nun nss_ldap trotzdem meldet, dass 'Server unavailable ist, dass liegt es an der nss_ldap Konfiguration. Ich vermute, dass irgendwo in /etc/ldap.conf der URI ldaps:/// steht, das bedeutet eine TLS-Session über Port 636, während startTLS eine TLS-Session über Port 389 ist. Prüfe die Zertifikate und die Konfiguration auf richtige Session-Initiierung.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Ulrich Hiller <hiller@mpia-hd.mpg.de> writes:
Hallo, nach etlichen Tagen probieren muss ich doch nochmal auf das Thema ldap über tls auf opensuse 11.3 zurückkommen. Ich habe unten nochmal die /etc/ldap.conf ohne die auskommentiereten Zeilen. Ein URI ldaps:/// gibt es da nicht. (siehe unten) So war unsere client-Konfiguration bis opensuse 11.2. Ab 11.3 ist kein Einloggen über ldap mehr möglich. Mit 'getent passwd' bekomme ich aber trotzdem alle ldap-user angezeigt. Meldung im /var/log/messages bei Einlogversuchen:
nss_ldap: could not search LDAP server - Server is unavailable gkr-pam: error looking up user information for: [hier steht der Benutzername] User not known to the underlying authentication module
Es sei denn, ich schalte nscd ab oder schreibe ins /etc/ldap.conf "tls_checkpeer no". Dann tut es.
Was hat sich zwischen opensuse 11.2 und opensuse 11.3 geändert?
Hat jemand noch Ideen? (Und: ja, ich habe schon gegoogelt. Aber das hat mich alles nicht weiter gebracht)
Gruß und Dank für die bisherige Hilfe, Ulrich
/etc/ldap.conf:
base o=xxxxx uri ldap://unser.ldap.server ldap_version 3 port 389 bind_policy soft pam_lookup_policy yes pam_check_host_attr yes pam_password crypt ssl start_tls ldap_version 3 pam_filter objectclass=posixAccount nss_base_passwd ou=xxxxx,o=xxxxx nss_base_shadow ou=xxxxx,o=xxxxx nss_base_group ou=xxxxx,o=xxxxx tls_checkpeer yes tls_cacertdir /etc/ssl/certs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Das Problem wird tls_cacertdir sein. Falls du eine eigene CA erstellt hast, nimm lieber tls_cacertfile /pfad/auf/cafile, zum Thema tls_checkpeer solltest du mal die TLS Parameter der slapd.conf mailen. Weiterhin solltest du prüfen, ob der CN im Subject des Serverzertifikats dem vollständigen Hostnamen entspricht. openssl x509 -in <certificate>.pem -text
-Dieter -- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
wir haben's mit tls_certfile und mit tls_cert (wie es in manchen Dokumentationen steht) probiert. Ohne Erfolg. die TLS-spezifischen Dinge im slapd.conf sind: TLSCACertificateFile /PFAD/xxxxxxx.pem TLSCertificateFile /PFAD/xxxxxxxxxx.pem TLSCertificateKeyFile /PFAD/xxxxxxxxx.key unten kommt nochmal das ganze slapd.conf Ja, der CN im Subject des Serverzertifikats entspricht dem vollständigen Hostnamen Nach meiner unbedeutenden Ansicht liegt das Problem darin wie der nscd mit dem tls umgeht. Denn wenn ich nscd abschalte, tut es. Oder leige ich falsch? Gruß, ulrich slapd.conf: include /PFAD/core.schema include /PFAD/cosine.schema include /PFAD/inetorgperson.schema include /PFAD/nis.schema include /PFAD/qmail.schema include /PFAD/ibm-auxAccount.ldif include /PFAD/samba.schema include /PFAD/freeradius.schema include /PFAD/quota.schema TLSCACertificateFile /PFAD/xxxxxxx.pem TLSCertificateFile /PFAD/xxxxxxxxxx.pem TLSCertificateKeyFile /PFAD/xxxxxxxxx.key allow bind_v2 password-hash {**********} pidfile /PFAD/slapd.pid argsfile /PFAD/slapd.args modulepath /PFAD/openldap moduleload back_bdb access to dn.subtree="ou=xxxxx,o=xxxxx" attrs=userPassword by anonymous auth by * none access to dn.subtree="ou=xxxxx,o=xxxxx" attrs=userPassword,sambaNTPassword,sambaLMPassword by dn="uid=xxxxxx,ou=xxxxx,o=xxxxx" read by self write by anonymous auth by * none access to * by * read Loglevel 64 database bdb suffix "o=xxxxx" rootdn "cn=xxxxx,o=xxxxx" rootpw ************************** directory /PFAD/xxxxx index uniqueMember pres index objectClass eq index uid,cn,uidNumber,gidNumber,mail,memberUid,member,mailAlternateAddress,accountStatus eq updatedn "cn=xxxxx,o=xxxxx" On 07/29/2010 11:59 AM, Dieter Kluenter wrote:
Das Problem wird tls_cacertdir sein. Falls du eine eigene CA erstellt hast, nimm lieber tls_cacertfile /pfad/auf/cafile, zum Thema tls_checkpeer solltest du mal die TLS Parameter der slapd.conf mailen. Weiterhin solltest du prüfen, ob der CN im Subject des Serverzertifikats dem vollständigen Hostnamen entspricht. openssl x509 -in<certificate>.pem -text
-Dieter
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Ulrich Hiller <hiller@mpia-hd.mpg.de> writes:
wir haben's mit tls_certfile und mit tls_cert (wie es in manchen Dokumentationen steht) probiert. Ohne Erfolg.
Das Argument pro oder contra tls_certdir ist, ob das CA certificate auch als Hashwert im ssl Verzeichnis vorhanden ist, häufig wird bei privaten CA's vergesssen c_hash aufzurufen.
die TLS-spezifischen Dinge im slapd.conf sind:
TLSCACertificateFile /PFAD/xxxxxxx.pem TLSCertificateFile /PFAD/xxxxxxxxxx.pem TLSCertificateKeyFile /PFAD/xxxxxxxxx.key
unten kommt nochmal das ganze slapd.conf
Ja, der CN im Subject des Serverzertifikats entspricht dem vollständigen Hostnamen
Nach meiner unbedeutenden Ansicht liegt das Problem darin wie der nscd mit dem tls umgeht. Denn wenn ich nscd abschalte, tut es. Oder leige ich falsch?
Der Name Service Cache Daemon stellt keine Verbindung zu LDAP her sondern cached nur die Ergebnisse. Letztlich sind es die Pam-Module und C-Funktionen, die nsswitch.conf auswerten. Aber prinzipiell sollte nscd abgeschaltet werden, wenn nsswitch.conf auf LDAP verweist. Es macht keinen Sinn, alte Daten, die ja teilweise 10 Minuten alt sind, zu verwenden. Ich würde slapd mal im Debugging-Modus 3 starten, also 'slapd -h ldap:/// -F /etc/openldap/slapd.d -o ldap -g ldap -d3' Dann sieh dir mal die ganzen tls Meldungen an.
access to dn.subtree="ou=xxxxx,o=xxxxx" attrs=userPassword by anonymous auth by * none
access to dn.subtree="ou=xxxxx,o=xxxxx" attrs=userPassword,sambaNTPassword,sambaLMPassword by dn="uid=xxxxxx,ou=xxxxx,o=xxxxx" read by self write by anonymous auth by * none
Dies Access-Regeln sind zwar nicht relevant für das nsswitch Problem, aber trotzdem können sie auf andere Weise zu Problemen führen, denn es wird nur der erste Regelsatz ausgewertet, das Passwort kann also nicht verändert werden. -Dieter -- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 07/29/2010 02:34 PM, Dieter Kluenter wrote:
Aber prinzipiell sollte nscd abgeschaltet werden, wenn nsswitch.conf auf LDAP verweist. Es macht keinen Sinn, alte Daten, die ja teilweise 10 Minuten alt sind, zu verwenden.
nunja, aber wenn ich so Befehle wie 'ls -l' aufrufe, in denen uid's in Namen übersetzt werden, bekomme ich Riesen-Netzwerktraffic, wenn der client nicht auf den Cache zurückgreifen kann. Oder habe ich was falsch verstanden? Gruß, ulrich -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Ulrich Hiller <hiller@mpia-hd.mpg.de> writes:
On 07/29/2010 02:34 PM, Dieter Kluenter wrote:
Aber prinzipiell sollte nscd abgeschaltet werden, wenn nsswitch.conf auf LDAP verweist. Es macht keinen Sinn, alte Daten, die ja teilweise 10 Minuten alt sind, zu verwenden.
nunja, aber wenn ich so Befehle wie 'ls -l' aufrufe, in denen uid's in Namen übersetzt werden, bekomme ich Riesen-Netzwerktraffic, wenn der client nicht auf den Cache zurückgreifen kann. Oder habe ich was falsch verstanden?
Sicher bekommst du Netzwerktraffik, aber wenn du in slapd.conf loglevel 0 setzt, ist slapd immer noch schneller als nscd, dazu bekommst du immer aktuelle Daten. -Dieter -- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, ich habe jetzt zumindest die Ursache des Problems gefunden: unscd Auf der netinstall CD ist unscd 0.45.5.1 Damit tut ldap über TLS. Sobald ich einen online-update mache (mache ich immer nach Neuinstallation) tut es nicht mehr mit den im thread beschriebenen Fehlermeldungen. Nach dem update ist unscd 0.45.6.1.1 drin. Den genauen Grund habe ich noch nicht raus, auch nicht, warum nscd bei mir nicht tat (habe möglicherweise da einen Fehler gemacht), aber zumindest kann ich wieder mit 11.3 arbeiten. Also: man darf alles updaten, außer unscd. Gruß, Ulrich -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ulrich Hiller [02.08.2010 11:36]:
Hallo, ich habe jetzt zumindest die Ursache des Problems gefunden: unscd Auf der netinstall CD ist unscd 0.45.5.1 Damit tut ldap über TLS. Sobald ich einen online-update mache (mache ich immer nach Neuinstallation) tut es nicht mehr mit den im thread beschriebenen Fehlermeldungen. Nach dem update ist unscd 0.45.6.1.1 drin. Den genauen Grund habe ich noch nicht raus, auch nicht, warum nscd bei mir nicht tat (habe möglicherweise da einen Fehler gemacht), aber zumindest kann ich wieder mit 11.3 arbeiten. Also: man darf alles updaten, außer unscd.
Bei mir ist unscd-0.45-6.1.1.x86_64 installiert, und ich melde mich jeden Morgen am LDAP an. Was mache ich da flscah? Gruß Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxWlXIACgkQk33Krq8b42PrUgCfVVwg1PH5Jvk2SvLCOowB4IuB fG0An2oMbNSIXiPpNB5FqUrZ7aws/FlN =9rs9 -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 08/02/2010 11:52 AM, Werner Flamme wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ulrich Hiller [02.08.2010 11:36]:
Hallo, ich habe jetzt zumindest die Ursache des Problems gefunden: unscd Auf der netinstall CD ist unscd 0.45.5.1 Damit tut ldap über TLS. Sobald ich einen online-update mache (mache ich immer nach Neuinstallation) tut es nicht mehr mit den im thread beschriebenen Fehlermeldungen. Nach dem update ist unscd 0.45.6.1.1 drin. Den genauen Grund habe ich noch nicht raus, auch nicht, warum nscd bei mir nicht tat (habe möglicherweise da einen Fehler gemacht), aber zumindest kann ich wieder mit 11.3 arbeiten. Also: man darf alles updaten, außer unscd. Bei mir ist unscd-0.45-6.1.1.x86_64 installiert, und ich melde mich jeden Morgen am LDAP an. Was mache ich da flscah?
die Frage ist wohl eher, was ich falsch mache. ;-) Machst Du ldap über tls? Hast Du tls_checkpeer yes gesetzt? Wenn ja, würde mich mal Deine weitere Konfiguration interessieren. Speziell ldap.conf und nscd.conf. Gruß, ulrich -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ulrich Hiller [02.08.2010 12:00]:
On 08/02/2010 11:52 AM, Werner Flamme wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ulrich Hiller [02.08.2010 11:36]:
Hallo, ich habe jetzt zumindest die Ursache des Problems gefunden: unscd Auf der netinstall CD ist unscd 0.45.5.1 Damit tut ldap über TLS. Sobald ich einen online-update mache (mache ich immer nach Neuinstallation) tut es nicht mehr mit den im thread beschriebenen Fehlermeldungen. Nach dem update ist unscd 0.45.6.1.1 drin. Den genauen Grund habe ich noch nicht raus, auch nicht, warum nscd bei mir nicht tat (habe möglicherweise da einen Fehler gemacht), aber zumindest kann ich wieder mit 11.3 arbeiten. Also: man darf alles updaten, außer unscd. Bei mir ist unscd-0.45-6.1.1.x86_64 installiert, und ich melde mich jeden Morgen am LDAP an. Was mache ich da flscah?
die Frage ist wohl eher, was ich falsch mache. ;-) Machst Du ldap über tls? Hast Du tls_checkpeer yes gesetzt? Wenn ja, würde mich mal Deine weitere Konfiguration interessieren. Speziell ldap.conf und nscd.conf.
Ha - nein, mache ich nicht. ldaps wird bei uns nur für die VoIP-Anlage benutzt. Im Zweifel wird eher ldaps die Ursache sein. Habe ich allerdings in diesem Thread (Message-id: <4C46F49E.90705@ufz.de>) schonmal vermutet. Meine nscd.con Auslieferungszustand sein, da habe ich nicht dran rumgefingert. Die ist allerdings kürzer als die von Dir gepostete: enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes und das jeweils für passwd, group und hosts. In der ldap.conf habe ich hosts, base und nss_base_passwd eingetragen. ssl steht auf no, tls_checkpeer ebenfalls. Den Eintrag nss_initgroups_ignoreusers root,ldap habe ich bei Dir nicht gefunden, sollte aber eigentlich auch keine Rolle spielen ;-) Dafür habe ich kein pam_check_host_attr aktiv. Gruß Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEUEARECAAYFAkxWmkoACgkQk33Krq8b42P0bwCTBLtzHcMADJwxDOkeFdnxAy4z rwCfa4fUYBIBamJ+XK5GTQMd3ETB4ow= =te6R -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
mit "tls_checkpeer no" im ldap.conf tut unscd-0.45.6.1.1 beim mir ebenfalls Aber wir wollen das auf yes haben. Gruß, ulrich On 08/02/2010 12:13 PM, Werner Flamme wrote:
Ha - nein, mache ich nicht. ldaps wird bei uns nur für die VoIP-Anlage benutzt. Im Zweifel wird eher ldaps die Ursache sein. Habe ich allerdings in diesem Thread (Message-id:<4C46F49E.90705@ufz.de>) schonmal vermutet.
Meine nscd.con Auslieferungszustand sein, da habe ich nicht dran rumgefingert. Die ist allerdings kürzer als die von Dir gepostete:
enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes
und das jeweils für passwd, group und hosts.
In der ldap.conf habe ich hosts, base und nss_base_passwd eingetragen. ssl steht auf no, tls_checkpeer ebenfalls.
Den Eintrag nss_initgroups_ignoreusers root,ldap habe ich bei Dir nicht gefunden, sollte aber eigentlich auch keine Rolle spielen ;-) Dafür habe ich kein pam_check_host_attr aktiv.
Gruß Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEUEARECAAYFAkxWmkoACgkQk33Krq8b42P0bwCTBLtzHcMADJwxDOkeFdnxAy4z rwCfa4fUYBIBamJ+XK5GTQMd3ETB4ow= =te6R -----END PGP SIGNATURE-----
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, der Thread ist schon etwas älter, aber es hat sich hier was Neues ergeben. Zur Erinnerung: Seit opensuse 11.3 hatten wir Probleme mit ldap und der TLS-Prüfung. Am ldap-Server registrierte Benutzer konnten sich nicht mehr am opensuse-11.3-client einloggen (bis 11.2 ging es noch). Fehlermeldung:
nss_ldap: could not search LDAP server - Server is unavailable gkr-pam: error looking up user information for: [hier steht der Benutzername] User not known to the underlying authentication module
Abhilfe: 1. TLS-Prüfung im ldap.conf abschalten mit "tls_checkpeer no" 2. nscd abschalten oder zumindest im nscd.conf "enable-cache passwd no" Beides sind sehr unbefriedigende Lösungen für uns. Jetzt kommt die wahrscheinliche Ursache: Es ist mit AppArmor verbunden, bzw. AppArmor verhindert den nscd-Zugang zum erforderlichen Zertifikat (weiß nicht wie ich das besser formulieren soll :-/ ) Jetzt also die Lösung, mit der ich leben kann: 1.apparmor abschalten (rcapparmor stop) und beim boot gar nicht erst starten oder besser 2. folgende Zeilen ins /etc/apparmor.d/abstractions/ssl_certs: /usr/share/ca-certificates/ r, /usr/share/ca-certificates/* r, /usr/share/ca-certificates/mozilla/ r, /usr/share/ca-certificates/mozilla/* r, /etc/openldap r, /etc/openldap/cacerts r, /etc/openldap/cacerts/* r, und 'rcapparmor restart'. Gruß, ulrich -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Tue, Aug 24, 2010 at 09:46:03AM +0200, Ulrich Hiller wrote:
Hallo, der Thread ist schon etwas älter, aber es hat sich hier was Neues ergeben. Zur Erinnerung: Seit opensuse 11.3 hatten wir Probleme mit ldap und der TLS-Prüfung. Am ldap-Server registrierte Benutzer konnten sich nicht mehr am opensuse-11.3-client einloggen (bis 11.2 ging es noch). Fehlermeldung:
nss_ldap: could not search LDAP server - Server is unavailable gkr-pam: error looking up user information for: [hier steht der Benutzername] User not known to the underlying authentication module
Abhilfe: 1. TLS-Prüfung im ldap.conf abschalten mit "tls_checkpeer no" 2. nscd abschalten oder zumindest im nscd.conf "enable-cache passwd no"
Beides sind sehr unbefriedigende Lösungen für uns. Jetzt kommt die wahrscheinliche Ursache: Es ist mit AppArmor verbunden, bzw. AppArmor verhindert den nscd-Zugang zum erforderlichen Zertifikat (weiß nicht wie ich das besser formulieren soll :-/ ) Jetzt also die Lösung, mit der ich leben kann: 1.apparmor abschalten (rcapparmor stop) und beim boot gar nicht erst starten oder besser 2. folgende Zeilen ins /etc/apparmor.d/abstractions/ssl_certs:
/usr/share/ca-certificates/ r, /usr/share/ca-certificates/* r, /usr/share/ca-certificates/mozilla/ r, /usr/share/ca-certificates/mozilla/* r, /etc/openldap r, /etc/openldap/cacerts r, /etc/openldap/cacerts/* r,
und 'rcapparmor restart'.
Mach bitte dazu einen Bug mit Referenz auf http://lists.opensuse.org/opensuse-de/2010-08/msg01085.html auf. Das gehört entweder in den jeweiligen Paketen der betroffenen Komponenten oder in einem der AppArmor-Pakete "gefixt". Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Tue, Aug 24, 2010 at 04:32:18PM +0200, Lars Müller wrote: [ 8< ]
Mach bitte dazu einen Bug mit Referenz auf http://lists.opensuse.org/opensuse-de/2010-08/msg01085.html auf.
Das gehört entweder in den jeweiligen Paketen der betroffenen Komponenten oder in einem der AppArmor-Pakete "gefixt".
https://bugzilla.novell.com/show_bug.cgi?id=623886 Auch in 2010 gilt: Nie und nimmer bug IDs referenzieren. Nicht auf Listen und nicht im change log eines Paketes. Zuviel Redundanz führt nur zu mehr Verwirrung. ;) Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
participants (4)
-
Dieter Kluenter -
Lars Müller -
Ulrich Hiller -
Werner Flamme