Administrator deaktivieren

[Pipeline 12]

Moin zusammen,

 

wir hatten ein Sicherheitsaudit (mal wieder) inkl. PEN Test. Der Abschlussbericht enthält die Empfehlung im Active Directory den built-in Administrator zu deaktivieren.
Das ist ja auch nicht gerade eine neue Idee. Wir verwenden den nicht aktiv, nur unsere personalisierten Konten, daher wäre das ohne direkte Probleme nötig.

Wir wollten das schon lange machen, jedoch waren wir uns über mögliche Einschränkungen nicht sicher.

Bei der Recherche gab es nur ein einziges Risiko welches wir gefunden haben und zwar der AD Restore.  Dazu haben wir widersprüchliches gefunden. In einigen Artikeln hieß es der built-in Admin wird auf der Restore Konsole automatisch wieder aktiviert, mal hieß es ohne aktiven User geht es nicht.

Auch dieser Artikel hatte letztes Jahr noch die Empfehlung den User zu deaktivieren, inzwischen wurde das überarbeitet

Appendix D - Securing Built-In Administrator Accounts in Active Directory | Microsoft Learn

Zitat

This guide used to recommend disabling the account. This was removed as the forest recovery white paper makes use of the default administrator account. The reason is, this is the only account that allows logon without a Global Catalog Server.

Auch das forest recovery sollte zuvor das Verhalten haben, dass der User wieder aktiv wird.

Nun bitte ich euch um echte, eigene Erfahrungen dazu. Hat es schon jemand durchgeführt und kann die Widersprüche aufklären?

 

Viele Grüße, Stefan

 

[cj_berlin 1.315]

Moin,

 

deaktivieren, das DSRM-Kennwort kennen, beim Recovery zuerst im DSRM den RID-500 wieder aktivieren und dann im Recovery-Prozess damit arbeiten, falls und wo notwendig.

 

Das ganze Thema akribisch dokumentieren, üben und die Dokumentation an einem Ort aufbewahren, den man ohne AD erreicht.

[toao 4]

Guten Morgen,

 
aktiviert lassen, ausreichendes Monitoring inklusive Alerting einrichten, das Kennwort offline sicher verwahren.

 

Drills für den Forest Restore Process durchführen, Fehler beheben, dokumentieren.

Gruß,
toao

[Gulp 254]

Ich würde den Build-In immer deaktivieren und lieber einen neuen speziellen Domain/Enterprise Admin mit gesichertem Offline Passwort (idealerweise auch mit MFA) im Tresor bevorzugen. Der Build-In kann dann wie Evgenij anmerkt beim Restore aktiviert werden.

 

Grüsse

 

Glp 

bearbeitet Dienstag um 08:26 von Gulp

[zahni 554]

Die CISA-Empfehlung ist den Administrator umzubenennen. Zusätzlich kann man noch als Honigtopf einen neuen User mit dem Namen "Administrator" ohne Rechte erstellen und den dann im Auge behalten,

Der wird eh immer gern durch irgendwas im Netz gesperrt (z.B. durch lokale Administrator-Konten).

Einen anderen User zum Enterprise-Admin machen, um den "Administrator zu deaktivieren, bringt am Ende keinen Sicherheitsgewinn. 

[NilsK 2.934]

Moin,

 

am Ende bleibt es eine Abwägungssache. Es gibt Argumente für und gegen das Deaktivieren. Wichtig ist vor allem, dass man den Account nicht ungeschützt lässt, im Normalbetrieb nicht verwendet und ihm vor allem keine Exchange-Mailbox gibt. Wir waren grad in einem Breach Assessment, wo Letzteres der Angriffsweg war.

 

Gruß, Nils

 

bearbeitet Dienstag um 09:31 von NilsK

[daabm 1.354]

vor 9 Stunden schrieb zahni:

Die CISA-Empfehlung ist den Administrator umzubenennen. Zusätzlich kann man noch als Honigtopf einen neuen User mit dem Namen "Administrator" ohne Rechte erstellen und den dann im Auge behalten,

 

LOL... Get-ADUser "$(( get-addomain -Current LocalComputer ).DomainSID.Value )-500"

[cj_berlin 1.315]

Ich glaube langsam, dass ALLES, was CISA, NIST und BSI verabschieden, auf der Vorstellung beruht, dass ein Hacker vor einer Anmeldemaske sitzt und Namen und Passwörter tippt...

[teletubbieland 167]

vor 10 Minuten schrieb cj_berlin:

Ich glaube langsam, dass ALLES, was CISA, NIST und BSI verabschieden, auf der Vorstellung beruht, dass ein Hacker vor einer Anmeldemaske sitzt und Namen und Passwörter tippt...

Na, so sieht man das doch auch immer in den Filmen.

Da muss doch was dran sein

 

[NilsK 2.934]

Moin, 

 

Genau, und auf dem Bildschirm ist dann immer der HTML-Quellcode einer Webseite. (Vermutlich wäre Homepage hier der passendere Ausdruck.)

 

Gruß, Nils

[zahni 554]

vor 13 Stunden schrieb daabm:

 

LOL... Get-ADUser "$(( get-addomain -Current LocalComputer ).DomainSID.Value )-500"

Und mit -519 bzw- -512 kannst Du die Enterprise-Admins bzw. Domain-Admins abfragen, insgesamt nur etwas mehr Tipparbeit. Daher bringt ein anderes User-Konto mit den gleichen Rechten nur sehr bedingt etwas.

Nicht umsonst gibt es eine GPO (Admin und Gast umbenennen) dafür.

Die CISA geht wahrscheinlich von externen Angriffen aus, die sich bisher nicht authentifiziert haben.

 

[daabm 1.354]

Das Umbenennen ist kompletter Quatsch. Es gibt eine LDAP-Funktion "SID Lookup"... Deaktivieren und Shadow Principals nutzen, dann sind die "wertvollen" Gruppen nämlich leer bis auf Break-Glass-Accounts.

[NilsK 2.934]

Moin,

 

die Policy gibt es, weil es Kunden gab, die die formale Anforderung erfüllen mussten. Die Anforderung selbst erzeugt praktisch keinen Sicherheitseffekt. Es gibt ja eine ganze Reihe von Vorgaben, die überholt sind oder sich als effektarm herausgestellt haben. Manche regulierten Unternehmen müssen sie trotzdem umsetzen, weil sie eben reguliert sind.

 

Gruß, Nils

[Pipeline 12]

Oh ich danke euch für die vielen Antworten.

Leider zeigt sich, dass es differenziert betrachtet und abgewogen werden sollte und nicht die eine richtige Antwort gibt.

Ich bin hier gerade in einem Umfeld aktiv, wo der Fall zutrifft: ist vorgegeben, BSI und Co ... 

Eure weiteren Anregungen nehme ich für nachträgliche Verbesserungsideen gerne mit

 

[Pipeline 12]

Am 20.11.2024 um 18:07 schrieb daabm:

Das Umbenennen ist kompletter Quatsch. Es gibt eine LDAP-Funktion "SID Lookup"... Deaktivieren und Shadow Principals nutzen, dann sind die "wertvollen" Gruppen nämlich leer bis auf Break-Glass-Accounts.

Moin Martin,

hast du dazu ("Shadow Principals" und "Break-Glass-Accounts") für mich eine gute Quelle zum nachlesen?