Benutzerprofile werden bei Anmeldung nicht geladen

Hallo,

ich hab da mal nach langer Zeit wieder mal eine Frage,
bei einem Kunden von uns passiert es seit ein paar Tagen sporadisch mal, das das Profil von Benutzern, die sich anmelden nicht geladen wird und damit auch die Freigaben nicht angelegt werden. Windows meldet dann, dass ein lokales Profil geladen wird.

Die Umgebung ist ein UCS-Master in der Version 3.0-1. Die Benutzer haben alle servergespeicherte Profile.

Beim durchforsten der Logs sind mir 2 Sachen aufgefallen:
In dem /var/log/univention/connector-s4.log gibt es folgende Fehlermeldungen:

06.09.2012 13:12:22,616 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-connector/s4/1341059081.399440 06.09.2012 13:12:22,618 LDAP (PROCESS): sync from ucs: [ ou] [ add] ou=virtualisiert,cn=server,cn=computers,dc=domainname,dc=lan 06.09.2012 13:12:22,670 LDAP (WARNING): sync failed, saved as rejected 06.09.2012 13:12:22,671 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 749, in __sync_file_from_ucs or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old))): File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2083, in sync_from_ucs self.lo_s4.lo.add_s(compatible_modstring(object['dn']), compatible_addlist(addlist)) #FIXME encoding File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 194, in add_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) NAMING_VIOLATION: {'info': '00002037: Naming violation - structural objectClass organizationalUnit is not a valid child class for CN=server,CN=Computers,DC=domainname,DC=lan', 'desc': 'Naming violation'}
und im /var/log/univention/samba-sync.log gibt es dieses

/usr/sbin/jitter: line 56: exec: /usr/share/univention-samba/slave-sync: cannot execute: No such file or directory /usr/sbin/jitter: line 56: /usr/share/univention-samba/slave-sync: No such file or directory

Gibt es da vielleicht einen Zusammenhang?
Ist es Sinnvoll die Profile noch mal neu anzulegen? Bei ein bis zwei Benutzern mag das nämlich noch gehen, bei mehreren ist das dann aber unpraktikabel. Es wäre schön wenn man die Ursache finden und beheben könnte.

Vielen Dank und viele Grüße
froeschchen

Hallo,

hat zwar nichts direkt mit dem Benutzerprofile-Problem zu tun, aber du verwendest Organisationseinheiten wo man normalerweise Container verwenden sollte.
Erstelle einfach einen Container in der Navigation an der Stelle wo deine Organisationseinheit ist (hier z.B. cn=server,cn=computers,dc=domainname,dc=lan)
und verschiebe die in der ou enthaltenen Objekte dann in den neuen Container. Danach kannst du die Organisationseinheit löschen.

Hallo,

die Meldungen aus der /var/log/univention/connector-s4.log sind, wie von fme bereits beschrieben darauf zurück zu führen das im LDAP unterhalb eines CN ein OU angelegt wurde - Active Directory unterstützt diese Struktur nicht.

Die Meldungen in der /var/log/univention/samba-sync.log wird vermutlich durch einen Cronjob /usr/share/univention-samba/slave-sync verursacht der nach der Umstellung auf Samba 4 nicht entfernt wurde. Der Cronjob sollte spätestens entfernt werden wenn Sie das Paket “univention-samba” purgen (apt-get remove --purge univention-samba).

Beide Meldungen sind jedoch unabhängig von den geschilderten Problemen. Sie sollten prüfen ob Sie die Probleme irgendwie eingrenzen können (Bestimmte Clients oder Benutzer, bestimmte Uhrzeiten o.ä.). Außerdem sollten Sie die Windows Eventlogs sowie die Samba Logdateien auf eventuelle Probleme hin prüfen.

Mit freundlichen Grüßen
Janis Meybohm

Wir haben hier leider das gleiche Problem und es tritt jetzt auch wieder bei Windows7 Clients auf die schon mal funktioniert haben. In den log Dateien
/var/log/samba/log.smbd
/var/log/samba/log.nmbd
/var/log/samba/log.samba
haben wir keine Fehler gefunden. Nach folgendem Muster wurden die Profile von der Univenten 2.0 Umgebung auf die neue Univention 3.0 Umgebung mit Samba4 kopiert:

Vorbereitung:
Alle Gruppen und User neu angelegt. Die Posix Nummern wurden dadurch neu vergeben.

  1. neuen User über UDM einrichten (also einen neuen Usernamen vergeben -> aus mueller wird mueller2)
  2. unter dem Reiter Konto den Profilpfad wie folgt einrichten
  \\{name des Servers}.{name der Domäne}.local\profile\{name des neuen Users}

Windows-Heimtverzeichnis

/home/{name des neuen Users}
  1. den Rechner in die neue Domäne hängen und mit dem neuen User anmelden / dann den Rechner wieder herunterfahren
  2. in dem alte Profil die user.Dat und alle .ini Dateien in dem Wurzelverzeichnis löschen / den Ordner “Microsoft” unter Appdata(oder anwenderdaten)/Roaming löschen
  3. das Alte Profil (mueller.V2) in das neue Profil des neuen Users (mueller2.V2) kopieren
    6.Den Rechner wieder hochfahren / testen

So hat es am Anfang funktioniert. Für die Profile haben wir ein eigenes share (\share\profile\mueller2.V2 -> siehe Punkt 2).

Mittlerweile weigern sich immer mehr Clients auf die Profile zuzugreigen und geben im Windows Log diese Meldungen aus:

Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne GILCHING aufgrund der folgenden Ursache nicht einrichten:
Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.
Dies kann zu Authentifizierungsproblemen führen. Stellen Sie sicher, dass der Computer mit dem Netzwerk verbunden ist. Wenden Sie sich an den Domänenadministrator, wenn das Problem weiterhin besteht.

Die Serverkopie des servergespeicherten Profils wurde nicht gefunden. Sie werden mit einem lokalen Benutzerprofil angemeldet. ƒnderungen an dem Profil werden nach der Abmeldung nicht auf den Server kopiert. Mögliche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte.
Details - Der Netzwerkpfad wurde nicht gefunden.

Was haben wir falsch gemacht?
Gruß Hahn

Hallo,

die Zitierte Fehlermeldung deutet auf ein Problem der Anmeldeserver hin. Sie sollten sicherstellen dass das System auf dem aktuellen Errata-Level von UCS 3.0-2 ist und das die Samba 4 Dienste korrekt funktionieren. Außerdem sollten Sie sicherstellen dass die Uhrzeiten aller Server und Clients synchron sind.

Evtl. handelt es sich nur im einen Tippfehler in Ihrer Beschreibung, zur Sicherheit sei aber gesagt dass das WIndows-Heimatverzeichnis als UNC Pfad (inkl. Servername) angegeben werden muss, z.B.: \<Benutzername>. /home/{name des neuen Users} entspricht der Syntax für UNIX-Heimatverzeichnis.

Mit freundlichen Grüßen
Janis Meybohm

Hallo Herr Meybohm,

Ich brauch nochmals ein paar Tipps von Ihnen:

  1. Errata ist gelaufen: Die momentan installierte Version ist 3.0-2
    Leider besteht das Problem unverändert.
  2. Beim Einrichten des Timeservers komme ich nicht weiter. Wie muss ich die Windows 7 Clients konfigurieren, dass sie den DCMaster als Timeserver aktzeptiren? Welche Software muss ich auf DCMaster installieren?
  3. Wo ist der Unterschied zwischen Profilpfad und Windows-Heimatverzeichnis?

Mit freundlichen Grüßen,
Volker Hahn

zu 3.
Im Profilpfad werden die Windows Einstellungen eines Users abgespeichert, z.B. eingestelltes Hintergrundbild usw. Für den User ist dieses Verzeichnis normalerweise im Arbeitsplatz/Explorer nicht sichtbar.
Das Heimatverzeichnis wird dem User als Laufwerk zur Verfügung gestellt, in diesem speichert er seine Daten ab. Da diese Daten dann auf dem Server liegen können sie einfach gesichert werden und der User bekommt sie bei Anmeldung an einem anderen PC auch zur Verfügung gestellt.

Hallo,

[quote=“versdirekt”]2. Beim Einrichten des Timeservers komme ich nicht weiter. Wie muss ich die Windows 7 Clients konfigurieren, dass sie den DCMaster als Timeserver aktzeptiren? Welche Software muss ich auf DCMaster installieren?[/quote]der Zeitserver “NTP” sollte standardmäßig aktiviert sein. Eine externen Zeitserver für den Abgleich können Sie über die UCR-Variable timeserver konfigurieren.
Damit Windows 7 Clients den Zeitserver automatisch verwenden, muss Signed-NTP aktiviert sein: Windows Clients melden Zeitunterschied zum UCS3 Server

Mit freundlichen Grüßen
Janis Meybohm

Mastodon