Domain angeben bei Android 11 unifi Enterprise WPA2

baumhof · 10. September 2021 um 09:14

Hallo zusammen,

… ein Kollege hat sich in den Ferien ein neues Handy gekauft … mit Android 11 vorinstalliert.
Jetzt wollte er, wie immer, in der Schule „mal schnell“ ins WLAN … geht aber nciht: das Android besteht beim Einloggen auf die Angabe einer Domain.
Diese heißt bei uns
bzpf.lan
und wie gebe ich das da ein?
In LDAP Notation (das wäre doch ein Totschläger: DC=bzpf,DC=lan)
Normale Eingabe hab ich probiert: hat nicht geklappt.

Wir verwenden den auf dem server installierten freeradius als auth für die unifi Clients … seit 2 Jahren ohne Probleme.

LG

Holger

foer · 10. September 2021 um 12:35

Hallo Holger,

was du da eingeben musst hängt vom Zertifikat ab, das du im Freeradius verwendest. Ich habe auf dem Server ein selfsigned-openssl-Zertifikat für die Domain: wifi.meineschule.lan erzeugt und dem Freeradius unter …/modes-enabled/eap untergeschoben. Beim Verbinden mit dem Wifi muss dann die o.g. Domain angegeben werden. Wichtig ist noch, dass die Leute bei der ersten Verwendung unter dem dann erscheinenden Punkt „Online-Zertifikatsstatus“ „Nicht prüfen“ auswählen…ansonsten müssten sie erst das CA-Zertifikat importieren und das will ich vermeiden…ist schon so recht komplex. Für die anderen Systeme (ungleich Android) hat das keine Auswirkungen bei der Anmeldung, es kommt halt die Warnung, dass sich das Zertifikat geändert hat.
Eine step-by-step Anleitung habe ich leider nicht, weil das vor einem Jahr mal ganz schnell nebenher gehen musste. Der o.g. Weg bringts aber.

LG Dominik

baumhof · 10. September 2021 um 18:35

Hallo Dominik,

tausend Dank: damit kann ich es vielelicht schaffen.
Jetzt weiß ich, dass er die Domain des Zertifikats will, nicht die des Samba (aus dem die authentifizierung stammt).
Da war ich falsch gewickelt.

Kannst du mir noch was zum Format sagen?

https://meinedomain.lan
oder
meinedomain.lan
?

Der Haken bei „nicht verifizieren“ (oder so) ist natürlich drin…

LG

Holger

foer · 10. September 2021 um 19:20

Hi Holger,

…da muss meinedomain.lan rein.

LG Dominik

DanielGross · 13. September 2021 um 10:36

Hallo zusammen,

ich habe das selbe Problem wie Holger.
Könnte mir das jemand bitte etwas ausführlicher erklären, bei dem es funktioniert?

Kann ich dafür auch das Server-Zertifikat nehmen? Oder muss das ein neu erstelltes Zertifikat sein?

LG Daniel

ChristianWd · 13. September 2021 um 13:52

Hallo miteinander,

durch diesen Thread bin ich erst darauf gekommen, dass das bei uns auch nicht mehr funktioniert (LMN6.2 und freeradius auf dem Server).
Ich habe das Wildcard Zertifikat unserer Domäne (*.pg-bs.de) in der Datei eap.conf im Konfigurationsverzeichnis von freeradius an den entsprechenden Stellen (privkey.pem, cert.pem und chain.pem) eingetragen und freeradius neu gestartet … und die Anmeldung mit der Internetdomain (pg-bs.de) hat geklappt.
VG
Christian

DanielGross · 14. September 2021 um 10:52

Hallo zusammen,

ich habe versucht die Zertifikatfiles von /etc/linuxmuster/ssl/… zu kopieren und in die @eap-Datei vom freeradius einzufügen und anzupassen.
Das sieht dann folgendermaßen aus: (die auskommentierten Zeilen sind relevant)

Mit diesen Einstellungen (meine neuen Verzeichnisse nicht auskommentiert) den Radius neu gestartet (er läuft auf dem server) und dann mit den Domänen linuxmuster.lan und server.linuxmuster.lan probiert, geht aber beides nicht.

Brauche ich ein separates Zertifikat? Wo ist mein Denkfehler???

LG Daniel

ChristianWd · 15. September 2021 um 05:05

Hallo Daniel,

das sind die snakeoil Zertifikate, von denen ich nicht weiß, welche Domain bzw. ob sie eine Domain haben. Ich schätze, hier muss man echte Zertifikate z.B. von LetsEncrypt hinterlegen.
LG
Christian

tjordan · 15. September 2021 um 05:54

Hallo zusammen,

man braucht für den RADIUS keine LE. Es wird auch ausdrücklich empfohlen, für Radius keine öffentlichen Zertifikate zu nehmen.

In der neuesten Android 11 Version musste ich für die RADIUS Konfiguration für PEAP-MSCHAPv2 sogar die CA importieren, mit der das RADIUS-Server-Zertifikat erstellt wurde. Sonst schlägt die Anmeldung am RADIUS mit dem Fehler „unknown CA“ fehlt. Man hat die vorher mögliche Funktion „nicht prüfen“ quasi vollständig deaktiviert.

Viele Grüße
Thomas

DanielGross · 15. September 2021 um 08:37

Hallo Thomas,

Wie geht das? Was muss ich da machen?

Ich habe inzwischen versucht mit openssl ein selbstsiginiertes Zertifikat für radius.linuxmuster.lan zu erstellen und key- und crt-file dem Radius unterzujubeln. Nachdem ich Rechte und Besitzer der key-Datei angepasst habe, ist damit der Radius neu gestartet. Anmeldung mit dem Handy und der Domain radius.linuxmuster.lan klappt aber weiterhin nicht :(.
VG Daniel

tjordan · 15. September 2021 um 08:52

Hallo Daniel,

wie man die CA importiert, steht hier beschrieben. Zertifikate hinzufügen und entfernen - Pixel-Hilfe

Welche CA du importieren musst, hängt davon ab, welche Zertifizierungsstelle das Zertifikat für den RADIUS-Server erstellt hat. Läuft dein RADIUS auf dem lmn7-Server, liegt das Zertifikate vermutlich unter /etc/linuxmuster/ssl. Mit openssl x509 -in /etc/linuxmuster/ssl/cacert.crt -text -noout kannst du das Zertifikat prüfen.

Wie bekommt man das aufs Smartphone? z.B. in die Nextcloud hochladen und dann mit dem Handy abrufen und entsprechend Anleitung importieren.

Viele Grüße
Thomas

PS: Zum Troubleshooten den freeradius-Dienst mit systemctl stop freeradius.service anhalten und mit freeradius -X starten. Dann siehst du die detaillierte Ausgabe mit allen Fehlern.

DanielGross · 15. September 2021 um 10:16

Hallo Thomas,

danke für deine Tipps. Jetzt läuft es

Ich habe in der Radiusdatei „eap-conf“ private_key_file=…/server.key.pem und certificate_file=…/server.cert.pem und ca_file=…/cacert.crt.

Auf Leserechte für ssl-cert (chmod 640 oder 644) für die Key-Datei achten. Danach Radius neustarten.

Die cacert.crt auf dem Handy importiert und installiert und dann klappt die Anmeldung mit der Domäne linuxmuster.lan.

VG Daniel

PS: Natürlich bin ich auf lmn7

guesswork · 22. September 2021 um 07:54

Ich bin auch gerade am Aufsetzen eines RADIUS-Servers für mein privates WLAN. Ich verwende dafür zwar kein lmn, aber für folgende RADIUS-Konfiguration (bei der auch gleich das VLAN 34 zugewiesen wird)…:

/etc/freeradius/3.0/mods-config/files/authorize:

[...]
"user123" Cleartext-Password := "password123"
	Tunnel-Type = 13,
	Tunnel-Medium-Type = 6,
	Tunnel-Private-Group-ID = 34
[...]

…verwende ich folgende Einstellungen unter Android 11:

EAP-Methode: TTLS
Phase 2-Authentifizierung: MS-CHAP v2
CA-Zertifikat: example.lan
Online-Zertifikatstatus: Nicht validieren
Domain: example.lan
Identität: user123
Anonyme Identität: [leer lassen]
Passwort: password123

Für die Sicherheit des WPA2-Enterprise-WLANs (und insbesondere der Clients) sind zwei Punkte wichtig:

Benutze unbedingt WLAN-CA-Zertifikate am Client!
Wie @tjordan geschrieben hat, sollte dabei für die WLAN-Authentifizierung ein privates, selbst-signiertes Zertifikat verwendet werden. Das könnte ja auf der Schul-Homepage öffentlich zum Download angeboten werden, es braucht nicht geheim zu sein.

Der Vollständigkeit halber hier noch die übrige RADIUS-Konfiguration als Beispiel:

AP-Konfiguration unter /etc/freeradius/3.0/clients.conf:

[...]
client ap-technikraum {
        ipaddr                  = 10.34.0.10
        secret                  = secret123
        shortname               = ap-technikraum
}
[...]

Zertifikat-Konfiguration unter /etc/freeradius/3.0/mods-available/eap:

eap {
        [...]
        tls-config tls-common {
        	    [...]
                private_key_file = /etc/freeradius/3.0/certs/radius1.example.lan.key
                certificate_file = /etc/freeradius/3.0/certs/radius1.example.lan.chain.pem
                ca_file = /etc/freeradius/3.0/certs/ca.pem
                dh_file = /etc/freeradius/3.0/certs/freeradius.example.lan_dh_4096.pem
                [...]
        }
        [...]
}

Ich verwende ein Intermediate-Zertifikat, das dann auch in der unter certificate_file angegebenen Datei enthalten sein muss.

baumhof · 10. Dezember 2021 um 10:20

Hallo Thomas,

ich würde gerne ein eigenes Cert für den Radius erstellen. Daniel hat ja (so wie es mir scheint) das vorhandene Cert der lmn auch für Radius verwendet.
Nun kann ich die vorhandene CA verwenden um das cert zu erstellen (also die gleiche CA wie das lmn Cert): kann mir jemand sagen, wie die Zeile dann aussehen muss?

openssl x509 …
?
Das wäre super.
Dann schreib ich auch am Ende eine Anleitung hier rein, wie ich das genau gemacht habe.

Ansonsten würde ich die Dateien des normalen certs in das freeradius Verzeichniss kopieren und die Radius eap conf auf diese zeigen lassen.
Die cacert.crt biete ich dann zum Download an (mit short URL).

LG

Holger

tjordan · 10. Dezember 2021 um 11:16

Hallo Holger,

ich schreibs mal hier rein:

Grundlage ist immer ein privater Schlüssel:

openssl genrsa -out radius-key.pem 4096

Hier macht es Sinn ein Password zuvergeben, welches der radius beim Start in der eap.conf unter /mods-enabled abfragt.

Auf Grundlage des eben erstellten Schlüssels wird ein neuer Zertifikatsantrag erstellt:

openssl req -new -key radius-key.pem -out radius.csr -sha512

Country Name (2 letter code) [AU]: DE
State or Province Name (full name) [Some-State]: Baden-Wuerttemberg
Locality Name (eg, city) []: Stuttgart
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Musterschule
Organizational Unit Name (eg, section) []: EDV
Common Name (e.g. server FQDN or YOUR name) []:radius.linuxmuster.lan

ACHTUNG!! Hier ist es wichtig UNBEDINGT eine sinnvolle Domain zu verwenden. Weil diese Domain von den Nutzern bei der WLAN-Konfiguration angegeben sein muss. Ein Kurzname funktioniert hier nicht mehr.

Email Address []: admin@linuxmuster.lan
Please enter the following ‚extra‘ attributes
to be sent with your certificate request
A challenge password []:whatever
An optional company name []:MS Stuttgart

Mit folgendem Befehl wird das Zertifikat „radius.pem“ ausgestellt und über die ca signiert, das 365 Tage lang gültig ist:

openssl x509 -req -in radius.csr -CA /etc/linuxmuster/ssl/cacert.pem -CAkey /etc/linuxmuster/ssl/cakey.pem -CAcreateserial -out radius.pem -days 365 -sha512

Zur Generierung benötigt man ebenfalls das Kennwort für den cakey!! (steht in /etc/linuxmuster/.secret/cakey)

Viele Grüße
Thomas

baumhof · 10. Dezember 2021 um 11:35

Hallo Thomas,

super: vielen Dank.
Ich hab mich langsam schon ein wenig eingelsen.
Bei deiner Anleitung wird also keine eigene CA erstellt, sondern die der lokalen lmn7 verwendet: das ist mir recht.
Ich würde den radius.pem aber mit einer viel längeren Zeit erstellen: 4 Jahre fände ich gut … wobei: die Geräte, die die cacert.crt importiert haben, meckern ja nciht mehr, wenn ich ein neues .pem erstelle und dem radius unterschiebe … nur die anderen … aber wer will schon jedes Jahr eine neue .pem erstellen.

Das mit dem Common Name ist mir klar: das ist der Knackpunkt.
Und deswegen will ich ja ein eigenes cert/key Paar (also .pem) erstellen: damit da radius.MEINEDOMAIN.LAN steht.

vielleicht muss ich für eap noch aus der .pem das .crt und den .key rausholen: mal sehen. Das ist nur ein Einzeiler (ich glaub eap.conf will crt und key und nciht nur .pem… aber vielelciht erinnere ich das auch falsch).

Tausend Dank: ich probier das übers Wochenende aus.

LG

Holger

tjordan · 10. Dezember 2021 um 11:43

Hallo Holger,

mit den Laufzeiten der Zertifikate ist das so eine Sache. Ich meine, mal gelesen zu haben das neuere Apple Releases eine Laufzeitbegrezung bei Zertifikaten haben.

Viele Grüße
Thomas

dorian · 10. Dezember 2021 um 11:48

Hi,

Dort steht aber auch:

This change will not affect certificates issued from user-added or administrator-added Root CAs.

VG, Dorian

tjordan · 10. Dezember 2021 um 11:59

Hallo Dorian,

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.

So ganz eindeutig ist das nicht: Hier steht maximal 825 Tage oder weniger…unabhängig davon ob es user-imported oder administartor imported ist.

Besser auf Nummer sicher gehen!

Viele Grüße
Thomas

tjordan · 10. Dezember 2021 um 12:05

Mir ist lieber: Ich weiß ich muss jedes Jahr im Februar Zertifikate tauschen, als wenn plötzlich Leute schreiend vor mir stehen, ich erst den Fehler suchen muss…weil bei manchen gehts und bei manchen nicht und es stellt sich raus, irgendwelche Clients mögen das Zertifikat nicht mehr und ich muss dann sowieso tauschen.