Windows Oktober 2022-Patchday: Fix für Domain Join Hardening (CVE-2022-38042) verhindert ggf. Domain-Join

Windows[English]Ich stelle mal eine erste Warnung vor den Oktober 2022-Sicherheitsupdates für Windows hier im Blog ein, da mich ein Leser aus dem Business-Umfeld darauf hingewiesen hat. Die mit den Updates durchgeführten Domain Join Hardening-Änderungen zum Schließen der Schwachstelle (CVE-2022-38042) haben mächtige Kollateralschäden. Mit diesem Update ist u.U. kein AD-Join der Windows-Clients mehr möglich, wenn bestimmte Bedingungen nicht erfüllt werden können – das betrifft alle Windows-Versionen.


Anzeige

Netjoin: Domain Join Hardening Changes

Microsoft beschreibt im Supportbeitrag KB5020276—Netjoin: Domain join hardening changes (Artikel wurde zum 12. Oktober 2022 überarbeitet) Änderungen, die wegen der Schwachstelle CVE-2022-38042 in den kumulativen Update-Paketen vom 11. Oktober 2022 für alle unterstützten Betriebssysteme eingeführt wurden.

  • Windows Server 2008 (ESU)
  • Windows 7 (ESU)
  • Windows Server 2008 R2 (ESU)
  • Windows Embedded POSReady 7 (ESU)
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Embedded 8 Standard
  • Windows Embedded 8.1
  • Windows 8.1
  • Windows RT 8.1
  • Windows 10 Windows 10, Version 1607
  • Windows 10 Enterprise 2019 LTSC
  • Windows 10 IoT Enterprise 2019 LTSC
  • Windows 10 IoT Core 2019 LTSC
  • Windows 10 Enterprise Multi-Session, Version 20H2
  • Windows 10 Enterprise und Education, Version 20H2
  • Windows 10 IoT Enterprise, Version 20H2
  • Windows 10 auf Surface Hub
  • Windows 10, Version 21H1 – 21H2 (alle Editionen)
  • Windows 11 Version 21H2 – 22H2 (alle Editionen)
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2022

Sobald die kumulativen Windows-Updates vom 11. Oktober 2022 oder später auf einem Clientcomputer installiert sind, führt der Client während des Domänenbeitritts zusätzliche Sicherheitsprüfungen durch, bevor er versucht, ein bestehendes Computerkonto erneut zu verwenden. Diese Änderungen werden standardmäßig aktiviert und sind laut Microsoft "sicher". Im Support-Beitrag heißt es:

Während des Domänenbeitritts und der Bereitstellung von Computerkonten fragt der Clientcomputer Active Directory nach einem vorhandenen Konto mit demselben Namen ab. Wenn ein solches Konto vorhanden ist, versucht der Client automatisch, es wieder zu verwenden.

Der Wiederverwendungsversuch schlägt laut Microsoft fehl, wenn der Benutzer, der den Domänenbeitritt versucht, nicht über die entsprechenden Schreibberechtigungen verfügt. Wenn der Benutzer jedoch über ausreichende Berechtigungen verfügt, sollte der Domänenbeitritt erfolgreich sein. Im Support-Beitrag beschreibt Microsoft Szenarien, warum der Domänenbeitritt (Domain Join) scheitert.

Domänenbeitritt (Domain Join) scheitert immer

Blog-Leser Martin E. schrieb mir vor wenigen Minuten, dass die Oktober 2022-Updates für Windows in seiner Umgebung zum Desaster führen. Nachdem er das Update KB5018418 für seine Windows 11 21H2 Clients (bei Windows 10 ist es ähnlich, siehe Screenshot unten) ins Image integriert hatte, konnten die Clients nicht mehr ins AD zur Domäne beitreten (joinen).

Netjoin: Domain join hardening changes - affected Windows versions

Das betrifft wohl alle Windows-Versionen. Martin verweist auf den Support-Beitrag KB5020276—Netjoin: Domain join hardening changes (microsoft.com) als Ursache. Er steht nun vor dem Problem, dass die Ausnahmen, die in obigem Support-Beitrag beschrieben werden, unmöglich auf einer umfangreichen Rechner-Flotte garantieren kann. Der User, der die Maschinen angelegt hat, muss auch der Join Account sein oder ein Domain Admin hat den Maschinen-Account angelegt.

Ein adhoc-Ansatz wäre, ein Image mit altem Patch September 2022 zu erstellen, und das Update für Oktober 2022 erst nach dem Domain Join zu installieren.

Das Verlassen einer AD-Domaine und erneute Beitreten wäre mit dem Oktober 2022-Patch dann nicht mehr möglich. Aktuell ist dieses Oktober 2022-Update noch in keinem Windows-Installationsabbild – selbst Windows 11 22H2 hat im Installationsabbild das Oktober 2022-Update noch nicht integriert (es ist noch auf dem Patchstand von September 2022).

Wie löst ihr dieses Problem? Oder trifft dies bei euch im Unternehmensumfeld nicht zu?

Möglicher Workaround

Martin schrieb in einem Nachgang, dass es eine Hintertür geben könnte und hat mir folgenden Screenshot mit einem Trace-Log und einer kurzen Erklärung geschickt:


Anzeige

Trace log

Es gibt einen neuen Registrierungseintrag NetJoinLegacyAccountReuse, und der Log liefert den Hinweis, dass der Active Directory-Beitritt beim Konto per Sicherheitsrichtlinie blockiert wurde. Martin schreibt:

Ich denke Status: 2 = net helpmsg 2 =  "Das System kann die angegebene Datei nicht finden"

Also dass er den Key nicht findet.

Aktuell finden Suchmaschinen wie Google noch nichts zum Registrierungseintrag NetJoinLegacyAccountReuse, der wohl brandneu ist. Der betreffende Eintrag NetJoinLegacyAccountReuse findet sich als DWORD-Wert im Schlüssel:

HKLM\System\CurrentControlSet\Control\Lsa

Wird dieser DWORD-Wert NetJoinLegacyAccountReuse auf 0x1 gesetzt, sollte ein Domain Join mit den alten Benutzerkonten wieder funktionieren. Ohne den DWORD-Eintrag liefert der Versuch des Domänenbeitritts bei installiertem Oktober 2022-Update folgenden Fehler:

An account with the same name exists in Active Directory. R-using the account was blocked by security policy.

The command failed to complet successfully.

Sobald der DWORD-Wert NetJoinLegacyAccountReuse auf 1 gesetzt ist, meldet der Client:

The computer needs to be restartet in order to complet the operation.

The command completed successfully.

Im Log wird das dann auch bestätigt, denn die Abfrage von IsNetJoinLegacyAccountReuseSetInRegistry liefert nun True zurück.

IsNetJoinLegacyAccountReuseSetInRegistry

Danke an Martin für diese Hinweise. Ein Supportbeitrag oder ein Nachtrag dazu in KB5020276 ist noch nicht vorhanden – ihr könnt ja einen Kommentar hinterlassen, wenn euch zur Thematik noch was unter die Augen kommt.

Ergänzung: Das Problem wurde zum 27. Oktober 2022 bestätigt – siehe Oktober 2022-Update: Error 0xaac (2732) bei Domain-Verbindungen durch Netjoin-Fix für CVE-2022-38042 bestätigt.

Ähnliche Artikel:
Microsoft Office Updates (4. Oktober 2022)
Microsoft Security Update Summary (11. Oktober 2022)
Patchday: Windows 10-Updates (11. Oktober 2022)
Patchday: Windows 11/Server 2022-Updates (11. Oktober 2022)
Windows 7/Server 2008 R2; Windows 8.1/Server 2012 R2: Updates (11. Oktober 2022)
Windows 10: Achtung vor einem möglichen TLS-Desaster zum Oktober 2022-Patchday


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Update, Windows, Windows 10, Windows 7, Windows 8.1, Windows Server abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

30 Antworten zu Windows Oktober 2022-Patchday: Fix für Domain Join Hardening (CVE-2022-38042) verhindert ggf. Domain-Join

  1. Kingcopy sagt:

    Hmmm Moin, alle Windows 10 haben sich heute Nacht die Updates gezogen und sind auf Version 10.0.19044.2130. ich bin gerade testweise mit einigen neuen Notebooks die noch nicht in der AD waren eingestiegen, dabei haben die Desktop0815 Namen , danach ausgestiegen und wieder eingestiegen und dann die Namen geändert und restartet, alles funktioniert einwandfrei, aber wohlgemerkt mit Domänen Admin Accounts.

    Mischumgebung aus 2016 Servern Servern und 2019 ern…

    2016er: 14393.5427
    2019er: 17763.3532

  2. Blacky Forest sagt:

    "Der Wiederverwendungsversuch schlägt laut Microsoft fehl, wenn der Benutzer, der den Domänenbeitritt versucht, nicht über die entsprechenden Schreibberechtigungen verfügt. Wenn der Benutzer jedoch über ausreichende Berechtigungen verfügt, sollte der Domänenbeitritt erfolgreich sein. Im Support-Beitrag beschreibt Microsoft Szenarien, warum der Domänenbeitritt (Domain Join) scheitert."
    Kann mir bitte jemand erklären, was sich da ändert? Das war doch in der Vergangenheit schon so? Oder war das nicht standard und man musste es aktivieren?

    • Blubmann sagt:

      Wäre auch meine Frage. War eigentlich bisher der Ansicht, dass das auch früher vor dem Patches bereits so war.

      • M sagt:

        Ich glaube der Passus ist einfach nur eine irreführende Einleitung.

        Das Problem ist, dass sich im Wiederaktivieren des Computerkontos was geändert hat (legacy account reuse), die Sicherheitsprüfung ob der anstoßende Benutzer das darf ist da unbeteiligt.

      • Hans sagt:

        Es wird nun geprüft ob der User der den Join macht, Owner des Computer Objektes ist oder Domain Admin. Wenn das AD Objekt vom gleichen User erstellt wurde, der den AD Join macht sollte es keine Probleme geben. Die OU Rechte braucht man natürlich trotzdem. Allerdings wieso das sicher sein soll wenn man auf dem Client das Verhalten ändern kann erkenne ich nun nicht ;)

  3. ToWa sagt:

    Salut,
    vielleicht sehe ich das Problem nicht richtig, aber Stand heute wird im Unternehmensumfeld kein Image mit den Oktoberupdates existieren, außer man integriert es manuell.

    Zudem bitte mal erklären welches Szenario existiert in dem ein System ohne Domainadminrechte ins AD aufgenommen werden kann?
    Beim Austritt benötigt man ein lokales Administratorkonto, bei der Aufnahme in die Domain ein Administratorkonto eben dieser…

    • Jan sagt:

      Ich denke mal das hier ein Scenario beschrieben wird welches nur in großen Unternehmen üblich ist.
      Dort gibt es Leute die im Vorfeld schon Konten anlegen und nicht alle Rechte besitzen, (sogannante Hilfadmins) das kann man so delegieren.
      Ich kann mir vorstellen das es dort nun zu Problemen kommen könnte.
      Und das sich die Updates so installieren kann ich mir auch nicht wirklich vorstellen, außer man winkt natürlich alles durch oder noch schlimmer man besitzt nicht mal ein WSUS.

      Allerdings ist das nur meine Meinung, selber arbeite ich nicht in so einem Konzern und mache alles von Hand was Ein- und Austritt in die Domäne betrifft.

    • DW sagt:

      Standardmäßig kann ein Domänen-Benutzer ohne weiteres eine bestimmte Anzahl von Geräten in eine Windows Domäne aufnehmen. Um dies für die genannte Gruppe zu vermeiden, sind manuelle Anpassungen notwendig. Du kannst vermutlich die Kunden an einer Hand abzählen, die das Thema auf dem Schirm haben und Gegenmaßnahmen ergriffen haben.

    • js sagt:

      uiuiui, also bei uns werden überhaupt keine systeme mit domainadminrechten ins ad aufgenommen, das ist doch für sowas viel zu hoch privilegiert!
      ein regulärer user muss doch (bislang) nur in einer ziel-ou das recht haben, computerobjekte zu erstellen, wird bei dem vorgang owner und dann läuft das bereits.
      es ist grob fahrlässig, dafür an einem client domainadmin-credentials zu missbrauchen…

    • Blackii sagt:

      Moin,

      in der Standardconfig von Microsoft können alle AD-User bis 10 Computer hinzufügen :D
      (jedenfalls bei WinSrv 2012-2016)

      MfG,
      Blackii

  4. Phatair sagt:

    hm… verstehe ich das jetzt richtig?
    Das Problem besteht doch nur, wenn das Computer Objekt im AD schon besteht.
    Bei neuen Geräten stört das erstmal nicht, da das Objekt ja noch nicht besteht.
    Bei bestehenden Geräten, die neu geimaged werden oder in die ad neu aufgenommen werden müssen ist das natürlich ein Problem.

    Wenn es schon besteht, muß der gleiche AD User den join durchführen wie beim vorherigen AD join? Das kann doch aber nicht der Ernst von ms sein?!

    @ToWa:
    Nein, zum AD join muss man kein domain administrator sein. Hier sollte man mit Delegation arbeiten und vor allem auch den default ändern, dass jeder AD User 10 Geräte in die Domäne aufnehmen kann.
    Der domain admin ist nur für spezielle AD Tätigkeiten zu gebrauchen und für sonst nichts.

    • ToWa sagt:

      Hey,
      eine Domainaufnahme ist in meinen Augen eine privilegiere Aufgabe für einen Admin. Ich muss gestehen, ich bin bislang nie auf die Idee gekommen da einen normalen Benutzer als Authentifizierung anzugeben.
      …und wenn ich die Beschränkung von 10 Geräten lese, dann ist das sicher auch nicht die Lösung für eine kleine iT. ;)

      Mit der Info würde ich jetzt eher hergehen und das Einbinden von Geräten mit Domain-Benutzer Credentials zu unterbinden. :D

      Aber erstmal nehme ich mit, das hier genannte Problem ist in meinen betreuten Umgebungen kein Problem. :)

      • Phatair sagt:

        Hi ToWa,
        Nein, definitiv nicht. Da gibt es keine zweite Meinung zu. Ein domain admin ist für komplett andere Aufgaben da.

        Das zu erklären wird off topic, aber du solltest dich dringend näher darüber informieren. domain admin accounts dürfen für solche Aufgaben nicht verwendet werden (ebenso haben die nichts auf clients oder Servern zu suchen und dürfen sich dort auch nicht anmelden können). Das ist grob fahrlässig.

        Das mit den 10 domain Aufnahmen hast du falsch verstanden. Es ist per default so, dass jeder ad User 10 Geräte in die Domäne aufnehmen kann. Das sollte man dringend auf 0 setzen (Stichwort ms-DS-MachineAccountQuota) und die Rechte für einen dedizierten Account vergeben. Das ist schnell gemacht und es gibt viele Anleitungen. Am besten für eine Gruppe, da man sonst jeden Account der das Recht bekommen soll neu berechtigungen muss. Dieses accounts können dann beliebig viele Geräte aufnehmen und nur so sollte es konfiguriert sein.

        Das sollte eigentlich Standard sein, wenn du ein AD administrierst.

        so, jetzt aber zum eigentliche Problem.
        Muss jetzt wirklich der owner vom computer Objekt (der beim ersten ad join eingetragen wurde) identisch mit dem sein, der den ad join erneut durchführt?

        • riedenthied sagt:

          "Nein, definitiv nicht. Da gibt es keine zweite Meinung zu. Ein domain admin ist für komplett andere Aufgaben da.

          Das zu erklären wird off topic, aber du solltest dich dringend näher darüber informieren. domain admin accounts dürfen für solche Aufgaben nicht verwendet werden (ebenso haben die nichts auf clients oder Servern zu suchen und dürfen sich dort auch nicht anmelden können). Das ist grob fahrlässig."

          Na doch, dazu gibt es schon zwei Meinungen. "Dürfen nicht", "grob fahrlässig", das sind schon starke Aussagen und doch etwas strikt. Dass man den Gebrauch der Domain Admins gering halten sollte, damit sie von kompromittierten Geräten nicht abgeschnorchelt werden können, steht außer Frage. Aber im Notfall darf das schon funktionieren.

          Der Domain Join eines neu aufgesetzten Rechners ist nun zwar kein Notfall, aber als Angriffsszenario sicherlich ein sehr überschaubares Risiko. Ein Rejoin eines älteren Exemplars ist etwas anderes, aber eben auch kein normaler Vorgang. Also ist es doch wie immer: Es gibt nicht nur schwarz und weiß und "Dürfen nicht" / "grob fahrlässig" ist schon sehr schwarz.

        • ToWa sagt:

          Salut noch mal,
          also ich habe ms-DS-MachineAccountQuota mal gecheckt und ich weiß nicht wo das Problem ist. ;)

          Der Schlüssel ist im ADSI-Editor gar nicht vorhanden und die Benutzer haben diesen daher auch nicht.

          Früher gab es ihn wohl mal, kann ich an einer alten 2012er Domain, welche von ursprünglich von einem alten SBS stammt noch nachvollziehen.

          Grundlegend ist der Standard aber heute wohl auch seitens Microsoft ein anderer.
          Daher ist es vielleicht "grob fahrlässig" nicht ab und an mal Tabula rasa zu machen und den alten Schrott immer mit zu ziehen. :)

          Grüße

          P.S.: Eine schlaue Sicherheitsfirma sagte mal:
          "Amateure hacken Systeme, Profis hacken Anwender."
          Es gibt so viele Schwachstellen, die meisten sitzen aber vor dem Bildschirm (ich schließe mich da durchaus nicht von aus).

  5. js sagt:

    So, ich kann mit sehr viel Verärgerung folgendes berichten:
    – Beim Test sind die DCs nicht gepatcht, ein Client gepatcht.
    – Das Computerobjekt existiert, die Ownership steht auf dem Serviceaccount mit dem ausgerollt wurde.
    – Ein delegierter User kann dieses bestehende Objekt NICHT mit einem erneuten Domainjoin beglücken, obwohl er FULL ACCESS darauf hat!
    – Nach Ändern der Ownership auf dem Computerobjekt für sein delegiertes Benutzerkonto funktioniert es.
    – Nach Änderung der Ownership auf eine Admingruppe, der er angehört, funktioniert es nicht
    – Nach setzen des Registry-Hacks am betroffenen Client funktioniert es wie beschrieben unabhängig von der Ownership am Computerobjekt.

    Ich bin wirklich schockiert von diesem brachialen Amateurlevel von Seiten Microsofts.
    Erstens müsste man ZENTRAL das Sicherheitsventil anbringen, nicht an manipulierbaren Clients.
    Zweitens muss man die effektive Beschreibbarkeit der relevanten Attribute berücksichtigen und kann nicht derart faul auf einer Prüfung der Ownership abheben.
    Drittens liefert man keine unoffizielle Backdoor aus, sondern einen dokumentierten und zentralisierten Workaround um den Schaden abwenden zu können.
    Viertens darf man auf bereits hier diskutierten Least-Privilege-Betrachtungen niemanden mit so schlecht gesetzten Prüfkriterien ermutigen, DomainAdmin-Konten für solche Aktivitäten zu benutzen.

    Es ist ein Wahnsinn.
    Die sollten für solche Flurschadenaktionen bezahlen.
    Ich hoffe inständig, das Cumulative Update wird umgehend zurückgezogen.

    • Phatair sagt:

      Danke für deine Tests.
      Das ist wirklich unfassbar.

      Wir nutzen beim rollout von clients auch einen Service account.
      Es gibt zusätzlich accounts die das delegierte Recht haben, clients in die Domäne aufzunehmen.

      Wir würden damit auch kein re-join eines clients durchführen können, da dafür der dedizierte Account und nicht der Service account vom rollout genommen wird.
      Domain admins sind bei uns für solche Tätigkeiten tabu.

      Das ist von ms tatsächlich unfassbar dämlich gelöst.
      Es wird uns jetzt nicht so oft treffen, da wir selten Geräte erneut in die Domäne aufnehmen müssen, aber das kann und muss anders gelöst werden von ms.

  6. Stefan A. sagt:

    Ich habe bisher noch nie verstanden, warum Microsoft den Default Wert so gesetzt hat, dass ein normaler User bis zu 10 Geräte in die Domäne aufnehmen kann.
    Das will doch keiner!

    Auch wir verwenden zur Aufnahme einen dedizierten Account, der die entsprechende Rechte hat.

    Wäre nicht auch ein Workaround, das Konto vorher zu löschen und dann neu anzulegen?

    Das folgende ist jetzt zwar off topic, aber es triggert mich sehr, dass ich das jetzt mal loswerden muss:

    In den letzten Monaten lese ich immer öfters die Aussage "grob fahrlässig" in den Kommentaren.

    Wenn es danach geht, müsste wohl eine Vielzahl aller Admins ihren Job hinschmeißen und hoffen, nicht noch verklagt zu werden. Denn genau das impliziert die Aussage "grob fahrlässig".

    Wer mich kennt weiß, wie sehr ich auf Sicherheit bedacht bin.
    Und trotzdem schwirrt mir durch solche Aussagen der Gedanke durch den Kopf:
    "Was ist, wenn du mal etwas falsch machst, was andere als "grob fahrlässig" ansehen?
    Bist du dann deinen Job los und wirst auf Schadensersatz verklagt, obwohl du nach bestem Wissen und Gewissen gehandelt hast?"

    Ich mache den Job inzwischen zwar 20 Jahre, aber ich bezweifle immer mehr, dass man den bis zum Rentenalter durchhält.

    Das musste ich jetzt einfach mal loswerden :-)

    • js sagt:

      Hey Stefan, ich habe ja da oben "grob fahrlässig" gesagt und die Anlehnung an den juristischen Begriff darf gerne beeindrucken.
      Das ist schon OK, wenn man es jemandem sagt, der möglicherweise seinen Alltag in einer Infrastruktur herumhopst und an "unverwalteten" Clients mit überhöhten Privilegien arbeitet ohne überlegt zu haben, ob er damit einem trittbrett-fahrendem Angreifer die Räuberstütze macht.
      Ansonsten kann man kann auch "mit bestem Wissen und Gewissen" als Reisebusfahrer die Autobahnabfahrt in die falsche Richtung hochfahren und muss dann halt mit den Konsequenzen leben.
      Und auch ich als Opi bin mal gespannt, wann der Übergang vom Sysadmin zum Cloudkontenklicker zu vollziehen ist. mal seheh was da noch kommt…

  7. Phatair sagt:

    Hi Stefan,
    Es ist leider grob fahrlässig mit einem Domänen Admin arbeiten wie einen domain join oder administrative Tätigkeiten auf einen client oder server durchzuführen.
    Es gibt absolut null Gründe dafür

    Es ist grob fahrlässig ein AD nicht nach Standards abzusichern.

    Jeder der mal ein AD audit mitgemacht hat, weiß wovon ich spreche. Unwissenheit schützt vor Strafe nicht und ein (AD) admin ist dafür verantwortlich genau diesen Bereich bestmöglichst abzusichern.
    Wenn dann schon bei basics, aus Grund von Komfort, wichtige Vorgaben nicht umgesetzt werden, ist das eben genau das, grob fahrlässig.

    nicht umsonst werden z.b. bei Cyberversicherungen genau solche Punkte auch abgefragt. Wenn das nicht gegeben ist, fehlt jegliches Verständnis für die Sicherheit.

    So, nun bin ich aber raus aus dem Thema. Jeder muss das für sich selber entscheiden.

  8. Phatair sagt:

    Hallo Herr Born,
    Eine Frage hätte ich an Sie. Wie sind Sie auf den Supportbeitrag KB5020276 aufmerksam geworden? Ich finde weder im Kb Artikel von CU 10/22 etwas noch im https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-38042 etwas.

    Ich finde MS macht es einem verdammt schwierig diese Infos zu finden oder fehlen mir nur die richtigen Quellen?

    Ich schaue meistens nur die KB Artikel zu den cumulativen Updates an und dort steht so etwas ja nicht. Die geschlossener Sicherheitslücken muss man dann über https://msrc.microsoft.com/update-guide/ suchen oder wie soll ich mir das vorstellen.

    Ich wäre für einen Tipp sehr dankbar :)

  9. Ralf M. sagt:

    Hallo,
    interessant zu wissen wäre für mich, inwieweit sich das geänderte Verhalten auswirkt beim Domain Join von Clients, die über WDS mit vorab erstelltem Computeraccount installiert werden.
    Oder ob es Probleme gibt mit der Domänenmitgliedschaft bei Clientvirtualisierung, genauer gestreamte CITRIX Virtual Desktops, bereitgestellt über CITRIX PVS.
    Vielleicht hat jemand damit zu tun? Ich wäre für Hinweise dankbar!

  10. Rene sagt:

    Hallo Ralf,

    also wir nutzen MDT und haben dort ein PS Script mit drin, welches dann den Domain Join erledigt… das Computerkonto besteht natürlich bereits im AD… aber auch bei neuen Computer Accounts aka. Rechner funktioniert es ohne Einschränkungen. Wir nutzen im PS Script ein Account, der delegierte Rechte innerhalb von 2 OUs hat.

    Ich habe nachdem ich in unser Referenz Image die Updates auf Win 10 21H2 / Win 11 22H2 installiert habe keine Probleme beim Installieren feststellen können…

  11. MWC sagt:

    Danke an alle für die Anregungen zum Grübeln und "besser werden".
    Eigentlich kann man als "Admin" nur noch alles falsch machen, auch wenn man guten Gewissens gehandelt hat.
    Das kommt wenn man keine Zeit mehr für Schulungen hat…

  12. Emeriks sagt:

    Die Tatsache, dass man als lokaler Admin die „Härtung" der Domäne umgehen kann, ist schon sehr peinlich für Microsoft.

  13. Matthias Pierschel sagt:

    Laut Microsoft soll der Workaround im kommenden Jahr deaktiviert werden:

    Wir planen auch, die ursprüngliche NetJoinLegacyAccountReuse-Registrierungseinstellung in einem zukünftigen Windows-Update zu entfernen. Diese Entfernung ist vorläufig für das Update vom 13. Februar 2024 geplant. Veröffentlichungsdaten können sich ändern. [Ende – September 2023]

    Quelle: https://support.microsoft.com/de-de/topic/kb5020276-netjoin-%C3%A4nderungen-bei-der-dom%C3%A4nenbeitrittsh%C3%A4rtung-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8

Schreibe einen Kommentar zu Phatair 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.