Passwort zurücksetzen im Zusammenhang mit Support
Hallo zusammen
Wir möchten gerne unsere Passwort-Politik umstellen und stolpern dabei über ein paar organisatorische Knacknüsse.
Da würde mich interessieren, was ihr dazu denkt oder wie ihr das handhabt.
Situation:
Wir müssen uns hin und wieder zu Supportzwecken mit einem Benutzer ins Citrix einloggen, in dessen Abwesenheit.
Vor allem beim halbjährlichen Abteilungswechsel der Lehrlinge oder halt einfach, um in Ruhe ein Problem zu analysieren.
Aktuell haben wir eine kennwortgeschützte Excel-Datei mit allen Benutzer-Kennwörtern drin.
Die Kennwörter laufen nie ab, und die User können sie auch nicht ändern.
Das ist die aktuelle Politik: einmal ein sicheres Passwort setzen, dafür nicht alle 2 Monate ändern müssen.
Soll-Zustand:
durch die Revision haben wir die Empfehlung erhalten, dass wir - zu unserem Selbstschutz - diese Liste aufgeben sollten. Absolut verständlich!
Nur bringt das z.B. folgendes Problem mit sich:
wenn wir uns als ein Benutzer einloggen wollen, müssten wir immer sein Passwort zurücksetzen.
Selbst wenn wir den Haken "Muss das Passwort bei der nächsten Anmeldung ändern" setzen ist das witzlos, weil der User das von uns temporär gesetzte Kennwort ja nicht weiss.
Ich habe über Google schon die Möglichkeit von so Self-Service Portalen gefunden, kommt bei uns aber nicht in Frage (die Leute wären schlicht überfordert...).
Wie können wir das lösen?
Bin sehr gespannt auf eure Kommentare
Herzliche Grüsse
Tom
Wir möchten gerne unsere Passwort-Politik umstellen und stolpern dabei über ein paar organisatorische Knacknüsse.
Da würde mich interessieren, was ihr dazu denkt oder wie ihr das handhabt.
Situation:
Wir müssen uns hin und wieder zu Supportzwecken mit einem Benutzer ins Citrix einloggen, in dessen Abwesenheit.
Vor allem beim halbjährlichen Abteilungswechsel der Lehrlinge oder halt einfach, um in Ruhe ein Problem zu analysieren.
Aktuell haben wir eine kennwortgeschützte Excel-Datei mit allen Benutzer-Kennwörtern drin.
Die Kennwörter laufen nie ab, und die User können sie auch nicht ändern.
Das ist die aktuelle Politik: einmal ein sicheres Passwort setzen, dafür nicht alle 2 Monate ändern müssen.
Soll-Zustand:
durch die Revision haben wir die Empfehlung erhalten, dass wir - zu unserem Selbstschutz - diese Liste aufgeben sollten. Absolut verständlich!
Nur bringt das z.B. folgendes Problem mit sich:
wenn wir uns als ein Benutzer einloggen wollen, müssten wir immer sein Passwort zurücksetzen.
Selbst wenn wir den Haken "Muss das Passwort bei der nächsten Anmeldung ändern" setzen ist das witzlos, weil der User das von uns temporär gesetzte Kennwort ja nicht weiss.
Ich habe über Google schon die Möglichkeit von so Self-Service Portalen gefunden, kommt bei uns aber nicht in Frage (die Leute wären schlicht überfordert...).
Wie können wir das lösen?
Bin sehr gespannt auf eure Kommentare
Herzliche Grüsse
Tom
Please also mark the comments that contributed to the solution of the article
Content-Key: 290868
Url: https://administrator.de/contentid/290868
Printed on: April 27, 2024 at 00:04 o'clock
17 Comments
Latest comment
Hi.
Ich hätte da zwein interessante Ansätze für Dich:
Das eine wäre eine zusätzliche Software, die es Supportkonten erlaubt, gesperrte Nutzersitzungen zu entsperren: http://www.e-motional.com/ULAdmin.htm
zum Zweiten: Du könntest über Autounlock in Verbindung mit einer Festplattenverschlüsselung (z.B. BItlocker) nachdenken. Und zwar so: Nutzer gibt sein Bitlockerkennwort ein, Rechner fährt hoch und meldet sich automatisch an. Bei Sperrung des PCs muss der Nutzer natürlich sein Kennwort eingeben.
Kommt nun der Admin, kommt er an BItlocker mit seinem eigenen Schlüssel vorbei und dank Autologon kommt er in die Nutzersitzung.
Darüber sollte man Nutzer natürlich informieren. Dass Admins immer und zu jeder Zeit im Namen des Nutzer handeln könnten und somit das von der Revision Geforderte eigentlich lächerlich ist, sollte auch klar sein (nur um den Schutz dieser Kennwort-Datei würde ich mir Sorgen machen).
Ich hätte da zwein interessante Ansätze für Dich:
Das eine wäre eine zusätzliche Software, die es Supportkonten erlaubt, gesperrte Nutzersitzungen zu entsperren: http://www.e-motional.com/ULAdmin.htm
zum Zweiten: Du könntest über Autounlock in Verbindung mit einer Festplattenverschlüsselung (z.B. BItlocker) nachdenken. Und zwar so: Nutzer gibt sein Bitlockerkennwort ein, Rechner fährt hoch und meldet sich automatisch an. Bei Sperrung des PCs muss der Nutzer natürlich sein Kennwort eingeben.
Kommt nun der Admin, kommt er an BItlocker mit seinem eigenen Schlüssel vorbei und dank Autologon kommt er in die Nutzersitzung.
Darüber sollte man Nutzer natürlich informieren. Dass Admins immer und zu jeder Zeit im Namen des Nutzer handeln könnten und somit das von der Revision Geforderte eigentlich lächerlich ist, sollte auch klar sein (nur um den Schutz dieser Kennwort-Datei würde ich mir Sorgen machen).
Nee, das kommt da natürlich nicht in Frage
Ok, dann bleibt Dir:
-Kennwort ändern und auf ein vorher mit dem Mitarbeiter vereinbartes zurücksetzen (man kann dies auch vor dem Supportbedarf vereinbaren)
-Einen zweiten Logonfaktor einführen (2FA, z.B. Rohos), den dann der Admin bekommt
-das bisherige Vorgehen rechtfertigen, auch im Lichte des Aufwandes, welchen wir gerade festgestellt haben
Ok, dann bleibt Dir:
-Kennwort ändern und auf ein vorher mit dem Mitarbeiter vereinbartes zurücksetzen (man kann dies auch vor dem Supportbedarf vereinbaren)
-Einen zweiten Logonfaktor einführen (2FA, z.B. Rohos), den dann der Admin bekommt
-das bisherige Vorgehen rechtfertigen, auch im Lichte des Aufwandes, welchen wir gerade festgestellt haben
Hallo!
Bei uns wird Variante 1 angewandt. - Ist vom Aufwand/Nutzen am einfachsten.
Der User (und nur dieser betreffende User) bekommt vorher eine Info, dass wir wider erwarten etwas arbeiten wollen
Wir verwenden allerdings ein Standardkennwort. Beim nächsten Login weis der User, dass er mit dem Standardkennwort arbeiten muss. Eine Kennwortänderung wird danach automatisch verlangt.
Gruß
Eisbein
Bei uns wird Variante 1 angewandt. - Ist vom Aufwand/Nutzen am einfachsten.
Der User (und nur dieser betreffende User) bekommt vorher eine Info, dass wir wider erwarten etwas arbeiten wollen
Wir verwenden allerdings ein Standardkennwort. Beim nächsten Login weis der User, dass er mit dem Standardkennwort arbeiten muss. Eine Kennwortänderung wird danach automatisch verlangt.
Gruß
Eisbein
Hi,
man kann den aktuellen NTHash des Accounts auch mit folgendem Powershell-Module auslesen, dann Passwort ändern und hinterher den alten NTHash wieder mit Set-SamAccountPasswordHash zurückschreiben, quick but dirty .
https://www.dsinternals.com/en/list-of-cmdlets-in-the-dsinternals-module ...
Gruß jodel32
man kann den aktuellen NTHash des Accounts auch mit folgendem Powershell-Module auslesen, dann Passwort ändern und hinterher den alten NTHash wieder mit Set-SamAccountPasswordHash zurückschreiben, quick but dirty .
https://www.dsinternals.com/en/list-of-cmdlets-in-the-dsinternals-module ...
Gruß jodel32
Moin zusammen,
Ergänzend zu Jodel's Tipp hier noch der nötige Befehl um Live einen Snapshot der NTDS.dit und das SYSTEM-Hive zu erstellen, was für das Extrahieren der Hashes mit dem PS-Module nötig ist, will man keine Offline Kopie oder Backup hernehmen, denn die Live-Daten lassen sich mit den PS-Module nicht verwenden da sie ja aktuell in Verwendung sind.
Macht einen Snapshot der NTDS.dit und dem SYSTEM Hive nach C:\ntds_backup.
Grüße Uwe
Zitat von @114757:
man kann den aktuellen NTHash des Accounts auch mit folgendem Powershell-Module auslesen, dann Passwort ändern und hinterher den alten NTHash wieder mit Set-SamAccountPasswordHash zurückschreiben, quick but dirty .
https://www.dsinternals.com/en/list-of-cmdlets-in-the-dsinternals-module ...
man kann den aktuellen NTHash des Accounts auch mit folgendem Powershell-Module auslesen, dann Passwort ändern und hinterher den alten NTHash wieder mit Set-SamAccountPasswordHash zurückschreiben, quick but dirty .
https://www.dsinternals.com/en/list-of-cmdlets-in-the-dsinternals-module ...
Ergänzend zu Jodel's Tipp hier noch der nötige Befehl um Live einen Snapshot der NTDS.dit und das SYSTEM-Hive zu erstellen, was für das Extrahieren der Hashes mit dem PS-Module nötig ist, will man keine Offline Kopie oder Backup hernehmen, denn die Live-Daten lassen sich mit den PS-Module nicht verwenden da sie ja aktuell in Verwendung sind.
ntdsutil "activate instance ntds" ifm "create full C:\ntds_backup" quit quit
Grüße Uwe
Moin,
Meine Methode ist, den Benutzer anzuweisen, ein bestimmtes Paßwort zu setzen, das natürlich variiert, damit andere User nicht die Situation ausnutzen können.Nach Durchführung der Arbeiten wird einfach eingestellt, daß der benutzer sein Paßwort bein nächsten login ändern mußt. Da kann er wieder das vorhergehende oder ein anderes wählen.
lks
Meine Methode ist, den Benutzer anzuweisen, ein bestimmtes Paßwort zu setzen, das natürlich variiert, damit andere User nicht die Situation ausnutzen können.Nach Durchführung der Arbeiten wird einfach eingestellt, daß der benutzer sein Paßwort bein nächsten login ändern mußt. Da kann er wieder das vorhergehende oder ein anderes wählen.
lks
mit Get-ADDBAccount
https://www.dsinternals.com/en/dumping-ntds-dit-files-using-powershell/
habe mal ein Skript gebastelt das euch alles abnimmt, inkl Erstellen des Snapshots der AD-DB und SYSTEM Hive wie oben geschrieben (installiertes PS Module DSInternals vorrausgesetzt):
Zum holen des Hashes:
ausführen. Dann wird der Hash in einer Textdatei im Aufrufverzeichnis gespeichert.
Zum Restoren des Hashes aus der Textdatei danach im selben Verzeichnis folgendes ausführen
https://www.dsinternals.com/en/dumping-ntds-dit-files-using-powershell/
habe mal ein Skript gebastelt das euch alles abnimmt, inkl Erstellen des Snapshots der AD-DB und SYSTEM Hive wie oben geschrieben (installiertes PS Module DSInternals vorrausgesetzt):
param(
[Parameter(mandatory=$true)][string]$SamAccountName,
[Parameter(mandatory=$true)][ValidateSet('Save','Restore')]$action
)
begin{
# Download here: https://www.dsinternals.com/en/list-of-cmdlets-in-the-dsinternals-module/
Import-Module DSInternals
$hashpath = '.\nthash.txt'
$snapshot = "$($env:TEMP)\ntds_backup"
}
process{
switch($action){
'Save' {
if(Test-Path $snapshot){remove-item $snapshot -Recurse -Force | out-null}
ntdsutil "activate instance ntds" ifm "create full $snapshot" quit quit | out-null
(Get-ADDBAccount -SamAccountName $SamAccountName -DBPath "$snapshot\Active Directory\ntds.dit" -BootKey (Get-BootKey -SystemHiveFilePath "$snapshot\registry\SYSTEM") -EA Stop | select -Expand NTHash | %{$_.toString('X').toLower().padLeft(2,"0")}) -join '' | out-file $hashpath
write-host "Hash saved to '$hashpath'" -Fore Green
}
'Restore' {
if(Test-Path $hashpath){
Set-SamAccountPasswordHash -SamAccountName $SamAccountName -NTHash (gc $hashpath) -Domain (Get-ADDomain).NetbiosName -EA Stop
write-host "Hash restored from '$hashpath'" -Fore Green
remove-item $hashpath -Force
}else{
write-host "Save the hash first with -action Save" -Fore Red
}
}
}
}
script.ps1 -SamAccountName MaxMuster -Action Save
Zum Restoren des Hashes aus der Textdatei danach im selben Verzeichnis folgendes ausführen
script.ps1 -SamAccountName MaxMuster -Action Restore
Ja, ich weiß, ich sollte meine eigentliche Arbeit weniger automatisieren , damit ich wieder mal mehr Arbeit hab, aber wozu gibt es so schöne Skriptsprachen, wenn sie einem mehr Zeit für die wichtigen Dinge im Leben geben .
Getestet, funktioniert.
Und weil's so schön ist: hier gleich noch eine Methode, die
A sehr einfach an den Hash kommt (ohne Powershellmodul-import und Konsorten)
B aufzeigt, wie (un-)sicher selbst die Cleartextpasswörter der Domäne vor dem Admin wirklich sind (falls es da noch Restzweifel geben sollte bei Euren Revisionisten).
C klar macht, was denn nun an der Option "umkehrbare Verschlüsselung ("reversible encryption") bei Kennwörtern eigentlich so schlimm ist
D nebenbei zeigt, dass das Privileg "Create msDS-PasswordSettings" (PSO-Erstellung) auf gar keinen Fall an Leute delegiert werden darf, die nicht eh Domänenadmins sind.
https://adsecurity.org/?p=2053
Und weil's so schön ist: hier gleich noch eine Methode, die
A sehr einfach an den Hash kommt (ohne Powershellmodul-import und Konsorten)
B aufzeigt, wie (un-)sicher selbst die Cleartextpasswörter der Domäne vor dem Admin wirklich sind (falls es da noch Restzweifel geben sollte bei Euren Revisionisten).
C klar macht, was denn nun an der Option "umkehrbare Verschlüsselung ("reversible encryption") bei Kennwörtern eigentlich so schlimm ist
D nebenbei zeigt, dass das Privileg "Create msDS-PasswordSettings" (PSO-Erstellung) auf gar keinen Fall an Leute delegiert werden darf, die nicht eh Domänenadmins sind.
https://adsecurity.org/?p=2053