PrometricDriver
-
Gesamte Inhalte
12 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von PrometricDriver
-
-
Am 4.10.2020 um 22:53 schrieb daabm:
Fast
Ich hab ein Startskript, das den Namen und den DN der OU in eine Umgebungsvariable schreibt. Kurzname in Deinem Beispiel "WEBSERVICE", DN dann OU=Webservice,OU=irgendwas,DC=contoso.
Die Gruppen in der GPO sind generische definiert als %ServiceOU%-Admins, %ServiceOU%-Users etc. Die Zielgruppenadressierung geht auf nen sAMAccountName %ServiceOU%-Admins mit ner Searchbase von LDAP://%ServiceOUDN%. GPP löst diese Variablen zur Laufzeit auf (was ja in den "alten" Benutzerrechten nicht geht).
Die GPO hängt über allen Services. Leg ne neue OU an, steck nen Server rein. Nach dem ersten Reboot sind die Umgebungsvariablen da, nach dem 2. Reboot stimmen die Benutzerrechte.
Der Rest (diese 47 Rechtegruppen) funktioniert nach dem gleichen Schema.
Jeder Service hat natürlich auch ne Standardgruppe für Serviceaccounts - Du ahnst es schon, %ServiceOU%-ServiceAccounts. Die stecken in der seServiceLogonRight Gruppe (und in seBatchLogonRight). Das kann man beliebig granular weiter runterbrechen, aber Admins, Users, Serviceaccounts reichte uns.
Ich glaub, ich muß da mal ne Blogpost dazu machen
Die Gruppen dürfen nur Domain Admins bearbeiten - und der Service Account des IDM, über das man die zugehörigen Rollen beantragt. Da es aber immer nach "Schema F" läuft, ist sogar das relativ easy.
PS: Die Gruppennamen bei uns sind anders - wir haben noch ein paar Prä- und Postfixe. Aber für das Prinzip spielt das keine Rolle.
So... Antwort hat bissel auf sich warten lassen, weil ich das jetzt mal in einem kleinen LAB nachgestellt hab.
Was soll ich sagen?! Einfach nur genial und eigentlich auch genau das was ich gesucht hab, weil übelst granular steuerbar. Eben auch, weil es hier "Dienstüberschneidungen" gibt und man das mit dieser Herangehensweise unglaublich fein berechtigen kann.
Vor allem aber mit nur einer einzigen GPO
Als Startup-Script dient jetzt ein kleines Powershellscript. An das bin ich bissel vorschnell ran ohne bedacht zu haben, dass ja nicht jeder Server per se das Powershell-Modul für ADDS installiert hat. Hat aber auch wunderbar mit ADSI umd CIM funktioniert. Das ergänzt eben die notwendigen Umgebungsvariablen über die dann die GPP wirkt.
Nochmal ganz herzlichen Dank für diesen grandiosen Input
-
2
-
-
vor 14 Stunden schrieb daabm:
Der Link läuft vermutlich ziemlich vielen über den Weg - nur verstehen leider auch ziemlich viele nicht, was darin für Möglichkeiten liegen, diese lästige Delegation von Admin-Rechten zu vereinfachen. Aber wie schon mehrfach geschrieben wurde: Gut, daß wieder einer anfängt, den alten Kram aufzuräumen
BTW: Wir haben im aktuellen Neu-Design nur noch eine Policy, die Admin- und User-Rechte auf allen (!) Member-Servern regelt. Alle Server eines "Service" liegen in einer OU. Für diese OU wird eine Umgebungsvariable gebildet (Startskript). Und diese Variable ist auch Bestandteil der Namen der delegierten Admin- und Usergruppen. Neuer Service? Kein Problem - OU anlegen, Maschine reindeployen. Gruppen anlegen, fertig. GPO ist schon da... Und natürlich hat diese GPO für alle delegierten Gruppen eine Zielgruppenadressierung - die Gruppe MUSS sich in der OU befinden, in der auch der Server ist (LDAP-Filter - braucht keine 5 ms). Sonst könnte ja wer irgendwo anders eine entsprechende Gruppe anlegen.
Zum Verständnis und mitschreiben... Du beschreibst im o.g. Link unten bei den Kommentaren, dass du pro lokales User-Right lokal eine Gruppe auf den Member-Servern anlegst.
Sprich SeNetworkLogonRight, SeInteractiveLogonRight etc. (insgesamt 47 UserRights) als lokale Gruppe in der GPO.
Du gruppierst die entsprechenden Maschinen nach angebotenem "Service", bspw. hast Du eine Webapplikation bestehend aus einem Webserver und einem Datenbankserver die beide in diese
OU wandern. Die OU nennt sich exemplarisch "WEBSERVICE" und beim Booten der Maschine nach dem Deployment innerhalb der OU greift EINE GPO die einerseits ein Startup-Script ausführt, welches Umgebungsvariablen anlegt (LDAP-Path = ServiceName, LDAP-Folder = LDAP-Pfad zum Service und dessen Objekten).
Du legst innerhalb dieser Service-OU globale Gruppen an die in etwa so lauten... GG_WEBSERVICE_SERVERADMINS, GG_WEBSERVICE_RDP, GG_WEBSERVICE_SERVICEACCOUNTS...
Beim Befüllen der lokalen Gruppen auf den Servern löschst Du bspw. die lokalen Administratoren, nimmst in einem zweiten Schritt den lokalen Admin und zusätzlich eine Gruppe "GG_%OUFOLDER%_SERVERADMINS " mit einer Zielgruppenadressierung die auf den LDAP-Pfad und den Gruppennamen zeigt (also in etwa LDAP://%OUPATH%/GG_%OUFOLDER%_SERVERADMINS)?!
Und im GPO-Template steht beim "Zuweisen von Benutzerrechten" zusätzlich bei bspw. "Anmelden als Dienst" dann bspw. seServiceLogonRight um der gleichnamigen lokalen Gruppe dann das Recht zu geben, als Dienst starten zu dürfen? Bei der Verlinkung im GPMC überschreibt dann diese GPO die UserRights von ggfs. verlinkten Baseline-GPOs, die Emfehlungen von Microsoft wer welche Rechte bekommen sollte übernimmst Du in diese Master-GPO (mir fällt kein besserer Begriff dafür ein)
Wenn ja frage ich mich zweierlei...
Du schreibst oben EINE GPO, die Du ja an irgendeiner "BASE" verlinken musst. Deine Service-OUs wären ja dann Sub-OUs und erben diese eine GPO. (oder verlinkst du die pro Sub-OU?!)
Angenommen Du benötigst jetzt einen gMSA den Du nur auf den beiden Maschinen innerhalb von "WEBSERVICE" installierst... Wie bildest Du sowas ab? Neue GPO mit Abweichungen von der Regel, welche nur an der Service-OU verlinkt wird oder innerhalb der Master-GPO mit Zielgruppenadressierung?
und... Wie handhabt ihr das dann mit der Delegation. Wer darf die Gruppen in der Ziel-OU bearbeiten und mit Usern füllen?
Also wenn ich das alles richtig verstanden hab, dann wäre das ja übelst fein steuerbar
-
vor 1 Stunde schrieb MurdocX:
Veränderungen sind b***d, denn man hat’s ja schon immer anderst gemacht.
Viel erreichen kannst du mit dem AppLocker und der Tier-Trennung. Wobei bei Letzterem schon viel mit verschieben Admin-Accounts auf Dom, Server und Clients getan ist. Der Weg ist der Richtige
Tier-Trennung definitiv... muss halt nur schauen ob ich das vollumfänglich auch budgetmäßig verkaufen kann. Applocker soll für den Anfang auch her halten, in Ausbaustufe ggfs. dann WDAC.
Ich stoße leider schon mit der Konzepterstellung auf reichlich Gegenwehr bei den Kollegen, die halt seit Jahrzehnten Day-2-Day als DA unterwegs sind
Aber ich beiß mich da durch und hab glücklicher Weise die notwendige Rückendeckung von weiter oben weil halt auch klar ist, dass das aktuell grob fahrlässig zu werten ist 
-
vor 15 Stunden schrieb daabm:
Ja, hätte er :-))
Und er kann noch ergänzen, daß das auch in einem Enterprise-Umfeld prima funktioniert. Bissele nachdenken, passende Variablen deployen (bzw. durch Startskripts erzeugen lassen) und die ganzen lokalen Admin- und Rechtegruppen füllen sich magisch wie von selbst.
Gut zu wissen weil mir bei Recherchen hier im Forum eben genau dieser Link schon öfters untergekommen ist und ich das in etwas abgewandelter Form jetzt in einem Lab implementiert hab
und das eigentlich soweit richtig gut funktioniert.
Wird halt ein richtiges Stück Arbeit, weil die Umgebung in die ich reingeraten bin zwar weiß, dass es AD gibt aber von der Umsetzung noch das Meiste nach alter NT4-Manier handhabt...
Keine Delegation, keine managed Service-Accounts, kein Splittung von privilegierten Konten und ich weiß nicht wie viele User-Accounts mit AdminCount 1 und bspw. Helpdeskmitarbeiter in BUILTIN/Kontenoperatoren nur um hier und da mal ein Passwort zu resetten...
Fürchte, die schmeißen mich spätestens dann raus, wenn ich denen allen eine PAW unterjubeln werde
Für Eure Antworten herzlichen Dank.
-
Guten Morgen Board,
ich bin gerade dabei einen Schlachtplan zu entwickeln uns weitestgehend gegen Privileged Escalation zu schützen.
Eigentlich ist mein Plan schon recht weit vorangeschritten und sieht so aus, GPO-gesteuert
auf allen Servern/Clients die UserRightsAssignments und lokalen User granular zu steuern.
Ein Step dieser GPO soll sein, die lokale Gruppe der Administratoren erstmal zu löschen und anschließend mit dem (erforderlichen) lokalen Administrator
und die für den Server/die Servergruppe notewendigen Server-Admins/administrativen Konten zu befüllen ohne die Domänen-Admins nochmal zu adden...
Nun bin ich beim Durchforsten der Microsoft-Empfehlungen auf folgenden Passus gestossen der mich hinsichtlich meinem Vorhaben bissel nachdenklich stimmt:
ZitatDomain Admins are, by default, members of the local Administrators groups on all member servers and workstations in their respective domains. This default nesting should not be modified because it affects supportability and disaster recovery options. If Domain Admins groups have been removed from the local Administrators groups on the member servers, they should be added to the Administrators group on each member server and workstation in the domain via restricted group settings in linked GPOs.
Finde die Begründung erstmal bissel oberflächlich, möchte auch deshalb mal in die Runde fragen, wie Ihr das so macht und ob ich da tatsächlich ggfs. irgendwas nicht beachte.
Sehe nämlich aktuell keinen wirklichen Grund die Domain-Admins nochmal zu adden und über Deny-Regeln zu arbeiten...
Wäre über jeglichen Input dankbar!
-
Sehr verständlich, vielen Dank. :thumb1:
Entspräche auch meinem bisherigen Kenntnisstand und dennoch fehlt mir irgendwie der Zusammenhang, wie dieser Passus oben gemeint sein soll.
Weil eigentlich kenne ich das nur so, dass die CALs den Zugriff auf alle Server im Netz erlauben und ich kann und will nicht glauben, dass ich jetzt wegen
paar ausgeschalteten VMs ´ne SA dafür brauche ;)
-
Hallo zusammen,
ich weiß der Thread ist alt aber bei uns steht das Thema jetzt auch zur Diskussion und irgendwie hab ich den Part mit der CAL-Lizenzierung noch nicht verstanden...
Zum Thema:
Wir möchten VMs von zwei Windows 2012 R2 Hosts via VEEAM Backup & Replication auf einen Cold-Backup-Server in einem zweiten Brandabschnitt replizieren.
Auf den beiden VM-Hosts laufen ausschließlich Volumenlizenzen ohne SA, sodass ich entweder die SA nachkaufe oder eben den Backupserver entsprechend lizenztechnisch gleich ausstatte.
Hier ist die Anschaffung einer Datacenter-Lizenz geplant, da der Backup-HyperV-Host auch andere VMs bereitstellen soll (abseits der Replikation)
Inhalt zweier VMs sind zwei SQL-Server 2012 Standardinstallationen mit einer handvoll CALs (SAGE und ne Branchenlösung).
Auch hier ist klar, dass wir die beiden SQL-Server 2012 doppelt lizenzieren müssen.
Alle CALs, egal ob Windows CAL oder SQL CAL sind als USER-CAL lizenziert und es existiert keine SA.
Nun steht da:
· Software Assurance für alle CALs, externen Connector-Lizenzen und Server-Management-Lizenzen beibehalten, unter denen Sie auf Ihre lizenzierte Software zugreifen, die auf dem Server für die Wiederherstellung bei Notfällen ausgeführt wird, und die Betriebssystemumgebungen verwalten, in denen diese Software ausgeführt wird.
Hab ich das jetzt richtig verstanden, dass ich für dieses Replikationskonstrukt jetzt tatsächlich für jede CAL, egal ob SQL oder WINDOWS entweder eine Software-Assurance benötige oder eben,
sofern diese nicht möglich ist (bspw. OEM-CALs oder Runtime-CALs) doppelt kaufen muß?
Irgendwie werde ich aus diesem Passus nicht wirklich schlau
Wäre über jeglichen Input dankbar :cool:
-
Hallo Daniel,
ich danke Dir sehr herzlich.
Ich hab eigentlich für beide Szenarien noch Lizenzen.
Hab noch eine virtuelle 2012R2 Lizenz über mit der ich gerade Szenario 1 abdecke.
Zudem hab ich eine Windows 8 Enterprise SA auf eine kürzlich erworbene Windows 8.1 OEM Version.
Allerdings hab ich das mit der SA jetzt so verstanden, dass ich damit zwar das VDA-Recht abdecke, jedoch nur für ein zugreifendes Gerät.
Es wäre etwas anderes, wenn Du eine VM auf einem Client betreiben würdest. Hier kannst Du die VM durch z.B. eine Windows Client System Builder-Lizenz abdecken. Aber auch hier gilt der Passus bezüglich des Betriebs als Server in der MSLT - für alles, was dort nicht aufgeführt ist, brauchst Du eine Serverlizenz.
Okay... heißt ich kaufe mir einen neuen Client mit Windows 8.1 OEM, darauf aktiviere ich Hyper-V und virtualisiere den Client einfach. Dieses Szenario lässt sich mit einer OEM/SB Lizenz abbilden?
Mir ist das völlig Schnuppe oder Client auf einem Server oder eben einem Client läuft. Wichtig ist, dass ich die VHDX der virtuellen Maschine täglich sichere und somit das System schnell wieder recovern könnte.
-
Hab ich und nochmal festgestellt, dass man von Softwarehäusern erworbene Systeme nicht einfach ohne Prüfung der Lizenzgrundlagen hinnehmen sollte. :shock:
Szenario 2 werde ich schleunigst auf ein Serversystem umswitchen.
Dennoch muss ich bei Szenario 1 nochmal nachhaken. Der Begriff EDI-Server ist hier vielleicht bissel hochtrabend gewählt, da das System
eigenltich nicht wirklich Serverdienste anbietet und somit hinsichtlich der MSLT eher unkritisch ist.
Mich interessiert wirklich nur, ob dieses System sobald virtualisiert und eigentlich jeden Tag nur vor sich hindümpelt und paar geplante Tasks ausführt und wenn überhaupt maximal 2 mal pro Woche
ein Zugriff via RDP stattfindet (von einem Arbeitsplatz aus) eine VDA benötigt?
-
Hallo Leute,
hab hinsichtlich der Virtualisierung von Clients rein lizenztechnisch wohl noch etwas Nachholbedarf und hoffe hier kann mir geholfen werden...
Szenario 1:
Windows 7 Professional OEM Client
Dort laufen Tasks die diverse Jobs im WWS ausführen
Gelegentlich sitzt jemand an dem physischen PC und lässt diverse Fakturierungsläufe laufen.
Zusätzlich fungiert das System als EDIServer.
Nun möchte ich das System virtualisieren und via Hyper-V bereitstellen. Zugreifen würden 1 User mit einem einzigen PC.
Bisher bin ich davon ausgegangen, dass ich eine Software Assurance für ein Windows Pro 8.1 benötige, da ich ein einziges zugreifendes Endgerät habe und
damit auch eine OEM virtualisieren und downgraden kann.
Szenario 2:
Windows 8.1 Professional OEM Client
Dort läuft eine SQL 2012 Express Datenbank die von einer kleinen Client-/Server-Anwendung benutzt wird.
Ansonsten laufen lokal auf dem Client Verwaltungsaufgaben die ihre Daten auch nur in die SQL DB schreiben.
Netzzugriff auf diesen "Server" findet eigentlich nur von zwei Clients auf die SQL-DB über TCP 1433 statt.
Hier bin ich bis heute davon ausgegangen, dass wir keine SA für die VDA benötigen, da es kein klassischer Desktopzugriff ist und lediglich
die SQL-DIenste genutzt werden?! Administration über RDP oder direkt an der Hyper-V Konsole.
Oder impliziert die Tatsache, dass ich ein Client-OS virtualiere gleich auch ein VDA ungeachtet der tatsächlichen Nutzung des Systems.
Bei MS finde ich ehrlich gesagt den Zusammenhang mit VDA immer nur im klassischen VDI-Fall wo Clientsystem konsolidiert und via Thinclients verwendet werden.
Über jegliches Feedback wäre ich Euch sehr dankbar.
Viele Grüße
PD
-
Hab gerade die selbe Sache am Bein und in dem beigefügten Exceldokument steht doch genau definiert drin, was die benötigen...
"Für die erworbenenen OEM und Einzelhandelslizenzen benötigen wir 5 Produktschlüssel für jedes Produkt, welches Sie beschafft haben. FAlls Sie z.B., jeweils 20
Kopien von OEM Office XP Professional und Windows XP Professional besitzen, bitten wir Sie, uns 5 vollständige Produktschlüssel für jede Produktgruppe als Nachweis vorzulegen."
Domänen-Admins lokal löschen (Memberserver/Clients)
in Active Directory Forum
Geschrieben
Also offen gestanden empfand ich deine Infos alles andere als dummy-tauglich
Das was Du geschrieben hast feat. dem was man in Deinem Blog dazu findet, sollte eigentlich auch dem größten "Dummy" die nötige Unterstützung geben. Problem heute ist aus meiner Sicht eher, dass die Leute meist fertige Lösungen präsentiert haben wollen und sich Dinge selten selbst erarbeiten.
Dennoch, danke für die Blumen