Samba Passwort-Hash sichern und direkt setzen 2


Heterogene Netzwerke sind heutzutage eher selten anzutreffen. Meist laufen Server in Unternehmen mit Linux wohin Arbeitsplatzrechner mit Windows betrieben werden. Mittlerweile kann auch unter Linux mit der Software Samba ein vollwertiges Active Directory (AD) betrieben werden.

Häufig kommt es vor, das man sich als Administrator als normalen User auf einem Benutzer-Desktop für Wartungsarbeiten/Problembeseitigung anmelden muss. Meist sollen diese Arbeiten gemacht werden, wenn der Anwender nicht vor dem PC sitzt oder im Urlaub ist. Jetzt kennt man entweder das Benutzerpasswort oder man setzt eben ein neues Passwort und der Anwender muss bei der nächsten Anmeldung ein neues Passwort vergeben. Ersteres kommt in vielen Firmen leider häufiger vor als man denkt und der zweite Weg führt häufig zu Verwirrung und Anrufen im Helpdesk – gerade wenn die Authentifizierung mit anderen Diensten gekoppelt ist (Email, ownCloud, …)

Einfacher wäre es, wenn es so etwas wie su bzw. sudo für Windows gäbe. Vor diesem Hintergrund wünscht man sich die Möglichkeit,

  1. das Benutzerkennwort zu sichern
  2. ein „Techniker-Passwort“ zu setzen und nach getaner Arbeit
  3. das Benutzerkennwort wieder zurückzusetzen

Wird das AD mit Samba betrieben und hat man direkten Zugriff auf den Server lässt sich dies wirklich bewerkstelligen. Gerne würde man die Änderungen über das LDAP-Backend machen, aber Zugriff auf den Passwort-Hash: unicodePwd erhält man nur, wenn man direkt auf die SAM-Datenbank zugreift.

Passwort-Hash auslesen

Mit dem Tool ldbsearch (nicht zu verwechseln mit ldapsearch) greift man direkt auf die SAM-Datei zu. Folgender Befehl auf der root-Konsole zeigt den Passwort-Hash des Benutzers Test an:

Jetzt hat man schon mal den Hashwert des Benutzerpassworts und mehr braucht es auch nicht, denn genau dieser Hash muss nach getaner Arbeit wieder gesetzt werden, damit der Anwender sich wieder mit seinem alten Passwort anmelden kann – also gut aufbewahren.

Techniker-Passwort setzen

Das Techniker-Passwort kann man nun mit den normalen Tools, entweder unter Windows oder in der Linux-Konsole ändern:

Das Passwort für den Benutzer Test wurde damit auf ein bekanntest Passwort geändert. Jetzt kann man sich als dem Problem auf dem Arbeitsplatzrechner des Benutzer widmen. Nach getaner Arbeit gilt es nun den zuvor gesicherten Hash zurückzuschreiben.

Passwort-Hash zurückschreiben

Das Tool ldbmodify erlaubt es direkt die SAM-Datei zu modifizieren. Hierzu erstellt man eine entsprechende ldif-Datei und wendet diese auf die SAM-Datei an. Im Folgenden wird exemplarisch der Hashwert des Benutzer Test in der fiktiven AD meinedomain gesetzt:

Mit den ersten vier Zeilen wird festgelegt das für den Benutzer der Hash-Wert ersetzt werden soll. Wichtig ist der doppelte Doppelpunkt hinter unicodePwd, da dies anzeigt dass es sich um einen Base64-kodierten Wert handelt. Die letzte Zeile wendet die ldif-Datei auf die SAM-Datenbank an. Mit dem angegeben –controls Parameter erzwingt man, dass der Hash-Wert direkt gesetzt werden kann. Wird er nicht angegeben, so erhält man eine entsprechende Fehlermeldung, dass das Attribut nicht direkt geändert werden kann (Quelle). Es versteht sich von selbst, dass man bei dem direkten Modifizieren der SAM-Datenbank größte Vorsicht und Sorgfalt an den Tag legen sollte.


2 Gedanken zu “Samba Passwort-Hash sichern und direkt setzen

  • Christof Walter

    Danke für diese vielversprechende Anleitung. Mein Problem: ich kann zwar wie beschrieben neue Hashwerte in unicodePwd setzen (oder auch zurücksetzen), wie man mit ldbsearch nachvollziehen kann – aber dies ist wirkungslos für die Anmeldung am Client – trotz Cache-reset am Samba oder sogar Serverneustart. Es gilt nach wie vor das mit samba-tool gesetzte Passwort.
    Was mache ich falsch?

    • Stephan Lorsbach Autor des Beitrags

      Ich habe in unserer internen Dokumentation nochmal nachgeschlagen und in der Tat fehlte was. Es sind noch weitere controls-Parameter nötig, welche ich ergänzt habe – wie auch die ursprüngliche Quelle dieser Parameter.
      Bei einem Kunden hatten wir mal ein ähnliches Phänomen, dass Passwörter, wenn sie von „extern“ geändert wurden, erst nach Stunden aktiv waren. Problem war in diesem Fall die eingesetzte Antivirus/Firewall-Lösung. Diese boykottierte die Verbindung zum AD, so dass die von Windows gecachten Passwörter genutzt wurden.
      Wenn es mit den neuen Parametern nicht funktioniert, vielleicht ist es ja auch dann so etwas?

Kommentare sind geschlossen.