32
Gruppenrichtlinien Benutzer vs. Administratoren
Benutzer haben keine RSOP Daten
Bei Administratoren klappts
Hallo zusammen
Ich hab da so ein Problem mit den Gruppenrichtlinen:
Wenn ich mich als Admin auf ner Workstation anmelde und "gpresult" eingebe, so funktionniert das besstens. Wenn ich das jedoch mit einem "normalen" Benutzer mache, so gibt er mir zurück, dass er keine RSOP Daten hat. (Ich nehme desshalb an, dass es der DNS nicht sein kann!)
Sysvol wird als lesezugriff für alle Benutzer vergeben.
Was mache ich falsch (da muss doch ein grundlegender Überlegungsfehler meinerseits vorliegen!)?
Gruss
Bei Administratoren klappts
Hallo zusammen
Ich hab da so ein Problem mit den Gruppenrichtlinen:
Wenn ich mich als Admin auf ner Workstation anmelde und "gpresult" eingebe, so funktionniert das besstens. Wenn ich das jedoch mit einem "normalen" Benutzer mache, so gibt er mir zurück, dass er keine RSOP Daten hat. (Ich nehme desshalb an, dass es der DNS nicht sein kann!)
Sysvol wird als lesezugriff für alle Benutzer vergeben.
Was mache ich falsch (da muss doch ein grundlegender Überlegungsfehler meinerseits vorliegen!)?
Gruss
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 122708
Url: https://administrator.de/forum/gruppenrichtlinien-benutzer-vs-administratoren-122708.html
Ausgedruckt am: 25.12.2024 um 18:12 Uhr
32 Kommentare
Neuester Kommentar
Moin.
Es geht normalerweise so. Evtl. liegt ein Defekt vor, probier es mal bei anderen Workstations.
Es geht normalerweise so. Evtl. liegt ein Defekt vor, probier es mal bei anderen Workstations.
Das ganze ist Workstation unabhängig, d.h. bei den Admins klappts und am selben Computer gehts mit den Benutzern nicht..... Profile werden korrekt übergeben, Skripte werden geladen nur diese Richtlinien scheinen keinen Bock zu haben!
Keine Ahnung.
Lies mal http://msinfluentials.com/blogs/jesper/archive/2006/11/25/group-policy- ... - wenigstens Ansätze von Profis.
Zitat:
Lies mal http://msinfluentials.com/blogs/jesper/archive/2006/11/25/group-policy- ... - wenigstens Ansätze von Profis.
Zitat:
This procedure verified that it was indeed profile corruption. When the user logged on next a complete kerberos logon was negotiated and group policy was applied
Außerdem zum googlen die englische Fehlermeldung: The user "Domain\user" does not have RSOP data
Nunja, die Herren von diesem Post haben ein anderes Problem. Bei denen funktioniert ein user nicht. Bei mir funktioniert kein user, nur Admins. Bei mir scheint das Problem an irgend so ner Freigabe zu liegen und nicht an einem Profil. Weiterhin verwenden die eine Umleitung der Eigenen Dateien und wahrscheilich noch mehr "Extras" in meinem Falle handelt es sich um ein minimal-Setup.
Ich habe in der Zwischenzeit auch wieder etwas gebastelt und jetzt kommt noch ein weiterer Bug hinzu. Vielleicht hat das ja denselben Ursprung:
Ich eröffne einen Account tester. Dieser ist Mitglied von den Gruppen Administratoren (dann hat er RSOP Daten) und Arbeiter (auf diese soll eine Richtlinie angewendet werden).
Dann machen ich eine Richtlinie RL_Arbeiter und verknüpfe sie mit dem obersten OU das ich in der Struktur hab. Danach überprüfe ich ob es nach unten in alle OUs weitervererbt wird. Dies ist der Fall. Beim Einloggen des tester accounts werden die Richtlinien jedoch nicht übernommen. Ändere ich nun die Richtlinie (unter Sicherheitsfilterung) so, dass sie nicht mehr auf die Gruppe Arbeiter angewendet wird sondern auf tester direkt, so klappt alles.
Dies scheint mir relevant, da die Gruppe Arbeiter die Zugriffe auf sysvol regelt…. D.h. wenn was mit dieser Gruppe nicht stimmen sollte, so klappt mir das ganze Kartenhaus von wegen Gruppenrichtlinien natürlich zusammen. Ich kann jedoch keine Fehler bei dieser Gruppe erkennen. Auch löschen und neu machen hilft da gar nicht….
Ich habe in der Zwischenzeit auch wieder etwas gebastelt und jetzt kommt noch ein weiterer Bug hinzu. Vielleicht hat das ja denselben Ursprung:
Ich eröffne einen Account tester. Dieser ist Mitglied von den Gruppen Administratoren (dann hat er RSOP Daten) und Arbeiter (auf diese soll eine Richtlinie angewendet werden).
Dann machen ich eine Richtlinie RL_Arbeiter und verknüpfe sie mit dem obersten OU das ich in der Struktur hab. Danach überprüfe ich ob es nach unten in alle OUs weitervererbt wird. Dies ist der Fall. Beim Einloggen des tester accounts werden die Richtlinien jedoch nicht übernommen. Ändere ich nun die Richtlinie (unter Sicherheitsfilterung) so, dass sie nicht mehr auf die Gruppe Arbeiter angewendet wird sondern auf tester direkt, so klappt alles.
Dies scheint mir relevant, da die Gruppe Arbeiter die Zugriffe auf sysvol regelt…. D.h. wenn was mit dieser Gruppe nicht stimmen sollte, so klappt mir das ganze Kartenhaus von wegen Gruppenrichtlinien natürlich zusammen. Ich kann jedoch keine Fehler bei dieser Gruppe erkennen. Auch löschen und neu machen hilft da gar nicht….
Ist das ein Produktivsystem oder ein Testsystem?
Welche Windows-AD-Version benutzt du?
IST das ein SBS-Server?
Hast du an den Default-GPO's etwas verändert?
Hast du an den AD-Freigaben (SYSVOL etc.) etwas verändert.
Gruß
Welche Windows-AD-Version benutzt du?
IST das ein SBS-Server?
Hast du an den Default-GPO's etwas verändert?
Hast du an den AD-Freigaben (SYSVOL etc.) etwas verändert.
Gruß
Es ist ein Produktiv-System an welchem wir grössere Veränderungen im Bereich der
Datenstruktur und der Zugriffssteuerung vorgenommen haben.
Der Server ist ein 2003er mit SP2. Der AD ist ein "Microsoft Management Console 3, Version 5.2 mit SP2"
Was das ganze GPO angeht, so hat mein Vorgänger diese nicht benutzt (wir sind ein sehr kleiner Betrieb ~25 User). Ich habe an den Defaults nichts geändert kann aber keine Aussage darüber machen, was der Verantwortliche vor mir gebastelt hat (gebastelt ist an dieser Stelle wirklich das richtige Wort). Kann man diese Einstellungen einfach resetten? Und was haben die mit der Funktionnalität des ganzen zu tun?
Sysvol-Freigaben wurden einmal gelöscht, dann aber wieder hergestellt und laufen auch soweit (ansonsten würden ja keine Profile versendet etc.)
Die Freigaben sind wie folgt:
Vollzugriff für: Administratoren,"Gruppe_mit_allen_Benutzern",Authentifizierte Benutzer und Domänen Benutzer (Ich weiss, dass einige Gruppen überflüssig währen)
Sicherheitseinstellungen:
Vollzugriff für: Administratoren und das System
Lesezugriff für: Authentifizierte Benutzer, "Gruppe_mit_allen_Benutzern" und Server Operatoren
Datenstruktur und der Zugriffssteuerung vorgenommen haben.
Der Server ist ein 2003er mit SP2. Der AD ist ein "Microsoft Management Console 3, Version 5.2 mit SP2"
Was das ganze GPO angeht, so hat mein Vorgänger diese nicht benutzt (wir sind ein sehr kleiner Betrieb ~25 User). Ich habe an den Defaults nichts geändert kann aber keine Aussage darüber machen, was der Verantwortliche vor mir gebastelt hat (gebastelt ist an dieser Stelle wirklich das richtige Wort). Kann man diese Einstellungen einfach resetten? Und was haben die mit der Funktionnalität des ganzen zu tun?
Sysvol-Freigaben wurden einmal gelöscht, dann aber wieder hergestellt und laufen auch soweit (ansonsten würden ja keine Profile versendet etc.)
Die Freigaben sind wie folgt:
Vollzugriff für: Administratoren,"Gruppe_mit_allen_Benutzern",Authentifizierte Benutzer und Domänen Benutzer (Ich weiss, dass einige Gruppen überflüssig währen)
Sicherheitseinstellungen:
Vollzugriff für: Administratoren und das System
Lesezugriff für: Authentifizierte Benutzer, "Gruppe_mit_allen_Benutzern" und Server Operatoren
du kannst die default GPO's resetten...ja mit dcgpofix.exe
Werden den die GPOs am client übernommen oder nicht?
Werden den die GPOs am client übernommen oder nicht?
nein die werden auch nicht übernommen. Auch die widerherstellung hat nichts bewirkt....
hast du das ganze an verschiedenen WS ausprobiert?
hast du oder dein Kollege vieleicht die Gruppe der Domainenbenutzer aus den jeweiligen user-accounts gelöscht?
hast du oder dein Kollege vieleicht die Gruppe der Domainenbenutzer aus den jeweiligen user-accounts gelöscht?
Das Problem ist bei allen WS und die Domainbenutzer und Gruppen wurden alle neu in neuen OU's erstellt (Profile, Skripte, Speicherorte, Namen, Passwörter alles neu aufgesetzt). Wenn ich nun einem Benutzer Adminrechte gebe (ohne verschieben, oder sonstigen Änderungen) funktionniert alles besstens. Nur wenn ich ihm "normale" Benutzerrechte vergebe, so klappt es nicht mehr.
Also die Gruppe Domainbenutzer MUSS in den jeweiligen useraccounts vorhanden sein.
Ist die Delegierung der GPO's richtig eingestellt? -> Authentifizierten Benutzer auf Lesen und Gruppenrichtlinie übernehmen ?
Wenn ja -> führ mal bitte auf dem client rsop.msc aus und berichte
Ist die Delegierung der GPO's richtig eingestellt? -> Authentifizierten Benutzer auf Lesen und Gruppenrichtlinie übernehmen ?
Wenn ja -> führ mal bitte auf dem client rsop.msc aus und berichte
Also die Gruppe "Domänen-Benutzer" ist bei jedem Account (auch den Admins) drin und kann auch nicht entfernt werden.
Die Delegierung der GPO's ist meiner Meinung nach richtig eingestellt:
Die "Gruppe_mit_allen_Benutzern" hat "Leserechte (durch Sicherheitsfilterung)"
Leserechte ohne Sicherheitsfilterung haben ausserdem:
Authentifizierte Benutzer und Domänencontroller der Organisation
Vollzugriff haben:
Domänen-Admins, Organisations Admins und das System
Die Delegierung der GPO's ist meiner Meinung nach richtig eingestellt:
Die "Gruppe_mit_allen_Benutzern" hat "Leserechte (durch Sicherheitsfilterung)"
Leserechte ohne Sicherheitsfilterung haben ausserdem:
Authentifizierte Benutzer und Domänencontroller der Organisation
Vollzugriff haben:
Domänen-Admins, Organisations Admins und das System
Sorry deinel letzt anfrage:
Mit einem normalen user ergibt rsop.msc folgende Meldungen:
zuerst kommt ein PoPup, dass folgendes besagt:
"Es werden andere Richlinienergebnissatzanweisungen mit den angeforderten Informationen ausgeführt. Das Ergebniss kann evt. fehlerhaft sein wenn sie diesen Vorgang fortsetzten ohne diese Richlinienergebnissatzanweisungen zu beenden. Soll der Vorgang fortgesetzt werden?"
Danach ein weiteres Popup mit "ungültigem Namespace"
Bei den Admins zeigt er mir nur die Richtlinen (ohne errors) an
Mit einem normalen user ergibt rsop.msc folgende Meldungen:
zuerst kommt ein PoPup, dass folgendes besagt:
"Es werden andere Richlinienergebnissatzanweisungen mit den angeforderten Informationen ausgeführt. Das Ergebniss kann evt. fehlerhaft sein wenn sie diesen Vorgang fortsetzten ohne diese Richlinienergebnissatzanweisungen zu beenden. Soll der Vorgang fortgesetzt werden?"
Danach ein weiteres Popup mit "ungültigem Namespace"
Bei den Admins zeigt er mir nur die Richtlinen (ohne errors) an
und unter delegierung steht bei den "authentifizierte benutzer" "Gruppenrichtlinien übernehmen" der hacken drinn?
...schau mal unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters auf dem client
..stimmen da die Werte Domain und NVDomain mit dem domainnamen (FQDN) überein?
...schau mal unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters auf dem client
..stimmen da die Werte Domain und NVDomain mit dem domainnamen (FQDN) überein?
Zum Zweiten Punkt: Ja das stimmt
Zum ersten hab ich ne Frage: Wo setzt Du da den Hacken? Wenn ich auf Delegierung gehe, so kann ich nur die Zugriffsrechte auf die Gruppenrichtlinie steuern. Habe aber nirgends so einen Hacken gesehen. Wenn ich jedoch unter "Bereich" nachschaue, so ist unter Sicherheitsfilterung die Gruppe genannt, auf die ich sie anwenden will.... Ist das gemeint?
Zum ersten hab ich ne Frage: Wo setzt Du da den Hacken? Wenn ich auf Delegierung gehe, so kann ich nur die Zugriffsrechte auf die Gruppenrichtlinie steuern. Habe aber nirgends so einen Hacken gesehen. Wenn ich jedoch unter "Bereich" nachschaue, so ist unter Sicherheitsfilterung die Gruppe genannt, auf die ich sie anwenden will.... Ist das gemeint?
also..wenn du die gpmc öffnest -> die gpo anklicken - rechtes fenster -> delegierung -> unten rechts auf "Erweitert" -> authentifizierte benutzer auswählen -> unteres fenster runterscrollen -> gruppenrichtlinien übernehmen anklicken.
Ach so, das ist das selbe was ich gemeint habe. Die Autentifizierten Benutzer sollen das ja nicht übernehmen aber die "Gruppe_mit_allen_Benutzern" soll das machen und die hats auch drin.
Die Autentifizerten Benutzer haben nur einen "Richtlinie übernehmen Haken" bei den Default Richtlinien nicht aber bei den eigens erstellten. (Eigentlich egal, da sie sowieso keine übernehmen)
Die Autentifizerten Benutzer haben nur einen "Richtlinie übernehmen Haken" bei den Default Richtlinien nicht aber bei den eigens erstellten. (Eigentlich egal, da sie sowieso keine übernehmen)
setz mal den hacken auf übernehmen und lesen und nimm die authentifizierten benutzer unter die sicherheitfilterung mit rein....ich will nur sehen ob es geht...wenn das geht...dann schauen wir weiter
Da tut sich rein gar nichts...
Ausser dass nun logischerweise alle Administratoren die sich in diesem OU befinden die neue Richtlinie erhalten.....
Ausser dass nun logischerweise alle Administratoren die sich in diesem OU befinden die neue Richtlinie erhalten.....
noch mal zum besseren verständnis:
1. du hast eine neue ou angelegt
2. du hast innerhalb dieser OU eine neue Gruppe und entsprechende User angelegt
3. du hast die benutzer den gruppen hinzugefügt
4. du hast mittels gpmc eine neue Policy angelegt und diese mit der OU verknüpft.
5. du hast die Policy AKTIVIERT
6. unter sicherheitsfilterung hast du die gewünschte gruppe aufgenommen
7. unter Registerreiter Details hast du unten im Popupmenue Aktiviert stehen
8. unter delegierung hast du auf diese gruppe sowohl lesen als auch" Gruppenrichtlinien übernehmen" aktiviert
9. du hast auf dem DC ein gpupdate force ausgeführt
10. du hast auf dem client ein gupdate force ausgeführt und am besten sich einmal ab und wieder angemeldet...mit entsprechenden Usern innerhalb der betroffenen gruppen
11. Du hast die Policy so konfiguriert, das Benutzereinstellungen definiert worden sind
1. du hast eine neue ou angelegt
2. du hast innerhalb dieser OU eine neue Gruppe und entsprechende User angelegt
3. du hast die benutzer den gruppen hinzugefügt
4. du hast mittels gpmc eine neue Policy angelegt und diese mit der OU verknüpft.
5. du hast die Policy AKTIVIERT
6. unter sicherheitsfilterung hast du die gewünschte gruppe aufgenommen
7. unter Registerreiter Details hast du unten im Popupmenue Aktiviert stehen
8. unter delegierung hast du auf diese gruppe sowohl lesen als auch" Gruppenrichtlinien übernehmen" aktiviert
9. du hast auf dem DC ein gpupdate force ausgeführt
10. du hast auf dem client ein gupdate force ausgeführt und am besten sich einmal ab und wieder angemeldet...mit entsprechenden Usern innerhalb der betroffenen gruppen
11. Du hast die Policy so konfiguriert, das Benutzereinstellungen definiert worden sind
Ich habe folgende Struktur im AD:
DOMAIN
OU_Benutzer
Benutzer_A
Benutzer_B
etc...
OU_Gruppen
Gruppe_A
Gruppe_B
etc...
OU_Computer
Computer_A
Computer_B
etc...
Dann habe ich folgende Gruppenrichtlinien-Verknüpfungen im gpmc angelegt:
DOMAIN (verknüpft mit den Default Richtlinien)
OU_Benutzer (verknüpft mit den gewünschten Richtlinien und Erbung der Defaults)
OU_Gruppen (verknüpft mit den gewünschten Richtlinien und Erbung der Defaults)
OU_Computer (keine Verknüpfung)
3) Die Gruppen wurden den Benutzern hinzugefügt
5) Polici ist aktiv
6) Gruppen sind aufgenommen
7) ja genau
8) richtig
9) DC? was ist das? Domain Computer? wenn ja, siehe 10)
10) hab ich auch versucht, funktionnierte auch, aber hatte nicht den Effekt, dass die Richtlinine übernommen wurden
11) Genau, sind alles Benutzereinstellungen
DOMAIN
OU_Benutzer
Benutzer_A
Benutzer_B
etc...
OU_Gruppen
Gruppe_A
Gruppe_B
etc...
OU_Computer
Computer_A
Computer_B
etc...
Dann habe ich folgende Gruppenrichtlinien-Verknüpfungen im gpmc angelegt:
DOMAIN (verknüpft mit den Default Richtlinien)
OU_Benutzer (verknüpft mit den gewünschten Richtlinien und Erbung der Defaults)
OU_Gruppen (verknüpft mit den gewünschten Richtlinien und Erbung der Defaults)
OU_Computer (keine Verknüpfung)
3) Die Gruppen wurden den Benutzern hinzugefügt
5) Polici ist aktiv
6) Gruppen sind aufgenommen
7) ja genau
8) richtig
9) DC? was ist das? Domain Computer? wenn ja, siehe 10)
10) hab ich auch versucht, funktionnierte auch, aber hatte nicht den Effekt, dass die Richtlinine übernommen wurden
11) Genau, sind alles Benutzereinstellungen
leg mal bitte ein neue ou an...nenn sie wie du es willst....verschiebe nun die OU_Gruppe und OU_Benutzer in diese ou...veknüpfe die Policy nun mit dieser ou...achte dabei auf die oben beschriebenen einstellungen...dann gpupdate auf beiden maschinen noch mal..zuerst DC (=DomainController)
w
meld dich ab und wieder an (client),
mach nen gpresult
w
meld dich ab und wieder an (client),
mach nen gpresult
auch kein Erfolg. Habe aber noch was komisches Herausgefunden:
Die Gruppenrichtline "GR_limited" sollte auf die Gruppe "limited" angewendet werden. Wenn ich jedoch einem Administrator die Gruppe "limited" zuweise/hinzufüge, und dann einen gpresult mache, so sagt er mir (ganz am schluss) dass die Richtlinie "GR_limited" nicht angewendet wurde und dass der Benutzer nicht Teil der Gruppe "limited" ist. Wie kann man sich das erklähren?
Die Gruppenrichtline "GR_limited" sollte auf die Gruppe "limited" angewendet werden. Wenn ich jedoch einem Administrator die Gruppe "limited" zuweise/hinzufüge, und dann einen gpresult mache, so sagt er mir (ganz am schluss) dass die Richtlinie "GR_limited" nicht angewendet wurde und dass der Benutzer nicht Teil der Gruppe "limited" ist. Wie kann man sich das erklähren?
das hat nicht funktioniert??
hmmm....da scheint dann etwas mehr in den fritten zu sein....
du bist dir sicher das DNS und co...in ordnung sind?
Du muss jetzt leider weg...
melde mich wieder.
Solltet Ihr hilfe benötigen.
schönes we
hmmm....da scheint dann etwas mehr in den fritten zu sein....
du bist dir sicher das DNS und co...in ordnung sind?
Du muss jetzt leider weg...
melde mich wieder.
Solltet Ihr hilfe benötigen.
schönes we
Dir auch schönen We
Vielen Dank nochmals für die Hilfe
Werde auch noch was rumbasteln und dann schmeiss ich den Server zum Fenster raus, vieleicht hilft das....
Vielen Dank nochmals für die Hilfe
Werde auch noch was rumbasteln und dann schmeiss ich den Server zum Fenster raus, vieleicht hilft das....
Tja, ich bringe das Ding immer noch nicht zum laufen....
Weiss jemand, ob es irgendwie noch ein "Testverfahren" gibt, das die Fehlerquelle etwas eingrenzt?
Weiss jemand, ob es irgendwie noch ein "Testverfahren" gibt, das die Fehlerquelle etwas eingrenzt?
liefern denn die RSOP am Server direkt den Ergebnisse?
hast du vieleicht irgend wo ein hacken "Gruppenrichtlinien Übernehmen" VERWEIGERN drin?
und du bist sicher das die benutzer auf die netlogon / sysvol freigaben zugreifen können?
evenlog schon durchsucht? - bitte mal am client und server nachschauen
PS.... schreib dir einmal die version (findest du im Sysvol-Ordner/GPO/gpt.ini) einer gpo auf - änder diese GPO - vergleich die versionen der geänderten gpo.
Hat sich die Zahl erhöht?
hast du vieleicht irgend wo ein hacken "Gruppenrichtlinien Übernehmen" VERWEIGERN drin?
und du bist sicher das die benutzer auf die netlogon / sysvol freigaben zugreifen können?
evenlog schon durchsucht? - bitte mal am client und server nachschauen
PS.... schreib dir einmal die version (findest du im Sysvol-Ordner/GPO/gpt.ini) einer gpo auf - änder diese GPO - vergleich die versionen der geänderten gpo.
Hat sich die Zahl erhöht?
Zitat von @Scratnut:
Also die Gruppe "Domänen-Benutzer" ist bei jedem
Account (auch den Admins) drin und kann auch nicht entfernt werden.
Also die Gruppe "Domänen-Benutzer" ist bei jedem
Account (auch den Admins) drin und kann auch nicht entfernt werden.
klar kann es...musst nur den focus auf eine andere Gruppe ändern
hab den ersten Fehler gefunden:
Ich habe die Profile kopiert von einer Vorlage (wegen den Desktopeinstellungen etc...) Dieses "Vorlagenprofil" ist jedoch derart veraltet, dass es irgendwas (was genau ist mir gelinde gesagt egal) nicht kapiert hat.
Lösung: Neues Profil anlegen lassen und dann klappt schon mal die Hälfte.
Was noch nicht geht:
wenn ich gpresult mache, dann zeigt er mir eine der Gruppen (jene auf welche die Richtlinie angewendet wird) nicht an. Sprich im letzten Abschnitt "Der Benutzer ist Mitglied in folgenden Sicherheitsgruppen:" Wird die besagte Gruppe nicht angezeigt!!
Kann man da was falsch machen??
Anmerkung: gpupdate /force nützt auch nix......
Ich habe die Profile kopiert von einer Vorlage (wegen den Desktopeinstellungen etc...) Dieses "Vorlagenprofil" ist jedoch derart veraltet, dass es irgendwas (was genau ist mir gelinde gesagt egal) nicht kapiert hat.
Lösung: Neues Profil anlegen lassen und dann klappt schon mal die Hälfte.
Was noch nicht geht:
wenn ich gpresult mache, dann zeigt er mir eine der Gruppen (jene auf welche die Richtlinie angewendet wird) nicht an. Sprich im letzten Abschnitt "Der Benutzer ist Mitglied in folgenden Sicherheitsgruppen:" Wird die besagte Gruppe nicht angezeigt!!
Kann man da was falsch machen??
Anmerkung: gpupdate /force nützt auch nix......
Nun ich hab mal den Fehler etwas genauer untersucht:
Das Profil welches Ich neu erstellt habe Funktionniert einwandfrei abgesehen von den Gruppenrichtlinien welche nicht erneuert werden. Also was habe ich gemacht.
1) Einen neuen account in AD erstellt mit Admin rechten. (Beinhaltet Gruppen Administrator und GR_limited)
2) einmal eingeloggt. (Die Admin-Rechte sind nötig, da nicht jeder in den Ordner mit den Profilen speichern darf)
2.1) Dabei wird ein neues Profil geschrieben.
2.2) Auftreten des ersten Fehlers: gpresult sagt, dass der Benutzer den ich da eingerichtet habe nicht der Gruppe GL_limited angehört!! Das kann man mal als LÜGE bezeichnen (der geübte Leser mag einen gewissen frustrierten Unterton in dieser Aussage finden)
3) Dem Benutzer werden die Admin Rechte gestrichen und nach ein und ausloggen dann
3.1) der 2te Fehler: gpresult meint immer noch dass der Benutzer Teil der Administratoren Gruppe ist. Alle anderen (von Hand erstellten) Gruppen werden immer noch nicht angezeigt. gpupdate /force hat auch nicht geklappt.
Hat jemand eine Idee hat woran es liegen könnte?
Das Profil welches Ich neu erstellt habe Funktionniert einwandfrei abgesehen von den Gruppenrichtlinien welche nicht erneuert werden. Also was habe ich gemacht.
1) Einen neuen account in AD erstellt mit Admin rechten. (Beinhaltet Gruppen Administrator und GR_limited)
2) einmal eingeloggt. (Die Admin-Rechte sind nötig, da nicht jeder in den Ordner mit den Profilen speichern darf)
2.1) Dabei wird ein neues Profil geschrieben.
2.2) Auftreten des ersten Fehlers: gpresult sagt, dass der Benutzer den ich da eingerichtet habe nicht der Gruppe GL_limited angehört!! Das kann man mal als LÜGE bezeichnen (der geübte Leser mag einen gewissen frustrierten Unterton in dieser Aussage finden)
3) Dem Benutzer werden die Admin Rechte gestrichen und nach ein und ausloggen dann
3.1) der 2te Fehler: gpresult meint immer noch dass der Benutzer Teil der Administratoren Gruppe ist. Alle anderen (von Hand erstellten) Gruppen werden immer noch nicht angezeigt. gpupdate /force hat auch nicht geklappt.
Hat jemand eine Idee hat woran es liegen könnte?
also die benutzer müssen vollzugriff auf ihre Profile haben...das ist ja wohl klar ..oder wie oder was...?
Ja Benutzer haben vollzugriff auf Ihre Profile aber nicht auf die darüberliegenden Ordner
Bspl
ORDNER_profile(nur lesezugriff für alle Benutzer)
UNTERORDNER_peter muster (vollzugriff für peter muster)
UNTERORDNER_lisa muster (vollzugriff für lisa muster)
Damit wird verhindert, dass peter oder lisa mich ärgern indem sie irgend einen beliebigen Ordner/files in den Ordner profile speichern.
Bspl
ORDNER_profile(nur lesezugriff für alle Benutzer)
UNTERORDNER_peter muster (vollzugriff für peter muster)
UNTERORDNER_lisa muster (vollzugriff für lisa muster)
Damit wird verhindert, dass peter oder lisa mich ärgern indem sie irgend einen beliebigen Ordner/files in den Ordner profile speichern.
