Ich hatte diese Woche einen Kunden der sein bestehendes NetScaler Gateway Deployment mit einer zusätzlichen Active Directory Domain ausgestattet haben wollte. Bisher lief die Authentifizierung via LDAP (Primary) und RADIUS (Secondary) via SMS Passcode.
Um die Policies zu entschlacken und etwas Komplexität aus dem Setup zu nehmen haben wir das ganze auf RADIUS only (via SMS Passcode) umgestellt. Dadurch muss beim späteren hinzufügen einer weiteren Domain keine weitere LDAP Policy hinzugefügt werden. Der RADIUS bzw. SMS Passcode ist an mehreren Domänen angebunden und übernimmt zudem noch die Password Validation.
Problematisch war jedoch das der Login mit sAMAccountName weiterhin möglich sein sollte. SMS Passcode (bzw. der Windows NPS) akzeptiert zwar den Login sowohl via sAMAccountName als auch via UserPrincipalName, auf dem NetScaler kann dann aber nicht mehr zugeordnet werden in welcher Domäne der Benutzer zugeordnet wurde. In der RADIUS Antwort des NPS ist die Domain des Users nicht enthalten. Auch gibt es sonst keine Möglichkeit ohne ein zusätzlich Group Extraction via LDAP an die Domain des Users zu kommen.
Bei einem NetScaler Gateway SSO zu Citrix Storefront wird die Domäne jedoch immer benötigt. Andernfalls bedeutet funktioniert zwar der Login am NetScaler selbst, der „NetScaler Gateway SSO“ an Storefront schlägt aber fehlt und es erscheint ein weiteres Login Prompt (bei dem im Regelfall aber kein manueller Login möglich ist).
Eine einfache Lösung sind an dieser Stelle Traffic Policies, mit denen man auch die Möglichkeit hat einen Rewrite des Benutzernamens auszuführen. Diese werden bei jedem Request (und damit nach der Authentifizierung) evaluiert. Via Conditions können diese sogar auf bestimmte URLs/Pfade (z.B. /Citrix/Store) beschränkt werden.
Die Standard SSO Domain in der Session Policy bleibt leer. Stattdessen legt man für jede Kundendomain eine eigene Traffic Policy an.
# SSO Traffic Policies
add vpn trafficAction prof_traffic_tentant1_sso_domain http -SSO ON -userExpression "HTTP.REQ.USER.LOGIN_NAME + \"@tentant1.local\""
add vpn trafficAction prof_traffic_tentant2_sso_domain http -SSO ON -userExpression "HTTP.REQ.USER.LOGIN_NAME + \"@tentant2.local\""
add vpn trafficPolicy pol_traffic_tentant1_sso_domain ns_true prof_traffic_tentant1_sso_domain
add vpn trafficPolicy pol_traffic_tentant2_sso_domain ns_true prof_traffic_tentant2_sso_domain
Diese Traffic Policies können nun an Gruppen aus dem Active Directory gebunden werden. Wichtig ist lediglich das man eine Gruppe verwendet die eindeutig ist und in dieser Schreibweise nur in einer Domain vorhanden ist.
# Bind Traffic Policies to AAA Groups
bind aaa group Tentant1_Users -policy pol_traffic_tentant1_sso_domain -priority 100
bind aaa group Tentant2_Users -policy pol_traffic_tentant2_sso_domain -priority 200
Optional bietet es sich noch an den Rewrite des Benutzernamens nur dann durchzuführen, wenn nicht bereits ein „\“ (TENTANT\user1) oder ein „@“ (user1@tentant.local) enthalten ist.
Dieses Problem besteht lediglich in Szenarien in denen ausschließlich via RADIUS authentifiziert wird. Bei LDAP gibt es die Möglichkeit das SSO Feld unabhängig vom Login Feld anzupassen (z.B. dann eben auf den UserPrincipalName).
