Even though it would be possible to manage a Citrix ADC / NetScaler using local users only we usually avoid doing so. Instead, we use users from other directories like TACACS, RADIUS or LDAP.
- TACACS is mainly used in large deployments. TACACS is an open standard, created in the 1984 to authenticate UNIX systems, adapted and widely used by Cisco and other vendors of network equipment. You will find TACACS mainly in large enterprises. TACACS may be used for both, authentication and authorizations. It’s very common to defind command policies in TACACS, not in Citrix ADC / NetScaler.
- RADIUS is a bit younger and mainly used for authentication in a multifactor environment. RADIUS can also do accounting, so keep statistics about logon/logoff actions and give you information who had been logged on when and for how long.
- LDAP is the youngest of the three authentication protocols. It’s an open standard for authentication. Microsoft’s Active Directory ™ supports LDAP.
We will focus on LDAP. Unfortunately, Wonderkitchen currently does not support LDAP, so you would have to create an Active Directory™ Server yourself.
How policies look like
Every policy consists of two parts: The expression and the action, the if and the then- part. See policies.
LDAP Policy actions
The policy action for authentication policy is also called ‘Server Definition’. It’s a definition of the server you want to authenticate too. The server usually is a load-balanced server pointing to several domain-controllers, so the authentication will still work, even if one or more of the domain controllers in your enterprise is down.
System → Authentication Policies → Classic Policies → LDAP. Click on Servers in the right side.
The top section
is all about server-settings.
The Server IP address of your LDAP server. This should be the IP of a load-balanced vServer to avoid failures if a domain controller is down.
Traffic to the authentication server will normally originate from the NSIP. If you load-balance this server, it will come from SNIP!
Security type will usually be SSL due to changes, Microsoft did to it’s LDAP default settings in 2020 and due to security reasons, Johannes Norz pointed out recently.
Port usually is 636 for secure LDAP and 389 for plain text or TLS.
Server Type is either AD (Active Directory) or NDS (Novell Directory Services). AD is a little bit misleading, as it is used with all kind of LDAP as long as it is 100% RFC compliant. So you would use AD for OpenLDAP as well.
Time-out is 3 seconds by default and usually does not need to get changed. It’s the time the server has to react to authentication attempts. I only have to change time-out values for challenge-response authentication systems like DUO to give users time to react to the challenge.
Authentication has to be ticked (we definitely want to authenticate)
SSh Public Key is not needed with Active Directory
The middle section
is about how to log on to a server, where to find users and so on.
Base DN (location of users) is the place, where users can be found. In my screen-shot, they are located in an OU called users of an AD called wonderkitchen.lab. dc is a domain, cn is either a container or an object (user, computer, group, …) and OU is an organizational unit. In my screen-shot users have to be located in or under the wonderkitchen.lab\users. A user in wonderkitchen.lab\admins would not be able to log on, as the user object would not be found.
Administrator Bind DN: The term is a bit misleading. It’s a user, no administrator, used to locate the user we want to log on. The name of this user in LDAP would be cn=LDAP, ou=systemusers,dc=wonderkitchen,dc=lab, but that’s not just hard to find out and all authentication would break down if someone moves this user somewhere else. As we use Active Directory we may also use a UPN, and that’s the preferred method.
This user needs to have read permissions all over the Base DN. It does not need (and should not have) the right to log on locally.
Administrator Password is the password of the Administrator Bind DN.
Test LDAP Reachability will connect to the LDAP server specified and try to logon the administrative bind DN. It will give a green result if everything could be completed successfully.
Retrieve Attributes will retrieve all attributes from the schema. This is needed if you don’t want to log on users using username and password, but something like UPN (user principal name) or any other attribute in your directory.
Test End User Connection will try to log on a soecifiv user.
The bottom section
Server Logon Name Attribute the username users specify to log on. Usually the SAMAccountName (vulgo user name: johannes.norz) or UserPrincipalName (vulgo mail address: johannes.norz@wonderkitchen.lab). Any other attribute (mail-address, phone number, …) would be possible as well, as long as it is unique.
Search Filter may get used to restrict logon to users with specific attributes. See CTX111079
Group Attribute the attribute, storing group membership. Usually memberOf.
Sub Attribute Name in Active Directory CN
SSO Name Attribute the attribute to logon to applications using single sign-on. It will use the Server Logon Attribute if you leave it blank.
Default Authentication Group is a string corresponding to a Citrix ADC / NetScaler group. All users logging on through this server are treated like members of this group. In my case it could be wonderkitchen, as these are users logged on to the wonderkitchen domain.
Allow Password Change needs to be enabled if users have to change their password if they are remote.
The policy
There are two kinds of policies. The “old” policies, usually called classic policies. Citrix recently announced to discontinue these in Citrix ADC 13.1, and the “new” ones, called default policies or advanced policies.
As classic policies will get discontinued soon we will create default policies only.
System → Authentication Policies →Advanced Policies → Policy. Click add.
Every policy needs to have an expression. The IF part. In my case, it’s a policy allowing logon from class C subnet 192.168.229.0 only. Citrix uses CIDR notation, so the subnet mask is specified using the number of significant digits to identify the network. In the case of class C (255.255.255.0) it’s 24.
Your policy expression could be as simple as a true, but also anything else you could thing of.
Binding the policy
Every policy has to be bound, or it won’t work. So we have to bind the policy “somewhere”, i.e. to the box itself. This is done by binding it globally.
Just click Global Bindings.
Select Policy: Click the little arrow to choose a policy.
Priority: If you bind more than one policy, the policy with the lowest priority number will get processed first. Authentication will process one policy after the other. It will stop and return auccess to the system if one policy gives a match (so username and password are correct).
Giving it a try
We should now be able to log on successfully. Unfortunately, we run into the same issue as before with local users: Our user does not have any permissions.
What can we do?
I will do a detour to point out, how authentication really works.
Creating a local user
Create a local user with the same user name, but a different password. Don’t clear the checkbox ““. Bind a command policy to this user.
Try logging on. This time, we will be able to log on successfully, and, at the same time, get permissions, no matter if we log on using domain-, or local credentials. So both users are treated as one. In fact, the Citrix ADC or NetScaler has two processes: One, checking user credentials. This one sends an OK to the kernel. And a second one authorizing this user.
We hope, we don’t have to mention: That’s not a good solution. There is no advantage over local users, but instead of one we now have two passwords, and Citrix ADC/NetScaler does not enforce strong passwords, so security came down.
Let’s have a look at the logs. They can be found in Authentication → Logs. Unfortunately, this is quite slow. Scrolling through the logs we will see this two stages authentication/authorization process. But more important: We will see a line like that:
On top, you see a message, sent to the kernel, to allow the user johannes.norz to log on. The second message we highlighted is at least the same the interesting: This johannes.norz is a member of two groups in Active Directory: PublishedApps and FaNorz.
More about logging and troubleshooting logon can be found here.
Creating Groups
Let’s try to create a croup, using one of these names. Bind a policy to this group. Give it another try. You will see: Logon is successful and we get permissions granted to this group.
That’s the way we usually do it!
[wpedon id=”798″ align=”center”]
