Connecting the world…


Windows LDAPS expired

A lot of appliances and/or security solutions use LDAP to synchronize users from an Active Directory or an eDirectory environment. Active Directory is LDAP enabled by default. If you would like to harden your network,  you would like to use LDAPS.

LDAPS is a term to refer to LDAP communication over SSL. Intercepted LDAPS traffic cannot be read easily by hackers. In an Active Directory environment you need to have at least one Certificate Authority (CA) to enable LDAPS. Windows uses Server Authentication certificates for the LDAPS operations.

Last week I had a customer complaining that people weren’t able to access their webmail via a Microsoft ISA reverse proxy. The cause of the problem was an expired Server Certificate on the specific domain controller. The reverse proxy server uses LDAPS to authenticate the user against an Active Directory. The following event log was found on the reverse proxy server.

ldaps-error To resolve the problem I had to renew the Server Authentication certificate on the domain controller. I decided to use the “Windows method” by using the Windows CA to renew the certificate. From the domain controller with the expired certificate I opened IE and enter the URL:

http://<IP address CA>/certsrv

This opens the Microsoft Certificate Services webpage of the CA. The following screenshots show the request and installation procedure for the certificate renewal.

01_request-certSince I had to renew a Server Authentication certificate, I choose the option Request a certificate.

02_advanced To request a Server Authentication certificate I choose the option advanced certificate request.

03_create-and-submit Normally I use OpenSSL to generate the certificate signing request, which is submitted to the CA. In that scenario I had to choose option 2. This time I decide to generate the csr via the webpage and choose the first option: Create and submit a request to this CA.

04_webserver The csr is generated with the information from the screenshot above. Because I had to renew a Server Authentication certificate, I choose the Web Server certificate template. The Name field is very important and should match the FQDN of the LDAPS server. It is also important to select the Store certificate in local computer certificate store option. This ensures that the certificate isn’t installed in the user’s certificate store, because the certificate cannot be exported with private key.

When you submit the certificate request, you have to wait until the request is approved. The approval has to be done by someone who manages the CA environment. If you open the CA MMC snap-in you will see one or more pending request. The pending request needs to be approved. After the request was approved, I browsed to the Microsoft Certificate Services webpage, like shown below.

05_status_pendingI choose the option View the status of a pending certificate request. Remember that I did the whole procedure on the LDAPS server to be sure that the certificate is stored in the servers local computer certificate store. The last step involves installing the certificate in the local computers certificate store. After the installation I always check the store to see if the private key is present for the certificate.

06_install_certThe renewal of the certificate is almost done. The LDAPS services depends on the process LSASS.exe. To “associate” the SSL certificate with the LDAPS server I needed to reboot the server. During the reboot the first valid Server Authentication SSL certificate within the local computer certificate store is used by the LDAPS server.

The reverse proxy server was able to use LDAPS again after the reboot of the specific domain controller.

Citrix Access Gateway: duplicate STA ID

I received complains from a customers who wasn’t able to add two new Citrix servers to his Citrix Access Gateway configuration. He could successfully add the first Citrix server, but he couldn’t add the second Citrix server, because the first was overwritten by the second. I looked at the problem and noticed that both Citrix server were using the same STA Identifier.

After asking some question about the installation of the Citrix server, I discovered that the second Citrix server was a clone of the fist Citrix server. That is why both servers have the same STA Identifier. The STA ID from a Citrix server can be changed by altering the file CtxSta.config. By default a Citrix server has two CtxSta.config files, located at the following destinations (default installation):

  • C:\Program Files\Citrix\System32;
  • C:\Inetpub\Scripts;

I had to change the STA ID in the C:\Inetpub\Scripts directory, because IIS was used to share port 80 on the server. The CtxSta.config file contains a UID, like the example below:










; Allowed Client IP addresses
; To change, substitute * with client IP addresses. Use ";" to seperate IP addresses/address ranges.
; To specify a range of IPs always use StartIP-EndIP.
; For example, AllowedClientIPList=;;


; SSL only mode
; If set to on, only requests sent through HTTPS are accepted

I changed the UID on the second server and restarted IIS. I tried to add the Citrix server to the Citrix Access Gateway, which is now possible with the new unique STA ID. The last step is adding the second Citrix server to the Citrix WebInterface (server farm & STA ID).

OpenSSL & Cygwin – Certificate Authority

I am using OpenSSL in conjunction with Cygwin on my Windows laptop to generate Certificate Signing Request and other SSL certificate related issues. Today I configured my own Certificate Authority, using the following guideline.


First I created some directories, like shown below:

mkdir /home/sslCA
cd /home/sslCA
mkdir certs private newcerts

Next I created a serial file which will be used to name the new certificates generated and an index.txt file.

echo 1000 > serial
touch index.txt

Generating the CA

After setting up the appropriate directory, I generated the Certificate Authority, like shown below.

cd /home/sslCA
openssl.exe req –new –x509 –days 3650 –extensions v3_ca \
-keyout private/cakey.pem –out cacert.pem \
-config /usr/ssl/openssl.cnf

The command above generates the following output:

Generating a 1024 bit RSA private key
writing new private key to ‘private/cakey.pem’
Enter PEM pass phrase:
Verifying – Enter PEM pass phrase:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
Country Name (2 letter code) [NL]:
State or Province Name (full name) [Some-State]:Noord-Brabant
Locality Name (eg, city) []:Eindhoven
Organization Name (eg, company) [Internet Widgits Pty Ltd]:4IP BV
Organizational Unit Name (eg, section) []:IP Consultancy
Common Name (eg, YOUR name) []:4IP Root CA
Email Address []:

Now I have a running Certificate Authority, which is ready to signing new certificates.


If you would like to add SubjectAltNames to your certificate, you can add the names by adding them to an extensions file. Below is an example of the file, which I named booches.extensions.cnf

subjectKeyIdentifier = hash

DNS.1 = *


Performing an SSL Request

I used the following command, with it’s output, to generate an SSL Certificate Signing Request.

cd /home/sslCA
openssl req -sha256 –new –nodes \
-out cert-www-4ip-nl.pem \
-keyout private/priv-www-4ip-nl.pem \
-config /usr/ssl/openssl.cnf

Generating a 1024 bit RSA private key
writing new private key to ‘private/priv-www-4ip-nl.pem’
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
Country Name (2 letter code) [NL]:NL
State or Province Name (full name) [Some-State]:Noord-Brabant
Locality Name (eg, city) []:Eindhoven
Organization Name (eg, company) [Internet Widgits Pty Ltd]:4IP BV
Organizational Unit Name (eg, section) []:IP Consultancy
Common Name (eg, YOUR name) []
Email Address []:

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Signing CSR

The last step in the process is signing the CSR. I used the following command to sign the CSR.

openssl ca –config /usr/ssl/openssl.cnf \
-out sslcert-www-4ip-nl.pem \
-extfile booches.extensions.cnf\
-infiles cert-www-4ip-nl.pem

When you want to configure a certificate to use with Windows Server 2003 IAS vor MS-PEAP authentication, you have to add the option ‘-extensions server_ext’. This command results in the following output:

Using configuration from /usr/ssl/openssl.cnf
Enter pass phrase for /home/sslCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 4096 (0x1000)
Not Before: Sep 30 11:01:11 2009 GMT
Not After : Sep 28 11:01:11 2019 GMT
countryName               = NL
stateOrProvinceName       = Noord-Brabant
organizationName          = 4IP BV
organizationalUnitName    = IP Consultancy
commonName                =
X509v3 extensions:
X509v3 Basic Constraints:
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
X509v3 Authority Key Identifier:

Certificate is to be certified until Sep 28 11:01:11 2019 GMT (3650 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Now I have all the appropriate files:

  • Certificate: /home/sslCA/sslcert-www-4ip-nl.pem
  • Key: /home/sslCA/private/priv-www-4ip-nl.pem

Converting to PKCS#12

Windows environments normally use PKCS#12 files. The following command generates a PKCS#12 file with the user certificate, the private key and the CA certificate:

cd /home/sslCA

openssl pkcs12 –export –out www-4ip-nl.pfx \
-inkey private/priv-www-4ip-nl.pem \
-in sslcert-www-4ip-nl.pem \
-certfile cacert.pem

This commands generates the appropriate PFX file (www-4ip-nl.pfx) for specific Windows environments, like IIS. Other usefull commands to convert certificate formats can be found here.

I added the following lines to openssl.cnf to use the extensions option for EAP authentication with Windows Server 2003 IAS.

[ client_ext]
extendedKeyUsage =

[ server_ext]
extendedKeyUsage =

Change password through LDAPS on ISA server

Today I received the question about allowing users to changes his/her password through webmail, whereby webmail is published via an ISA server 2006 reverse proxy. This is possible, but it requires the configuration of LDAPS to authenticate users.

I started by configuring a Certificate Authority (CA) on a member server in the domain. During the installation of CA a root certificate is generated. You need to export this root certificate with private key. Next I imported the certificate on the reverse proxy server, but didn’t mark the private key as exportable. So the root certificate cannot be exported from the reverse proxy server with its private key in the future. I checked if binding to the Active Directory is possible by using the tool ldp.exe.

The last part is configuring LDAP Validation in ISA. Go to Configuration –> General –> Specify RADIUS and LDAP Servers. First you need to add a LDAP server set, like shown in the following picture.

Important when configuring the LDAP server set is the usage of the FQDN as LDAP server hostname. This FQDN should be exactly the same compared to the FQDN mentioned in the imported root certificate.

The last step is configuring the LDAP server mapping, which is also shown below.

Because I don’t want to add a domain name during the login procedure on the OWA login page, like DOMAIN\USER, I use the Login Expression wildcard character * and link that to the configured LDAP server set. Now you can login with just username and password, instead of domain\username and password.

Next I configure a OWA Publishing policy like always, but on the Listener I use LDAP as authentication mechanism. On the Listener Forms tab you can enable or disable the options:

  • Allow users to change their passwords;
  • Remind users that their passwords will expire in this number of days;

These options add some extra option to the OWA login page. Another step to configure is the allowed users. In most environments I use the group Domain Users as allowed OWA group, because mostly all users are allowed to use OWA, else you need to configure a separate user group in Active Directory. On the Users tab you remove the All Authenticated Users and click Add. You need to define a new user group, like shown below.

User Group

This means that if you are member of the group Domain Users, you are allowed to use OWA.

The last step is configuring the public path. When logged in to OWA, you have the option to change your password through the options page. To use this feature, you need to added another path to the Path configuration in the reverse proxy server. The path, which should be added, is /iisadmpwd/*, where the External Path is the same as the Internal Path.

Over at, Thomas Shinder wrote a great post about using LDAPS with OWA and multiple domains. The article is called LDAP Pre-Authentication with ISA 2006 Firewalls: Using LDAP to Pre-Authenticate OWA Access.