Hallo Allerseits. Wir werden in einer kleinen Schritt-für-Schritt Anleitung erfahren, wie wir die Authentifizierung für Wireless Client ein wenig härten können.

Bemerkung: Ein paar Voraussetzung (Oder auch nicht) für diesen Post.

• Wir haben bereits einen funktionierenden Cisco Wireless-Controller mit angebunden Access-Points.
• Wir verfügen bereits über ein Wireless LAN welches via PSK gesichert ist.
• Cisco ISE ist installiert und funktionsfähig.
• Man solle sich mit dem Admin Portal der ISE zurecht finden.

Und nun ran an dem Beispiel…

Bei der Anmeldung des Clients am Netz, schickt der Wireless Controller eine Reihe an Informationen, für die Authentifizierung der des Clients, an die Cisco ISE weiter.

Alle drei Geräte haben hier eine Rolle oder einen Name:

• Client: Supplicant
• Cisco Wireless-Controller: Authenticator
• Cisco ISE: Authenticator Server

Der Client spricht nur den Wireless-Controller an, dieser baut anschliessend die Verbindung mit dem Authenticator Server auf, schickt die Daten und wartet auf eine Antwort.

Für die Authentifizierung benötigen wir in diesem Fall ein Inner- (MSCHAPv2) und Outer (EAP-TLS) method. Was nichts anderes bedeutet, als dass zuerst einen Tunnel aufgebaut wird, der die ganze Kommunikation sichert und das Inner method (MSCHAPv2) transportiert.

Diese ist eine High-Level Beschreibung, wie die Authentifizierung via MSCHAPv2 als Inner-Method aussieht. Es fehlen sicher ein paar Schritte, welche simplifiziert worden sind (z.B EAP-TLS Tunnel), dennoch reicht es aus, um das Konzept oberflächlich zu verstehen.

Die verschiedenen Angaben des Clients werden nun auf der ISE überprüft und sequentiell gegen die Policy-Sets verglichen. Gibt es einen Treffer, dann wird dieser Policy-Set abgearbeitet. Zuerst Authentifizierung und anschliessend wird die Autorisierung durchgeführt. Es kann auch vorkommen, dass die Authentifizierung erfolgreich abgeschlossen worden ist, aber dennoch diese Sitzung nicht zustande kommt, da für die Kriterien für die Autorisierung nicht übereinstimmen.

Zum Beispiel kann eine Person zwar einen Benutzername und ein Passwort haben und sich erfolgreich authentifizieren, aber die Maschine von der er sich versucht anzumelden ist nicht autorisiert in das Netz zu gelangen.

Somit wird hier der unterschied zwischen Authentifizierung und Autorisierung erklärt. Während der Authentifizierung wird bestätigt wer ich bin und bei der Autorisierung was ich darf.

Nun zu unserem Scenario.

Ich bin im Besitz von zwei Wireless fähige Geräte:

1. Android Smartphone (MAC-Adresse 24:18:1D:F3:C6:B0)
2. Microsoft Surface (MAC-Adresse C0:33:5E:34:AB:67)

Beide Clients werden sich mit dem selben Benutzername und Passwort am Netz anmelden. wir werden dafür sorgen, dass nur das Smartphone in der Lage in das Netzwerk zu gelangen.

Die Überprüfung der Anmeldung wird über die Cisco ISE erfolgen. Für diesen Test steht uns die Version 2.6 zur Verfügung.

Die Topologie sieht wie folgt aus.

Um unseren Test erfolgreich durchzuführen müssen wir Anpassungen an der ISE und am WLC vornehmen.

Konfiguration auf der ISE

Gruppe erstellen, um die Clients zu gruppieren.

Unter „Administration -> Identity Management -> Groups -> Endpoints Identity Groups -> +“ kann man eine neue Endpoint-Gruppe auf dem System erfassen. Wir haben die Möglichkeit während und auch nach der Erfassung der MAC-Adresse diese in eine Gruppe zu hinzufügen. Dies erfolgt wenn man „Static Group Assignment“ eincheckt und die Gruppe manuell aus der Drop-Down Liste auswählt.

MAC-Adressen des Clients erfassen und zu einer Gruppe zuordnen

Unter „Context Visibility -> Endpoints -> +“ kann man eine neue MAC-Adresse auf dem System erfassen. Wir haben die Möglichkeit (Und es wird empfohlen) während der Erfassung der MAC-Adresse diese in eine Gruppe zu hinzufügen. Dies erfolgt wenn man „Static Group Assignment“ eincheckt und die Gruppe manuell aus der Drop-Down Liste auswählt.

Benutzergruppe erstellen

Unter „Administration -> Identity Management -> Groups -> Users Identity Groups -> + Add“ können wir eine neue Gruppe anlegen. Im selben fenster können wir auch einen neuen User hinzufügen und automatisch zu dieser Gruppe zuordnen lassen.

Policy-Set erstellen

Policies werden auf der Cisco ISE genau wie bei einer Firewall sequentiell abgearbeitet und sobald es einen Treffer gibt, dann wird nur diese Policy bearbeitet und die restlichen ignoriert. Daher sollte man bei der Platzierung der Policy aufpassen, dass es nicht von einer anderen abgefangen wird und ebenfalls sollte man die Bedingungen so wählen, dass bestehende Policies weiterhin funktionieren.

Hier sehen wir ein Beispiel wie ein Policy-Set aussehen könnte.

Policy Kondition: Wenn ein Radius Paket von dem in „Default Access Network“ kommunikationskanäle kommt, dann… weiter

Authentication Policy: Wenn Authentifizierung über 802.1x erfolgreich gegenüber ALL_User_ID_Stores, dann… weiter

Authorisation Policy: Wenn User in der Gruppe „Administrators“ UND die MAC-Adresse in der Endpoint-Gruppe „Trusted_Devices“ vorhanden ist, dann wird das Authorisierungs-Profil „Permit Access“ appliziert, und der User kiregt voller Zugang zum Netz. Wird diese Konditionen nicht erfüllt, dann wird das Autorisierungs-Profil „Deny Access“ appliziert und die Verbindung zum Netz schlägt fehl.

zuletzt müssen wir unser Wireless Controller in die ISE einbinden. Später werden wir genau das selbe auf der Gegenstelle durchführen.

Unter „Administration -> Network Resources -> Network Devices -> + Add“ können wir diverse Angaben zum Controller eintippen.

Wir brauchen einen Name, um den Controller innerhalb der ISE zu identifizieren. Zudem wird auch die IP-Adresse des Host benötigt. Es können zusätzliche Angaben zum Gerät gemacht werden wie: Location oder Device Type, welche uns bei der Erstellung der Policy-Sets/Konditionen behilflich sein können, um eine grössere Granularität zu erreichen. Das werden wir in einem späteren Post genauer anschauen.

Anschliessend müssen wir die Angaben für die RADIUS Anbindung konfigurieren. In unserem Fall braucht es nur ein „Shared Secret“, welches auf beiden übereinstimmen sollen.

Konfiguration auf dem Cisco Wireless Controller

Wo wir bei der ISE aufgehört haben, fangen wir auf dem WLC an. Wir werden. Wir müssen für die Authentication und Accounting zwei separate Einträge erstellen.

Unter dem Security Tab im Menu „AAA -> RADIUS -> Authentication“ und „AAA -> RADIUS -> Accounting“

Authentication

Accounting

Ich hatte bereits im Vorfeld ein bestehendes WLAN mit WPA2-PSK. Dieses werden wir jetzt erweitern oder besser gesagt umkonfigurieren.

Unter „WLANs“ kann man über das Klicken der WLAN ID auf die Einstellung dieses Netz zugreifen.

Unter dem Register „Security -> Layer“ klnnen wir WPA2-Policy und WPA2 Encryption AES einchecken. Dazu kommt jetzt, das unter „Authentication Key Management“ PSK wegfällt und dafür das 802.1x eingecheckt wird.

Anschliessend tragen wir unter dem Register „Security -> AAA Servers“ noch den Server für Authentication und Accounting ein.

Somit ist die Konfiguration aller Devices erledigt. Und nun testen wir…

Resultat

Ich vesuche jetzt mit zwei verschiedene Clients zu via Wireless auf meine SSID zu verbinden. Beide sind im Besitzt der Benutzername und Passwort.

Der Client mit der MAC-Adresse C0:33:5E:34:AB:67 wird den Zugang zum Netz nicht gewährt (Authorization Profile: DenyAccess), aber warum?

Werfen wir einen Blick auf die Details der beiden Sitzungen.

Erfolgreiche Authentifizierung

Benutzername und Passwort stimmen, zusätzlich ist die MAC-Adresse unseres Supplicants in der Endpoint Gruppe „Trusted_Devices“ vorhanden. Der Supplicant hat in diesem Fall alles richtig gemacht, und daher das richtige Profil bekommen.

Fehlgeschlagene Authentifizierung

In diesem Fall war der Benutzername und Passwort korrekt, aber, die MAC-Adresse des Supplicant konnte in der Endpoint Gruppe nicht gefunden werden.

Fazit

Wenn wir es gegenüber herkömmliche Authentifizierungsmethoden wie WPA2 PSK vergleichen, dann bietet MSCHAPv2 gewisse Vorteile. Jeder hat ein individuelles Passwort und die Verbindungen können somit besser nachvollzogen werden. Auch die Verwaltung der Zugänge ist ebenfalls bequemer, man kann Benutzer hinzufügen oder entfernen ohne andere Teilnehmer im Netzwerk zu tangieren.

In diesem Post haben wir die Benutzer gegenüber eine lokale Datenbank authentifiziert. Mit der ISE haben wir auch die Möglichkeit die Benutzer gegenüber ein Active Directory Server zu authentifizieren und somit eine Dezentrierung der Benutzerverwaltung zu vermeiden.

Vielen Dank und bis bald!