tag:blogger.com,1999:blog-6651313754316039486.post900512155024047394..comments2024-03-26T15:05:46.851+01:00Comments on What you can do, should do and should NOT do with GPOs: Wer bin ich und was darf ich - Gruppenmitgliedschaften und BenutzerrechteMartin Binderhttp://www.blogger.com/profile/10868219832141484922noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-6651313754316039486.post-8741656431494054272024-02-27T18:00:47.250+01:002024-02-27T18:00:47.250+01:00Patrick, schau mal bei www.mcseboard.de vorbei, da...Patrick, schau mal bei www.mcseboard.de vorbei, da bin ich fast täglich aktiv. Dann haben alle da was von den Antworten :-) Und der Austausch von Infos und Screenshots ist viel einfacher.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6651313754316039486.post-69077463864817490592024-02-27T12:16:27.980+01:002024-02-27T12:16:27.980+01:00Hallo Martin,
vielen Dank für den interessanten A...Hallo Martin,<br /><br />vielen Dank für den interessanten Ansatz zur Verwendung von lokalen Gruppen als zentralen Anker zur Zuweisung von Berechtigungen.<br /><br />Ich bin aktuell dabei, in unserem Unternehmen nach diesem Ansatz die Berechtigungen für ein AD Tiering vorzubereiten.<br />Hierzu verwende ich Umgebungsvariablen für die Tiers, PAW- / Server-/ und Clientobjekte, sowie Bezeichner für die jeweiligen Systeme / Systemverbund Computerobjekte, um eine Namenskonvention für AD Gruppen vorzugeben.<br />Der Vorteil, dass man granular Berechtigungen innerhalb einer einzigen GPO setzen und Namensstandards forcieren kann, ist sehr hilfreich.<br /><br />Auch ich habe in einer Testumgebung angefangen und kann sagen, dass das automatische Befüllen der Gruppen mit Parametern gut funktioniert, wenn die Umgebungsvariablen vorhanden sind.<br /><br />Ein einziger Wermutstropfen:<br />Sobald ich ein GPRESULT /H abgebe, sehe ich in den Ergebnissen für die anzulegenden Gruppen und bei der Aufnahme von Gruppen in die lokalen Gruppen "Ergebnis: Fehler (Fehlercode: 0x8007089a)", höchstwahrscheinlich aufgrund der Gruppenangabe %Computername%\CORP-LogonLocally.<br />Beim Anlegen der Lokalen Gruppen ist %Computername% nötig ist, da die Gruppen sonst nicht erstellt werden.<br /><br />Wenn ich die Gruppen angelegt habe und bei der Aufnahme von AD Gruppen den Gruppenname ohne %Computername% angebe, wird eine Erfolgsmeldung zurückgegeben.<br /><br />Bsp: Gruppenname "CORP-LogonLocally" - Aktion "Aktualisieren" - Hinzufügen "CORP\%Tier%-ADM-%Systemverbund%" -> Erfolgreich<br /><br />Hast Du möglicherweise weitere Hinweise, die bei der Realisierung dieses Umfangreichen Unterfangens helfen können, oder hast Du weitere Stolpersteine bei der Umsetzung gefunden, die möglicherweise auch auf mich zukommen werden?<br />Auch aus Sicherheitssicht bin ich am eruieren, ob sich mögliche Angriffsvektoren ergeben, die ich gegebenenfalls abfangen muss.<br />Falls Du dazu bereits auch Erkenntnisse hast, würde ich mich freuen, wenn Du sie mit mir / uns teilen magst.<br /><br /><br />Viele Grüße<br />PatrickAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6651313754316039486.post-50621195812820288262019-10-18T07:41:04.610+02:002019-10-18T07:41:04.610+02:00Hi Martin,
erst einmal ganz herzlichen Dank für d...Hi Martin,<br /><br />erst einmal ganz herzlichen Dank für die schnelle Rückantwort.<br />Die Fehlermeldung erscheint auf den Memberservern auf denen die neuen Gruppen erzeugt werden sollen...<br /><br />Ich hab das in meinem LAB jetzt auch ohne die UV %ComputerName% belassen und verhindere zusätzlich noch über die Zielgruppenadressierung, dass DCs das Ding ziehen.<br /><br />Dein Angebot, Dich per Mail zu kontaktieren, werde ich mit 100%iger Sicherheit in Anspruch nehmen und möchte mich vorab dafür sehr herzlich bedanken. Insbesondere interessiert mich, wie du die GPO per Zielgruppenadressierung für Server und Client unterscheidest um bspw. zu verhindern, dass sich %ComputerName%-Admins bzw. %SrvRole%-Admins nicht an Clients anmelden dürfen. ;)<br /><br />Also ich komme definitiv auf dein Angebot zurück!!!<br /><br />VGAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6651313754316039486.post-45136387943146465412019-10-17T21:41:01.370+02:002019-10-17T21:41:01.370+02:00Hallo Erich.
Kommt der Fehler auf DCs oder auf Mem...Hallo Erich.<br />Kommt der Fehler auf DCs oder auf Member Servern? Davon unabhängig: Ich lasse das %Computername%\ inzwischen weg, das klappt. Und als Gruppenname verwende ich einfach den Namen des zugehörigen Rechts, hier also seInteractiveLogonPrivilege.<br />In unserer aktuellen Umgebung mache ich das für ALLE Benutzerrechte (47 Stück), und das funktioniert prima.<br />Du kannst mir auch gerne mal ne Mail dazu schreiben, wenn ich helfen kann:<br />martin<br />unterstrich<br />binder<br />at<br />outlook<br />punkt<br />de<br />:-))Martin Binderhttps://www.blogger.com/profile/10868219832141484922noreply@blogger.comtag:blogger.com,1999:blog-6651313754316039486.post-201506576488096142019-10-17T10:44:35.862+02:002019-10-17T10:44:35.862+02:00Hallo Martin,
ich finde den Ansatz dieses Artikel...Hallo Martin,<br /><br />ich finde den Ansatz dieses Artikels sehr interessant und wollte das Ganze vor einem produktiven Einsatz erstmal in einem LAB austesten.<br /><br />Irgendwie stoße ich da allerdings beim Anlegen der lokalen Gruppen auf den jeweiligen Servern auf eine unschöne Fehlermeldung im EventLog, bei der ich nicht wirklich weiter komme und hoffe hier eine Antwort auf dieses Problem zu finden ;)<br /><br />Du legst die lokalen Gruppen explizit unter Angabe der %ComputerName%-Umgebungsvariable nach dem Muster %ComputerName%\CORP-LogonLocally an und begründest dies mit der Tatsache, dass so auf DCs (sofern ihnen die GPO zugewiesen wird) keine domänenlokale Gruppen erzeugt werden.<br /><br />Und genau dabei kommt es bei mir zum Fehler:<br /><br />Das Computer "LAB-LogonLocally erstellen"-Einrichtungselement im Gruppenrichtlinienobjekt "Server Security" wurde aufgrund eines Fehlers nicht angewendet. Fehlercode "0x8007089a Der angegebene Benutzername ist unzulässig"<br /><br />Ich verwende hier folgende Syntax innerhalb der GPP %ComputerName%\LogonLocally<br /><br />Entferne ich die UV %ComputerName% und belasse einfach LogonLocally wird die Gruppe ordnungsgemäß auf den Servern angelegt...<br /><br />Zwar könnte ich dafür sorgen, dass die GPO definitiv nicht auf DCs angewendet wird, finde aber Deinen Ansatz deutlich eleganter...<br /><br />Any Idea?<br /><br />Vorab ganz herzlichen Dank!<br /><br />Gruß ErichAnonymousnoreply@blogger.com