PrometricDriver

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

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

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

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

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: Quelle: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models 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: 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. 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."