19
NPS - WLAN Verbindung nach Update nicht mehr möglich
Ich habe hier eine WLAN Verbindung über Computerzertifikate. Seit einem Windows Update erhalte ich den Fehler 6273 "Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch."
Ob das Update mit dem Fehler zusammenhängt bin ich mir nicht sicher. Die Zugangsdaten stimmen, das Client Zertifikat sowie das Computerzertifikat auf dem NPS Server ist ebenfalls noch gültig.
Im Internet habe ich schon den ein oder anderen Tipp gefunden. Unteranderem auf dem NPS den Registry Key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList" oder "SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\DisableEndEntityClientCertCheck" zu setzen was auch nicht zum Erfolg geführt hat. Ich habe auch mal die abgelaufenen Stammzertifikate gelöscht. Aber auch das hat noch nicht zu einem Erfolg geführt.
Hat da vielleicht jemand eine Idee für mich?
Ob das Update mit dem Fehler zusammenhängt bin ich mir nicht sicher. Die Zugangsdaten stimmen, das Client Zertifikat sowie das Computerzertifikat auf dem NPS Server ist ebenfalls noch gültig.
Im Internet habe ich schon den ein oder anderen Tipp gefunden. Unteranderem auf dem NPS den Registry Key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList" oder "SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\DisableEndEntityClientCertCheck" zu setzen was auch nicht zum Erfolg geführt hat. Ich habe auch mal die abgelaufenen Stammzertifikate gelöscht. Aber auch das hat noch nicht zu einem Erfolg geführt.
Hat da vielleicht jemand eine Idee für mich?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2748916037
Url: https://administrator.de/contentid/2748916037
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
19 Kommentare
Neuester Kommentar
Servus,
überprüfe penibel folgende Informationen im Eventlog des NPS in der Message:
Wenn die Infos hier nicht mit dem AD stimmen und der Computer tatsächlich noch existiert und dessen Computer-Passwort nicht abgelaufen ist, dann ist evt. die Verbindung zum DC gestört. Alternativ könnte es auch Probleme beim Beschreiben des NPS Logs gegeben haben denn dann lehnt NPS per Default Authentifizierungs-Anfragen ab.
Wenn im Security Eventlog keine NPS infos geloggt werden schalte sie ein unter
Oder mittels Konsole
Grüße Uwe
überprüfe penibel folgende Informationen im Eventlog des NPS in der Message:
Benutzer:
Sicherheits-ID: *******
Kontoname: ******
Kontodomäne: *****
Vollqualifizierter Kontoname: ******Wenn im Security Eventlog keine NPS infos geloggt werden schalte sie ein unter
Oder mittels Konsole
auditpol /set /subcategory:"Netzwerkrichtlinienserver" /success:enable /failure:enable Grüße Uwe
Danke für deine Antwort
Die Daten sind identisch mit den Daten der letzten Tage an denen es funktioniert hat.
Das Kennwort des Benutzers ist nicht abgelaufen. Es betrifft allgemein alle Benutzer.
Die Verbindung zum DC kann ich mir nicht vorstellen, da der NPS auf dem DC installiert ist und die Logs ja auch entsprechend erscheinen.
Ist eingeschaltet
überprüfe penibel folgende Informationen im Eventlog des NPS in der Message
Wenn die Infos hier nicht mit dem AD stimmen und der Computer tatsächlich noch existiert und dessen Computer->>Passwort nicht abgelaufen ist, dann ist evt. die Verbindung zum DC gestört.
Die Verbindung zum DC kann ich mir nicht vorstellen, da der NPS auf dem DC installiert ist und die Logs ja auch entsprechend erscheinen.
Wenn im Security Eventlog keine NPS infos geloggt werden schalte sie ein unter
Das meinte ich nicht, ich meinte ich das der Computer evt. seine Vertrauensstellung verloren hat. Du machst ja eine Computer-Auth.
Es betrifft allgemein alle Benutzer.
Nur an einem Computer oder auch auf anderen Computern? Du sagst ja das du eine Computer Authentifizerung machst da ist der "User" ja nicht von Belang, da diese unabhängig vom User stattfindet!Die Verbindung zum DC kann ich mir nicht vorstellen, da der NPS auf dem DC installiert ist und die Logs ja auch entsprechend erscheinen.
Auch da kann es haken, doppelt prüfen vor allem im erweiterten Log, einfach bspw. mit dem IAS-Viewer.
Bisher weiss ich von sicher 30 Clients (Auch gem. Logs)
Das meinte ich nicht, ich meinte ich das der Computer evt. seine Vertrauensstellung verloren hat.
Sieht eigentlich nicht danach aus. Gibt es hier ggf. eine sichere Methode das zu testen?
Gut bei der Menge ist das eher unwahrscheinlich.
Lade dir mal den Iasviewer und prüfe das Logfile genauer
https://www.deepsoftware.com/iasviewer/download.html
Dort sind oft mehr Informationen zur genauen Ursache hinterlegt.
Lade dir mal den Iasviewer und prüfe das Logfile genauer
https://www.deepsoftware.com/iasviewer/download.html
Dort sind oft mehr Informationen zur genauen Ursache hinterlegt.
Danke.
Dort sehe ich auch nicht mehr. Das Programm gibt eine tolle übersicht.
Name Value
Connect Request IAS_AUTH_FAILURE
Terminate Cause AUTH_FAILURE
Was ich nicht verstehe. Zwei Clients konnten sich verbinden.
Dort sehe ich auch nicht mehr. Das Programm gibt eine tolle übersicht.
Name Value
Connect Request IAS_AUTH_FAILURE
Terminate Cause AUTH_FAILURE
Was ich nicht verstehe. Zwei Clients konnten sich verbinden.
Dann prüfe mal was an den Clients von der Richtlinie tatsächlich in der Praxis angekommen ist (rsop.msc und das Profil im Klartext unter C:\Windows\wlansvc\Policies\*). Vor allem die Parts in der PEAP Section "Identitätsschutz" und "Anderen Benutzernamen für die Verbindung verwenden".
Für den exakten Dateinamen für das Klartext-Profil siehe die Registry unter
Wenn du ein Update vermutest, rolle es halt mal testweise auf einem betroffenen Client zurück.
Für den exakten Dateinamen für das Klartext-Profil siehe die Registry unter
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Wireless\GPTWirelessPolicyWas ich nicht verstehe. Zwei Clients konnten sich verbinden.
Cached Cred. / nicht übernommene GPO usw.Wenn du ein Update vermutest, rolle es halt mal testweise auf einem betroffenen Client zurück.
Wenn du ein Update vermutest, rolle es halt mal testweise auf einem betroffenen Client zurück.
Das kann ich unterdessen ausschliessen. Ich habe Testweise einen anderen Server als NPS eingerichtet und die Einstellungen Importiert. Auf diesem war das Update noch nicht installiert.Dann prüfe mal was an den Clients von der Richtlinie tatsächlich in der Praxis angekommen ist
Die GPOs scheinen aktuell zu sein und alle werden gezogen.Ich kann mir langsam nur noch erklären das irgendetwas mit den Zertifikaten nicht stimmt oder vielleicht mit deaktivierten LM/NTLM wobei das schon eine ganze weile her ist und bisher nur auf den Clients ist und nicht den Servern
Moin,
evtl. ist ein Lösungsweg für dich dabei:
https://www.borncity.com/blog/2022/05/11/windows-office-mai-2022-patchda ...
Du hast leider keine detailierten Informationen geschrieben.
Gruß,
Dani
evtl. ist ein Lösungsweg für dich dabei:
https://www.borncity.com/blog/2022/05/11/windows-office-mai-2022-patchda ...
Du hast leider keine detailierten Informationen geschrieben.
Gruß,
Dani
Danke auch für deine Antwort.
Leider keine Lösung aber so weiss ich schonmal das ich nicht der einzige bin. Nach dem entfernen des Updates KB5013952 funktioniert alles wieder.
Nun hoffe ich auf eine baldige Lösung da KB5013952 ein nicht gerade unwichtiges Update ist.
Leider keine Lösung aber so weiss ich schonmal das ich nicht der einzige bin. Nach dem entfernen des Updates KB5013952 funktioniert alles wieder.
Nun hoffe ich auf eine baldige Lösung da KB5013952 ein nicht gerade unwichtiges Update ist.
Es geht munter weiter:
https://www.borncity.com/blog/2022/05/12/windows-mai-2022-updates-verurs ...
Gruß,
Dani
https://www.borncity.com/blog/2022/05/12/windows-mai-2022-updates-verurs ...
Gruß,
Dani
Na das war ja mal wieder super kommuniziert ...
https://support.microsoft.com/de-de/topic/kb5014754-certificate-based-au ...
https://support.microsoft.com/de-de/topic/kb5014754-certificate-based-au ...
Manuelle Zuweisung bei zwei Maschinen mag ja in Ordnung sein aber wenn man 100 aufwärts hat...
Hoffe MS bringt bald ein Update
Hoffe MS bringt bald ein Update
Zitat von @KodaCH:
Manuelle Zuweisung bei zwei Maschinen mag ja in Ordnung sein aber wenn man 100 aufwärts hat...
Hoffe MS bringt bald ein Update
Manuelle Zuweisung bei zwei Maschinen mag ja in Ordnung sein aber wenn man 100 aufwärts hat...
Hoffe MS bringt bald ein Update
Da kommt kein Update für die oben verlinkte Neuerung. Stell die Zertifikate mit der SID Extension neu aus und das war's. Bitte den Beitrag mal etwas aufmerksamer lesen, das Mapping ist nur als Workaround gedacht falls man die Zertifikate momentan nicht neu ausstellen will/kann/darf . 😉
Enterprise Certificate Authorities (CA) will start adding a new non-critical extension with Object Identifier (OID) (1.3.6.1.4.1.311.25.2) by default in all the certificates issued against online templates after you install the May 10, 2022 Windows update. You can stop the addition of this extension by setting the 0x00080000 bit in the msPKI-Enrollment-Flag value of the corresponding template. For example, you run the following certutil command to exclude certificates of the user template from getting the new extension.
Da kommt kein Update für die oben verlinkte Neuerung.
Microsoft hat das Problem ja bereits bestätigt. Weshalb denkst du das hier kein Update mehr kommt?Stell die Zertifikate mit der SID Extension neu aus und das war's.
Ich habe bei zwei Clients das alte Zertifikat gelöscht und ein neues ausgestellt. Die entsprechende OID ist nun im Zertifikat vorhanden. Trotzdem bleibt der Fehler bestehen. Das mit der OID habe ich vorallem um Zusammenhang mit Server 2012 gelesen. Eventuell ist dies für Server 2016 nicht die Lösung?Zitat von @KodaCH:
Weil wir offensichtlich von zwei unterschiedlichen Dingen sprechen. Ich sprach von der SID Neuerung die ich oben verlinkt hatte, du vermutlich von dem aktuellen DC Authentifizierungsproblem.Da kommt kein Update für die oben verlinkte Neuerung.
Microsoft hat das Problem ja bereits bestätigt. Weshalb denkst du das hier kein Update mehr kommt?Das mit der OID habe ich vorallem um Zusammenhang mit Server 2012 gelesen.
Nein, das gilt für alle NPS mit aktuellen Sicherheits-Patches, denn das ist eine schwerwiegende Sicherheitslücke wenn sich der NPS hier von einfachen Namen im Abgleich mit dem AD täuschen lässt.Weil wir offensichtlich von zwei unterschiedlichen Dingen sprechen. Ich sprach von der SID Neuerung die ich oben verlinkt hatte, du vermutlich von dem aktuellen DC Authentifizierungsproblem.
Da habe ich dich wirklich falsch verstanden. Dachte das könnte die Lösung für mein Authentifizierungsproblem sein 
Moin,
Gruß,
Dani
Microsoft hat das Problem ja bereits bestätigt. Weshalb denkst du das hier kein Update mehr kommt?
Ding Dong... dein Wunsch wurde erhört: https://docs.microsoft.com/en-us/windows/release-health/resolved-issues- ...Gruß,
Dani
1
Hallo werte Kollegen und Leidensgenossen. Ich habe eine Lösung entwickelt für das Problem, dass die neue SID-Zertifkaterweiterung nur bei Zertifikatvorlagen eingetragen wird, die für AD-(Auto)Enrollment konfiguriert sind. Microsoft hat laut ihrem KB ja vor, das "Full Enforcement" am 09. Mai 2023 hart zu erzwingen, was meiner Ansicht nach alle MDM (Intune, Airwatch und Co.) verwalteten Endgeräte aus dem 802.1x rauswerfen wird wenn das Unternehmen den Network Policy Server einsetzt.
Die Lösung ist ein sog. Policy Modul für die Zertifizierungsstelle. Es kann eingehende Zertifikatanforderungen analysieren, die beantragte Identität ermitteln und auf das zugehörige AD Objekt mappen. So kann es die SID für das entsprechende Konto ermitteln und in das ausgestellte Zertifikat eintragen. Das funktioniert mit allen von der Microsoft CA zur Verfügung gestellten Protokollen, Clients und allen MDM Systemen.
Hier findet ihr das Modul: TameMyCerts auf GitHub
Es ist Open Source, kann also kostenlos eingesetzt werden. Unter "releases" liegt eine fertig kompilierte digital signierte Version davon. Ich hoffe, dass es euch einen Nutzen stiften kann. Meldet euch wenn ihr Schwierigkeiten beim Einsatz oder andere Fragen haben solltet. Mitarbeit am Projekt ist ebenfalls herzlich willkommen.
Die Lösung ist ein sog. Policy Modul für die Zertifizierungsstelle. Es kann eingehende Zertifikatanforderungen analysieren, die beantragte Identität ermitteln und auf das zugehörige AD Objekt mappen. So kann es die SID für das entsprechende Konto ermitteln und in das ausgestellte Zertifikat eintragen. Das funktioniert mit allen von der Microsoft CA zur Verfügung gestellten Protokollen, Clients und allen MDM Systemen.
Hier findet ihr das Modul: TameMyCerts auf GitHub
Es ist Open Source, kann also kostenlos eingesetzt werden. Unter "releases" liegt eine fertig kompilierte digital signierte Version davon. Ich hoffe, dass es euch einen Nutzen stiften kann. Meldet euch wenn ihr Schwierigkeiten beim Einsatz oder andere Fragen haben solltet. Mitarbeit am Projekt ist ebenfalls herzlich willkommen.
