Archive

Posts Tagged ‘nsconmsg’

How to check which #NetScaler policy that your #Citrix #Receiver or web browser hits?

April 18, 2013 1 comment

Ok, this is a common issue that you’ll end up in when setting up Access Gateway access scenarios:

How do you know which policy that is hit when your different Receivers are logging in?

Well, there are a couple of nice commands that can help you troubleshooting your access scenario! I guess that most of you have a simple scenario where you have one domain to authenticate against and some simple PNA, CVPN and potentially SSL VPN policies and profiles to deal with, and they are all linked to the virtual server like something like this simple example:

AG_vServer_VIP

But in more complex scenarios you may end up controlling which browser the user is accessing with (for giving nice error messages instead of Citrix default messages when users may use an unsupported browser etc.), or when you have multiple AD domains and AD groups to link different policies to etc. Then it may be complex and you have multiple policies and profiles for the same config with minor changes like the SSO domain name etc. So how do you then troubleshoot that easily?

First we have the must know command that hooks into the auth process of the NetScaler and gives you a view of the authentication process:

cat /tmp/aaad.debug

When you run that and you authenticate you’ll see the result of your auth process agains for instance LDAP and RADIUS sources like the result here when I logged in to our little environment:

aaad_debug_output

At the top of the output you see all the AD groups that I’m a member of that needs to match the group that you like to use on the NetScaler side, and last you see that accept from AD for my authentication request.

Then you know that you’re authentication ok, but which of the session polices are we hitting? Then you need to have a look at this great command:

nsconmsg -d current -g pol_hits

This is the output when I access using my Receiver on OS X:

nsconmsg_policy_hit

Read more…