9
Administratorrechte an Benutzer innerhalb der Domain übertragen
Hallo Zusammen,
ich habe folgendes "Problem", welches ich zwar anderweitig selbst lösen kann allerdings würde ich trotzdem gerne wissen warum ich erstmal so nicht weiterkomme.
Umgebung:
Windows Server 2019 gleichzeitig der Domänencontroller
Windows 10 - Client
Mit dem Windows 10 Client befinde ich mich in besagter Domäne, wenn ich nun gewisse Windows-Einstellungen verändern möchte ploppt die Benutzerkontensteuerung auf und ich regelte das bisher immer mit dem "Administrator"-Konto.
Nun wollte ich den Administrator allerdings für so etwas ruhen lassen und einen Benutzer aus der Organisation, also mich selbst mit erhöhten Rechten ausstatten.
Ich ging also in die Active Directory und machte den besagten Benutzer zum Mitglied der Gruppe "Domänen-Admins", desweiteren ist er auch immer noch in der Gruppe "Domänen-Benutzer".
Wenn ich nun meinen Benutzer in der Benutzerkontensteuerung eintrage erscheint immer die Meldung "Dieser Vorgang erfordert erhöhte Rechte".
Ich habe mir mal den Administrator in der AD angesehen und festgestellt dass dieser noch Mitglied von ein paar Gruppen mehr ist:
Administratoren
Domänen-Admins
Domänen-Benutzer
Organisations-Admins
Richtlinien-Ersteller-Besitzer
Schema-Admins
Wenn ich nun zum Test einen komplett neuen Benutzer in der AD unter "Users" erstelle, dort wo also auch der Administrator liegt, und diesen dann in "Domänen-Admins" eintrage klappt es und ich kann mit diesen neuen Benutzer auf dem Client die Einstellungen tätigen.
Wieso klappt es mit meinem eigenen Benutzer nicht? Was mache ich falsch oder übersehe ich?
ich habe folgendes "Problem", welches ich zwar anderweitig selbst lösen kann allerdings würde ich trotzdem gerne wissen warum ich erstmal so nicht weiterkomme.
Umgebung:
Windows Server 2019 gleichzeitig der Domänencontroller
Windows 10 - Client
Mit dem Windows 10 Client befinde ich mich in besagter Domäne, wenn ich nun gewisse Windows-Einstellungen verändern möchte ploppt die Benutzerkontensteuerung auf und ich regelte das bisher immer mit dem "Administrator"-Konto.
Nun wollte ich den Administrator allerdings für so etwas ruhen lassen und einen Benutzer aus der Organisation, also mich selbst mit erhöhten Rechten ausstatten.
Ich ging also in die Active Directory und machte den besagten Benutzer zum Mitglied der Gruppe "Domänen-Admins", desweiteren ist er auch immer noch in der Gruppe "Domänen-Benutzer".
Wenn ich nun meinen Benutzer in der Benutzerkontensteuerung eintrage erscheint immer die Meldung "Dieser Vorgang erfordert erhöhte Rechte".
Ich habe mir mal den Administrator in der AD angesehen und festgestellt dass dieser noch Mitglied von ein paar Gruppen mehr ist:
Administratoren
Domänen-Admins
Domänen-Benutzer
Organisations-Admins
Richtlinien-Ersteller-Besitzer
Schema-Admins
Wenn ich nun zum Test einen komplett neuen Benutzer in der AD unter "Users" erstelle, dort wo also auch der Administrator liegt, und diesen dann in "Domänen-Admins" eintrage klappt es und ich kann mit diesen neuen Benutzer auf dem Client die Einstellungen tätigen.
Wieso klappt es mit meinem eigenen Benutzer nicht? Was mache ich falsch oder übersehe ich?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1182705440
Url: https://administrator.de/contentid/1182705440
Printed on: April 24, 2024 at 15:04 o'clock
9 Comments
Latest comment
Okay, sorry....
Ein Restart des Clients und wahrscheinlich die daraus resultiernde Neuanmeldung des Benutzers brachte den gewünschten Erfolg
Ein Restart des Clients und wahrscheinlich die daraus resultiernde Neuanmeldung des Benutzers brachte den gewünschten Erfolg
Echt jetzt?
"und machte den besagten Benutzer zum Mitglied der Gruppe "Domänen-Admins""
Da macht man einen lokalen Admin für den/die Clients.
"und machte den besagten Benutzer zum Mitglied der Gruppe "Domänen-Admins""
Da macht man einen lokalen Admin für den/die Clients.
Hallo.
Ein Hinweis der Warnung:
Einem Benutzer diese Gruppen zu zuweisen kann Probleme machen.
Da es bei dir wahrscheinlich um eine Testumgebung handelt nicht weiter schlimm, aber so etwas sollte man nicht in produktiven Systemen konfigurieren.
Beispielsweise Active Sync zu einem Exchange Server funktioniert nicht aufgrund der vererbten Berechtigungen innerhalb der Domäne.
Generell gilt aber:
Einem Benutzer lokale Admin-Rechte zu geben ist aus Sicht der Sicherheit nie eine gute Idee.
Früher benötigten Anwendungen wie Datev oder CAD/CAM Programme immer lokale, administrative Rechte, das ist aber zum Glück weitestgehend nicht mehr der Fall.
Gruß
Marc
Ein Hinweis der Warnung:
Einem Benutzer diese Gruppen zu zuweisen kann Probleme machen.
Da es bei dir wahrscheinlich um eine Testumgebung handelt nicht weiter schlimm, aber so etwas sollte man nicht in produktiven Systemen konfigurieren.
Beispielsweise Active Sync zu einem Exchange Server funktioniert nicht aufgrund der vererbten Berechtigungen innerhalb der Domäne.
Generell gilt aber:
Einem Benutzer lokale Admin-Rechte zu geben ist aus Sicht der Sicherheit nie eine gute Idee.
Früher benötigten Anwendungen wie Datev oder CAD/CAM Programme immer lokale, administrative Rechte, das ist aber zum Glück weitestgehend nicht mehr der Fall.
Gruß
Marc
Zitat von @Xerebus:
Echt jetzt?
"und machte den besagten Benutzer zum Mitglied der Gruppe "Domänen-Admins""
Da macht man einen lokalen Admin für den/die Clients.
Echt jetzt?
"und machte den besagten Benutzer zum Mitglied der Gruppe "Domänen-Admins""
Da macht man einen lokalen Admin für den/die Clients.
Und/ oder richtet einen eigenständigen User für administrative Zwecke ein.
Mal angenommen D. Ilbert ist der IT-Administrator im Unternehmen.
hat sein User dilbert Adminrechte (egal ob lokal oder domainweit) und er fängt sich etwas ein, hat das mitunter weitreichende Konsequenzen.
Wenn D. Ilbert aber einen zusätzlichen Admin-User hat (adm_di), sind die Auswirkungen bei einer Infektion über den User dilbert geringer, da der User dilbert keine (globalen) Adminrechte hat.
Gruß
em-pie
2
Danke für die Hinweise, ich erstelle dann tatsächlich einen neuen User für diese Zwecke
Zitat von @jstar5588:
Okay, sorry....
Ein Restart des Clients und wahrscheinlich die daraus resultiernde Neuanmeldung des Benutzers brachte den gewünschten Erfolg
Okay, sorry....
Ein Restart des Clients und wahrscheinlich die daraus resultiernde Neuanmeldung des Benutzers brachte den gewünschten Erfolg
Das ist auch kein Wunder. Änderungen am Benutzer im AD greifen erst, wenn der Benutzer sich abmeldet und am AD wieder frisch anmeldet.
Zitat von @jstar5588:
Ich ging also in die Active Directory und machte den besagten Benutzer zum Mitglied der Gruppe "Domänen-Admins", desweiteren ist er auch immer noch in der Gruppe "Domänen-Benutzer".
Wenn ich nun meinen Benutzer in der Benutzerkontensteuerung eintrage erscheint immer die Meldung "Dieser Vorgang erfordert erhöhte Rechte".
Ich habe mir mal den Administrator in der AD angesehen und festgestellt dass dieser noch Mitglied von ein paar Gruppen mehr ist:
Administratoren
Domänen-Admins
Domänen-Benutzer
Organisations-Admins
Richtlinien-Ersteller-Besitzer
Schema-Admins
Ich ging also in die Active Directory und machte den besagten Benutzer zum Mitglied der Gruppe "Domänen-Admins", desweiteren ist er auch immer noch in der Gruppe "Domänen-Benutzer".
Wenn ich nun meinen Benutzer in der Benutzerkontensteuerung eintrage erscheint immer die Meldung "Dieser Vorgang erfordert erhöhte Rechte".
Ich habe mir mal den Administrator in der AD angesehen und festgestellt dass dieser noch Mitglied von ein paar Gruppen mehr ist:
Administratoren
Domänen-Admins
Domänen-Benutzer
Organisations-Admins
Richtlinien-Ersteller-Besitzer
Schema-Admins
Es ist eine ganz schlechte Idee, einen regulären User zum Admin zu machen. Standard ist es, dafür extra einen extra Admin-User anzulegen.
Wenn Du alsr regulärer User administrative Rechte hast, kann Dir Malware ganz einfach Tretminen unterschieben. Und das geht sogar so, daß Du es trotz UAC nicht merkst.
lks
2
Kleine Anmerkung:
MS selbst sagt, Ich habe den Link leider nicht gespeichert, das UAC KEIN sicherheitsfeature ist!
Es ist dafür gedacht das Anwender:innen darauf hingewiesen werden das sie was starten damit.
Der "echte " Administrator hat die UAC aber zB gar nicht.
Wie lästerte ein Linux Admin einmal gegenüber einem Admin von MS der dem nicht widersprach:
Unter Windows sind die unterschiedlichen Benutzerkonten weniger zu Sicherheitszwecken (administrator einmal ausgenommen) als vielmehr zu organisatorischen Zwecken.
Damit nicht User 1 auf die privaten Daten von User 2 kommt.
Wer versucht hat unter Linux einmal Daten zu sichern wo das PW abhanden gekommen ist..
Es geht. Aber der aufwand ist GANZ anders als unter Windows
Davon einmal abgesehen.
Änderungen an Benutzerkonten sind IMMER nur gültig NACH der Abmeldung zw wiederanmeldung.
Mein cent
MS selbst sagt, Ich habe den Link leider nicht gespeichert, das UAC KEIN sicherheitsfeature ist!
Es ist dafür gedacht das Anwender:innen darauf hingewiesen werden das sie was starten damit.
Der "echte " Administrator hat die UAC aber zB gar nicht.
Wie lästerte ein Linux Admin einmal gegenüber einem Admin von MS der dem nicht widersprach:
Unter Windows sind die unterschiedlichen Benutzerkonten weniger zu Sicherheitszwecken (administrator einmal ausgenommen) als vielmehr zu organisatorischen Zwecken.
Damit nicht User 1 auf die privaten Daten von User 2 kommt.
Wer versucht hat unter Linux einmal Daten zu sichern wo das PW abhanden gekommen ist..
Es geht. Aber der aufwand ist GANZ anders als unter Windows
Davon einmal abgesehen.
Änderungen an Benutzerkonten sind IMMER nur gültig NACH der Abmeldung zw wiederanmeldung.
Mein cent
Wie hat Fefe UAC mal beschrieben:
Genau so muss man übrigens UAC ("Wollen Sie wirklich?"-Prompts von Windows seit Vista) sehen. Das ist alles unsicher und ein Einfallstor, aber die Arbeitsprozesse brechen zusammen, wenn man das ordentlich macht, und die Kunden von Microsoft wollen es nicht ordentlich sondern die wollen weiter pfuschen. Also kommt da ein Knopf hin. Damit Microsoft im Zweifelsfall auf den Knopf zeigen kann. Schaut her, sagen sie dann, da hat der User drauf geklickt. Selber Schuld.
Genau so muss man übrigens UAC ("Wollen Sie wirklich?"-Prompts von Windows seit Vista) sehen. Das ist alles unsicher und ein Einfallstor, aber die Arbeitsprozesse brechen zusammen, wenn man das ordentlich macht, und die Kunden von Microsoft wollen es nicht ordentlich sondern die wollen weiter pfuschen. Also kommt da ein Knopf hin. Damit Microsoft im Zweifelsfall auf den Knopf zeigen kann. Schaut her, sagen sie dann, da hat der User drauf geklickt. Selber Schuld.
Dafür legt man eine GPO an, welche alle lokalen User deaktiviert. Anschließend rollt man LAPS aus welches ein rollierendes Passwort für lokale Accounts vergibt, das man dem User auch temporär geben kann weil es nach 3 Monate wechselt.
[optional] Dann ernennt man Keyuser welche auf ausgesuchten Maschine dauerhaft lokale Adminrechte bekommen.
[optional] Dann ernennt man Keyuser welche auf ausgesuchten Maschine dauerhaft lokale Adminrechte bekommen.
