Radius und Backupserver

Radius für WLAN - da gibt es 2 Varianten:

PEAP (EAP-Mschapv2) oder PEAP (EAP-TLS).

Bei erster Variante authentisiert sich der Radius-Server selbst beim anfragenden Client mit dem Radius Serverzertifikat.
Dieses Zertifikat kannst du auf beliebigen Radius-Servern verwenden, der Hostname oder DNS Name des Radius-Servers ist unerheblich für diesen Anwendungszweck. Einfach Serverzert exportieren und auf dem Backup NPS importieren (Certsotre Local Computer) und in der RAS Policy bei Profile.. Authentication.. EAP einbinden. Der Client dagegen authentisiert sich bei dieser Variante beim Radius-Server mit seinen Domaincredentials (Username / Kennwort) und benötigt kein Clientzertifikat. Allerdings braucht der Client das Root CA Zertifikat der CA, die das Radiusserverzertifikat signiert hat.
Sonst würde der Client dem Radiusserver Zertifikat nicht vertrauen.

Bei zweiter Variante authentisiert sich der Radiusserver mit seinem Servercert beim anfragenden Client - und der Client hat auch ein eigenes Clientzertifikat, mit dem er sich beim Radius authentisiert. Hier macht eine PKI die ins AD integriert ist Sinn, damit die Clients automatisch ihr individuelles Clientzertifikat bekommen.

Bei beiden Varianten muss das Root CA Zertifikat (nicht das Radiusserverzertifikat) an die Clients verteilt werden (Certstore "Vertrauenswürdige Stammzertifizierungsstellen") da der Client dem Radiusserver ja sonst nicht vertraut. Das Prinzip ist da selbe wie bei https://postbank.de - der Posstbank Webserver sendet beim Zugriff meinem Browser sein webzertifikat, und damit ich sicher sein kann, dass dies tatsächlich der Postbankserver ist, muss ich diesem Zertifikat vertrauen. Und das kann ich nur, wenn das Postbankzertifikat von einer Root CA signiert wurde, deren Root CA Zertfiikat sich in meinem Certstore "vertrauenswürdige stammzertifizierungsstellen" befindet. Ggfs. muss auch ein "intermediate CA Zertifikat" ( je nach Cert-chain ) installiert werden im entspr. Ordner.

Das wird funktionieren weil das Root Zertifikat das du verteilst auch die Root CA Zertifikate (zufällig.. hehe) enthält.
Das Radiuszertifikat das auf dem Client installiert wird hat ansonsten garkeine Auswirkungen da es ja bei EAP-MSchapv2 nicht verwendet wird da der Client sich nur mit seinen Domaincredentials authentisiert.


wenn sich der client mit nem zertifikat (und nicht mit domaincredentials) anmelden soll, musst du in der NPS policy eben "Smartcard oder anders Zertifika" wählen anstelle von "Protected EAP". Das wäre dann EAP-TLS.
Der Client braucht ein Clientzertifikat das für diesen Zweck "Clieintauthentisierung" ausgestellt ist.

Ist aber garnicht trivial das zum laufen zu bringen - die Clients im AD (benutzerkonten) müssen mit dem jeweiligen Clientzert verbunden werden (AD Konsole.. Benutzer und Comptuer.. Ansicht.. alles einblenden, das ist nämlcih normal ausgeblendet in den Benutzer-Eigenschaften im AD). Macht meines Erachtens nur Sinn wenn man die CA auf dem AD laufen hat, aber damit machst du ein ziemliches Fass auf - erstmal in ner Testumgebung testen wg. Nebenwirkungen
Ansonsten ist EAP-TLS noch ein wenig sicherer als EAP-Mschapv2 weil ja sonst jeder der in WLAN Reichweite ist mit nem Domain-Kennwort ins Netz kommt, auch Anwender die mit ihrem Android Smartphone rumlaufen. Mit Clientzert muss ja erstmal das Zertifikat aufs Endgerät, und wenn das mit ner Passphrase geschützt ist kann das keiner installieren der das Kennwort für die Installation nicht kennt. Allerdings ist das echt nicht so einfach, da brauchste im Vergleich zum relativ einfachen EAP-MSchapv2 schon viel Zeit zum Testen und Verstehen. Versuch erstma die einfache Variante sauber zum laufen zu bringen.

Das Root CA Zertifikat ist nur eine Art "Beglaubigung", dass das Radius Serverzert vertrauenswürdig ist.
Wenn das garnicht verteilt wird, bekommt der Anwender eine Aufforderung, das Zertfifikat zu bestätigen wenn er sich mit dem WLAN verbinden will, bzw. der RAdius-Server schickt das ggfs. fehlende Root-Zertifikat zum Anwender.