nach dem Anlegen eines neuen Users in der UMC wird das Home-Verzeichnis auf dem Samba3-Memberserver nicht angelegt. Eine Anmeldung des neuen Users an der Windows-Domäne (von einem Win7 Pro Client aus) schlägt fehl. Die Authentifizierung gegen das LDAP/ADS gelingt, Windows gibt die Meldung “Willkommen” aus, dann wird der Anmeldevorgang aber abgebrochen. Nachvollziehbar, wenn das Samba-Homeverzeichnis auf dem Samba3-Memberserver nicht existiert.
Wo finde ich Troubleshooting-Informationen, um herauszufinden, warum das Samba-Verzeichnis nicht angelegt werden konnte? Ich hatte erwartet, dass dies mit dem Anlegen des Users in der UMC automatisch geschieht.
Kann ich das Problem als Workaround auch lösen, indem ich auf dem Samba3-Memberserver das Home-Directory manuell anlege? Gibt es dafür Skripte bzw. univention-* Kommandos, die ich dazu nutzen kann/sollte?
die Homes werden normalerweise bei der ersten Anmeldung angelegt. Da du vermutlich Samba 4 verwendest: Hast du am Benutzer den korrekten Pfad zu seinem Home (inkl. Servername etc.) angegeben?
ja, ich nutze Samba4 auf dem PDC und habe noch einen Samba3 Member Server laufen, auf dem die User-Verzeichnisse abgelegt werden.
Die entsprechenden Felder habe ich in der Benutzerverwaltung nicht angegeben, da sie eigentlich via UCR-Default gezogen werden sollten (so hatte ich das jedenfalls verstanden). Da steht bei mir folgendes:
Die Dateihierarchie unter \file01\home\meinuser sieht exakt so aus, wie bei Usern, mit denen die Anmeldung funktioniert.
Bekomme aber immer bei der Anmeldung zwei eigenartige Ergebnisse (zumindest für mich unverständlich):
[ul]
[li] in /var/log/samba/log.samba auf dem PDC:
[2013/01/08 16:14:43.825288, 1, pid=6862] …/source3/smbd/process.c:463(receive_smb_talloc)
read_smb_length_return_keepalive failed for client ipv4:192.168.12.103:49890 read error = NT_STATUS_CONNECTION_RESET.[/li]
[li] Eine Änderung an /var/run/samba/unexpected.tdb (laut Zugriffszeit) - aber keine Inhalte, die ich mit tdbtool auswerten könnte[/li][/ul]
Habe auf dem Samba3 Memberserver unmittelbar nach der fehlgeschlagenen Anmeldung nach geänderten Dateien gesucht, und da scheint mir eben die unexpected.tdb verdächtig zu sein. Es wird aber nur das Änderungsdatum beeinflusst, die Größe und der Inhalt ändern sich nicht.
root@file01:/# find -mmin -2
./var/lib/univention-nagios/check_univention_replication.cache
./var/spool/postfix/public/pickup
./var/cache/samba
./var/cache/samba/browse.dat
./var/run/samba/unexpected.tdb
./var/run/cups/certs
./var/run/cups/certs/0
(...ganz viele Einträge aus proc und sys...)
Bei abgelaufenem Passwort etc. müsste ich ja noch andere Einträge in den Logs von Samba und LDAP / auth.log finden. Fehlanzeige
So, ein letzter Eintrag noch für heute: Die Trust-Beziehung zwischen PDC und Member passt nicht:
Administrator@file01:/$ net rpc trustdom list
Enter Administrator's password:
Trusted domains list:
none
Trusting domains list:
none
Das hatte ich schon einmal in Beitrag [url]Nmblookup zwischen Samba 4 DCM und Samba 3 Memberserver] und bin damals leider auch zu keiner nachvollziehbaren Lösung gekommen. Vielleicht ging es wieder, weil einige Passwörter neu generiert wurden? Ich weiß es nicht.
Habe vergeblich versucht den Trust wieder herzustellen:
Das Passwort des Domain Trust Users habe ich in der UMC passend geändert. Hilft nix.
Habe es auch auf dem PDC an der Kommandozeile vergeblich versucht:
Hallo,
[ul]
[li]welche UCS Version setzten Sie ein (auf DC-Master und Memberserver)?[/li]
[li]wann war das letzte Update?[/li]
[li]verwenden Sie Servergespeicherte Profile (welcher Pfad ist für diese bei den Benutzern eingetragen)?[/li]
[li]verwenden Sie den Samba-Homeshare oder eine selbst definierte Freigabe (“ucr get samba/share/home”, [bug]25339[/bug])?[/li]
[li]funktionier die Anmeldung bestehender Benutzer noch?[/li]
[li]funktioniert der Zugriff auf den Homeshare manuell, z.B. via “smbclient”?[/li][/ul]
Wenn die Anmeldung für bereits bestehende Benutzer noch funktioniert, was Sie in einem Posting erwähnen, handelt es sich hierbei vermutlich nicht um ein generisches Problem in der Verbindung zwischen Memberserver und DC-Master.
[quote=“be-team”]Nach Erhöhen des Log levels bekomme ich den gleichen Fehler, wie hier beschrieben: [bug]27762[/bug].
[2013/01/08 17:14:46.271628, 0] lib/smbldap.c:697(smbldap_store_state)
PANIC: assert failed at lib/smbldap.c(697): tmp_ldap_state == smbldap_state
[2013/01/08 17:14:46.434095, 0] winbindd/idmap_ldap.c:422(idmap_ldap_allocate_id)
sambaUnixIdPool object not found
Eine Lösung zu diesem Fehler hatte ich im Bugzilla nicht gefunden. Auf Verdacht den Samba3 Memberserver aktualisieren?[/quote]Ich glaube nicht dass es sich hier um das am Bug beschriebene Problem handelt. Die PANIC hat, soweit bekannt, keine negativen Auswirkungen auf den Betrieb und sie tritt in Ihrem Fall auch in einem anderen Kontext auf.
[quote=“be-team”]So, ein letzter Eintrag noch für heute: Die Trust-Beziehung zwischen PDC und Member passt nicht[/quote]Da der Samba 3 Server in eine AD Domäne (Samba 4) gejoint ist, sollte es hier keine Vertrauensstellung geben (“net rpc trustdom list” müsste IMHO einen Fehler ausgeben dass die Domain nicht gefunden wird da es keine NT-Domäne mit dem Namen gibt).
Daher sind evtl. auch die Anpassungen aus dem Thread nmblookup zwischen Samba 4 DCM und Samba 3 Memberserver für dieses Problem relevant bzw. ausschlaggebend.
Um zu prüfen ob der Samba 3 Server noch korrekt in die AD-Domäne gejoint ist: “net ads testjoin”
Neue Ergebnisse aus Tests mit smbclient auf dem Memberserver selbst (Samba3) liefern folgendes. Habe einen User genommen, der bekanntermaßen funktioniert. smbclient bestätigt das:
root@file01:/# smbclient //FILE01/mbuero -Uuserthatworks%secret
Domain=[BE-TEAM] OS=[Unix] Server=[Samba 3.5.11]
smb: \> ls
. D 0 Fri Oct 19 12:01:52 2012
.. D 0 Thu Sep 13 18:08:34 2012
italc.key.txt AR 590 Mon Sep 24 21:37:38 2012
.DS_Store AH 6148 Wed Oct 17 15:39:39 2012
34954 blocks of size 524288. 26752 blocks available
smb: \> exit
Dann habe ich das Passwort absichtlich falsch angegeben. Die erwartete Fehlermeldung kommt:
Mit dem neuen User sieht es anders aus. Weder das korrekte Passwort noch ein falsches Passwort bringen das erwartete Ergebnis. Beide laufen auf NT_STATUS_ACCESS_DENIED:
Bei Durchsicht der Ausgabe aus # univention-ldapsearch uid=newuser ist mir die sambaSID aufgefallen, die anders aussieht als beim funktionierenden User:
sambaSID: S-1-4-2030
Die 2030 ist nichts anderes als die Relative ID. Beim funktionierenden User sieht es so aus (Ziffernfolge mit 123… überschrieben):
So, jetzt komme ich der Sache näher: Es scheint Schwierigkeiten mit der ADS/LDAP-Synchronisierung zu geben. Gibt es dazu geeignete Troubleshooting-Topics?
Habe den Benutzer einmal zur Probe mit den Windows-ADS-Tools überprüft (dsa.msc). Dort fehlte er, während er im LDAP (vom umc Benutzermodul aus) vorhanden war. Also User im LDAP gelöscht, mit dsa.msc neu angelegt (minimale Vorgaben, keine serverbasierten Profile etc.). Siehe da: Anmeldung an der Domäne möglich. Aber wohl nur am Samba4 ADS auf dem PDC, denn der Memberserver wusste nichts vom neu angelegten User, ebenso wenig kam der neue User im umc Benutzermodul zum Vorschein.
Jetzt würde ich noch gerne herausfinden, wie ich mich in diesen Schlamassel manövriert habe… dann muss ich den ADS-LDAP-sync wieder schön machen.
Aber nicht mehr heute
Bin wie gesagt für ein paar Tipps bzgl. Analyse dankbar.
)