Re: Probleme nach cipux-Installation
Hallo Hans-Dietrich,
On 12/12/2010 07:55 PM, Hans-Dietrich Kirmse wrote:
ich wollte nur helfen, indem ich dass, was du angegeben hast, für Alfred
aufbereitet habe. - dabei können Fehler passieren. Trotzdem, wenn
praktisch keiner versucht zu helfen, dann ist keinem geholfen.
Ich habe auf die Schnelle keinen Fehler in Deinen Ausführungen gesehen
und es hat Alfred sicher geholfen. Ausprobiert habe ich es nicht.
Am 12.12.2010 18:41, schrieb Erik Auerswald:
On 12/12/2010 05:56 PM, Hans-Dietrich Kirmse wrote:
Hallo Alfred,
wie ich schon geschrieben habe, habe ich kein Skolelinux. Ich war
einfach davon ausgegangen, dass die Antwort von Erik korrekt ist.
So kann man jedenfalls das Problem falscher Credentials lösen.
schön wär's, wenn das Problem gelöst wäre.
>
ich war/bin davon ausgegangen, dass für Samba üblicherweise das
LDAP-Adminpasswort verwendet wird.
Der verwendete Account steht in der smb.conf. Samba merkt sich das
zugehörige Passwort in der Datei secrets.tdb. Der Inhalt davon wird mit
smbpasswd -w gesetzt. Das hat erstmal nichts mit Skolelinux zu tun,
sondern nur mit Samba und LDAP.
Dass man das hier nicht so macht -
etwas bessere Doku von Skolelinux hätte das Missverständnis gar nicht
erst aufkommen lassen. Das diese Variante etwas sicherer ist - okay.
Ich bedanke mich jedenfalls bei dir, dass ich Tjener besser durchschaue
- nur hilft das Alfred nicht wirklich weiter.
Am 12.12.2010 16:03, schrieb Scheiber Alfred:
Während der Installation gibt es eine Zeile:
smbpasswd -a -U cipadmin -w $cipadminpw
^^^
Aha! Hier wird das Samba LDAP Account Passwort auf das von cipadmin
gesetzt. Dieser Teil der CipUX Anleitung sollte eher wie folgt aussehen:
*** ACHTUNG! UNGETESTET! VERWENDUNG AUF EIGENE GEFAHR! ***
# printf "$cipadminpw\n$cipadminpw\n" | smbpasswd -s -a cipadmin
Jedenfalls dann, wenn der cipadmin einen Samba Account bekommen soll.
das funktioniert problemlos, aber der gleiche Befehl nachher (nach der
Installation von CatWeb abgesetzt bringt die bereits zitierte
Fehlermeldung:
failed to bind to server ldap://ldap with
dn="cn=smbadmin,ou=People,dc=skole,dc=skolelinux,dc=no" Error: Invalid
credentials
(unknown)
Connection to LDAP server failed for the 1 try!
So, durch den Aufruf von "smbpasswd -w $cipadminpw" hat man Samba ein
falsches Passwort zum Zugriff auf
"cn=smbadmin,ou=People,dc=skole,dc=skolelinux,dc=no" genannt.
Das hört sich für mich danach an, als ob genau da das Problem zu suchen
wäre. Um dies zu bestätigen oder zu widerlegen kann man Skolelinux neu
aufsetzen, die CipUX Installation OHNE die smbpasswd Zeile durchführen
und schauen, ob Samba verwendet werden kann (mit neuen Accounts).
[Achtung! In diesem Fall ist cipadmin kein Account, mit dem ein Rechner
in die Domäne aufgenommen werden kann!]
also kann smbadmin nicht connecten - es ist ein Problem mit den
Passwörtern(?) von 'smbadmin'.
Oder vielleicht ein Problem mit LDAP an sich.
möglich, aber dann sollten die Experten ihre Beiträge bringen, möglichst
so, dass die Nutzer das auch umsetzen können. Bis jetzt ist davon nicht
viel zu sehen. (Sonst hätte ich mich auch als Nicht- Skolelinux-Nutzer
ganz bestimmt nicht reingehangen)
Bei der CipUX / CAT-Web
Installation wird OpenLDAP neu gestartet. Zumindest für PAM muss auch
der nslcd (nicht mit dem nscd verwechseln) neu gestartet werden, damit
er eine neue Verbindung zum LDAP aufbaut. Vielleicht hilft das auch hier.
Ist (zumindest für mich) sehr interessant. Ich kannte den nslcd noch gar
nicht, weil ich mich nur mit Debian Lenny ein klein wenig auskenne. Und
da gibt es das Paket noch nicht. - Danke für die Info.
Bei Debian/Lenny gibt es den nslcd, er ist im Paket libnss-ldapd
enthalten. Skolelinux ist Debian/Lenny mit bestimmter Paketauswahl und
spezieller Konfiguration.
Oder könnt ihr mir ein paar ldap/slap-Konsolenbefehle sagen mit denen
ich was überprüfen könnte, oder wo kann ich zu suchen beginnen?
LDAP funktioniert offenbar, der smbadmin Account ist auch da. Die
Fehlermeldung von smbpasswd sagt aus, dass das Passwort, das Samba für
den smbadmin Account verwendet, nicht stimmt. Das Passwort steht zum
Einen im LDAP (userPassword) und zum Anderen in der Datei secrets.tdb.
Letztere kannst Du Dir mit
# tdbdump /var/lib/samba/secrets.tdb
anzeigen lassen. In der secrets.tdb steht es im Klartext, im LDAP als
Hash. Es im LDAP (mit ldapmodify) auf diesen Wert zu setzen ermöglicht
Samba den Schreibzugriff aufs LDAP (wenn die LDAP ACLs entsprechend
eingerichtet sind - das ist bei Skolelinux der Fall).
ldapsearch funktioniert jedenfalls und zeigt mir zumindest, dass es
neben all den anderen admins auch einen smbadmin gibt, allerdings weiss
ich nicht, was die verschiedenen Objekteigenschaften aussagen oder
nicht
aussagen:
# smbadmin, People, skole.skolelinux.no
dn: cn=smbadmin,ou=People,dc=skole,dc=skolelinux,dc=no
objectClass: top
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: smbadmin
description: Samba Administrator
diese Ausgabe zeigt, das smbadmin nur ein simpleSecurityObject ist und
damit auch kein Sambapasswort hat. Der Schritt b) war somit falsch. Also
Er braucht ein userPassword, kein Samba Passwort.
nicht
smbpasswd -w geheim
-w password
This parameter is only available if Samba has been
compiled with LDAP support. The -w switch is used to specify
the password to be used with the ldap admin dn. Note that
the password is stored in the secrets.tdb and is keyed off of
the admin's DN. This means that if the value of ldap
admin dn ever changes, the password will need to be manually
updated as well.
Wenn sich Samba nicht zum LDAP verbinden kann, weil das Passwort nicht
stimmt, ist _genau dieser_ Befehl zu verwenden.
Wie oben schon gesagt - du wirst sicher recht haben. Aber dann sollte es
erst recht einfach sein, einen Test anzugeben, der eben nicht auf Samba
zurückgreift, dann wäre zumindest geklärt, ob es ein Samba-Problem oder
ein LDAP-Problem ist.
Das Problem hängt doch offensichtlich mit der Interaktion von Samba und
LDAP zusammen. Die LDAP Utilities greifen direkt auf den LDAP Server zu
und umgehen die Caches (nscd) und Konnektoren (nslcd), die von PAM via
NSS verwendet werden.
Wie genau Samba auf LDAP zugreift, weiß ich nicht. Ich würde annehmen,
dass es dies direkt macht, trotzdem ist es sinnvoll zu testen, ob die
Zwischenschichten einen Einfluss haben, d.h. doch verwendet werden.
Zum Verständnis:
Samba speichert seine Accounts (also die Benutzer, die unter Windows
angegeben werden, um sich an die Domäne anzumelden oder um ein Share
einzubinden) selbst, prinzipiell unabhängig von den Unix
Benutzeraccounts. Das kann auch in einer via LDAP angebundenen Datenbank
erfolgen. Um auf diese Datenbank zuzugreifen, verwendet Samba einen
bestimmten LDAP Account (in der smb.conf angegeben). Das Passwort, mit
dem sich Samba zu diesem Account verbindet, steht in der secrets.tdb und
wird mit smbpasswd -w gesetzt.
Wenn dieser Account (bei Skolelinux eben smbadmin) richtig eingerichtet
ist, kann Samba Benutzeraccounts im LDAP anlegen. Neue Accounts legt man
mit smbpasswd -a BENUTZER an.
sondern stattdessen sollte das (als root) mit
passwd smbadmin
erledigt werden. Denke ich zumindest. - Sorry.
Nein. Der smbadmin LDAP Account ist kein normaler Systemaccount, sondern
ein spezieller Samba LDAP Account.
So entstehen Missverständnisse - und dann diese Skolelinux-Doku ;)
Ich sehe das größere Problem in den vielen verschiedenen Aufgaben, die
mit smbpasswd erledigt werden...
Ein Samba-LDAP-Account würde bei mir so aussehen (kein Tjener!):
[...]
Ja, richtig, das ist für die Benutzung des Samba Servers von außen, also
z.B. mit einem Windows Rechner.
dn: uid=mustermannman58,ou=people,ou=accounts,dc=delixs-schule,dc=de
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: sambaSamAccount
cn: mustermannman58
sn: mustermannman58
givenName: mustermannman58
uid: mustermannman58
uidNumber: 1394
gidNumber: 1002
homeDirectory: /home/students/mustermannman58
loginShell: /bin/bash
gecos: Manfred Mustermann,6a
dabei wäre mir für einen Samba-Account die objectClass 'sambaSamAccount'
entscheidend. Aber ich will nicht streiten. Ihr macht das schon. (für
mich EOT)
Na, nicht gleich eingeschnappt sein. ;-)
Viele Grüße,
Erik
--
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/
auerswald@fg-networking.de Tel: +49-631-4149988-0 Fax: +49-631-4149988-9
Gesellschaft für Fundamental Generic Networking mbH
Geschäftsführung: Volker Bauer, Jörg Mayer
Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630
Reply to: