Management lokale Passwörter - Domänenuser mit lokalen Adminrechten

[wznutzer 35]

Ein paar Stunden später ist mir eher klar was du mir sagen wolltest. Zusammengefasst sagst du: Melde dich einfach als 0815 Domänenuser ohne spezielle Rechte an. Poppt dann bei irgendeiner Arbeit z. B. die UAC auf, gibst du halt die per LAPS verwalteten lokalen Anmeldedaten ein. Alternativ die zur Verfügung stehenden Dinge wie ausführen als etc.. Das erfüllt meine Anforderungen, jedenfalls die die ich jetzt kenne . Bei irgendwelchen Bedenken wird das PW dieses einen 0815 Users geändert.

bearbeitet 4. April 2018 von wznutzer
Satz ergänzt

[NorbertFe 2.027]

Wäre eine Möglichkeit. Wie gesagt, wenn deine PCs quasi als jeweils abgegrenztes Tier betrachtet werden sollen, dann wäre dein Weg schon richtig, nur würde ich das eben nur bedingt als sinnvoll erachten. Wenn deine Anforderungen das notwendig machen, bleibt wie oben schon mehrfach geschrieben nur der manuelle Pflegeaufwand. Ansonsten siehe deine Antwort genau hier drüber. LAPS plus "normaler" Account.

 

Ansonsten sieh dir mal den Thread an: 

Ihr habt irgendwie eure Anforderungen und Lösungen vertauscht. ;) (nur ein Scherz)

Bye

Norbert 

[wznutzer 35]

Dann sage ich mal Danke für das schieben in die richtige Richtung.

[wznutzer 35]

Hi,

ich würde gerne das Thema noch mal nach oben holen.

 

Die grundsätzliche Empfehlung war ein 0815 Domänenuser und für Arbeiten die höhere Rechte auf den Clients erfordern ein lokaler Nutzer dessen PW mit LAPS verwaltet wird.

 

Ich könnte aber auch den 0815 Domänenuser an allen Clients in der OU in die Gruppe der lokalen Administratoren schieben. Wie wir bereits diskutiert haben ist das schlecht, weil Prozesse die in dessen Kontext laufen allerhand Dinge auf allen zur OU gehörenden Clients tun können. Aber ist es auch noch schlecht, wenn ich zusätzlich folgendes mache:

 

Option setzen: Account is sensitive and cannot be delegated

Per GPO für den Account unter Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments
Deny access to this computer from the network
Deny log on as a batch job
Deny log on as a service
Deny log on through Remote Desktop Services

 

Das sollte doch eine evtl. laufende Malware hindern sich auf weitere Rechner zu verbreiten? Evtl. Lücken mal ausgeschlossen.

[NilsK 2.930]

Moin,

 

ich glaube, du hast diese Optionen nicht richtig verstanden. Abgesehen davon, ist ein lokaler Admin eben lokaler Admin. Maßnahmen wie die genannten können evtl. in einem Gesamtkonzept eine Rolle spielen, aber es gibt kein kleines, überschaubares Set von Einstellungen, das Sicherheit "herstellt".

 

Solange nicht klar ist, was denn erreicht werden soll und vor welchen konkreten Gefahren du dich schützen willst, kann man keine passende Lösung entwerfen. Wobei je nach Anforderung eine Lösung durchaus ein größeres Projekt zur Entwicklung erfordern kann.

 

Allgemeine Anregungen findest du im Web zuhauf. Wenn dann konkrete Fragen bestehen, können wir die gern diskutieren.

 

Gruß, Nils

[wznutzer 35]

Guten Abend,

ich wärme diesen Thread nochmals auf.

Am 10.4.2018 um 21:02 schrieb NilsK:

ich glaube, du hast diese Optionen nicht richtig verstanden. Abgesehen davon, ist ein lokaler Admin eben lokaler Admin. Maßnahmen wie die genannten können evtl. in einem Gesamtkonzept eine Rolle spielen, aber es gibt kein kleines, überschaubares Set von Einstellungen, das Sicherheit "herstellt".

Solange nicht klar ist, was denn erreicht werden soll und vor welchen konkreten Gefahren du dich schützen willst, kann man keine passende Lösung entwerfen. Wobei je nach Anforderung eine Lösung durchaus ein größeres Projekt zur Entwicklung erfordern kann.

Allgemeine Anregungen findest du im Web zuhauf. Wenn dann konkrete Fragen bestehen, können wir die gern diskutieren.

Die Frage war, so dachte ich jedenfalls, konkret, aber evtl. kam das nicht richtig rüber. Wir brechen das ganz konkret runter. Keine Frage zu einem Konzept, nicht das große Ganze.

• Ich habe einen AD-User - AD0815
• Diesem User gebe ich an allen Domänenrechner lokale Adminrechte

• Ich setze folgende Einstellungen für diesen AD-User auf allen Domänenrechner
  Option setzen: Account is sensitive and cannot be delegated

  Per GPO für den Account unter Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments
  Deny access to this computer from the network
  Deny log on as a batch job
  Deny log on as a service
  Deny log on through Remote Desktop Services

Nach allem was ich bisher getestet habe, ist der User nur noch zum lokalen Anmelden (ich sitze davor) zu gebrauchen.

• Es kann nicht mehr auf Freigaben ohne weitere Eingabe vom Passwort zugegriffen werden, auch wenn diese für diesen User freigegeben sind.
• Der User kann nicht auf die $Freigaben zugreifen (remote).
• Der User kann nicht auf "normale" Freigaben zugreifen (remote).
• Der User kann z. B. keine WMI-Abfragen machen (remote).
• Der User kann sich nicht per RDP anmelden (remote).
• Der User kann keine Dienste starten (lokal).
• Der User kann keine Aufgaben ausführen (lokal).
• PsExec geht nicht mehr (remote)

Wenn das so eingerichtet ist, kann ich mich bedenkenlos mit diesem User an einer beliebigen Arbeitsstation anmelden, ohne die Sorge haben zu müssen, dass eine evtl. laufende Malware irgendwas mit den Credentials dieses Users im Netzwerk anstellen kann. Das wäre auch das Ziel.

 

Diese Frage ist aber, weiß ich was nicht, habe ich etwas falsch gemacht?

Mit welcher Technik könnte ich jetzt noch immer von PC A auf PC B zugreifen um z. B. Prozesse zu starten, Daten abzugreifen?

 

Vielen Dank

[NilsK 2.930]

Moin,

 

was soll man dazu sagen? Gemessen woran könntest du etwas "falsch" gemacht haben? Es bleibt unklar, was du wovor schützen willst. Und für mich bleibt unklar, wozu du so einen User brauchen könntest und warum der gewählte Weg in dem Szenario sinnvoll sein könnte. Kann sein, kann nicht sein, das ist so nicht zu entscheiden.

 

Ein Punkt springt weiter ins Auge: Dein User ist lokaler Admin. Er kann also sämtliche Einschränkungen abschalten. Vielleicht mit etwas Aufwand, aber bei den gegebenen Privilegien nicht verhinderbar.

 

Sorry, aber mehr kann ich dazu nicht beitragen.

 

Gruß, Nils

 

[wznutzer 35]

Hi,

ich glaube wir sehen das durch unterschiedliche Brillen (Sichtweisen). Deine Brille ist die Consulting-Brille: Pflichtenheft, Anforderungen, Konzept, das große Ganze. Das ist schwierig in einem Forum. Deswegen, so dachte ich, dein Hinweis auf eine ganz konkrete Frage. Diese ganz konkrete Frage habe ich formuliert. Nun sagst du, dass die konkrete Frage nicht beantwortet werden kann ohne das große Ganze. Aber natürlich ist das OK, ich habe keinerlei Ansprüche. In einem Forum bittet man und fordert nicht (als Fragender).

 

Schafft man es mit den oben genannten Einstellungen Prozesse von PC A auf PC B mit Kenntnis der Credentials zu starten? Ohne diese Einstellungen ist das einfach möglich. Entweder es geht, oder es geht nicht. Im Moment sieht es für mich so aus, als ob es nicht geht. Würde ich auf PC A Malware feststellen ist es völlig egal was da gelaufen ist, da wird ein sauberes Backup wiederhergestellt. Aber auf PC B ist nichts passiert.

 

Ich werde einfach noch weiter testen/recherchieren, das Ergebnis, egal welcher Art, poste ich hier.

 

Außerdem hilfst du mir trotzdem. Ich bin kürzlich über ein paar Videos von dir (CIM) gestolpert, die sehe ich mir demnächst an .

 

Grüße

[zahni 550]

Du kannst einen User mit lokalen Adminrechten nicht einschränken. 

Alle Einstellungen, die Du da machen willst, lassen sich u.a. mit Regedit und dem Editor für lokale Sicherheitsrichtlinien wieder entfernen.

 

Einer der Gründe, warum Nils nach dem Konzept fragt. Vielleicht gibt es ja eine bessere Lösung.

bearbeitet 25. April 2018 von zahni

[wznutzer 35]

Am 25.4.2018 um 21:43 schrieb zahni:

Du kannst einen User mit lokalen Adminrechten nicht einschränken. 

Das ist völlig klar und habe ich mit keiner Silbe angezweifelt. Es gibt hier aber, denke ich, ein Missverständnis.

 

Beispiel:
Du bist der böse Bube aus Malware-City und hast es geschafft meinen PC A zu kompromittieren. Deine Malware läuft mit Adminrechten und da du mit allen Wassern gewaschen bist, hast du die genannten Einschränkungen rückgängig gemacht, mit Mimikatz bist du auch auf du und du und evtl. hast du sogar das Passwort meines User0815 im Klartext. PC A kann man vergessen, darum geht es gar nicht mehr. Nun versuchst du auf PC B zuzugreifen, das wird dir dann so eher (derzeitiger Wissensstand) nicht gelingen. Daran hindern dich ein paar (nicht alle) der Einstellungen. Da du in Malware-City sitzt, kannst du nicht einfach hinlaufen und dich lokal anmelden, du musst das über das Netzwerk machen. Darum geht es, der Zugriff von PC A auf PC B. Es nützt dir nichts, wenn du auf PC B irgendwas rückgängig machen könntest wenn du Zugriff hast, weil du eben keinen Zugriff hast.

 

Die konkrete Frage war: Ist es doch irgendwie möglich auf PC B zuzugreifen/Prozesse zu starten und wenn ja wie kann dann das verhindert werden (Voraussetzungen siehe oben).

 

Ein schönes (langes?) Wochenende wünsche ich euch.

 

bearbeitet 28. April 2018 von wznutzer
Schreibfehler

[NilsK 2.930]

Moin,

 

auch wenn du sehr interessante Vermutungen über mich und meine Brille (ich habe keine) anstellst: Du verfolgst hier offenbar eine akademische Frage. Ein zu erreichendes operatives Ziel gibst du zumindest nicht an, du versteifst dich auf deine selbst gewählte Frage. Kann man machen, aber für mich hat das keine Relevanz. Mir ist nicht klar, wozu man einen Domänenuser mit lokalen Adminrechten ausstattet, wenn man gleichzeitig versucht, ihn so einzuschränken, als wäre er kein Domänenbenutzer. Klar, da kann man rein technisch einiges machen. Für mich fehlt aber der Nutzen, weswegen ich mich nicht weiter damit befasse. Wüsste ich, was das operative Ziel ist, könnte ich mir überlegen, wo ich die Grenzen des Ansatzes sehe oder ob mir Alternativen einfallen.

 

Dass du mit dem Konzept einen Rechner wirklich malware-sicher bekommst, bezweifle ich dennoch energisch. Dein Konzept ist blind gegenüber anderen Lücken, die ein nicht abgedichtetes Windows in üblichen Betriebsweisen hat. Es kümmert sich eben nur um diese eine Frage. Daher mein Hinweis, dass man solche Dinge sicher in einem Gesamtkonzept brauchen kann, aber allein bringt es nach meiner Ansicht ausgesprochen wenig.

 

Damit ist für mich hier Schluss.

 

Gruß, Nils

 

[wznutzer 35]

Guten Morgen,

ich fasse nochmals kurz zusammen um was es hier ging. Ich meine man sollte Threads nicht einfach im Nichts enden lassen.

 

Zu Anfangs ging es um die Verwaltung der lokalen Accounts: Empfehlung LAPS

 

Die Diskussion ging dann über wie ein Wartungsaccount für Domänenmitglieder aussehen könnte: Empfehlung Domänenuser ohne lokale Adminrechte + lokaler Account mit dem PW aus LAPS.

 

Weiter ging es dann mit der Frage ob ein Domänenuser mit lokalen Adminrechten und den genannten Einstellungen nicht genauso gut wäre: Keine Empfehlung bzw. unterschiedliche Meinungen.

 

Meine Überlegungen dazu waren: Es ist so schlicht einfacher/bequemer und dem Domänenuser ohne lokale Adminrechte müsste ich das Recht geben die per LAPS vergebenen Passwörter aus dem AD auszulesen. Das kann dann aber auch Malware. Das schmeckt mir wiederum nicht. Hat der User nicht das Recht das PW zu ermitteln muss das ein anderer User, schreibe ich dann das PW auf einen Zettel um es bei der UAC-Abfrage einzugeben?

 

Alle einzelnen Maßnahmen eines Sicherheitskonzeptes sind auf unterster Ebene immer irgendwie akademischer Natur. Wie lang muss das Passwort sein, macht das Scannen mit dem verbundenen Aufbrechen verschlüsselter Verbindungen Sinn, filtere ich Email-Anhänge, betreibe ich Geo-Blocking usw..

 

Ich habe hier im Forum einfach mal nach Malware gesucht. Erstaunt haben mich die teilweise unwidersprochenen Kommentare, dass bei Malware auf einem einzelnen Rechner das komplette Netzwerk neu installiert werden soll. Sollte eine durchdachte Rechtevergabe nicht genau das verhindern können? In diese Richtung gehen meine Überlegungen. Microsoft denkt auch darüber nach: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory. Da habe ich auch die Empfehlungen entnommen.

 

Ich schätze alle weiteren Kommentare, ansonsten können wir das auch beenden.

[zahni 550]

vor 15 Stunden schrieb wznutzer:

Das ist völlig klar und habe ich mit keiner Silbe angezweifelt. Es gibt hier aber, denke ich, ein Missverständnis.

 

Beispiel:
Du bist der böse Bube aus Malware-City und hast es geschafft meinen PC A zu kompromittieren. Deine Malware läuft mit Adminrechten und da du mit allen Wassern gewaschen bist, hast du die genannten Einschränkungen rückgängig gemacht, mit Mimikatz bist du auch auf

Nö, bin ich  nicht.

 

Du solltest Dir einfach die Infektionswege überlegen. Remote-Infektionen sind eher selten und basieren  Sicherheitslücken. 

Wie willst Du aber ein Programm blockieren, das direkt auf der Konsole ausgeführt wird? Das setzt in Windeseile alle Sicherheitseinrichtungen zurück. Besonders, wenn UAC aus ist. Eine Weiterverbreitung ist dann über klassische Dateiinfektion möglich.

Daher macht es keinn Sinn über solche Dinge nachzudenken. Es gibt auch genügend Passwort-Manager, bei denen man lokale Admins sicher verwalten kann. Recht interessant finde ich https://www.manageengine.com/products/passwordmanagerpro/ Damit kann man z.B. einmalig gültige Passwörter verwalten usw.

bearbeitet 28. April 2018 von zahni