Wie 2-FA für Admin Accounts in onPrem Windows Domänen?
Hallo, ich wollt einfach mal in die Runde fragen - wie sichert ihr eure Administrator Accounts ab in nicht-Cloud Windows Server Umgebungen.
Speziell das Thema 2 Faktor Authentisierung würde mich da mal interessieren, mit welchen mitteln man das absichern kann und wie praktikabel das dann ist.
Wenn man jetzt z.B. einem Mitarbeiter helfen muss auf seinem Client PC, und man schaltet sich per Teamviewer auf den ClientPC - wie kann man da ein Programm nachinstallieren oder die Registry bearbeiten mit administrativen rechten? Wenn da die UAC hoch ploppt und man einen Administrativen Account angibt - wie soll dann da eine 2 FA funktionieren wenn man selber nicht vorot ist um mit einer SmartCard oder einem USB Stick zu arbeiten?
Speziell das Thema 2 Faktor Authentisierung würde mich da mal interessieren, mit welchen mitteln man das absichern kann und wie praktikabel das dann ist.
Wenn man jetzt z.B. einem Mitarbeiter helfen muss auf seinem Client PC, und man schaltet sich per Teamviewer auf den ClientPC - wie kann man da ein Programm nachinstallieren oder die Registry bearbeiten mit administrativen rechten? Wenn da die UAC hoch ploppt und man einen Administrativen Account angibt - wie soll dann da eine 2 FA funktionieren wenn man selber nicht vorot ist um mit einer SmartCard oder einem USB Stick zu arbeiten?
Please also mark the comments that contributed to the solution of the article
Content-ID: 1493922016
Url: https://administrator.de/contentid/1493922016
Printed on: October 15, 2024 at 15:10 o'clock
14 Comments
Latest comment
Hi,
die internen Admin-Accounts sind bei uns nicht mit 2FA gesichert.
Für dein Beispiel würde ich persönlich aber auch immer den lokalen Admin des jeweiligen Clients benutzen, der mit Hilfe von LAPS (www.msxfaq.de/windows/endpointsecurity/laps.htm) ein individuelles PW hat.
Grund:
- Unabhängig von Verbindung zur Domain
- Kann schlimmstenfalls diesen PC versauen (wenn böse Tiere dort wohnen)
- Selbst wenn ein Key-Logger drauf ist, hat der Böse Mensch erstmal nur das lokale Admin-PW, aber nicht gleich einen Domainaccount der als Admin vermutlich auch noch sehr weitreichende Rechte hat.
die internen Admin-Accounts sind bei uns nicht mit 2FA gesichert.
Für dein Beispiel würde ich persönlich aber auch immer den lokalen Admin des jeweiligen Clients benutzen, der mit Hilfe von LAPS (www.msxfaq.de/windows/endpointsecurity/laps.htm) ein individuelles PW hat.
Grund:
- Unabhängig von Verbindung zur Domain
- Kann schlimmstenfalls diesen PC versauen (wenn böse Tiere dort wohnen)
- Selbst wenn ein Key-Logger drauf ist, hat der Böse Mensch erstmal nur das lokale Admin-PW, aber nicht gleich einen Domainaccount der als Admin vermutlich auch noch sehr weitreichende Rechte hat.
Zitat von @Drohnald:
Selbst wenn ein Key-Logger drauf ist, hat der Böse Mensch erstmal nur das lokale Admin-PW, aber nicht gleich einen Domainaccount der als Admin vermutlich auch noch sehr weitreichende Rechte hat.
Selbst wenn ein Key-Logger drauf ist, hat der Böse Mensch erstmal nur das lokale Admin-PW, aber nicht gleich einen Domainaccount der als Admin vermutlich auch noch sehr weitreichende Rechte hat.
Idealerweise hat man für administrative Tätigkeiten auch einen dedizierten Client Admin Account den man dafür nutzt, einen Account mit Domain Admin Berechtigungen braucht man im Alltag fast nie.
Idealerweise hat man für administrative Tätigkeiten auch einen dedizierten Client Admin Account den man dafür nutzt, einen Account mit Domain Admin Berechtigungen braucht man im Alltag fast nie.
Völlig richtig. War missverständlich formuliert.Was ich meinte: Der Admin-Account wäre ein Account der Domain (was der lokale Admin ja nicht ist); Der kann also schon mal jede read-only Abfrage an den DC stellen. Gleichzeitig wäre aber selbst der dedizierte Client Admin Account zumindest auf allen Clients Admin. Könnte also jeden einzelnen Client infizieren, der erreichbar ist.
Moin,
wir wollten uns schon seit längerem einmal Google Duo ansehen, aber der Tag hat immer so wenig Stunden
https://duo.com/docs/rdp
Die Adminfrage ist so gelöst:
https://duo.com/docs/administration-admins
@thomka
Machen wir für unsere Lehrsaal-Rechner so und wechseln regelmäßig das Passwort. Ansonsten ist das auch eine schöne Sicherheitslücke, meist kümmert sich um den Account niemand mehr. Für User-Rechner wäre die LAPS-Lösung schlauer.
Gruß
wir wollten uns schon seit längerem einmal Google Duo ansehen, aber der Tag hat immer so wenig Stunden
https://duo.com/docs/rdp
Die Adminfrage ist so gelöst:
https://duo.com/docs/administration-admins
@thomka
Idealerweise hat man für administrative Tätigkeiten auch einen dedizierten Client Admin Account den man dafür nutzt, einen Account mit Domain Admin Berechtigungen braucht man im Alltag fast nie.
Machen wir für unsere Lehrsaal-Rechner so und wechseln regelmäßig das Passwort. Ansonsten ist das auch eine schöne Sicherheitslücke, meist kümmert sich um den Account niemand mehr. Für User-Rechner wäre die LAPS-Lösung schlauer.
Gruß
Hallo,
wir schleichen da auch schon eine weile drum herum. Das Problem ist, dass man die Admin-Account entweder gar nicht braucht - oder im Problemfall (vielleicht abgesehen von der Softwareinstallation). Wenn dann der Problemfall eintritt, muss der der MFA Login weiter funktionieren und nicht darf gestört sein.
Bei uns sind die Clients und Member-Server alle mit LAPS ausgestattet. Das erfordert einen funktionierenden Domänencontroller auf den ich im Notfall auch zugreifen kann. Wenn ich den Zugang zum DC jetzt auch noch weiter verrammele - wie läuft der Login dann im Notfallszenario ab?
Zweiter Punkt. Wenn Admin-Rechte erforderlich sind, kann man die auch Zeitweise vergeben - was dann im Grunde einer MFA ähnlich ist. Ein Admin erteilt dem anderen die erforderlichen Rechte - auf Zeit. Hier die Azure-Variante https://docs.microsoft.com/de-de/azure/active-directory/privileged-ident ...
Grüße
lcer
wir schleichen da auch schon eine weile drum herum. Das Problem ist, dass man die Admin-Account entweder gar nicht braucht - oder im Problemfall (vielleicht abgesehen von der Softwareinstallation). Wenn dann der Problemfall eintritt, muss der der MFA Login weiter funktionieren und nicht darf gestört sein.
Bei uns sind die Clients und Member-Server alle mit LAPS ausgestattet. Das erfordert einen funktionierenden Domänencontroller auf den ich im Notfall auch zugreifen kann. Wenn ich den Zugang zum DC jetzt auch noch weiter verrammele - wie läuft der Login dann im Notfallszenario ab?
Zweiter Punkt. Wenn Admin-Rechte erforderlich sind, kann man die auch Zeitweise vergeben - was dann im Grunde einer MFA ähnlich ist. Ein Admin erteilt dem anderen die erforderlichen Rechte - auf Zeit. Hier die Azure-Variante https://docs.microsoft.com/de-de/azure/active-directory/privileged-ident ...
Grüße
lcer
Zitat von @Coreknabe:
Machen wir für unsere Lehrsaal-Rechner so und wechseln regelmäßig das Passwort. Ansonsten ist das auch eine schöne Sicherheitslücke, meist kümmert sich um den Account niemand mehr. Für User-Rechner wäre die LAPS-Lösung schlauer.
Machen wir für unsere Lehrsaal-Rechner so und wechseln regelmäßig das Passwort. Ansonsten ist das auch eine schöne Sicherheitslücke, meist kümmert sich um den Account niemand mehr. Für User-Rechner wäre die LAPS-Lösung schlauer.
Warum kümmert sich um den Account niemand mehr? Das soll ja keine einzelner Account sein den alle nutzen, sondern ein persönlicher Account des Admins.
/Thomas
@lcer
Das haben wir mit einem kleinen Powershellskript gelöst. Jede Nacht werden die Passwörter in eine Datei auf dem DC geschrieben, verschlüsselt mit einem Archiv-Passwort und auf unseren Fileserver weggespeichert. Die Datei auf dem DC wird danach gelöscht. So haben wir die aktuellen Passwörter immer in einer CSV greifbar, für Notfälle.
@Th0mKa
Ich habe mich blöd ausgedrückt, in der Regel hat der dann ein Passwort, was nie wieder angefasst wird. Anderes Problem: Der Azubi / Dienstleister soll auch mal was installieren. Im Zweifel egal, weil das Passwort in einem Monat wieder ein anderes ist bzw. ich ein neues spontan antriggern kann. Und eben die Ein-Passwort-für-alle-Problematik.
Gruß
Bei uns sind die Clients und Member-Server alle mit LAPS ausgestattet. Das erfordert einen funktionierenden Domänencontroller auf den ich im Notfall auch zugreifen kann. Wenn ich den Zugang zum DC jetzt auch noch weiter verrammele - wie läuft der Login dann im Notfallszenario ab?
Das haben wir mit einem kleinen Powershellskript gelöst. Jede Nacht werden die Passwörter in eine Datei auf dem DC geschrieben, verschlüsselt mit einem Archiv-Passwort und auf unseren Fileserver weggespeichert. Die Datei auf dem DC wird danach gelöscht. So haben wir die aktuellen Passwörter immer in einer CSV greifbar, für Notfälle.
@Th0mKa
Ich habe mich blöd ausgedrückt, in der Regel hat der dann ein Passwort, was nie wieder angefasst wird. Anderes Problem: Der Azubi / Dienstleister soll auch mal was installieren. Im Zweifel egal, weil das Passwort in einem Monat wieder ein anderes ist bzw. ich ein neues spontan antriggern kann. Und eben die Ein-Passwort-für-alle-Problematik.
Gruß
Z.B. so: https://support.yubico.com/hc/en-us/articles/360015654500-Setting-up-Win ...
Praktisch so:
- RDP öffnen
- smartcard stecken
- smartcard als Login auswählen
- verbinden PIN eingeben und ggf. bei Yubikey 1-2x auf das Knöpfchen drücken
Grüße
lcer