Skip navigation
All People > SungHoon_Kim > Sung Hoon Kim's Blog > 2015 > December
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

 

If you have an LDAP server and you want to connect using TLS1, and your connection is failing. What do you do next?

 

It doesn't matter if it is LDAP or HTTP.

You can use openssl to connect to it with specific protocol and see which one is successful and which one is not.

 

openssl s_client -connect <server:port> [-ssl2|-ssl3|-tls1] [-CAfile <CA Certificate>]

 

Following is a sample  output when trying to connect to www.google.com:443 using 3 different protocols.

SSLv2 was rejected.

SSLv3 was accepted

TLSv1 was accepted

 

You can see the server replying what protocol it will accept.

 

Connections -ssl2 -ssl3 -tls1

C:\> openssl s_client -connect www.google.com:443 -ssl2

Loading 'screen' into random state - done

CONNECTED(000001A4)

6020:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:.\ssl\s2_pkt.c:428:

C:\>openssl s_client -connect www.google.com:443 -ssl3

Loading 'screen' into random state - done

CONNECTED(000001A4)

 

depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

verify error:num=20:unable to get local issuer certificate

verify return:0

---

Certificate chain

0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com

   i:/C=US/O=Google Inc/CN=Google Internet Authority G2

1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2

   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIEgDCCA2igAwIBAgIIPdT6GgLd9RowDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE

BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl

cm5ldCBBdXRob3JpdHkgRzIwHhcNMTUxMTI1MjM1ODIyWhcNMTYwMjIzMDAwMDAw

WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN

TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOd3d3

Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCLAOQm

O2VgGU0aOmmePDlf5iQlv0QNVP6njfkUl7Fn7elhqY/e+EK+hOpuQzMxif6fdx9n

f38ElikpyWGtEmq2edfDjNcVHaq0KRg3QQs/LdEcKgQVm+hjiLN7DSDxOfwU2zll

yxR7RaszXWd1pYqDFMqjlt4E9h1YRAr5ydgkahUpJhmf1yUuT6La2WKa/r6XMyJ9

GZdu0Y2HOO5YVPeOyCxFSq66abWq/xKtxMuGi+sJGoW4aXN5mbemBn0aF0Us1k3u

GgiRnQfCuWjUkMbNR97WNqES/IJXD6GuLVH7jZVhOeXso8g66DAxzFOzFM+P5ihy

qo8RdyyNY8ao8LDRAgMBAAGjggFLMIIBRzAdBgNVHSUEFjAUBggrBgEFBQcDAQYI

KwYBBQUHAwIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20waAYIKwYBBQUHAQEE

XDBaMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0

MCsGCCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0G

A1UdDgQWBBTRwgCCdfWJaxML7yIFzOuB25yrozAMBgNVHRMBAf8EAjAAMB8GA1Ud

IwQYMBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMCEGA1UdIAQaMBgwDAYKKwYBBAHW

eQIFATAIBgZngQwBAgIwMAYDVR0fBCkwJzAloCOgIYYfaHR0cDovL3BraS5nb29n

bGUuY29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQsFAAOCAQEAJSSBOqxtVR9aQlHk

w1ijGVuMmaeVnrv6DcUZK+O1y2+HbKEZ6c84l2TScJpTkif1XORwSq50g6OEmmB0

lLKY/shlk/5Ywf+8W+h1moTw4TXEI8ASpG7hzKfkKAl7qhfv1K1Zh6cPx0zHmJkh

JdcK9uSt91XzxzQJvvFWM52ywlEdsCHyTzNJrhy8oeMvae8EqYq8u923b6gvMDP7

w8gZQdNHv8Q2L7Bo6Ud3C7e2FMXnEgbElpiYwlYJ5ZX5l2L/9a7xyh6DbpxcS1dO

CB32HWKmBs8SZ5HibLaqNhpV0b9nKlyJZiKpHKWYhIjK285QTFBZx3QfKVNKMV1d

5S+LyA==

-----END CERTIFICATE-----

subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com

issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2

---

No client certificate CA names sent

---

SSL handshake has read 3245 bytes and written 424 bytes

---

New, TLSv1/SSLv3, Cipher is RC4-SHA

Server public key is 2048 bit

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : SSLv3

    Cipher    : RC4-SHA

    Session-ID: 51FB4F7B6C9356C3B9660C6F21FCA95129A29EA97B241EEFAB4AB6B3445F9CF7

    Session-ID-ctx:

    Master-Key: EA56764B14C836380F3A3AAB74F69B7BDC6B872BCE619E79DA511D71167804A43BEF4FFD7207BDC10B6362EDC25F40D8

    Key-Arg   : None

    Start Time: 1449628122

    Timeout   : 7200 (sec)

    Verify return code: 20 (unable to get local issuer certificate)

---

C:\>openssl s_client -connect www.google.com:443 -tls1

Loading 'screen' into random state - done

CONNECTED(000001A4)

 

depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

verify error:num=20:unable to get local issuer certificate

verify return:0

---

Certificate chain

0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com

   i:/C=US/O=Google Inc/CN=Google Internet Authority G2

1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2

   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIEgDCCA2igAwIBAgIIPdT6GgLd9RowDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE

BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl

cm5ldCBBdXRob3JpdHkgRzIwHhcNMTUxMTI1MjM1ODIyWhcNMTYwMjIzMDAwMDAw

WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN

TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOd3d3

Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCLAOQm

O2VgGU0aOmmePDlf5iQlv0QNVP6njfkUl7Fn7elhqY/e+EK+hOpuQzMxif6fdx9n

f38ElikpyWGtEmq2edfDjNcVHaq0KRg3QQs/LdEcKgQVm+hjiLN7DSDxOfwU2zll

yxR7RaszXWd1pYqDFMqjlt4E9h1YRAr5ydgkahUpJhmf1yUuT6La2WKa/r6XMyJ9

GZdu0Y2HOO5YVPeOyCxFSq66abWq/xKtxMuGi+sJGoW4aXN5mbemBn0aF0Us1k3u

GgiRnQfCuWjUkMbNR97WNqES/IJXD6GuLVH7jZVhOeXso8g66DAxzFOzFM+P5ihy

qo8RdyyNY8ao8LDRAgMBAAGjggFLMIIBRzAdBgNVHSUEFjAUBggrBgEFBQcDAQYI

KwYBBQUHAwIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20waAYIKwYBBQUHAQEE

XDBaMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0

MCsGCCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0G

A1UdDgQWBBTRwgCCdfWJaxML7yIFzOuB25yrozAMBgNVHRMBAf8EAjAAMB8GA1Ud

IwQYMBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMCEGA1UdIAQaMBgwDAYKKwYBBAHW

eQIFATAIBgZngQwBAgIwMAYDVR0fBCkwJzAloCOgIYYfaHR0cDovL3BraS5nb29n

bGUuY29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQsFAAOCAQEAJSSBOqxtVR9aQlHk

w1ijGVuMmaeVnrv6DcUZK+O1y2+HbKEZ6c84l2TScJpTkif1XORwSq50g6OEmmB0

lLKY/shlk/5Ywf+8W+h1moTw4TXEI8ASpG7hzKfkKAl7qhfv1K1Zh6cPx0zHmJkh

JdcK9uSt91XzxzQJvvFWM52ywlEdsCHyTzNJrhy8oeMvae8EqYq8u923b6gvMDP7

w8gZQdNHv8Q2L7Bo6Ud3C7e2FMXnEgbElpiYwlYJ5ZX5l2L/9a7xyh6DbpxcS1dO

CB32HWKmBs8SZ5HibLaqNhpV0b9nKlyJZiKpHKWYhIjK285QTFBZx3QfKVNKMV1d

5S+LyA==

-----END CERTIFICATE-----

subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com

issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2

---

No client certificate CA names sent

---

SSL handshake has read 3233 bytes and written 414 bytes

---

New, TLSv1/SSLv3, Cipher is AES128-SHA

Server public key is 2048 bit

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : TLSv1

    Cipher    : AES128-SHA

    Session-ID: 3D9FC8E43F4215A8E4D014E98A531C92DF71CBED07BAF26645D668B4AC416F0B

    Session-ID-ctx:

    Master-Key: 150ED15765714B4AE1F6E21265BE6D452220580E5ABD82CD00BC9D4FE011336569DE730E3128B081B31A2BF09326E3EA

    Key-Arg   : None

    Start Time: 1449628146

    Timeout   : 7200 (sec)

    Verify return code: 20 (unable to get local issuer certificate)

---

 

You can also capture network and follow the TCP stream that shows "Client Hello" and see which protocol it was attempting.

The client will send a list of protocols it supports because it would not know which protocol the server supports until it actually makes connection to it.

Then the server would choose one protocol from the list that it prefers. This is where you will see "Server Hello" message in the network trace.


If you are getting "Server Hello" then the connection is established.

 

Next the client will have to perform "Server Authentication" aka 1 way SSL.

Client performs the following and if all passes then the server is authenticated.

 

1. Is the "Issuer" found in the local certificate store and trusted?

2. Does the server's FQHN match the "CN" (or SUBJECT) of the server certificate?

3. Is the server certificate still valid? (not expired?)

 

If the above does not pass, then you will see the client dropping (RESET) the connection.

If passed, then you will see the client encrypting the data and sending over to the server.