Hallo zusammen
In den letzten beiden Artikel der Serie haben wir ein wenig die Möglichkeiten der Ressourcenzuweisung mit NetScaler Gateway sowie einer Gruppe mit Authorization Policies erläutert.
Was ist nun aber, wenn beim Anmelden via AAA mehrere oder gar verschachtelte Gruppen Zugriff erhalten sollen.
Dies wollen wir uns nun ein wenig genauer anschauen.
Als Basis für den Artikel dient uns der letzte, weshalb am Schluss auch beide Skriptdateien zur Verfügung stehen. Die Differenzen zum letzten Artikel sind zusätzlich rot hervorgehoben.
Nehmen wir uns als erstes die verschachtelten Gruppen (nested Groups) einmal vor. Damit dies funktioniert muss die LDAP Abfrage ein wenig erweitert werden. Innerhalb des GUIs findet man dies unter LDAP > Servers > euer LDAP Server > „More“
Hier kann man die Gruppenextrahierung aktivieren, die maximale Verschachtelungstiefe definieren (hoffentlich nicht zu tief), sowie die Attribute konfigurieren. Erstellt man den LDAP Server mittels CLI sieht es folgendermassen aus:
add authentication ldapAction ldap-srv-PIT -serverIP 192.168.100.50 -serverPort 389 -ldapBase "dc=domain,dc=pit" -ldapBindDn svcldap@domain.pit -ldapBindDnPassword Password1 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -nestedGroupExtraction ON -maxNestingLevel 3 -groupNameIdentifier sAMAccountName -groupSearchAttribute memberOf -groupSearchSubAttribute CN
Ab jetzt werden auch die verschachtelten Gruppen aufgelöst. Prüfen kann man dies mittels dem Tool aaad.debug
Für die erlaubte Anmeldung mehrerer Gruppen beschreibe ich hier vier Varianten. Bei diesen gehen wir davon aus, dass nebst der bekannten Gruppe G_PIT_Backend auch die Gruppen L_PIT_Intranet und U_PIT_VIPs Zugriff erhalten sollen.
Variante 1 / für jede Gruppe eine Policy
Die erste Variante ist zwar einfach, jedoch mit Fleissarbeit und der Gefahr der Unübersichtlichkeit verbunden. Wir erstellen für jede einzelne Gruppe eine Policy und fügen sie dem LB vServer hinzu. Es gilt hier vor allem auch auf die Prioritäten zu achten!
add authorization policy IntranetBackendAllow-G_PIT_Backend "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")" ALLOW add authorization policy IntranetBackendAllow-L_PIT_Backend "HTTP.REQ.USER.IS_MEMBER_OF(\"L_PIT_Backend\")" ALLOW add authorization policy IntranetBackendAllow-U_PIT_VIPs "HTTP.REQ.USER.IS_MEMBER_OF(\"U_PIT_VIPs\")" ALLOW bind lb vserver LB-vsrv-intranet.domain.pit -policyName IntranetBackendAllow-G_PIT_Backend -priority 100 -gotoPriorityExpression END -type REQUEST bind lb vserver LB-vsrv-intranet.domain.pit -policyName IntranetBackendAllow-L_PIT_Backend -priority 200 -gotoPriorityExpression END -type REQUEST bind lb vserver LB-vsrv-intranet.domain.pit -policyName IntranetBackendAllow-U_PIT_VIPs -priority 300 -gotoPriorityExpression END -type REQUEST bind lb vserver LB-vsrv-intranet.domain.pit -policyName DenyAll -priority 1000 -gotoPriorityExpression END -type REQUEST
Variante 2 / sämtliche Gruppenabfragen in einer Policy (Inbound Expression)
In dieser zweiten Variante fragen wir sämtliche Gruppen in der Policy-Expression ab. Vorteil der Variante ist ein einziger Konfigurationsort – Nachteil ist jedoch, dass die Abfragen nicht wiederverwendet werden können im Gegensatz zu Variante 3 und 4.
add authorization policy IntranetBackendAllow "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")||HTTP.REQ.USER.IS_MEMBER_OF(\"L_PIT_Backend\")||HTTP.REQ.USER.IS_MEMBER_OF(\"U_PIT_VIPs\")" ALLOW
Variante 3 / pro Gruppe eine eigene Expression
In der dritten Variante erstellt man pro Gruppenabfrage eine Expression (im GUI unter AppExpert) und verbindet diese dann in der Policy:
add policy expression IS_G_PIT_Backend "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")"
add policy expression IS_L_PIT_Backend "HTTP.REQ.USER.IS_MEMBER_OF(\"L_PIT_Backend\")"
add policy expression IS_U_PIT_VIPs "HTTP.REQ.USER.IS_MEMBER_OF(\"U_PIT_VIPs\")"
add authorization policy IntranetBackendAllow "IS_G_PIT_Backend || IS_L_PIT_Backend || IS_U_PIT_VIPs" ALLOW
Variante 4 / sämtliche Gruppenabfragen in einer Expression
Wie in Variante zwei können sämtliche Gruppenabfragen in einer Expression erledigt und die Abfrage kann in mehreren Policies verwendet werden:
add policy expression IS_AllowForBackend "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")||HTTP.REQ.USER.IS_MEMBER_OF(\"L_PIT_Backend\")||HTTP.REQ.USER.IS_MEMBER_OF(\"U_PIT_VIPs\")"
add authorization policy IntranetBackendAllow "IS_AllowForBackend" ALLOW
Ich persönlich bevorzuge die Variante 3 da die Abfragen mehrfach und in verschiedenen Konstellationen wiederverwendet werden können.
Skripte: NS-ResToGroup2 & NS-ResToGroup3