Erhöhung AD Sicherheit - DomAdm / Tier Modell

[Robinho1986 1]

Hallo zusammen,

 

ich stehe vor der Herausforderung in einer gewachsenen Domänenstruktur die Sicherheit im Bezug auf einen bekannten Domänen-Admin zu erhöhen. 

Vermutlich sind viele Anwendungen / Dienste vor geraumer Zeit mit genau diesem implementiert worden. Aktuell stellen wir uns die Frage, wie wir am besten vorgehen und was das Ziel sein sollte.

 

Folgend meine Ideen und Gedanken: 

 

1. Grundsätzlich sollte die Domänenadmin-Gruppe NUR den Domänenadmin enthalten

2. Im besten Falle kann ich per Skript und Co. alle Dienste auslesen und erkennen, worin der User enthalten ist

3. Sukzessive stellen wir alle Applikationen auf eigene entsprechend berechtige User um

4. Die Einführung eines TIER Modells sollte das Ziel sein?!

5. LAPS haben wir bereits eingeführt

 

Hat jemand Erfahrungen bei dieser Thematik und kann eventuell gute Tipps und Ideen dazu beitragen? 

 

Vielen lieben Dank im Voraus! 

 

 

bearbeitet 12. März von Robinho1986

[daabm 1.348]

vor 5 Stunden schrieb Robinho1986:

Hat jemand Erfahrungen bei dieser Thematik und kann eventuell gute Tipps und Ideen dazu beitragen? 

Ja. Nein.

 

Wenn der Account "irgendwo" verwendet wird, mußt Du erst mal Auditing machen und rausfinden, von wo Logons kommen. Der Rest ist dann einfach. LAPS hat damit nichts zu tun.

[Nobbyaushb 1.464]

Der erste Schritt aus meiner Sicht wäre damit zu beginnen, ein Dienstkonto (oder mehrere..) mit sehr langen und komplexen Kennwörtern zu erstellen

Dann das Passwort vom Dom-Admin zu ändern (auch komplex…)

Nach recht kurzer Zeit wird man merken, was sich alles auf die Seite legt bzw. nicht mehr geht

Nun wird den jeweiligen Diensten die bereits erstellten Konten zugewiesen und diese neu gestartet 

dann sieht man weiter

Ansonsten ist das viel Arbeit und es gibt kein Patentrezept dafür

Was bei der einen Umgebung passt ist in einer anderen Umgebung völlig falsch

Auf jeden Fall ist das ein langfristiger Prozess, der vor allem mit der GL und allen Beteiligten abgestimmt werden muss 

[Sunny61 806]

vor 5 Stunden schrieb Robinho1986:

Im besten Falle kann ich per Skript und Co. alle Dienste auslesen und erkennen, worin der User enthalten ist

Eine Idee zur Umsetzung kann dieser Artikel liefern: https://www.faq-o-matic.net/2008/12/25/dienst-und-task-konten-identifizieren/

Außer die Umgebung ist klein genug um das selbst manuell zu erledigen. In dem Zusammenhang kann man auch prüfen, ob man evtl. Maschinen mit mehreren Diensten im Einsatz hat und hier die Anzahl der Dienste pro Maschine/Server reduzieren kann.

[NilsK 2.930]

Moin,

 

fangen wir doch mal vorne an - wie groß ist denn das Netzwerk überhaupt? Jede Maßnahme muss ja auch angemessen sein.

 

Gruß, Nils

 

[toao 3]

Hi Robinho1986,

 

zum Thema "Wo wird der Domain-Admin genutzt" ein paar potentielle Anwendungsbereiche:
- Scheduled Tasks

- Local Services

- IIS Application Pool

- Scripts, batches

- Tools, Applications

 

Richtig, dass alles solltest Du versuchen mit einem Script abzufragen.  Zusätzlich könntest Du auch etwas über die nachfolgenden Windows EventIDs (auf den Domain Controllern) herausbekommen (auch mit ins Script einarbeiten):

Kerberos:

4768: A Kerberos authentication ticket (TGT) was requested.

4769: A Kerberos service ticket was requested.

4770: A Kerberos service ticket was renewed.

NTLM:

4779: The computer attempted to validate the credentials for an account.

*Bitte prüfe ob das Auditing zumindestens für die oben genannte EventID's, bei Euch entsprechend eingerichtet ist.

 

Du erhälst in allen EventIDs zwar nicht den genauen Prozess, Service serviert, jedoch die IP-Adresse(Hostname) des Endsystems. Quasi ein Anfang um weitere Nachforschungen durchzuführen.

 

Sobald es ans eingemachte geht, den Domain-Admins gegen einen Service-Account zu tauschen, bitte favorisiere als Service-Account immer einen MSA/GMSA (object class ms-DS-Group-Managed-Service-Account) wo immer es geht und nicht einen Service-Account auf Basis der object class: user.

 

Je nach Größe des Unternehmens, kannst Du damit sicherlich ersteinmal ordentlich zu tun haben.

 

Das Tiering- und Delegation Model würde ich sagen ist nie verkehrt. Da müsst Ihr schauen welche Kapazitäten ihr habt das parallel laufen zulassen , wie versiert Ihr mit der Delegierung von Berechtigungen im AD seid und einiges mehr. Da kann man sich schnell verlieren und soetwas muss sorgfältig geplant und durchgeführt werden.

 

Viel Erfolg beim Aufspühren der Nutzung des Domänen-Admins in den nächsten Tagen und Wochen :)

 

Toao

 

 

 

bearbeitet 17. März von toao

[cj_berlin 1.306]

vor 46 Minuten schrieb toao:

Sobald es ans eingemachte geht, den Domain-Admins gegen einen Service-Account zu tauschen, bitte favorisiere als Service-Account immer einen MSA/GMSA (object class ms-DS-Group-Managed-Service-Account) wo immer es geht und nicht einen Service-Account auf Basis der object class: user.

...und bedenke dabei, dass Du die Häufigkeit des Kennwortwechsels für das gMSA nur einmal festlegen kannst, nämlich bei dessen Erzeugung  

 

Alles, was @toao und die Vorredner geschrieben haben, ist richtig und wichtig. Ein technisch deutlich komplexeres Problem als das Aufspüren von hochprivilegierten Service-Accounts ist die Frage, welche von ihnen wie stark überprivilegiert sind, d.h. auf welches Berechtigungsniveau Du das zukünftige Service-Account, ob nun Legacy oder gMSA, heben musst, damit die jeweilige Anwendung funktioniert. Insbesondere dann, wenn ihr die Default-Konstruktion nicht geändert habt, die Domain Admins zu lokalen Admins auf Member-Maschinen macht.

[Robinho1986 1]

Am 13.3.2024 um 10:58 schrieb NilsK:

Moin,

 

fangen wir doch mal vorne an - wie groß ist denn das Netzwerk überhaupt? Jede Maßnahme muss ja auch angemessen sein.

 

Gruß, Nils

 

Hallo, 

 

wir reden von ca. 70 Windows VMs und ca. 500 Mitarbeitern. 

vor 16 Stunden schrieb toao:

Hi Robinho1986,

 

zum Thema "Wo wird der Domain-Admin genutzt" ein paar potentielle Anwendungsbereiche:
- Scheduled Tasks

- Local Services

- IIS Application Pool

- Scripts, batches

- Tools, Applications

 

Richtig, dass alles solltest Du versuchen mit einem Script abzufragen.  Zusätzlich könntest Du auch etwas über die nachfolgenden Windows EventIDs (auf den Domain Controllern) herausbekommen (auch mit ins Script einarbeiten):

Kerberos:

4768: A Kerberos authentication ticket (TGT) was requested.

4769: A Kerberos service ticket was requested.

4770: A Kerberos service ticket was renewed.

NTLM:

4779: The computer attempted to validate the credentials for an account.

*Bitte prüfe ob das Auditing zumindestens für die oben genannte EventID's, bei Euch entsprechend eingerichtet ist.

 

Du erhälst in allen EventIDs zwar nicht den genauen Prozess, Service serviert, jedoch die IP-Adresse(Hostname) des Endsystems. Quasi ein Anfang um weitere Nachforschungen durchzuführen.

 

Sobald es ans eingemachte geht, den Domain-Admins gegen einen Service-Account zu tauschen, bitte favorisiere als Service-Account immer einen MSA/GMSA (object class ms-DS-Group-Managed-Service-Account) wo immer es geht und nicht einen Service-Account auf Basis der object class: user.

 

Je nach Größe des Unternehmens, kannst Du damit sicherlich ersteinmal ordentlich zu tun haben.

 

Das Tiering- und Delegation Model würde ich sagen ist nie verkehrt. Da müsst Ihr schauen welche Kapazitäten ihr habt das parallel laufen zulassen , wie versiert Ihr mit der Delegierung von Berechtigungen im AD seid und einiges mehr. Da kann man sich schnell verlieren und soetwas muss sorgfältig geplant und durchgeführt werden.

 

Viel Erfolg beim Aufspühren der Nutzung des Domänen-Admins in den nächsten Tagen und Wochen :)

 

Toao

 

 

 

 

Vielen Dank für die ausführliche Antwort. Ich habe schon vermutet, dass es kein Tool oder Patentrezept geben wird. Ich denke das wichtigste ist, erstmal anzufangen.

Jeder Schritt wird einen Mehrwert an Sicherheit bringen. Wir werden uns nun erstmal einen Schlachtplan entwerfen. 

[NilsK 2.930]

Moin,

 

okay, das ist eine Größenordnung, wo ein gewisser Aufwand sinnvoll ist. Wichtig dabei, wie du ja schon selbst feststellst: Planung. Nicht einfach losrennen, auch scheinbare Quick-wins sollte man zumindest einschätzen und einordnen. Zum Thema "Tiering" ist in den letzten zehn Jahren auch viel geschrieben worden, was in mittelgroßen Netzwerken eher unsinnig ist.

 

Konkrete Fragen gern hier. Mit einem Inventar der Admin-Konten und ihrer Verwendung anzufangen, ist jedenfalls eine gute Idee.

 

Gruß, Nils

 

[testperson 1.674]

Hi,

 

du würdest vermutlich in die Dokumentation gucken, wenn diese (vollumfänglich) vorhanden wäre. ;) Dann nutze die Gegebenheiten jetzt und dokumentiert alles.

 

Gruß

Jan

[Robinho1986 1]

Am 18.3.2024 um 12:44 schrieb testperson:

Hi,

 

du würdest vermutlich in die Dokumentation gucken, wenn diese (vollumfänglich) vorhanden wäre. ;) Dann nutze die Gegebenheiten jetzt und dokumentiert alles.

 

Gruß

Jan

 

korrekt. Danke nochmal für alle Eure Infos, mit dem Input kann ich definitiv starten!

 

Eine Frage zu einem konkreten Beispiel hätte ich dennoch. Es existiert ein Berechtigungskonzept auf einem Fileserver, soweit so gut.

Dennoch ist in jedem Ordner die Gruppe der Domänenadmins mit Vollzugriff eingetragen, Besitzer ist der lokale Admin des Servers.

Würdet Ihr das ändern? 

 

[testperson 1.674]

Hi,

 

alleine um die ACLs sauber zu haben, würde ich die entfernen.

 

Am Ende des Tages bekommen die Domain Admins aber i.d.R. ein "Logon * Deny" / "Deny Access to this computer from network" auf den Membern / Clients und können sich eh nicht mehr am Fileserver anmelden. Bspw. so: What you can do, should do and should NOT do with GPOs: Wer bin ich und was darf ich - Gruppenmitgliedschaften und Benutzerrechte (evilgpo.blogspot.com)

 

Gruß

Jan

[Sunny61 806]

vor 56 Minuten schrieb Robinho1986:

Es existiert ein Berechtigungskonzept auf einem Fileserver, soweit so gut.

Dennoch ist in jedem Ordner die Gruppe der Domänenadmins mit Vollzugriff eingetragen, Besitzer ist der lokale Admin des Servers.

Würdet Ihr das ändern? 

Eine eigene Gruppe erstellen die Zugriff hat. Ausgewählte Benutzerkonten einfügen, bzw. eine Gruppe mit Benutzerkonten wenn man das Berechtigungskonzept durchgängig nach diesem Muster erstellt: https://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/

Insbesonders dieses Schaubild zeigt es deutlich wie es sein sollte:

[NilsK 2.930]

Moin,

 

ich würde das bei einer Neukonzeption ändern, aber ohne nähere Kenntnis der Situation würde ich vermuten, dass das kein vordringliches Problem ist. Sehr wahrscheinlich wird die Energie zu Beginn eines solchen Wegs an anderen Stellen besser investiert sein.

 

Gruß, Nils