thaefliger
Goto Top

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 face-smile


Herzliche Grüsse
Tom

Content-Key: 290868

Url: https://administrator.de/contentid/290868

Ausgedruckt am: 29.03.2024 um 05:03 Uhr

Mitglied: DerWoWusste
DerWoWusste 14.12.2015 aktualisiert um 21:00:06 Uhr
Goto Top
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).
Mitglied: thaefliger
thaefliger 14.12.2015 um 11:25:19 Uhr
Goto Top
Hi

es geht nicht zwingend um gesperrte Nutzersitzungen, sondern um komplett abgemeldete User als die wir uns einloggen müssen.
Bei den gesperrten schaue ich einfach im AppCenter wann sie wieder am arbeiten sind (Leerlaufzeit).

Bitlocker kommt wohl auch eher nicht in Frage in einer Terminalserver-Umgebung?
Mitglied: DerWoWusste
Lösung DerWoWusste 14.12.2015 aktualisiert um 17:47:28 Uhr
Goto Top
Nee, das kommt da natürlich nicht in Frage face-smile
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
Mitglied: thaefliger
thaefliger 14.12.2015 um 11:51:11 Uhr
Goto Top
Ja das wird wirklich ein Abwägen zwischen Aufwand und Nutzen...

entweder Variante 1 oder Variante 3 wie von dir vorgeschlagen.


Vielen Dank dir!
Mitglied: eisbein
eisbein 14.12.2015 um 12:03:26 Uhr
Goto Top
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 face-wink
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
Mitglied: thaefliger
thaefliger 14.12.2015 um 12:07:00 Uhr
Goto Top
Hallo @eisbein

unsere Überlegungen gehen auch in diese Richtung mit dem Standardpasswort.


Gruss
Tom
Mitglied: 114757
114757 14.12.2015 aktualisiert um 12:19:11 Uhr
Goto Top
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 face-wink.
https://www.dsinternals.com/en/list-of-cmdlets-in-the-dsinternals-module ...

Gruß jodel32
Mitglied: DerWoWusste
DerWoWusste 14.12.2015 um 12:48:50 Uhr
Goto Top
@114757
Ui. Cool!
Mitglied: colinardo
colinardo 14.12.2015 aktualisiert um 13:04:26 Uhr
Goto Top
Moin zusammen,
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 face-wink.
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  
Macht einen Snapshot der NTDS.dit und dem SYSTEM Hive nach C:\ntds_backup.

Grüße Uwe
Mitglied: Lochkartenstanzer
Lochkartenstanzer 14.12.2015 um 13:27:16 Uhr
Goto Top
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
Mitglied: thaefliger
thaefliger 14.12.2015 um 13:50:38 Uhr
Goto Top
Coole Idee @114757 face-smile was Powershell so alles kann :P
Mitglied: DerWoWusste
DerWoWusste 14.12.2015 um 14:26:15 Uhr
Goto Top
Und mit welchem Befehl extrahiert Ihr? Ich sehe nur set, aber nicht get.
Mitglied: colinardo
Lösung colinardo 14.12.2015 aktualisiert um 17:47:21 Uhr
Goto Top
Zitat von @DerWoWusste:
Und mit welchem Befehl extrahiert Ihr? Ich sehe nur set, aber nicht get.
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):
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  
		    }
	    }
    }
}
Zum holen des Hashes:
script.ps1 -SamAccountName MaxMuster -Action Save
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
script.ps1 -SamAccountName MaxMuster -Action Restore
Mitglied: DerWoWusste
DerWoWusste 14.12.2015 aktualisiert um 20:52:01 Uhr
Goto Top
Jou. Uwe mal wieder unterbeschäftigt gewesen face-wink
Mitglied: colinardo
colinardo 14.12.2015 aktualisiert um 16:17:55 Uhr
Goto Top
Zitat von @DerWoWusste:

Jou. Uwe mal wieder unterbeschäfigt gewesen face-wink
Ja, ich weiß, ich sollte meine eigentliche Arbeit weniger automatisieren face-big-smile, 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 face-wink.
Mitglied: DerWoWusste
DerWoWusste 14.12.2015 um 17:09:40 Uhr
Goto Top
mehr Zeit für die wichtigen Dinge
=noch mehr coden? face-wink
Mitglied: DerWoWusste
DerWoWusste 14.12.2015 aktualisiert um 20:42:14 Uhr
Goto Top
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 face-smile
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