07.06.2024

2582

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:

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/contentid/13999642430

Ausgedruckt am: 21.11.2024 um 16:11 Uhr

33 Kommentare

Neuester Kommentar

Moin,

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

Hey Looser, danke für deinen Beitrag.

Ja, habe schon versucht mich mit: benutzername@domain.local anzumelden.

Funktioniert nicht.

Mit dem selben Benutzer an einem Iphone oder Android Handy funktioniert es.

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.

Hallo qaui, danke für deinen Beitrag.

Zu meiner Verteidigung: Die Domain ist schon 8 Jahre alt und wurde vor meiner Zeit erstellt.

Habe Benutzername und Password überprüft. Wurde beides korrekt eingegeben.

Kontoname:			tab-qm1

Für mich sieht es so aus, das der Benutzername korrekt ankommt.

Versuche mal folgende Syntax beim Benutzernamen:

domain\\samaccountname

(ja die 2 \ sind Absicht)

Versuche mal folgende Syntax beim Benutzernamen:

Leider ohne Erfolg.

Passen die Netzwerk-Einstellungen an den Geräten? Können die Problemlos alle benötigten Resourcen erreichen? Grätscht da vielleicht eine Firewall-Regel dazwischen?

IP soll via DHCP bezogen werden, das passt.

Bei allen anderen Geräten funktioniert es ja. Selbst am PC hab ich Wlan Adapter aktiviert und mich erfolgreich verbinden können.

Nur die Tablets machen mir einen Strich durch die Rechnung.

Ich check das eben mit WireShark mal ab.

Auch im WireShark sehe ich, das der Benutzername korrekt übertragen wird.
Danach folgt: Access-Reject

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?

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

Danke hempel, für deinen Beitrag.

Hier mal die Eigenschaften der Zertifikats und die aktivierten TLS-Protokolle.

Ciphers sind alle aktiv

Zitat von @Ueba3ba:
Hier mal die Eigenschaften der Zertifikats und die aktivierten TLS-Protokolle.

Mit Bildchen siehst man hier ja so gut wie nix ...

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!!

Welche OS hat der NPS?

Windows Server 2016 DC

Die von Android 13 unterstützten Chiphers sind aktiviert.

Ich werde nichts deaktivieren, da ich nicht weiß welche Auswirkungen das auf das Netzwerk hat.
Ich soll heute nur 802.1X zum laufen bringen. Was ja eigentlich schon läuft, eben nur auf den Tablets nicht.

Meine Vermutung geht immer noch auf das Zertifikat.

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

Denke auch das das zertifikat nicht passt, im grunde müsstest du doch das root-ca zertifikat importieren auf den androids und nicht das nps server zertifikat.
Warum eigentlich PEAP-MSCHAPv2 und nicht EAP-TLS ?

Warum eigentlich PEAP-MSCHAPv2 und nicht EAP-TLS ?

Es ist Benutzername und Passwort Authentifizierung gewollt, nicht Zertifikat basierte Authentifizierung.

Stammt das von einer Windows CA?

Ich habe kein Zertifikat erstellt. Denke also nein.

Läuft diese AD integriert?

Weiß ich nicht, denke aber nein.

Ist es ein Wildcard-Zertifikat?

Nein

Wenn ich das Zertifikat aus den Vertrauenswürdigen Stelle exportieren möchte, lässt er mich den Privaten Schlüssel nicht mit exportieren.

Ich denke pebcak hat recht, ich habe das falsche Zertifikat(NPS Zertifikat) in die Tablets importiert.

Habe ich nur getan, da ich wie oben erwähnt:

Wenn ich das Zertifikat aus den Vertrauenswürdigen Stelle exportieren möchte, lässt er mich den Privaten Schlüssel nicht mit exportieren.

Der private schlüssel des server ( oder ca ) zertifikats wird auch nicht auf den clients benötigt ( und hat da natürlich auch nichts zu suchen)

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!

Autsch da fehlen wohl schon sämtliche Zertifikatsgrundlagen ..

Zugegeben, ja. Da fehlt mir noch Erfahrung.

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.

Hatte auch nicht die Mögichkeit es als .pem zu exportieren. Nur als .cer

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!

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.

NICHT als WLAN Zertifikat installieren, das braucht man nur wenn man mit EAP-TLS arbeitet !!!

Ja, ich hatte auf WLAN gedrückt und nicht auf auf CA-Zertifikat.

Werde ich gleich ausprobieren.

Vielen Dank.

Selbe Fehler wenn ich es als CA-Zertifikat importieren möchte.

Meldung vom Tablet: Für die Installation von Zertifikaten ist ein Privater Schlüssel notwendig

Habe ich das falsche Zertifikat exportiert??

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!

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.

Das ist falsch, für das Importieren einer CA braucht man keinen private Key!

Gut, zur Kenntnis genommen.

Da hat wohl jemand bei euch richtigen Bullshit getrieben als er das eingerichtet hat.

Auf dem Server habe ich gestern nur den NPS installiert. Unifi AP's als Clients hinzugefügt und Secret vergeben.
AD Gruppe angelegt und Benutzer hinzugefügt.
Sonst habe ich an dem System nichts verändert.
Und der Server ist der Domain Controller.

Wieder Screenshots mit denen man nix anfangen kann. Immer das selbe, habe ich oben aber schon angemahnt

Verzeihung.

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.

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??

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.

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