Es gibt verschiedene Möglichkeiten, wie sich ein Client an einem WLAN Accesspoint authentifizieren kann. Wir haben es so umgesetzt, dass die Laptops ein Zertifikat erhalten, mit dem sie sich an einem Radiusserver ausweisen müssen, damit sie Zugang ins Netzwerk erhalten.
- Der Laptop bekommt über eine Gruppenrichtlinie ein Zertifikat vom Zertifikatserver. Dazu muss der Laptop über ein Kabel am Netzwerk angeschlossen sein (z.B. beim Neuaufsetzen).
- Der Laptop stellt eine Verbindung mit dem Accesspoint her und weist sich mit seinem Zertifikat aus.
- Der Accesspoint gibt die Anfrage mit dem Zertifikat an den Radiusserver weiter. Dieser heisst bei einem Windowsserver NPS und muss nicht auf dem gleichen Server wie die PKI laufen.
- Der Radiusserver bestätigt dem Accesspoint die Gültigkeit des Zertifikates. Nun kann der Laptop eine Verbindung ins Netzwerk herstellen.
Diese Lösung hat diverse Vorteile. Zum einen lässt sie sich zentral verwalten. Ein weiterer Vorteil ist, dass niemand ein Passwort eingeben muss, dass vergessen oder weitergegeben werden kann. Ausserdem gilt diese Lösung als sehr sicher.
Migration Zertifikatserver
Wie man eine bestehende CA (Certificate Authority) migriert, wird auf dieser Technet Seite beschrieben. Auf dem Blog von Rachfahl findet man eine bebilderte Schritt-für-Schritt Anleitung. Dabei sollte der neue Server den gleichen Namen wie der alte haben. Ausserdem sollte der alte Server entfernt werden, bevor der neue eingesetzt wird. Wenn sich ein Problem ergeben sollte, ist der Rückweg versperrt. Auf dem Blog von Rachfahl wird die alte Zertifizierungsstelle zwar erst entfernt, nachdem die neue aufgesetzt wird, aber dies entspricht nicht dem empfohlenen Vorgehen gemäss der Technet Seite. Wenn man nach der Installation der neuen Zertifizierungsstelle die alte entfernt, könnte dies zu Problemen im Active Directory führen. Wie man die Einträge der CA im Active Directory findet, ist hier beschrieben. So habe ich mich aus diversen Überlegungen dazu entschieden, einen neuen Zertifikatserver aufzusetzen und den alten gar nicht zu migrieren.
Neuer Zertifikatserver
Gemäss diesem Technet-Blog-Beitrag spricht nichts dagegen, zwei PKI’s parallel zu betreiben. Aus den oben angetönten Gründen habe ich mich für diesen Weg entschieden. So habe ich also einen weiteren Server in der Domäne erstellt (diesmal kein Domänencontroller).
Dazu muss man eine neue Rolle hinzufügen.
Hier kann man die Zertifikatsdienste auswählen und muss diese dann auch noch bestätigen.
Nach diversen Klicks auf “Weiter” habe ich als Rollen “Zertifizierungsstelle” und “Zertifizierungsstellen-Webregistrierung” ausgewählt.
Nach erfolgter Installation wird im Servermanager angezeigt, dass man die Zertifikatsdienste noch konfigurieren muss.
Als Installationstyp wählt man Unternehmenszertifizierungsstelle und danach Stammzertifizierungsstelle. Dies genügt für unsere Zwecke. Wer sich dafür interessiert, wie man eine deutlich komplexere Struktur (multi-tier hierarchy) einsetzt findet in diesem Technetblog einen guten Einstieg.
Beim Namen für die Zertifizierungsstelle wird ein Name vorgeschlagen. Diesen kann man ändern, was ich aber nicht gemacht habe.
Bei der Gültigkeitsdauer habe ich grosszügig 10 Jahre genommen. So bekommen wir sicher keine Probleme bis zum nächsten Serverwechsel.
Nach ein paar “Weiter” Klicks ist die Konfiguration beendet.
Zertifikate automatisch verteilen
Die Zertifikate lassen sich automatisch über eine Gruppenrichtlinie verteilen.
Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Zertifikatdienstclient – Automatische Registrierung
Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Zertifikatdienstclient – Zertifikatregistrierungsrichtlinie
Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Einstellungen der automatischen Zertifikatanforderung
Hier ein Zertifikat auswählen, das automatisch verteilt werden soll.
Tipp: Wenn man eine eigens erstellte Vorlage verwenden möchte (statt der Standardvorlage Computer), muss man die Schemaversion der Vorlage von 2 auf 1 ändern. Dazu kann man ADSI-Edit verwenden.
WLAN Profile verteilen
Da wir keine Passwörter eingeben, sondern uns mit einem Computerzertifikat authentifizieren wollen, verwenden wir ein PEAP-TLS Verbindungsprofil, das wir über eine Gruppenrichtlinie verteilen.
Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Drahtlosnetzwerkrichtlinien (IEEE 802.11)
Durch einen Rechtsklick kann man eine neue Richtlinie hinzufügen.
Nun kann man der Richtlinie einen Namen geben und ein Infrastrukturprofil hinzufügen.
Hier kann man für ein Profil die entsprechenden SSID Namen hinzufügen.
Als Sicherheitsmethoden wird bereits WPA2-Enterprise mit AES Verschlüsselung vorgeschlagen, was im Moment die beste Sicherheit bietet.
Bei “Authentifizierungsmodus” wählt man “Computerauthentifizierung”. Ansonsten verliert der Computer die Verbindung, sobald sich jemand anmeldet. Dies könnte man umgehen, indem man auch Zertifikate für die Benutzer verteilen würde, was aber für unseren Einsatz nicht wirklich etwas bringt.
Bei “Netzwerkauthentifizierungsmethode” wählt man “Microsoft: Smartcard- oder anderes Zertifikat”. Durch einen Klick auf “Eigenschaften” kann man das Zertifikat angeben. Hier kann man einfach den Vorschlag “Zertifikat auf diesem Computer verwenden” akzeptieren. Unten muss man noch die Stammzertifizierungsstelle auswählen.
Radius Server konfigurieren
Die Clients bekommen nun also automatisch über eine Gruppenrichtlinie ein Zertifikat von der Zertifizierungsstelle (CA) und die passenden WLAN Einstellungen. Nun muss noch der Radiusserver (bei Microsoft Netzwerkrichtlinienserver NPS) konfiguriert werden. Dieser meldet den Accesspoints ob der Client eine Verbindung herstellen darf oder nicht (vgl. Grafik ganz oben).
Um NPS zu installieren, muss man über den Servermanager eine neue Rolle Netzwerkrichtlinien- und Zugriffsdienste hinzufügen.
Auf dem Radiusserver muss man nun die Clients (Accesspoints oder die Managementstation für die AP’s) hinzufügen und eine Richtlinie erstellen.
Um einen Client hinzuzufügen, macht man einen Rechtsklick auf “RADIUS-Clients” und wählt “Neu”.
Nun kann man Anzeigename, IP-Adresse und den gemeinsamen geheimen Schlüssel eintragen. Selbstverständlich muss man auf der Accesspoint-Seite die IP dieses Servers eingeben (resp. in meinem Fall anpassen) und den gleichen Schlüssel eintragen.
Mit einer Richtlinie kann man angeben, welche Voraussetzungen erfüllt sein müssen, damit der Radiusserver das OK für die Verbindung gibt. Man kann die Richtlinien manuell erstellen oder über den Szenario Assistenten erstellen lassen. Dazu wählt man bei “Erste Schritte” bei Standardkonfiguration “Radius-Server für drahtlose oder verkabelte 802.1X-Verbindungen” aus und klickt auf “802.1X konfigurieren”.
Im ersten Fenster wählt man “Sichere Drahtlosverbindungen” und gibt einen Namen für die Richtlinien.
Im nächsten Fenster könnten man die Radius-Clients hinzufügen. Einen habe ich schon vorher manuell hinzugefügt (vgl. oben).
Bei der Authentifizierungsmethode wählt man “Microsoft: Smartcard- oder anderes Zertifikat”
Nun kann man noch Benutzergruppen angeben. Dies habe ich nicht gemacht. Alle Computer mit gültigem Zertifikat dürfen sich bei uns über WLAN am Netzwerk anmelden, unabhängig vom angemeldeten Benutzer.
Auch Datenverkehrssteuerelemente werden in unserem Fall nicht benötigt.
Und so werden nun eine Verbindungsanforderungsrichtlinie und eine Netzwerkrichtlinie erstellt, die man manuell überprüfen kann.
Wichtig ist nun noch, dass man die Radius-Clients auch so umstellt, dass sie sich mit dem neuen Radiusserver verbinden.
Zusätzliche Aufgaben bei einer Ablösung eines alten Servers
So wie das oben beschrieben ist, kann man WLAN mit Zertifikaten neu aufsetzen. Wenn man aber wie ich einen alten Server ohne Unterbruch der WLAN Verbindungen ablösen möchte, gibt es noch ein paar Dinge, die man beachten sollte.
Zertifikat des Radiusservers
Wir haben bei der Verteilung der WLAN-Profile über Gruppenrichtlinien angegeben, dass die Identität des Servers über dessen Zertifikat überprüft werden soll. Wenn wir nun den Radiusserver wechseln, weist sich der neue mit dem neuen Zertifikat aus, was vom Client nicht automatisch akzeptiert wird. Daher muss man beim WLAN Profil beide Server als vertrauenswürdige Stammzertifizierungsstellen angeben.
Damit der Client diese Änderung bei den Gruppenrichtlinien erfährt, muss er einmal am Netzwerk gestartet werden. Dies bedeutet, dass man einen Zeitpunkt festlegen und dies den Mitarbeitern mitteilen muss, bis zu dem alle Laptops einmal gestartet werden müssen. Falls ein Laptop in dieser Zeit nicht gestartet wurde, kann er danach nicht mehr automatisch eine Verbindung mit dem Netzwerk herstellen. Am einfachsten startet man ihn dann einmal mit eingestecktem Netzwerkkabel, damit er die Einstellung erhält und danach auch wieder automatisch eine Verbindung über WLAN herstellt.
Zertifikate der Clients
Da die beiden Zertifizierungsstellen (CA’s) im Active Directory eingetragen sind, vertrauen sie einander und auch den Zertifikaten voneinander. So spielt es also keine Rolle, von welcher Zertifizierungsstelle das Zertifikat des Clients ausgestellt wurde.
Solange die alte CA auch noch vorhanden ist, können beide Zertifikate ausliefern. Es kann aber nur eine CA Zertifikate ausliefern, die auch die entsprechende Zertifikatvorlage besitzt. Um die alte CA davon abzuhalten, neue Zertifikate auszuliefern, kann man also einfach die entsprechende Vorlage auf der alten CA löschen (in meinem Fall war das die Vorlage “Computer”).
Besser wäre eine duplizierte Vorlage, wie ich sie neu verwende. Dazu dupliziert man bei den Zertifikatvorlagen die Vorlage Computer.
Der neuen Vorlage habe ich den Namen “ComputerzertifikatWLAN” gegeben.
Wenn man nun nur bei der lokalen Zertifizierungsstelle des neuen Servers die Vorlage aktiviert, liefert auch nur dieser Zertifikate dieser Vorlage aus.
Sobald also alle Zertifikatvorlagen von der alten Zertifizierungsstelle gelöscht sind werden die Zertifikate von der neuen Zertifizierungsstelle ausgestellt. Wenn auf der neuen Zertifizierungsstelle die neu erstellte Vorlage die einzige für die Clientauthentifizierung ist, bekommen nun alle Clients ein solches Zertifikat, sobald sie ein neues anfordern.
Die alten Zertifikate bleiben aber bestehen, bis sie ablaufen, bei mir wäre das ein Jahr. Sinnvoll wäre es also, wenn die Clients schon vor Ablauf des Zertifikats ein neues beziehen, damit man den alten Server deinstallieren kann.
Die Zertifikate vom Computer kann man in einer Mangement Konsole (MMC) ansehen (mmc –> Datei –> Snap-In hinzufügen/entfernen –> Zertifikate –> Computerkonto) oder unter Windows 8 certlm.msc starten.
Wenn man einen Rechtsklick unter “Zertifikate (Lokaler Computer)” –> “Eigene Zertifikate” –> “Zertifikate” macht, kann man “Alle Aufgaben” –> “Neues Zertifikat anfordern…” auswählen und sich ein neues Zertifikat ausstellen lassen.
Man kann dies automatisieren, indem man bei den Zertifikatvorlagen die gewünschte auswählt und über einen Rechtsklick “Alle Zertifikatinhaber erneut registrieren” lässt.
Dies funktioniert aber leider nur mit duplizierten Vorlagen, die von mir damals verwendete Standard-Vorlage “Computer” lässt dies nicht zu.
Man kann auch mit dem Befehl “certreq” erreichen, dass ein neues Zertifikat von den Clients bezogen wird:
certreq -q -enroll -machine ComputerzertifikatWLAN
Diesen Befehl könnte man z.B. als renewcertificate.bat abspeichern und über SCCM an alle Clients verteilen. Windows 7 bringt aber eine Meldung wegen fehlender Berechtigung (obwohl die Berechtigung über den Weg mit der graphischen MMC ausreicht und der gleiche Befehl unter Windows 8 problemlos funktioniert).
Wenn man eine neue Vorlage erstellt und diese über die automatische Zertifikatanforderung verteilt, wird diese beim nächsten Start bezogen. So bekommen alle Computer schnell ein Zertifikat vom neuen Server. Somit kann demnächst der alte Server deinstalliert werden…
und zum anderen haben wir auch noch Schüler/-innen, die nach einer solchen Mitteilung vielleicht erst recht die Datei ausführen. 
![image_thumb[1]](https://ictschule.files.wordpress.com/2014/08/image_thumb1.png "image_thumb[1]")
![image_thumb[2]](https://ictschule.files.wordpress.com/2014/08/image_thumb2.png "image_thumb[2]")
ictschule 