Domain User in der lokalen Admin Gruppe (Clients)

[phatair 39]

Hallo zusammen,

 

ich habe auf dem Born Blog einen interessanten Artikel gelesen, der mich etwas zum nachdenken gebracht hat.

https://www.borncity.com/blog/2021/09/11/active-directory-vor-ransomware-attacken-schtzen/

 

Wir haben vor ein paar Jahren unsere Admin Accounts wie folgt aufgeteilt:

- jeder Admin arbeitet an seinem Geräte mit einem normalen AD Account ohne erhöhte Rechte.

- für Server Tätigkeiten hat jeder Admin einen eigenen Server Admin. Dieser wird per GPO auf die benötigten Server in die lokale Admin Gruppe eingetragen. So hat nicht jeder Admin auf alle Server zugriff.

- für Client Tätigkeiten hat jeder Admin einen eignen Client Admin. Dieser wird ebenso per GPO auf die benötigten Clients in die lokale Admin Gruppe eingetragen.

- der lokale Standard Admin auf den Servern ist deaktiviert und ein neuer mit geändertem Namen wurde erstellt. Jeder dieser lokalen Server Admin Accounts hat ein eigenes Passwort (aktuell noch ohne LAPS)

 

Über das Thema hatten wir 2019 hier schon mal diskutiert :)

 

Nun schlägt der Beitrag auf borncity.com ja unteranderem folgende Maßnahme vor:

• Erstens, muss das lokale Administratorkennwort auf jedem Endpunkt unterschiedlich sein. Microsoft offeriert hierfür eine kostenlose Lösung namens Local Administrator Password Solution (LAPS).
• Zweitens, sollten keine Domain-Konten in der Gruppe der lokalen Administratoren miteinander verwoben sein, um einen einfachen IT-Support zu ermöglichen.

 

Punkt 1 mit LAPS wollen wir demnächst auch auf den Clients angehen und klingt für mich schlüssig (ich weiß, es gibt noch andere Tools mit denen man das machen kann).

Punkt 2 ist für mich im Moment sehr sperrig und hier würde mich mal eure Meinung interessieren. Sicherheit geht meistens mit Komfort Verlust einher, aber das klingt für mich nicht ganz so praxistauglich.

Das würde ja bedeuten, dass ich nur noch lokale Admins über LAPS erstelle und damit auch die administrative Tätigkeiten auf den Clients ausführen kann. Bin ich also beim User vor Ort und muss dort erhöhte Rechte anfordern, muss ich irgendwie and das LAPS kommen, sonst kann ich nichts tun.

Wie handhabt ihr das bei euch? Ähnlich wie wir  - mit getrennten Admin Accounts oder ganz anders?

Würde mich interessieren. Vielleicht verstehe ich den obigen Vorschlag auch falsch oder habe einen Denkfehler :)

 

Grüße!

 

[NilsK 2.930]

Moin,

 

gemeint ist vor allem eine funktionale Trennung von Adminkonten. Ein Client-Adminkonto darf nicht genutzt werden, um auf einem Server zu administrieren. Und ein Serveradmin soll nicht das AD manipulieren. Umgekehrt soll sich ein AD-Admin gar nicht auf einem Client anmelden können usw. Vor allem Letzteres ist relevant: Keine Admins höherer Sicherheitsbereiche auf Rechnern niedrigerer Stufen - heißt: keine Anmeldung für deren Konten. Ein Weg dazu kann LAPS sein, wobei ich es insgesamt nicht so sehe, dass das der einzige Weg dazu wäre (zumal LAPS so toll nun auch wieder nicht ist).

 

Schau mal nach "Administrative Tiering" und "ESAE".

 

Gruß, Nils

 

bearbeitet 13. September 2021 von NilsK
hatte zu früh auf Senden geklickt

[Sunny61 806]

vor 22 Minuten schrieb phatair:

Bin ich also beim User vor Ort und muss dort erhöhte Rechte anfordern, muss ich irgendwie and das LAPS kommen, sonst kann ich nichts tun.

Dann beim Kollegen anrufen und das PW aus der LAPS GUI für diesen Client geben lassen. Alternativ per Remoteunterstützung auf den Client kommen.

[phatair 39]

Hi Nils,

 

ok, dass klingt dann für mich schon schlüssiger :)

Ich werde nach den beiden Schlagworten mal googlen.

 

Die Trennung der Admin Accounts haben wir schon fast komplett durchgezogen.

Was uns noch fehlt sind die PAWs. 

Demnächst haben wir erstmal ein AD Security Audit und da bin ich dann mal gespannt was noch so alles auf uns zukommt (ldap channel binding and ldap signing, usw). Aber das ist ein anderes Thema.

 

  

vor 1 Minute schrieb Sunny61:

Dann beim Kollegen anrufen und das PW aus der LAPS GUI für diesen Client geben lassen. Alternativ per Remoteunterstützung auf den Client kommen.

Remoteunterstützung oder Telefon ist natürlich klar. Mir ging es vor allem um die grundsätzliche Idee und ob ich diese so wirklich richtig verstanden haben.

Es kann natürlich schon dazu führen, dass der Support etwas in die länge gezogen wird und da stellt sich dann die Frage ob Aufwand - Nutzen wirklich so groß ist.

Die Trennung, die der Nils erwähnt hat, klingt für mich im ersten Schritt auf jeden fall praxistauglicher :)

 

Gruß,

Steffen

 

bearbeitet 13. September 2021 von phatair

[daabm 1.348]

Ich schmeiß mal meinen inzwischen auch schon recht betagten Post dazu in den Ring: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html

Und nein, Domain Admins haben auf Clients und Member Servern kein Recht, sich anzumelden. Läßt sich damit prima umsetzen

[phatair 39]

Danke

vor 2 Stunden schrieb daabm:

Ich schmeiß mal meinen inzwischen auch schon recht betagten Post dazu in den Ring: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html

 

Danke! Deinen Post habe ich mir schon vor 2 Jahren angeschaut und Anregungen geholt :)

 

Ich habe auch ein paar sehr gute Beiträge über die AD Absicherung bei Frankysweb.de gefunden.

Hier geht es auch um das einrichten von Tiering, PAWs und LAPS.

Wenn wir nächste Woche unser AD Audit abgeschlossen haben, werde ich mich mal noch tiefer mit diesen Themen beschäftigen und diese dann bei uns umsetzen.

Ein paar Fragen habe ich jetzt schon, aber wenn die nach dem AD Audit noch offen sind werde ich einen neun Thread dazu eröffnen.

 

Danke für eure Hilfe.

[MurdocX 949]

Am 13.9.2021 um 09:54 schrieb phatair:

Punkt 1 mit LAPS wollen wir demnächst auch auf den Clients angehen und klingt für mich schlüssig (ich weiß, es gibt noch andere Tools mit denen man das machen kann).

Wir haben auch LAPS im Einsatz. Sobald die Computer Notebooks sind, die sich unregelmäßig und meist von extern mit dem Firmennetz verbinden, wird's schwierig  Interne Computer machen keine Probleme.

[phatair 39]

vor 27 Minuten schrieb MurdocX:

Wir haben auch LAPS im Einsatz. Sobald die Computer Notebooks sind, die sich unregelmäßig und meist von extern mit dem Firmennetz verbinden, wird's schwierig  Interne Computer machen keine Probleme.

Den Gedanken mit den Notebooks hatte ich auch. Ich hatte gehofft, dass die Geräte, die zu dem Zeitpunkt der geplanten Passwortänderung nicht das AD erreichen können, diese Änderung aufschieben bis sie wieder eine AD Verbindung haben und das neue Passwort übertragen können.

Deiner Aussage entnehme ich - dem ist nicht so? :(

[NorbertFe 2.027]

vor 3 Stunden schrieb MurdocX:

Sobald die Computer Notebooks sind, die sich unregelmäßig und meist von extern mit dem Firmennetz verbinden, wird's schwierig

Was genau meinst du?

vor 2 Stunden schrieb phatair:

Ich hatte gehofft, dass die Geräte, die zu dem Zeitpunkt der geplanten Passwortänderung nicht das AD erreichen können, diese Änderung aufschieben bis sie wieder eine AD Verbindung haben und das neue Passwort übertragen können.

Die Passworte werden erst geändert, wenn Schreibzugriff ins AD besteht. Könnte man übrigens in der sehr guten Doku von LAPS auch nachlesen.

Zitat

-          Client Side Group Policy Extension that is installed on each domain-joined computer. CSE will be responsible for the following tasks:

o   Management of password of Administrator password:

•  Checking whether the password of Administrator account has expired or not
•  Generating the new password when old password expires or is required to be changed prior to expiration
•  Validating newly generated password against password policy that is in place
•  Reporting the password to password repository
•  Reporting the next expiration time to password repository
•  Changing the password of Administrator account

 

[MurdocX 949]

vor einer Stunde schrieb NorbertFe:

Was genau meinst du?

AFAIR wird der Vorgang von der CSE angestoßen. Der Anmeldevorgang findet überwiegend mit Cached Credentials statt. Dadurch laufen unsere Passwörter öfters mal ab.

[NorbertFe 2.027]

Kann eigentlich nicht sein. Denn wie oben zitiert wird das Kennwort durch die CSE erst dann auch gesetzt, wenn sie es im AD hinterlegt _hat_.  So ist jedenfalls meine Lesart und bisher auch Erfahrung.

bearbeitet 14. September 2021 von NorbertFe

[MurdocX 949]

Damit liegst du auch richtig  Es läuft nur meist bei uns vorher ab, bevor ein neues gesetzt wird. Unser Intervall ist recht kurz.

[NorbertFe 2.027]

Versteh ich nicht. Ist euer Intervall 2 Minuten?

[MurdocX 949]

Das soll jetzt nicht das Thema hier sein. Wir können uns gerne per PM austauschen.

[phatair 39]

Ich werde es zwar noch mal bei uns testen, aber vielleicht könnt ihr mir trotzdem noch mal auf die Sprünge helfen. 

Ich verstehe das jetzt so:

- ich definiere einen Zeitpunkt, wann das lokale Passwort von der CSE geändert werden soll -> z.B. alter 30 Tage

- die CSE generiert ein neues lokale Admin Passwort, wenn dieses Alter erreicht ist und versucht dieses dann in der AD zu speichern

- Ist die Speicherung erfolgreich, wird es auf dem Client geändert

 

Das würde für mich bedeuten, wenn z.B. ein Notebook außer Haus ist und die AD nicht erreicht werden kann, wird das Passwort auch nicht geändert. Auch wenn der Zeitpunkt laut Policy schon gegeben ist.

Ist dafür die GPO "Do not allow password expiration time longer than required by policy" verantwortlich? Würde ich diese aktivieren, wird das Passwort gesetzt sobald der Zeitpunkt für die Passwort Änderung überschritten ist und es wird nicht geprüft ob die AD erreicht werden kann?

 

Ich werde hier aus der Doku noch nicht ganz schlau.

Vielen Dank.