RADIUS, Zertifikate, Unifi

chrissps · September 26, 2019, 12:56pm

Hallo allerseits!
Wir haben bei unserem Domaincontroller den Radius-Server installiert und wollen diesen für unsere WLAN authentifizierung nutzen.
Wir haben unser eigenes Wildcard-Zertifikat in UCS(Apache2) und Radius importiert und es funktioniert alles auf z.B. iPhone. → Heißt, ich kann mich mit einem iPhone im WLAN mit einem Domain-User und seinem Kennwort anmelden. (Werde aber gefragt, ob ich dem Zertifikat vertrauen möchte - nicht vertrauenswürdig)

Das Webinterface zu UCS erreiche ich ohne Fehlermeldung.

Jetzt der Fehler: Ich kann mich unter unseren Windows-Maschinen nicht in diesem WLAN anmelden!
Hat wer Erfahrung mit sowas?

Hello everyone!

We have installed the Radius server at our domain controller and want to use it for our WLAN authentication.
We have imported our own wildcard certificate into UCS(Apache2) and Radius and it all works on e.g. iPhone. --> Means I can log in with an iPhone in the WLAN with a domain user and his password. (But I am asked if I want to trust the certificate - not trusted).

I reach the web interface to UCS without an error message.

Now the error: I can't log on to this WLAN under our Windows machines!
Does anyone have experience with this?

msi · September 26, 2019, 1:27pm

Weil ich das Problem erst kürzlich selber erneut hatte in kürze bei einer anderen Installation: Windows mag keine Wildcard-Zertifikate für RADIUS.

Wenn man freeradius im Debugmodus laufen lässt und eine Anmeldung von Windows mitschneidet, sieht man an einem Punkt, wie Windows bei der TLS-Verbindung abbricht, ehe die MSCHAPv2 challgne abgewickelt wird. Leider gibt dir Windows auf seiner Seite eigentlich keine sinnvolle Fehlermeldung. Das war beim letzten Fall wo ich mir das Zertifikat genauer angeschaut habe.

Kein anderes mir bekanntes Betriebssystem hat damit sonst Probleme (Linux, Android, macOS). Du brauchst zwingend ein Zertifikat, welches auf einen Hostnamen ausgestellt ist. Es kann übrigens auch für mehrere Hosts über Einträge im Subject Alternate Name augestellt sein, wenn du mehrer RADIUS-Server hast.

Siehe dazu: https://wiki.freeradius.org/guide/certificate-compatibility

Man kann den Windows supplicant über Profile (z.B. via GPOs) auch korrekt dazu zwingen, Verbindungen mit einer bestimmten SSID aufzubauen, wenn das Zertifikat des RADIUS-Server von einer bestimmten CA, ausgestellt auf bestimmte Namen ist. (Das kann durchaus sinnvoll sein, um den Supplicant gegen böse Zwillinge (Evil twin Problematik) etwas abzusichern.

chrissps · September 27, 2019, 7:01am

Danke!

Ich würd ja gerne die SSID nach anwenden der Richtlinie “(Drahtlosnetzwerkrichtlinien (IEEE 802.11)” sagen, dass das jetzt klappt… tut es aber auch nicht… Ich kann ja beim Zertifikat nur die Stammzertifizierungsstellen auswählen… und da ist genau unser Zertifikat nicht enthalten…

Selbst wenn ich das Häkchen bei “Identität des Servers mittels Zertifikatsprüfung überprüfen” rausgebe, bekomm ich keine Verbindung…

Was mir aber auffällt, ist dass ich unter iOS das Zertifikat bestätigen muss und da wird angezeigt, es wäre nicht vertrauenswürdig… komisch, denn es ist auf allen anderen servern und diensten absolut vertrauenswürdig

msi · September 27, 2019, 9:44am

Auf dem Rechner, wo du die GPOs editierst, musst du die CA in die “Vertrauenswürdigen Stammzertifizierungsstellen” importieren. Der Group Policy Editor wertet den CA-Store von deiner Kiste aus. Danach müsste es gehen. Im Worst case (erinnere ich mich nicht mehr genau) musst du die CA gar nicht nur in dein Profil, aber in den CA speicher des Systems laden. Wenn du in einer leeren MMC.exe das Snap-In Zertifikate/Certificates hinzufügst, kannst du das entsprechend wählen.

Schreib doch mal, von welcher CA ihr das Zertifikat habt. Evtl. habt ihr noch die Zwischenzertifikat nicht korrekt konfiguriert resp. im Zertifikat von FreeRADIUS hinterlegt. Das könnte die Meldung mit iOS erklären.

Die Zwischenzertifikate (ohne die Root CA) müssen in der richtigen Reihenfolge im Zertifikatfile enthalten sein, welches FreeRADIUS einbindet. Schau mal, ob nur 1 Zertifikat (also nur jeweils 1x "-----BEGIN CERTIFICATE----- " und “-----END CERTIFICATE-----” erscheint)

Genauere schreib ich sonst gerne, sollte das zutreffen.

Windows ist sehr pingelig was RADIUS und Zertifikate anbelangt. Es gibt leider keinen “egal was mit Zertifikaten und Co nicht stimmt, verbinde jetzt einfach trotzdem”-Button.

Beachte einfach: Die Nutzung von einem Zertifikat einer öffentlichen CA hat Vor- und Nachteile bei RADIUS:

Vorteil: Ich muss in der Regel keine CA-Zertifikate zusätzlich auf den Endgeräten installieren
Nachteil: Wenn du den CN nicht einschränkst (was Windows kann, aber nicht alle anderen Plattformen[1]), so vertraut ein Client, selbst wenn du die CA einschränkst, allen Serverzertifikaten dieser CA aler RADIUS-Server mit dieser SSID. Ich kann also von z.B. Comodo ein Zertifikat bekommen, und eine gleiche SSID aktivieren. Bei einer eigenen CA ist die Kontrolle enger. Die hast du ja prinzipiell mit UCS bereits.

Grüsse und bin gespannt auf deine Antwort.

[1] Soweit ich mich entsinne, kann man unter iOS als Endbenutzer von Hand immer noch nicht die CA festlegen und den CN prüfen. Einzig wenn du dir die Mühe machst, iOS .mobileconfigs zu verteilen kannst du das festlegen. - Was dank kostenlosen Diensten wie https://enterprise-wifi.net schmerzloser als früher geworden ist. (Disclaimer: Ich bin Nutzer)

chrissps · October 2, 2019, 9:43am

Also ich hab das Zertifikat wie beschrieben importiert (auch root-zertifikate von den ausstellern) und es geht trotzdem nicht…

Infos zu unserem Zertifikat:

Allgemeiner Name (CN)	GeoTrust TLS RSA CA G1
Organisation (O)	DigiCert Inc
Organisationseinheit (OU)	www.digicert.com

Bezüglich der Zwischenzertifikate:

wie mach ich das am freeradius?

Wir wollen auf jeden Fall unser öffentliches Wildcard-Zertifikat verwenden…

msi · October 2, 2019, 11:45am

In aller Kürze: Ihr braucht zuallererst ein Zertifikat, welches nicht ein Wildcard-Zertifikat ist. Vorher wird es mit Windows nicht klappen, egal ob die Intermediates im RADIUS-Server korrekt eingebunden sind oder nicht oder in einer GPO etwas falsch ist.

Wildcard ist mit RADIUS und Windows schlicht und einfach ausgeschlossen, das habe ich gleich zu Beginn geschrieben. Der Grund ist der Supplicant von Windows, der solche Zertifikate grundsätzlich ablehnt.

Ein Zertifikat einer öfffentlichen CA geht mit Windows dann, wenn es auf einen Servernamen ausgestellt ist. Wenn ihr ein öffentliches Zertifikat wollt, reicht ein Domain-Validiertes (DV) von einer CA - in dem Fall wohl Comodo? Die kosten auch nicht viel, sind tendenziell günstiger sogar als Wildcard.

Behalte folgendes im Hinterkopf: Zum Zeitpunkt der WLAN-Authentifizierung haben Clients keine Möglichkeit im Netz das Zertifikat genauer zu prüfen (CRL, OCSP). Dein Zertifikat kann auf den FQDN des UCS RADIUS ausgestellt sein (wenn es ein öffentliche registrierte Domain ist, also gerade nicht .local), muss es aber nicht. Es kann auch fancyradius.<meineöffentlichedomain>. sein.

Windows akzeptiert dann eine Verbindung, wenn (u.a.) folgendes erfüllt ist:

Serverzertifikat ist von einer vertrauenswürdigen CA
Intermediates werden in der korrekten Reihenfolge vom RADIUS-Server übermittelt
Bestimmte OIDs müssen im Serverzertifikat sein resp. Extended Key Use (EKU)
Optional: Stammt das Zertifikat von einer bestimmten CA?
Optional: Ist das Zertifikat auf einen bestimmten Namen ausgestellt?

Die beiden letzten Elemente kann man bei Apple und den meisten Windows-Versionen öfters nur über Profile konfigurieren. Bei Windows also über mit netsh importierte XML-Dateien oder eben GPO, bei Apple über .mobileconfig Dateien.

Wo geht das nicht? Unter Windows im GPO-Editor oder jetzt beim RADIUS-Server?

Für FreeRADIUS-Teil empfehle ich folgenden Post von der FreeRADIUS-Liste, der mir selber geholfen hat.

Vielleicht gibts auch bessere Artikel (hab ihn in meinen Favoriten gespeichert), dort wird aber sauber mit OpenSSL beschrieben, wie man die Zertifikate selber prüft und in welcher Reihenfolge man sie ins Zertifikatbundle reinbekommt, welches dann FreeRADIUS laden soll.

chrissps · October 3, 2019, 6:10am

Oh mist… und ich dachte das kann ich trotzdem irgendwie umgehen…

Das heißt, wenn ich das Standard Zertifikat vom ucs-freeradius wieder rein gib und dieses per Gruppenrichtlinie als “Sicheres Stammzertifikat” hinzufüge, sollte es gehen?

Ich bekomme immer unter Windows die Meldung in der Ereignisanzeige: “6105 - deauth EAPOL key exchange sequence” (beim Verbinden lässt er mich nichtmal user und kennwort eingeben) und wenn ich wie lt windoof beschrieben per registry die TLS-Versionen downgrade, was ich eigentlich nicht möchte, kann ich mich zumindest mal anmelden, die Verbindung wird aber trotzdem abgelehnt.

Danke ich schau mal weiter Und sorry, ich brauch bei so zertifikats-sachen immer etwas länger…

msi · October 3, 2019, 6:39am

Ja, sollte. Da die UCS CA nur eine Root CA und keine Intermediate (Issuing) CA hat, muss nur das Serverzertifikat selber eingebunden sein. Natürlich muss der fragliche Rechner zuerst über LAN die aktualisierte GPO bezogen haben (oder du importierst das Zertifikat zum testen kurz manuell in den Cert-Store)

Der genannte Fehler kann vieles sein, das ist genau das Problem von Windows: Du kriegst weder im User Interface, noch in den Logs etwas schlaues hingeklatscht, die Meldung ist generisch genug, dass man verschiedene Antworten darauf findet…

Also ich entsinne mich nicht, dass man Windows dafür mit FreeRADIUS zu einem TLS downgrade zwingen muss, um mit FreeRADIUS zu arbeiten. Ich tippe mal darauf, dass ihr einen Schritt weiterkommt, sobald ihr ein Zertifikat im RADIUS-Server habt, welches die Anforderungen von Microsoft erfüllt.

Die Ausgabe von FreeRADIUS im Debugmodus mag zu Beginn etwas verwirren, aber sie hat mir zig mal bereits geholft, weil ich am Client keine sinnvolle Meldung bekomen habe bei Problemen. Deswegen ist der Standardspruch auf der FreeRADIUS-Liste derjengie, dass man Debuglogs liefern soll

chrissps · October 3, 2019, 7:19am

Also ich hab keine “eap_peap: ERROR: TLS Alert read:fatal:unknown CA” mehr, sondern “eap_peap: ERROR: TLS Alert read:fatal:access denied”…

Aber immerhin schon besser als vorher

msi · October 3, 2019, 7:44am

Hach, bin wohl etwas pingelig, aber von wo kommt dieser Fehler jetzt - Windows oder FreeRADIUS?
Vom Format her hätte ich jetzt auf FreeRADIUS getippt, aber auch nur weil Windows eine Event ID meist mitgibt.

Macht doch folgendes (und was freeradius.org selber ja auch sagt):

# Stoppe FreeRADIUS
systemctl stop freeradius

# FreeRADIUS im debugmodus starten
freeradius -X

# Bei längeren Logs kann auch helfen, dann hast du den Output und ein Logfile in /tmp für die Analyse
freeradius -X | tee /tmp/radiusdebug.log

# Mit Ctrl-C stoppst du FreeRADIUS im Debumodus.

# Nachher (nicht vergessen)
systemctl start freeradius

Dann poste hier diesen Debug Log. Wenn es FreeRADIUS, sind vermutlich die Rechte auf der Zertifikatsdatei falsch. Den Pfad zu Zertifikat und private Key wird bei UCS über eine UCR-Variable vorgegeben. (hast du das so gelöst oder einfach die Zertifikatsdateien modifiziert?)

Wie du die Standardzertifikate (für ein renewal) korrekt installierst, siehst du in diesem KB-Artikel. Da siehst du auch, dass die Rechte auf root:freerad gesetzt sein müssen.

chrissps · October 3, 2019, 7:58am

Okay ich hab gerade mit einem linux-client versucht, mit dem standardmäßigen zertifikat (also domaincontroller.domain.at) einzusteigen - unknown CA… wenn ich aber das root-ca vom server selbst angebe als zertifikat, funktioniert es. soll ich also unter /etc/freeradius/ssl das root-zertifikat vom server reinstellen?

Ich hab den originalordner umbenannt und einfach unsere zertifikate so umgeschrieben, dass sie im vorgegebenen Format dazu gepasst haben… also hab jetzt den original-ordner wiederhergestellt und trotzdem…

Ja, die Fehlermeldung kommt vom freeradius. (radius.log) sorry…

Debug lass ich gleich laufen und stells dann rein

chrissps · October 3, 2019, 8:07am

Also hier ein kleiner Ausschnitt aus dem debugger.
Hier hab ich das zertifikat verwendet, das vom root-zertifikat ausgestellt wurde.
Wenn ich das root-zertifikat selbst verwende, funktionierts (zumindest auf linux). Aber das root-zertifikat war ja standardmäßig auch nicht drin

(90) eap: Expiring EAP session with state 0x5013864651cf9c3c
(90) eap: Finished EAP session with state 0x861748ba82c551b4
(90) eap: Previous EAP request found for state 0x861748ba82c551b4, released from the list
(90) eap: Peer sent packet with method EAP PEAP (25)
(90) eap: Calling submodule eap_peap to process data
(90) eap_peap: Continuing EAP-TLS
(90) eap_peap: Peer indicated complete TLS record size will be 7 bytes
(90) eap_peap: Got complete TLS record (7 bytes)
(90) eap_peap: [eaptls verify] = length included
(90) eap_peap: <<< recv TLS 1.2  [length 0002] 
(90) eap_peap: ERROR: TLS Alert read:fatal:unknown CA
(90) eap_peap: TLS_accept: Need to read more data: error
(90) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
(90) eap_peap: ERROR: System call (I/O) error (-1)
(90) eap_peap: ERROR: TLS receive handshake failed during operation
(90) eap_peap: ERROR: [eaptls process] = fail
(90) eap: ERROR: Failed continuing EAP PEAP (25) session.  EAP sub-module failed
(90) eap: Sending EAP Failure (code 4) ID 210 length 4
(90) eap: Failed in EAP select
(90)     [eap] = invalid
(90)   } # authenticate = invalid
(90) Failed to authenticate the user
(90) Login incorrect (eap_peap: TLS Alert read:fatal:unknown CA): [christoph.fischer/<via Auth-Type = eap>] (from client AP-VA-01-1-5 port 0 cli macadress)
(90) Using Post-Auth-Type Reject
(90) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(90)   Post-Auth-Type REJECT {
(90) attr_filter.access_reject: EXPAND %{User-Name}
(90) attr_filter.access_reject:    --> christoph.fischer
(90) attr_filter.access_reject: Matched entry DEFAULT at line 11
(90)     [attr_filter.access_reject] = updated
(90)     [eap] = noop
(90)     policy remove_reply_message_if_eap {
(90)       if (&reply:EAP-Message && &reply:Reply-Message) {
(90)       if (&reply:EAP-Message && &reply:Reply-Message)  -> FALSE
(90)       else {
(90)         [noop] = noop
(90)       } # else = noop
(90)     } # policy remove_reply_message_if_eap = noop
(90)   } # Post-Auth-Type REJECT = updated
(90) Delaying response for 1.000000 seconds

Hier noch die tls-config auch aus dem Befehl “freeradius -X”:

        tls-config tls-common {
        verify_depth = 0
        ca_path = "/etc/freeradius/3.0/certs"
        pem_file_type = yes
        private_key_file = "/etc/freeradius/ssl/private.key"
        certificate_file = "/etc/freeradius/ssl/cert.pem"
        ca_file = "/etc/univention/ssl/ucsCA/CAcert.pem"
        dh_file = "/etc/freeradius/3.0/certs/dh"
        fragment_size = 1024
        include_length = yes
        auto_chain = yes
        check_crl = no
        check_all_crl = no
        cipher_list = "DEFAULT"
        ecdh_curve = "prime256v1"

was ist jetzt der Unterschied zwischen dem ca_file und dem certificate_file? Das certifikate_file ist in dem Pfad, wo ich die Zertifikate editiert habe und das ca_file ist das root-Zertifikat…

Edit:
Hab noch was: Unter windows schreit der debugger anders:

(44) eap: Expiring EAP session with state 0x8bae07358ed11ed8
(44) eap: Finished EAP session with state 0x8bae07358ed11ed8
(44) eap: Previous EAP request found for state 0x8bae07358ed11ed8, released from the list
(44) eap: Peer sent packet with method EAP PEAP (25)
(44) eap: Calling submodule eap_peap to process data
(44) eap_peap: Continuing EAP-TLS
(44) eap_peap: Peer indicated complete TLS record size will be 37 bytes
(44) eap_peap: Got complete TLS record (37 bytes)
(44) eap_peap: [eaptls verify] = length included
(44) eap_peap: <<< recv TLS 1.0 Alert [length 0002], fatal access_denied 
(44) eap_peap: ERROR: TLS Alert read:fatal:access denied
(44) eap_peap: WARNING: No data inside of the tunnel
(44) eap_peap: [eaptls process] = ok
(44) eap_peap: Session established.  Decoding tunneled attributes
(44) eap_peap: PEAP state ?
(44) eap_peap: ERROR: Tunneled data is invalid
(44) eap: ERROR: Failed continuing EAP PEAP (25) session.  EAP sub-module failed
(44) eap: Sending EAP Failure (code 4) ID 127 length 4
(44) eap: Failed in EAP select
(44)     [eap] = invalid
(44)   } # authenticate = invalid
(44) Failed to authenticate the user
(44) Login incorrect (eap_peap: TLS Alert read:fatal:access denied): [christoph.fischer/<via Auth-Type = eap>] (from client AP-VA-01-1-5 port 0 cli 28-16-AD-1B-BF-AC)
(44) Using Post-Auth-Type Reject
(44) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(44)   Post-Auth-Type REJECT {
(44) attr_filter.access_reject: EXPAND %{User-Name}
(44) attr_filter.access_reject:    --> SPS\\christoph.fischer
(44) attr_filter.access_reject: Matched entry DEFAULT at line 11
(44)     [attr_filter.access_reject] = updated
(44)     [eap] = noop
(

chrissps · October 4, 2019, 9:39am

Sodalla…
Also wenn ich ein nicht-domain notebook reinhänge ins WLAN, geht es auch nicht. Ausnahme:

Die Zertifikate wurden importiert
Das WLAN wurde von Hand in die gespeicherten Verbindungen aufgenommen

Ohne dem lässt er mich nichtmal username und Kennwort eingeben…

Wenn ich jetzt das gleiche über die GPO mache, rührt sich gar nichts…
Debug output:

(9109) eap_peap: ERROR: TLS Alert read:fatal:access denied
(9109) eap_peap: WARNING: No data inside of the tunnel
(9109) eap_peap: [eaptls process] = ok
(9109) eap_peap: Session established.  Decoding tunneled attributes
(9109) eap_peap: PEAP state ?
(9109) eap_peap: ERROR: Tunneled data is invalid
(9109) eap: ERROR: Failed continuing EAP PEAP (25) session.  EAP sub-module failed
(9109) eap: Sending EAP Failure (code 4) ID 210 length 4
(9109) eap: Failed in EAP select
(9109)     [eap] = invalid
(9109)   } # authenticate = invalid
(9109) Failed to authenticate the user
(9109) Login incorrect (eap_peap: TLS Alert read:fatal:access denied): [christoph.fischer/<via Auth-Type = eap>] (from client AP-VA-01-1-5 port 0 cli 28-16-AD-1B-BF-AC)

chrissps · June 18, 2020, 5:59am

Ich hab mich in der Vergangenheit ein wenig gespielt und hab meine Lösung gefunden:

Ich hab die Zertifikate für den RADIUS Server erneuert, alle Radius Konfigurationen neu geschrieben und unter das Zertifikat nicht mehr für “alle” Zwecke freigegeben sondern nur für das Authentifizieren für das WLAN. Ich hab herausgefunden, dass unsere Windows Clients in diesem Fall Zertifikate, die für alle Zwecke freigegeben sind, komplett ignorieren… Sachen gibts.

Vielen dank aber für die Hilfe!

Translation:
I have renewed the certificates for the RADIUS server, rewritten all Radius configurations and no longer released the certificate for "all" purposes but only for authentication for the WLAN. I found out that in this case our Windows clients completely ignore certificates that are released for all purposes...