NPS Problem
Hallo,
ich habe ein Problem mit einem NPS an einem Standort.
Wenn ich am WLAN Controller einen anderen NPS eingebe zum Authentifizieren, geht es.
Es ist ein Windows Server 2016 mit NPS Rolle. Als Clients sind es Unifi Accesspoints.
Im Eventlog steht folgender "nichtssagender" Hinweis:
Stelle ich im UniFi Controller einen anderen Authentifizierungsserver ein, klappt es sofort. Von Daher gehe ich davon aus, das es am Windows Server liegt.
Ich habe den NPS eben mal resettet mit dem Befehtl
Auch nach neu eingeben klappt es nicht.
Kennt jemand das Problem oder dessen Ursache?
ich habe ein Problem mit einem NPS an einem Standort.
Wenn ich am WLAN Controller einen anderen NPS eingebe zum Authentifizieren, geht es.
Es ist ein Windows Server 2016 mit NPS Rolle. Als Clients sind es Unifi Accesspoints.
Im Eventlog steht folgender "nichtssagender" Hinweis:
Der Netzwerkrichtlinienserver hat einem Benutzer den Zugriff verweigert.
Wenden Sie sich an den Administrator des Netzwerkrichtlinienservers, um weitere Informationen zu erhalten.
Benutzer:
Sicherheits-ID: DOMAIN\KONF$
Kontoname: host/KONF.domain.local
Kontodomäne: DOMAIN
Vollqualifizierter Kontoname: domain.local/Domain Gruppe/Ort/Computer/KONF
Clientcomputer:
Sicherheits-ID: NULL SID
Kontoname: -
Vollqualifizierter Kontoname: -
ID der Empfangsstation: 7E-8A-20-xx-xx-xx:WiFI_SSID
ID der Anrufstation: 34-E1-2D-xx-xx-xx
NAS:
NAS-IPv4-Adresse: 10.2.1.9
NAS-IPv6-Adresse: -
NAS-ID: 7e8a20f20bf7
NAS-Porttyp: Drahtlos (IEEE 802.11)
NAS-Port: -
RADIUS-Client:
Clientanzeigename: AP3
Client-IP-Adresse: 10.2.1.9
Authentifizierungsdetails:
Name der Verbindungsanforderungsrichtlinie: WiFi
Netzwerkrichtlinienname: WiFi Auth.
Authentifizierungsanbieter: Windows
Authentifizierungsserver: FILE.domain.local
Authentifizierungstyp: EAP
EAP-Typ: Microsoft: Smartcard- oder anderes Zertifikat
Kontositzungs-ID: 41363543353345333237344130434532
Protokollierungsergebnisse: Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben.
Ursachencode: 16
Ursache: Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch.
Stelle ich im UniFi Controller einen anderen Authentifizierungsserver ein, klappt es sofort. Von Daher gehe ich davon aus, das es am Windows Server liegt.
Ich habe den NPS eben mal resettet mit dem Befehtl
netsh nps reset
Kennt jemand das Problem oder dessen Ursache?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2849511630
Url: https://administrator.de/contentid/2849511630
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
19 Kommentare
Neuester Kommentar
Servus @killtec .
Guckst du hier
NPS - WLAN Verbindung nach Update nicht mehr möglich
https://docs.microsoft.com/en-us/windows/release-health/resolved-issues- ...
Des weiteren solltest du dir für die Zukunft noch folgendes zu Gemüte führen
KB5014754—Certificate-based authentication changes on Windows domain controllers
Grüße Uwe
Guckst du hier
NPS - WLAN Verbindung nach Update nicht mehr möglich
https://docs.microsoft.com/en-us/windows/release-health/resolved-issues- ...
Des weiteren solltest du dir für die Zukunft noch folgendes zu Gemüte führen
KB5014754—Certificate-based authentication changes on Windows domain controllers
Grüße Uwe
Zitat von @colinardo:
Servus @killtec .
Guckst du
NPS - WLAN Verbindung nach Update nicht mehr möglich
Grüße Uwe
Servus @killtec .
Guckst du
NPS - WLAN Verbindung nach Update nicht mehr möglich
Grüße Uwe
und da: Mal wieder Risiko-Patchday für Domänencontroller
Grüße
lcer
Ist nicht mehr nötig, gibt bereits einen Patch.
https://docs.microsoft.com/en-us/windows/release-health/resolved-issues- ...
https://docs.microsoft.com/en-us/windows/release-health/resolved-issues- ...
@killtec
Ich möchte dir das sonnige Wochenende nicht versauen...
Bei uns im Lab hat das Update keine Besserung gebracht. Alle beteiligten Server laufen mit Windows Server 2019 (Build 1809) Englisch. Alle Rollen (ADDC, NPS, etc..) sind auf dedizierten Servern installiert. Testclients sind Apple iPads, Apple iPhones und Windows 10 VMs.
Gruß,
Dani
Ich möchte dir das sonnige Wochenende nicht versauen...
Bei uns im Lab hat das Update keine Besserung gebracht. Alle beteiligten Server laufen mit Windows Server 2019 (Build 1809) Englisch. Alle Rollen (ADDC, NPS, etc..) sind auf dedizierten Servern installiert. Testclients sind Apple iPads, Apple iPhones und Windows 10 VMs.
Gruß,
Dani
Zitat von @Dani:
Bei uns im Lab hat das Update keine Besserung gebracht. Alle beteiligten Server laufen mit Windows Server 2019 (Build 18.09) Englisch. Alle Rollen (ADDC, NPS, etc..) sind auf dedizierten Servern installiert. Testclients sind Apple iPads, Apple iPhones und Windows 10 VMs.
Hier in einer Server 2022 Lab Umgebung klappt nach dem Patch wieder alles reibungslos. So unterschiedlich können Erfahrungen ausfallen , wahr vermutlich wieder einmal ein Schnellschuss.Bei uns im Lab hat das Update keine Besserung gebracht. Alle beteiligten Server laufen mit Windows Server 2019 (Build 18.09) Englisch. Alle Rollen (ADDC, NPS, etc..) sind auf dedizierten Servern installiert. Testclients sind Apple iPads, Apple iPhones und Windows 10 VMs.
Danke für die Info.
@colinardo
Ich möchte keinenfalls den Thread kappern... aber zwei Fragen muss ich loswerden:
Gruß,
Dani
Ich möchte keinenfalls den Thread kappern... aber zwei Fragen muss ich loswerden:
- Hast du den von Microsoft beschriebenen Workaround vor Installation des OoB Updates wieder rückgängig gemacht?
- Nutzen die Clients noch die ursprünglichen Zertifikate (ohne UPN) oder hast du diese im Rahmen der Fehlersuche bzw. Tests erneuert und somit den UPN in einem Attribut?
Gruß,
Dani
Zitat von @Dani:
@colinardo
Ich möchte keinenfalls den Thread kappern... aber zwei Fragen muss ich loswerden:
Ja.@colinardo
Ich möchte keinenfalls den Thread kappern... aber zwei Fragen muss ich loswerden:
- Hast du den von Microsoft beschriebenen Workaround vor Installation des OoB Updates wieder rückgängig gemacht?
* Nutzen die Clients noch die ursprünglichen Zertifikate (ohne UPN)
Ja, UPN ist aber bei uns im SAN enthalten.Im Compatibility Mode sollte dann nur eine Warnung auftauchen. Erst im Full Enforcement Mode wird das Strong-Mapping nötig.
Ich habe ähnliches Problem gehabt auch NPS auf dedizierten Server, gleiche Meldung. Clients werden per Zertifikat authentifiziert.
Ich konnte es lösen in dem ich dem Registry Wert "CertificateMappingMethods" mit dem Wert "0x1F" auf den zugehörigen Domain Controllern hinzugefügt habe. Hat ein wenig gedauert bis mir klar wurde das die Änderung auf den DCs durchgeführt werden muss.
Angeblich sollen mit dem Update neu ausgestellte Zertifikate das Problem dann nicht mehr haben, habe mir einen Termin im Kalender gesetzt um das mit den neuen Zerts zu testen bevor MS weiter Chaos stiftet.
Siehe Dazu:
https://support.microsoft.com/de-de/topic/kb5014754-certificate-based-au ...
Ich konnte es lösen in dem ich dem Registry Wert "CertificateMappingMethods" mit dem Wert "0x1F" auf den zugehörigen Domain Controllern hinzugefügt habe. Hat ein wenig gedauert bis mir klar wurde das die Änderung auf den DCs durchgeführt werden muss.
Angeblich sollen mit dem Update neu ausgestellte Zertifikate das Problem dann nicht mehr haben, habe mir einen Termin im Kalender gesetzt um das mit den neuen Zerts zu testen bevor MS weiter Chaos stiftet.
Siehe Dazu:
https://support.microsoft.com/de-de/topic/kb5014754-certificate-based-au ...
https://www.borncity.com/blog/2022/05/21/windows-out-of-band-updates-vom ...
Die nachgeschobenen Updates bringen es nicht wirklich, es bleibt nur die Deinstallation des Ursprung-Patch.
Die nachgeschobenen Updates bringen es nicht wirklich, es bleibt nur die Deinstallation des Ursprung-Patch.
Zitat von @chgorges:
https://www.borncity.com/blog/2022/05/21/windows-out-of-band-updates-vom ...
Die nachgeschobenen Updates bringen es nicht wirklich, es bleibt nur die Deinstallation des Ursprung-Patch.
https://www.borncity.com/blog/2022/05/21/windows-out-of-band-updates-vom ...
Die nachgeschobenen Updates bringen es nicht wirklich, es bleibt nur die Deinstallation des Ursprung-Patch.
Oder die Zertifikate vorausschauend auf aktuellen Stand bringen. Bei Domain-Joined-Clients beschränkt sich das ja auf einen Klick in den Zertifikatsvorlagen um die Seriennummer des Templates zu erhöhen. Beim nächsten Pulse erneuert sich der Client das Zertifikat dann automatisch, (Manuell triggern geht natürlich auch
certutil -pulse
(für Computer-Zertifikate in elevated Shell), oder certutil -pulse -user
für Benutzerzertifikate des aktuell angemeldeten Users.)Aktualisierte Zertifikate sollten dann die SID Extension mit DER kodierter Computer- oder User-SID beinhalten
Moin,
ein Kollege von mir, hat mir folgenden Link zu kommen lassen:
https://www.askwoody.com/forums/topic/master-patch-list-as-of-may-19-202 ...
Gruß,
Dani
ein Kollege von mir, hat mir folgenden Link zu kommen lassen:
https://www.askwoody.com/forums/topic/master-patch-list-as-of-may-19-202 ...
Gruß,
Dani
Der Tipp von @colinaro bringt es vermutlich.
@Dani: Warum in die Ferne schweifen, liegt das Gute doch so nah .
Der "anonymous" Post im Thread bei askwoody.com ist von mir (war zu faul, meine Nutzerdaten für die Anmeldung heraus zu suchen) - ich habe mit Patch Lady Susan Bradley "über Bande" gespielt und es hat funktioniert - das Ganze ist inzwischen von mir in meinen deutschen und englischen Blog-Beiträgen berücksichtigt - ob es funktioniert, kann ich nicht testen. Vielleicht hilft es aber weiter.
Windows Out-of-Band-Updates vom 19.5.2022 versagen mit NPS beim AD DC-Authentifizierungsfehler
@Dani: Warum in die Ferne schweifen, liegt das Gute doch so nah .
Der "anonymous" Post im Thread bei askwoody.com ist von mir (war zu faul, meine Nutzerdaten für die Anmeldung heraus zu suchen) - ich habe mit Patch Lady Susan Bradley "über Bande" gespielt und es hat funktioniert - das Ganze ist inzwischen von mir in meinen deutschen und englischen Blog-Beiträgen berücksichtigt - ob es funktioniert, kann ich nicht testen. Vielleicht hilft es aber weiter.
Windows Out-of-Band-Updates vom 19.5.2022 versagen mit NPS beim AD DC-Authentifizierungsfehler
Zitat von @killtec:
Ich habe die Zertifikate noch mal angepackt. Die Zertifikate habe ich um das Attribut UPN erweitert. Es stand nur der DNS drin. Jetzt scheint es zu laufen. Von daher war der Tipp schon Gold Wert
Ich habe die Zertifikate noch mal angepackt. Die Zertifikate habe ich um das Attribut UPN erweitert. Es stand nur der DNS drin. Jetzt scheint es zu laufen. Von daher war der Tipp schon Gold Wert
Naja, der UPN war eigentlich schon sehr lange in den Mindestanforderungen für die Client-Zertfikate für EAP von MS drin, insofern ein hausgemachtes Problem
Konfigurieren von Zertifikatvorlagen für PEAP- und EAP-Anforderungen
Bei EAP-TLS oder PEAP-TLS akzeptiert der Server den Clientauthentifizierungsversuch, wenn das Zertifikat die folgenden Anforderungen erfüllt:
...
Bei Benutzerzertifikaten enthält die Subject Alternative Name -Erweiterung (SubjectAltName) im Zertifikat den Benutzerprinzipalnamen (UPN).
...
...
Bei Benutzerzertifikaten enthält die Subject Alternative Name -Erweiterung (SubjectAltName) im Zertifikat den Benutzerprinzipalnamen (UPN).
...