HOW TO: Netscaler 10.5 – Change Password / Secure LDAP configuration

During my current project I had to build a Netscaler cluster for Access Gateway functionality. After initially configuring the Access Gateway vServer I noticed that user account that are marked for “Change Password on next Logon” could not authenticate not via Access Gateway Logon Page nor Via Dell Wyse ThinClient that are configured for StoreFront access (via Netscaler Access Gateway). Password Change direct via StoreFront 2.6 was working flawlessly. After some googling I managed to get this working I followed these steps to succesfully configure “Allow Password Change” via Netscaler.

  1. Create Root CA on Netscaler
  2. Enable Secure LDAP on domain controllers (without Microsoft CA services)
  3. Configure Authentication Server object on Netscaler
  4. Configure Access Gateway vServer on the Netscaler

1. Create Root CA, RSA Key

  • Login to Netscaler Administration Console.
  • Browse to NetScaler > Traffic Management > SSL and click Create RSA Key

Enter required information:

  • Key Filename = /nsconfig/ssl/RootCA.key
  • Key Size = 4096
  • Public Exponent Value = 3
  • Key Format = PEM
  • PEM Encoding Algorithm = DES3
  • PEM Passphrase = somepassword (2x)
create ssl rsa /nsconfig/ssl/RootCA.key 4096 -keyform PEM -des3 -password somepassword

2. Create Certificate Signing Request

  • Login to Netscaler Administration Console.
  • Browse to NetScaler > Traffic Management > SSL and click Create Certificate Signing Request (CSR)

Enter required information:

  • Request File Name = /nsconfig/ssl/RootCA.csr
  • Key Filename = /nsconfig/ssl/RootCA.key
  • Key Format = PEM
  • PEM Passphrase (For Encrypted Key) = Earlier created password
  • Country = Enter desired value
  • State or Province = Enter desired value
  • Organization Name = Enter desired value
  • Common Name = Enter desired value (This name is visible on the certificate)
create ssl certreq /nsconfig/ssl/RootCA.csr -keyFile /nsconfig/ssl/RootCA.key -keyform PEM -CountryName US -StateName NY -OrganizationName PrivateInc -commonName RootCAPrivateInc

3. Create RootCA Certificate

  • Login to Netscaler Administration Console.
  • Browse to NetScaler > Traffic Management > SSL and click Create Certificate

Enter required information:

  • Enter Certificate File name  = /nsconfig/ssl/RootCA.cer
  • Certificate Format = PEM
  • Certificate Type = Root-CA
  • CSR File = /nsconfig/ssl/RootCA.csr
  • Key Filename = /nsconfig/ssl/RootCA.key
  • Key Format = PEM
  • PEM Passphrase = Earlier created .key password
  • Validity Period = 365 (max 3650)

Now import this new certificate to the Netscaler Certificates store.

  • Browse to NetScaler > Traffic Management > SSL > Certificates and click Install
  • Certificate-Key Pair Name = “Name it you like
  • Certificate File Name = /nsconfig/ssl/RootCA.cer
  • Key File Name = /nsconfig/ssl/RootCA.key
  • Certificate Format = PEM
  • Password = Earlier created .key password
  • Certificate Bundle = Enabled


4. Enable Secure LDAP on domain controllers  

After we created the RootCA account we need to enable secure LDAP om the domain controllers. For this to work we need to create a CSR on the Domain Controllers. To do this you need to login on (all) your domain controller(s) and create a CSR. Copy the contents of this file to notepad and name the file request.inf. Save the file to c:\windows\temp

;----------------- request.inf ----------------- 


Signature="$Windows NT$" 


Subject = "CN=servername.domain.com"
KeySpec = 1 
KeyLength = 4096 
Exportable = TRUE 
MachineKeySet = TRUE 
SMIME = False 
PrivateKeyArchive = FALSE 
UserProtected = FALSE 
UseExistingKeySet = FALSE 
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
ProviderType = 12
RequestType = PKCS10 
KeyUsage = 0xa0 





now open a command-prompt (elevated rights) and issue the command:

cd \windows\temp
certreq -new c:\request.inf servername.csr

Upload  the newly created CSR file(s) to the Netscaler /nsconfig/ssl/ folder (via Manage Certificate > Upload)

5. Sign Domain Controller certificate.

Now Sign this CSR with the RootCA certificate created earlier via Create Certificate

  • Enter Certificate File name  = /nsconfig/ssl/servername.cer
  • Certificate Format = PEM
  • Certificate Type = SERVER
  • CSR File = /nsconfig/ssl/servername.csr
  • Key Format = PEM
  • Validity Period = 365 (max 3650)
  • Key Filename = /nsconfig/ssl/RootCA.key
  • CA Certificate File Name = /nsconfig/ssl/RootCA.cer
  • CA Certificate File format = PEM
  • CA Key File Name = /nsconfig/ssl/RootCA.key
  • CA Key File Format = PEM
  • PEM Passphrase = RootCA PEM Password
  • CA Serial File Number = /nsconfig/ssl/servername.serial

 6. Export RootCA as PFX

On Netscaler SSL Administration page click Export PKCS#12

  • PKCS12 File Name = /nsconfig/ssl/RootCA.pfx
  • Certificate File Name = /nsconfig/ssl/RootCA.cer
  • Key Filename = /nsconfig/ssl/RootCA.key
  • Export Password =  thisisanewpassword
  • PEM Passphrase = RootCA PEM Password

7. Import RootCA Certificate on Domain Controllers

Download the PFX file to C:\windows\temp on your domain controller and import it to the Trusted Root part of the Machine Certificate Store. When importing select “mark this key as exportable” repeat this step on all your Domain Controllers.

8. Import Server Certificate

Download the servername.cer file from the Netscaler to the domaincontroller c:\windows\temp, open command-prompt with elevated rights and issue command(s)

cd \windows\temp
certreq -accept servername.cer

Test your secure ldap with ldp.exe, select connect and enter the servername on which you just imported the certificates. Use port 636, and check the SSL option.


9. Configure Authentication Server object on Netscaler

  • Login to Netscaler Administration Console.
  • Browse to NetScaler > System > Authentication > LDAP and in the right pane click Servers and then Add.

Enter required information make sure to use these settings to enable secure LDAP connections:

  • Security Type: SSL
  • Port: 636
  • DO NOT enable “Validate LDAP Server Certificate”
  • Allow Password Change: Enabled

Bind this new server object to a Authentication Policy.

10. Configure Access Gateway vServer on the Netscaler

Open your Access Gateway vServer:

  • Bind Root Certificate as to CA Certificates
  • Bind the secure LDAP Autentication Policy to the vServer.
  • Enable “Client Authentication” in “SSL Parameters


All is done, now test it and hopefully this works for you too.



Microsoft KB321051


Netscaler Patching and Heartbleed Information

After the publicity of the latest OpenSSL vulnerability CVE-2014-0160 (aka Heartbleed). I’ve investigated if Netscaler’s firmware was vulnerable to this vulnerability. Soon I found out that Netscaler’s software is NOT vulnerable. But during my investigation I noticed that the OpenSSL implementation is very old (2004). This raised some questions like:

  • Why this old version is still actively used by Netscaler firmware?
  • Is OpenSSL used for SSL Authentication?
  • Is this version subject to all vulnerabilities that where discovered since 2004?

After some discussions on Citrix Forums, finally today a conclusive statement was given by Citrix Netscaler product manager Steve Shah.

Starting with the most important detail: NetScaler is NOT vulnerable to CVE-2014-0160. We have an up to date set of information at http://support.citrix.com/article/CTX140605

There seems to be some confusion around our SSL implementation and our patch strategy as well.

The NetScaler has two halves: the Internet-facing front half which uses our own SSL stack and is not vulnerable to OpenSSL. Our SSL stack is not OpenSSL. The second half is the management half which does use OpenSSL.

We validate our internal SSL stack against all SSL vulnerabilities posted against all SSL stacks out there.

For our OpenSSL implementation, we keep it patched for all the latest security issues, but not for the latest features. This is done to mitigate risk and maintain a stable code base where possible. Because the features do not change, we leave the version number of OpenSSL alone (openssl version) so that components that look at the version number to determine which API to use behave themselves.

We use this strategy across all of the relevant opensource we use, including OpenSSH. This leads to false positives from some security scanners that only use the version number to determine if a stack is vulnerable.

Shame on Me!

Shame on me, it has been more than a year between blogposts. It has been a busy year so that’s good. Hopefully I will find some time next weeks to start writing again.