servergespeichertes Profil wird nur mit lokalen Admin Rechten vollständig geladen
Windows Server 2003 Domäne mit Windows XP Client, servergespeicherte Profile
Ich habe folgendes Problem,
ein bestimmter Benutzer meldet sich an einem Client-PC, an welchem er lokaler Admin ist, an.
Dabei wird sein servergespeichertes Profil vollständig geladen.
Sobald sich der selbe Benutzer aber an einem Rechner anmeldet,
an dem er keine lokalen Adminrechte hat, wird sein Profil nicht vollständig geladen.
(Gibt man dem Benutzer an diesem PC dann Admin Rechte, so wird sein Profil wieder vollständig geladen)
Nicht Vollständig bedeut in diesem Fall:
Der Benutzername wird richtig erkannt und auch die auf dem "Desktop" hinterlegten Dateien werden gefunden,
aber z.B. die Menüstruktur und Programm relevante Einträge der Registry werden nicht geladen.
Nun bin ich bei meinen Recherchen über die ntuser.dat gestolpert, jedoch kann ich keine Berechtigungs-Probleme erkennen.
Der betroffene Benutzer ist auch der Besitzer (und hat vollen Zugriff), der in seinem Profil hinterlegten NTUSER.DAT.
Ich hoffe, ich konnte mich halbwegsverständlich ausdrücken und Ihr könnt mir ein wenig weiterhelfen.
(Ich möchte den Benutzer nämlich nicht überall zum lokalen Admin machen)
mfG
Ich habe folgendes Problem,
ein bestimmter Benutzer meldet sich an einem Client-PC, an welchem er lokaler Admin ist, an.
Dabei wird sein servergespeichertes Profil vollständig geladen.
Sobald sich der selbe Benutzer aber an einem Rechner anmeldet,
an dem er keine lokalen Adminrechte hat, wird sein Profil nicht vollständig geladen.
(Gibt man dem Benutzer an diesem PC dann Admin Rechte, so wird sein Profil wieder vollständig geladen)
Nicht Vollständig bedeut in diesem Fall:
Der Benutzername wird richtig erkannt und auch die auf dem "Desktop" hinterlegten Dateien werden gefunden,
aber z.B. die Menüstruktur und Programm relevante Einträge der Registry werden nicht geladen.
Nun bin ich bei meinen Recherchen über die ntuser.dat gestolpert, jedoch kann ich keine Berechtigungs-Probleme erkennen.
Der betroffene Benutzer ist auch der Besitzer (und hat vollen Zugriff), der in seinem Profil hinterlegten NTUSER.DAT.
Ich hoffe, ich konnte mich halbwegsverständlich ausdrücken und Ihr könnt mir ein wenig weiterhelfen.
(Ich möchte den Benutzer nämlich nicht überall zum lokalen Admin machen)
mfG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 80673
Url: https://administrator.de/contentid/80673
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
4 Kommentare
Neuester Kommentar
hm...ich habe momentan das gleiche Problem, ich habe ein vorgefertigtes Profil das eine User Gruppe zuverfügung stehen soll. Im Einsatz sind Windows Server 2003 und Thin Clients mit XPE. Ich muss die Gruppe den lokalen Administratoren zuordenen um Änderungen an der Registry vornehmen zu können.
Bevor ich den die neue Technologie eingesetzt habe, hatte ich eine Testumgebung erstellt und dort die notwendigen Test vollzogen. Nach erfolgreichen Tests wollte ich die Technik im Einsatz nehmen. In einer Domäne die schon existiert. Problem ist nun die Geschichte mit dem Profil das das er die Registry nicht lädt bzw ändert. In der Testumgebung ging es ohne Problem. Es war eine reine Windows Server 2003 Umgebung und er hat die Registry Änderungen ohne Problme übernommen.
Sinn macht es nicht unbedingt, die Domänenbenutzer in die Administratorengruppe aufzunehmen, oder?
Bevor ich den die neue Technologie eingesetzt habe, hatte ich eine Testumgebung erstellt und dort die notwendigen Test vollzogen. Nach erfolgreichen Tests wollte ich die Technik im Einsatz nehmen. In einer Domäne die schon existiert. Problem ist nun die Geschichte mit dem Profil das das er die Registry nicht lädt bzw ändert. In der Testumgebung ging es ohne Problem. Es war eine reine Windows Server 2003 Umgebung und er hat die Registry Änderungen ohne Problme übernommen.
Sinn macht es nicht unbedingt, die Domänenbenutzer in die Administratorengruppe aufzunehmen, oder?
Hallo Zusammen,
ich habe das selbe Problem wie "happytorte".
Server: Debian Lenny mit Samba 3 als PDC
Clients: Windows XP Pro. mit Service Pack 3
Mit lokalen Admin-Rechten funktioniert die Synchronisierung beim Ein- und Ausloggen mit dem Server, ohne geht es nicht...
Ich finde es nicht gut alle Benutzer lokal mit Admin-Rechten anlegen zu müssen. Außerdem benötigen die normalen Benutzer keine Admin-Rechte. Ist ja auch ein Sicherheitsthema.
Habt Ihr dieses Problem mittlerweile lösen können?
Gruß
TuxRulez
ich habe das selbe Problem wie "happytorte".
Server: Debian Lenny mit Samba 3 als PDC
Clients: Windows XP Pro. mit Service Pack 3
Mit lokalen Admin-Rechten funktioniert die Synchronisierung beim Ein- und Ausloggen mit dem Server, ohne geht es nicht...
Ich finde es nicht gut alle Benutzer lokal mit Admin-Rechten anlegen zu müssen. Außerdem benötigen die normalen Benutzer keine Admin-Rechte. Ist ja auch ein Sicherheitsthema.
Habt Ihr dieses Problem mittlerweile lösen können?
Gruß
TuxRulez
Ist zwar schon lange her, aber hier eine mögliche Erklärung:
Nicht nur die Datei ntuser.dat benötigt die passenden Berechtigungen. In der ntuser.dat sind die Registry-Schlüssel des Users gespeichert - diese sind ebenfalls mit Berechtigungen versehen.
Gerade nach dem Kopieren eines Profils kann es also zu diesem Berechtigungsproblem kommen.
Ich habe ein ähnliches Problem per Batch gelöst, die als Startskript ausgeführt wird. Dazu habe ich das Tool SetACL.exe verwendet, welches ich auf einen "network share Ordner" auf dem Server kopiert habe:
http://www.helge.mynetcologne.de/setacl/#download
Der Batchcode lautet:
REM SetACL auf den Client kopieren
xcopy "\\Servername\...Pfad zu network share mit SetACL..." "%windir%\system32" /E /C /H /Y /R /I
REM ntuser.dat Rechte anpassen
reg load HKU\locuser "...lokaler Pfad zu...\NTUser.dat"
SetACL.exe "Users\locuser" /registry /set %computername%\%Lokaler_Benutzer% /full /i:cont_obj_inh
reg unload "HKU\locuser"
Der Benutzername (%Lokaler_Benutzer%) muss natürlich zuvor definiert werden. Dann gibt das Skript dem User vollen Zugriff auf alle seine Registry-Schlüssel.
Vielleicht hilft's ja. Auf jeden Fall funktioniert's bei mir beim automatisierten Kopieren eines servergespeichertem mandatory-Profils für einen lokalen Standard-Benutzer.
Ein Hoch auf SetACL !!!
Nicht nur die Datei ntuser.dat benötigt die passenden Berechtigungen. In der ntuser.dat sind die Registry-Schlüssel des Users gespeichert - diese sind ebenfalls mit Berechtigungen versehen.
Gerade nach dem Kopieren eines Profils kann es also zu diesem Berechtigungsproblem kommen.
Ich habe ein ähnliches Problem per Batch gelöst, die als Startskript ausgeführt wird. Dazu habe ich das Tool SetACL.exe verwendet, welches ich auf einen "network share Ordner" auf dem Server kopiert habe:
http://www.helge.mynetcologne.de/setacl/#download
Der Batchcode lautet:
REM SetACL auf den Client kopieren
xcopy "\\Servername\...Pfad zu network share mit SetACL..." "%windir%\system32" /E /C /H /Y /R /I
REM ntuser.dat Rechte anpassen
reg load HKU\locuser "...lokaler Pfad zu...\NTUser.dat"
SetACL.exe "Users\locuser" /registry /set %computername%\%Lokaler_Benutzer% /full /i:cont_obj_inh
reg unload "HKU\locuser"
Der Benutzername (%Lokaler_Benutzer%) muss natürlich zuvor definiert werden. Dann gibt das Skript dem User vollen Zugriff auf alle seine Registry-Schlüssel.
Vielleicht hilft's ja. Auf jeden Fall funktioniert's bei mir beim automatisierten Kopieren eines servergespeichertem mandatory-Profils für einen lokalen Standard-Benutzer.
Ein Hoch auf SetACL !!!
Hallo,
hatte auch das gleiche Problem! Der Benutzer hatte keine Schreibrechte mehr auf den Registry-Schlüssel
Lösung:
1. User in lokale Admin-Gruppe aufnehmen (falls noch nicht geschehen)
2. mit der User-Kennung anmelden (zur Not User informieren und Passwort zurücksetzen)
3. Befehl
4. zum Schlüssel
5. rechte Maustaste auf den Schlüssel und "Berechtigungen" wählen
6. User hinzufügen und "Vollzugriff" gewähren
7. Abmelden und mit Administrator anmelden
8. User aus der lokalen Admin-Gruppe entfernen
FERTIG
Gruß
PSi
hatte auch das gleiche Problem! Der Benutzer hatte keine Schreibrechte mehr auf den Registry-Schlüssel
HKEY\CURRENT_USER
Lösung:
1. User in lokale Admin-Gruppe aufnehmen (falls noch nicht geschehen)
2. mit der User-Kennung anmelden (zur Not User informieren und Passwort zurücksetzen)
3. Befehl
regedt32
ausführen (Start/Ausführen)4. zum Schlüssel
HKEY\CURRENT_USER
wechseln5. rechte Maustaste auf den Schlüssel und "Berechtigungen" wählen
6. User hinzufügen und "Vollzugriff" gewähren
7. Abmelden und mit Administrator anmelden
8. User aus der lokalen Admin-Gruppe entfernen
FERTIG
Gruß
PSi