Accelera Solutions - Blog

Creating a Unified Login Method for NetScaler Users

Written by Braxton Koppelman | Mar 21, 2017 1:00:00 PM

With the widespread adoption of Microsoft Office 365, many customers are looking for a more unified login experience to access all the applications and resources available to them. When a user logs in, they are prompted to authenticate with their email address and password, which raised a similar question for a NetScaler customer who logs in the traditional way with their username and password.

“What if I also want my NetScaler users to authenticate with their email address?”

Here are the steps to configuring a seamless unified login experience:

(Keep in mind that the user can continue logging in the traditional way with their username and password if they choose)

 

  1. In many instances, the internal user domain doesn’t match up with the public domain. If that’s the case, you won’t be able to use the Universal Principal Name (UPN) to authenticate the user because it won’t match up with the user’s email address. A different Server Logon Name Attribute that is tied to the user’s email address in the Active Directory, or the ‘mail’ attribute, will be used instead.

 

  1. Create a new authentication server (this is very similar to the one you’ve probably already configured using ‘sAMAccountName’ as the logon attribute). The new LDAP server should resemble the below screenshot:

 

 

  1. Set the SSO Name Attribute to ‘sAMAccountName’ so the user credentials can be forwarded to StoreFront when using the Pass-through authentication from NetScaler.

 

  1. Once you’ve created the new LDAP server, you’ll need to create another LDAP policy so it can bind it to the NetScaler Gateway or AAA vServer. Using an expression of ns_true, and pointing it to the new LDAP server should do the trick unless there are some custom LDAP policies for things such as MFA


  2. Once complete, bind the new authentication policy to your NetScaler vServer with either a higher or lower priority than your existing policy (depending on your preference. This step should do the trick!

 

Once this is bound, a user can login the traditional way with their username and password or with their email address and password.

 

If a user chooses to log in with their email address, it will skip over the LDAP policy, using the sAMAccountName as the logon attribute and authenticate the user with the mail logon attribute.

 

Finally, below is the NetScaler configuration that I’ve exported for both authentication servers and policies that you’ll have to tailor to your environment. Hopefully this helps in your travels!

 

add authentication ldapAction 192.168.1.100_LDAPS_mail -serverIP 192.168.1.100 -serverPort 636 -ldapBase "DC=domain,DC=local" -ldapBindDn svc_NetScaler@domain.local -ldapBindDnPassword <Password> -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName mail -groupAttrName memberOf -subAttributeName cn -secType SSL -ssoNameAttribute samAccountName -passwdChange ENABLED

add authentication ldapAction 192.168.1.100_LDAPS_sAM -serverIP 192.168.1.100 -serverPort 636 -ldapBase "DC=domain,DC=local" -ldapBindDn svc_NetScaler@domain.local -ldapBindDnPassword <Password> -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -passwdChange ENABLED

 

add authentication ldapPolicy LDAPS_pol_mail ns_true 192.168.1.100_LDAPS_mail

add authentication ldapPolicy LDAPS_pol_sAM ns_true 192.168.1.100_LDAPS_sAM

 

bind vpn vserver NS_GW_gateway.domain.com-Int_443 -policy LDAPS_pol_mail -priority 100

bind vpn vserver NS_GW_gateway.domain.com-Int_443 -policy LDAPS_pol_sAM -priority 110