uademo
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
uademo [2016/08/12 08:12] – michael-neesen | uademo [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 | + | Bei Einsatz von SNMPv3 ist eine Zeitsynchronität |
</ | </ | ||
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, | + | Zum discovern der Switche werden die Informationen über einen SNMP-Benutzer, |
- | {{ : | + | {{ : |
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 | + | {{ : |
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 | + | {{ : |
Zeile 46: | Zeile 46: | ||
Vor der Konfiguration von Unified Access und Port-Security, | Vor der Konfiguration von Unified Access und Port-Security, | ||
- | {{: | + | {{ : |
Bild | Bild | ||
==== Unified Access - Unified Profile ==== | ==== Unified Access - Unified Profile ==== | ||
Im " | Im " | ||
+ | \\ | ||
+ | {{ : | ||
+ | \\ | ||
Im Folgenden wird die Variante beschrieben, | Im Folgenden wird die Variante beschrieben, | ||
+ | \\ | ||
+ | {{ : | ||
+ | \\ | ||
- | {{: | ||
- | Für diese Konfiguration wählen wir das Template " | + | {{: |
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, | ||
+ | Im nächsten Schritt werden die Geräte und die Ports ausgewählt, | ||
+ | \\ | ||
+ | {{ : | ||
+ | \\ \\ | ||
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 " | Bei allen Profilen, aus denen heraus oder in die hinein per Change of Authorization (CoA) gewechselt werden soll, muss " | ||
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. | ||
- | + | \\ | |
- | {{: | + | {{ : |
+ | \\ | ||
+ | {{: | ||
Nachdem die Rollen erstellt/ | Nachdem die Rollen erstellt/ | ||
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" | 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" | ||
+ | |||
+ | \====== 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" | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | 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. | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | ===== 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 " | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | 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" | ||
+ | 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" | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | Die finale Konfiguration des Services sollte folgendermaßen aussehen: | ||
+ | |||
+ | {{ :: |
uademo.1470989528.txt.gz · Zuletzt geändert: 2024/06/09 10:29 (Externe Bearbeitung)