SungHoon_Kim

Why suddenly Policy Server fails to connect to AD user/policy store via LDAPS connection?

Blog Post created by SungHoon_Kim Employee on Dec 10, 2015

SiteMinder Policy Server supports LDAP: namespace and AD: namespace.

 

LDAP namespace is using Netscape LDAP SDK as LDAP client.

AD namespace is obviously using MS SDK as LDAP client.

 

In case if your environment was working fine and out of nowhere your policy server fails to connect to AD (using LDAP namespace) without any error then this might match your use case.

     You try to view contents from AdminUI and don't get any error but just an empty result.

     smps.log also do not report any error.

 

This can be due to the AD Server Certificate being silently renewed.

Usually the Certificate AutoRenew can kick in 6 weeks before expiry.

There are Certificate Templates that will be used and it will depend on that template to decide what the certificate will be like.

 

If you load mmc and add "Certificate Templates" then you will get to see how the templates are configured by default.

 

What you want to check is "Domain Controller" template and "Domain Controller Authentication" template.

 

There are differences between the two templates and following will interest you.

 

[Domain Controller Template]

You can see here that the SUBJECT NAME will be sourced from the information available in the Active Directory.

DomainControllerTemplate.jpg

 

[Domain Controller Authentication Template]

You can see here that the SUBJECT NAME is "None"

And it is adding "ALTERNATE SUBJECT NAME" using DNS name.

DomainControllerAuthenticationTemplate.jpg

 

[SUBJECT NAME = CN]

 

The reason why I am showing this is because the SUBJECT in the certificate is a problem to Netscape LDAP SDK.

It does not, or have interest in the "Altername Subject Name". It is treated as some additional properties.

There are 3 generic checks performed in SSL communication.

 

     1. Is the Certificate Trusted? (Is its CA certificate found in my certificate store?)

     2. Does the Certificate CN match the hostname?

     3. Is the Certificate Valid?

 

From the #2 above, Policy Server will validate the server by comparing the server name against the CN value of the server certificate.

And if the CN value has no value, obviously it will fail to authenticate the server.

 

Then what is the default Domain Controller's AD Certificate in the first place? Did it have SUBJECT(CN) in the first place when Domain Controller was setup?

 

Following screenshot will explain the template used for the initial Active Directory was from "Domain Controller" template.

And it also shows that the SUBJECT has a value of TESTMC1.ssl.lab.

Domain_Cert.jpg

 

I am attaching the sample Domain Controller Certificate and its CA certificate for reference.

(Remove the .zip extension from the file. All attachments get .zip extension but they are not zip files.)

 

So, if the AD server certificate was renewed and if it was issued using "Domain Controller Authentication" template, then you will have issue connecting to the Active Directory via LDAPS.

 

[Solution]

Issue a new certificate using "Domain Controller" template.

Or, you may need to consult with your Certificate Authority Manager and see if they can update the "Domain Controller Authentication" to have SUBJECT, the same way as "Domain Controller" template.

 

[Considerable workarounds]

1. Temporarily use non-secure port but you will not be able to reset user password via SiteMInder.

2. Use AD namespace. But you cannot modify the existing user store definition from "LDAP:" to "AD:".

So you will need to create a new instance using AD namespace and reconfigure all your policies ==> It may not be realistic for customers having lots of policies.

 

*** This is now posted as a Knowledge Document linked below.

http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec1436002.aspx

 

Attachments

Outcomes