dosser
Goto Top

Servergespeicherte Profile funktionier nur mit Adminrechten

Ich hab da ein Windows Domain ( Server 2k3 & 2k8 ) mit Windows Xp Clients.

Für alle User gibt es Roaming Profiles die bisher problemfrei funktionierten.

Selten - aber leider doch - passiert es, das ein userprofil nur mehr funktioniert, wenn der User auf dem jeweiligen Client ( also dann auf allen wenn er den Platz wechselt ) Adminrechte hat. Hauptbenutzerberechtigungen haben alle user schon auf den Clients.

Wenn ich das Profil lösche und neu erstelle funktioniert dann wieder alles !!

Gibts da ein Schräubchen an dem ich drehen kann, um das ohne löschen des Profils zu beheben ?

Content-ID: 211335

Url: https://administrator.de/contentid/211335

Ausgedruckt am: 25.11.2024 um 22:11 Uhr

elt0n
elt0n 12.07.2013 um 12:55:37 Uhr
Goto Top
Hi,

haben denn die User alle Rechte auf den Profil Ordnern ?
dosser
dosser 12.07.2013 aktualisiert um 13:11:06 Uhr
Goto Top
Die user haben alle rechte auf den Profilordner am Server und auf dem Client

Das ging ( geht ) ja auch schon lange ohne Probleme, und es gab keine Änderungen. Das Problem tritt ohne ersichtlichen Grund auf.
64748
64748 12.07.2013 um 14:43:05 Uhr
Goto Top
Hallo,

der Besitzer des Profilverzeichnisses muss die Gruppe der Domänenadministratoren sein, das solltest Du prüfen.

Markus
dosser
dosser 12.07.2013 um 16:29:27 Uhr
Goto Top
Diese Berichtigung und Besitzer passt.

Nochmal falls ich was unklar formuliert habe:

Die Roaming-Profile funktionieren bei allen usern einwandfrei. Egal welcher User sich auf welchem Client anmeldet - alles funktioniert.

Aus heiterem Himmel wird dann das Profil "user-xy" nur mehr vollständig geladen , wenn der User-xy auf dem Client Admin-Rechte hat - egal auf welchem Client.
Oder ich mach den User-xy zum Mitglied von (Domain)-/Administratoren. Dann gehts auch wieder , dann auf allen Clients.

Kann als meines erachtens nur ein Problem im Profil-xy sein. Irgend ein Bit muss da "umgefallen" sein, das diesen Bug verursacht.
DerWoWusste
DerWoWusste 15.07.2013 aktualisiert um 13:59:49 Uhr
Goto Top
Hi hmarkus.

der Besitzer des Profilverzeichnisses muss die Gruppe der Domänenadministratoren sein, das solltest Du prüfen
Äh... wie kommst Du darauf? Besitzrechte des Admins haben mit Zugriff der User rein gar nichts zu tun. Sie bieten nur dem Admin die Möglichkeit, die Rechte zu ändern. Ebenso ist es nicht default, dass der Domänenadmin dort Besitzer ist. Von "muss" kann keine Rede sein.

Hallo dosser.

Hauptbenutzer können sich selbst im Handumdrehen zu Admins machen, diese Gruppe benutzt man nicht, wenn es um Sicherheit geht.
Zur Behebung: Setze doch mal die Rechte in allen Unterordnern zurück.
dosser
dosser 15.07.2013 um 15:56:29 Uhr
Goto Top
Zitat von @DerWoWusste:


Hauptbenutzer können sich selbst im Handumdrehen zu Admins machen, diese Gruppe benutzt man nicht, wenn es um Sicherheit
geht.
Zur Behebung: Setze doch mal die Rechte in allen Unterordnern zurück.

Die Berechtigungen des betroffenen Profilordners hab ich schon in alle möglichen/unmöglichen Richtungen verändert - keine Änderung.


PS:
Bezüglich HAUPTBENUTZER:
Das ist leider für die besch JetTravel-Software notwendig.
Was meinst was ich mich deswegen aufgeregt hab. Ohne Konsequenzen. Nicht umsonst ist DataSystem liquidiert worden.
DerWoWusste
DerWoWusste 15.07.2013 um 16:02:46 Uhr
Goto Top
Dann monitore von einem zweiten, parallel angemeldeten Adminuser aus mal mit procmon, was passiert, wenn sich der andere Nutzer anmeldet - lokal siehst Du so alle access denials.
dosser
dosser 15.07.2013 um 16:13:03 Uhr
Goto Top
Zitat von @DerWoWusste:
Dann monitore von einem zweiten, parallel angemeldeten Adminuser aus mal mit procmon, was passiert, wenn sich der andere Nutzer
anmeldet - lokal siehst Du so alle access denials.


Das geht doch nur mit "schneller Benutzerumschaltung" ? Die ist deaktiviert.

Oder steh ich auf dem Schlauch ;-(
DerWoWusste
DerWoWusste 15.07.2013 um 16:51:07 Uhr
Goto Top
Argh, xp, da ist sie aus... dann fällt die Methode flach.
Zunächst keine weitere Iddee, aber ich komme nochmal zurück.
dosser
dosser 15.07.2013 um 16:57:07 Uhr
Goto Top
Nur keinen Stress.

Jedenfalls schon mal herzlichen Dank für Deine Bemühung.
64748
64748 15.07.2013 um 19:46:56 Uhr
Goto Top
Zitat von @DerWoWusste:
Hi hmarkus.

> der Besitzer des Profilverzeichnisses muss die Gruppe der Domänenadministratoren sein, das solltest Du prüfen
Äh... wie kommst Du darauf? Besitzrechte des Admins haben mit Zugriff der User rein gar nichts zu tun. Sie bieten nur dem
Admin die Möglichkeit, die Rechte zu ändern. Ebenso ist es nicht default, dass der Domänenadmin dort Besitzer ist.
Von "muss" kann keine Rede sein.
mh, ich hab das immer so gemacht und meine, dass ich das auch damals beim MCSA-Lehrgang so gelernt habe. Situation in meinen Domänen ist, dass es sich um ein obligatorisches Profil handelt, welches von allen Usern benutzt wird. Aber wenn es anders ist, dann muss ich mir das beizeiten nochmal durchlesen, bald steht bei mir der MCSA für Server 2012 an, da werde ich das sicher vertiefen. Danke jedenfalls @DerWoWusste für den Hinweis.

Markus
DerWoWusste
DerWoWusste 15.07.2013 um 22:14:27 Uhr
Goto Top
Ah, es gibt eine Möglichkeit: starte procmon und stele "enable boot logging" ein und starte dann neu. procmon zeichnet dann alles auf beim nächsten Start und der nächsten Anmeldung.
dosser
dosser 15.07.2013 um 22:17:06 Uhr
Goto Top
Was ich noch vergessen hab:

Das Userprofil wird komplett und richtig von Server gezogen und als "c:\Dokumente und Einstellungen\user-xy" gespeichert.

Nur funktionieren Menues, Programme , Links ,.. nicht, Die Quickstart wird nicht angezeigt, und ein vorhandes Desktop-Wallpaper wird nicht angezeigt.
dosser
dosser 16.07.2013 aktualisiert um 14:51:57 Uhr
Goto Top
Zitat von @DerWoWusste:
Ah, es gibt eine Möglichkeit: starte procmon und stele "enable boot logging" ein und starte dann neu. procmon
zeichnet dann alles auf beim nächsten Start und der nächsten Anmeldung.

Das ging ja super. Jetz hab ich die RIESEN-logs

Name Extension Size

Vom USER mit normalen Rechten:

Bootlog.pml 253.563.515
Bootlog-1.pml 321.686.681
Bootlog-2.pml 313.324.258
Bootlog-3.pml 285.747.136

Vom USER mit Admin-Rechten

Bootlog-adm.pml 243.448.792
Bootlog-adm-1.pml 63.240.059

Erstmal stellt sich mir die Frage warum das log mit den Admin-Rechten ¼ so gross ist und nur aus zwei logs besteht.
Zweitens fehlt mir irgend eine Idee wo ich mit der Fehlersuche ansetze , da ja das lesen & schreiben auf dem Client & Server immer funktioniert.

Die auffallendsten Probleme sind das fehle der Quickstart und die fixierte Taskleiste - die Fixierung lässt sich nicht aufheben.
dosser
dosser 16.07.2013 um 15:21:33 Uhr
Goto Top
Kann das momentan nicht praktisch testen, daher eine theoretische Frage

Mir ist folgendes aufgefallen:

in einer "normalen" NTUSER.INI steht:

[General]
ExclusionList=Lokale Einstellungen;Temporary Internet Files;Verlauf;Temp;Lokale Einstellungen\Anwendungsdaten\Microsoft\Outlook
[ProfileLoadType]
LastUploadState=Complete

in dem nicht funktionierenden Profil steht aber nur:

[General]
ExclusionList=Lokale Einstellungen;Temporary Internet Files;Verlauf;Temp;Lokale Einstellungen\Anwendungsdaten\Microsoft\Outlook


Kann der fehlende Parameter schuld sein - ich finde keine Doku zu dem Parameter ?
Wieso fehlt der Parameter, bzw. was verursacht das fehlen ?

Danke schon mal.
DerWoWusste
DerWoWusste 16.07.2013 aktualisiert um 15:42:48 Uhr
Goto Top
ini: weiß ich nicht.
procmon: such/filter im Log nach access denied
dosser
dosser 17.07.2013 aktualisiert um 10:46:36 Uhr
Goto Top
Ich hab das gefilterte LOG hier hingestellt:

http://kuno.sytes.net/stuff/u19-Log.CSV ~18MB
oder
http://kuno.sytes.net/stuff/u19-Log.PML ~ 40MB

1) 23:25:49,2348380 winlogon.exe 592 CreateFile C:\Dokumente und Einstellungen ACCESS DENIED

Da gibts sämtliche Rechte für alle. Die Profile werden dort ja auch ohne Problem hinkopiert ???

2)
23:28:53,7943993 winlogon.exe 592 RegOpenKey HKU\S-1-5-21-1667534469-852598543-854850462-1126 ACCESS DENIED
23:28:53,8375791 userinit.exe 2308 RegOpenKey HKU\.Default ACCESS DENIED Desired Access: Read/Write

Jede Menge Problem mit der Registry. Woher weiss ich nicht. Und was ich dagegen tun soll ist mir noch nicht ganz klar.

PS:
Was mir an dem ProcessMonitor nicht ganz klar ist, warum der bei verschiedenen Usern verschieden Grosse/viele Logs schreibt.
Ich hab das mit einem zweiten Problem-user getestet, und da hat mir das Teil 89 Logs mit ~ 30GB geschrieben
dosser
dosser 18.07.2013 aktualisiert um 00:29:46 Uhr
Goto Top
Einen Schritt bin ich mal weiter:

Auf dem Registry-Teil des Users ( HKU\S-1-5-21-1667534469-852598543-854850462-1126 ) hatte der User keine Berechtigungen ??!!

Folgende Berichtigung ungen waren da eingetragen:

Administratoren - VOLLZUGRIFF
SYSTEM - VOLLZUGRIFF
Eingeschränkter Zugriff - LESEN


Nachdem ich nun auf dem Client des Users dem USER auf den HKU\S-1-5-21-1667534469-852598543-854850462-1126 VOLLZUGRIFF gegeben habe läuft das wieder alles 1A auf dem Client.

Wie sich Profil des auf anderen Clients verhält konnte ich noch nicht testen. Aber der HKU-Teil der Registry wird ja als ntuser.dat ins servergespeicherte Profil geschrieben. Somit soltte sich das Problem auch auf den anderen Clients gelöst haben.

Wenn ich das fertig gechecked hab melde ich mich nochmal.

Mein ganz besonderer Dank geht an DerWoWusste. für seine Bemühungen und den heissene Tip mit dem ProcessMonitor.

PS:

Woher dieses Problem kam (kommt) konnte ich nicht feststellen und habe auch keine Idee wie ich das rauskriegen könnte.
dosser
dosser 19.07.2013 um 11:41:15 Uhr
Goto Top
So wie in meinem vorigen post beschrieben klappt das einwandfrei.

Sollte es dennoch Probleme geben:

1) auf dem client mit Adminrechten anmelden
2) regedit öffnen ->
3) im regeditor LINKS HKEY_USERS anklicken
4) Datei -> Stuktur laden -> die ntuser-dat des entsprechenden users laden
5) Der Keyname der Struktur bekommt dann die SID des jeweiligen users ( lässt sich mit getsid aus den PSTOOLS ermitteln )
6) abschliesend sollte man für den neuen Schlüssel die Berechtifungen prüfen.

War etwas mühsam das alles aus viel verschiedenen Infos im Netz zu finden.

Bei mir jedengfalls geht wieder alles 1a .

Danke ans Forum für die unterstützung.