ubuntuusers.de

OpenLDAP als Authentifizierungsserver

Status: Ungelöst | Ubuntu-Version: Ubuntu 7.10 (Gutsy Gibbon)
Antworten |

MirkoMachine

Anmeldungsdatum:
17. Dezember 2007

Beiträge: Zähle...

Wohnort: Hamburg

Hallo,

ich habe hier ein neu-installiertes Ubuntu 7.10 AMD64, auf dem ich den OpenLDAP-Server bereits eingerichtet habe.
Im laufenden Betrieb kann ich mich auch als Nutzer per LDAP anmelden, aber sobald ich das System mit den neuen Einstellungen boote, bleibt es hängen.

hier mal ein Nutzer per "ldapsearch -x":

# ck, Users, mknet
dn: cn=ck,ou=Users,dc=mknet
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
cn: ck
sn: Clark
uid: ck
uidNumber: 10001
loginShell: /bin/bash
gidNumber: 1000
homeDirectory: /home/ck

getent passwd liefert folgendes:

ck:*:10001:1000:ck:/home/ck:/bin/bash


(hat der Stern * etwas zu bedeuten (kein x wie bei den anderen))?

und hier die Meldung aus /var/log/auth.log (ein Test mit falschem PW, dann eine gültige Anmeldung und danach zurück zum User (per files, nicht per ldap):

Dec 17 21:23:23 MirkoWork su[6552]: pam_ldap: error trying to bind as user "cn=ck,ou=Users,dc=mknet" (Invalid credentials)
Dec 17 21:23:24 MirkoWork su[6552]: pam_unix(su:auth): authentication failure; logname=mk uid=1000 euid=0 tty=pts/1 ruser=mk rhost=  user=ck
Dec 17 21:23:25 MirkoWork su[6552]: pam_authenticate: Fehler bei Authentifizierung
Dec 17 21:23:25 MirkoWork su[6552]: FAILED su for ck by mk
Dec 17 21:23:25 MirkoWork su[6552]: - pts/1 mk:ck
Dec 17 21:23:34 MirkoWork su[6553]: Successful su for ck by mk
Dec 17 21:23:34 MirkoWork su[6553]: + pts/1 mk:ck
Dec 17 21:23:34 MirkoWork su[6553]: pam_unix(su:session): session opened for user ck by mk(uid=1000)
Dec 17 21:24:05 MirkoWork su[6570]: Successful su for mk by ck
Dec 17 21:24:05 MirkoWork su[6570]: + pts/1 ck:mk
Dec 17 21:24:05 MirkoWork su[6570]: pam_unix(su:session): session opened for user mk by mk(uid=10001)


auch eine Anmeldung mit beiden Nutzern (ck und mk) per ssh von einem anderen Rechner (Putty unter WinXP) funktioniert.

Wenn ich jetzt allerdings neustarte, bleibt er während des Bootvorgangs hängen... reagiert dann aber noch auf ein CTRL-ALT-DEL, so dass er sauber runterfährt und rebootet.

Ich poste jetzt mal die wichtigsten Config-Dateien:

/etc/pam.d/common-auth:

auth    sufficient      pam_ldap.so
auth    required        pam_unix.so use_first_pass nullok_secure

/etc/pam.d/common-account:

account sufficient      pam_ldap.so
account required        pam_unix.so use_first_pass

/etc/pam.d/common-password:

password   sufficient pam_ldap.so
password   required   pam_unix.so use_first_pass nullok obscure min=4 max=8 md5

/etc/pam.d/common-session:

session required        pam_unix.so
session optional        pam_foreground.so


(diese 4 habe ich 1:1 aus dem wiki übernommen (LDAP_Client_Authentifizierung ))

/etc/ldap.conf:

host 127.0.0.1
base dc=mknet


weiterhin ist hier der "rootbinddn" eingetragen sowie das Password in /etc/ldap.secret

die vier Dateien /etc/pam_ldap.conf, /etc/pam_ldap.secret, /etc/libnss-ldap.conf und /etc/libnss-ldap.secret aus dem Wiki sind bei mir nicht vorhanden, aber der Artikel behandelt Ubuntu 7.10 ja auch nicht offiziell... Ich gehe mal davon aus, dass diese Dienste die /etc/ldap.con nutzen.

/etc/nsswitch.conf:

#passwd:         compat
#group:          compat
#shadow:         compat

passwd:         files ldap
group:          files ldap
shadow:         files ldap

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Wie gesagt, mit dieser Konfiguration funktioniert es im laufenden Betrieb, aber ein Neustart des Systems schlägt fehl... Ich poste jetzt mal die (sehr dürftigen) Logs:
(ich habe das System um 21:24 Uhr runtergefahren, und dann um 21:31 Uhr neu gestartet und abgewartet bis 21:38 Uhr. Danach habe ich das System per BootCD "gerettet" und um 21:46 Uhr neu gestartet (ohne LDAP))

/var/log/messages:

...
Dec 17 21:24:38 MirkoWork exiting on signal 15
Dec 17 21:31:54 MirkoWork syslogd 1.4.1#21ubuntu3: restart.
Dec 17 21:38:17 MirkoWork exiting on signal 15
Dec 17 21:46:10 MirkoWork syslogd 1.4.1#21ubuntu3: restart.
Dec 17 21:46:10 MirkoWork kernel: Inspecting /boot/System.map-2.6.22-14-generic
...

/var/log/syslog:

...
Dec 17 21:24:35 MirkoWork init: tty4 main process (4457) killed by TERM signal
Dec 17 21:24:35 MirkoWork init: tty5 main process (4458) killed by TERM signal
Dec 17 21:24:35 MirkoWork init: tty2 main process (4460) killed by TERM signal
Dec 17 21:24:35 MirkoWork init: tty3 main process (4463) killed by TERM signal
Dec 17 21:24:35 MirkoWork init: tty1 main process (4464) killed by TERM signal
Dec 17 21:24:35 MirkoWork init: tty6 main process (4465) killed by TERM signal
Dec 17 21:24:36 MirkoWork avahi-daemon[5268]: Got SIGTERM, quitting.
Dec 17 21:24:36 MirkoWork avahi-daemon[5268]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.43.
Dec 17 21:24:38 MirkoWork exiting on signal 15
Dec 17 21:31:54 MirkoWork syslogd 1.4.1#21ubuntu3: restart.
Dec 17 21:38:17 MirkoWork exiting on signal 15
Dec 17 21:46:10 MirkoWork syslogd 1.4.1#21ubuntu3: restart.
Dec 17 21:46:10 MirkoWork kernel: Inspecting /boot/System.map-2.6.22-14-generic
Dec 17 21:46:10 MirkoWork kernel: Loaded 26084 symbols from /boot/System.map-2.6.22-14-generic.
...

Irgendeine Idee, wo ich einen Fehler gemacht habe? oder zumindest, wo ich nachschauen sollte, da ja nicht mal geloggt wird?!?

Gruß und Danke für die Hilfe
Mirko

Edit:
Beim Systemstart wechselt Ubuntu vom grafischen Bootscreen auf die Konsole, kurz bevor er anhält... hier mal die letzten Ausgaben:

* Configuring network interfaces...   [OK]
* Loading ACPI modules...             [OK]
* Starting ACPI services...           [OK]
* Starting system log daemon...       [OK]
* Doing Wacom setup...                [OK]
* Starting kernel log daemon...

tekknokrat

Anmeldungsdatum:
4. Mai 2007

Beiträge: 117

/etc/ldap.conf:
Code:
host 127.0.0.1
base dc=mknet

Die von dir genannte ist die für die Konfiguration von pam_ldap nss_ldap.

Da fehlt imo der rootbinddn.

→ rootbinddn cn=admin,dc=th-domain,dc=lan

Auserdem muss dann auch die /etc/ldap.secret mit dem Password bestehen.

Frage arbeitest du mit den Standard organisational Units?

Dein ldap Server an sich läuft ja.
Ich hatte das Problem mit dem aufhängen vor dem login auch einmal - aber da war noch so viel andere Grütze in den configs...

find das mit der auth-client-config noch ganz spannend:

http://ubuntuforums.org/showthread.php?t=597056&highlight=ldap

Das wiki ist glaub ich überholungsbedürftig...

MirkoMachine

(Themenstarter)

Anmeldungsdatum:
17. Dezember 2007

Beiträge: 10

Wohnort: Hamburg

tekknokrat hat geschrieben:

/etc/ldap.conf:
Code:
host 127.0.0.1
base dc=mknet

Die von dir genannte ist die für die Konfiguration von pam_ldap nss_ldap.

Da fehlt imo der rootbinddn.

→ rootbinddn cn=admin,dc=th-domain,dc=lan

Auserdem muss dann auch die /etc/ldap.secret mit dem Password bestehen.

MirkoMachine hat geschrieben:

/etc/ldap.conf:

host 127.0.0.1
base dc=mknet

weiterhin ist hier der "rootbinddn" eingetragen sowie das Password in /etc/ldap.secret

wie schon geschrieben: der rootbinddn-Eintrag sowie das Kennwort in ldap.secret bestehen. Hast Du wohl überlesen...
Das kann folglich nicht das Problem sein.

Aber ist es denn wirklich so, dass es jetzt die Dateien /etc/pam_ldap.conf, /etc/pam_ldap.secret, /etc/libnss-ldap.conf und /etc/libnss-ldap.secret nicht mehr gibt? Werden pam_ldap und nss_ldapdie jetzt von /etc/ldap.conf bedient?
Oder meintest Du das mit deiner Aussage
tekknokrat hat geschrieben:

Die von dir genannte ist die für die Konfiguration von pam_ldap nss_ldap.

?

Was mich jedoch am meisten verblüfft ist die Tatsache, dass nicht mal ein Logging stattfindet... d.h. dass er schon vorher hängen bleibt!
Wenn ich den Rechner dann aber per STRG-ALT-DEL neu starte, meldet er, dass viele Dienste gestoppt werden, u.a. OpenLDAP. Dieses läuft folglich schon beim "Hängenbleiben".

Hat noch jemand einen Ansatz für mich?

Gruß
Mirko

tekknokrat

Anmeldungsdatum:
4. Mai 2007

Beiträge: 117

sorry hab ich übersehen, ich hatte nur oberflächlich die config dateien verglichen.

Ja es ist wirklich so dass nur noch die /etc/ldap.conf als zentrale konfiguration für nss_ldap, pam_ldap steht.
siehe auch

less /usr/share/doc/libpam_ldap/README.Debian

wichtig ist dass in der nsswitch.conf erst file dann ldap steht.

ausserdem habe ich diese daten in meiner ldap.conf:

ssl off
suffix dc=th-domain,dc=lan
uri ldap://localhost
pam_password exop

nss_initgroups_ignoreusers root,openldap
bind_policy soft
bind_timelimit 15

rootbinddn cn=admin,dc=th-domain,dc=lan

ldap_version 3
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberuid
nss_base_passwd ou=peoples,dc=th-domain,dc=lan
nss_base_shadow ou=peoples,dc=th-domain,dc=lan
nss_base_group ou=groups,dc=th-domain,dc=lan
nss_base_hosts ou=hosts,dc=th-domain,dc=lan

das auth-client-config-profil:

cat /etc/auth-client-config/profile.d/open_ldap

[open_ldap]
nss_passwd=passwd: files ldap
nss_group=group: files ldap
nss_shadow=shadow: files ldap
pam_auth=auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
pam_account=account sufficient pam_unix.so
account sufficient pam_ldap.so
account required pam_deny.so

pam_password=password sufficient pam_ldap.so
password required pam_unix.so nullok md5 shadow
password required pam_deny.so

pam_session=session required pam_limits.so
session required pam_mkhomedir.so skel=/etc/skel/
session required pam_unix.so
session optional pam_ldap.so

jke

Anmeldungsdatum:
28. Dezember 2007

Beiträge: Zähle...

Hallo Mirko,

hab genau das gleiche Problem mit LDAP. Hast du eine Lösung gefunden?

Danke, Jens

MirkoMachine

(Themenstarter)

Anmeldungsdatum:
17. Dezember 2007

Beiträge: 10

Wohnort: Hamburg

Hi Jens,

ich habe es gestern hinbekommen 😉

folgendes habe ich angepasst:

# Reconnect policy: hard (default) will retry connecting to
# the software with exponential backoff, soft will fail
# immediately.
bind_policy soft

scheinbar war der slapd zu dem Zeitpunkt, als er hängenblieb, noch nicht gestartet, so dass er vergeblich versucht hat sich zu "binden" und zu authentifizieren.

Gruß
Mirko

Baobab

Anmeldungsdatum:
5. Januar 2008

Beiträge: Zähle...

Wohnort: Innsbruck

Hallo Mirko,

du hast das Problem ja schon elegant gelöst. ☺ 😀

Hier ein Nachtrag, denn auch mich hat das einige Zeit gekostet, da sich der "nsswitch" - Prozess meiner Meinung nach nicht so verhält, wie es die Manpages beschreiben ist!

Auch bei mir ist der Computer bei Installation einer ldap - Authentifizierung, gleich wie bei dir, mit nachfolgender Meldung beim Booten hängen geblieben.

 * Configuring network interfaces...   [OK] 
 * Loading ACPI modules...             [OK] 
 * Starting ACPI services...           [OK] 
 * Starting system log daemon...       [OK] 
 * Doing Wacom setup...                [OK] 
 * Starting kernel log daemon...

habe dann im Startskript /etc/init.d/klogd für den Kernel-log-daemon nachgesehen und dort ein

chown klog:klog /var/run/klogd 


entdeckt.
chown scheint also beim Ändern des Users hängen zu bleiben, und zwar beim Aufruf des ldap - Verzeichnisses!!
Mit einer nsswitch.conf mit

 passwd:         files
 group:          files
 shadow:         files


hat das Booten nämlich problemlos funktioniert. ldap war dann natürlich zum anmelden nicht verfügbar.

Mit einer angepassten nsswitch.conf wie folgt, hat es dann funktioniert:

 passwd:         files [UNAVAIL=return] ldap
 group:          files [UNAVAIL=return] ldap
 shadow:         files [UNAVAIL=return] ldap

Für mich ist das insofern unlogisch, weil bei einer erfolgreichen Suche in den "files" der Suchprozess mit "SUCCESS=RETURN" eigentlich laut Manpages abgebrochen werden sollte!! ☹
Besonders ungut auch, dass es mit Ubuntu 6.10 noch ganz nach Beschreibung funktioniert hat!

Möglicherweise hat sich die "bind_policy" im jetzt neu bennannten File /etc/ldap.conf (vormals libnss-ldap.conf) geändert?

lg
Reinhard

PS:
Noch eine Bemerkung zum Eintrag:
rootbinddn cn=...

Bei mir funktioniert die ldap - Authentifizierung auch ohne diese Option. (#rootbinddn auskommentiert)
Hat meiner Meinung nach den Vorteil, dass kein Passwort offen in einem File "herumliegt".

DerSigi

Anmeldungsdatum:
23. August 2005

Beiträge: 61

Hi,

ich hatte das gleiche Problem. Ich habe dann den Runlevel 2 so abgeändert das slapd vor klogd gestartet wird.

sudo mv /etc/rc2.d/S19slapd /etc/rc2.d/S09slapd

Zusätzlich hatte ich noch 'upstart' gegen 'sysvinit' ausgetauscht

sudo apt-get install sysvinit


was aber warscheinlich gar nicht notwendig gewesen wäre.

Grüße

Sigi

Antworten |