Jump to content

Built-In Administrator auf Server daktivieren


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,

 

bin gerade dabei eine Server Sicherheitsrichtlinie für Server zusammen zu schreiben und hänge an dem Thama deaktivieren des Built-In Admins (SID500).

Gibt es einen triftigen Grund den Built-In Admin auf einen 2008-2012R2 Server nicht zu deaktivieren? Hintergrund ist einen Angriff auf SID-500 zu unterbinden.

Stattdessen sollte eine neuer lokaler Account erstellt und die Gruppe "administrators" aufgenommen werden?

 

Vielen Dank

Takis

Link zu diesem Kommentar

Lokale Accounts sind security- und betriebstechnisch meist nicht so gut zum Arbeiten..

Wenn der Server in einer Domäne steht, dann benutze besser einen Domänenaccount ohne besondere Rechte im AD und stecke den dann in die lokale Administratorgruppe des Servers.

Ab Domänenlevel 2012 ist eine Mitgliedschaft in der Domain Gruppe "protected users" für diesen Account sinnvoll, da dadurch dem Account einige sehr gefährliche, aber so gut wie nie benötigte, Privileges (Debuggng, Driver Installation, etc) genommen werden. Außerdem muss er dadurch immer Kerberos nutzen.

https://technet.microsoft.com/en-us/library/dn466518.aspx

Den lokalen 500-er würde ich nicht deaktivieren, aber gib ihm ein 30-stelliges keepass-Zufallspasswort. (pro Server ein eigenes!) und wechsle das auch regelmäßig z.B. jährlich.

Für Software bzw. Serviceaccounts benutze möglichst keine (lokalen) Accounts mit Adminrechten. Die können einfach zu viel bzw. haben zu viele unnötige und gefährliche Privileges

https://technet.microsoft.com/en-us/library/cc771990.aspx

 

Diese Liste an Maßnahmen für lokale Accounts ist sicher nicht vollständig

 

Konkret zu deiner Frage

Zwischen dem lokalen 500-er Account und einem neuen lokalen Account in der Administratorgruppe ist so gut wie kein Unterschied in Bezug auf Security. Beide können Alles auf der Maschine!

 

blub

Link zu diesem Kommentar

Hallo an alle,

 

vielen Dank für Eure Antworten.

Die Verwendung von Domain-Accounts (stand-alone Server in einer DMZ?), die Vergabe von komplexen Passwörtern und deren Verwaltung (wir verwenden hierzu PowerBroker), das sind Lösungen die ich bereits berücksichtigt habe.

 

Die Frage ist ob die Deaktivierung des lokalen -500er Probleme bereiten kann oder nicht.

 

...

 

Konkret zu deiner Frage

Zwischen dem lokalen 500-er Account und einem neuen lokalen Account in der Administratorgruppe ist so gut wie kein Unterschied in Bezug auf Security. Beide können Alles auf der Maschine!

 

blub

 

Hi blub,

 

danke für die Infos.

Der Unterschied zw. den -500er und einen neu generierten Account der in die Admin-Gruppe aufgenommen wird ist, dass dessen SID nicht bekannt ist da sie zufällig generiert wird.

 

Viele Grüße

Takis

bearbeitet von takis.ch
Link zu diesem Kommentar

Moin,

 

Die Frage ist ob die Deaktivierung des lokalen -500er Probleme bereiten kann oder nicht.

 

das ist ja schon beantwortet worden: Ja, sie kann Probleme bereiten.

 

 

Der Unterschied zw. den -500er und einen neu generierten Account der in die Admin-Gruppe aufgenommen wird ist, dass dessen SID nicht bekannt ist da sie zufällig generiert wird.

 

Das ist im Grundsatz zwar richtig, aber genauso bekannt ist der SID der Gruppe Administratoren. Ein engagierter Angreifer wird von dort aus weiterkommen.

Abgesehen davon, wird der SID (genauer: der RID) nicht zufällig generiert, sondern einfach weitergezählt. Da es auf den meisten Servern nur sehr wenige lokale Accounts gibt, ist der neu definierte Admin also schnell gefunden.

 

Hier und da wirst du den Account also vermutlich abschalten können (ist ja bei Clients auch so), an anderen Stellen wirst du es wegen des Funktionsrisikos aber nicht tun wollen. Und gewonnen ist damit wenig. Komplexe Kennwörter sind ziemlich eindeutig besser.

 

LAPS halte ich allerdings nicht für eine schöne Lösung. Man muss dabei sehr viel zusätzlich gewährleisten, damit es funktioniert. Kleine Sorgfaltslücken können dann ein großes Sicherheitsproblem erzeugen.

 

Gruß, Nils

bearbeitet von NilsK
Link zu diesem Kommentar

Moin,

 

Welche Lösung würdest du anstatt LAPS einsetzen oder empfehlen?

 

das hängt vom Einsatzgebiet und den Anforderungen ab. In dem hier diskutierten Szenario könnte es ausreichen, eine Vorgabe zum manuellen Setzen eines komplexen Kennworts zu machen. LAPS kann durchaus eine Lösung sein, aber sie passt nur, wenn es sehr strikte Prozesse gibt. Aufgrund der Architektur ist LAPS für typische mittelständische Unternehmen i.d.R. nicht geeignet.

 

Man könnte auch etwas LAPS-Ähnliches selbst bauen, z.B. einen Task, der lokal ein Kennwort generiert, es setzt und an einen geschützten Ort schreibt. Eine einzelne Datei auf einem Server oder eine einzelne Datenbank kann man meist leichter absichern als Attribute in einem AD.

 

Gruß, Nils

Link zu diesem Kommentar

Den Artikel kenne ich. Allerdings ist doch:

 

 

 

Wichtig aber: LAPS legt die Admin-Kennwörter im Klartext im AD ab. Sie sind dann nur noch über die Zugriffsberechtigungen geschützt, die oben im Artikel erläutert sind. Wer LAPS einsetzt, muss also peinliche Sorgfalt darauf verwenden, die Berechtigungen richtig zu setzen.

 

der einzig kritische Aspekt im Artikel. In typischen, mittelständischen Unternehmen sollte man das Attribut doch mit den richtigen Berechtigungen versehen können? Ein entsprechendes Tool, um die Berechtigungen des Attributs auslesen zu können liefert LAPS doch sogar mit.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...