Heutzutage stehen Unternehmen immer häufiger vor der Herausforderung, interne Applikationen (z.B. Collaboration-Plattformen) auch für den Zugriff von „Außen“, also aus unsicheren Netzwerken heraus, zugängig zu machen. Natürlich sollen und müssen dabei alle bestehenden Berechtigungen genauso berücksichtigt werden, als ob der Zugriff von intern erfolgen würde. Im Idealfall können dazu die bestehenden Authentifizieurngsmöglichkeiten, wie z.B. Kerberos oder NTLM, genutzt werden. Da nicht alle Authentifizierungsverfahren für eine „externe“ Nutzung geeignet sind, gibt es ein paar grundlegende Sicherheitsbetrachtungen zu berücksichtigen (Verschlüsselung, Passwörter in Klarschrift übertragen, etc.), wobei diese nicht Teil dieses Beitrages sind. 

Dieser Beitrag zeigt die Möglichkeit, wie der BigIP Access Policy Manager (APM) als Reverse- und Authentifizierungs-Proxy genutzt und gleichzeitig ein transparentes Single Sign On (SSO) zur Applikation (mit NTLM) umgesetzt werden kann.

Es müssen entweder APM (standalone) oder LTM+APM als lizensierte Module aktiviert sein.

 

APM - Konfiguration

Konfigurationsschritte:

  • Erstellen eines AAA-Server
  • Erstellen einer SSO-Konfiguration
  • Erstellen eines Access Profiles
  • Erstellen einer zugehörigen Access Policy

 

AAA-Server:

Die Authentifizierungsmethode ist grundsätzlich erst einmal unabhängig von der später gewählten SSO-Methode. Mit diesem Schritt wird lediglich definiert, wo die Benutzerinformationen hinterlegt sind und die BigIP sie abfragen kann. Im diesem Beispiel ist es die LDAP-Abfrage gegen ein bestehendes Microsoft Active Directory.

Unter: „Access Policy  ››  AAA Servers : Active Directory“ kann mit “Create” ein neuer AAA-Server vom Typ LDAP erstellt und entsprechend konfiguriert werden (alle „blau“ gekennzeichneten Felder müssen ausgefüllt werden, der Rest ist optional).

Server Connection:         direct oder Pool, wenn es mehrere Server sind

Server Address:                                IP des LDAP-Servers

Service Port:                      389, bzw. der jeweilige LDAP-Port des Servers

Admin DN:                          Benutzer-Account mit entsprechenden Berechtigungen (z.B. Administrator).
                                                Bsp.: CN=administrator,CN=users,DC=vmlab,DC=local

Passwort:                            das jeweilige Passwort

 

Mit “finished” die Konfiguration speichern.

 

 

SSO-Konfiguration:

Mit der SSO-Konfiguration wird festgelegt, in welcher Form die Applikation die eingebenen Benutzerinformationen (z.B. von der APM-Login-Seite) erwartet. Sinnvoller Weise sollte nur eine zur jeweiligen Authentifizierungs-Methode passende SSO-Konfiguration gewählt werden. Wenn z.B. Client-seitig eine Zertifikats-basierende Authenfizierung genutzt wird (also im Normalfall ohne Passwort), kann als SSO-Methode keine Passwort-abhängige Methode wie z.B. NTLM genutzt werden.

Unter: „Access Policy  ››  SSO Configurations : NTLMV2“ kann mit “create” eine neue SSO-Konfiguration vom Typ NTLMv2 angelegt und konfiguriert werden.

Name:

Username Source:          session.sso.token.last.username (default Session-Variable)

Password Source:            session.sso.token.last.password (default Session-Variable)

Domain Source:                session.logon.last.domain (default Session-Variable, der Wert wird später “passend” überschrieben)

NTLM Domain:                  die primäre NTLM Domain

 

 

Mit “finished” die Konfiguration speichern.

 

 

Access Profile:

In einem Access Profile werden alle Einstellungen zusammengefasst und alle zuvor konfigurierten Objekte (z.B. AAA-Server oder SSO-Konfiguration) eingebunden. Weiterhin können hier z.B. auch Applikation-spezifische Timeouts oder die bevorzugten Sprachen konfiguriert werden. In diesem Beispiel betrachten wir jedoch nur den SSO-Teil und die zugehörige Access-Policy.

Unter: “Access Policy  ››  Access Profiles : Access Profiles List“ kann mit “create” ein neues Profile vom Typ „all“ angelegt und konfiguriert werden.

 

 

Nach Auswahl des Profile-Typs werden weitere Optionen angezeigt, wobei alles bis auf Sprache und SSO-Configuration auf Default gelassen werden kann (sind für dieses SSO-Beispiel nicht relevant, sollten aber grundsätzlich immer für die jeweilige Applikation angepasst werden.).

 

 

Im Bereich „SSO Configuration“ über das Pull-Down-Menü die bereits konfigurierte Konfiguration auswählen und anschließend noch eine oder mehrere Sprachen auswählen und in das linke Feld „Accepted Languages“ übernehmen (bei mehreren Sprachen muss noch die richtige Default Language ausgewählt werden.).

 

Mit “finished” die Konfiguration speichern.

Das Access Profile ist soweit fertig und wir können als nächstes die Access Policy anlegen.

 

Access Policy:

Eine Access Policy ist eine Zusammenfassung aller Schritte und Bedingungen, die für einen erfolgreichen Applikationszugriff durchlaufen/erfüllt werden müssen. Konfiguriert wird sie über den sogenannten Virtual Policy Editor (VPE).

Unter: „Access Policy  ››  Access Profiles : Access Profiles List“ befindet sich neben dem gerade erstelltem Access Profile ein Link zur Access Policy.

 

Durch Klicken auf „edit“ öffnet sich ein neuer Tab/ ein neues Fenster, in dem der VPE und eine „leere“ Policy angezeigt wird.

 

In diese leere Policy müssen jetzt alle erforderlichen Schritte konfiguriert werden.

Als erstes dazu auf das „+“ Zeichen vor dem „deny“ Kasten klicken, im Bereich „Logon“ die „Logon Page“ auswählen und mit „Add Item“ das Element zur Policy hinzufügen.

 

Nachdem das Element „Logon Page“ hinzugefügt wurde, öffnet sich automatisch ein weiteres Fenster mit den entsprechenden Konfigurationsmöglichkeiten. Für dieses Beispiel können alle Werte auf default gelassen und die Einstellungen mit „Save“ gespeichert werden.

 

Als nächstes Element muss die gewünschte Authentifizierung anglegt werden. In diesem Beispiel ist es eine bestehende MS-AD mit LDAP, wobei dazu der bereits konfigurierte AAA-Server zum Einsatz kommt.

Durch Klicken auf das „+“ Zeichen vor dem „deny“ Kasten, öffnet sich wieder ein Auswahlfenster, in welchem im Bereich Authentifizierung „LDAP-Auth“ ausgewählt werden muss. Nach „add item“ öffnet sich wieder ein Konfigurationsfenster, in welchem die notwendigen Einstellungen vorgenommen und gespeichert werden müssen.

 

Server:                 über das Pull-Down Menü den bereits konfigurierten LDAP-Server auswählen

SearchDN:           hier muss der LDAP-Pfad eingetragen werden, in dem die Benutzerinformationen
                                stehen. z.B: cn=users,dc=vmlab,dc=local

SearchFilter:       definiert das Format des Benutzernamen (z.B. UPN oder sAmAccountName) und in

welcher Session-Variable der Wert dazu steht.

z.B. (userPrincipalName=%{session.logon.last.username})

 

In diesem Beispiel wurde der UPN als Benutzername gewählt, da dieser sehr wahrscheinlich als eindeutig eingestuft werden kann und damit ideal für eine Authentifizierung gegen mehrere MS-ADs genutzt werden kann. Grundsätzlich können aber auch alle möglichen Formen/Formate als Benutzername genutzt werden, z.B. auch domain\username und so weiter. Wichtig ist dabei nur, dass für das spätere NTLM-SSO zur Applikation das richtige Format für den Benutzernamen gewählt werden muss (z.B. das @vmlab.local vom UPN abtrennen, etc.).

 

Alternative Konfiguration – „split Username/Domain“:

Das „Logon Page“ Objekt bietet die Möglichkeit, den Benutzernamen automatisch von der Domäne zu trennen.

 

Durch das Aktivieren von „Split domain from full Username“ werden aus: stephan@vmlab.local (Benutzername im UPN-Format) automatisch zwei getrennte Session-Variablen.

session.logon.last.username ---- stephan

session.logon.last.domain ------- vmlab.local

Je nachdem können diese weiter genutzt oder angepasst werden.

 

Zum jetzigen Zeitpunkt müsste die Policy ungefär so aussehen.

 

Der zuletzt eingefügte LDAP-Auth-Kasten bietet standardmäßig zwei mögliche Wege, wobei der eine „successful“ heißt und für eine erfolgreiche Authentifizierung steht. In diesem Weg muss auch die weitere Konfiguration erfolgen, da der Fallback-Weg eine nicht erfolgreiche Authentifizierung darstellt und im Normalfall der Client-Request geblockt, bzw. ein erneuter Versuch notwendig wird.

Dieses Beispiel geht davon aus, dass der UPN nicht zwingendermaßen den richtigen und eindeutigen Domänen-Teil enthält (insbesondere bei mehreren AD-Domains), der für das NTLM-SSO notwendig ist. Sollte das doch der Fall sein, kann die Alternative Konfiguration – „split Username/Domain“ genutzt werden.

Glücklicher Weise können im Normalfall alle relevanten Informationen aus der MS-AD oder dem LDAP-Directory ausgelesen werden. In diesem Beispiel wird der DN oder Distingueshed Name dazu genutzt.

Beispiel DN oder Distingueshed Name:

CN=user1,CN=Users,DC=vmlab,DC=local

CN=user1,CN=Users,DC=d01,DC=vmlab,DC=local

Im ersten Fall ist der Domänen-Teil “ vmlab.local” und im zweiten Fall “d01.vmlab.local”.

 

Damit das APM überhaupt diese Werte auslesen und weiter benutzen kann, muss eine LDAP-Query (eine Abfrage der Attribute) eingefügt und konfiguriert werden.

Durch Klicken auf das „+“ Zeichen vor dem „deny“ Kasten (im „successful“-Weg‘), öffnet sich wieder ein Auswahlfenster, in welchem im Bereich Authentifizierung „LDAP-Query“ ausgewählt werden muss. Nach „add item“ öffnet sich wieder ein Konfigurationsfenster, in welchem die notwendigen Einstellungen vorgenommen und gespeichert werden müssen.

 

Server:                 über das Pull-Down Menü den bereits konfigurierten LDAP-Server auswählen

SearchDN:           hier muss der LDAP-Pfad eingetragen werden, in dem die Benutzerinformationen
                                stehen. z.B: cn=users,dc=vmlab,dc=local

SearchFilter:       definiert das Format des Benutzernamen (z.B. UPN oder sAmAccountName) und in

welcher Session-Variable der Wert dazu steht.

z.B. (userPrincipalName=%{session.logon.last.username})

 

 

Grundsätzlich kann über eine solche Query auch z.B. eine Abfrage der Gruppenzugehörigkeit eines Benutzers erfolgen (Authorisierung es Benutzers) und damit die Zugangsberechtigung abgefragt werden. In diesem Beispiel wird die Abfrage jedoch nur zur Abfrage der Attribute genutzt, so dass mehrere Wege (entweder / oder Entscheidungen) nicht erforderlich sind.

Die alternativen Wege der LDAP-Query können innerhalb des Konfigurationsfensters, im Bereich „Branch Rules“ gelöscht werden (wenn das Konfiguratonsfenster bereits geschlossen ist, kann es durch Klicken auf den LDAP-Query Link im Kasten wieder geöffnet werden).

 

 

Durch Klicken des „Löschen“-Buttons wird die vorhandene Branch Rule gelöscht, so dass nur noch der „fallback“-Weg übrig bleibt.

 

 

Nachdem nun alle Attribute abgefragt werden können, muss die NTLM-Domäne noch erstellt und als Session-Variable gesetzt werden. Das APM bietet hierfür die Möglichkeit, über ein „Variable Assign“ beliebige Variablen zu setzen oder bestehende umzuschreiben.

Durch Klicken auf das „+“ Zeichen vor dem „deny“ Kasten (im „fallback“-Weg der LDAP-Query), öffnet sich wieder ein Auswahlfenster, in welchem im Bereich Assignment „Variable Assign“ ausgewählt werden muss. Nach „add item“ können die Änderungen im sich neu öffnenden Konfigurationsfenster vorgenommen werden.

 

 

Über „add new entry“ und anschließendem Klick auf „change“ öffnet sich ein weiteres Konfigurationsfenster.

 

 

Im linken Teil wird der Variablenname und im rechten Teil die Quelle bzw. der überschreibende Wert eingetragen.

 

Linker Teil (welche Variable soll genutzt/angepasst werden):

Variablenname: session.logon.last.domain

(entspricht dem “Domain Source” Feld der zuvor konfigurierten SSO-Konfiguration)

 

Rechter Teil (was soll mit dem Wert gemacht werden, bzw. welcher Wert soll gesetzt werden):

set subject [mcget {session.ldap.last.attr.distinguishedName}];

set startIndex [expr [string first "DC=" $subject] +3];

set endIndex [expr [string first "," $subject $startIndex] -1];

return [string range $subject $startIndex $endIndex];

Das aufgeführte TCL-Script ließt den Wert vom LDAP-Attribut “session.ldap.last.attr.distinguishedName“ aus und extrahiert den NTLM-Domänen-Teil.

Bsp:

“vmlab.local” aus: CN=user1,CN=Users,DC=vmlab,DC=local

“d01.vmlab.local” aus: CN=user1,CN=Users,DC=d01,DC=vmlab,DC=local

               

Als letztes muss noch ein “SSO Credential Mapping” erfolgen, damit das APM die richtigen Werte für Benutzername und Passwort an die Applikation übergeben kann.

Durch Klicken auf das „+“ Zeichen vor dem „deny“ Kasten (im „fallback“-Weg des „Variable Assign“), öffnet sich wieder ein Auswahlfenster, in welchem im Bereich Assignment „SSO Credential Mapping“ ausgewählt werden muss. Nach „add item“ können die Änderungen wieder im sich neu öffnenden Konfigurationsfenster vorgenommen werden.

SSO Token Username:  welcher Wert, bzw. welches Format soll für den Benutzernamen übergeben

werden (in welcher Session-Variable steht der Wert)

SSO Token Password:    in welcher Session-Variable steht der Wert

 

In diesem Beispiel wurde der, aus dem LDAP ausgelesene sAMAccountName als Benutzername gewählt, da der UPN nicht vorher „gesplittet“ wurde. Der Wert für das Password wird direkt von der Logon Page übernommen. Als Ergebnis sollte folgendes herauskommen:

 

stephan\vmlab.local

oder

stephan\d01.vmlab.local

 

Damit der Applikationszugriff auch erfolgreich funktioniert, muss das „ending“ im Fallback-Weg des SSO-Credential-Mappings noch zu „allow“ geändert werden.

 

Die fertige Policy sollte ungefär so aussehen.

 

LTM - Konfiguration

Damit die APM-Funktionen aktiv für eine Applikation genutzt werden können, muss das Access Profile an einen bestehenden Virtuellen Server (VS) gebunden werden. Sollte noch kein entsprechender VS vorhanden sein, muss dieser vorher erstellt werden (die notwendigen Schritte sind nicht Teil dieses Beispiels).

Unter: “Local Traffic  ››  Virtual Servers : Virtual Server List  ››  Name des VS” kann das Access Profile im Bereich “Access Policy” ausgewählt werden.

 

Mögliche Fehlersuche und Behebung:

Das APM kann sehr ausführliche Reports loggen und nützliche Informationen zur Fehlersuche bereitstellen. Bei Bedarf ist das Log-Level noch anpassbar.

 

Log-Level anpassen:

Unter: “ System  ››  Logs : Configuration : Options” kann das Level auf Debug gestellt werden (empfiehlt sich nur für die Fehlersuche, nicht für den produktiven Betrieb der Policy).

 

Anzeigen / Aufrufen der Reports:

Unter: „Access Policy  ››  Reports : View Reports“ werden alle APM-Logdaten aufgelistet. Beim erstmaligen Aufrufen erscheint ein „Parameter Fenster“, in welchem mit „Run Report“ die Reports erstellt werden.

 

Im Bereich „Session Details“ werden alle relevanten Log-Einträge für die jeweilige Session aufgelistet (auf den Link vor der Session klicken).

z.B.

  • klappt die Authentifizierung und welcher Server wird genutzt?
  • können alle LDAP-Attribute ausgelesen werden und wie heißen diese?
  • klappt das Variable Assign?
  • etc.