20.05.2022

9061

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:

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

Auch nach neu eingeben klappt es nicht.

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/forum/nps-problem-2849511630.html

Ausgedruckt am: 21.12.2024 um 12:12 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

Windows Updates vom Mai deinstallieren, ist ein bestätigtes Problem.

Zitat von @colinardo:

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

Zitat von @chgorges:

Windows Updates vom Mai deinstallieren

Ist nicht mehr nötig, gibt bereits einen Patch.
https://docs.microsoft.com/en-us/windows/release-health/resolved-issues- ...

Hi Zusammen,
schaue mir das von MS was @colinardo geschrieben hat mal an. Der Patch ist ja satte 1,5GB groß...
Könnte gut damit zusammen hängen, da es vorher lief.
Ich gebe dann Rückmeldung. Danke

@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

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.
Danke für die Info.

@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) 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:

Hast du den von Microsoft beschriebenen Workaround vor Installation des OoB Updates wieder rückgängig gemacht?

Ja.

* 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 ...

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.

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.

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

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

So,
kurze Rückmeldung. Bei mir half der Patch KB5015019 auf dem DC der Vor Ort ist. Die Zertifikate beinhalten den FQDN des Clients bereits.

Danke
Gruß

Korrektur, das hielt nur einen Reboot lang

Ich habe das entsprechende Zertifikat geprüft, es steht die SID und nicht der Cleintname im Zertifikat.
Wie gesagt, gebe ich einen anderen NPS in der Domäne an, der an einem anderen Standort steht, so geht alles.
Demnach kann es doch nur entweder beim DC oder beim NPS an dem Standort liegen, oder?

So, kleines Update:

Zitat von @colinardo:

Aktualisierte Zertifikate sollten dann die SID Extension mit DER kodierter Computer- oder User-SID beinhalten

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 beobachte das noch ein paar Tage ob das stabil bleibt. Von gestern auf heute lief es stabil.

Gruß

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

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).
...