 |
| Themenwochenende: IEEE 802.1X & EAP-TLS (LAN/WLAN) :: Dynamische VLANs mit FreeRADIUS und dem GS108Tv2 |
|
|
|||||||||||||||||||||
|
|||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
ACHTUNG: Dieser Beitrag wurde für FreeRADIUS v2.x geschrieben!
Für v3.x braucht es einige Anpassungen, die noch nicht enthalten sind. Ob und wann dieser Beitrag überarbeitet wird, steht noch nicht fest…  IEEE 802.1X, vielleicht auch besser bekannt in Zusammenhang mit EAP (Extensible Authentication Protocol), ist eine Möglichkeit, um für kabelgebundene Netzwerke (Ethernet) eine Authentifizierung zu verlangen. Für WLAN gibt es diese Möglichkeit ebenfalls, dort ist es meistens unter dem vielversprechenden Namen WPA2-Enterprise bekannt. Um letzteres geht es in diesem Beitrag noch nicht, dafür folgt im Laufe des Wochenendes ein zweiter und dritter Blogpost. Normalerweise sind die typischen Heimnetzwerke, aber auch viele kleinere Firmennetzwerke, immer so aufgebaut, dass sich an der Netzwerkdose jeder anstecken kann. Ein normales Patchkabel reicht aus und schon ist man im Netzwerk und kann viel Unfug treiben. Das ist besonders gefährlich, wenn man nicht jeden Netzwerkanschluss im Blick hat, wodurch auch ein Spionagegerät schnell angestöpselt werden kann. In Zeiten von immer kleiner werdenden Mikrocomputern mit viel Rechenleistung und Speicherplatz eine echte Gefahr. Solche Ängste wären bei meinem Heimnetzwerk natürlich übertrieben. Aber auch hier gibt es reale Einsatzzwecke, die das Thema in den Fokus meiner Begierde rückten:
Die Authentifizierung soll mittels EAP-TLS (X.509 Zertifikate) erfolgen. Zum Einsatz kommt ein GS108Tv2 von Netgear. Es handelt sich dabei um einen leistbaren Smart-Managed Switch aus der ProSAFE Reihe, der kaum Wünsche offen lässt. Er bietet 8 Ports und lässt sich auf Wunsch sogar mittels PoE in das Netzwerk integrieren. Mein erster dieser Switches ist bereits seit 2011 in Betrieb. In den damals typischen älteren Firmware Versionen (u.a. 5.0.x) wurde laut diversen Forenbeiträgen nur EAP-MD5 unterstützt, was mittlerweile als unsicher gilt und von aktuellen Windows Versionen auch nicht mehr unterstützt wird. Die aktuellste Firmware (5.4.x) unterstützt aber auch mein präferiertes EAP-TLS einwandfrei, wodurch einem Test im Jahr 2016 nichts mehr im Weg stand! Nebenbei wird auch IPv6 endlich zur Verwaltung unterstützt. Alle Schritte wurden mit der Firmware Version 5.4.2.22 getestet. Der GS110TPv2 nutzt übrigens die gleiche Firmware und ist für manche Anwendungsszenarien besser geeignet. Für den doppelten Preis bekommt man PoE auf allen Ports (dafür kann er selbst nicht über PoE betrieben werden) und zwei SFP-Einschübe. Dafür muss man auch kleinere Abstriche bei der Größe in Kauf nehmen, in einen 10-Zoll Netzwerkschrank passt er nicht mehr! Wer noch mehr Ports braucht, findet bei der ProSAFE Reihe viele weitere Modelle, die sich allerdings teilweise im Funktionsumfang unterscheiden. Grundlegendes zu RADIUS beim GS108Tv2 Um IEEE 802.1X bzw. EAP nutzen zu können, wird ein RADIUS-Server benötigt. Dieser sorgt für die eigentliche Verarbeitung der Anfragen, der Switch ist quasi nur der Vermittler dazwischen. Wenn man RADIUS auf diesem Switch nutzen möchte, ist es wichtig, dass man versteht, wie der Switch intern arbeitet. Zur Authentifizierung gibt es bei Netgear Listen, in diesem Fall nur eine einzige, nämlich die defaultList. Darüber wird später nicht nur geregelt, wie die Anmeldung an einem Ethernetport verifiziert wird, sondern auch der Login zur Telnet-/Weboberfläche vom Switch selbst! Der RADIUS-Server ist also auch dafür verantwortlich, dass es für den admin Benutzer vom Switch einen passenden Eintrag mit einem Passwort gibt. Darauf gehe ich später nochmals im Detail ein. Sobald RADIUS am Switch eingerichtet ist, erfolgt die Überprüfung der Zugangsdaten für das administrative Switchmanagement nicht mehr direkt am Gerät. Das gespeicherte Passwort im Switch dient nur noch als Fallbacklösung, falls der RADIUS-Server nicht erreichbar ist. Im Falle ungültiger Zugangsdaten sendet der RADIUS-Server ein REJECT, der Login am Switch scheitert dadurch sofort. Das gilt, wie bereits geschrieben, auch für Telnet und eventuell auch für SNMP(v3). Letzteres nutze ich aber nicht aktiv für einen schreibenden Zugriff, damit habe ich keine Erfahrung. Tipp: Falls der Switch in einem eigenen abgeschotteten VLAN arbeitet, was immer zu empfehlen ist, sollte der RADIUS-Server auch in dieses VLAN gesteckt werden. Somit vermeidet man unnötige Umwege über Router und sorgt für ein wenig mehr Sicherheit und eventuell sogar eine höhere Verfügbarkeit. Die Kommunikation zwischen Switch und RADIUS-Server kann damit nicht mehr so leicht abgefangen und manipuliert werden. Das ist zwar nicht unbedingt erforderlich, es sorgt aber für eine saubere Trennung der Netzwerkbereiche. FreeRADIUS installieren und konfigurieren Unter Linux ist FreeRADIUS als Software die erste Wahl. In diesem Blogbeitrag geht es nur um die Version 2.2.x, andere Versionen sollten aber ähnlich zu konfigurieren sein. Prinzipiell kann man das freeradius(2) Paket auf jedem System installieren, wo man möchte. Selbst ein Raspberry Pi oder der Router eignen sich problemlos dafür. Unter OpenWrt 15.05.1 gibt es allerdings einen bekannten Kernelbug, der radiusd beim Eintreffen der Authentifizierungsanfrage in eine Endlosschleife jagt. Die Vorgängerversion OpenWrt 15.05 und die aktuellen Snapshots sind offenbar nicht betroffen. Wer sich für die Installation unter OpenWrt entscheidet, sollte nicht vergessen den FreeRADIUS-Konfigurationsordner in der /etc/sysupgrade.conf einzutragen! Ich habe mich aufgrund der Bugs aber für die Installation innerhalb eines neuen KVM-Gastsystems unter Debian Jessie entschieden. An den nachfolgenden Schritten ändert es wenig, es müssen nur ein paar Pfadangaben geändert werden. Unter OpenWrt heißt der Ordner z.B. /etc/freeradius2 (statt /etc/freeradius) und die ausführbare Datei heißt radiusd (statt freeradius). Unter Debian ist die Installation kinderleicht: Code:
Wer noch keine eigene PKI/CA (Public Key Infrastruktur & Certification Authority) für seine Zertifikate hat, kann z.B. Easy-RSA nutzen. In Debian ist es als eigenes Paket enthalten: Code:
Auf die Nutzung gehe ich jetzt nicht näher ein, da es dazu schon extrem viele Seiten im Internet gibt, z.B. auch der Teil über Easy-RSA im Debian Wiki oder der Absatz darüber im OpenWrt Wiki. Das würde außerdem den Rahmen dieses Beitrags sprengen, da man dazu grundlegende Themen von TLS ansprechen müsste. Es gibt auch grafische Tools zur Verwaltung einer PKI/CA, für nahezu jedes Betriebssystem. Ich gehe davon aus, dass das CA-Zertifikat, eines für den RADIUS-Server und mindestens eines für jeden Client (den anzuschließenden Computer) generiert wurde. Deshalb springe ich direkt zur Konfiguration von RADIUS. Die Standardkonfiguration unter Debian ist für den ersten Start relativ brauchbar, es lohnt sich aber mindestens ein Blick in die /etc/freeradius/radiusd.conf, besonders auth=yes ist von Vorteil! Danach müssen folgende Dinge in der /etc/freeradius/eap.conf angepasst werden: Code:
Gerade der letzte Teil ist enorm wichtig, da ansonsten zwar das Zertifikat überprüft wird, aber nicht ob der angegebene Benutzernamen dem CN (Common Name) entspricht! Man könnte sich somit als x-beliebiger User ausgeben, was durch die spätere VLAN-Zuweisung ein Sicherheitsproblem wäre. Bevor weitergemacht werden kann, werden die angegebenen DH-Parameter generiert: Code:
Die existierenden Snakeoil Zertifikate kann man getrost löschen: Code:
Danach können die Dateien ca.pem, server.pem und server.key mit den eigenen Zertifikaten befüllt werden. Weiter geht es in der Datei /etc/freeradius/clients.conf, wo am Ende ein neuer Block hinzugefügt wird: Code:
Die IP-Adresse muss vom Switch sein. Beim "secret" muss ein sicheres Passwort gewählt werden, mit dem der Switch später alle Anfragen weiterleitet. Bitte unbedingt beachten, dass der GS108Tv2 offenbar keine Passwörter mit 32 Zeichen unterstützt! 16 Zeichen funktionieren problemlos, irgendwo darüber existiert dieses magische Limit. Das Webinterface meldet beim Eintragen desselben keinen Fehler, man merkt es erst in den Logs vom FreeRADIUS-Server. Ich war allerdings zu faul, die exakte Maximallänge herauszufinden, falls das jemand nachholen möchte, bitte die Erkenntnisse in den Kommentaren melden. Ich vermute aktuell, dass es auf 20 gesetzt ist. Benutzerdatenbank einrichten Es gibt viele Möglichkeiten FreeRADIUS zu nutzen. Von LDAP bis MySQL ist alles erdenkliche drinnen. Für die ersten Gehversuche empfiehlt sich aber eine simple Textdatei: /etc/freeradius/users 
Wie bereits zu Beginn angesprochen, braucht man neue (zusätzliche) Zugangsdaten für die Weboberfläche vom Switch. Code:
Beim Passwort bitte ein sicheres eintragen! Auch hier gilt, dass der GS108Tv2 keine zu langen Passwörter unterstützt. Auf der sicheren Seite ist man mit einer Maximallänge von 16-20 Zeichen. Der Service-Type ist besonders wichtig, da man ansonsten nur Read-Only Zugriff auf die Administrationsoberfläche vom Switch bekommt. Dieses Detail war extrem schwer zu finden. Wenn man den RADIUS-Server auch noch für andere Zwecke nutzen möchte oder mehrere Switches mit unterschiedlichen Adminpasswörtern betreiben möchte, kann man tricksen: Code:
Ein leerer NAS-Port (also 0) heißt, dass die Anfrage von keinem Ethernetport, sondern vom Gerät selbst kommt. Mittels NAS-IP-Address kann man es auch noch auf die IP-Adresse vom Switch beschränken. Das kann man mit beliebigen Variablen kombinieren, auch reguläre Ausdrücke sind möglich: Code:
Die Konfiguration von FreeRADIUS ist für die ersten Tests damit abgeschlossen, für die VLAN-Zuweisung muss später aber noch etwas hinzugefügt werden. Für den Anfang empfiehlt sich der Debug-Modus, damit man jeden Fehler sofort sieht: Code:
Tipp: Wenn die Details nicht reichen, einfach -XX verwenden, dann gibt es noch mehr Ausgaben. Manchmal ist es auch hilfreich einen Netzwerksniffer einzusetzen. tcpdump liefert sehr viele Details über die RADIUS-Kommunikation, wenn es mit -v oder -vv aufgerufen wird.  Switch vorbereiten und erste Tests
Bevor es ernst wird und alles wie auf dem Bild rechts abgesichert ist, ein wichtiger Warnhinweis: Unbedingt ein Backup der funktionierenden Switch Konfiguration anlegen! Die nächsten Schritte können sehr leicht dazu führen, dass man sich selbst aussperrt und nichts mehr am Switch ändern kann. Mir ist das drei Mal passiert, einmal bei der VLAN-Einrichtung vor einigen Jahren und zwei Mal bei der 802.1X Einrichtung im Rahmen dieses Beitrags. In so einem Fall hilft nur noch ein Zurücksetzen auf Werkseinstellungen. Dafür gibt es eine kleine Taste "Factory Defaults" auf der rechten Seite, die mit einer aufgebogenen Büroklammer für mindestens 5 Sekunden gedrückt werden muss. Danach sind auch alle VLAN-Einstellungen zurückgesetzt, wodurch zum Zurückspielen des Backups oft sogar eine temporäre Neuverkabelung notwendig werden kann. Falls kein DHCP-Server (ohne VLAN!) zur Verfügung steht, muss vielleicht sogar direkt ein Computer am Switch angeschlossen und mit einer statischen IP-Adresse konfiguriert werden. Das alles nur als Warnhinweis am Rande. Wer damit nicht vertraut ist, sollte das vorher unbedingt einmal üben. Wenn man die Schritte genau befolgt und mitdenkt, sollte zwar nichts schief gehen, trotzdem ist es besser, wenn man weiß, was im Notfall zu tun ist. In der Weboberfläche vom Switch geht es weiter! Je nachdem, welche Protokolle eingerichtet und aktiviert sind, ist der Zugriff entweder über HTTPS oder HTTP über die IP-Adresse vom Switch möglich. Sofern keine statische Netzwerkkonfiguration gewählt wurde, wird die Adresse über DHCP bezogen. Der Login muss jetzt noch mit den im Switch hinterlegten Zugangsdaten erfolgen, das im RADIUS-Server eingetragene Passwort ist noch absolut wertlos! Falls noch nie ein Passwort vergeben wurde, lautet es password und sollte gleich geändert werden. Auf der Seite Security » Management Security » RADIUS » Server Configuration muss zuerst einmal der vorhin eingerichtete RADIUS-Server eingetragen werden. Neben der IP-Adresse vom RADIUS-Server braucht man jetzt auch das gewählte Passwort ("secret") aus der clients.conf: 
Bitte nicht durch den zweiten Server verwirren lassen! Normalerweise reicht ein Server, ich habe zum Test aber auch noch einen weiteren Eintrag hinzugefügt. Danach müssen bei der Global Configuration einige Dinge angepasst werden: 
Für den Anfang sollte ein niedriger Wert für die erneuten Versuche ("Max Number of Retransmits") und das Timeout für den RADIUS-Server ("Timeout Duration") gewählt werden. Schlägt die Verbindung nämlich fehl, weil der Server z.B. nicht läuft oder eine Firewall die Verbindung blockiert, wird erst nach Ablauf dieser Zeitspanne auf die Local Liste zurückgegriffen! Beim gezeigten Screenshot wären das 2 × 5 Sekunden. Der Menüpunkt Authentication List ist die nächste Anlaufstelle: 
Die defaultList muss angepasst werden. Wie bereits in der Einleitung geschrieben, handelt es sich dabei um die einzige verfügbare Quelle zur Authentifizierung. Sie gilt somit nicht nur für die Ethernetports, sondern auch für den Login auf der Weboberfläche vom Switch! Als erste Quelle muss RADIUS ausgewählt werden, als zweite folgt Local. Letzteres ist sehr wichtig, da ansonsten kein Login am Switch mehr möglich ist, wenn der RADIUS-Server ausgefallen ist oder eine Fehlkonfiguration vorliegt! Nach dem Übernehmen der Einstellungen sollte der Browsertab unbedingt geöffnet bleiben. Ich empfehle zusätzlich einen anderen Browser oder ein Inkognitofenster (privater Tab) zu öffnen, damit man den Login zum Switch testen kann, ohne sich auszusperren. Falls etwas nicht klappt, könnte man die Einstellungen sofort wieder zurückändern, damit nur noch Local in der defaultList genutzt wird. Wenn der Login übers Webinterface funktioniert, sollte folgendes im Protokoll von FreeRADIUS auftauchen: Code:
Taucht stattdessen nur eine Fehlermeldung oder auch gar nichts auf, geht es weiter zur Fehlersuche. Der Debugmodus von FreeRADIUS ist dabei sehr hilfreich und sollte detailliert zeigen, woran es scheitert. Ich gehe an dieser Stelle davon aus, dass alles geklappt hat. Falls nicht, bitte in den Kommentaren oder im Forum melden. Switch scharf schalten Der erste große Schritt ist damit geschafft! Jetzt beginnt die Konfiguration der einzelnen Ports, um die es eigentlich geht. Unter Security » Port Authentication » Advanced » Port Authentication beginnt der eigentliche Spaß: 
Dieser Schritt ist enorm wichtig, dabei sollten keine Fehler passieren! Jeder Port, für den später keine Authentifizierung gewünscht oder wo es unmöglich ist, muss im Feld Port Control auf Authorized eingestellt werden. Nur so ist er nachher als Force Authorized markiert. Dazu zählen meistens Uplink-Ports, eventuell Tagged-VLAN-Ports und natürlich Ports, die Wartungszwecken dienen und immer erreichbar sein müssen. Wer sich unsicher ist, welche Ports derzeit genutzt werden, wirft lieber nochmals einen kontrollierenden Blick beim Tab Switching auf die aktuell angeschlossenen Geräte. Unter Port Summary sollte danach nochmals kontrolliert werden, ob die gewünschten Ports wirklich mit forceauthorized auftauchen. Wenn alles doppelt und dreifach kontrolliert wurde, kann beim Menüpunkt 802.1X Configuration alles scharf geschaltet werden: 
Für den Anfang reicht ein Enable bei Port Based Authentication State, alles andere kann vorerst auf Disable gelassen werden. Unter Port Authentication zeigt das Feld Authenticator PAE State jederzeit den aktuellen Status eines Ports an.  Die erste Verbindung mit EAP-TLS unter Linux
Für die ersten realen Tests empfiehlt sich ein zweiter Computer, damit man die Ausgaben von FreeRADIUS weiterhin im Blick haben kann und zur Not auch am Switch Änderungen vornehmen kann. Falls das nicht möglich ist, hilft auch eine zweite Netzwerkkarte. Über USB kann man z.B. mit der D-Link DUB-E100 einen weiteren Ethernetport nachrüsten. Unter GNU/Linux funktioniert diese OOTB. Im nachfolgenden Beispiel wird die Konfiguration unter Xubuntu 15.10 mit dem NetworkManager gezeigt. Bei anderen Distributionen wird es ähnlich funktionieren. Das CA-Zertifikat und das Zertifikat sowie der Schlüssel für den Client müssen zuvor auf den Zielrechner kopiert werden. Am einfachsten ist es einen USB-Stick zu nutzen. Wenn die private Schlüsseldatei für den Client durch kein Passwort geschützt ist, bei Easy-RSA ist das eventuell nicht der Fall, muss das für den NetworkManager nachgeholt werden. Dieser scheint nämlich keine Schlüsseldateien ohne Passwort zu akzeptieren. Mit OpenSSL ist das aber sehr schnell erledigt: Code:
Danach steht der weiteren Einrichtung nichts mehr im Weg:  
Wie bereits weiter oben erwähnt, ist das Setup so geplant, dass der CommonName vom Zertifikat dem Benutzernamen ("Identität") entspricht. Die gewählten Dateinamen sind logischerweise völlig egal. Wenn alles richtig eingetragen wurde, kann die Verbindung auch schon hergestellt werden. Wenn alles erfolgreich war sollte ein entsprechender Protokolleintrag bei FreeRADIUS erscheinen und der Port in der Weboberfläche des Switches als Authorized markiert werden. Code:
Leider hat diese Methode einige Nachteile: Das Passwort für die Schlüsseldatei wird im Keyring des aktuellen Benutzers gespeichert. Man könnte es zwar in der Konfigurationsdatei vom NetworkManager manuell angeben, bei der nächsten Änderung über die GUI wird es aber wieder in den Keyring verschoben. Andere Benutzer haben somit keinen Zugriff auf das Netzwerk, bis sie das Passwort erneut angeben. Vorausgesetzt die Zertifikatsdateien sind für sie überhaupt lesbar. Benutzer mit eingeschränkten Rechten (Desktop-User) haben überhaupt keine Möglichkeit sich zu authentifizieren. Da der erste angemeldete Benutzer die Netzwerkverbindung herstellt, ist das äußerst ungünstig. Eine brauchbare Lösung bietet aktuell nur eine manuelle Konfiguration, wie im nachfolgenden Abschnitt beschrieben. Unter Linux, ohne NetworkManager… Back to the roots! Es geht auch ohne den NetworkManager, was den großen Vorteil hat, dass die Verbindung unabhängig vom angemeldeten Benutzer hergestellt wird und bereits kurz nach dem Bootvorgang verfügbar ist. Auf DHCP muss auch dabei nicht verzichtet werden, man kann die Einstellungen halt nicht mehr direkt über die GUI ändern. Alle Befehle sind in einem Terminal mit root-Rechten auszuführen. (su / sudo -s) Unter Ubuntu ist es standardmäßig enthalten, bei Debian muss es erst nachinstalliert werden: Code:
Die Zertifikate und Schlüsseldatei sollten an einem globalen Ort (z.B. /etc/eap/tls) abgelegt werden, der Zugriff kann auf den root-User beschränkt werden: Code:
Wer nicht ganz sattelfest mit den Befehlen ist, findet hier einen schnellen Überblick: Code:
Die wpas.conf ist die Konfigurationsdatei für den WPA Supplicant: Code:
Bei identity gehört der Benutzername (CommonName) aus dem Zertifikat eingetragen, das Passwort der Schlüsseldatei muss bei private_key_passwd eingetragen werden. Die Pfade sind entsprechend anzupassen. Danach steht dem ersten Test auf der Konsole nichts im Weg: Code:
Falls die Netzwerkschnittstelle nicht eth0 heißt, bitte entsprechend abändern! Hat alles geklappt, kann es fix in die /etc/network/interfaces eingetragen werden: Code:
Für IPv6 muss noch folgendes hinzugefügt werden: Code:
Wer lieber DHCPv6 statt SLAAC nutzt, kann auto durch dhcp austauschen, verliert dadurch aber wahrscheinlich die Privacy Extensions! Im NetworkManager kann der Eintrag für das Kabelnetzwerk jetzt entfernt werden. Danach ist ein Neustart des Computers die schnellste Methode, um alles zu übernehmen. Falls etwas nicht geklappt hat, bitte einen Blick ins Syslog werfen und notfalls im Kommentarbereich oder Forum melden. Und was ist mit Windows? Ich bin zwar größtenteils weg von Windows, dieser Blogbeitrag wäre aber nur die Hälfte wert, wenn Windows als Client nicht wenigstens ganz kurz behandelt werden würde. Für den Mac muss ich mangels Testgeräten leider passen. Prinzipiell sollte es für EAP-TLS aber zahlreiche Anleitungen im Internet geben. Die nachfolgende Anleitung wurde unter Windows 7 Professional getestet. Unter Windows ist vieles anders, auch das Handling mit Zertifikaten! Zuerst muss das Client Zertifikat und der private Schlüssel in ein anderes Format konvertiert werden: Code:
Die neue pfx-Datei muss danach irgendwie auf das Windows-System gebracht werden. Vorzugsweise auch hier wieder mittels USB-Stick. Dort werden die enthaltenen Zertifikate mit einem Rechtsklick installiert bzw. importiert:     
Dabei ist eines ganz wichtig: Das Zertifikat darf nach dem Import durch kein Passwort geschützt sein! Die Sicherheitsstufe Hoch und ähnliche Spielereien sind hierbei also komplett tabu. Damit es als Client-Zertifikat genutzt werden kann, muss es unter Eigene Zertifikate abgelegt werden. Das CA-Zertifikat muss genauso installiert werden, allerdings unter dem Speicherort Vertrauenswürdige Stammzertifizierungsstellen:    
Bevor es weiter geht, muss ein Dienst über Computerverwaltung (Rechtsklick auf Computer / Verwalten) » Dienste und Anwendungen » Dienste aktiviert werden: Automatische Konfiguration (verkabelt) Einmal kurz über die Eigenschaften öffnen, damit der Starttyp auf Automatisch gesetzt werden kann. Ein weiterer Klick auf den Starten Button erspart einen lästigen Neustart von Windows…  
Unter Systemsteuerung » Netzwerk und Internet » Netzwerkverbindungen muss der Einstellungsdialog der zu ändernden Netzwerkschnittstelle geöffnet werden. Beim neu hinzugekommenen Tab Authentifizierung werden alle Einstellungen vorgenommen:   
Wichtig hierbei ist, dass das vorher importierte Stammzertifikat ausgewählt wird. Nachdem alles gespeichert wurde, kann das Netzwerkkabel erstmalig angesteckt werden. Im Benachrichtigungsbereich sollte nun ein Popup erscheinen, das angeklickt werden muss: 
Im nachfolgenden Dialog muss das vorher importierte Zertifikat ausgewählt werden. Der Benutzername sollte automatisch dem CommonName vom Zertifikat entsprechen: 
Die Verbindung sollte jetzt immer problemlos hergestellt werden, ohne weitere Rückfragen! 
Die installierten Zertifikate sind übrigens, wie üblich, über Systemsteuerung » Netzwerk und Internet » Internetoptionen » Inhalte » Zertifikate einseh-/änderbar. Leider gibt es auch hier bei Multiuser Systemen keine befriedigende Lösung. Die Zertifikate müssten für jeden User importiert werden, trotzdem baut der erste angemeldete Benutzer die Verbindung auf. Unterschiedliche Zertifikate je Benutzer am gleichen PC machen somit bei kabelgebundenen Netzwerken wenig Sinn. Außerdem dürfte Windows etwas verbuggt sein, wenn man Benutzer wechselt. Falls ich dabei eine simple Lösung übersehen habe, bitte in den Kommentaren melden! Ein globales Zertifikat für den ganzen Computer konnte ich bei meinen Tests jedenfalls nicht einbinden. Dynamische VLANs, WPA2-Enterprise, … All das folgt im zweiten und dritten Teil der kleinen Blogserie. Dieser Beitrag ist eh schon aufgebläht genug! Bis morgen, dann geht es weiter… |
|||||||||||||||||||||
|
|||||||||||||||||||||
|
||||
  |
|
|||