Lokale Admin Konten mit MFA absichern
Hallo zusammen,
gibt es eine, möglichst kostenlose oder zumindest kostengünstige, Lösung um lokale Admin Konten auf Windows Server per MFA abzusichern?
Konkret geht es um meinen Backup Server, der logischerweise vom AD getrennt ist und nur zwei lokale Admin Konten hat. Und genau die würde ich gerne mit einem zweiten Faktor versorgen, z.B. einem OTP.
Ich setze zwar NetIQ Advanced Authentication ein, aber da muss ich ein Repository mit der Benutzerverwaltung angeben, eben z.B. ein AD. Das geht aber ja bei lokalen Konten nicht.
Hat hier jemand vielleicht schon etwas im Einsatz?
Danke im Voraus.
Michael
gibt es eine, möglichst kostenlose oder zumindest kostengünstige, Lösung um lokale Admin Konten auf Windows Server per MFA abzusichern?
Konkret geht es um meinen Backup Server, der logischerweise vom AD getrennt ist und nur zwei lokale Admin Konten hat. Und genau die würde ich gerne mit einem zweiten Faktor versorgen, z.B. einem OTP.
Ich setze zwar NetIQ Advanced Authentication ein, aber da muss ich ein Repository mit der Benutzerverwaltung angeben, eben z.B. ein AD. Das geht aber ja bei lokalen Konten nicht.
Hat hier jemand vielleicht schon etwas im Einsatz?
Danke im Voraus.
Michael
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668782
Url: https://administrator.de/forum/lokale-admin-konten-mit-mfa-absichern-668782.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
32 Kommentare
Neuester Kommentar
Hi.
Deine Beschreibung lässt noch Fragen offen
Wenn Du damit Maschinen/Daten aus der Domäne sicherst, warum ist dann "logischerweise" der Backupserver nicht im AD? Ich kann mir vorstellen, dass Du die Vorstellung hast, ohne Domänenmitgliedschaft wäre das sicherer, aber beschreibe doch einmal, warum der nicht im AD ist.
Dann musst Du bitte das OS des Backupservers nennen und auch, wie Du dich dort anmeldest (Konsole und/oder RDP)?
Nicht zuletzt die Frage: warum willst Du MFA nutzen?
Welche Gefahren siehst Du?
Ist der Backupserver in einem sicheren Raum, oder nicht?
Ich nenne dir dennoch spontan 3 einfache Tools für MFA bei lokalen Konten:
Yubico Login (eine Software von Yubico, die mit Yubikeys zusammen kombinierbar ist - nur wer Yubikey und PW hat, kommt rein)
EIDauthenticate - kombinierbar mit einer virtuellen oder physikalischen SmartCard kann man sich per Smartcard + PIN anmelden
Rohos Logon Key - Kennwort plus USB-key
Darüber hinaus kann man natürlich auch mit Biometrie arbeiten, wenn Ihr das wollt.
Deine Beschreibung lässt noch Fragen offen
Wenn Du damit Maschinen/Daten aus der Domäne sicherst, warum ist dann "logischerweise" der Backupserver nicht im AD? Ich kann mir vorstellen, dass Du die Vorstellung hast, ohne Domänenmitgliedschaft wäre das sicherer, aber beschreibe doch einmal, warum der nicht im AD ist.
Dann musst Du bitte das OS des Backupservers nennen und auch, wie Du dich dort anmeldest (Konsole und/oder RDP)?
Nicht zuletzt die Frage: warum willst Du MFA nutzen?
Welche Gefahren siehst Du?
Ist der Backupserver in einem sicheren Raum, oder nicht?
Ich nenne dir dennoch spontan 3 einfache Tools für MFA bei lokalen Konten:
Yubico Login (eine Software von Yubico, die mit Yubikeys zusammen kombinierbar ist - nur wer Yubikey und PW hat, kommt rein)
EIDauthenticate - kombinierbar mit einer virtuellen oder physikalischen SmartCard kann man sich per Smartcard + PIN anmelden
Rohos Logon Key - Kennwort plus USB-key
Darüber hinaus kann man natürlich auch mit Biometrie arbeiten, wenn Ihr das wollt.
Hallo,
solange du das ganze mit Windof betreibst, kannst du mit MFA baden gehen .... Denn das Problem besteht darunter.
Denk immer daran MFA brauch eine Person ( Token / Passwort / Handy ..... )
Ein Backup Server soll gleich Administrierbar sein, wie der Server, den er ersetzt.
MFA ist ein netter Gedanke, aber nervrt in der Praxis vom feinsten, keiner will X Apps oder X Tockns am Schlüsselbund.
grüße
solange du das ganze mit Windof betreibst, kannst du mit MFA baden gehen .... Denn das Problem besteht darunter.
Denk immer daran MFA brauch eine Person ( Token / Passwort / Handy ..... )
Ein Backup Server soll gleich Administrierbar sein, wie der Server, den er ersetzt.
MFA ist ein netter Gedanke, aber nervrt in der Praxis vom feinsten, keiner will X Apps oder X Tockns am Schlüsselbund.
grüße
. Aus dem Grund ist mein Backup Server nicht an das AD gebunden, sondern hat eben lokale Admins mit komplexem Passwort. Das ist meines Wissens nach eine Empfehlung von Veeam. Ich finde das nur gerade nicht auf die Schnelle.
Nun möchte ich eben genau diesen Admin User zusätzlich noch mit einem zweiten Faktor absichern
Nun möchte ich eben genau diesen Admin User zusätzlich noch mit einem zweiten Faktor absichern
Nun wie soll sich dein Backup Server mit MFA am Hauptserver melden zum Backup machen? Da würde es dann immer eine Person brauchen, automatisierte Backups, Gute Nacht
Zitat von @beck2oldschool:
Vor allem sind die FIDO2 Key am Schlüsselbund des Users. Verlässt er den Raum / Firma, nimmt er seinen Schlüssel mit und der PC ist damit gleich gesperrt.
Zitat von @godlie:
MFA ist ein netter Gedanke, aber nervrt in der Praxis vom feinsten, keiner will X Apps oder X Tockns am Schlüsselbund.
Erfahrungsgemäß tut das nur am Anfang weh. Wie geschrieben setzen wir MFA auf allen PCs ein. Das (komplexe) Windows Passwort muss man so oder so eingeben. Und danach noch eine PIN + FIDO2 Key drücken ist auch kein Aufwand mehr. Oder, wenn Push eingerichtet, klicke ich auf dem Smartphone nochmal nen Button. Das funktioniert beides auch im Außendienst auf Surface Geräten super.MFA ist ein netter Gedanke, aber nervrt in der Praxis vom feinsten, keiner will X Apps oder X Tockns am Schlüsselbund.
Vor allem sind die FIDO2 Key am Schlüsselbund des Users. Verlässt er den Raum / Firma, nimmt er seinen Schlüssel mit und der PC ist damit gleich gesperrt.
Hm du hast scheinbar Junge Mitarbeiter die den "Aufwand" mitmachen...
Zitat von @beck2oldschool:
Ich sichere mit Veeam VMs vom vCenter. Dort gibt es einen (lokalen) User mit einem sehr langen und komplexen Kennwort. Das muss man dann auch nirgends eingeben. Und dieser User hat natürlich auch nur die Berechtigungen, die er auch tatsächlich braucht...
Mir geht es um die User, die sich interaktiv an dem Server anmelden müssen.
Zitat von @godlie:
Nun wie soll sich dein Backup Server mit MFA am Hauptserver melden zum Backup machen? Da würde es dann immer eine Person brauchen, automatisierte Backups, Gute Nacht
Nun wie soll sich dein Backup Server mit MFA am Hauptserver melden zum Backup machen? Da würde es dann immer eine Person brauchen, automatisierte Backups, Gute Nacht
Ich sichere mit Veeam VMs vom vCenter. Dort gibt es einen (lokalen) User mit einem sehr langen und komplexen Kennwort. Das muss man dann auch nirgends eingeben. Und dieser User hat natürlich auch nur die Berechtigungen, die er auch tatsächlich braucht...
Mir geht es um die User, die sich interaktiv an dem Server anmelden müssen.
Denk nochmal kurz nach, Backup Server MFA, !Use!r die sich anmelden können ......
Für Ratschläge in Punkto Sicherheit fehlt in der Tat noch die Beschreibung, wie denn Backups geschrieben werden: push (Prozess am Client) oder pull (Prozess am Server)? Zudem musst Du nennen, welche Nutzer dabei handeln, wird dazu ein Domänennutzer verwendet?
Die Vorstellung "Mitarbeiter fällt auf eine Mail rein und kurz danach wird das Backup angreifbar" ist sehr weit hergeholt - dazwischen muss sehr viel passieren, was Nachlässigkeit der Admins voraussetzt. Den Server aus der Domäne zu nehmen macht oft mehr Probleme, als dass es Sicherheiten schafft.
Beispiel: Nutzerrechner ist infiziert, Angreifer steuert ihn und hat Adminrechte erlangt. Er kann nun alles zerstören, was beschreibbar ist von:
allen Nutzern, die sich an dem Client anmelden
dem, was das Systemkonto des PCs löschen kann
Das darf nicht viel sein. Wenn er damit alle Backups der Firma beschreiben kann, dann muss er ja zuvor in Besitz eines mächtigen Kontos gekommen sein, was per se niemals auf einem Client eingesetzt werden darf und somit ist dieses Szenario einzig und allein möglich, wenn der Admin schon zuvor die einfachsten Tiering-Grundsätze nicht beherzigt hat.
Die Vorstellung "Mitarbeiter fällt auf eine Mail rein und kurz danach wird das Backup angreifbar" ist sehr weit hergeholt - dazwischen muss sehr viel passieren, was Nachlässigkeit der Admins voraussetzt. Den Server aus der Domäne zu nehmen macht oft mehr Probleme, als dass es Sicherheiten schafft.
Beispiel: Nutzerrechner ist infiziert, Angreifer steuert ihn und hat Adminrechte erlangt. Er kann nun alles zerstören, was beschreibbar ist von:
allen Nutzern, die sich an dem Client anmelden
dem, was das Systemkonto des PCs löschen kann
Das darf nicht viel sein. Wenn er damit alle Backups der Firma beschreiben kann, dann muss er ja zuvor in Besitz eines mächtigen Kontos gekommen sein, was per se niemals auf einem Client eingesetzt werden darf und somit ist dieses Szenario einzig und allein möglich, wenn der Admin schon zuvor die einfachsten Tiering-Grundsätze nicht beherzigt hat.
Ich hab hier dieselbe Konstellation.
Veeam B&R 12 ist auf einem W2k22 außerhalb der Domäne.
Da werden die VMs weggesichert, da brauchts keinen Zugang zur Domäne.
Ich hab da aber RDP deaktiviert. Zugriff erfolgt ausschließlich über das vCenter.
Da jetzt noch ein MFA wär mir zuviel. Man ist zwar nicht oft drauf auf der Maschine, aber mir ist erst später aufgefallen, dass da ein ^vor einem Vokal im Passwort generiert wurde. Das ist immer nervig einzutippen. Und jedesmal nehm ich mir vor, das Passwort zu ändern, lass es aber dann doch, weil braucht man ja nicht oft.
Veeam B&R 12 ist auf einem W2k22 außerhalb der Domäne.
Da werden die VMs weggesichert, da brauchts keinen Zugang zur Domäne.
Ich hab da aber RDP deaktiviert. Zugriff erfolgt ausschließlich über das vCenter.
Da jetzt noch ein MFA wär mir zuviel. Man ist zwar nicht oft drauf auf der Maschine, aber mir ist erst später aufgefallen, dass da ein ^vor einem Vokal im Passwort generiert wurde. Das ist immer nervig einzutippen. Und jedesmal nehm ich mir vor, das Passwort zu ändern, lass es aber dann doch, weil braucht man ja nicht oft.
Zitat von @beck2oldschool:
Und das finde ich Unsinn. Welcher Komfort geht denn flöten? Durch Eingabe einer 6 stelligen Zahl nach einem Windows Passwort? Und nur der Schwenk auf Unix Derivat bringt auch Null,Null mehr an Sicherheit.
Zitat von @godlie:
Viel Aufwand für wenig mehr an Sicherheit, Komfort geht flöten .... Setz als Backup Server eine Linux / BSD Maschine ein, gewinnste mehr .....
Viel Aufwand für wenig mehr an Sicherheit, Komfort geht flöten .... Setz als Backup Server eine Linux / BSD Maschine ein, gewinnste mehr .....
Und das finde ich Unsinn. Welcher Komfort geht denn flöten? Durch Eingabe einer 6 stelligen Zahl nach einem Windows Passwort? Und nur der Schwenk auf Unix Derivat bringt auch Null,Null mehr an Sicherheit.
Mhm sagte der KlickuBunitAdmin
Hi!
Veeam hat schon die Funktionalität (MFA)
Funktioniert ebenfalls mit lokalen accounts... da brauchst du kein AD
https://helpcenter.veeam.com/docs/backup/vsphere/mfa.html?ver=120
Veeam hat schon die Funktionalität (MFA)
Funktioniert ebenfalls mit lokalen accounts... da brauchst du kein AD
https://helpcenter.veeam.com/docs/backup/vsphere/mfa.html?ver=120
Wieder mal was Neues.
Setzt zwar quasi eine Ebene später an, würde aber IMHO komplett ausreichen.
Setzt zwar quasi eine Ebene später an, würde aber IMHO komplett ausreichen.
Moin, Duo sollte das können., hat auch eine offline funktion.
was hier bestimmte user von sich geben wird ja langsam echt lächerlich. Natürlich ist es best-practice den Veeam B&R Server nicht in der Domäne zu haben. Und nur weil man nen Unix-Betriebssystem irgendwo einsetzt wirds nicht automatisch sicherer, vor allem geht es nicht mit Veeam. Und weit hergeholt ist es nicht das ein Angreifer versuchen wird sich domain-admin rechte zu beschaffen und die backups zu manipulieren.
Aber ist schon klar wenn statt mit sachlichen argumenten mit klickubunti und "Windof" angefangen wird ( und sogar noch bewusst der Filter für die Begriffe umgangen wird)
was hier bestimmte user von sich geben wird ja langsam echt lächerlich. Natürlich ist es best-practice den Veeam B&R Server nicht in der Domäne zu haben. Und nur weil man nen Unix-Betriebssystem irgendwo einsetzt wirds nicht automatisch sicherer, vor allem geht es nicht mit Veeam. Und weit hergeholt ist es nicht das ein Angreifer versuchen wird sich domain-admin rechte zu beschaffen und die backups zu manipulieren.
Aber ist schon klar wenn statt mit sachlichen argumenten mit klickubunti und "Windof" angefangen wird ( und sogar noch bewusst der Filter für die Begriffe umgangen wird)
Zitat von @kpunkt:
Wieder mal was Neues.
Setzt zwar quasi eine Ebene später an, würde aber IMHO komplett ausreichen.
Wieder mal was Neues.
Setzt zwar quasi eine Ebene später an, würde aber IMHO komplett ausreichen.
Sicher?
Der Böhse Bube meldet sich am Windows an und löscht dir dein Backup-Repository auf File-Ebene…
Aber auch da bin ich bei @DerWoWusste
Bis da hin gab es schon viele Löcher..
Warum meldet ihr euch eigentlich mit Admin-Rechten an Windows an? Normaler User reicht. Innerhalb von VEEAM bekommt der User dann passende Rollen.
Und wenn die Kiste mal administriert werden muss, holt man sich den Zugabg aus Keepass/ dem Zettel im Safe…
Zitat von @godlie:
Viel Aufwand für wenig mehr an Sicherheit, Komfort geht flöten .... Setz als Backup Server eine Linux / BSD Maschine ein, gewinnste mehr .....
Genau mein Humor Viel Aufwand für wenig mehr an Sicherheit, Komfort geht flöten .... Setz als Backup Server eine Linux / BSD Maschine ein, gewinnste mehr .....
https://www.heise.de/news/Perfectl-Linux-Malware-laesst-Server-heimlich- ...
Backupserver, egal welches OS, hat im „Normalen“ Netzwerk nichts verloren. Erst recht nicht im Internet. Updates kann man alle offline bereitstellen
Guten Morgen,
wir haben unseren Veeam Backup-Server nicht im AD, RDP ist nur von der administrativen Workstation möglich und es werden lokale Benutzer verwendet. In Veeam selbst haben wir MFA aktiviert, die Veeam-Console ist auf der Admin-Workstation installiert, so dass der RDP-Zugriff lediglich zu Wartungszwecken (Updates, etc.) notwendig ist.
Der einzige Angriffsvektor wäre RDP über die Admin-Workstation, dort könnte der Zugriff auf das lokale Backuprepository erfolgen, jedoch ist ein Tape-Backup sowie ein hardened Repository vorhanden.
wir haben unseren Veeam Backup-Server nicht im AD, RDP ist nur von der administrativen Workstation möglich und es werden lokale Benutzer verwendet. In Veeam selbst haben wir MFA aktiviert, die Veeam-Console ist auf der Admin-Workstation installiert, so dass der RDP-Zugriff lediglich zu Wartungszwecken (Updates, etc.) notwendig ist.
Der einzige Angriffsvektor wäre RDP über die Admin-Workstation, dort könnte der Zugriff auf das lokale Backuprepository erfolgen, jedoch ist ein Tape-Backup sowie ein hardened Repository vorhanden.
Zitat von @em-pie:
Sicher?
Der Böhse Bube meldet sich am Windows an und löscht dir dein Backup-Repository auf File-Ebene…
Zitat von @kpunkt:
Wieder mal was Neues.
Setzt zwar quasi eine Ebene später an, würde aber IMHO komplett ausreichen.
Wieder mal was Neues.
Setzt zwar quasi eine Ebene später an, würde aber IMHO komplett ausreichen.
Sicher?
Der Böhse Bube meldet sich am Windows an und löscht dir dein Backup-Repository auf File-Ebene…
Backup-Repository ist in unserem Design nicht die selbe VM. (Kein Windows) + Backup-Copy Job (Immutable Storage). Um Jobs, Repositories etc. zu managen benötigt man dann entsprechend (Veeam)MFA
Ich persönlich würde die Funktionalität des Veeam MFA auf jeden Fall konfigurieren..
Nutzen wir auch, liegt natürlich an einem anderen Standort. Wenn dann das RZ abraucht und gleichzeitig das Speichersystem mit dem Immutable Backup am anderen Standort geklaut wird ... wäre wie ein Jackpot im Lotto.
Noch einer zum Testen. Kann viel: https://www.win-logon.com/elevate-windows-login-security-with-totp-authe ...
Zitat von @beck2oldschool:
Danke schonmal für eure Antworten!
Ich gehe von einem Windows Server 2022 aus. Anmeldung per RDP, da der Server in einem verschlossenen Raum und Schrank steht. Da der dahinterliegende User aber unabhängig von Login Verfahren ist, also Konsole oder Remote, hab ich das mal außer Acht gelassen.
Also der Gedanke ist folgender. Ich gehe von einem Ransomware Angriff aus. Ein Angreifer schafft es irgendwie in mein Netz, durch Klick eines Users auf einen Link, Email Anhang, was auch immer. Das erste, was ich als Hacker/Erpresser tun würde wenn ich "drin bin" wäre, zu versuchen das Backup zu zerstören. Aus dem Grund ist mein Backup Server nicht an das AD gebunden, sondern hat eben lokale Admins mit komplexem Passwort. Das ist meines Wissens nach eine Empfehlung von Veeam. Ich finde das nur gerade nicht auf die Schnelle.
Nun möchte ich eben genau diesen Admin User zusätzlich noch mit einem zweiten Faktor absichern. Sollte also irgendwie (z.B. Keylogger o.ä.) das Kennwort dieses Admin in falsche Hände kommen, fehlt immer noch der zweite Faktor.
Ein Freund von mir hat in seinem Konstruktionsbüro aktuell einen Ransomware Befall. Und das erste was bei dem Angriff zerstört wurde, war eben das Backup. Deswegen möchte ich das so gut wie möglich absichern.
Yubico ist auf jedenfall schonmal ein guter Hinweis. Das hatte ich tatsächlich vor einigen Jahren mal getestet. Wir loggen uns aktuell sowieso mit FIDO2 Sticks an den PCs ein. Von daher wäre die Hardware nicht das Problem. Das kann ich nochmal angehen.
Rohos hab ich vorhin per Google gefunden.
Danke schonmal für eure Antworten!
Ich gehe von einem Windows Server 2022 aus. Anmeldung per RDP, da der Server in einem verschlossenen Raum und Schrank steht. Da der dahinterliegende User aber unabhängig von Login Verfahren ist, also Konsole oder Remote, hab ich das mal außer Acht gelassen.
Also der Gedanke ist folgender. Ich gehe von einem Ransomware Angriff aus. Ein Angreifer schafft es irgendwie in mein Netz, durch Klick eines Users auf einen Link, Email Anhang, was auch immer. Das erste, was ich als Hacker/Erpresser tun würde wenn ich "drin bin" wäre, zu versuchen das Backup zu zerstören. Aus dem Grund ist mein Backup Server nicht an das AD gebunden, sondern hat eben lokale Admins mit komplexem Passwort. Das ist meines Wissens nach eine Empfehlung von Veeam. Ich finde das nur gerade nicht auf die Schnelle.
Nun möchte ich eben genau diesen Admin User zusätzlich noch mit einem zweiten Faktor absichern. Sollte also irgendwie (z.B. Keylogger o.ä.) das Kennwort dieses Admin in falsche Hände kommen, fehlt immer noch der zweite Faktor.
Ein Freund von mir hat in seinem Konstruktionsbüro aktuell einen Ransomware Befall. Und das erste was bei dem Angriff zerstört wurde, war eben das Backup. Deswegen möchte ich das so gut wie möglich absichern.
Yubico ist auf jedenfall schonmal ein guter Hinweis. Das hatte ich tatsächlich vor einigen Jahren mal getestet. Wir loggen uns aktuell sowieso mit FIDO2 Sticks an den PCs ein. Von daher wäre die Hardware nicht das Problem. Das kann ich nochmal angehen.
Rohos hab ich vorhin per Google gefunden.
genau so erlebt, danach war der HV-Cluster eine eigene Domäne und der Backupserver nicht mehr Domainjoined, wir hatten den Kunden eine Woche vorher übernommen und gerade die Modernisierung geplant, ging dann schneller als gedacht 😂😂