Mit den November 2022-Updates für Windows Server gibt es ggf. Probleme mit dem Domain-Join. Das betrifft vor allem Umgebungen, wo eventuell ältere Windows XP-Maschinen noch in ein Netzwerk integriert sind. Ein Blog-Leser hat mich auf das Problem hingewiesen und hofft auf eine Lösung.
Anzeige
Vorab eine Anmerkung im Hinblick auf Bemerkungen der Art "Windows XP ist längst aus dem Support gefallen". Der Fall zeigt, wie der Teufel im Detail liegt und man Windows eigentlich in vielen Industriebereich nicht einsetzen kann!
Windows XP in Produktionsmaschinen
Leider gibt es die fatale Tendenz, dass Entwickler von Maschinen auf die Idee gekommen sind, Windows zur Überwachung und Steuerung zu verwenden. Immer wenn eine Windows-Version ihr End of Life erreicht, laufen die Maschinenbesitzer in ein Problem. Eine Maschine, die hunderttausende von Euro gekostet hat, ersetzt man nicht, weil ein Windows keinen Support mehr bekommt.
Im aktuellen Fall schrieb mir der Blog-Leser, dass im Unternehmen leider noch mehrere Windows-XP Clients in Produktionsmaschinen eingesetzt werden. Bei diesen Produktionsmaschinen (Fremdfabrikate) ist ein Austausch/Update des Clients teilweise nicht supported (Produktionssoftware) oder gar nicht möglich. Der Austausch des Clients bedeutet somit Neuanschaffung der Maschine, was aufgrund der sehr hohen Investitionssummen von der Unternehmensleitung meist abgelehnt wird. Andererseits sind einige der Maschinen im Unternehmen des Leser auch noch produktionsrelevant, was das Ganze nicht besser macht.
An den Gegebenheiten lässt sich nichts ändern. Die IT hat diese Windows XP-Maschinen in den Produktionsmaschinen entsprechend vom Netzwerk/Internet isoliert, wie der Leser auf Nachfrage schreibt:
Anzeige
Die Maschinen sind in einem separaten VLAN im Netzwerk und prinzipiell nicht vom Internet erreichbar. Wie ein normaler Verwaltungs-PC jedoch eben in einem separaten Netzwerk.
Aus sicherheitstechnischer Sicht besteht daher in meinen Augen kein Anlass, die Clients stillzulegen. Allerdings laufen die Betreiber einer solchen Konstellation in ein anderes Problem: Sobald Microsoft etwas am Netzwerk ändert, wird es Kommunikationsprobleme geben.
Domain-Join scheitert seit November 2022
Im November 2022 hat Microsoft aus Sicherheitsgründen Änderungen am Netlogon- und Kerberos-Protokoll vorgenommen (siehe November 2022-Updates für Windows: Änderungen am Netlogon- und Kerberos-Protokoll). Das betrifft die als Domain Controller (DC) fungierenden Windows Server-Systeme. Und hier laufen die Produktionsmaschinen mit Windows XP des Blog-Lesers in Probleme, weil der Domain Join nicht mehr klappt. In der Umgebung wird offenbar ein Windows Server 2016 als Domain Controller verwendet, der dann im November 2022 das (Problem-)Update KB5019964 erhalten hat. Der Blog-Leser schreibt:
Nach der Installation des November-Patches (kb5019964) sind wir nicht mehr in der Lage Windows-XP Clients in die Domain zu joinen und auch weitere Nebeneffekte sind schon aufgefallen.
- So kann bspw. in einem Loginscript auf dem XP-Client der "UserName" und "ComputerName" mittels einem vbs-Script nicht mehr von der Domain abgefragt werden.
- Hauptproblem für uns stellt jedoch der nicht mehr funktionierende Domain-Join dar.
Ebenfalls die Fragestellung "Warum muss dieser XP-Client in die Domain?" wird sicherlich nochmals aufkommen, aber derzeit sind die Maschinen und die Programme einfach so gestrickt, dass der Domain-Join zwingend notwendig ist. Auf gut Deutsch: Ich habe keine andere Wahl und muss nach einem Workaround suchen.
Der Blog-Leser hat das Ganze mal in einer Testumgebung nachgebaut. Im Testszenario ist aber alles virtuell und im selben Netzwerk, ohne Firewall usw. Aber es ist alles Standard in der Netzwerk-Konfiguration. Auch in dieser virtualisierten Testumgebung ist nach dem November 2022-Update kein Domain-Join mehr möglich.
Der Blog-Leser fragt, ob einer aus der Leserschaft dieses Problem in seiner Umgebung ebenfalls hat und vielleicht auf einen Workaround gestoßen ist. Ich bin skeptisch, dass es eine Lösung gibt, denn die Sicherheitsupdates vom November 2022 mussten ja auf den Servern und den Clients installiert werden. Dabei hat Windows XP ja kein Sicherheitsupdate mehr bekommen. Das wird in der FAQ zu diesem Microsoft Artikel bestätigt.
Komischerweise findet sich bei Microsoft dieser Post mit diversen Hinweisen, der angibt, dass eine Windows XP-Maschine, die bereits in der Domäne eingegliedert ist, weiterhin funktioniert. Das geht auch mit meinem Verständnis des Microsoft Support-Artikels KB5020276—Netjoin: Domain join hardening changes einher, der die Härtung für neue Domain Joins beschreibt.
Mir selbst ist bisher kein solcher Fall untergekommen, aber ich denke, es müssen einige Administratoren betroffen sein. Auf spiceworks gibt es diese Diskussion, wo letztendlich bestätigt wird, dass das Domain Join für Windows XP kaputt ist. Falls jemand eine Lösung kennt, bitte als Kommentar skizzieren.
Ergänzung: Wenn ich nicht gänzlich falsch interpretiere, hat Frank Carius in diesem Beitrag ebenfalls einige Tipps für temporäre Workarounds veröffentlicht.
Eine Bitte: Wer nichts zur Lösung oder zum Workaround beitragen kann oder will, möge sich der Kommentierung enthalten. Ich werden alle Kommentare, die sich zum Thema "Windows XP ist aus dem Support" äußern, schlicht löschen.
Ähnliche Artikel:
Microsoft Security Update Summary (8. November 2022)
Patchday: Windows 10-Updates (8. November 2022)
Patchday: Windows 11/Server 2022-Updates (8. November 2022)
Windows 7/Server 2008 R2; Windows 8.1/Server 2012 R2: Updates (8. November 2022)
November 2022-Updates für Windows: Änderungen am Netlogon- und Kerberos-Protokoll
Microsoft bestätigt Direct Access-Probleme nach Nov. 2022 Updates
DirectAccess funktioniert nach November 2022 Windows Updates nicht mehr
Windows Server November 2022-Updates verursachen LSASS-Memory Leak
Anzeige
Bei uns gibt es auch noch 2003 und da mussten wir den msDS-supportedEncryptionTypes auf RC4_HMAC_MD5 zurückstufen. Auch für Netlogon New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Netlogon\Parameters" -Name RequireSeal -Value 1 -PropertyType DWORD –Force für den Kompatibilitätsmodus.
Anschliessend mussten noch anfällige alte Kerberostickets gekillt werden.
Auf der msxfaq ist seit gestern noch ein guter Artikel geschaltet, was noch kommt dieses Jahr
Parallität der Ereignisse, ich hatte es die Woche auf Twitter gesehen und mir aufgehoben. Sonntag kommt noch ein kurzer Artikel mit einem Hinweis, was Frank Carius da zusammen getragen hat (steckt bereits in der Konserve).
Vielleicht hat es auch was mit den Änderungen am Kerberos Protokoll zu tun. Hier wird es zukünftig Probleme geben:
„Unsupported versions of Windows includes Windows XP, Windows Server 2003, Windows Server 2008 SP2, and Windows Server 2008 R2 SP1 cannot be accessed by updated Windows devices unless you have an ESU license. If you have an ESU license, you will need to install updates released on or after November 8, 2022 and verify your configuration has a common Encryption type available between all devices."
https://support.microsoft.com/en-us/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d
Die Vorschläge von Tom801 sind gut, unbedingt ausprobieren. Ich habe aber noch zwei Ideen mehr. Vielleicht kann man mal ausprobieren, ob man den XP-Maschinen für ihren Standort einen Linux-Rechner mit SMBV4 als DC in die Domäne heben kann, vielleicht kann ein SMBV4-DC als Brücke in die Domäne benutzt werden. Oder man zieht für die XP-Maschinen eine eigene Domäne hoch, die man mit zwei DCs auf Basis Server 2016/2019 betreibt, die man nur mit den Updates bis Oktober 2022 bestückt und dann die Updates ausschaltet, Das ganze natürlich per Firewall gut isoliert vom Rest der Umgebung, vielleicht kann man auch noch einen Domain-Trust aufbauen, vielleicht reicht ja sogar ein einseitiger Trust, je nach dem ob Accounts aus der "XP-Domäne" Daten von der "Nach-November-Domäne" Daten abholen müssen, oder umgekehrt.
Wenn man ganz genau weiß was man tut, und die Altsysteme nicht aufs Internet zugreifen müssen, keine von extern erreichbaren Mailaccounts abfragen müssen, usw., dann kann man sowas durchaus tun. Ich weiß auch von einer ganz wichtigen Logistik-Infrastruktur mit riesigen Hochregalsteuerungen, die unter XP/2003 läuft, ohne die wir alle verhungern würden…
Hi Ihr, na gottseidank haben wir jetzt endlich eine Arbeitsbasis, bei der man sich für rückwärtskompatible Unsicherheit mal ein Bisschen mit Details beschäftigen muss. Schon bei der Überschrift dachte ich an RC4, das Schreckgespenst der letzten Wochen :)
Ich habe vorgestern mit einem 13 Jahre alten Netbook gekämpft, der wollte keinen an meinem Win10 "Server" freigegebenen Druckern verbinden, da wars es:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\RpcAuthnLevelPrivacyEnabledDWORD=0h
Das Netbook mit Atom N450 CPU läuft noch mit Win 7 und da ist das dann natürlich auch ein Problem. Vielleicht installiere ich mal Esubypass um das Ding auf den letzten Stand zu bringen. Wo bekomme ich das?
Gefunden…
Eventuell geht auch einen UCS (Univention Corporate Server) also weiteren DC hinzuzufügen und den sozusagen vor die XP-Maschinen zu hängen. Ist aber soviel ich im Kopf hab nur bis Domainlevel 2008R2 möglich.
Auf 2 Domain Member Server 2003 die seit November 2022 keine Laufwerke im Login Script mappen wollten, habe ich der Server Name mit der IP Adresse ersetzt. Dann ging es wieder "normal"…
Bei der IP Adresse kommt es zu einem fallback auf NTLM, da dir IP nicht genügend Informationen für Kerberos liefert
leider kann man das nicht für den netlogon oder Joindomain erzwingen
Dann macht er kein Kerberos sondern ntlm weil er keinen SPN findet
Warum bekommen es dann die Produktionsmaschinenhersteller, die es ja im Prinzip verbockt haben, nicht auf die Reihe Kleinstserver auf Linuxbasis passend für ihre Maschinen zu entwickeln die eben genau diese Probleme beheben? Die Maschine kommuniziert mit dem Server und der mit der Infrastruktur des Unternehmens. Allein die Hersteller kennen die Bedürfnisse ihrer Produktionssoftware genau.
Ok es wäre besser wenn man von der Unsitte abkäme Windows für Maschinen zu verwenden die länger als eine Windowsversion nutzbar sein sollen.
Es gibt au meiner Sicht eine einfache Antwort: Weil inzwischen überall Informatiker (oder Betriebswirte) sitzen, die bestimmte Sachen für alternativlos halten und dann nicken, wenn die Hersteller ihre Maschinen mit Windows-Rechnern ausstatten.
Es ist verdammt lange her – vor 29 Jahren habe ich den Exit in der Industrie gemacht, um als frei fliegender Künstler meinem Hobby nachzugehen, und den Leuten "Combuder-Teknik beizubiegen". Vorher habe ich als Ing. im Bereich Regeln, Steuern, Automatisieren, Prozessdatenerfassung in der Großchemie Software entwickeln lassen und auch Projekte geleitet. Damals war es immer ein Kampf mit den Informatikern und auch den Anwendern sowie Automatisierungsfachleuten, denen die Systeme mit Windows auszureden. Es hieß "Born ist Bedenkenträger", die Hersteller bieten doch diesen schönen PC, der das alles billig kann. Bei uns im Unternehmen sind die Informatiker dankend auf den Zug aufgesprungen (da können wir neue Arbeitsgebiete vereinnahmen). Und die Informatiker bei den Herstellern hatten auch keinen Draht zu den Bedenken, die ich äußerte ("wieso, machen doch alle, und ist so schön einfach"). Die kamen höchstens und fragten, wie sie dieses und jenes (z.B. PID-Regeler) als Software implementieren müssen, damit es arbeitet.
Grundproblem aus meiner Sicht (ich habe sowohl ein Ingenieur-Studium als auch eine Reihe Semester Informatik-Studium absolviert, kenne also die Denke auf beiden Seiten) ist, dass alte Ingenieurstugenden, Produkte auch von der Wartung und von der Lebensdauer als Ganzes zu begreifen, zu entwerfen und zu implementieren, heute verloren gegangen sind bzw. in der Informatik nie vorhanden waren ("ich kann zur Not den Fehler ja schnell durch Neukompilieren ausmerzen").
Ich hatte das mal grob im Beitrag 60 Jahre Software-Entwicklung: Ein Alptraum, der mit grottiger Qualität und im Chaos endet angerissen. Unter dem Strich: Wenn ich in der Industrie geblieben wäre, hätte ich meinen Kampf gegen Windmühlen elendiglich verloren (obwohl ich irgendwann mit großen Kuhaugen feststellen durfte, das die von mir in den achtziger Jahren, bis 1993 konzipierten Softwarearchitekturen mindestens 20 Jahrzehnte überdauert haben und immer noch als solide auf "PCs mit Windows" eingesetzt wurden). Heute sehen wir, wie das den Leuten (nicht nur) in der Produktion immer häufiger auf die Füße fällt. Allerdings kann ich es nicht als Genugtuung empfinden, dass ich am Ende des Tages Recht behalten habe – denn die Ergebnisse sind viel zu traurig.
>>> Allerdings kann ich es nicht als Genugtuung empfinden, dass ich am Ende des Tages Recht behalten habe – denn die Ergebnisse sind viel zu traurig.
Letztlich ist das kein Problem der Software-Entwicklung, sondern gesamtgesellschaftlich/zivilisatorisch praktisch überall zu beobachten. Insbesondere die Menschen in den Wohlstandsnationen verlernen mit Lichtgeschwindigkeit elementare Grundprinzipien biologischer Existenz.
Ein anderer Punkt, welcher mich auch regelmäßig auf die Plame bringt:
Serielle Übertragung differenzieller Signale mit hoher Geschwindigkeit wird physikalisch gut verstanden und ist technisch inzwischen auch problemlos handlebar.
Stecker wie SATA, USB oder Lightning zeigen daß man das stabil, halbwegs DAU-kompatibel und auch billig hinkriegt.
WARUM ZUM GEIER mußte man ausgerechnet beim Ethernet an einen über 50 Jahre alten Stecker, der ursprünglich nur zum Anschließen von analogen Telefonen gedacht war, immer weiter festhalten und auch heute noch verwenden?
ISDN OK, gut – auch noch 10 Mbit oder 100, aber wenn man sich anschaut was für abartige Schirmkonstruktionen heute verkauft werden, um 1, 2,5 oder auch 10 GBit über diese Krücke zu transportieren und halbwegs eine CAT.7 oder 8 einhalten zu können, geht mir regelmäßig die Hutschnur hoch.
Krönung ist, daß man z.T. auch versucht Glasfasern in dieses Format zu pressen -MT-RJ.
Dabei gibt es im Industriebereich gute Stecker für Ethernet, rund, mit Bajonett oder Überwurfmutter, knickfest usw, es verwendet sie nur keiner.
👍 +1
Und das absolut Interessante an der ganzen Sache ist, dass die (also auch wir) die in den sog. "Wohlstandsnationen" leben, sich immer so dermaßen supertoll finden und sich überlegen vorkommen – und gleichzeitig immer weniger merken, dass sie kontinuierlich den Ast absägen, auf dem sie alle sitzen … Anstatt ein gemeinsames "Wir" an den Tag zu legen, immer mehr nur noch "Ich" und vor allem "Wir gegen Die" …
Die ganze(n) Entwicklung(en) in der IT/digitalen Welt, sind da nur ein Auswuchs unter vielen Dingen, wo man sehr oft immer nur "so weit denkt, wie eine fettes Schwein springen kann". Unter dem Strich betrachtet, hat uns die ganze Digitalisierung mit gefühlter (beweisen kann ich es natürlich nicht) Sicherheit nicht weniger, sondern eher mehr Probleme gebracht. Evtl. halten sich positive und negative Erscheinungen auch gerade noch die Waage (?) Alleine schon die ganze "Verwirrung" bzgl. der Vielfalt, Breite und Tiefe der Anwendungen. Wer hat da noch den Überblick über "sinnvoll, oder nicht"? PC, Laptop, Smartphone … App hier und App da … Und jede App schreit dich an: "Du brauchst mich unbedingt!!" Wie viele Menschen (so ca. ab 45 +, aber auch – und oft auch gerade – Jüngere) leiden inzwischen unter der angeblichen "digitalen Vereinfachung", die oftmals dann doch alles mehr verkompliziert (hat) als zuvor?! Habe viele (natürlich nicht alle, aber doch überproportional viele) Senioren/Seniorinnen in der Verwandtschaft, die nur noch die Hände über dem Kopf zusammenschlagen und genervt abwinken … Und dann haben wir noch nicht von den diversen "Fehlern" in der IT gesprochen, die ja immer öfters auch das öffentlich-gesellschaftliche Leben u. U. fast komplett außer Gefecht setzen können. Einen echten Super-Gau hatten wir bisher zwar noch nicht, aber das was so alles bisher aufgetreten ist, reicht schon als "netter" Vorgeschmack, wie ich finde …
Das Problem ist NICHT die "Informatik"; es sind die Trottel, die in ihre für eine Lebensdauer von mehr als 10 Jahren konzipierten Maschinen Teile/Komponenten (hier: PCs mit Windows) einbauen, ohne die (vorher bekannte) Lebensdauer dieser zugelieferten Teile/Komponenten zu berücksichtigen, bzw. keine Wartungsverträge über die konzipierte Lebensdauer mit den Zulieferern abschliessen.
Dieses Problem wird auch immer größer, wenn man sich z.B. die ganze Home-Automation/IOT-Sache ansieht, alles geht übers Smartphone oder Tablet, aber was ist wenn eines Tages ein OS-Update kommt, oder ein neues Smartphone, mit dem die zugehörige App nicht mehr kompatibel ist. Und da denke ich auch an PKWs, die mit einer App verbunden sind.
Das! Exemplarisch: Ich habe gerade mein neues Scheunentor a.k.a. Solar-Wechselrichter gepatcht, der vorher nur ein fixes admin/12345678 kannte – und von außen in der Wifi-Range als AP unabstellbar zugreifbar war. Software made in 2022! Dass die WRs nach China funken, wenn man die in der Fritzbox nicht abkneift – was soll's. Aber das nächste Scriptkiddie wartet doch nur auf den Leak von "hoppla, in China ist ein Sack Reis umgefallen, äh, eine Datenbank mit WR-Daten abhanden gekommen". Und da gibt es keine DSGVO. Wieder neue Zombies für DDoS.
Sorry, es wurde dann doch OT. Mein Rant kann gelöscht werden :D
Es gibt aber auch viele strukturelle Probleme. Ich habe es auch schon mehrfach erlebt, dass Großmaschinen für hunderttausende Euros gekauft werden, ohne je vernünftig sich mit IT Entscheider auseinander zu setzen. Denn dir, solang Sie irgendwie bei Verstand sind, prüfen und beraten da schon lange hin, das wenn PC/Win eingesetzt wird, dies Modular und Austauschbar gestaltet wird.
Dann dürfte man Windows gar nicht mehr als Unterbau nehmen.
CNC-Maschinen laufen i.d.R. 10-20 Jahre, selbst mehr als 30 Jahre sind keine Seltenheit.
Maschinen werden so lange betrieben, wie ihr Betrieb noch wirtschaftlich ist.
Natürlich könnte man theoretisch eine neuere Windows-Version installieren, aber hat die Steuerung überhaupt die Hardware-Mindestanforderung der neuen Windows-Version?
Gibt es für die neuere Windows-Version überhaupt Treiber für die in der Steuerung verbaute Hardware?
Läuft die Steuerungssoftware überhaupt auf der neuen Windows-Version?
I.d.R. kann man alle 3 Fragen mit nein beantworten.
Und genau deshalb fasst man die Software einer Maschinensteuerung nicht an.
Und auch aus organisatorischer und sicherheitstechnischer Sicht gehören das Netzwerk für die Maschinensteuerungen etc. und die für die Verwaltung etc. getrennt.
Und dann hat man auch 2 getrennte Domänen und das Problem stellt sich nicht wirklich.
Und was die Kunden angeht:
Was für ein Betriebsystemunterbau eine Maschinensteuerung verwendet, weiß nicht einmal der Maschinenhersteller, denn die Maschinensteuerung wird i.d.R. zugekauft (z.B. von Siemens, Indramat, etc.). Der Betriebssystemunterbau wird von den Herstellern der Maschinensteuerungen gar nicht publiziert.
Ergo hat weder der Maschinenhersteller noch der Maschinenkunde eine Wahlmöglichkeit.
Ob es Windows oder Linux ist ändert nichts an der Sache, dass das jeweilige Betriebssystem weiterhin mit Updates versorgt werden muss, um mit aktuellen Servern kommunizieren zu können.
Auch Linux Distributionen sind einmal EOL.
Wir machen auch SPS Steuerungssysteme und unsere Visualisierungen (SCADA) laufen alle auf Windows PCs. Das würde ich so also nicht unterschreiben, dass Windows für solche Anwendungszwecke nicht geeignet ist.
Allerdings liefern wir auch heute noch PCs für Anlagen mit Windows 11 und einem aktualisierten SCADA System aus, welche vor 25 Jahren mit Windows 98 in Betrieb gingen.
Das bedeutet, der Hersteller muss seine Software eben einfach warten und auch immer auf den aktuellen Betriebssystemen zum Laufen bekommen.
Es gibt ja auch eigene Windows Versionen, welche extra lange mit Updates versorgt werden, z.B. Windows 10 IoT Enterprise mit über 10 Jahren.
Wobei ich mich auch frage, ob es überhaupt notwendig ist den PC einer Produktionsmaschine in die Domäne einzubinden.
"Wobei ich mich auch frage, ob es überhaupt notwendig ist den PC einer Produktionsmaschine in die Domäne einzubinden."
Genau!
Nächste Frage: wird das (oder auch nur der Datenaustausch via SMB bzw. TLS) vom Hersteller der Produktionsmaschine denn explizit unterstützt, d.h. ist das eine in Angebot/Produktbeschreibung/Handbuch zugesicherte Eigenschaft?
Falls ja, dann hat der Kunde/Käufer ein Recht auf Nachbesserung bzw. Fehlerbehebung!
Die XP Maschinen zusammen mit einem DC auf einem alten Patchlevel in einer DMZ/VLAN stecken. Entweder eigene Domain oder eben nur Verbindung zu einem DC im restlichen Netzwerk.
Genauso haben wir es auch gelöst.
Kern dieses Legacy-Netzes ist ein Windows 2000-DC, der SMB und IPX spricht und an den sich die verschiedensten Systeme (SMB Client for DOS, anyone? 🤣) verbinden.
Das Austauschen von Fertigungsdaten, Prüfprogrammen und die zentrale Akkumulation der Prüfprotokolle übernimmt der und die Daten (nur die) werden dann (natürlich durch eine HW-Firewall mit entsprechend straffen Regeln) ans "aktuelle" Netz weitergegeben.
Tut für DOS, Novell, Windows 97 – 7, Windows CE und nicht zu vergessen diverse steinalte embedded Linux-Varianten.
Unsere Entwickler mußten sich zähneknirschend von der Idee verabschieden, ihre Prüfprogramme direkt von der Maschine ins GitHub zu pushen, aber als ich dann mal vorgeschlagen habe sie sollen doch die aktuellen Mozilla-Quellen mit TLS1.2-Support auf der Windows95-Maschine kompilieren war plötzlich Ruhe 😎
Ich weiß es steht im Text, aber das ist zu 100% ein Fehler in der Sicherheitsstruktur, solche Clients in die selbe Domäne zu joinen wie die üblichen Büro Verwaltungscomputer, man kann so etwas dann nicht mehr sicher betreiben. Da hilft einem die Trennung vom Internetzugriff und Segmentierung genau gar nix mehr – die einzige Möglichkeit wäre hier eine eigene Verwaltungsdomäne für die Produktion aufzusetzen die KEINE Verbindung zur "Büro" Domäne hat.
Die Remote Assistance, auch ein Tool aus XP Zeiten, ist leider mit dem letzten Kerberos Update im Novemeber auch kaputt gegangen. Remote Assistance setzt scheinbar nur auf DES und RC4 (forder etypes 23 3 1 an). Wenn die Domänen kein RC4 erlaubt (zB durch Härtungsmaßnahmen, wie zB in manchen Sec Baselines vorgeschlagen), dann schlägt der Zugriff nun seit November fehl – vorher hat's wohl trotz Härtung irgendwie doch geklappt mit dem Tool. (in gehärteten Umgebungen sind folgende etypes verfügbar: 18 17)
Schade das Tool war super für den 1st Level Support, und war in Windows integriert und kostenlos. Habe da keine großen Hoffnungen, dass MS hier auch Mal ein Update liefert, das die aktuellen Kerberos etypes unterstützen wird.
Remoteassistant haben wir auch viel eingesetzt, bis dann jeder Teams hatte…
Stimmt Teams hat so etwas auch, ist halt nur mühsam in Umgebungen wo das nicht jeder einsetzt/einsetzen kann.
Wir haben dafür eine seperate Domain VLAN mit quasi dmz im LAN mit jumpserver und wsus gemacht. der wsus stand wird eingefroren pro os was noch kompatibel ist. so kann man nochmal ein Austausch hmi oder Image auf den gleichen Stand patchen. Nachteil ist nur das man die User einmalig doppelt anlegen muss und aus User Sicht die Passwörter nicht im sync sind. über einen Fileserver mit 2 Netzwerk Karten gibt es noch ein Transfer für Reports in das Office Netzwerk.
Deine Behauptung "… Ingenieurstugenden, Produkte auch von der Wartung und von der Lebensdauer als Ganzes zu begreifen, zu entwerfen und zu implementieren, heute verloren gegangen sind bzw. in der Informatik nie vorhanden waren …" ist glücklicherweise blühender BLÖDSINN: "Software Engineering" wird seit 50 Jahren von jedem nicht völlig verblödeten Informatiker betrieben.
Es gibt dazu eine Gruppenrichtlinie, mit der man den Zugriff von XP-Maschinen erlauben kann. Unter Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien/Sicherheitsoptionen -> Andere gibt es den Punkt "Domänencontroller: Sichere Verbindungen mit verwundbaren Kanäle über den Anmeldedienst (Netlogon) zulassen". Da trägt man die gewünschten XP-Maschinen ein. Ob man das möchte, muss jeder für sich selber beurteilen und verantworten.
Für XP wie hier diskutiert gibt es sicherlich einige Workarrounds die man umsetzen kann, aber wie sieht es mit großen Archiv- oder alten ERP-Systemen aus, die auf älteren OS-Versionen laufen und zwingend noch viele Jahre gesetzlich noch vorgehalten werden müssen, inkl. Online- bzw. Domänenzugriff ?
Gesetzlich Vorhalten heißt aber nicht, das diese Systeme aktiv laufen müssen.
Man kann die Systeme auch still legen und die Maschinen abbauen und in den Keller stellen.
Man muß sie nur funktionsfähig wieder in Betrieb nehmen können.
nun ja, und wenn sie dann wieder hochgefahren werden müssen und keine Anmeldung mehr möglich ist ?
Und Computeraccounts fliegen ja auch nach XX Tagen aus der Domäne…..
ich hab leider noch 2 XP-Kisten.
Geholfen hat:
aus dem AD löschen
DNS-Einträge löschen
neu joinen
Hat jemand für das Problem schon eine händelbare Lösung gefunden?In meiner Testumgebung bekomme ich beim DomainJoin von Windows XP Maschinen immer einen Internal Error, ein Objekt wird zwar im AD angelegt, aber direkt auch deaktiviert.
Das Setzen einer GPO auf allen DCs ( Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien/Sicherheitsoptionen -> Andere –> "Domänencontroller: Sichere Verbindungen mit verwundbaren Kanäle über den Anmeldedienst (Netlogon) zulassen") hat auch keine Abhilfe geschaffen…
War jemand demnach schon mit neuem Security Patchlevel der DCS erfolgreich eine Windows XP Maschine in die Domäne zu joinen?
Hallo Zusammen, ja es gibt eine Lösung – zumindest hat es bei mir geklappt. Mein Testszenario: Windows Server 2022 als DC und Windows XP SP3 32-Bit als Client in einer HyperV-Maschine. Fündig geworden bin ich auf einer asiatischen Seite:
https://eqaz1.blogspot.com/2020/12/adds-win-xp-windows-server-2019-ad.html
Demnach muss folgende GPO gesetzt werden:
Computerkonfiguration – Windows-Einstellungen – Sicherheitseinstellungen – Lokale Richtlinien – Sicherheitsoptionen – Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren
Hier alles außer AES128 und AES256 auswählen.
Hallo Casalla,
mit dieser Einstellung aktivierst du zwar RC4 wieder, aber du deaktivierst auch AES128 und AES256 damit. Wir hatten das in einer Testumgebung ebenfalls versucht, dort ging der Domain-Join dann wieder problemlos.
Nachdem wir diese Policy aber in der Produktionsumgebung aktiviert haben, hatten diverse Win10 und andere "aktuelle" Geräte Probleme, da diese nicht mehr mit AES verschlüsseln konnten. Fehlgeschlagene Anmeldungen, fehlenden Policies, usw. waren die Auswirkung. Wir haben diese Änderung dann wieder rückgängig gemacht. Also bitte vorsichtig sein wenn du dies wirklich aktivieren willst. Ebenfalls bleiben die Einstellung trotz deaktivierter GPOs erstmals hängen, d.h. du musst die Settings in den Registry-Keys löschen. Für uns war das kein Workaround.
Hallo Erazerme,
das Problem kann ich bestätigen/habe ich jetzt auch.
Kannst Du bitte schildern, welche Settings Du in welchen Registry-Keys konkret löschen musstest?
Backup sei Dank:
es muss der Registrypfad [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\kerberos\parameters]
gelöscht werden…
Mein Workaround war beim Rejoin von 2 XP Maschinen, diesen zuerst einen anderen Hostnamen mit neuem AD Konto zu geben und damit wieder in die Domäne aufzunehmen. Anschließend konnte ich die Rechner nach einem erneuten aus der Domäne nehmen, wieder mit dem ursprünglichen Hostnamen und AD Konto ebenso wieder in die DOM aufnehmen. Evtl. geht das in Richtung von dem Beschriebenen Workaround von Kerbel3rd.
Zunächst einmal:
ja, auch wir haben sowohl Maschinen wie Fräsen (sogar noch unter Win2000) im Netz, als auch 'eingefrorene' Entwicklungsumgebungen als VM mit (notwendigerweise!) Windows XP als Betriebssystem … im Netzwerk.
Ich hatte gerade eine funktionierende WinXP VM von VMware nach VirtualBox migrieren wollen und bin genau über das geschilderte Problem gestoplert (in einer – noch – Win2012r2 Domäne).
Die einfache Prozedur von Kerbel3rd, bzw. Matze hat nicht zum Erfolg geführt, wohl aber das für den Domainjoin kurzzeitige setzen der GPO, wie Casalla beschrieben hat.
Tausend Dank dafür!
Die Frage ist, ob dieses Verfahren bzw. die vorhandenen Domänenmitgliedschaften der WindowsXP Maschinen die kurz bevorstehende Migration nach Server 2022 überlebt…
hallo ich habe eine Testumgebung für das Thema.
Das oben erwähnte Setzten von RC4/DES hat bisher noch geholfen.
nun habe ich die updates von 4/23 8/23 hochgezogen.
Nun können sich XP Clients nicht mehr am AD anmelden.
"Domäne oder Computerconto nicht verfügbar"
Join geht auch nicht mehr
Server 2003 geht aber noch.
Hängt das am PAC Sealing ?
Gibt es da schon "workaraound" ( ausser vintage.subdomain oder Arbeitsgruppe)
(jaja wir sind ein Industreibetrieb und z.b. eine XP Vm mit einem 16 bit "ASCII" program mit der eine NT4.0 Maschiene gefüttert wird, ja die system sind offline, nur RDP. und ja ich habe auch noch 2003er Server VMs und W2K Hardware am laufen…..)
Hallo,
ich hatte ebenfalls das Vergnügen, mit alten XP Maschine arbeiten zu dürfen, welche natürlich hoch kritisch für die Produktion sind.
Meine Aufgabe war es nun, diese umzubenennen.
Leider konnte ich sie nicht umbenennen und habe daher versucht, sie aus der Domäne zu nehmen, umzubenennen und dann wieder in die Domäne aufzunehmen.
Der erste Part hat auch einwandfrei geklappt, nur beim wieder in die Domäne aufnehmen bin ich dann auf das Problem gestoßen.
Ich habe nach langem rumprobieren und einen Workaround gefunden, der zwar alles andere als sauber ist, aber jetzt sind die Rechner wieder in der Domäne und ich kann mich mit neuen Domänen Usern daran anmelden.
Beim versuchen ist mir aufgefallen, dass ich den Rechner in die Domäne aufnehmen kann, wenn ich ihn gleichzeitig umbenenne. Im ersten Moment hat mich das auch gefreut, bis ich gesehen habe, dass der Rechner unter seinem alten Namen in die Domäne aufgenommen wurde aber local den neuen Namen hat.
Nun habe ich folgende "Lösung" gefunden, um das zu verhindern.
1. Erstelle eine Dummy-Computer Konto. Nennen wir es "Dummy-PC01"
2. Füge deinen PC der Domäne hinzu und benennen ihn gleichzeitig um in "Dummy-PC01"
Nun wird der PC der Domäne hinzugefügt, aber das umbenennen wird abgelehnt, da es bereits ein solches Computer-Konto in der Domäne gibt.
Jetzt sollte der Rechner in die Domäne aufgenommen sein und die Namen sollten übereinstimmen.
Aber Achtung, es gibt noch zwei Dinge zu beachten:
1. Einige Attribute werden nicht mehr automatisch ausgefüllt. Bisher habe ich die Attribute "dNSHostName" & "servicePrincipalName" entdeckt, welche ich händisch nachpflegen musste. (Falls ihr noch andere Attribute findet, lasst es mich gerne wissen.
2. Wenn man sich nun diesem Rechner mit einem Domänen Benutzer anmelden will, kann es bei einigen Rechner vorkommen, dass das Drop-Down-Menü für die Domäne ewig lädt. Um dieses Problem zu umgehen, drückt man einmal kurz den Ausknopf. Dann kann er die Domänen-liste auf einmal anzeigen. Nun melde dich mit einem Domänen-Benutzer an. Direkt nach der Anmeldung wird der Rechner zwar runtergefahren, aber beim wieder hochfahren ist die Domäne dann vorausgewählt.
Mit dieser Methode konnte ich nun 9/10 XP Rechner in meiner Domäne umbenennen (aus der Domäne schmeißen und wieder aufnehmen), wobei bei einem Rechner die Methode nicht auf anhieb funktioniert hat. Beim zweiten mal in die Domäne aufnehmen hat es jedoch geklappt, trotz dass ich exakt das gleiche gemacht habe. Bei 4 dieser 10 Rechner ist das Problem mit der Domänen Drop-Downliste aufgetreten. Bei jedem musste ich die oben genannten Attribute händisch eintragen.
Ich hoffe ich konnte hiermit helfen.
VG
Lex