Fehler bei RADIUS-Authentifizierung im WLAN
Hallo
Nachdem wir nun endlich dazu kommen unser WLAN etwas abzusichern stoße ich schon auf das erste Problem bei dem ich nicht weiterkomme.
Zur Situation:
- Unsere Clients sind alle ausschließlich via WLAN an das Firmennetz angeschlossen
- Alle Clients nutzen Windows10 (20H2, einige noch 1909)
- Alle Clients sind AzureAD-Joined (Kein HybridJoin!)
- Es findet ein sync der User zwischen AAD und AD via AAD-Connect statt
- Es wird Windows Hello for Buisness zur Anmeldung genutzt (Fingerprint)
Nun das Problem:
Ich habe ein neues (Test)-WLAN aufgespannt welches eine Radius-Authentifizierung durchführen soll.
Verbinde ich einen Client zum ersten mal mit diesem Netz fragt mich Windows nach den Zugangsdaten.
Ich klicke an das er sich automatisch mit dem Netz verbinden soll und sage dem Rechner das er die Windows-Anmeldedaten verwenden soll (so das ich kein Passwort eingeben muss sondern Windows selbst die gecacheten Anmeldedaten verwendet)
Die Verbindung wird problemlos aufgebaut.
Starte ich nun den Rechner neu und hänge in der Anmeldemaske wird mir angezeigt das der Client kein Netz hat (was auch richtig ist das der Rechner ja noch nicht auf meine Daten zugreifen kann)
Logge ich mich nun mit meinen Anmeldedaten ein meldet mir Windows das er versucht eine Verbindung zu dem WLAN-Netz herzustellen. Dies bricht jedoch ab.
Klicke ich auf die Verbindung wird mir angezeigt das die Zugangdaten nicht stimmen würden und ich mein Kennwort bitte eingeben soll. Mache ich dieses wird die Verbindung wieder aufgebaut.
Da wir den Usern nicht jeden Tag zumuten wollen ihr Passwort erneut eingeben zu müssen um ins WLAN zu kommen suche ich seit einer Woche nach einer Lösung, kann aber bisher noch nichtmal das Problem richtig eingrenzen. (Windows Hello? Radius-Konfig? Windows-Problem?)
In den Log-Dateien vom Radius sehe ich nur das mir eine Access-Challenge präsentiert wurde. Jedoch sehe ich keinen Grund warum er nicht das Windows-Passwort verwendet.
Nachdem wir nun endlich dazu kommen unser WLAN etwas abzusichern stoße ich schon auf das erste Problem bei dem ich nicht weiterkomme.
Zur Situation:
- Unsere Clients sind alle ausschließlich via WLAN an das Firmennetz angeschlossen
- Alle Clients nutzen Windows10 (20H2, einige noch 1909)
- Alle Clients sind AzureAD-Joined (Kein HybridJoin!)
- Es findet ein sync der User zwischen AAD und AD via AAD-Connect statt
- Es wird Windows Hello for Buisness zur Anmeldung genutzt (Fingerprint)
Nun das Problem:
Ich habe ein neues (Test)-WLAN aufgespannt welches eine Radius-Authentifizierung durchführen soll.
Verbinde ich einen Client zum ersten mal mit diesem Netz fragt mich Windows nach den Zugangsdaten.
Ich klicke an das er sich automatisch mit dem Netz verbinden soll und sage dem Rechner das er die Windows-Anmeldedaten verwenden soll (so das ich kein Passwort eingeben muss sondern Windows selbst die gecacheten Anmeldedaten verwendet)
Die Verbindung wird problemlos aufgebaut.
Starte ich nun den Rechner neu und hänge in der Anmeldemaske wird mir angezeigt das der Client kein Netz hat (was auch richtig ist das der Rechner ja noch nicht auf meine Daten zugreifen kann)
Logge ich mich nun mit meinen Anmeldedaten ein meldet mir Windows das er versucht eine Verbindung zu dem WLAN-Netz herzustellen. Dies bricht jedoch ab.
Klicke ich auf die Verbindung wird mir angezeigt das die Zugangdaten nicht stimmen würden und ich mein Kennwort bitte eingeben soll. Mache ich dieses wird die Verbindung wieder aufgebaut.
Da wir den Usern nicht jeden Tag zumuten wollen ihr Passwort erneut eingeben zu müssen um ins WLAN zu kommen suche ich seit einer Woche nach einer Lösung, kann aber bisher noch nichtmal das Problem richtig eingrenzen. (Windows Hello? Radius-Konfig? Windows-Problem?)
In den Log-Dateien vom Radius sehe ich nur das mir eine Access-Challenge präsentiert wurde. Jedoch sehe ich keinen Grund warum er nicht das Windows-Passwort verwendet.
Please also mark the comments that contributed to the solution of the article
Content-Key: 665229
Url: https://administrator.de/contentid/665229
Printed on: April 27, 2024 at 21:04 o'clock
5 Comments
Latest comment