Im folgenden Artikel werden die Konfigurationsschritte für Remote Configuration Load und Unified Access beschrieben.

Remote Configuration Load wird in diesem Zusammenhang dafür verwendet, den Switch aus OmniVista 2500 heraus managen zu können. Und besteht aus drei Dateien:

1. instruction.alu: Dieses Instruktionsfile enthält den Ort und die Version der Software sowie den Pfad für eine Standardkonfiguration und Skript.
2. boot.cfg/vcboot.cfg: Diese Konfigurationsfiles werden in das working Verzeichnis des Switches kopiert und angewandt. Hier können alle Konfigurationen, die auch in der boot.cfg/vcboot.cfg enthalten sind, getätigt werden (bspw. aaa, vlan, 802.1q…).
3. script.txt: Das Skript File läuft nach dem Kopieren der Konfiguration ab und ermöglicht alle Einstellungen, die über die CLI möglich sind.

Wichtig ist an dieser Stelle, dass ein Benutzer hinzugefügt wird, dem die entsprechenden Rechte und nach Möglichkeit auf die Verschlüsselung für SNMPv3 zugeordnet werden. Dies kann nur über das Skript-File gemacht werden, da die Benutzer nicht in der boot.cfg/vcboot.cfg enthalten sind.

In der Skript-Datei kann auch die IP-Konfiguration vom DHCP-Server in die permanente Kofniguration übernommen werden.

Alle RCL-Informationen werden über die DHCP-Optionen 66 und 67 gemanagt. Eine genaue Beschreibung eines DHCP-Servers soll an dieser Stelle nicht erfolgen.

Beispiele für ein Skript und eine Instruktionsdatei.

Die Integration der Switche in OmniVista 4.2 erfolgt über das Menü → Network → Discovery Zum discovern der Switche werden die Informationen über einen SNMP-Benutzer, möglichst über einen Konsolen-Benutzer und die Einstellung von SNMP-Security und IP-Adressen der Switche benötigt. Diese Daten sind in einem Discovery-Profile zu hinterlegen. Eine detaillierte Beschreibung ist hier zu finden.

Im nächsten Schritt wird über Discovery → Discover new devices eine IP-Range festgelegt und anschließend mit den Discovery Profiles verknüpft. Nach dem Durchlauf sollten die Switche unter Discovery angezeigt werden.

Ist LLDP auf den Switchen aktiviert, werden unter Network → Topology die Switche in einer Topologie-Ansicht mit den zugehörigen Links angezeigt.

Aus OmniVista heraus können nun Sicherheitseinstellungen für die Switche erstellt werden. Dies ist in einem Workflow und Templates im OV 2500 R4.2 komplett neu geregelt und wird im folgenden näher beschrieben:

Vor der Konfiguration von Unified Access und Port-Security, muss der entsprechende RADIUS-Server angelegt werden. Dies erfolgt über Security → Authentication Servers → RADIUS. Wird hier der Server einmal angelegt, kann er in den folgenden Workflows immer genutzt werden. Für ClearPass ist es wichtig, dass die Switche als „Network Devices“ angelegt werden.

Bild

Im „Hauptmenü“ von Unified Profile werden unterschiedliche Möglichkeiten angeboten die Konfiguration auf den Switchen zu steuern. Zum einen gibt es strukturierte „Workflows“, die alle Authentifizierungsmöglichkeiten abdecken und kombinieren. Zum Anderen haben wir hier „Templates“, die aus den „Workflows“ entstehen und auf die Switche ausgebracht werden können. Außerdem kann die individuelle Konfiguration der Switche über „Device Config“ angeschaut und geändert werden.

Im Folgenden wird die Variante beschrieben, die eine 802.1x-Authentifizierung bei 802.1x-Geräten durchführt, wenn dies nicht möglich ist, wird eine MAC-Authentifizierung und anschließend, bei unbekanter MAC-Adresse ein Captive-Portal für Gäste bzw. OnBoarding durchgeführt.

Für diese Konfiguration wählen wir das Template „802.1x and MAC Authentication“. Als Erstes wird festgelegt, welche Zuordnung vorgenommen werden soll. Hier sind für die Plattform OS6450 VLAN Port möglich, für die OS6860 zusätzlich SPB-Access und für die OS6900 zusätzlich noch VxLAN. Wir fahren mit VLAN Port fort.

Im nächsten Schritt werden die Geräte und die Ports ausgewählt, auf denen das Profil angelegt werden soll.


Wenn WLAN Geräte vorhanden sind, können hier auch WLAN Einstellungen vorgenommen werden. Dies wird in einem späteren Beitrag gesondert behandelt werden.

Im dritten Schritt werden die Authentifizierungsserver festgelegt. Wir nutzen an dieser Stelle für beide Authentifizierungen ClearPass

Als nächstes werden die Accounting Server ausgewählt. Dies hat im Release 6 keine Auswirkungen.

Im fünften Schritt werden nun Access Role Profiles (UNPs) konfiguriert. Entweder werden bestehende Profile genutzt oder das „Access Role Profile Template“ aufgerufen um neue UNPs zu erstellen.

Das „Access Role Profile Template“ erstellt neue UNPs und kann außerdem Policy Listen zu den Profilen hinzufügen, oder, wenn das interne Captive Portal der Switche genutzt werden soll, ein Captive Portal Profil zugeordnet werden. Bandbreiten-Limitierungen sind hier ebenfalls möglich.

Wir nutzen das Redirect bei den Profilen Gast und restricted. In alle anderen Profile wird durch Radius-Rückgabeattribut und nicht durch CoA gewechselt.

Nachdem die Rollen erstellt/ausgewählt werden, wird nun das VLAN Mapping vorgenommen. Wichtig: die VLANs, sollten diese manuell konfiguriert sein, müssen vom Gerät vorher „abgerufen werden“. Dies ist unter „Configuration“ → „VLAN“ → „Poll“ möglich und geht sehr schnell.

Im sechsten und siebten Schritt können noch weitere Klassifizierungen bei fehlgeschlagenen oder undefinierten Profilen angewandt werden. Wir übergehen in dieser Beschreibung beide Schritte.

Als Abschluss kann ausgewählt werden, was mit dem Traffic passiert, bevor die Authentifizierung erfolgreich stattgefunden hat. Der Wert steht standardmäßig auf „Block All Traffic“. Dies ist die sicherste Variante und sollte nach Möglichkeit beibehalten werden.

\

Sofern der Clearpass Server zuvor mit OmniVista 2500 über das Menü → Unified Access → Premium Services → BYOD verknüpft wurde, sind durch die oben beschriebene Workflow-Konfiguration bereits Enforcement Profile für die Übertragung der UNPs im Clearpass angelegt worden. Zusätzlich kann in OmniVista in diesem Bereich auch die Radius-Konfiguration gleichzeitig auf die OmniSwitche und den Clearpass Server ausgebracht werden. Diese erscheinen dann im Clearpass Server unter Configuration → Network → Devices.

Für eine einfache Authentifizierung auf AD-Nutzerbasis kann der Clearpass-Server mit einem bestehenden Active Directory gekoppelt werden. Dies erfolgt unter Administration → Server Manager → Server Configuration. Hier den entsprechenden Clearpass Server auswählen und unter System auf „Join AD Domain“ klicken. Im folgenden die AD-Daten angeben und speichern.

Das AD kann anschließend unter Configuration → Authentication → Sources über Add als neue Authentifizierungsquelle eingerichtet werden. Hierfür wird ein AD-Nutzer benötigt, über welchen der Clearpass Server lesend auf das AD zugreifen kann. In diesem Fall wurde dafür ein separater Nutzer ldapquery angelegt, welche unter Bind-DN hinterlegt wird. Über den Base-DN wird festgelegt, ab bzw. in welchem Pfad nach Nutzern für die Authentifizierung gesucht wird.

Für die 802.1x Authentifizierung wird unter Configuration → Services ein neuer Service benötigt, dazu Add auswählen. Durch die Auswahl des Typs „802.1X Wired“ werden die passenden Service Rule Conditions ausgewählt. Diese können bei Bedarf auch angepasst werden.

Als Authentifizierungsmethoden wurde lediglich EAP-TLS manuell hinzugefügt. Diese Methode wird für das OnBoarding benötigt und wird in einem separaten Artikel beschrieben. Als Authentifizierungsquelle wird die eben angelegte AD ausgewählt. Für das OnBoarding wird zusätzlich das „OnBoard Devices Repository“ benötigt.

Im nächsten Schritt wird ein Role Mapping und eine Enforcement Policy erstellt, um die authentifizierten Nutzer ihrem passenden UNP zuweisen zu können. Über das Role Mapping wird im Clearpass Server intern eine Rolle zugewiesen, welche dann für das Enforcement in unterschiedlichen Policies genutzt werden kann. Für die Rollenzuweisung kann der Clearpass Server auf AD-Attribute wie z.B. Gruppenzugehörigkeit (memberOf) oder Abteilung (Department) zugreifen.
Hierfür auf „Add new Role Mapping Policy“ klicken und die entsprechenden Einstellungen vornehmen, wobei die verwendeten Roles zuvor Configuration → Identity → Roles angelegt werden müssen.
In diesem Beispiel wird die Gast-Rolle angewendet, wenn der Nutzer keiner anderen Rolle zugeordnet werden kann. Dies kann beispielsweise dahingehend angepasst werden, dass hierfür eine generische Mitarbeitet-Rolle verwendet wird.

Für die Zuweisung der Rolle auf den OmniSwitchen wird eine Enforcement Policy benötigt, welche die Clearpass Rolle über eine Filter-ID auf den OmniSwitch überträgt. Diese wird über „Add new Enforcement Policy“ angelegt und wie im folgenden Screenshot dargestellt konfiguriert. Auch hier werden die beiden OnBoard BYOD Einträge später für das OnBoarding benötigt und können in diesem Schritt vernachlässigt werden.

Die finale Konfiguration des Services sollte folgendermaßen aussehen: