Friday, May 20, 2016

NetScaler VPX - Part 10 (user authentication with Active Directory - LDAP)

In my previous blog post, I examined local user management: user accounts created for the various NetScaler administrators on the appliance itself. In the present blog post, I will demonstrate how we can regulate access to the NetScaler using an external user database such as Active Directory.

We configure external authentication in this section of the management interface:

NetScaler > System > Authentication

Note: you can click on the images to enlarge.

Besides simple local authentication (what we saw in the previous blog post), we can use LDAP (Active Directory is based on LDAP), RADIUS or TACACS. In this blog post, I'll use LDAP.

So what do we need to do?

We have to:
  1. Designate an authentication server.
  2. Create a policy that directs authentication requests to that server.
  3. Bind that policy globally.

Designate the external authentication server

Click on "No LDAP authentication server" (see the right pane of the screenshot above) and then, under the "Servers" tab, click on "Add":

There are a decent amount of settings to configure so I've taken three screenshots of what is in fact a single page.

I designate the LDAP server with a name: srv_LDAP_DC2. This does not have to be the exact same name of the domain controller itself. I then enter the IP address of the server in question as well as the other settings shown below:

Note: yes, you may have noticed the Security Type "PLAINTEXT" and wondered if this setting is secure. Are the credentials sent in plain text? In some of the documentation consulted, I've seen this parameter left as is, perhaps because the objective of the documentation was simply to demonstrate how LDAP authentication is configured, without necessarily addressing security best practices. If you are using LDAP in a production environment, it would be a good idea to evaluate the other options. I may take another look at this, perhaps with a WireShark capture, but my time is not unlimited. 

We then enter the "Base DN" that the LDAP authentication query will target. Most examples I have seen show the domain. You could apparently target a more specific object (an organizational unit perhaps) but all users to authenticate would have to be in that container or a sub-container. We also need to enter an Active Directory account that the NetScaler will use to access (in our case) Active Directory. Enter the account name and password as shown below: 

Note: the use of the "Retrieve Attributes" link can be a challenge. First, based on what I have read in some sources (online forums), it seems that the "retrieval action" actually takes place on the management computer from which you access the NetScaler management interface. Therefore, this computer itself must be able to access Active Directory. If it cannot locate the domain controllers (lack of connectivity or incompatible DNS settings), we will not be able to "retrieve attributes". In my case, after much trial and error, I observed that the correct attributes in "Other Settings" (see below) had the correct values by default, even without clicking the "Retrieve Attributes" link. In fact, clicking the link caused a second field to appear under each of the fields shown below but with no other options from which to chose. In the end, I avoided clicking the link on later configuration attempts.

In "Other Settings", select the following values (if they are not already present):

We click on "Close" or "Done" as needed to return to the LDAP Servers tab. Remember to save the NetScaler "Running Configuration" so the changes become permanent.

If we want to test our configuration, we can go to the following section of the management interface, observe the "Status" of the (LDAP) authentication server and also click on "Test":

NetScaler > Authentication > Authentication Servers

Create the authentication policy

In the section shown below, click on the "Policies" tab and then "Add":

NetScaler > System > Authentication > LDAP

We need to do the following:

  1. Provide a name for the policy.
  2. Designate the server we just created (click on the "down arrow" to show the choices).
  3. Select the "ns_true" policy expression (once again, click on the "down arrow" for choices).

Click on "Create".

Bind the authentication policy (globally)

We can bind an authentication policy (or other types of policies) to a particular virtual server or "globally". In this case, we want to create a global binding. So, once the policy is created and we are back on the "Policies" tab of the LDAP page, we click on the "Global Bindings" button:

Select the policy we just created by clicking on the arrow ("greater than" symbol):

Click  "Select":

Then "Bind":

And finally, "Done":

Interaction with Active Directory and testing

In Active Directory, I will create two security groups to which a NetScaler "command policy" will be assigned:

I invented group names that include the name of the command policy (SuperUser, Read-Only). In fact, when we create the matching "system group" in the NetScaler (next step) the group names will have to match exactly, letter for letter (and they are case-sensitive).

Note: as explained in the previous blog post, a "command policy" is essentially a set of permissions that allows the user to execute certain operations on the NetScaler - or simply have read-only access.

Back on the NetScaler, we go to the following section to create the system groups that are associated with their equivalent in Active Directory (click on "Add"):

NetScaler > System > User Administration > Groups

I create a system group with the exact same name as the corresponding group in Active Directory and then click on "Insert" to select a command policy:

For the group "NetScaler_Admins_SuperUser", we logically select "superuser" and then click "Insert":

Click on Create:

Note: I repeat the same process for the group "NetScaler_Admins_Read-Only".

If everything has been configured correctly, that is all we need for the NetScaler to authenticate administrators via Active Directory. Please note that is is for authentication of users who access the NetScaler to manage the NetScaler. We can also use the NetScaler to authenticate users who will only pass through to access network resources but that is a different subject and different procedure.

How can we test authentication - and for that matter, user rights as regulated by the command policy?

I will add the user "Alan.Reid" to the "NetScaler_Admins_SuperUser" group in Active Directory:

Note: yes, for this part, I assume the reader has minimal knowledge of Active Directory user and group managment. I will not illustrate the procedure step-by-step.

I also add the user "Alex.Heyne" to the "NetScaler_Admins_Read-Only" group in Active Directory (no screenshot).

At the Citrix NetScaler logon page, the user enters their name as configured in Active Directory. Below, it is "alex.heyne" but in other networks, it could be "aheyne":

Alex Heyne can logon (and since there is no local account for him, we know LDAP authentication is working, which validates our configuration above) and... we can see that he does have limited permissions:

This is somewhat strange since Alex Heyne does have the "read-only" command policy and one would think he could at least read the version information. In any case, he cannot make changes (enabling new features, for example).

Next, I'll connect as Alan Reid and we can see immediately, once logged on, that his "superuser" command policy grants him greater permissions (in fact, permissions equal to those of the default administrator account nsroot):

Moreover, he can make changes to the NetScaler configuration (no error message when he clicks OK):

No comments:

Post a Comment