A Citrix ADC allows authenticating to an application using several widely respected and secure authentication methods using AAA vServers. In addition, it allows to pre-authenticate to a AAA vServer and forward credentials provided to the application.
This means that it is no longer necessary to allow unauthenticated traffic to pass through to the application and the application servers can no longer be attacked directly from the Internet. Instead, authentication will be done on the Citrix ADC / NetScaler. This authentication may be very flexible and as strong as needed. The application itself does not even need to know about authentication!
Requirements: This lab uses the load balancing vServeror any other vServer (load balancing or content switching)
Requirements
-
- AAA feature only works with SSL, so a valid SSL certificate is a requirement.
- We need 2 authentication sources. You could use local authentication, the other one might be any Active Directory ®. Unfortunately, Wonderkitchen currently can’t provide an active directory by now.
- We need a DNS-record or an entry in your hosts file to resolve the host-name we use for authentication. In my environment this is aaa.training.lab pointing to 192.168.229.150
Creating a first AAA vServer
Go to Security → AAA – Application Traffic → Virtual Servers
Bind a certificate, bind a SSL profile (or – as a minimum – disable SSL v.3, TLS 1 and TLS 1.1). Leave authentication methods blank.
In case your AAA vServer appears to be down: Enable the feature SSL! All SSL vServers appear to be down as long as SSL is not enabled!
Authentication methods
We create two authentication methods. Obe, pointing to an LDAP directory of your choice, one pointing to RADIUS, or, if you don’t have a RADIUS server, to local authentication.
Both authentication sources need a user with the same user name.
Local authentication
Create a policy from Security → AAA-Application Traffic → Policies → Authentication → Advanced Policies → Policy
Local authentication does not need any policy actions!
LDAP authentication
The server definition
Go to Security → AAA-Application Traffic → Policies → Authentication → Advanced Policies → Policy → Actions → LDAP
The server you authenticate too should be a load-balanced domain controller, so you can stand one of these domain controllers being down.
- Server IP: The IP address of your domain controller. Instead, you might provide a fully qualified domain name. This DNS name has to be resolvable by Citrix ADC / NetScaler.
- Security Type: Plaintext, TLS or SSL. Due to changes, Microsoft did, it has to be SSL. See here.
- Port: 636 for SSL, 389 for Plaintext or TLS.
- Server Type: NDS for Novell Directory Services ® and AD for all other LDAP sources
- Time-out: leave it to 2 seconds. The time, your AD has to respond.
- Authentication: This directory is used for authentication. It will be used for group extraction only if youi uncheck.
- Base DN: The point in your directory used to search for users. dc=training, dc=lab is the entire directory training.lab. ou=remote-users,ou=Enterprise-Users,dc=training, dc=lab would allow training.lab users located in the OU remote-users inside the OU Enterprise-Users to log on. And, of course, any user in an OU below this point.
- Administrator Bind DN: I hate the word administrator here. In fact, in most cases, this might be any user, no special user rights needed. Any domain user is fine. Remove the right to log on locally for security reasons. You may use the user principal name for AD (my suggestion!), or the LDAP user name for all other types of LDAP.
- Administrator Password / Confirm …: The password for Administrator Bind DN.
- Test LDAP Reachability: connects to the domain controller and checks if all your data above is correct. Should return a message in green colour.
- Server Logon Attribute Name: Usually sAMAccountName, might also be userPrincipalName or any other attribute in AD, as long as it’s unique.
- Group Attribute: in AD memberOf
- SubAttribute: in AD CN
The policy
Go to Security → AAA-Application Traffic → Policies → Authentication → Advanced Policies → Polic.
Click Add. Give it a name. Select Action Type (LDAP) and action. Enter true as an expression.
Binding the first authentication policy
Like any other policy, our policy has to get bound. So we re-open the AAA vServer and click on No Authentication Policy.
I select the LDAP Policy and bind it with a default priority (100). No further action needed.
A first test
We should now be able to surf to this AAA vServer and authenticate.
Try logging on using invalid credentials. You will see: the login page will display again, just a short message is added. You may change the design and all colours using portal themes if you don’t like the design.
After logging on successfully we will see an error message:
This is expected. It’s because we did not start from a load-balancing vServer. The AAA vServer has no idea where to send the user after successful authentication.
Enabling authentication for a website
Next, we navigate to Traffic Management → Load Balancing → Virtual Servers
We open our lb_vs_colours and click Authentication at the very right side. This will add authentication settings to our configuration.
Select form-based Authentication (401 Based would force the browser to open an authentication dialogue). Specify the FQDN for this AAA vServer (you need to be able to resolve this host-name!) and select the right AAA vServer.
Testing logon
Surf to this load-balancing vServer. The logon dialogue is expected to show up. You should be able to log on successfully. Depending on Citrix ADC version you may see an error message:
This message is due to a missing authorization policy. Create a policy in Security → AAA-Application Traffic → Policies → Authorization. Click add. Create a policy, action allow, expression true. Bind it to the load-balancing vServer. This should solve the problem!
[wpedon id=”798″ align=”center”]
