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

Printed on: April 25, 2024 at 10:04 o'clock

Member: DerWoWusste
DerWoWusste Dec 14, 2015 updated at 20:00:06 (UTC)
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).
Member: thaefliger
thaefliger Dec 14, 2015 at 10:25:19 (UTC)
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?
Member: DerWoWusste
Solution DerWoWusste Dec 14, 2015 updated at 16:47:28 (UTC)
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
Member: thaefliger
thaefliger Dec 14, 2015 at 10:51:11 (UTC)
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!
Member: eisbein
eisbein Dec 14, 2015 at 11:03:26 (UTC)
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
Member: thaefliger
thaefliger Dec 14, 2015 at 11:07:00 (UTC)
Goto Top
Hallo @eisbein

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


Gruss
Tom
Mitglied: 114757
114757 Dec 14, 2015 updated at 11:19:11 (UTC)
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
Member: DerWoWusste
DerWoWusste Dec 14, 2015 at 11:48:50 (UTC)
Goto Top
@114757
Ui. Cool!
Member: colinardo
colinardo Dec 14, 2015 updated at 12:04:26 (UTC)
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
Member: Lochkartenstanzer
Lochkartenstanzer Dec 14, 2015 at 12:27:16 (UTC)
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
Member: thaefliger
thaefliger Dec 14, 2015 at 12:50:38 (UTC)
Goto Top
Coole Idee @114757 face-smile was Powershell so alles kann :P
Member: DerWoWusste
DerWoWusste Dec 14, 2015 at 13:26:15 (UTC)
Goto Top
Und mit welchem Befehl extrahiert Ihr? Ich sehe nur set, aber nicht get.
Member: colinardo
Solution colinardo Dec 14, 2015 updated at 16:47:21 (UTC)
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
Member: DerWoWusste
DerWoWusste Dec 14, 2015 updated at 19:52:01 (UTC)
Goto Top
Jou. Uwe mal wieder unterbeschäftigt gewesen face-wink
Member: colinardo
colinardo Dec 14, 2015 updated at 15:17:55 (UTC)
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.
Member: DerWoWusste
DerWoWusste Dec 14, 2015 at 16:09:40 (UTC)
Goto Top
mehr Zeit für die wichtigen Dinge
=noch mehr coden? face-wink
Member: DerWoWusste
DerWoWusste Dec 14, 2015 updated at 19:42:14 (UTC)
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