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

Hallo zusammen

Im letzten Artikel ging ich auf die Zuweisung von Session Policies an Gruppen innerhalb NetScaler Gateway ein. Auch wenn dieser dem einen oder anderen Leser vielleicht sehr banal vorkam, so wird dies in Kursen und im Support öfter mal angefragt.

In diesem Artikel wollen wir uns die Möglichkeiten anschauen, Authorization Policies des AAA Features aufgrund Gruppenmitgliedschaften ausführen zu lassen.

Zwar gibt es verlockenderweise auch Gruppen und Benutzer:

Und man erhält sogar die Option um Authorization Policies zuzuweisen, jedoch wird man bald an einer Fehlermeldung scheitern :-(

Somit ist diese Möglichkeit leider eben deren keine.

Wir müssen also auf eine andere Variante zurückgreifen und zwar auf die Expressions. Bevor ich diese genauer erläutere, bauen wir uns erst ein Szenario:

Gehen wir davon aus, dass wir einen bestimmten Backendservice mittels LB bereitstellen und zusätzlich mittels AAA (ohne SSO) absichern wollen.
Die Anmeldung erfolgt via LDAP und die Gruppen werden entsprechend ermittelt.
Die Gruppe G_PIT_Backend soll Zugriff erhalten, während den restlichen Benutzer der Zugriff verweigert werden soll.

Als erstes erstellen wir die LDAP Server und Policy inkl. Ermittlung der Gruppen:

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
add authentication ldapPolicy ldap-pol-PIT ns_true ldap-srv-PIT

Im weiteren Schritt wird der AAA vServer für die spätere Authentifizierung erstellt:

add authentication vserver aaa-vsrv-aaa.domain.pit SSL 192.168.200.50 443
bind authentication vserver aaa-vsrv-aaa.domain.pit -policy ldap-pol-PIT -priority 100
bind ssl vserver aaa-vsrv-aaa.domain.pit -certkeyName aaa.domain.pit

Nun können wir wie gewohnt unseren Backendservice mittels LB bereitstellen, jedoch zusätzlich den AAA vServer zur Authentifizierung hinzufügen:

add server INTRANET01 192.168.100.81
add server INTRANET02 192.168.100.82
add service svc-https-intranet01 INTRANET01 SSL 443
add service svc-https-intranet02 INTRANET02 SSL 443
add lb vserver lb-vsrv-intranet.domain.pit SSL 192.168.200.80 443 -persistenceType COOKIEINSERT -persistenceBackup SOURCEIP -AuthenticationHost aaa.domain.pit -Authentication ON -authnVsName aaa-vsrv-aaa.domain.pit
bind lb vserver lb-vsrv-intranet.domain.pit svc-https-intranet01
bind lb vserver lb-vsrv-intranet.domain.pit svc-https-intranet02
bind lb vserver lb-vsrv-intranet.domain.pit -certkeyName intranet.domain.pit

Nach einem ersten Test stellen wir nun fest, dass die Authentifizierung funktioniert. Jedoch erhält aktuell noch jeder Benutzer Zugriff ins Backend.

Um die Zugriffe ins Backend zu steuern erstellen wir nun zwei Authorization Policies, wobei die eine alles sperrt und die andere den Zugriff für unsere Gruppe gewährt:

add authorization policy DenyAll HTTP.REQ.IS_VALID DENY
add authorization policy IntranetBackendAllow "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")" ALLOW

Diese Policies müssen wir nun noch in der richtigen (!) Priorität dem vorhin erstellen LB vServer zuweisen:

bind lb vserver LB-vsrv-intranet.domain.pit -policyName IntranetBackendAllow -priority 100 -gotoPriorityExpression END -type REQUEST
bind lb vserver LB-vsrv-intranet.domain.pit -policyName DenyAll -priority 200 -gotoPriorityExpression END -type REQUEST

Ab jetzt erhalten nur noch die Mitglieder unserer definierten Gruppe den Zugriff ins Backend.

Viel Erfolg beim Nachbauen. :-)

Skript: NS-ResToGroup2