In a previous article, we examined NetScaler 11.0’s enhanced authentication and Single Sign-On (SSO) capabilities, such as support for oAuth2.0 and OpenID Connect.
Today, let’s take a look at one further enhancement, which involves the NetScaler acting as a SAML IDP, with Kerberos as primary client side authentication method, and NTLM as a fallback. We will use Google Apps as an integration end point for our demonstration.
Kerberos provides strong authentication, as it does not involve user password being transmitted on the wire; what is exchanged is the encrypted value involving the hash of the user password and a changing timestamp. Kerberos authentication requires that the client be domain joined, as well as it being able to reach the KDC (Key Distribution Center), typically a Domain Controller, within a Microsoft Windows environment. In the event that Kerberos is not available, such as when the end user is external, NTLM authentication kicks in.
When we deploy NetScaler as a SAML IDP with client side Kerberos authentication, it means that the NetScaler will authenticate the end user with Kerberos; upon authentication completes, the NetScaler will SSO the user to Google Apps, through SAML. Specifically, the NetScaler generates a SAML assertion, asserting user identity, and sends it to Google Apps, which acts as a SAML Service Provider (SP). If assertion is verified authentic by SAML SP, Google Apps (e.g. email, calendar. drive) become available to the end user.
From a user’s perspective, all they have to do is enter the Google Apps URL (e.g. https://mail.google.com/a/your_domain) and they will be presented with apps (e.g. email, drive, calendar). They should not be prompted for credentials if Kerberos authentication succeeded, as Kerberos happens in the background with user credentials being obtained at login through GINA. As a fallback, the end user will see a pop-up window, through which they provide credentials, for NTLM authentication.
In order to deliver this seamless (Kerberos) authentication experience, The following steps are required,
- Sign up Google Apps for your enterprise – for a PoC, there is a 30-day trial
- Configure Google Apps to use the NetScaler as a 3rd party SAML IDP
- Configure the NetScaler as SAML IDP
- Register AAA VIP FQDN as a SPN (Service Principal Name) on the KDC
For Google Apps configuration, the most critical settings are captured in red rectangles, shown below. In this PoC, ‘nsidp.h.l’ resolves to an AAA VIP created on the NetScaler. The Sign-in page URL should always be https://AAA_VIP_FQDN/saml/login. ‘Sign-out page’ and ‘Change password’ URLs do not matter at this stage.
Since all SAML assertions are signed using the private key (configured on SAML IDP), the associating certificate (public key) must be provided for signature verification.
On the NetScaler and the KDC, we will need to create the followings,
- AAA vServer and matching certificate
- Negotiate (Kerberos) profile/policy
- Register SPN on the KDC with a user account
- SAMLIDP profile/policy
- LDAP profile/policy (optional)
For the negotiate profile, we must use the same domain user account that is also used for SPN registration.
To register SPN, use the following command on a domain joined Windows machine.
Below is a sample SAMLIDP profile,
add authentication samlIdPProfile TM_SAML_Google_apro -samlIdPCertName wildcard.h.l -assertionConsumerServiceURL “https://www.google.com/a/hahah.eu/acs” -rejectUnsignedRequests OFF -audience “https://www.google.com/a/hahah.eu/acs” -NameIDFormat Unspecified -NameIDExpr “HTTP.REQ.USER.ATTRIBUTE(1)” -samlBinding REDIRECT
‘assertionConsumerServiceURL’ refers to the URL that the NetScaler sends SAML assertion to. It is provided by Google Apps, and is specific to the environment.
The ‘NameIDExpr’ option is used as a bridge for account linking. This is required if the username or domain name is different between Google Apps and internal Windows domain.
In this PoC, the Windows domain is ‘h.l’, and the domain used with Google Apps is ‘hahah.eu’. We must find a way to link a domain user (e.g. administrator@h.l) to its Google Apps equivalent (e.g. chriszh@hahah.eu).
One way to link the two is shown below.
Once Kerberos authentication is complete for domain user ‘administrator@h.l’, the User Principal Name (UPN) is passed to LDAP for attribute extraction. The NetScaler does a UPN lookup for ‘administrator@h.l’, within the LDAP database, and extracts the associated ‘mail’ attribute value ‘chriszh@hahah.eu’, as username for subsequent SAML assertion for Google Apps.
The following shows the LDAP profile. Note that authentication is disabled, LDAP login name is set to ‘UserPrincipalName’ and ‘mail’ is extracted as ‘attribute1’, which is then referenced in ‘NameIDExpr’ configuration in SAMLIDP profile (e.g. -NameIDExpr “HTTP.REQ.USER.ATTRIBUTE(1)”).
add authentication ldapAction TM_LDAP_asvr -serverIP 172.16.18.3 -ldapBase “dc=h,dc=l” -ldapBindDn administrator@h.l -ldapBindDnPassword 3eeb26b55b96ffd0c98c0f9affe37c7f97272a2849a2584460d538b2588cca85 -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName UserPrincipalName -groupAttrName memberOf -subAttributeName CN -ssoNameAttribute userPrincipalName -authentication DISABLED -passwdChange ENABLED -Attribute1 mail
Please note that the LDAP policy needs to be bound as secondary, as shown below.
For the browsers, Kerberos authentication is not enabled by default. To enabled Kerberos on IE/Chrome, add the AAA VIP URL to the ‘Trusted sites’.
Select ‘Automatic logon with current user name and password’ within security level configuration.
Please refer to https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM for instructions for other browsers.
That’s it! But how do we tell if it was working? If the user sees all applications immediately after visiting https://mail.google.com/a/hahah.eu, as shown below, then it works. If the user is prompted for credentials, it means Kerberos did not work, and it falls back to NTLM authentication.
For completeness, below is Kerberos and SAML related info, which can be used in the event of troubleshooting.
SAML Request from Google Apps:
SAML Response from NetScaler IDP:
Kerberos service ticket for ‘HTTP/nsidp.h.l’, under account ‘administrator@h.l’ (Ticket Granting Ticket #0):
In this article, we demonstrated how to configure the NetScaler as a SAML IDP, with Kerberos primary and NTLM fallback client side authentication, and its integration with Google Apps. We also showed account mapping between two different environments through LDAP attribute extraction.
Please note that this feature requires NetScaler 11.0 64.x or above.
I hope you have enjoyed this article!
