Configuring LDAPS / SSL for Citrix NetScaler LDAP authentication with Active Directory

I recently been asked about how to configure a NetScaler to authenticate against a domain controller when publishing XenApp / XenDesktop environments to utilize secure LDAP (LDAPS) via SSL and after realizing I’ve never written a blog post, I thought I’d do so.

The node in the NetScaler administration console we’re interested in is the Servers tab located in System –> Authentication –> LDAP:

Clicking on the Add button will bring up the following configuration options where we’re interested in using the port 636 for LDAPS rather than the unsecured 389 for LDAP and option SSL instead of PLAINTEXT:

Prior to actually configuring the NetScaler settings, begin by configuring the Active Directory domain controllers the NetScaler appliance will be authenticating against.  I won’t go into the details to configure them for LDAPS as I’ve written a blog post about it before so I’ll simply include the post here:

Configure LDAPs an Active Directory Domain Controller for LDAP over SSL Connections
http://terenceluk.blogspot.com/2013/10/configure-ldaps-active-directory-domain.html

Once the domain controllers have been configured with a LDAPS certificate and verified to be accepting SSL encrypted connections navigate back to the Servers tab located in System –> Authentication –> LDAP and fill out the fields as such:

Note that the Port has been specified to be 636 while the Security Type has been specified as SSL in the screenshots above.  Proceed with configuring additional Servers as required based on the amount of domain controllers you would like to authenticate against and once completed, bind them to the appropriate Virtual Servers in the NetScaler Gateway –> Virtual Servers objects.

--------------------------------------------------------------------------------------------------------------------------------------------------

One of the questions I get asked a lot when demonstrating this configuration to fellow colleagues, is if we have to import the root certificate of the certificate that the domain controllers will be using if the Certificate Authority (CA) is an internal Microsoft Certificate Services Authority and what I’ve noticed is that the authentication still works even if you skip this step.  I personally like to be on the safe side so I would go and import it onto the NetScaler anyways.

April 13, 2015 Update: As one of the comments from my original post notes, it is actually important to import the certificate because failing to do so would cause devices such as tablets (Androids and Apple) to present a:

Cannot verify this server’s certificate.

… or:

Invalid Server Certificate

This server certificate is not trusted.

Do you wish to accept this certificate and connect to the server anyway?

Contact your help desk if you are unsure.

For more information, check out the following blog post:

Android and Apple devices is presented with an “Invalid Server Certificate” warning and are unable to launch applications published through a NetScaler VPX
http://terenceluk.blogspot.com/2015/04/android-and-apple-devices-is-presented.html

-------------------------------------------------------------------------------------------------------------------------------------------------- 

Begin by going onto any one of the servers in the domain that has the Root CA certificate in the Trusted Root Certificates store and export the certificate as a Base-64 encoded X.509 (.CER) format:

Note that a Base-64 encoded X.509 (.CER) contains readable text in the exported file as shown in the following screenshot:

… while a DER encoded binary X.509 (.CER) contains binary code as such:

With the Root CA certificate exported, proceed by logging onto the NetScaler and navigating to Traffic Management –> SSL –> Certificates:

Clicking on the Install button will bring up the following menu:

As with all the other certificate menus on the NetScaler, I often find it confusing so the following is what you need to fill in if you are importing a certificate without a private key:

Certificate-Key Pair Name: A logical name you’d like to call this certificate (type in anything you like)

Certificate File Name: Click on the browse button, upload and select the .CER file you’ve exported

Key File Name: <blank> <—we’re not importing a certificate with a private key so there is no password

Certificate Format: PEM

Password: <blank> <—we’re not importing a certificate with a private key so there is no password

Clicking on the Install button will complete the import.

Note the differences between a certificate that the NetScaler has the private key (the middle certificate) and a certificate that the NetScaler does not have the private key (the one at the bottom).

Android and Apple devices is presented with an “Invalid Server Certificate” warning and are unable to launch applications published through a NetScaler VPX

Problem

You have successfully published a Citrix Receiver rule on the NetScaler and confirmed that a Windows PC can access Citrix published applications with a Citrix Receiver but you notice that Androids and Apple devices are presented with the following warning while logging on:

Invalid Server Certificate

This server certificate is not trusted.

Do you wish to accept this certificate and connect to the server anyway?

Contact your help desk if you are unsure.

… and although they can continue the login process by tapping the Accept button, they are presented with the following error when attempting to launch applications:

Cannot validate SSL certificate

Cannot verify this server’s certificate.

Solution

The reason why devices such as Androids and iPads present this error is because it cannot verify the presented certificate’s certificate chain.  Devices other than traditional Windows PCs do not have the trusted certificate chains installed by default and while it is possible to try and install the certificate onto the devices themselves, that solution is not practical in any environment with more than a few devices to manage.  The way to address this issue is to actually install the trusted chain of Root and Intermediate issuing CA certificates onto the NetScaler then link it to the certificate that used by the NetScaler to secure traffic.

Begin by using a browser and navigate to the Citrix portal and open the certificate properties:

Note that the Issued by field indicates this certificate was issued by the certificate authority QuoVadis Global SSL ICA G2 in the screenshot above.  Proceed and navigate to the Certification Path to display the full certificate issuing chain:

As shown in the Certification path above, the certificate chain is comprised of the QuoVadis Root CA 2 Root CA that issues the QuoVadis Global SSL ICA G2 Intermediate CA that issues the server certificate that the NetScaler is using to secure traffic to the server.  The two certificates we need to download are the QuoVadis Root CA 2 Root CA that issues the QuoVadis Global SSL ICA G2 intermediate CA.

Performing a quick search on Google returns the following URL that includes the links to download either the the DER or PEM of the certificates:

https://www.quovadisglobal.com/QVRepository/DownloadRootsAndCRL/InstallingSSL.aspx

Proceed to download the PEM for both the Root and Intermediate certificates by copying the text for each certificate and saving them as .cer files:

Upload the two certificates to the NetScaler:

Continue and import the certificates:

Fill in the following:

Certificate-Key Pair Name*: <a logical name that makes sense such as QuoVadis-Global-SSL-ICA-G2>

Certificate File Name*: Select the .cer file that was uploaded

Key File Name: Leave Blank

Select PEM format

Password: Leave Blank

The rest should be left as default.

Click on the Install button and you should now see the intermediate certificate installed:

Repeat the same procedure for the Root CA:

With the 2 certificate installed, the final stage is to link the chain together by right clicking on the server certificate and select Link:

If the correct intermediate issuing CA certificate was uploaded, the NetScaler should automatically detect it and have it set in the drop down menu:

With the server certificate linked, proceed and link the intermediate certificate to the root:

With the certificate chain linked, your tablet device such as iPads or Androids should no longer present the certificate warning and will be able to launch published applications:

Unable to connect to VMware Horizon View with iPad or Android devices

Problem

You’ve recently renewed the certificate issued by a public CA for your VMware Horizon View Security server that secures external incoming traffic. Windows desktops continue to connect without any issues but users with iPads or Android devices receive the following error:

iPad Error:

Untrusted Horizon Connection

VMware Horizon cannot verify your connection. Contact your administrator.

View Certificate

Do Not Connect

Clicking on the View Certificate shows the following certificate details (this example uses a GoDaddy certificate):

Not Trusted

Android Error:

Security Error

Failed to connect to the Connection Server. The server provided a certificate that is inavlid.

Clicking on the View Certificate shows the following certificate details (this example uses a GoDaddy certificate):

The certificate is not trusted.

Solution

Assuming that you are using the Fully Qualified Domain Name to connect to the View Connection Server then one of the reasons why this error is thrown is because either the root or intermediate or both of the certificates have not been imported into your View Security Server.  To confirm whether this is the case, log onto your View Security Server, launch the MMC and open the properties of the certificate that is for connections:

Certificate Information

Windows does not have enough information to verify this certificate.

Notice that the certificate summary indicates that the server has information verifying the certificate.  Continuing to click on the Certificate Path will display the following:

Certificate status:

The issuer of this certificate could not be found.

To correct this problem, we will need to find the intermediate CA issuer of the certificate by navigating back to the General tab and making a note of the Issued by field which in this example displays:

Go Daddy Secure Certificate Authority - G2

All certificate authorities makes their Certificate Authorities certificates available through their website and for this example, we can obtain the GoDaddy certificate from the following URL:

https://certs.godaddy.com/repository

The certificate we are interested in is the:

GoDaddy Secure Server Certificate (Intermediate Certificate) – G2

gdig2.crt

Download and import the certificate into the Local Computer’s Intermediate Certification Authorities:

We should now see the intermediate chain displayed in the certificate’s Certification Path once the intermediate issuing Certificate has been imported into the Intermediate Certification Authorities

The next step is to import the Go Daddy Root Certificate Authority – G2 into the Local Computer’s Trusted Root Certification Authorities:

GoDaddy Class 2 Certification Authority Root Certificate – G2

gdroot-g2.crt

With both the intermediate and root certificates imported, the properties of the certificate should now display the properties free of any warnings:

Proceed by restarting the VMware Horizon View Security Server service and the error for the iPad and Android devices will no longer be presented:

Configuring AAA Authentication with Cisco switch and Microsoft NPS server fails with the error message: “Authorization failed”

Problem

You’ve configured AAA authentication for a Cisco switch with IOS 12.2(55)SE5 to use a Microsoft NPS server as a RADIUS server to allow Active Directory account authentication but noticed that only certain users are able to login while others receive the error message: Authorization failed

You troubleshoot the issue by performing a AAA debug session for an account that you are able to login with and an account that you are unable to.  Comparing the outputs show the following differences highlighted in RED:

Successful Login

1y28w: RADIUS:  User-Name           [1]   8   "a-tluk"
1y28w: RADIUS:  User-Password       [2]   18  *
1y28w: RADIUS:  NAS-Port            [5]   6   2
1y28w: RADIUS:  NAS-Port-Id         [87]  6   "tty2"
1y28w: RADIUS:  NAS-Port-Type       [61]  6   Virtual                   [5]
1y28w: RADIUS:  Calling-Station-Id  [31]  13  "10.10.10.205"
1y28w: RADIUS:  NAS-IP-Address      [4]   6   192.168.254.253
1y28w: RADIUS(000003EB): Started 5 sec timeout
1y28w: RADIUS: Received from id 1645/8 10.21.1.72:1812, Access-Accept, len 97
1y28w: RADIUS:  authenticator D0 8C 90 31 B5 D7 E9 6B - 77 5F 27 B6 5A 2B 66 53
1y28w: RADIUS:  Service-Type        [6]   6   NAS Prompt                [7]
1y28w: RADIUS:  Class               [25]  46
1y28w: RADIUS:   70 47 06 45 00 00 01 37 00 01 02 00 0A 15 01 48 00 00 00 00 09 C9 33 0D 64 7B EA 12 01 D0 72 08 20 97 22 7B 00 00 00 00 00 00 00 15      [ pGE7H3d{r "{]
1y28w: RADIUS:  Vendor, Cisco       [26]  25
1y28w: RADIUS:   Cisco AVpair       [1]   19  "shell:priv-lvl=15"
1y28w: RADIUS(000003EB): Received from id 1645/8
1y28w: AAA/AUTHOR (0x3EB): Pick method list 'user-authorization' - PASS
1y28w: AAA/AUTHOR/EXEC(000003EB): processing AV priv-lvl=15
1y28w: AAA/AUTHOR/EXEC(000003EB): processing AV service-type=7
1y28w: AAA/AUTHOR/EXEC(000003EB): Authorization successful
1y28w: RADIUS/ENCODE(000003EB):Orig. component type = EXEC
1y28w: RADIUS(000003EB): Config NAS IP: 192.168.253.253
1y28w: RADIUS(000003EB): Started 5 sec timeout
1y28w: RADIUS: Received from id 1646/6 10.10.2.72:1813, Accounting-response, len 20

Failed Login

1y28w: RADIUS:  User-Name           [1]   12  "a-aburrows"
1y28w: RADIUS:  User-Password       [2]   18  *
1y28w: RADIUS:  NAS-Port            [5]   6   2
1y28w: RADIUS:  NAS-Port-Id         [87]  6   "tty2"
1y28w: RADIUS:  NAS-Port-Type       [61]  6   Virtual                   [5]
1y28w: RADIUS:  Calling-Station-Id  [31]  13  "10.10.10.205"
1y28w: RADIUS:  NAS-IP-Address      [4]   6   192.168.254.253
1y28w: RADIUS(000003E9): Started 5 sec timeout
1y28w: RADIUS: Received from id 1645/6 10.21.1.72:1812, Access-Accept, len 97
1y28w: RADIUS:  authenticator D0 95 9A 7C EE 63 A9 AD - BB CA 8B BB 8B DE 1C 05
1y28w: RADIUS:  Service-Type        [6]   6   Callback Framed           [4]
1y28w: RADIUS:  Class               [25]  46
1y28w: RADIUS:   70 45 06 43 00 00 01 37 00 01 02 00 0A 15 01 48 00 00 00 00 09 C9 33 0D 64 7B EA 12 01 D0 72 08 20 97 22 7B 00 00 00 00 00 00 00 13      [ pEC7H3d{r "{]
1y28w: RADIUS:  Vendor, Cisco       [26]  25
1y28w: RADIUS:   Cisco AVpair       [1]   19  "shell:priv-lvl=15"
1y28w: RADIUS(000003E9): Received from id 1645/6
1y28w: AAA/AUTHOR (0x3E9): Pick method list 'user-authorization' - PASS
1y28w: AAA/AUTHOR/EXEC(000003E9): processing AV priv-lvl=15
1y28w: AAA/AUTHOR/EXEC(000003E9): processing AV service-type=4
1y28w: AAA/AUTHOR/EXEC(000003E9): received invalid service type 4
1y28w: AAA/AUTHOR/EXEC(000003E9): Authorization FAILED
*Sep 15 14:40:24: %SYS-5-CONFIG_I: Configured from console by admin on vty0 (10.10.10.205)
TCH-2nd-3750-3#

Solution

After realizing that the Service-Type was being set incorrectly for the user account, I opened up the problematic user’s account properties to check the Dial-in tab and immediately noticed that the Callback Option was set to Set by Caller (Routing and Remote Access Service only):

Meanwhile, for the user who was able to successfully login had the Callback Option set to No Callback:

To correct this issue, either configure the problematic user accounts’ Callback Option to No Callback, or change the NPS policy to Ignore user account dial-in properties as such: