LAPS-Integration per April 2023-Update in Windows – Ärger für Administratoren

Windows[English]Microsoft hat mit dem April 2023-Patchday (11. April 2023) seine Local Administrator Password Solution (LAPS) direkt ins Windows Betriebssystem integriert. Erfolgte auf "vielfachen Wunsch" aus dem Kreis der Unternehmenskunden, wie es bei Microsoft heißt. Da dieser Schritt aber wohl unzureichend getestet wurde, haben Administratoren, die den alten LAPS-Client installiert hat, ein Problem. Im Nachgang fasse ich mal die Informationen zusammen, die mir inzwischen vorliegen.


Anzeige

LAPS nun in Windows integriert

Windows Local Administrator Password Solution (Windows LAPS) ist ein Windows-Feature, mit dem das Kennwort eines lokalen Administratorkontos auf den in Azure Active Directory oder Windows Server Active Directory eingebundenen Geräten automatisch verwaltet und gesichert werden kann. Diese lokale Administratorkennwortlösung (Local Administrator Password Solution, LAPS) von Microsoft stellt die Verwaltung der Kennwörter lokaler Administratorkonten für in eine Domäne eingebundenen Computer bereit.

Windows LAPS lässt sich auch verwenden, um das Kennwort des DSRM-Kontos (Directory Services Repair Mode, Reparaturmodus für Verzeichnisdienste) auf Windows Server Active Directory-Domänencontrollern automatisch zu verwalten und zu sichern. Ein autorisierter Administrator kann das DSRM-Kennwort abrufen und verwenden. Kennwörter werden zufällig in Active Directory (AD) angeordnet und gespeichert und durch ACLs geschützt.

Bisher musste dazu ein Administrator aber einen entsprechenden Client unter Windows installieren. Nur in Windows 11 Insider Previews experimentierte Microsoft mit der Integration des LAPS-Clients im Betriebssystem. Zum 11. April 2023 wurde dann der LAPS-Client automatisch mit den kumulativen Sicherheitsupdates auf alle unterstützten Windows-Systeme ausgerollt (siehe die am Artikelende verlinkte Beiträge zu den Sicherheitsupdates für Windows 10 und Windows 11/Sever 2022). Microsoft hatte in den Support-Beiträgen folgenden Hinweis gegeben:

New! This update implements the new Windows Local Administrator Password Solution (LAPS) as a Windows inbox feature.

Microsoft hatte den Techcommunity-Beitrag By popular demand: Windows LAPS available now! zu diesem Thema veröffentlicht. Auf Grund von Kundenanforderungen habe man LAPS ab dem 11. April 2023 sowohl für Cloud- als auch für lokale Umgebungen in folgenden Betriebssystemen bereitgestellt.

  • Windows 11 Pro, EDU und Enterprise
  • Windows 10 Pro, EDU und Enterprise
  • Windows Server 2022 und Windows Server Core 2022
  • Windows Server 2019

Damit wollte Microsoft den Administratoren ersparen, den betreffenden Client manuell installieren zu müssen. Details über die Neuerungen und Vorteile lassen sich im Techcommunity-Beitrag nachlesen. Künftige Korrekturen oder Funktionsupdates will Microsoft über die normalen Windows Updates bereitstellen. Eigentlich eine gute Idee, aber die Kommentarlage zum Blog-Beitrag von Jay Simmons in der Techcommunity zeigt, dass da Diskussionsbedarf besteht.

Ärger, mit LAPS, da zu kurz gesprungen

Leider scheint dieser Schritt für Microsoft mal wieder ziemlich schief gelaufen zu sein. Hier im Blog hatte 1St1 bereits zum 12. April 2023 in diesem Kommentar Probleme angedeutet (danke dafür, hatte das gesehen, aber keine Zeit, es sofort aufzugreifen), und zum 13. April 2023 in diesem Kommentar folgende Details zusammen gefasst:

Das neue LAPS funktioniert nicht nur mit einem lokale AD, sondern jetzt auch mit einem Azure-AD (bzw. Intune). Es ändert nun auch das DSRM Passwort auf Domain-Controllern. Interessanterweise ändert LAPS das lokale Admin-Passwort nun jedes Mal wenn man es benutzt hat, ich weiß nicht, ob das ein bisschen zu viel des Guten ist. Außerdem unterstützt es neue interessante GPO-Settings, man kann jetzt z.B. eine Passwort-History aktivieren, was interessant ist, wenn man ein System auf einen Zeitpunkt vor der letzten LAPS Passwortänderung zurück restoren muss. Details siehe unten in dem Link.

Aber wer LAPS bereits einsetzt, hat für den LAPS Agent schon das eine oder andere automatische Deployment im AD etabliert, welches den bisherigen Agent auf einem System installiert, welches man neu installiert und ins AD aufgenommen hat. Da gibts jetzt ein Problem, installiert man den bisherigen LAPS Agent auf einem System mit den April-Updates, funktioniert LAPS nicht, es ist kaputt.

Aber die Lösung ist recht einfach, man prüft im Deployment-Script auf die Existenz von c:\windows\system32\laps.dll und wenn vorhanden, bricht man das Script ab. LAPS wird dennoch mit dem nun in Windows fest integrierten LAPS Agent funktionieren, wenn man es schon in der Domäne eingeschaltet hat (entsprechende GPO-Settings, Schema-Erweiterung).

Was mir noch nicht klar ist, ob die neuen GPO-Settings, insbesondere die LAPS Passwort History nochmal eine Erweiterung des Schemas brauchen. Ich habe dazu aber noch nicht alle Links gelesen, ich musste erstmal sicherstellen, dass der alte LAPS-Agent nicht mehr autodeployed wird, wenn bereits das April-2023-Update auf der Maschine ist. Diese erweiterten Settings sind im Screenshot unter nachfolgendem Link zu sehen, ich habe sie in unseren Gruppenrichtlinien noch nicht entdeckt, vielleicht muss man da erst eine neue ADMX einspielen.

Zum 14. April 2023 hat Blog-Leser Jonas dann in diesem Kommentar erneut auf das Problem hingewiesen:

Wichtiger Hinweis für diejenigen, die das Legacy-LAPS im Einsatz haben.

Man zerschießt sich beide (!) LAPS-Varianten, wenn man nach der Installation der April-Updates die Legacy-Version von LAPS installiert (was in unserer Umgebung der Fall ist, da in unserer automatisierten OS-Installation die aktuellen MS-Updates zuerst aufgespielt werden – getestet haben wir es noch nicht).

Aufgeschnappt habe ich das im aktuellen Reddit-Patchday-Thread (siehe auch).

Jonas weist darauf hin, dass Microsoft das Problem bereits in einem Infofeld im Beitrag Legacy LAPS Interop issues with the April 11 2023 Update auflistet (es gibt dort  blaues Info-Feld mit folgendem Text – nachfolgend noch die deutsche Übersetzung):


Anzeige

Das Update vom 11. April 2023 enthält zwei potenzielle Regressionen im Zusammenhang mit der Interoperabilität mit älteren LAPS-Szenarien. Bitte lesen Sie die folgenden Informationen, um die Parameter des Szenarios und mögliche Umgehungslösungen zu verstehen.

Problem Nr. 1: Wenn Sie die Legacy-LAPS-CSE auf einem Gerät installieren, das mit dem Sicherheitsupdate vom 11. April 2023 gepatcht wurde, und eine Legacy-LAPS-Richtlinie anwenden, treten sowohl Windows LAPS als auch Legacy-LAPS in einen fehlerhaften Zustand ein, in dem keine der Funktionen das Kennwort für das verwaltete Konto aktualisiert. Zu den Symptomen gehören die Windows LAPS-Ereignisprotokoll-IDs 10031 und 10033 sowie die Legacy-LAPS-Ereignis-ID 6. Microsoft arbeitet an einem Fix für dieses Problem.

Für das obige Problem gibt es zwei primäre Umgehungsmöglichkeiten:

a.Deinstallieren Sie das alte LAPS CSE (Ergebnis: Windows LAPS übernimmt die Verwaltung des verwalteten Kontos)

b. Deaktivieren Sie den Legacy-LAPS-Emulationsmodus (siehe Disable legacy LAPS emulation mode); Ergebnis: Legacy-LAPS übernimmt die Verwaltung des verwalteten Kontos)

Problem Nr. 2: Wenn Sie eine Legacy-LAPS-Richtlinie auf ein Gerät anwenden, das mit dem Update vom 11. April 2023 gepatcht wurde, wird Windows LAPS die Legacy-LAPS-Richtlinie sofort erzwingen, was störend sein kann (z. B. wenn dies während des Arbeitsablaufs der Betriebssystembereitstellung geschieht). Die Deaktivierung des Legacy-LAPS-Emulationsmodus kann ebenfalls verwendet werden, um diese Probleme zu vermeiden.

Das Ganze ist also ziemlich schief gegangen. An dieser Stelle mein Danke an alle Leser, die sich wegen des Themas hier im Blog oder per Mail gemeldet haben.

Vorgehensweise für deutsche Systeme

Mark Heitbrink hatte bereits in internen Facebook-Gruppen auf die Problematik hingewiesen (hatte ich gesehen) und mir gestern noch eine Mail mit Hinweisen geschrieben (danke dafür). Er meinte, dass es Ärgerliches aus der LAPS Ecke gäbe, und das Durcheinander sei mal wieder mangelnder Sorgfalt geschuldet. Es sieht so aus, dass die englischsprachigen Windows-Implementierungen getestet werden, während die Administratoren von anderen Sprachen mit Windows auf den Bauch fallen.

Mark Heitbrink hat für deutschsprachige Leser den Beitrag Migration LAPS Legacy zu LAPS native veröffentlicht, der beschreibt, was durch die Integration des LAPS-Clients in Windows mit den April 2023-Updates zu beachten ist, sofern LAPS bereits in der Unternehmensumgebung eingesetzt wurde. Sollte sich jeder Administrator, der LAPS im Unternehmen einsetzt, vielleicht mal durchlesen.

Ähnliche Artikel:
Microsoft Security Update Summary (11. April 2023)
Patchday: Windows 10-Updates (11. April 2023)
Patchday: Windows 11/Server 2022-Updates (11. April 2023)
Windows 7/Server 2008 R2; Server 2012 R2: Updates (11. April 2023)
Patchday: Microsoft Office Updates (11. April 2023)
Microsoft April 2023 Patchday-Nachlese
Windows Server Active Directory-Schema für die aktuelle Windows LAPS-Version aktualisieren


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

48 Antworten zu LAPS-Integration per April 2023-Update in Windows – Ärger für Administratoren

  1. Mark Heitbrink sagt:

    @1ST1 den automatischen Wechsel nach Verwendung kannst du per Richtlinie deaktivieren. Ich halte ihn für ein "Most Wanted Feature", da es jetzt nicht mehr als Workflow mit manuellem Passworddatumsablauf gesetzt werden muss. Das wurde oft vergessen. Aber je nach Einsatz kann das schon nervig sein. Aus Sicherheitssicht ist es richtig.
    Computerkonfiguration\Administrative Vorlagen\System\LAPS
    Aktionen nach der Authentifizierung = Aktiviert
    -> Dropdown: Deaktiviert – Keine Aktion ausführen

    Du wirst schon gemerkt haben, das es ein Schemaupdate ist, da erzähle ich nichts neues :-)

    Das DSRM Kennwort wird nur bei Server OS 2019 und DFL 2016 gesetzt.
    – DFL 2016 um die Kennworte zu verschlüsseln. Sonst geht nur Plaintext
    – DFL 2016 und DC Operating System 2019, wenn das DSRM Kennwort gesetzt werden soll
    Der Rest geht auch mit einem DC 2003, wenn er noch supported wäre :-)

  2. Mark Heitbrink sagt:

    LAPS Nativ deaktivieren geht per GPO, klingt nur nicht so auf den ersten Blick:

    Computerkonfiguration\Administrative Vorlagen\System\LAPS
    Kennwortsicherungsverzeichnis konfigurieren = Aktiviert
         Sicherungsverzeichnis = 0=Deaktiviert (Kennwort wird nicht gesichert)
         Kommentar: oder per RegHack HKLM\Software\Microsoft\Windows\CurrentVersion\LAPS\Config, DWord BackupDirectory = 0

  3. JohnRipper sagt:

    Danke für den Hinweis.

    Dann muss man das Deployment der April 2023 Updates erstmal aussetzen, bis LDAPs auf die native Variante umgesetzt ist.

    Natürlich muss das relativ kurzfristig erfolgen.

    Was eine s****

    • Tom sagt:

      Andererseits solltest du aber die April Updates wirklich zügig umsetzen, vor allem wenn irgendwo MSMQ (Microsoft Message Queuing) aktiviert ist. Da gibt es eine kritische Lücke CVE-2023-21554, die mit den April Updates gefixt wird.

  4. Andy sagt:

    "Fehlende Sorgfalt" in Bezug Windows Updates kann ich irgendwie nicht mehr hören. Könnte man quasi als Synonym für diese benutzen.
    Etwas Abwechslung in den Begrifflichkeiten fände ich gut. Und es schien mir auch die neue Mode, für alles ein Wortspiel zu finden und es so zu bennen.
    Ich schlage für dieses Mal vor: es ist ihnen ein LAPSus unterlaufen.
    Auch wenn es eigentlich ein LAPS(de-)de sein müsste, weil LAPS(en-)us ja wohl weniger Probleme macht.
    Ich melde mich ab, muss mich erst mal von diesem Posting erholen. Außerdem laufe ich sonst Gefahr, mich noch über weitere LAPSde-des auszulassen, wie zum Beispiel jeden Microsoft-Artikel auf deutsch. Argh, bin weg.

  5. Mark Heitbrink sagt:

    Megaaaaaaaa. Bähm. You nailed it. Wie geil ist das denn?

    LAPSus ist der Hammer, weil es nur in englisch funktioniert :-) Den schlage ich Jay direkt um die Ohren.

  6. MOM20xx sagt:

    den dreck hätten sie sich schenken können. leute die noch windows server 2012 r2 im einsatz haben müssen sowieso legacy LAPS verwenden.
    da kommt a security update und installiert ein neues feature, dass dann ein anderes feature schlicht weg kaputt macht.
    im klartext heisst das wohl für alle die legacy laps verwenden wollen

    https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-legacy#disabling-legacy-microsoft-laps-emulation-mode

    To prevent this you can disable legacy Microsoft LAPS emulation mode by creating a REG_DWORD registry value named BackupDirectory under the HKLM\Software\Microsoft\Windows\CurrentVersion\LAPS\Config key and set it to the value zero (0). Setting this value will prevent Windows LAPS from entering legacy Microsoft LAPS emulation mode, regardless of whether the legacy Microsoft LAPS CSE is installed or not. This value may be used temporarily or permanently. Note that if\when a new Windows LAPS policy is configured, that new policy will take precedence. For more information on the Windows LAPS policy precedence ordering, see Configure Windows LAPS policy settings.

    das ist wirklich alles sehr durchdacht und die haben das vor rollout sicher auch getestet – nicht?

  7. Michael sagt:

    "Interessanterweise ändert LAPS das lokale Admin-Passwort nun jedes Mal wenn man es benutzt hat, ich weiß nicht, ob das ein bisschen zu viel des Guten ist." Das ist eigentlich eine neue Funktion, die per GPO verwaltbar ist. Das heißt, dass hier wohl jemand schon die neuen Templates geladen hat und diese Funktion aktiviert hat, weil im Emulation Mode gibt's die Funktion ja noch nicht.

    • 1ST1 sagt:

      Stimmt, dieses Feature wird erst aktiv, wenn man die neuen LAPS-Gruppenrichtlinien und die neue Schema-Erweiterung umgesetzt hat. Das habe ich inzwischen auch verstanden, dank des Artikels auf gruppenrichtlinien.de, danke @Martin H., und dank des Artikels auf windowspro.de, danke @ Wolfgang S.

      Da wir noch ein paar 2012er Server laufen haben, die aber noch weg kommen, lasse ich es jetzt erstmal so laufen, wie es ist, das heißt im Legacy-Modus. Wenn die 2012er dann weg sind, dann probiere ich das mit der Migration auf die neue Variante. Aber jedes Mal PW wechseln, wenn man das LAPS-PW nutzt, ist vielleicht wirklich ein bischen fett, wenn man das LAPS-PW für eine Tätigkeit gerade mal öfters braucht. Aber man kann es ja abschalten – ein zeitverzögerter Wechsel (4 Stunden nach letzter Benutzung oder sowas wäre ein schicker Kompromiss!)

      Hier auch der recht aufschlussreichen Artikel von Wolfgang Sommergut, auch dafür danke:

      https://www.windowspro.de/wolfgang-sommergut/laps-nun-windows-1011-windows-server-enthalten-neue-funktionen-fuer

      Der Artikel hat aber IMHO am Ende einen Fehler:

      "Außen vor bleiben die Anwender von Windows Server 2016."

      Nach meinen Untersuchungen hat auch Server 2016 nach dem Update die Datei c:\windows\system32\laps.dll plus alle weiteren Laps-Dateien, die vor dem Update nicht da waren, ich habe auch ein paar 2016er Server mit/ohne Update untersucht und es war eindeutig, auch 2016 wird meiner Meinung nach auf die neue Version von LAPS migriert.

      • MSH MC sagt:

        nach Culmulatives April Update habe ich festgestellt, dass auf einem DC mit Windows Server 2016 die laps.dll fehlt. Ist das normal oder werden die WS2016-Server doch nicht unterstützt? Das Thema ist, dass ich nicht weiter mit den Schema-Updates usw. beginnen möchte, wenn ich die Registerkarte "LAPS" nicht sehen kann.

        Gibt es eine Lösung oder ein Update für Domain Controller, die unter WS2016 laufen?

        Vielen Dank im Voraus.

    • Mark Heitbrink sagt:

      ja. Die Migration in 2 Domänen ist schon abgeschlossen.

  8. MadJack sagt:

    Ich war gerade dabei das alte LAPS bei uns einzurichten. An meinem Test-System läuft das schon.
    Wir haben noch mehrere 2012R2 DC im Einsatz.
    Verstehe ich das jetzt richtig. Das neue Windows LAPS funktioniert nur, wenn man einen Windows 2019 DC hat und die Domain auf Windows 2016 Level oder höher ist.
    Wennst einen 2012 R2 oder Windows 2016 DC hast darfst/musst das alte Legacy LAPS einsetzten?
    Die Produktiven Clients haben schon das aktuelle April Windows Update erhalten. Server werden nächste Woche installiert.

    • Mark Heitbrink sagt:

      welchen Teil von "sonst geht nur plaintext" hat du nicht gelesen? ;-)
      du kannst es auf den Membern zb per WMI filter in den Gruppenrichtlinien 2 gleisig fahren und im AD beides speichern

  9. Heiko sagt:

    Ich habe mich ja schon länger damit befasst. Und eigentlich war meine Info dass sobald die alte CSE installiert ist und die Legacy GPOs konfiguriert sind, Windows LAPS nicht in den Legacy Mode geht.
    Und es war auch eigentlich so gedacht, das man bei im parallel Betrieb haben kann, wenn damit unterschiedliche Benutzer verwaltet werden.

    In sofern erstaunt es mich jetzt doch, dass es wohl zu Konflikten kommt. Und so wie ich das sehe ist die Funktion Windows LAPS zu deaktivieren, um den Legacy Modus zu verhindern auch noch nicht lange implementiert/in der Dokumentation.

    Btw, der lokale Regkey kann auch per GPO gesetzt werden. Einfach die "Backup Directory" policy deaktivieren.

  10. Heiko sagt:

    @Günter Born, @Mark Heitbrink
    Ich habe hier interessante Informationen darüber, was genau schief läuft. Und es hat nix mit der Sprache zu tun.

    https://github.com/MicrosoftDocs/windowsserverdocs/issues/6961#issuecomment-1509890241

    • Mark Heitbrink sagt:

      doch ist es, jedenfalls was meine spezielle Problematik betrifft: eventlog, admx adml chaos.

      in dem Link reden ein paar Leute, die Gruppenrichtlinien für Voodoo halten und keine Ahnung haben, aber am Ende kommen sie zu dem richtigen Schluss:

      ja, es gibt ein Problem, wenn 04-2023 installieren ist und LAPS legacy nachträglich kommt oder weiterhin aktiv ist.

      die simple Lösung ist:
      legacy abschalten, nativ integrieren. 5 Minuten Arbeit.

  11. Tom sagt:

    Hmmm… kann ich hier irgendwie nicht nachstellen.

    Wir aktualisieren hier jeden Monat das WIM für das Betriebssystem Deployment, damit die Installation der Patches auf neuen Systemen nicht so lange dauert. Sprich, neu installierte Rechner haben schon das April Update integriert. Die neue LAPS.DLL ist vorhanden. Und der Win10 Rechner ist auf 19044.2846, der win11 Rechner auf 22000.1817

    Nachträglich wird die alte LAPS CSE installiert. Die alte AdmPWD.dll ist vorhanden.

    Die neuen Schema Erweiterungen haben wir nicht, ebenso keine der neuen GPO Settings. Ich habe jetzt extra über die alte Legacy LAPS UI das Passwort des lokalen Administrators mehrfach erneuern lassen. Das wurde problemlos durchgeführt. Das Passwort für den lokalen Administrator wurde geändert und auch erfolgreich in die AD geschrieben.

    Ich habe dann auch noch den "ExtensionDebugLevel" auf "Verbose Logging" (2) gestellt um das ausführliche LAPS Reporting in der Ereignisanzeige zu haben. Aber auch da finde ich nichts ungewöhnliches außer der Meldung, dass das Kennwort erfolgreich geändert und in die AD geschrieben wurde.

    Irgendwie komisch. Oder tritt das Problem nur auf, wenn zusätzlich noch die neuen GPOs verwendet werden?

    • Anonymous sagt:

      Ohne Arme keine Kekse. Wie soll das neue LAPS funktional werden, wenn du keine Schema Erweiterung gemacht hast. Nur DLL/CSE Installieren hat beim LAPS legacy auch nie funktioniert.

      LAPS ist eine 3 teilige Komponente:
      – Schema Erweiterung
      – DLL (ehemals CSE)
      – SelfWrite des Computer Obejcts auf den Attributen

      • Tom sagt:

        Du hast mich glaube ich falsch verstanden. Wir haben LAPS Legacy seit Jahren im Einsatz. auf den Client ist also die LAPS CSE installiert. Die Schema Erweiterung von LAPS Legacy ist natürlich auch vorhanden, genauso wie die Legacy GPOs und die Rechte auf den notwendigen AD Attributen.

        Ich hatte es nur so verstanden, dass das kumulative April Update auch die alte LAPS Legacy Lösung funktionsunfähig macht, falls auf neuen Rechnern das kumulative April Update VOR der Installation der Legacy CSE installiert wird. Das ist bei uns aber nicht der Fall. LAPS Legacy funktioniert ohne Probleme, auch wenn der Apil Patch vor der CSE installiert wird.

        Deshalb war die Frage, ob das Problem vielleicht zusätzlich auch mit der Reihenfolge zu tun hat, wann die Legacy GPOs angewendet werden.

        • Andreas sagt:

          Genau was Du beschrieben hast, habe ich ebenfalls beobachtet.
          DCW2k16, kein Schemaupdate für native LAPS.
          Legacy LAPS seit Jahren in Anwendung.

          Windows 10 Client mit April Patch. Datei c:\windowssystem32\laps.dll vorhanden. Passwörter werden aktualisiert.

          Erneute legacy LAPS installation auf Rechner. Passwörter werden weiterhin aktualisiert.

  12. Markus sagt:

    Guten Morgen,

    für mich zum Verständnis.

    Wir haben alle unsere DCs auf Server 2016 Datacenter. Somit bin ich dann außen vor, was die neue LAPS Integration/Nutzung angeht oder?

    • Mark Heitbrink sagt:

      Nein.
      Der 2016 ist als CLIENT draussen und das DSRM Kennwort kann nicht auf dem DC 2016 gesetzt werden

      • Markus sagt:

        Hallo Mark,

        das heißt aber troztdem für mich, das ich die DCs auf min. 2019 hochziehen/ersetzen muss, um dann das Schema Update durchführen zu können. Das Schema Update ist bei DCs mit Server 2016 doch nicht möglich.
        Erst wenn das Schema Update durchgeführt wurde, kann ich das neue LAPS nutzen, oder verstehe ich das falsch?

        • Bernd sagt:

          Hallo Markus,
          ich stehe vor dem gleichen Problem. 2 DCs auf 2016, 2 auf 2019. Den Befehl für das Schema Update kennt OS 2016 gar nicht, wohingegen der DC 2019 mit dem April Patch sehr wohl den Befehl kennt. Allerdings bin ich mir sicher, dass das Schema Update schief gehen wird.
          Ohne Schemaerweiterung kein Laps native würde ich dann mal sagen. Oder gibt es dazu andere Erkenntnisse?

          • Michael sagt:

            Hallo,
            vielleicht kommt die Antwort etwas spät aber wir hatten den gleichen Fall. Alle DCs sind 2016, ich habe das Schema Update an einem Member Server 2019 durchgeführt. Hat funktioniert, man muss auch die LAPS Passwörter an einem Server 2019 oder Windows 10 auslesen.

  13. MOM20xx sagt:

    haben die irgendwas getestet?
    hab jetzt mal auf unseren Servern den legacy mode deaktiviert. teils nagelt laps das eventlog mit 4-5 events pro 5 sekunden zu. teils mit 4-5 events pro 5 minuten.

  14. Emeriks sagt:

    Moin,
    wir rollen das alte LAPS bisher per GPO + MSI aus.

    Sollte man jetzt nicht besser (und am einfachsten) das alte LAPS genauso wieder deinstallieren, bevor man die 02/23-Updates installiert? Zumindest bei allen Win 2019 ff. und Win 10 ff. ?

    Ich frage weil:
    Es scheint ja so zu sein, dass das beschriebene Problem auftritt, wenn man das alte LAPS installiert, nachtem das neue "native" LAPS installiert wurde.
    Was passiert dann, wenn man das alte LAPS deinstalliert, erst nachdem man das neue mit den Updates installiert hat?

    E.

    • Michael sagt:

      Eine Deinstallation ist nicht notwendig. Einfach das Deployment für Microsoft LAPS auf allen "LAPS for Windows" supporteten SKUs stoppen (Kernel Win10 1809 und jünger, Win11). LAPS for windows erkennt automatisch die vorhandene dll und arbeitet entsprechend. Probleme gibt es nur, wenn Microsoft LAPS nachträglich installiert wird.

  15. Emeriks sagt:

    Gibt es da jetzt auch ne neue GUI zum Auslesen der gespeicherten Passwörter oder geht das (nur) über PowerShell?

    • Thomas sagt:

      So wie ich es verstanden habe steht es im jeweiligen AD Objekt in einem neuen Reiter der "LAPS" heißt. Eine Übersicht für alle wie die Web GUI (ka da LAPS leider nie eingesetzt) wüsste ich jetzt nicht, lasse mich aber gerne korrigieren.

  16. Thomas sagt:

    Moin, immer diese Admins die sich auch krank mit IT Themen beschäftigen müssen…
    In einer Domäne in der es nur einen Server 2016 DC und sonst Server 2012/2012R2 DCs gibt und noch klein LAPS in irgendeiner Form eingeführt wurde (also weder das "alte manuelle" noch das neue per Updates, müssen wir jetzt irgendetwas beachten? Wenn ich es richtig verstanden habe dann erst wenn wir bald neue DCs haben (2019 aufwärts) und das AD Schema angehoben haben, dann das Ganze per GPOs konfigurieren, richtig? Oder laufen die Windows 10 Clients mit den April Updates jetzt in eine Falle?

    • Emeriks sagt:

      Auch mit DC kleiner als 2019 können Clients mit größer/gleich Win 10 1809 mit LAPS versorgt werden.
      Aber so wie ich das verstanden habe: Wenn man nicht explizit das Schema-Update einspielt und nicht explizit das neue LAPS per GPO aktiviert, dann ändert sich diesbzgl. gar nichts.

    • Mark Heitbrink sagt:

      Noch mal, für alle die nicht mitlesen:
      a) Deine "Falle" ist NUR(!) relevant für Admins mit LAPS Legacy. Bist du nicht, hast du nicht.
      b) Die "Falle" ist NUR(!) aktiv, wenn das LAPS Legacy MSI NACHTRÄGLICH(!1!11!) zum 04.2023 installiert wird.. Passiert dir nicht, du fängst direkt mit Native an und lässt Legacy an.

  17. Zanza sagt:

    Wie kann man erstens, das neue LAPS erzwungen in das kumulative monatliche Sicherheitsupdate integrieren und zweitens, das nicht mal auf Kompatibilität testen?

  18. Boris sagt:

    Wir beobachten das gleiche wie andere hier im Forum

    – LAPS legacy seit längerem im Einsatz (inkl. Schemaerweiterung)
    – Keine Schemaerweiterung vom neuen LAPS
    – Neue, deutsche Windows 10 Clients inkl. April 2023 Updates bekommen nachträglich legacy LAPS ausgerollt und es funktioniert alles wie vorher auch

    Hat denn jemand konkret die Probleme, die oben beschrieben wurden?

  19. Daniel Hoffmann sagt:

    mal eine ganz bescheidene Frage in die Runde:
    – bei uns ist das LAPS legacy seit Jahren im Einsatz (Version 6.2.1.0)

    ich habe nun ein ganz anderes Problem:

    wenn das April-Update eingespielt ist und legacy LAPS auf dem Rechner noch installiert ist startet der Dienst "Microsoft Software Protection" nicht, dies führt dann dazu dass Office365 Lizenzen anscheinend nicht mehr aktualisiert werden können und das aktuelle Office 365 dann ständig mit der Meldung "Office reparieren…" kommt. Konnte noch wer das so nachvollziehen?

    Deinstallation des LAPS legacy Client behebt das Problem nach Neustart…

    • Paul sagt:

      Kann ich soweit bestätigen. Hatten die selbe Konstellation und auch die selben Fehler. Erst die Deinstallation des alten LAPS Clients hat geholfen.

  20. Martin sagt:

    Ich habe festgestellt, dass das integrierte LAPS auf Server 2019 Core nicht funktioniert. Bei diesen Server brauche ich weiterhin den alten LAPS Client, damit das Passwort aktualisiert wird.

  21. Christian sagt:

    Ich habe gerade noch festgestellt, dass auf vielen DCs zwar die LAPS.admx Datei in den PolicyDefinitions vorhanden ist, aber die LAPS.adml Dateien in den entsprechenden Sprach-Ordnern fehlen. Hierdurch wirft die Gruppenrichtlinienverwaltung für alle GPOs den Fehler "Für Datei "C:\Windows\PolicyDefinitions\LAPS.admx" konnte keine geeignete Ressourcendatei gefunden werden (Fehler = 2): Das System kann die angegebene Datei nicht finden.". Windows erstellt dann für bestehende GPOs keinen Bericht für die Administrativen Vorlagen mehr und auch beim Erstellen neuer GPOs schmeißt Windows erstmal eine Warnung mit obigem Inhalt.

    Das Problem lässt sich zwar einfach beheben, indem man die Datei von einem anderen System kopiert (ich konnte sie von meinem Windows 11 Notebook kopieren), nervig ist das aber allemal.

    Für alle die Suchen müssten, die Datei liegt auf Servern und Clients unter
    C:\Windows\PolicyDefinitions\de-DE\LAPS.adml (oder entsprechende andere Sprache)

    Auf DCs bitte auch an den zentralen Speicher für GPO-Vorlagendateien denken:

    C:\Windows\SYSVOL\sysvol\contoso.com\policies\PolicyDefinitions\de-DE\LAPS.adml
    bzw.
    \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions
    bzw.

  22. Stefan sagt:

    Hallo zusammen,

    ich möchte euch auf einen weiteren Bug in Zusammenhang mit den neuen Windows/native LAPS hinweisen, der auf Failover-Clustern (Windows Server 2019) mit Hyper-V Rolle zu unerwarteten Neustarts der Nodes führt.

    Siehe in Günthers Blog-Post "Microsoft April 2023 Patchday-Nachlese" die Kommentare von mir https://www.borncity.com/blog/2023/04/14/microsoft-april-2023-patchday-nachlese/#comment-147102 und die Kommentare von Peter https://www.borncity.com/blog/2023/04/14/microsoft-april-2023-patchday-nachlese/#comment-147552 .

    Wir konnten hier nachstellen, dass das Zuweisen der neuen GPOs zu diesem echt üblen Verhalten führt, Stichwort: "The system process 'C:\Windows\system32\lsass.exe' terminated unexpectedly. The system will now shut down and restart."

    Das Problem scheint hoffentlich mit KB5026362 behoben zu sein, siehe Microsofts Beitrag zum Mai Update: "This update addresses a race condition in Windows LAPS. The Local Security Authority Subsystem Service (LSASS) might stop responding. This occurs when the system processes multiple local account operations at the same time. The access violation error code is 0xc0000005."

    Viele Grüße
    Stefan

  23. Chris sagt:

    Ich habe einen Win 11 Test Client, dort den alten LAPS Client deinstalliert.
    Schemaerweiterung fürs neue LAPS durchgeführt und eine neue LAPS GPO deployed.
    Nun bekomme ich LAPS Fehler 10072, dass das Passwort in der AD nicht verschlüsselt werden kann wegen fehlenden KDS Root Key, obwohl dieser vorhanden ist und auch für GMSA usw verwendet wird.

  24. Matthias sagt:

    Hallo zusammen.
    Gab es mit dem Update aus 02/2024 eine weitere Änderung?
    Auf div. Systemen hat die LAPS.dll nun ein Datum aus 02/2024.
    Weiß da jemand was?
    Auf verschiedenen Maschine dauer die GPO "AdmPwd" auch bis zu einer Stunde – also bis man sich überhaupt anmelden kann.

Schreibe einen Kommentar zu Michael Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.