Built-In Administrator auf Server daktivieren

[takis.ch 10]

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

[Nobbyaushb 1.471]

Kommt drauf an.

 

Wenn du z.B. den Adaptec Maxview drauf hast, brauchst du das lokale Administrator-Konto.

 

Ist bei LSI & Co. meines Wissens nicht viel anders.

 

Hat der Server Internetzugang?

 

;)

[blub 115]

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

[NorbertFe 2.034]

Für lokale adminkonten gibt's doch seit einiger Zeit LAPS von Microsoft. ;)

[blub 115]

lokales Adminkonto -> Anmeldung mit NTLMv2 -> schlecht

[NorbertFe 2.034]

Das war auch nicht dazu gedacht, sich dann damit anzumelden, sondern dass ein komplexes Kennwort existiert, so dass man gar keine Lust hat sich damit anzumelden. ;)

[blub 115]

sorry, da hab ich es falsch verstanden

[takis.ch 10]

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 30. März 2016 von takis.ch

[blub 115]

jeder einfache User kann die Members der Administrator-Gruppe auslesen

[NilsK 2.934]

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 30. März 2016 von NilsK

[MurdocX 949]

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.

 

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

[NilsK 2.934]

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

[ChrisRa 42]

Aufgrund der Architektur ist LAPS für typische mittelständische Unternehmen i.d.R. nicht geeignet.

 

Könntest du dazu nicht mal was schreiben? Würde mich schon arg interessieren. 

 

Edit: Bitte?  :D

bearbeitet 30. März 2016 von ChrisRa

[NilsK 2.934]

Moin,

 

brauch ich nicht, gibt's schon, wenn auch nicht von mir:

 

[LAPS – lokales Admin-Passwort endlich sicher | faq-o-matic.net]
http://www.faq-o-matic.net/2015/07/01/laps-lokales-admin-passwort-endlich-sicher/

 

Gruß, Nils

[ChrisRa 42]

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.