9
GPO für Anmelden als Dienst korrekt einstellen
Hi,
ich hab in einer Testdomäne eine GPO angelegt, die einem bestimmten Benutzer das Recht "Anmelden als Dienst" zuweist.
Diese war dann kontraproduktiv, die Dienste eines SQL Servers starten nicht auf einem Domänenmitglied nach Aktivierung der GPO
Muß ich in die GPO noch generische Gruppen mit aufnehmen?
Und wenn ja wie heißen die?
ich hab in einer Testdomäne eine GPO angelegt, die einem bestimmten Benutzer das Recht "Anmelden als Dienst" zuweist.
Diese war dann kontraproduktiv, die Dienste eines SQL Servers starten nicht auf einem Domänenmitglied nach Aktivierung der GPO
Muß ich in die GPO noch generische Gruppen mit aufnehmen?
Und wenn ja wie heißen die?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 387783
Url: https://administrator.de/forum/gpo-fuer-anmelden-als-dienst-korrekt-einstellen-387783.html
Ausgedruckt am: 08.04.2025 um 09:04 Uhr
9 Kommentare
Neuester Kommentar
Moin,
wie bitte? Kannst Du das Problem bitte so schildern, dass man es auch versteht?
Was willst Du erreichen? Welche Fehlermeldungen gibt es? Welche Software wird eingesetzt? Usw. usf.
Liebe Grüße
Erik
wie bitte? Kannst Du das Problem bitte so schildern, dass man es auch versteht?
Was willst Du erreichen? Welche Fehlermeldungen gibt es? Welche Software wird eingesetzt? Usw. usf.
Liebe Grüße
Erik
die Dienste starten nicht mehr mit einer Meldung daß der Login typ 5 für das Benutzerkonto nicht erlaubt ist, ds zum Starten des Diesntes verwendet wurde.
Das Setup vom SQL server erstellt drei lokale Benutzerkonten und erteilt diesen Benutzern das Recht "Anmelden als Dienst".
Diese tauchen auch in der lokalen Sicherheitsrichtlinie auf... nachdem ich die GPO aktiviere sind die weg und man sieht nur noch das AD Konto, dem ich die Rechte in der GPO gegeben hab.
Ohne das Recht ist nur der Login typ 2 erlaubt (interaktives Login).
Das Probelm taucht natürlich acuh mit anderen Serverdiensten auf.
Das Setup vom SQL server erstellt drei lokale Benutzerkonten und erteilt diesen Benutzern das Recht "Anmelden als Dienst".
Diese tauchen auch in der lokalen Sicherheitsrichtlinie auf... nachdem ich die GPO aktiviere sind die weg und man sieht nur noch das AD Konto, dem ich die Rechte in der GPO gegeben hab.
Ohne das Recht ist nur der Login typ 2 erlaubt (interaktives Login).
Das Probelm taucht natürlich acuh mit anderen Serverdiensten auf.
Moin,
Und warum änderst Du das und lässt es nicht so, wie es die Installationsroutine angelegt hat? Was willst Du erreichen?
Liebe Grüße
Erik
Zitat von @GrueneSosseMitSpeck:
Das Setup vom SQL server erstellt drei lokale Benutzerkonten und erteilt diesen Benutzern das Recht "Anmelden als Dienst".
Diese tauchen auch in der lokalen Sicherheitsrichtlinie auf... nachdem ich die GPO aktiviere sind die weg und man sieht nur noch das AD Konto, dem ich die Rechte in der GPO gegeben hab.
Das Setup vom SQL server erstellt drei lokale Benutzerkonten und erteilt diesen Benutzern das Recht "Anmelden als Dienst".
Diese tauchen auch in der lokalen Sicherheitsrichtlinie auf... nachdem ich die GPO aktiviere sind die weg und man sieht nur noch das AD Konto, dem ich die Rechte in der GPO gegeben hab.
Und warum änderst Du das und lässt es nicht so, wie es die Installationsroutine angelegt hat? Was willst Du erreichen?
Liebe Grüße
Erik
Zitat von @GrueneSosseMitSpeck:
Das Setup vom SQL server erstellt drei lokale Benutzerkonten und erteilt diesen Benutzern das Recht "Anmelden als Dienst".
Das Setup vom SQL server erstellt drei lokale Benutzerkonten und erteilt diesen Benutzern das Recht "Anmelden als Dienst".
Moin,
welcher SQL Server ist das? Keiner meiner bisher installierten MS SQL Server (2000 - 2014) hat so etwas gemacht.
Gruss
Moin,
Doch schon. Naja, nicht der Server selbst, sondern die DB-Anwendungen machen sowas. Hier laufen z. B. zwei, bei denen eine drei, die andere einen lokalen User braucht. Die Frage ist, warum man sowas ändern will.
Liebe Grüße
Erik
Zitat von @sabines:
welcher SQL Server ist das? Keiner meiner bisher installierten MS SQL Server (2000 - 2014) hat so etwas gemacht.
welcher SQL Server ist das? Keiner meiner bisher installierten MS SQL Server (2000 - 2014) hat so etwas gemacht.
Doch schon. Naja, nicht der Server selbst, sondern die DB-Anwendungen machen sowas. Hier laufen z. B. zwei, bei denen eine drei, die andere einen lokalen User braucht. Die Frage ist, warum man sowas ändern will.
Liebe Grüße
Erik
Nee, er schreibt das Setup des SQL Servers macht das.
Wenn eine DB andere User als den SA braucht (was gängige Praxis ist), dann lässt man ein Script laufen und gut ist.
An den Einstellungen des SQL Servers ändert man eher nichts.
Wenn eine DB andere User als den SA braucht (was gängige Praxis ist), dann lässt man ein Script laufen und gut ist.
An den Einstellungen des SQL Servers ändert man eher nichts.
Hi.
Ganz einfach: wenn du diese Policy auf Systemen anwendest, dann wird die dort gesetzte Einstellung überschrieben. Du musst also dafür sorgen, dass diese GPO entweder
A nicht überall angewendet wird oder
B dass die Konten, die nun überschrieben wurden, von der GPO wieder gesetzt werden.
Diese Konten rauszufinden kannst nur Du, bzw. dein Backup.
Ganz einfach: wenn du diese Policy auf Systemen anwendest, dann wird die dort gesetzte Einstellung überschrieben. Du musst also dafür sorgen, dass diese GPO entweder
A nicht überall angewendet wird oder
B dass die Konten, die nun überschrieben wurden, von der GPO wieder gesetzt werden.
Diese Konten rauszufinden kannst nur Du, bzw. dein Backup.
Und dass soll ich glauben.
Ich vermute mal, das ist eine DB-Anwendung, die den SQL gleich mitinstalliert.Wenn eine DB andere User als den SA braucht (was gängige Praxis ist), dann lässt man ein Script laufen und gut ist.
An den Einstellungen des SQL Servers ändert man eher nichts.
An den Einstellungen des SQL Servers ändert man eher nichts.
Deshalb ja auch meine Frage an den TO, was er damit erreichen will bzw. warum er da überhaupt dran fummelt.
Hi,
es verhält sich, wie DWW schon schreibt.
Kurz zur Erklärung:
Es gibt Einstellungen, bei welchen man Gruppen und/oder Benutzer angeben kann, welche dann irgendwas dürfen oder irgendwo Mitglied sein sollen. Spontan fallen mir dazu die "eingschränkten Gruppen" und die Privilegien (Sicherheitseinstellungen) ein. Bei denen verhält es sich so, dass die in der GPO angegebenen Gruppen und/oder Benutzer nicht zu den lokalen Einstellungen hinzugefügt werden, sondern die lokalen Einstellungen durch die in der GPO angegeben Einstellungen komplett ersetzt werden.
Im Bsp. des TO hat der TO mit der GPO dem "bestimmten Benutzer" nicht das Recht "Anmelden als Dienst" erteilt, sondern dem Computer mitgeteilt, dass er bei Anwendung dieser GPO nur "bestimmten Benutzer" für das Privileg "Anmelden als Dienst" eintragen soll. Die alte Einstellung für dieses Privileg verwirft der Computer dabei. D.h. die SQL-Server, welche diese GPO - sicherlich ungeplant - angewendet haben, haben ihre lokalen Einstellungen für dieses Privileg komplett verworfen und da jetzt nur noch "bestimmten Benutzer" drin stehen. Diese Einstellung ist "tattooing", dafür gibt es kein "UnDo". Wenn man dafür sorgt, dass die GPO nicht mehr für die SQL-Server gilt, dann steht da trotzdem weiterhin nur noch "bestimmten Benutzer" drin. Entweder man korrigiert das dann an jedem einzelnen betroffenen Computer oder man erstellt eine "Gegen-GPO", welche das für diese Computer wieder so einstellt, wie es vorher war.
It's not a bug, it's a feature. Dieses muss man kennen wenn man mit diesen GPO-Einstellungen hantiert.
E.
Edit: Gleiches gilt z.B. für die NTFS- oder Registry-Rechte, welche man per GPO verteilen kann.
es verhält sich, wie DWW schon schreibt.
Kurz zur Erklärung:
Es gibt Einstellungen, bei welchen man Gruppen und/oder Benutzer angeben kann, welche dann irgendwas dürfen oder irgendwo Mitglied sein sollen. Spontan fallen mir dazu die "eingschränkten Gruppen" und die Privilegien (Sicherheitseinstellungen) ein. Bei denen verhält es sich so, dass die in der GPO angegebenen Gruppen und/oder Benutzer nicht zu den lokalen Einstellungen hinzugefügt werden, sondern die lokalen Einstellungen durch die in der GPO angegeben Einstellungen komplett ersetzt werden.
Im Bsp. des TO hat der TO mit der GPO dem "bestimmten Benutzer" nicht das Recht "Anmelden als Dienst" erteilt, sondern dem Computer mitgeteilt, dass er bei Anwendung dieser GPO nur "bestimmten Benutzer" für das Privileg "Anmelden als Dienst" eintragen soll. Die alte Einstellung für dieses Privileg verwirft der Computer dabei. D.h. die SQL-Server, welche diese GPO - sicherlich ungeplant - angewendet haben, haben ihre lokalen Einstellungen für dieses Privileg komplett verworfen und da jetzt nur noch "bestimmten Benutzer" drin stehen. Diese Einstellung ist "tattooing", dafür gibt es kein "UnDo". Wenn man dafür sorgt, dass die GPO nicht mehr für die SQL-Server gilt, dann steht da trotzdem weiterhin nur noch "bestimmten Benutzer" drin. Entweder man korrigiert das dann an jedem einzelnen betroffenen Computer oder man erstellt eine "Gegen-GPO", welche das für diese Computer wieder so einstellt, wie es vorher war.
It's not a bug, it's a feature. Dieses muss man kennen wenn man mit diesen GPO-Einstellungen hantiert.
E.
Edit: Gleiches gilt z.B. für die NTFS- oder Registry-Rechte, welche man per GPO verteilen kann.
1
