Anlegen neuer User: samba Home-Dir nicht erzeugt

Hallo,

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?

Vielen Dank für Tipps zur Analyse des Problems!

Besten Dank vorab.

Hallo,

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?

emg

Hallo zurück,

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:

samba/homedirserver=XYZ.be-team.org
samba/homedirpath=%U
samba/homedirletter=I

Ich werde noch einmal einen Test-User neu anlegen, bei dem ich die Werte explizit angebe.

Melde dann das Ergebnis.

mk

In Samba 4 Umgebungen kann man das nicht mehr per UCR vorgeben (Konfiguration des Servers, auf dem das Heimatverzeichnis abgelegt wird). Da geht das nur direkt am Benutzer oder per GPO.

emg

Hallo,

habe jetzt folgende Einstellungen am User hinterlegt:

sambaHomePath: \\file01\home\meinuser
sambaHomeDrive: H:

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 :frowning:

Nachtrag:

Nach Erhöhen des Log levels bekomme ich den gleichen Fehler, wie hier beschrieben: https://forge.univention.org/bugzilla/show_bug.cgi?id=27762.

[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?

Jetzt wächst /var/run/samba/unexpected.tdb. Leider komme ich mit tdbtool nicht an den Inhalt heran bzw. weiß nicht wie. So weit bin ich gekommen:

root@file01:/var/run/samba# tdbtool unexpected.tdb 
tdb> info
Size of file/data: 40960/0
Number of records: 0
Smallest/average/largest keys: 0/0/0
Smallest/average/largest data: 0/0/0
Smallest/average/largest padding: 0/0/0
Number of dead records: 1
Smallest/average/largest dead records: 304/304/304
Number of free records: 3
Smallest/average/largest free records: 340/13288/39172
Number of hash chains: 131
Smallest/average/largest hash chains: 0/0/1
Number of uncoalesced records: 2
Smallest/average/largest uncoalesced runs: 2/2/2
Percentage keys/data/padding/free/dead/rechdrs&tailers/hashes: 0/0/0/97/1/0/1
tdb> keys
key 24 bytes: .........K.P...........
tdb> hexkeys
key 24 bytes
[000] 01 00 00 00 00 00 00 00  17 4B EC 50 00 00 00 00  ....... .K.P...
[010] 07 00 00 00 00 00 00 00                           ....... 

tdb> 

Wie komme ich jetzt mit dem Hexkey an die Daten?

Ok, tdbdump unexpected liefert mir Infos:

root@file01:/var/run/samba# tdbdump unexpected.tdb
{
key(24) = "\01\00\00\00\00\00\00\00\89~\ECP\00\00\00\00M\00\00\00\00\00\00\00"
data(253) = "g\0C\A8\C0\8A\00\11\02\B3I\C0\A8\0Cg\00\8A\00\E9\00\00 EDEPEOFDFFEMFEEJEOEHDADADBCACAAA\00 ECEFCNFEEFEBENCACACACACACACACABM\00\FFSMB%\00\00\0                         0\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\11\00\00I\00\00\00\00\00\00\00\00\00\E8\03\00\00\00\00\00\00\00\00I\00\5C\00\03\                         00\01\00\01\00\02\00`\00\5CMAILSLOT\5CNET\5CNETLOGON\00\12\00\00\00C\00O\00N\00S\00U\00L\00T\00I\00N\00G\000\000\001\00\00\00\00\00\5CMAILSLOT\5CNET\5CGET                         DC468\00\00\00\00\00\00\00\00\00\0B\00\00\00\FF\FF\FF\FF"
}

Hilfe, damit kann ich leider nichts anfangen!

Wie kann ich denn überprüfen, ob die Kommunikation zwischen Samba4 PDC und Samba3 Memberserver sauber ist?

mk

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:

Administrator@projects:~$ net rpc password BE-TEAM
[2013/01/08 22:31:37.223747,  0] param/loadparm.c:7622(lp_do_parameter)
  Ignoring unknown parameter "server role"
[2013/01/08 22:31:37.223959,  0] param/loadparm.c:7622(lp_do_parameter)
  Ignoring unknown parameter "server services"
[2013/01/08 22:31:37.224201,  0] param/loadparm.c:7622(lp_do_parameter)
  Ignoring unknown parameter "tls enabled"
[2013/01/08 22:31:37.224258,  0] param/loadparm.c:7622(lp_do_parameter)
  Ignoring unknown parameter "tls keyfile"
[2013/01/08 22:31:37.224302,  0] param/loadparm.c:7622(lp_do_parameter)
  Ignoring unknown parameter "tls certfile"
[2013/01/08 22:31:37.224349,  0] param/loadparm.c:7622(lp_do_parameter)
  Ignoring unknown parameter "tls cafile"
[2013/01/08 22:31:37.224456,  0, pid=3680] param/loadparm.c:7622(lp_do_parameter)
  Ignoring unknown parameter "dcerpc endpoint servers"
Ignoring unknown parameter "server role"
Ignoring unknown parameter "server services"
Ignoring unknown parameter "tls enabled"
Ignoring unknown parameter "tls keyfile"
Ignoring unknown parameter "tls certfile"
Ignoring unknown parameter "tls cafile"
Ignoring unknown parameter "dcerpc endpoint servers"
Enter new password for BE-TEAM:
Enter Administrator's password:
Failed to set password for 'BE-TEAM' with error: Could not map names to SIDs.

Ist meine Vorgehensweise so überhaupt sinnvoll? Warum gibt es ein Zuordnungsproblem mit den SIDs?

Bitte um Hilfe!!

mk

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

Mit freundlichen Grüßen
Janis Meybohm

Hallo Herr Meybohm,

erst einmal danke für die Rückmeldung! Die letzten beiden Tage war ich unterwegs, daher die Verzögerung.

  • Version ist 3.0-1 auf Master (errata-level 136) und Member (errata-level 140)
  • Nach den beobachteten Problemen hatte ich vergangenen Dienstag die errata aktualisiert, das Problem besteht nach wie vor
  • Servergespeicherte Profile verwende ich - ich prüfe gerade Pfad und Zugriff und Share
  • Bestehende User können sich noch anmelden (sonst hätte ich mich früher gemeldet :wink: )
  • Zugriff via smblient prüfe ich; bisher greifen keine Linux-Clients auf die Samba-Shares zu

Ergebnisse meiner Prüfungen liefere ich noch nach.

mk

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:

root@file01:/# smbclient //FILE01/mbuero -Uuserthatworks%wrongpw
session setup failed: NT_STATUS_LOGON_FAILURE

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:

root@file01:/# smbclient //FILE01/mbuero -Unewuser%secret
Domain=[BE-TEAM] OS=[Unix] Server=[Samba 3.5.11]
tree connect failed: NT_STATUS_ACCESS_DENIED

root@file01:/# smbclient //FILE01/mbuero -Unewuser%wrongpw
Domain=[BE-TEAM] OS=[Unix] Server=[Samba 3.5.11]
tree connect failed: 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):

sambaSID: S-1-5-21-1234567890-123456789-123456789-1234

Liefert das einen Ansatzpunkt?

mk

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 :slight_smile:

Bin wie gesagt für ein paar Tipps bzgl. Analyse dankbar.

mk

So, nun läuft der Sync auch wieder:

/etc/init.d/univention-s4-connector restart

“Doch ein heißes Bügeleisen, auf den kalten Leib gebracht, hat es wieder gut gemacht.” (Wilhelm Busch)

Scheint jetzt alles zu klappen - beobachte das noch skeptisch… Warum der Connector k.o. war, weiß ich nicht.

Hallo,

in den Logdateien des Connectors ("/var/log/univention/connector-s4*.log") sollten sich Hinweise finden lassen wenn der Dienst abgestürzt sein sollte.

Mit freundlichen Grüßen
Janis Meybohm

Mastodon