[English]Kurzer Hinweis an Administratoren, die Installationen von Windows Server 2019 und Windows Server 2022 neu aufsetzen. Ein Blog-Leser hat mich auf einen Bug hingewiesen, der ihm beim Setup aufgefallen ist. Bei der Installation kann man ein Passwort für den Administrator vergeben, welches aber nicht gespeichert wird.
Anzeige
Leserbeobachtung zur Passwort-Speicherung
Blog-Leser Gregor O. ist im IT-Bereich einer Einrichtung tätig und hat mich die Tage per E-Mail über eine Beobachtung seines Teams im Zusammenhang mit der Installation von Windows Server 2019 bzw. Windows Server 2022 informiert. Es gibt wohl Probleme mit der Zuweisung eines Kennworts für das Administratorkonto bei der Installation. Er schreibt:
Ich bin ein fleißiger Leser von Ihren Blogeinträgen.
Ich wollte mich bei Ihnen Melden das uns bei Windows Server 2019 / 2022 ein „Bug" aufgefallen ist der ggf. mehrere Leser interessieren könnte:
Beim Installieren eines virtuellen Windows Server 2019 / 2022 wird bei der Installation ein Passwort für den Administrator verlangt, dieser wurde von uns auch hinterlegt. Das Systembestätigt auch dass dies übernommen wurde.
Wenn der Server fertig konfiguriert ist, und man sich per vSphere Client mit dem lokalen Administrationskonto anmelden will, muss man kein Kennwort hinterlegen. Man wird trotzdem mit dem Konto angemeldet.
Windows Server 2019 / 2022 speichert also bei der Installation das angegebene Passwort nicht ab und man ist lokaler Administrator auf der VM.
Die Aussage ist eindeutig: Ein beim Setup gesetztes Kennwort für den Administrator wird demnach nicht gespeichert. Man kann zwar im Nachgang das Passwort setzen, aber Gregor O. schreibt im Nachgang:
Hallo,
nachträglich geht es, fraglich ist jedoch, ob man dann noch daran denkt, wenn der Server bereits in einer Domäne aufgenommen ist, da braucht man eigentlich den lokalen Administrator nicht.
Wir haben auch noch folgendes herausgefunden:
Dieser „Bug" triff nicht bei allen Passwörtern zu, wenn man z.b. einen Server 2019 / 2022 mit dem initialen Kennwort #1Administrator2# installiert, wird das Kennwort verworfen, wenn man aber z.b. „12345678" als Kennwort nimmt, geht dies.
Ist das schon jemandem aufgefallen?
Nichts passendes im Web
Ich habe noch kurz im Internet bezüglich des Themas recherchiert – bin da auf die Schnelle aber nicht fündig geworden. Es gibt den Eintrag Windows server 2019 does not save passwords in applications bei Microsofts Q&A-Seite aus dem Februar 2021, der sich aber auf Anwendungen bezieht, wobei AD mit der Remote-App zum Einsatz kommt. Dort gibt es von einer Microsoft-Mitarbeiterin einige Tipps zum Überprüfen – aber der Fall passt nicht auf das obige Szenario eines lokalen Administrator-Konto.
Der Eintrag Cannot enter new credentials after fresh installation ist dagegen von 2017 und bezieht sich auf eine Insider Preview in einer virtuellen Maschine. Dort geht es um das Problem, dass sich die Eingaben nur mit einem Trick absenden lassen – das passt also auch nicht.
2015
LAPS installieren, dann ist immer ein PW da.
LAPS ist genial. Ich für Windows 10 Clients.
Was ich nur schade finde ist das es keine Historie über die sich automatisch geänderten Kennwörter gibt.
Könnte nützlich sein wenn man beispielsweise ein 1 Jahr altes Backup eines Servers wiederherstellen muss. Dann bringt einem das aktuell gültige Kennwort von LAPS für diesen Server auch nicht weiter. (Stichwort Vertrauensstellung zur Domäne wiederherstellen).
Ui, da wäre ich dabei. Damit hatte ich ebenso schon zu kämpfen nach einem Restore. Ansonsten ist LAPS genial.
Nannte sich "Laps Enterprise" (LAPS.E), darf er nicht mehr … jetzt ist es wieder unter dem alten Namen aus CodePLex Zeiten: AdmPwd.E … hoppla da ist ja auch wieder der Laps Dateiname :-)
https://www.admpwd.com/Admpwd
Jiri hat alles richtig gemacht. Das Tool for free entwickelt, dann abgetreten an MS, jeder möchte es und dann hat er die Enterprise Wünsche und Anfragen in ein eigenes Produkt gegossen.
Du kannst di automatisch per powershell Exportieren
Kann ich definitiv ausschließen, funktioniert hier ohne Probleme.
Könnte an der Buildversion der Iso liegen, meine aktuell funktionierenden sind von Juni 2021
SW_DVD9_Win_Server_STD_CORE_2019_1809.16_64Bit_English_DC_STD_MLF_X22-67487.ISOSW_DVD9_Win_Server_STD_CORE_2019_1809.16_64Bit_German_DC_STD_MLF_X22-67489.ISO
auch die älteren (Version ist die Zahl hinter dem 2019_1809.) funktionieren ohne Probleme. Eine neue Iso habe ich bisher nicht ausprobiert, Isos sind immer aus dem VLSC.
Bei der Installation auch kein Dynamic Update, gepatcht wird immer nach Installation über WSUS
Das Verhalten habe ich weder bei HyperV noch vSphere VMs. Sicher, dass da keine GPO oder ähnlich reinfunkt?
eventuell zu schwaches passwort? könnte das problem nicht eventuell damit zu tun haben:
KB5020282—Account lockout available for local administrators
siehe letzter absatz:
Additionally, we are now enforcing password complexity on new machines if a local administrator account is used. The password must have at least three of the four basic character types (lower case, upper case, numbers, and symbols).
Was mir nicht klar ist: Bedeutet das der Administrator kann sich in dieser Einrichtung Anmelden mit einem "leeren" Passwort UND dem eigentlich gesetzten Passwort? Bzw. mit einem beliebigen Passwort?
Meine Interpretation: Ein leeres Passwort – aber beachtet meinen Nachtrag, dass der Effekt nur bei "manchen" Passwörtern auftritt.
Kann ich nicht bestätigen!
Ich kann das auch nicht bestätigen, oder ich verstehe es falsch?
Soeben mit einer Win Srv 2022 ISO (August 21) getestet.
Core-Variante:
Nach erfolgreichem Setup kommt:
————
Administrator
The user's password must be changed before signing in.
OK
————
Passwort gesetzt -> Neustart -> Anmeldung erfordert Passwort!
GUI-Variante:
Customize settings
Type a password for the built-in administrator account that you can use to sign in to this computer.
—————
Passwort gesetzt -> Anmeldebildschirm mit Ctrl+Alt+Del -> Passwort wird gefordert, d.h. keine Anmeldung ohne Passwort möglich.
Ich arbeite normalerweise mit MDT: Passwort in der Unattended-Datei hinterlegt. Dort ist auch ein Passwort für Logon erforderlich, Server 19 und 22.
Ev. hat dort jemand die Unattended-Datei verbockt oder es ist wo ein Autologon aktiviert?
Hi, wir haben mit der originalen ISO von MS getestet, Autologon ist nicht gesetzt da der Server noch nicht mal das AD kennt.
Hallo,
ich melde mich mal zu Wort :-)
bei der Installation vom Server im Lab testen wir immer verschiedene Passwörter aus, wenn wir beim Installieren das Passwort #1Administrator2# vergeben, wird dies vom Server zwar angenommen aber danach ignoriert.
Wenn ich mich nun mit dem lokale Administrator über vSphere anmelden will, sagt er einfach das kein PW gesetzt ist.
Gruß Gregor
ok, also liegt's vielleicht daran, dass ihr das Passwort mit # beginnt od. endet? mit anderen Zeichenfolgen das selbe Problem?
andere Passwörter werden übernommen, jedoch habe ich nicht probiert am Anfang und ende # zu hinterlegen und in der Mitte was anderes.
aber trotzdem komisch, sollte ja eigentlich egal sein
Mit Passwort #1Administrator2# kann ich es auch bestätigen, Server 2022 Standard Iso.
Ev. hängt es mit dem Benutzernamen im Pwd zusammen?
Danke für die Ergänzung – wenn es weitere Bestätigungen gibt, schiebe ich zum Wochenende einen englischsprachigen Blog-Beitrag nach. Dann kann ich es den Microsoftlern vor die Füße spülen.
Hi, das habe ich denen schon gemeldet, das case würde von denen einfach zugemacht ohne irgendwas getan zu haben.
Gruß Gregor
Hab's auch im vorbeigehen mit einer Server 2022 getestet. Wenn das Passwort "#1Administrator2#" gesetzt wird, dann erfolgt anschließend ein Auto-Logon. Es kommt also keine Kennwort-Abfrage …
Mir ist das damals schon aufgefallen, wie bekannt wurde, dass das setzen von Passwörtern via GPO böse ist und auch entfernt wurde.
Hatte man eine solche GPO für das Adminkonto eingerichtet, konnte man OHNE Passwort einloggen.
Hat halt leider niemand wirklich interessiert. Insofern sind das für mich keine Neuigkeiten, eher ein weiteres Armutszeugnis für Redmond.
Hi, ja nur haben wir solch eine GPO nicht, der Server zieht sich sogar gar keine GPO da er noch keinen Join hatte.
ansich empfinde ich das schon als Sicherheitslücke…. gut man muss erstmal Zugang zu vSphere haben, wenn das jemand hat der das nicht sollte, hat man eh ein anderes Problem. Aber ein lokalen Serveradministrator ohne PW…… naja
Mit dem leeren Passwort kann sich aber zumindest niemand remote anmelden.
Die Situation ist natürlich trotzdem unschön.
Das liegt an der neuen Passwortkomplexität. Es ist nicht erlaubt den Benutzernamen oder Vor- und Nachnamen im Passwort zu verwenden.
Hi,
Hm ja aber es geht trotzdem und danach hat's ihn verlassen
dann sollt beim setzen des Passworts eine dementsprechende Fehlermeldung kommen und fertig. Kann ja nicht sein, dass es Konstellationen geben kann, wo Microsoft einfach sagt super und im Hintergrund kein Passwort setzt.
Man kann sich nicht immer auf LAPS verlassen. Es soll auch Serverrollen und Konstellationen bei MS geben, wo eine Domain zugehörigkeit nicht unbedingt förderlich oder gewünscht wäre.
Richtig, sehe ich genauso.
Falls noch mehr Bestätigungen hier kommen und Herr Born das der Microsoft vor die Füße wirft, bin ich gespannt wie sie reagieren.
Ganz einfach: alles über 14 Zeichen sprengt den Rahmen!
#1Administrator2# geht (17)
#1Administrator2 geht (16)
#1Administrator geht (15)
#1Administrato loggt nicht mehr automatisch ein (14)
(Getestet mit Eval. von Server 2019 und 2022)
Eigentlich unfassbar, da soll man lange Passwörter verwenden, aber bei denen ist nach 14 Zeichen zu
Ich muss zurückrudern!
Es ist wie schon festgestellt wurde, das Wort "Administrator" das im Kennwort verboten ist, da es dem Nutzernamen entspricht. Die Länge hat nichts damit zu tun, reiner Zufall, dass es in meinem schnellen test gerade beim Überschreiten von 14 auftrat.
Erstmal mein voriges Kommentar lesen und dann noch dieses Leckerli, was ich einst gefunden hatte: https://administrator.de/knowledge/win10-1703-und-nutzerkennwoerter-bei-ersteinrichtung-erstaunliche-erkenntnis-343221.html#comment-343221
Ergo: die Microsofties versagen hier gleich an mehreren Fronten auf unterschiedlich haarsträubende Art und Weise.