Sicherer Umgang mit Supportkonten
Dies ist eine kompakte Anleitung zu folgendem Admin-Problem, hier gemünzt auf Windows:
User brauchen unseren Support und wir Supporter gebrauchen nicht selten globale administrative Konten, um diesen zu leisten.
Diese Konten sicher einzusetzen, ist bei genauer Betrachtung eine Herausforderung.
Jeder Admin, der es mit der Sicherheit ernst nimmt, fürchtet Angriffe auch durch eigene Kollegen.
Somit steht er beim Usersupport vor einem kleinen Dilemma: genau genommen ist jeder User-PC „Feindesland“.
Wie authentifizieren wir uns am PC des Users, ohne Gefahr zu laufen, dass der User unsere starken Konten kapert?
Nehmen wir Remoteunterstützung, Remotedesktop oder Teamviewer, setzen wir uns gemeinsam mit dem User davor, machen wir das erst nach Feierabend des Users…geben wir Kennwörter im Beisein des Users ein, mit UAC oder ohne, mittels runas, nutzen wir gar 2-Faktor-Authentifizierung? Nutzen wir lokale Admins, oder doch gleich den Domänenadmin oder erschaffen wir eine AD-Gruppe mit erweiterten Rechten? Und wie pflegen wir die Kennwörter? Listen schreiben, merken, alle gleich setzen? Oder lassen wir den User doch seine Probleme alleine lösen und geben ihm gleich lokale Adminrechte? ;)
Man findet verschiedene Empfehlungen dazu auch seitens Microsoft und doch möchte ich meinen eigenen Ansatz hier ausstellen und empfehlen. Er kommt ohne 2-Faktor-Authentifizierung und ohne weitere Software aus und ist robust. Ich setze ihn seit nunmehr einem Jahr ein.
Der Grundgedanke lautet: es ist unnötig, zum Support ein Konto zu nutzen, welches auf mehr Maschinen als dem Ziel-PC Adminrechte hat!
Man hätte davon keinen Gewinn, geht aber große Risiken ein (siehe Mimikatz und Co., Sicherheitsprobleme von Kerberos).
Der Grund, warum vielerorts Adminkonten benutzt werden, die an vielen/allen Clientrechnern Adminrechte haben, ist lediglich Bequemlichkeit.
Ich werde zeigen, dass dies auf andere Weise bequem und sicher zugleich geht.
Das Einsatz-Szenario: Nutzer braucht Support, das Problem wurde (ggf. über RemoteAssistance mit dem User zusammen) identifiziert, doch leider werden Adminrechte benötigt, um es zu beheben.
Die Admincredentials sollen ausdrücklich nicht in der Usersitzung eingegeben werden.
Von mir war beabsichtigt:
A Für maximale Sicherheit exklusiv ein eigenes Supportkonto mit Adminrechten pro PC zu haben
B mit diesem Konto Zugriff auf Domänenressourcen zu haben
C dieses Konto nur für die Zeit des Supportfalles zu aktivieren
D keine Kennwortlisten führen zu müssen (ja nicht einmal jemals ein Kennwort zu kennen oder eingeben zu müssen)
Und so wurde ein Schuh draus:
1 wir legen in der Domain automatisiert für jeden PC („PCxy“) ein deaktiviertes Benutzerkonto adminPCxy mit Zufallskennwort an, welches sich nirgendwo anmelden kann: logonworkstations:Fantasiename (hier:haiopai). Beispiel: Liste.txt mit PCs erstellen, dann auf dem DC
ausführen
2 Diese Konten kommen in eine eigene OU, auf die die eigenen (schwachen) Konten der Supportmitarbeiter volle Rechte delegiert bekommen (mittels delegation of control wizard)
3 Ein Domänenstartskript macht auf jedem PC das jeweils zugehörige Konto zum Mitglied der lokalen Admingruppe.
(einmal für englische Systeme, einmal für deutsche Systeme)
4 Wenn Supportbedarf Adminrechte erfordert, aktiviert der Supporter per (nachfolgendem) Skript dieses Konto, lässt das Skript ein neues Kennwort setzen und diese Credentials zugleich im Credential Manager seines eigenen Rechners ablegen und baut damit automatisch eine Remotedesktopverbindung zum PCxy auf. Ist man fertig, wird das Supportkonto wieder automatisch deaktiviert.
Das Skript selbst ist ebenfalls simpelster Batchcode, verfeinert mit einem Powershellskript (public domain) aus http://www.sans.org/windows-security/files/scripts.zip , welches Zufallskennwörter (anpassbare Länge, default: 15) generiert
genauer: scripts.zip\Day6-PowerShell\GenerateRandomPassword.ps1 *
Das Konto kann also völlig gefahrlos zur Hilfe via RDP eingesetzt werden. Wenn man die Batch durch anykey korrekt beendet, wird es sofort wieder deaktiviert. Zur Sicherheit läuft auf dem DC jedoch ein Task, welcher nach Feierabend alle Supportadmins deaktiviert.
* Ich habe dieses Skript minimal angepasst:
Zeile 65 auskommentiert:
Und dahinter eingefügt:
Das wär's. Sicherlich kann man dies weiter verfeinern, aber hier soll nur das Grundgerüst ausgestellt (und vielleicht diskutiert) werden.
User brauchen unseren Support und wir Supporter gebrauchen nicht selten globale administrative Konten, um diesen zu leisten.
Diese Konten sicher einzusetzen, ist bei genauer Betrachtung eine Herausforderung.
Jeder Admin, der es mit der Sicherheit ernst nimmt, fürchtet Angriffe auch durch eigene Kollegen.
Somit steht er beim Usersupport vor einem kleinen Dilemma: genau genommen ist jeder User-PC „Feindesland“.
Wie authentifizieren wir uns am PC des Users, ohne Gefahr zu laufen, dass der User unsere starken Konten kapert?
Nehmen wir Remoteunterstützung, Remotedesktop oder Teamviewer, setzen wir uns gemeinsam mit dem User davor, machen wir das erst nach Feierabend des Users…geben wir Kennwörter im Beisein des Users ein, mit UAC oder ohne, mittels runas, nutzen wir gar 2-Faktor-Authentifizierung? Nutzen wir lokale Admins, oder doch gleich den Domänenadmin oder erschaffen wir eine AD-Gruppe mit erweiterten Rechten? Und wie pflegen wir die Kennwörter? Listen schreiben, merken, alle gleich setzen? Oder lassen wir den User doch seine Probleme alleine lösen und geben ihm gleich lokale Adminrechte? ;)
Man findet verschiedene Empfehlungen dazu auch seitens Microsoft und doch möchte ich meinen eigenen Ansatz hier ausstellen und empfehlen. Er kommt ohne 2-Faktor-Authentifizierung und ohne weitere Software aus und ist robust. Ich setze ihn seit nunmehr einem Jahr ein.
Der Grundgedanke lautet: es ist unnötig, zum Support ein Konto zu nutzen, welches auf mehr Maschinen als dem Ziel-PC Adminrechte hat!
Man hätte davon keinen Gewinn, geht aber große Risiken ein (siehe Mimikatz und Co., Sicherheitsprobleme von Kerberos).
Der Grund, warum vielerorts Adminkonten benutzt werden, die an vielen/allen Clientrechnern Adminrechte haben, ist lediglich Bequemlichkeit.
Ich werde zeigen, dass dies auf andere Weise bequem und sicher zugleich geht.
Das Einsatz-Szenario: Nutzer braucht Support, das Problem wurde (ggf. über RemoteAssistance mit dem User zusammen) identifiziert, doch leider werden Adminrechte benötigt, um es zu beheben.
Die Admincredentials sollen ausdrücklich nicht in der Usersitzung eingegeben werden.
Von mir war beabsichtigt:
A Für maximale Sicherheit exklusiv ein eigenes Supportkonto mit Adminrechten pro PC zu haben
B mit diesem Konto Zugriff auf Domänenressourcen zu haben
C dieses Konto nur für die Zeit des Supportfalles zu aktivieren
D keine Kennwortlisten führen zu müssen (ja nicht einmal jemals ein Kennwort zu kennen oder eingeben zu müssen)
Und so wurde ein Schuh draus:
1 wir legen in der Domain automatisiert für jeden PC („PCxy“) ein deaktiviertes Benutzerkonto adminPCxy mit Zufallskennwort an, welches sich nirgendwo anmelden kann: logonworkstations:Fantasiename (hier:haiopai). Beispiel: Liste.txt mit PCs erstellen, dann auf dem DC
for /f %a in (liste.txt) do net user /add admin%a /random /active:no /WORKSTATIONS:haiopai
2 Diese Konten kommen in eine eigene OU, auf die die eigenen (schwachen) Konten der Supportmitarbeiter volle Rechte delegiert bekommen (mittels delegation of control wizard)
3 Ein Domänenstartskript macht auf jedem PC das jeweils zugehörige Konto zum Mitglied der lokalen Admingruppe.
net localgroup /add administrators admin%computername%
net localgroup /add administratoren admin%computername%
4 Wenn Supportbedarf Adminrechte erfordert, aktiviert der Supporter per (nachfolgendem) Skript dieses Konto, lässt das Skript ein neues Kennwort setzen und diese Credentials zugleich im Credential Manager seines eigenen Rechners ablegen und baut damit automatisch eine Remotedesktopverbindung zum PCxy auf. Ist man fertig, wird das Supportkonto wieder automatisch deaktiviert.
Das Skript selbst ist ebenfalls simpelster Batchcode, verfeinert mit einem Powershellskript (public domain) aus http://www.sans.org/windows-security/files/scripts.zip , welches Zufallskennwörter (anpassbare Länge, default: 15) generiert
genauer: scripts.zip\Day6-PowerShell\GenerateRandomPassword.ps1 *
@echo off
set /p target=Auf welchen PC willst Du?: %=%
for /f %%a in ('powershell \\server\share\GenerateRandomPassword.ps1') do net user admin%target% %%a /domain /active /workstations:%computername%,%target% & cmdkey /add:TERMSRV/%target% /user:netbiosdomainname\admin%target% /pass:%%a
start mstsc /v:%target%
pause
net user admin%target% /active:no /domain
Das Konto kann also völlig gefahrlos zur Hilfe via RDP eingesetzt werden. Wenn man die Batch durch anykey korrekt beendet, wird es sofort wieder deaktiviert. Zur Sicherheit läuft auf dem DC jedoch ein Task, welcher nach Feierabend alle Supportadmins deaktiviert.
* Ich habe dieses Skript minimal angepasst:
Zeile 65 auskommentiert:
#1..20 | foreach { Generate-RandomPassword -length $length } ; "`n"
1 | foreach { Generate-RandomPassword -length $length } ; "`n"
Das wär's. Sicherlich kann man dies weiter verfeinern, aber hier soll nur das Grundgerüst ausgestellt (und vielleicht diskutiert) werden.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 262066
Url: https://administrator.de/contentid/262066
Ausgedruckt am: 21.11.2024 um 14:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo
@DerWoWusste !
danke fuer die Anleitung
Sie gefaellt mir sehr gut und ich hab mal unserem Abteilungsleiter-Winbloedmausschubser den Link geschickt.
@herbrich
Meiner Meinung nach findet man diese Info doch in den Security Eventlogs ?
per powershell z.B get-eventlog -newest 10 -logname security | Format-List
aber da gibt es bestimmt noch bessere Ideen.
Gruss
@DerWoWusste !
danke fuer die Anleitung
Sie gefaellt mir sehr gut und ich hab mal unserem Abteilungsleiter-Winbloedmausschubser den Link geschickt.
@herbrich
Vlt noch ein Sicerheitslog wo drinnen steht welcher support user zur welcher zeit admin zugrif auf welchen rechner hatte.
Meiner Meinung nach findet man diese Info doch in den Security Eventlogs ?
per powershell z.B get-eventlog -newest 10 -logname security | Format-List
aber da gibt es bestimmt noch bessere Ideen.
Gruss
Tach@DerWoWusste,
echt geil... echt gut beschrieben...
du hast mir den tag heute gerettet, da ich nicht wusste was ich heute mit einem praktikanten machen sollte -
fiel mir dein artikel ein- ok... mit den worten " du arbeitest das jetzt mal ab- und heute nachmittag sehe ich mir das an"
habe ich fluchtartig das labor verlassen...
mittlerweile bin ich zurück, und zufrieden- klappt alles - kein lab server geschrottet, kein ap geschrottet...
Lg
V
echt geil... echt gut beschrieben...
du hast mir den tag heute gerettet, da ich nicht wusste was ich heute mit einem praktikanten machen sollte -
fiel mir dein artikel ein- ok... mit den worten " du arbeitest das jetzt mal ab- und heute nachmittag sehe ich mir das an"
habe ich fluchtartig das labor verlassen...
mittlerweile bin ich zurück, und zufrieden- klappt alles - kein lab server geschrottet, kein ap geschrottet...
Lg
V
Zitat von @Alchimedes:
danke fuer die Anleitung
Sie gefaellt mir sehr gut und ich hab mal unserem Abteilungsleiter-Winbloedmausschubser den Link geschickt.
danke fuer die Anleitung
Sie gefaellt mir sehr gut und ich hab mal unserem Abteilungsleiter-Winbloedmausschubser den Link geschickt.
@Alchimedes: Na dann hoffen wir das er nicht deinen Kommentar mit deiner Email verbindet und ein gutes Wort beim Chef einlegt ;)
Zitat von @DerWoWusste:
@echo off
> set /p target=Auf welchen PC willst Du?: %=%
> for /f %%a in ('powershell \\server\share\GenerateRandomPassword.ps1') do net user admin%target% %%a /domain /active /workstations:%computername%,%target% & cmdkey /add:TERMSRV/%target% /user:netbiosdomainname\admin%target% /pass:%%a
> start mstsc /v:%target%
> pause
> net user admin%target% /active:no /domain
Danke für diese Anleitung, man könnte noch die Zeile 4 und 5 mittels "start /wait mstsc /v:%target%" etwas mehr automatisieren. Dadurch pausiert das Skript dort automatisch, bis mstsc geschlossen wurde (Entspricht einem "-Wait" in PowerShell).