Archive for October, 2015

Troubleshooting the D1IM LDAP Authentication Module

October 10, 2015 Leave a comment

During a recent Go-Live with Dell One Identity Manager 6.1.2 we ran into some issues establishing the IT-Shop authentication leveraging the LDAP Authentication Module. I’d like to use this blog post to share all the know how we were able to gather and participate within the finding.

So here’s the setup we were using:
We had a custom D1IM 6.1.2 IT-Shop application being published to a set of Windows 2008 R2 based IIS web servers. The authentication had to established against Novell eDirectory 8.8 SP8 using LDAPS via Port 636.

This is the way it was intended to work out:
The user lands on the IT-Shop login page being asked to enter the username and password. D1IM looks up the LDAPAccount table for user, having the given user name. When found, D1IM grabs the Distinguished Name of the identified LDAPAccount object and uses this one in combination with the given password to do a login using the LDAPADSI bind functionality against the configured LDAP directory to authenticate the user. If the authentication was successful, the user will be logged into the IT-Shop using the Person object being connected to the LDAPAccount object.

Here’s how we approached the activation of the LDAP Authentication Module:
We went into Designer and activated the Dynamic LDAP Authentication Module and fed it with the configuration data, specifically the LDAP RootDN, the FQDN of the LDAP server (which initially was a F5-FQDN load balancing against all the LDAP servers), port number and the authentication method. Having this in place, we went into web portal configuration tool to activate the LDAP authentication module.

Then we were pretty much done… At least, we thought we were. Testing the LDAP based authentication ran into the first issue: in the IT-Shop log we saw the following error message:

Value RootDN is required for authentication

 As we had the RootDN being configured into the module configuration we did cross check the current setting with the real RootDN of the LDAP directory and the domain object being established in D1IM finding no failure at all. So we opened up a service request with Dell Software Support.

Finding #1 was, that the IT-Shop is not able to leverage the configuration of the LDAP authentication module. Therefore, we needed a manual entry in the web.config as the configuration is not able to define the necessary key. Dell provided this information in a Kb article pretty quick. The KB can be found here:

 So we put our LDAP configuration into the web.config and did a retest which ran into the next issue: looking up the IT-Shop log we now did find the next error message:

The server is not operational

So we did use the VINSProviderTest.exe to test login into the LDAP directory from one of our web servers. Using the LDAPNovell Provider, the login was all fine, using the LDAPADSI provider which the LDAP authentication modules is leveraging failed. So we had the intention that the LDAP authentication module is not compatible to work with a Novell eDirectory for LDAP authentication. So while mailing back and forth with Dell Support we did came to the conclusion that we would need a custom authentication module talking LDAPNovell for our customer, which would have been a massive challenge due to the limited till Go-Live.

But here’s the good news: it does work with Novell eDirectory for LDAP authentication if all the environment configuration is right.

As i mentioned, we did configure the F5-FQDN which is load balancing all the LDAP requests onto the LDAP servers in the infrastructure. Being asked by Dell Support, we were looking up the SSL certificate of the LDAP servers finding the issue, that the web servers did not have the Root-CA certificate being installed to trust the certificate at all. Installing the root certificate removed the warnings from the server certificates. But it did not help us authenticate. So we did check the certificate path of the server certificates next and recognized, that those were server specific but there was no certification path for the F5 loadbalancer. So in next step, we talked to the LDAP team if there was any chance to add alternate subject names to their certificates carrying the F5-FQDN to be leveraged by the LDAPADSI provider to authenticate successfully. But this approach was unsuccessful due to timing issues as well with regards to our Go-Live.

Dell did bring online a KB describing this issue as well which can be found here:

So we ran into the next workaround: connecting to one of the LDAP server directly bypassing the F5 Loadbalancer. But even this was unsuccessful. We were near to the goal but we still ran into the issue that the authentication was failing with the error message „The server is not operational“. What came now has nothing to with D1IM at all but we were not aware of what was coming next….

Being totally desperate, we got hand onto one the best Novell eDirectory engineers of the customers organization to do a LDAP trace while trying to login. What we saw was pretty upsetting:

SSLv3 handshake failed: no matching ciphers found

So we started looking into the security configuration. Based upon the security policy of the customer organization, the System Integrators did some hardening work on the IIS servers being used for the D1IM IT-Shop, disabling everything except TLSv1.2 and disabling weak encryption ciphers to comply with security policy. Next step in our troubleshooting procedure was an approach of one of our System Integrators, using the OpenSSL tool suite to test-drive the available SSL / encryption features being supported by the current instance of the Novell eDirectory. The result was pretty disgusting: SSLv3 and TLS1.0 but nothing more secure. So the LDAP engineers did open a service request with Novell, which ended up in being told that Novell eDirectory does not support TLSv1.1 and TLSv1.2. Such support will be available with Novell eDirectory 9.0 somewhat in 2016.

After getting an exceptional approval by the customers IT security office, we did lower the SSL / encryption level of our D1IM web servers. Since the we’re successfully authenticating against the customers Novell eDirectory.

So if you ever want to use the D1IM LDAP authentication module in the IT-Shop portal, there shouldn’t be any more you can run into regarding potential issues.

I also wanted to use this blog post to say „many thanks“ to Rene O. from Dell Support and Ralph G. from the Dell Development Department in Dresden who were not loosing the faith into D1IM and the authentication module till the end. I think we all learned a lot during the time we were dealing with this special service request.

Categories: D1IM, IAM, Identity, IDM, Programming, Tools