Android 13 und Radius Authentication
Hallo und guten Tag.
Mein Problem am Freitag
Ich sitze eben bei einem Kunden, bei dem ich die 802.1X Auth. mit Unifi AP's eingerichtet habe.
Das funktioniert auch soweit alles.
Die Benutzer existieren alle im AD und können sich von ihren Mobile Phones am Wlan anmelden.
Jetzt hab ich hier noch 8 Tablets mit Android 13, die sich leider nicht anmelden können.
Habe das "Microsoft REMOTE Attestaton Service" Zertifikat exportiert und auf die Tablets übertragen.
Ohne das Zertifikat erhalte ich im Log folgende Meldung:
Mit Zertifikat kommt folgende Meldung:
Wie in der zweiten Meldung zu sehen ist, klappt die Anmeldung ebenfalls nicht.
Wenn ich mich mit dem selben Benutzer, hier tab-qm1, an meinem Mobile Phone anmelde, klappt es aber.
An den Tablets stelle ich folgendes ein:
EAP-Methode -> PEAP
Phase-2-Authentifizierung-> MS-CHAP v2
CA-Zertifikat-> Radius (Das exportierte)
Domain-> MusterFirma.local
Identität-> tab-qm1
Anonyme Identität-> wir leer gelassen
PAssword-> Benutzer Password
Ich hoffe allen benötigen Informationen erwähnt zu haben.
Ja, leider klappt die Anmeldung wie bereits erwähnt an den Tablets nicht.
Daher hoffe ich das jemand aus dem Forum eine Lösung anbieten kann.
Mein Problem am Freitag
Ich sitze eben bei einem Kunden, bei dem ich die 802.1X Auth. mit Unifi AP's eingerichtet habe.
Das funktioniert auch soweit alles.
Die Benutzer existieren alle im AD und können sich von ihren Mobile Phones am Wlan anmelden.
Jetzt hab ich hier noch 8 Tablets mit Android 13, die sich leider nicht anmelden können.
Habe das "Microsoft REMOTE Attestaton Service" Zertifikat exportiert und auf die Tablets übertragen.
Ohne das Zertifikat erhalte ich im Log folgende Meldung:
Der Netzwerkrichtlinienserver hat einem Benutzer den Zugriff verweigert.
Wenden Sie sich an den Administrator des Netzwerkrichtlinienservers, um weitere Informationen zu erhalten.
Benutzer:
Sicherheits-ID: MusterFirma\techniker
Kontoname: techniker
Kontodomäne: MusterFirma
Vollqualifizierter Kontoname: MusterFirma\techniker
Clientcomputer:
Sicherheits-ID: NULL SID
Kontoname: -
Vollqualifizierter Kontoname: -
ID der Empfangsstation: 7A-AC-B9-65-AA-4D:MusterFirma
ID der Anrufstation: 7A-12-11-34-FD-DC
NAS:
NAS-IPv4-Adresse: 192.168.3.100
NAS-IPv6-Adresse: -
NAS-ID: 7aacb965ac4d
NAS-Porttyp: Drahtlos (IEEE 802.11)
NAS-Port: -
RADIUS-Client:
Clientanzeigename: Anbau Büro
Client-IP-Adresse: 192.168.3.100
Authentifizierungsdetails:
Name der Verbindungsanforderungsrichtlinie: Sichere Drahtlosverbindungen
Netzwerkrichtlinienname: Sichere Drahtlosverbindungen
Authentifizierungsanbieter: Windows
Authentifizierungsserver: Con-xxxxx.xxxxlocal
Authentifizierungstyp: PEAP
EAP-Typ: -
Kontositzungs-ID: 41414530313445344136364144313035
Protokollierungsergebnisse: Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben.
Ursachencode: 265
Ursache: Die Zertifikatskette wurde von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt.
Mit Zertifikat kommt folgende Meldung:
Der Netzwerkrichtlinienserver hat einem Benutzer den Zugriff verweigert.
Wenden Sie sich an den Administrator des Netzwerkrichtlinienservers, um weitere Informationen zu erhalten.
Benutzer:
Sicherheits-ID: MusterFirma\tab-qm1
Kontoname: tab-qm1
Kontodomäne: MusterFirma
Vollqualifizierter Kontoname: MusterFirma\tab-qm1
Clientcomputer:
Sicherheits-ID: NULL SID
Kontoname: -
Vollqualifizierter Kontoname: -
ID der Empfangsstation: 7A-AC-B9-60-AA-4D:MusterFirma
ID der Anrufstation: 7A-12-11-35-FD-DC
NAS:
NAS-IPv4-Adresse: 192.168.3.100
NAS-IPv6-Adresse: -
NAS-ID: 7aacb965ac4d
NAS-Porttyp: Drahtlos (IEEE 802.11)
NAS-Port: -
RADIUS-Client:
Clientanzeigename: Anbau Büro
Client-IP-Adresse: 192.168.3.100
Authentifizierungsdetails:
Name der Verbindungsanforderungsrichtlinie: Sichere Drahtlosverbindungen
Netzwerkrichtlinienname: Sichere Drahtlosverbindungen
Authentifizierungsanbieter: Windows
Authentifizierungsserver: Con-MusterFirma.MusterFirma.local
Authentifizierungstyp: PEAP
EAP-Typ: -
Kontositzungs-ID: 33303143344531414134464334413036
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.
Wie in der zweiten Meldung zu sehen ist, klappt die Anmeldung ebenfalls nicht.
Wenn ich mich mit dem selben Benutzer, hier tab-qm1, an meinem Mobile Phone anmelde, klappt es aber.
An den Tablets stelle ich folgendes ein:
EAP-Methode -> PEAP
Phase-2-Authentifizierung-> MS-CHAP v2
CA-Zertifikat-> Radius (Das exportierte)
Domain-> MusterFirma.local
Identität-> tab-qm1
Anonyme Identität-> wir leer gelassen
PAssword-> Benutzer Password
Ich hoffe allen benötigen Informationen erwähnt zu haben.
Ja, leider klappt die Anmeldung wie bereits erwähnt an den Tablets nicht.
Daher hoffe ich das jemand aus dem Forum eine Lösung anbieten kann.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 13999642430
Url: https://administrator.de/forum/android-13-und-radius-authentication-13999642430.html
Ausgedruckt am: 22.12.2024 um 02:12 Uhr
33 Kommentare
Neuester Kommentar
Moin,
in der zweiten Meldung steht doch im Klartext:
Mit welchem AD-Namen versuchst Du die Anmeldung? domain\samaccountname oder e-mail-adresse? Schon mal das jeweils andere versucht?
Gruß
Looser
in der zweiten Meldung steht doch im Klartext:
Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet...
Mit welchem AD-Namen versuchst Du die Anmeldung? domain\samaccountname oder e-mail-adresse? Schon mal das jeweils andere versucht?
Gruß
Looser
Domain-> MusterFirma.local
Mal wieder die gleiche falsche Leier mit einer falschen TLD... Hinweise zur Verwendung der Domäne .local in DNS und mDNS
Manche lernen es nie, aber andere Baustelle...
Fakt ist ja das Username und Passwort nicht stimmen wie die Fehlermeldung ja klar sagt.
Folglich also einmal am Server debuggen und checken was dort überhaupt als Username ankommt.
Siehe zu der Thematik auch HIER im Kapitel Win Clients.
Das wird wohl entweder noch am NPS Server-Zertifikat liegen mit dem der Android-Client seine Probleme hat oder an den TLS-Ciphers. Checke das NPS Zertifkat und dessen Eigenschaften und poste diese hier.
Dann NPS-Dienst stoppen, Zertifikat neu zuweisen und wieder starten.
Stammt das NPS Zertfikat von einer Windows CA oder ist das eine andere/externe CA?
Dann NPS-Dienst stoppen, Zertifikat neu zuweisen und wieder starten.
Stammt das NPS Zertfikat von einer Windows CA oder ist das eine andere/externe CA?
Zusätzlich prüfen welche TLS-Protokolle und Ciphers auf dem NPS aktiv sind und aktuelle Chiper-Suites aktivieren.
https://www.nartac.com/Products/IISCrypto
Ciphersuites die auf Androids möglich sind stehen hier
https://developer.android.com/reference/javax/net/ssl/SSLEngine
https://www.nartac.com/Products/IISCrypto
Ciphersuites die auf Androids möglich sind stehen hier
https://developer.android.com/reference/javax/net/ssl/SSLEngine
Mit Bildchen siehst man hier ja so gut wie nix ...
Und vor allem die wichtigen ChipherSuites sehen wir auch nicht (2. Punkt). Prüfe und vergleiche mit dem Link zu den Ciphersuites die unter Android supported sind.
Welche OS hat der NPS?
Ciphers sind alle aktiv
Schlecht! Alle unsicheren gehören deaktiviert, nach Best Practice!Und vor allem die wichtigen ChipherSuites sehen wir auch nicht (2. Punkt). Prüfe und vergleiche mit dem Link zu den Ciphersuites die unter Android supported sind.
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
Welche OS hat der NPS?
Außerdem macht ein CA Zertifikat das du da aus den Zwischenzertifikzierungsstellen ausgewählt hast keinen Sinn als Server Zertifikat, das ist Bullshit. Ein Server-Zertifikat liegt auch nicht im User-Store den du da offen hast sondern im Machine Store!!
Meine Vermutung geht immer noch auf das Zertifikat.
Aber bitte jetzt keine Screenshots aus dem User-Store mehr ... Als Admin solltest du eigentlich wissen das die im Machine-Store und nicht im User-Store abgelegt sind!
Details lassen sich auch auf der Konsole abfragen (
- Stammt das von einer Windows CA?
- Läuft diese AD integriert?
- Ist es ein Wildcard-Zertifikat?
Aber bitte jetzt keine Screenshots aus dem User-Store mehr ... Als Admin solltest du eigentlich wissen das die im Machine-Store und nicht im User-Store abgelegt sind!
Details lassen sich auch auf der Konsole abfragen (
certutil -v -store my <THUMBPRINT>
) oder Powershell (Get-Item cert:\LocalMachine\My\<THUMBPRINT> | fl *
)Wenn ich das Zertifikat aus den Vertrauenswürdigen Stelle exportieren möchte, lässt er mich den Privaten Schlüssel nicht mit exportieren.
Autsch da fehlen wohl schon sämtliche Zertifikatsgrundlagen ... . Freitag halt... 🐟Auf das Tablet gehört nur die CA die das Serverzertifikat ausgestellt hat als Vertrauenswürdig importiert sonst nüscht!
Zitat von @Ueba3ba:
Als ich das Zertifikat exportiert habe und auf dem Tablet importiert habe, kam eine Fehlermeldung:
Das Zertifikat konnte wegen fehlendem Privaten Schlüssel nicht importiert werden.
Dann hast du es versucht als User-Zertifikat zu importieren, das ist natürlich falsch. Das CA Zertifikat muss man in die vertrauenswürdigen Zertifizierungsstellen importieren!Als ich das Zertifikat exportiert habe und auf dem Tablet importiert habe, kam eine Fehlermeldung:
Das Zertifikat konnte wegen fehlendem Privaten Schlüssel nicht importiert werden.
Sicherheit > Weitere Sicherheitseinstellungen > Verschlüsselung und Anmeldedaten > Ein Zertifikat installieren > CA-Zertifikat
NICHT als WLAN Zertifikat installieren, das braucht man nur wenn man mit EAP-TLS arbeitet !!!
Hatte auch nicht die Mögichkeit es als .pem zu exportieren. Nur als .cer
Das ist egal das ist nur die Endung, im inneren ist es Klartext. Mehr braucht man vom CA Cert nicht. Der Public Key reicht.Zitat von @Ueba3ba:
Meldung vom Tablet: Für die Installation von Zertifikaten ist ein Privater Schlüssel notwendig
Das ist falsch, für das Importieren einer CA braucht man keinen private Key!Meldung vom Tablet: Für die Installation von Zertifikaten ist ein Privater Schlüssel notwendig
Habe ich das falsche Zertifikat exportiert??
Ja. Ein CA Cert muss in den basicConstraints CA:True stehen haben. Wieder Screenshots mit denen man nix anfangen kann. Immer das selbe, habe ich oben aber schon angemahnt Da hat wohl jemand bei euch richtigen Bullshit getrieben als er das eingerichtet hat. Hol dir jemanden ins Boot der das für euch gerade zieht wenn du nicht die nötige Expertise dafür hast. Im Zweifel neue CA aufziehen, Server-Cert generieren einbinden und CA verteilen.
Also hast du den B... selbst verbrochen .
Dann bau dir als erstes eine vernünftige CA auf, entweder eine CA im AD installieren oder selbst eine mit XCA oder OpenSSL erstellen, sonst wird das nichts.
Fürs Flugzeug fliegen braucht man ja auch erst mal gewisse Grundkenntnisse, ohne landet man schnell wieder auf dem Boden der Tatsachen .
Also als erstes mal ein paar Tutorials zu CAs reinziehen bevor du mit dem NPS weiter machst.
Good luck.
Dann bau dir als erstes eine vernünftige CA auf, entweder eine CA im AD installieren oder selbst eine mit XCA oder OpenSSL erstellen, sonst wird das nichts.
Fürs Flugzeug fliegen braucht man ja auch erst mal gewisse Grundkenntnisse, ohne landet man schnell wieder auf dem Boden der Tatsachen .
Also als erstes mal ein paar Tutorials zu CAs reinziehen bevor du mit dem NPS weiter machst.
Good luck.
Zitat von @Ueba3ba:
Heißt das, das ich auf dem Server die Active-Directory-Zertifikatdienste installieren muss?
Muss man nicht zwingend, ist aber komfortabel und an Bord und da Verteilen der CA und Zertifikate unter Windows in der Domain gehen damit quasi automatisch, ist halt eine Variante von vielen unter Windows aber sicherilch eine bevorzugte Variante.Heißt das, das ich auf dem Server die Active-Directory-Zertifikatdienste installieren muss?
Angenommen ich erstelle eines mit XCA. Wie wäre das weitere Vorgehen??
Du solltest dir dringend erst mal die Grundlagen zu Zertifizierungsstellen anlesen, da kann man beim Aufsetzen viel falsch machen was du hinterher nur wieder gerade biegen kannst wenn du die CA neu aufsetzt. Es gibt dabei diverse Dinge zu beachten die dir jetzt vielleicht nicht wichtig sind hinterher aber wichtig werden.Wie man eine CA praktisch aufsetzt kannst du ja überall nachlesen. Aber Planung der CA Struktur CRL Distribution Points etc. ist hier wie gesagt alles, das eigentliche Erstellen ist dann PillePalle.
https://sid-500.com/2017/03/31/active-directory-zertifikatsdienste-teil- ...
https://docs.insys-icom.de/pages/en_m3_creating_certificates_xca.html
Angenommen ich erstelle eines mit XCA. Wie wäre das weitere Vorgehen??
Hier einmal am Beispiel von OpenSSL:EAP-PEAP über Radius: cert "wird nicht vertraut"
IPhone Authentifizierung am NPS nur mit Zertifikat
Oder wenn man eine pfSense oder OPNsense sein eigen nennt:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi