Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
takis.ch

Built-In Administrator auf Server daktivieren

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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?

 

;)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von ChrisRa

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×