Netscaler Gateway - Configure inside/outside access rules based on AD Groups

I fought with this one for awhile. Like many others, the client had remote access configured to run through a Netscaler to a Web Interface server. And also like many others, we had to migrate this one toward Netscaler + Storefront. The detail here was that the client had two groups of users: Those allowed to work from home, and those who were not. This was controlled by AD membership in a security group.

On the older setup, the membership was checked after the netscaler, at the web-interface server. So after much thinking, more coffee, and a couple applications of forehead to desk, I determined I was going to use session policies to determine which IP address the client was coming from, and filter on AD group if the client was coming from the IP of the firewall.

I'm not covering certificate configuration, or look and feel, there are quite a few blogs that have covered these topics better then I could have done. This is about session policies and security.

Configure AAA Groups

1. After Setting up your Gateway vServer, make sure you configure your AD Domain under the "Authentication" panel of your vserver.
2. Navigate to "Netscaler Gateway" -> "User Administration" -> "AAA Groups".
3. Add a new group (The name you enter here has to match your AD Security group name EXACTLY, it's case sensitive. If there was a place to use copy and paste, this is one of them.)
4. On the next screen, click "Authorization Policies" on the right bar.
   
   
   
5. Click on "No Authorization Policy"
6. Click "Add Binding"
7. Click the "+" Next to "Select Policy" (after the first time, you can choose the created policy for any other AD groups)
8. Give it a name like "Auth_Policy_Allow", make sure the action is set to "Allow" and enter "ns_true" (no quotes) for the Expression, then click "Create".
   
   
9. Click "Bind"
10. Click "Close"
11. Repeat Steps 3-10 above for any other AD Groups you may have.

Configure Session Profile

1. Within your Gateway vServer, navigate to the Policies tab, Click the "+" in the upper right to add. (If the Policies tab is not shown, add it from the "Advanced Settings" pane on the right.)
2. Select "Session" and "Request", then click "Continue".
   
3. Click "Add Binding"
   
   
4. Click the "+" to the right of "Select Policy".
   
5. Click the "+" next to the "Profile" selector.
   
6. Give the Profile a name. As best as I understand, the Profile controls some of the connection settings, the Policy controls when the bound profile is used. The Binding links the previous two to a vServer, in an order of application. This may help you choose your name.
7. Click the "Security" tab.
   - Check "Default Authorization Action" and set to "Deny" (This is why we set the auth policy on the AAA groups)
   - Check "Advanced Settings"
   - Check "Authorization Groups" and move any AAA groups form the left to the right to give them access.
   
   
8. Click the "Published Applications" tab, and configure with your storefront Web Interface Address (your settings may differ)
   
9. Click "Create" to save your Session Profile.
10. Now your profile will be set, you need to name your Policy, and set an expression. If all your external traffic comes from a single IP, say.... 192.168.0.1 then your expression would be:
    
    REQ.IP.SOURCEIP == 192.168.0.1
    
    If your external traffic comes from a subnet, IP range, or a few scattered IPs, you'll need to build a bigger expression.
11. Now that your profile and policy is set, you have to give it a Priority Number. I don't claim to have a full understanding of how Netscaler Priorities work, but I do know that the Deny binding number needs to be LOWER then the Allow binding (which we still have to create). Pick your number, and choose "Bind".
12. Now redo the above steps, for your internal traffic, BUT
    - Leave out the security config (step 7)
    - For the policy expression (step 10)  enter:  ns_true
    - For the binding priority, go one lower (if you picked 100, go with 99) 

At this point, you should have a Gateway vServer that allows logins for all internally, but requires your AD membership when coming from outside addresses. If you need to test without actually going outside your network, you can use a different expression to treat your admin subnet or IP address as "outside". This expression allows you to filter on a subnet instead, just make sure you don't lock out anyone important :D

REQ.IP.SOURCEIP == 192.168.2.0 -netmask 255.255.255.0