In diesem Artikel wird beschrieben, wie man ein Active-Directory an das UPAM-Modul anbindet und mithilfe von AD-Attributen die Benutzer in verschiedene VLANs verschiebt. Die Benutzer können sich mit ihren AD-Credentials an einer SSID anmelden und bekommen Ihre Resourcen zur Verfügung gestellt. In diesem Beispiel werden wir zwei Benutzer von verschiedenen Standorten über eine einzige SSID in verschiedene Subnetze schieben.
Für die Umsetzung wird ein OV2500 mit UPAM benötigt. Zusätzlich setzen wir hier Stellar WLAN ein und ein Actice-Directory (AD). Das Active-Directory ist in der Regel beim Endkunden schon implementiert. Falls der Kunde mehrere ADs im Einsatz hat und diese eine Vertrauensstellung haben, reicht es aus am UPAM-Modul das ROOT-AD anzubinden.
Um zu starten benötigen wir AP Groups, wo wir die Access Role Profiles und SSIDs ausrollen können. In den folgenden zwei Bildern sind Beispiele, wie eine AP Group und wie Access Role Profile aussehen können. Wichtig bei den Access Role Profilen ist, dass sie mit dem Button „Apply to Device“ zu einer AP Group zugewiesen werden und auf das richtige VLAN verweisen.
Im UPAM-Modul ist es möglich das AD anzubinden. Es gibt verschiedene Möglichkeiten. Man kann die Datenbank über LDAP oder das Active-Directory direkt anbinden. Über LDAPS kann man die Verbindung verschlüsseln. In diesem Beispiel ist kein Zertifikat vorhanden, deswegen wird das ganze ohne LDAPS angebunden.
Bei der SSID muss darauf geachtet werden, das man „Enterprise Network for Employees (802.1x)“ Enterprise auswählt. Anschließend wird im UPAM-Modul automatisch eine Access Policy und eine Authentication Strategy erstellt. Im unteren Teil kann als Default VLAN ein „Dummy VLAN“ ausgewählt werden. In diesem Beispiel wird der Traffic über einen Tunnel (Remote Access Point) geleitet. Dies liegt an der an der Infrastruktur im Testlab.
Im UPAM-Modul sind über die Erstellung der SSID automatisch 2 Proflie erstellt wurden. (Access Policy und Authentication Strategy). Die Access Policy regelt, welche Authentication Strategy bei den Usern angewendet wird. In diesem Beispiel werden User, die über die SSID dot1x_AD kommen an die Authentication Strategy dot1x_AD weitergegeben. Die Authentication Strategy regelt die Autehntication Source (wo befindet sich die Datenbank mit den Usern - External LDAP/AD, Local Database, External Radius). Desweiteren kann ich hier das Role Mapping aktivieren, womit ich dann über Rückgabewerte des ADs die User in verschiedene VLANs schieben kann.
Über die SSID wird automatisch in der Authentication Strategy als Authentication Source „Local Database“ ausgewählt. Bitte dies auf „External LDAP/AD“ ändern!
Da das Role Mapping aktiviert ist, müssen wir nun Attribute festlegen. In diesem Beispiel benutzen wir das Attribut I (Ort). Das Attribut muss bei „Attribute for LDAP/AD“ erstellt werden. Anschließend kann in „Role Mapping for LDAP/AD“ mit dem Rückgabewert auf dem AD eine Condition aufgebaut werden. In diesem Beispiel arbeiten wir mit den Rückgabewerten Berlin und München. Je nachdem, welcher Rückgabewert vom AD kommt, wird der Benutzer in das dazugehörige VLAN verschoben, welches wir am Anfang in den Access Role Profile festgelegt haben.
Im Authentication Record kann überprüft werden, ob die Benutzer dem richtigen Profil zugeordnet sind. In den nachfolgenden Bilder gibt es einen Test-User aus Berlin und einen Test-User aus München. Im Authentication Record ist zu erkennen, dass beide über die selbe SSID kommen, der Berliner User in das Berliner VLAN und der München User in das Münchener VLAN verschoben wird.