daabm

Bevor da jetzt einer in die Eigenschaften schaut - nein, die zeigen nicht auf die MSI-Datei. Die zeigen auf das "Installer-Objekt" (ich weiß nicht, wie ich's einfacher beschreiben soll), das triggert dann einen Teil des MSI-Pakets (das dann z.B. trotz computerbezogener Installation noch userbezogene Nachinstallation machen kann) und startet dann die im Installer-Objekt hinterlegte Zieldatei. Aber jetzt ist [/OT]

Ich wüßte spontan nichts - aber im Security Compliance Toolkit war irgendwas drin mit Policy Compare, da würde ich mal suchen... Alternativ kann Quest GPOAdmin das auf jeden Fall sehr gut (das weiß ich sicher), das ist aber nicht ganz umsonst.

Ich erinnere mich dunkel, daß hier im Board keine Unterstützung kommt, wenn es um Lizenz-"Konstrukte" geht...

Nein, tut es nicht. Das ist ein Windows-Recht, das man per GPO jedem geben kann, wenn es Not tut. Und ich persönlich finde diesen Weg nicht sooo falsch - bei Picasa ging das ja seinerzeit auch nur mit Symlinks, wenn man eine gemeinsame DB auf mehreren Rechnern nutzen wollte. Die Ordnerumleitung von "Bilder" ist natürlich der insgesamt schlüssigere Weg https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links

Die ISE hat den von Olaf erwähnten Vorteil: Ist Powershell da, ist auch eine ISE da. Der Rest ist immer nur optional...

Moin im Board. Hast Du eine alte Fritzbox übrig? Die ist Switch, Access Point und Router in einem und kann damit alles erfüllen, was Du für B haben willst. Und wenn in A auch schon eine FB steht, geht's mit dem AVM Mesh sogar für Einsteiger relativ einfach, nur das Cat6-Kabel muß noch einer durch das Rohr ziehen

Merke - nicht jedes Postfix ist ein Mailer

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.

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.

Wie wär's mit nem gebrauchten Business-Rechner? Gibt's ab ca. 150,- dann noch SSD rein und mit deutlich unter 300,- hast ne Kiste, die mit jeder Windows-Variante kompatibel ist... Nix gegen Bootcamp, aber alles hat Grenzen

Das mit "Sicherheit herabsetzen" ist eine Folge von NLA - dann klappt die Anmeldung mit abgelaufenem Kennwort per RDP nicht mehr... Das mit der Sinnhaftigkeit der regelmäßigen Kennwortänderung wurde ja schon erwähnt - Microsoft und das BSI sind von dieser Empfehlung abgerückt, könnte diese Cyberversicherung ja mal nachziehen. Besser "lang - sehr lang". PS: Rein aus Neugier - wie implementiert man eine FGPP für "4 OUs"? Bei mir war das bisher immer für "Gruppen", nicht für OUs

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.

Nachträglich deaktivieren entfernt nicht zuverlässig alles, was vorher mal kam. Und "erzwungen" kommt eh immer noch.

Jaja, und tailspin noch. Wer kennt den Rest? https://social.technet.microsoft.com/wiki/contents/articles/1117.list-of-fictional-companies-used-in-microsoft-material.aspx

Ja, Titel "my long way from contoso.local to northwindtraders.com and beyond"

Nein. Gibt Third Party für sowas, einfach mal ne Suchmaschine bemühen.

Sei net so pingelig - LDAP bezeichnet das auch als Kette... 1.2.840.113556.1.4.1941

Genau das will er ja nicht erreichen Er will nen Client, wo er die Zeit ändern kann - das ist ein Benutzerrecht, kann man prima per GPO steuern. Frage wäre nur "was ist auf dem Client da aktuell gesetzt?" Sysinternals "accesschk -a *" verrät, wer welche User Rights (bzw. Privileges) tatsächlich hat. "gpresult / report.html" erstellt Dir nen grafischen Bericht, in dem steht, wo es herkommen dürfte.

...und seit Windows 8 mit Store und Apps kommt noch ein wenig mehr in HKLM dazu. Besser supportete Varianten verwenden - per GUI oder über Win32_UserProfile.

Dem kann ich nur zustimmen... Wir haben das Problem grad, daß alle "Alt-Domains" (DNS und AD) alle alten Firmennamen enthalten - au weia... Der neue interne Namensraum ist generisch und firmenunabhängig.

Doch - so ein Mid-Size Familienunternehmen mit 10 bis 20 k Accounts, das wäre meine Wunschumgebung. Am besten international, damit noch ein wenig Herausforderung dabei ist. Wir haben zu viele Domains, wir haben zu viele Schrauben zum Drehen, da geht zu oft hinten eine Mutter ab, wenn man vorne wo dreht... Weil man's einfach nicht wissen kann. Aber jetzt wird's glaub o/t, ich bin damit mal aus meinen eigenen Stories raus und warte auf Fragen des TO @mcdaniels Ich find's gut, daß Du reagierst, wie Du reagierst. Wie @MurdocX oben schon schrub: Der Admin ist in SOHO-Umgebungen oft halt "der" Admin - Domäne, Server, Clients, da gibt's keine Delegation und keine Account-Trennung. Schön, daß Du daran arbeitest

AppLocker oder Software Restriction Policies (SRP) sind eine gute Gegenmaßnahme. Erstaunlich günstig (da in Windows enthalten), erstaunlich einfach "grundlegend" zu konfigurieren, erstaunlich wirksam. Dazu noch anständige Makro-Policies für Office und der Fisch ist im wesentlichen geputzt. Bei c't gibt's sogar ein Standalone-Utility für SRP.

Über Tiers müssen wir hier glaub noch nicht reden, ich hab das inzwischen verinnerlicht AD ist kein Konzept, nur ein Produkt. Die Konzepte entwickeln sich, und ESAE sieht aktuell nicht soo schlecht aus. Wenn man die Tier-Trennung durchhält, ist es brauchbar. Und bisher sieht es sehr danach aus. Unser Hauptproblem aktuell: Das IDM, das alle Non-Domain Admins provisioniert, kann pro User nur einen Account - manche bräuchten aber mehrere (Clients, Terminal Server, SQL-Server). "Toxische Rechte-Kombination" nennt man das dann... Dom-Admins werden nur manuell provisioniert, ohne IDM -> ein Einfallstor weniger. Und man sollte natürlich keine Angst haben vor Umfeldern mit Duzenden Domains und Forests

Versuchen wir grad. SCVMM - negativ. Cluster - negativ. SCCM - negativ. (Alles noch 2016 oder älter - ab 2019 soll es angeblich besser werden). "Dieser Weg wird kein leichter sein"... Das NTLM Operational Eventlog ist unser täglicher Begleiter.

Ich werf mal meinen Senf dazu: Deine Ideen sind richtig, der Weg ist auch richtig. Und wie schon gesagt wurde: Einen Domain Admin kannst Du NICHT wirksam einschränken, von dem Gedanken mußt Du Dich verabschieden. Oder allgemeiner: Wer auch immer Admin des aktuellen Scope ist, kann in diesem Scope nicht wirksam eingeschränkt werden. Wir haben das (in einem größeren Umfeld) auch so umgesetzt: Jeder Service hat seine Service-Gruppen, die sind dann User oder Admin für die Server, die dazu gehören. Domain Admins gehören nicht dazu, können sich nicht mal anmelden. Andersrum natürlich auch nicht. Geht mit ein wenig GPO-Voodoo relativ einfach https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html Und lass Dich von den Kommentaren von Nils nicht entmutigen - Du bist jetzt schon weiter als 95% aller Admins.