NPS Authentifizierung fehlgeschlagen
Hallo und ein frohes neues Jahr,
wir nutzen den Windows NPS als Radius. Dieser läuft einmal auf einem Memberserver und einmal auf einem DC.
Wir nutzen 802.1x mit Zertifikaten für Domainclients und dann noch User+PW für z.B. Drucker
Jetzt ist es seit ca. 1 Monat so, dass die Authentifizierung mit User+PW am Memberserver nicht mehr funktioniert.
Die Domainclients können sich aber noch per Zertifikat authentifizieren, sowohl am Memberserver als auch am DC.
Wenn der DC genutzt wird für die Authentifizierung per User+PW klappt es.
Im Eventlog des Memberservers ist im NPS-Log dann zu sehen:
Woran kann dies liegen?
wir nutzen den Windows NPS als Radius. Dieser läuft einmal auf einem Memberserver und einmal auf einem DC.
Wir nutzen 802.1x mit Zertifikaten für Domainclients und dann noch User+PW für z.B. Drucker
Jetzt ist es seit ca. 1 Monat so, dass die Authentifizierung mit User+PW am Memberserver nicht mehr funktioniert.
Die Domainclients können sich aber noch per Zertifikat authentifizieren, sowohl am Memberserver als auch am DC.
Wenn der DC genutzt wird für die Authentifizierung per User+PW klappt es.
Im Eventlog des Memberservers ist im NPS-Log dann zu sehen:
Ursachencode: 16
Ursache: Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch.
Woran kann dies liegen?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670443
Url: https://administrator.de/forum/nps-authentifizierung-fehlgeschlagen-670443.html
Ausgedruckt am: 04.01.2025 um 21:01 Uhr
12 Kommentare
Neuester Kommentar
Hi,
woran das liegen kann? Bei den recht wenigen Informationen theoretisch an allem.
Um die Sache sauber durch zu analysieren:
Welche Switchmodelle nutzt du? Wie ist die 802.1x Config dafür gebaut? Was nutzt ihr für MAB?
- PEAP MSCHAPv2?
- PAP?
- CHAP?
Wie ist die Config für das Übergeben des Passwortes? Passwort gleich MAC-Adresse? Wie überreicht der Switch das Passwort, also ist in der Policy notwendig darauf zu achten, ob dies Case Sensitiv ist?
Die Fehlermeldung deutet auf ein Missmatch hin, das kann aber nur mit den oben stehenden Fragen beantwortet werden, weiterhin wäre ein kompletter Auszug von einer fehlerhaften Authentifizierung hilfreich.
Alles andere wäre wildes Raten.
Weiterhin:
- Wie lautet die NPS Config für MAB? Bitte alles mal posten, anonymisiere höchstens die Hostnamen und die Domain.
woran das liegen kann? Bei den recht wenigen Informationen theoretisch an allem.
Um die Sache sauber durch zu analysieren:
Welche Switchmodelle nutzt du? Wie ist die 802.1x Config dafür gebaut? Was nutzt ihr für MAB?
- PEAP MSCHAPv2?
- PAP?
- CHAP?
Wie ist die Config für das Übergeben des Passwortes? Passwort gleich MAC-Adresse? Wie überreicht der Switch das Passwort, also ist in der Policy notwendig darauf zu achten, ob dies Case Sensitiv ist?
Die Fehlermeldung deutet auf ein Missmatch hin, das kann aber nur mit den oben stehenden Fragen beantwortet werden, weiterhin wäre ein kompletter Auszug von einer fehlerhaften Authentifizierung hilfreich.
Alles andere wäre wildes Raten.
Weiterhin:
- Wie lautet die NPS Config für MAB? Bitte alles mal posten, anonymisiere höchstens die Hostnamen und die Domain.
Hi,
aus dem Bauch raus hätte ich jetzt KB5014754 in Verdacht - Certificate Hardening von MS.
https://support.microsoft.com/de-de/topic/kb5014754-%C3%A4nderungen-an-d ...
https://www.gradenegger.eu/de/anmeldungen-ueber-den-netzwerkrichtliniens ...
Schau dir mal die eingesetzten Zertifikate vom Memberserver an, ob diese schon das neue SID-Merkmal haben.
Ansonsten bräuchten wir noch ein paar Infos, wie AK-47.2 schon geschrieben hat.
Schau auch mal in die NPS-Logs, was da steht.
https://learn.microsoft.com/en-us/windows-server/networking/technologies ...
Gab es Änderungen, die mit dem Problem im zeitlichen Verlauf zusammen hängen könnten (Patches, Firewall, AD Changes etc.)
Grüße
Tsukaito
aus dem Bauch raus hätte ich jetzt KB5014754 in Verdacht - Certificate Hardening von MS.
https://support.microsoft.com/de-de/topic/kb5014754-%C3%A4nderungen-an-d ...
https://www.gradenegger.eu/de/anmeldungen-ueber-den-netzwerkrichtliniens ...
Schau dir mal die eingesetzten Zertifikate vom Memberserver an, ob diese schon das neue SID-Merkmal haben.
Ansonsten bräuchten wir noch ein paar Infos, wie AK-47.2 schon geschrieben hat.
Schau auch mal in die NPS-Logs, was da steht.
https://learn.microsoft.com/en-us/windows-server/networking/technologies ...
Gab es Änderungen, die mit dem Problem im zeitlichen Verlauf zusammen hängen könnten (Patches, Firewall, AD Changes etc.)
Grüße
Tsukaito
tsukaito 02.01.2025 um 13:12:33 Uhr
Hi,
aus dem Bauch raus hätte ich jetzt KB5014754 in Verdacht - Certificate Hardening von MS.
https://support.microsoft.com/de-de/topic/kb5014754-%C3%A4nderungen-an-d ...
https://www.gradenegger.eu/de/anmeldungen-ueber-den-netzwerkrichtliniens ...
Hi,
aus dem Bauch raus hätte ich jetzt KB5014754 in Verdacht - Certificate Hardening von MS.
https://support.microsoft.com/de-de/topic/kb5014754-%C3%A4nderungen-an-d ...
https://www.gradenegger.eu/de/anmeldungen-ueber-den-netzwerkrichtliniens ...
Meiner Meinung nach kann das nicht sein, das Hardening bezieht sich auf die Clients mit aktivem EAP-Client und Computerzertifikat im Speicher, Microsoft hat das Mapping angepasst, was nach Update der DCs zuschlägt. Dafür mussten dann neue Zertifikate mit der passenden Erweiterung ausgestellt werden.
Hierbei handelt es sich ja genau um Geräte ohne aktiven EAP Client oder eben nicht aktiviertem EAP-Client, dann übernimmt der Switch die Rolle des EAP-Clients und authentifiziert anhand der MAC Adresse.
wie du siehst, fehlt der EAP Typ. Also in deinem Falle vermutlich MSCHAP v2. Anscheinend wird gar kein Passwort übergeben.
Es muss MAB verwendet werden, hierbei wird vom Switch doch dann genau Username und Kennwort übergeben.
Ohne die entsprechenden Configs von NPS und Switch kann ich dir aber nicht helfen, ich gehe davon aus, dass der Switch in der 802.1x Config eine falsche/fehlende Methode für MAB besitzt.
Ist sichergestellt, dass der Switch PEAP MSCHAPv2 supported? Welches Kennwort übergibt der Switch? Kennwort gleich MAC-Adresse? Ist dies Case-Sensitiv? Das muss dann genau so in der AD matchen.
Es fehlen Informationen wie du siehst.
Es muss MAB verwendet werden, hierbei wird vom Switch doch dann genau Username und Kennwort übergeben.
Ohne die entsprechenden Configs von NPS und Switch kann ich dir aber nicht helfen, ich gehe davon aus, dass der Switch in der 802.1x Config eine falsche/fehlende Methode für MAB besitzt.
Ist sichergestellt, dass der Switch PEAP MSCHAPv2 supported? Welches Kennwort übergibt der Switch? Kennwort gleich MAC-Adresse? Ist dies Case-Sensitiv? Das muss dann genau so in der AD matchen.
Es fehlen Informationen wie du siehst.
Eigentlich ist der Grund ja klar und eindeutig: "Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch!"
Mit anderen Worten: Der im 802.1x Client des Endgerätes definierte Name und das Passwort existieren entweder nicht im AD oder haben ein falsches Kennwort.
Gemeinhin lügt ein Radius Server diesbezüglich ja nicht. Macht ja also Sinn erstmal genau DA anzusetzen.
Mit anderen Worten: Der im 802.1x Client des Endgerätes definierte Name und das Passwort existieren entweder nicht im AD oder haben ein falsches Kennwort.
Gemeinhin lügt ein Radius Server diesbezüglich ja nicht. Macht ja also Sinn erstmal genau DA anzusetzen.
Sry, dann habe ich das missverstanden, ich bin nicht davon ausgegangen, dass du PEAP mit aktivem EAP Client am Drucker betreibst.
Deine Richtlinie solltest du auf jeden Fall überarbeiten. Alle Häkchen bei den unsicheren Methoden raus.
Du benötigst lediglich PEAP mit MSCHAPv2 als innerer Authentifizierungsmethode.
Du sprichst von Memberserver mit NPS Rolle und DC mit NPS Rolle. Sind die Server im gleichen Subnetz?
Ist die NPS Config gleich auf beiden Servern?
Falls nicht im selben Subnetz, sind alle benötigten Firewallregeln gesetzt?
Deine Richtlinie solltest du auf jeden Fall überarbeiten. Alle Häkchen bei den unsicheren Methoden raus.
Du benötigst lediglich PEAP mit MSCHAPv2 als innerer Authentifizierungsmethode.
Du sprichst von Memberserver mit NPS Rolle und DC mit NPS Rolle. Sind die Server im gleichen Subnetz?
Ist die NPS Config gleich auf beiden Servern?
Falls nicht im selben Subnetz, sind alle benötigten Firewallregeln gesetzt?
Lass doch mal den Debugger direkt am Switch laufen, der zeigt dir doch zumindestens den 802.1x Usernamen an den das Endgerät an den Radius sendet. Hier mal ein Beispiel auf einem Cisco Catalysten:
Zusätzlich kann man vom Switch auch einen Radius Test mit den 802.1x Credentials des Endgerätes machen um zu checken ob die fehlerfrei authentisiert werden:
Der "Access accept" sagt dann alles!
Switch# debug radius authentication
Radius protocol debugging is on
Jan 2 17:33:06: RADIUS/ENCODE:Orig. component type = Dot1X
Jan 2 17:33:06: RADIUS: Config NAS IP: 10.1.10.7
Jan 2 17:33:06: RADIUS: Config NAS IPv6: ::
Jan 2 17:33:06: RADIUS: Sending a IPv4 Radius Packet
Jan 2 17:33:06: RADIUS: Started 5 sec timeout
Jan 2 2025 17:33:09 CET: %AUTHMGR-5-START: Starting 'dot1x' for client (8cae.4cfe.0194) on Interface Fa0/3 AuditSessionID 0A010A0700000022004668D3
Jan 2 17:33:21: RADIUS/ENCODE:Orig. component type = Dot1X
Jan 2 17:33:21: RADIUS: Config NAS IP: 10.1.10.7
Jan 2 17:33:21: RADIUS: Send Access-Request to 10.1.10.222:1812 id 1645/69, len 232
Jan 2 17:33:21: RADIUS: User-Name [1] 10 "testuser"
Jan 2 17:33:21: RADIUS: Service-Type [6] 6 Framed [2]
Jan 2 17:33:21: RADIUS: Vendor, Cisco [26] 27
Jan 2 17:33:21: RADIUS: Cisco AVpair [1] 21 "service-type=Framed"
Jan 2 17:33:21: RADIUS: Framed-IP-Address[8] 6 10.1.10.148
Jan 2 17:33:21: RADIUS: Framed-MTU [12] 6 1500
Switch# test aaa group RADIUS testuser test123 legacy
Attempting authentication test to server-group LABRADIUS using radius
User was successfully authenticated.
Jan 2 18:05:39: RADIUS: Pick NAS IP for u=0x39BD15C tableid=0 cfg_addr=10.1.10.7
Jan 2 18:05:39: RADIUS: Send Access-Request to 10.1.10.222:1812 id 1645/79, len 60
Jan 2 18:05:39: RADIUS: NAS-IP-Address [4] 6 10.1.10.7
Jan 2 18:05:39: RADIUS: NAS-Port-Type [61] 6 Async [0]
Jan 2 18:05:39: RADIUS: User-Name [1] 10 "testuser"
Jan 2 18:05:39: RADIUS: User-Password [2] 18 *
Jan 2 18:05:39: RADIUS: Sending a IPv4 Radius Packet
Jan 2 18:05:39: RADIUS: Started 5 sec timeout
Jan 2 18:05:39: RADIUS: Received from id 10.1.10.222:1812, Access-Accept, len 20
Mehr Logs einholen hilft i.d.R. zuverlässig die Ursache zu finden
https://learn.microsoft.com/de-de/previous-versions/windows/it-pro/windo ...
https://learn.microsoft.com/de-de/previous-versions/windows/it-pro/windo ...