Benutzer-Werkzeuge

Webseiten-Werkzeuge


uademo

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
uademo [2016/08/12 08:12] michael-neesenuademo [2024/06/09 10:29] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 16: Zeile 16:
 Alle RCL-Informationen werden über die DHCP-Optionen 66 und 67 gemanagt. Eine genaue Beschreibung eines DHCP-Servers soll an dieser Stelle nicht erfolgen. 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 [[script|Skript]] und eine Instruktionsdatei.+Beispiele für ein [[script|Skript]] und eine [[instruktionsdatei|Instruktionsdatei]].
  
 ---- ----
  
-===== Integration in OmniVista 4.2.1 (Beta) =====+====== Integration in OmniVista 4.2.1 ======
  
 <WRAP center round tip 80%> <WRAP center round tip 80%>
-Bei Einsatz von SNMPv3 ist eine zeitsynchronität im Netzwerk über alle Geräte und OmniVista ein absolutes Muss-Kriterium.+Bei Einsatz von SNMPv3 ist eine Zeitsynchronität im Netzwerk über alle Geräte und OmniVista ein absolutes Muss-Kriterium.
 </WRAP> </WRAP>
  
 Die Integration der Switche in OmniVista 4.2 erfolgt über das Menü -> Network -> Discovery 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.+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 [[devicediscovery|hier]] zu finden.
  
 {{ :dicovery_profile.png?nolink |}} {{ :dicovery_profile.png?nolink |}}
Zeile 33: Zeile 33:
 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. 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.
  
-BILD+{{ :discovery-ua.png?nolink |}}
  
 Ist LLDP auf den Switchen aktiviert, werden unter Network -> Topology die Switche in einer Topologie-Ansicht mit den zugehörigen Links angezeigt.  Ist LLDP auf den Switchen aktiviert, werden unter Network -> Topology die Switche in einer Topologie-Ansicht mit den zugehörigen Links angezeigt. 
  
-BILD+{{ :topology-421.png?nolink |}}
  
  
Zeile 46: Zeile 46:
 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. 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.
  
-{{:aaa_server.png?600|BILD}} +{{ :aaa_server.png?nolink |}}
 Bild Bild
  
 ==== Unified Access - Unified Profile ==== ==== Unified Access - Unified Profile ====
 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 "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.
 +\\ 
 +{{ :unified_profile_home.png?nolink |}} 
 +\\
 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.  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. 
 +\\
 +{{ :entscheidung_unified_access.jpg?nolink |}}
 +\\
  
-{{:unified_profile_home.png?600|BILD}} 
  
-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.+{{:workflow_unp_type.png?nolink&200 |}}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. 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. 
  
 +Im nächsten Schritt werden die Geräte und die Ports ausgewählt, auf denen das Profil angelegt werden soll.
 +\\
 +{{ :workflow_select_switches.png?nolink |}}
 +\\ \\
 Wenn WLAN Geräte vorhanden sind, können hier auch WLAN Einstellungen vorgenommen werden. Dies wird in einem späteren Beitrag gesondert behandelt werden. Wenn WLAN Geräte vorhanden sind, können hier auch WLAN Einstellungen vorgenommen werden. Dies wird in einem späteren Beitrag gesondert behandelt werden.
  
Zeile 73: Zeile 80:
 Bei allen Profilen, aus denen heraus oder in die hinein per Change of Authorization (CoA) gewechselt werden soll, muss "Redirect Status" enabled sein. Ohne diesen Haken kann der Switch die Änderung der Rolle nicht vornehmen.</WRAP> Bei allen Profilen, aus denen heraus oder in die hinein per Change of Authorization (CoA) gewechselt werden soll, muss "Redirect Status" enabled sein. Ohne diesen Haken kann der Switch die Änderung der Rolle nicht vornehmen.</WRAP>
 Wir nutzen das Redirect bei den Profilen Gast und restricted. In alle anderen Profile wird durch Radius-Rückgabeattribut und nicht durch CoA gewechselt. Wir nutzen das Redirect bei den Profilen Gast und restricted. In alle anderen Profile wird durch Radius-Rückgabeattribut und nicht durch CoA gewechselt.
- +\\ 
-{{:access_role_guest.png?600|BILD}} +{{ :access_role_guest.png?nolink |}}  
 +\\ 
 +{{:workflow_role_vlan_mapping.png?nolink&200 |}}
 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. 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.
  
Zeile 81: Zeile 89:
  
 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.  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. 
 +
 +\====== Konfiguration des Clearpass Servers ======
 +
 +===== Vorbereitung =====
 +
 +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.
 +
 +===== Kopplung des Clearpass Servers mit einer Active Directory =====
 +
 +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.
 +
 +{{ ::clearpass-ad.png?nolink |}}
 +
 +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.
 +
 +{{ ::clearpass-ad-auth.png?nolink |}}
 +
 +===== Service =====
 +
 +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.
 +
 +{{ ::clearpass-1x-service1.png?nolink |}}
 +
 +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.
 +
 +{{ ::clearpass-1x-service2.png?nolink |}}
 +
 +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.
 +
 +{{ ::clearpass-1x-rolemapping.png?nolink |}}
 +
 +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.
 +
 +{{ ::clearpass-1x-enforcement.png?nolink |}}
 +
 +Die finale Konfiguration des Services sollte folgendermaßen aussehen:
 +
 +{{ ::clearpass-1x-service.png?nolink |}}
uademo.1470989562.txt.gz · Zuletzt geändert: 2024/06/09 10:29 (Externe Bearbeitung)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki