6
Zertifikatsbasierte Mobile Device Authentifizierung am Windows NPS
Hallo Community,
aktuell versuchen wir Windows-Systeme, iOS und Android per Zertifikat an einem Windows-Radius für das WLAN zu authentifizieren. Die Systeme welche in der AD sind, können ohne Probleme sich authentifizieren. Doch leider erhalten wir beim Anmeldeversuch von nicht AD-Systemen (iOS und Android) die Fehlermeldung 23.
"Fehler während der Netzwerkrichtlinienserver-Verwendung des Extensible Authentication-Protokolls (EAP). Überprüfen Sie die EAP-Protokolldateien auf EAP-Fehler."
Zur aktuellen Konfiguration und Struktur:
- APs sind von Sophos und sind Clients des RADIUS
- Der RADIUS ist in der AD bekannt und hat ein Zertifikat durch die interne PKI
- Das Zertifikat des RADIUS und die der PKI sind auf allen Systemen bekannt und Vertrauenswürdig
- CRL kann von extern heruntergeladen werden
- Verbindungsanforderung und Netzwerkrichtlinie akzeptieren nur den EAP-Typ: Microsoft: Smartcard- oder anderes Zertifikat
keine weniger sicheren Authentifizierungsmethoden
- Auf dem iOS und Android wird ein Zertifikat durch das MDM von der PKI per SCEP ausgerollt, das Zertifikat beinhaltet UPN und E-Mail des AD-Users
Habt Ihr hier Ideen, was müssen wir ändern müssen, damit das Problem gelöst wird, gibt es eventuell sogar bessere Wege als unseren?
Vielen Dank für eure Unterstützung.
aktuell versuchen wir Windows-Systeme, iOS und Android per Zertifikat an einem Windows-Radius für das WLAN zu authentifizieren. Die Systeme welche in der AD sind, können ohne Probleme sich authentifizieren. Doch leider erhalten wir beim Anmeldeversuch von nicht AD-Systemen (iOS und Android) die Fehlermeldung 23.
"Fehler während der Netzwerkrichtlinienserver-Verwendung des Extensible Authentication-Protokolls (EAP). Überprüfen Sie die EAP-Protokolldateien auf EAP-Fehler."
Zur aktuellen Konfiguration und Struktur:
- APs sind von Sophos und sind Clients des RADIUS
- Der RADIUS ist in der AD bekannt und hat ein Zertifikat durch die interne PKI
- Das Zertifikat des RADIUS und die der PKI sind auf allen Systemen bekannt und Vertrauenswürdig
- CRL kann von extern heruntergeladen werden
- Verbindungsanforderung und Netzwerkrichtlinie akzeptieren nur den EAP-Typ: Microsoft: Smartcard- oder anderes Zertifikat
keine weniger sicheren Authentifizierungsmethoden
- Auf dem iOS und Android wird ein Zertifikat durch das MDM von der PKI per SCEP ausgerollt, das Zertifikat beinhaltet UPN und E-Mail des AD-Users
Habt Ihr hier Ideen, was müssen wir ändern müssen, damit das Problem gelöst wird, gibt es eventuell sogar bessere Wege als unseren?
Vielen Dank für eure Unterstützung.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 583956
Url: https://administrator.de/forum/zertifikatsbasierte-mobile-device-authentifizierung-am-windows-nps-583956.html
Ausgedruckt am: 18.04.2025 um 03:04 Uhr
6 Kommentare
Neuester Kommentar
Moin,
nur noch mal eine Rückfrage:
Alle Clients benötigen ein eigenes Zertifkat? Oder reicht den Clients, dass die dem ROOT-Zertifikat vertrauen?
Hast du das mal mit einem NB ausprobiert, welches nicht in dieser AD ist?
Nur mal eben aus dem blauen Dunst:
Vielleicht sollte bei den Zertifikat unter "Allgemeiner Name" der FQDN vom Client stehen.
nur noch mal eine Rückfrage:
Alle Clients benötigen ein eigenes Zertifkat? Oder reicht den Clients, dass die dem ROOT-Zertifikat vertrauen?
Hast du das mal mit einem NB ausprobiert, welches nicht in dieser AD ist?
Auf dem iOS und Android wird ein Zertifikat durch das MDM von der PKI per SCEP ausgerollt, das Zertifikat beinhaltet UPN und E-Mail des AD-Users
Nur mal eben aus dem blauen Dunst:
Vielleicht sollte bei den Zertifikat unter "Allgemeiner Name" der FQDN vom Client stehen.
Hi, vielen Dank für deine Antwort.
Wir würden es gerne so handhaben der Sicherheit zur liebe.
Ein Notebook welches nicht in der AD ist hat die selbe Problem wie ein iOS oder Android, sprich Fehlercode 23.
Wir würden es gerne so handhaben der Sicherheit zur liebe.
Ein Notebook welches nicht in der AD ist hat die selbe Problem wie ein iOS oder Android, sprich Fehlercode 23.
Zitat von @RalphT:
Vielleicht sollte bei den Zertifikat unter "Allgemeiner Name" der FQDN vom Client stehen.
Die Notebooks in der AD erhalten bereits Zertifikate wo der FQDN im CN des Zertifikats steht. Teste aktuell ein Zertifikat ohne Domänen-Suffix, da dieser ja ein Missmatch auf einem System außerhalb der AD verursacht.Vielleicht sollte bei den Zertifikat unter "Allgemeiner Name" der FQDN vom Client stehen.
Verate doch mal was du im NPS unter EAP-Typ eingestellt hast. Hier die Möglichkeiten:
EAP-Typen auf dem Reiter Einschränkungen:
Microsoft: EAP Gesichertes Kennwort (EAP MSCHAP v2)
Microsoft: Geschütztes EAP (PEAP) unter EAP-Typen: Gesichertes Kennwort (EAP MSCHAP v2)
Microsoft: Geschütztes EAP (PEAP) unter EAP-Typen: Smartcard- oder anderes Zertifikat
Microsoft: Smartcard oder anderes Zertifikat
Und wie gesagt, das Zertifikat für den Client muss unter "Allgemeiner Name" den FQDN des Clients haben. Das gilt nur die Rechner/Geräte außerhalb der Domäne. Daher muss die Zertifikatvorlage so gestrickt sein, dass der Client diese Frage beim Anfordern des Zertifikats beantworten kann. Daher ist es notwendig, dass du in der CA für diese Zertifikate auf dem Reiter "Antragstellername" die Option bei "Informationen werden in der Anforderung...". Für die Clients in der AD braucht man das nicht. Sieht man ja auch, denn du schreibst, dass das ja funktioniert. Daher habe ich in der CA 2 Vorlagen erstellt.
EAP-Typen auf dem Reiter Einschränkungen:
Microsoft: EAP Gesichertes Kennwort (EAP MSCHAP v2)
Microsoft: Geschütztes EAP (PEAP) unter EAP-Typen: Gesichertes Kennwort (EAP MSCHAP v2)
Microsoft: Geschütztes EAP (PEAP) unter EAP-Typen: Smartcard- oder anderes Zertifikat
Microsoft: Smartcard oder anderes Zertifikat
Und wie gesagt, das Zertifikat für den Client muss unter "Allgemeiner Name" den FQDN des Clients haben. Das gilt nur die Rechner/Geräte außerhalb der Domäne. Daher muss die Zertifikatvorlage so gestrickt sein, dass der Client diese Frage beim Anfordern des Zertifikats beantworten kann. Daher ist es notwendig, dass du in der CA für diese Zertifikate auf dem Reiter "Antragstellername" die Option bei "Informationen werden in der Anforderung...". Für die Clients in der AD braucht man das nicht. Sieht man ja auch, denn du schreibst, dass das ja funktioniert. Daher habe ich in der CA 2 Vorlagen erstellt.
Microsoft: Smartcard oder anderes Zertifikat
Ist eingestelltUnd wie gesagt, das Zertifikat für den Client muss unter "Allgemeiner Name" den FQDN des Clients haben. Das gilt nur die Rechner/Geräte außerhalb der Domäne. Daher muss die Zertifikatvorlage so gestrickt sein, dass der Client diese Frage beim Anfordern des Zertifikats beantworten kann. Daher ist es notwendig, dass du in der CA für diese Zertifikate auf dem Reiter "Antragstellername" die Option bei "Informationen werden in der Anforderung...". Für die Clients in der AD braucht man das nicht. Sieht man ja auch, denn du schreibst, dass das ja funktioniert. Daher habe ich in der CA 2 Vorlagen erstellt.
Nun funktioniert auch ein AD-Fremdes System mit dem FQDN eines AD-Systems im CN.Der Windows NPS versucht den FQDN in der AD zu validieren, sonst kommt es zur keiner Authentifizierung. Was mache ich also mit einem iOS und Android, hier wird es nie einen gültigen FQDN geben, wenn das Gerät iPhonevonUser heißt?
Was mache ich also mit einem iOS und Android, hier wird es nie einen gültigen FQDN geben, wenn das Gerät iPhonevonUser heißt?
Ja das stimmt, das wäre nicht praktikabel. Bei den Smartphones würde ich anders agieren. Jetzt ist natürlich die Frage, über wieviele Geräte reden wir hier? Hast du jeden Tag andere Gäste?
Ich würde das für die Smartphones ohne ein Computerzertifikat lösen. Entweder mit einem Benutzerzertifikat oder mit Name/Passwort.
Wobei ich die Variante mit Name und Passwort besser finde. Das gibt man ja nur einmal ein und gut ist. Ein Benutzerzertifikat muss der jeweilige Hanynutzer bekommen. Enweder per USB oder per Mail. Ich bin der Meinung, das nervt auf beiden Seiten.
Dazu erstellt du im NPS eine weitere Regel. Du legst im AD eine neue Gruppe an. In diese Gruppe packst du alle Handynutzer mit Namen, die vorher in der AD alle angelegt worden sind. Diese Gruppe muss im NPS in der neuen Regel erlaubt werden. Dann darf der EAP-Typ nicht auf Zertifikat stehen. Hier muss das hier stehen:
"Microsoft: Geschütztes EAP (PEAP) unter EAP-Typen: Gesichertes Kennwort (EAP MSCHAP v2)"
Wichtig ist hier folgendes:
Bei deiner ersten Regel, arbeitest du im NPS und in der AD mit einer Gruppe in der COMPUTER sind. Bei der neuen, zweiten Regel arbeitest du im NPS und in der AD mit einer Gruppe in der NUTZER sind. Das wird schnell mal vergessen.
Wenn du später ein Handynutzer nicht mehr magst, dann deaktivierst du in der AD sein Benutzerkonto. Damit hättest du die Leute schnell ausgesperrt. Alle Hanynutzer müssen jeoch das ROOT-Zertifkat haben. Aber das sollte ja kein Problem darstellen, da dieses Zertifikat eine lange Laufzeit hat.
Ja das stimmt, das wäre nicht praktikabel. Bei den Smartphones würde ich anders agieren. Jetzt ist natürlich die Frage, über wieviele Geräte reden wir hier? Hast du jeden Tag andere Gäste?
Ca. 5000-8000 Systeme, da wir auch die PDAs so ins WLAN heben wollen.Ich würde das für die Smartphones ohne ein Computerzertifikat lösen. Entweder mit einem Benutzerzertifikat oder mit Name/Passwort.
MSCHAPv2 ist aktuell konfiguriert und ist leider auch für uns ein Problem, da wir freiwillige Mitarbeiter haben, die somit die Geräte nutzen ohne einen AD-Account zu haben.Wobei ich die Variante mit Name und Passwort besser finde. Das gibt man ja nur einmal ein und gut ist. Ein Benutzerzertifikat muss der jeweilige Hanynutzer bekommen. Enweder per USB oder per Mail. Ich bin der Meinung, das nervt auf beiden Seiten.
Wir verteilen die Zertifikate per MDM, dort ist ein SCEP-Proxy hinterlegt mit Zugriff auf die interne PKIDarf ein Benutzerzertifikat die Schlüsselverwendung "Client-Authentifizierung" haben? Denn ich denke das stört den NPS aktuell.
Unsere Zertifikate bestehen aus den Informationen des MDM-Users und wird auf Geräte außerhalb der Domäne verteilt.
