Archive for the ‘Programming’ Category

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

A D1IM programming snippet

August 1, 2015 Leave a comment

There has been a discussion about an implementation detail within Dell One Identity Manager with two colleagues that came up during my family vacation and which i took on after being back at my desk Thursday this week. It all started with the simple question how to catch the event name that triggered a process. The initial answer was „there’s no way to get there“ but this answer is at least outdated. Sure there is a way to catch the event name in an D1IM process by using the EventName-property. So just in case you have a process that is raised by two different events but you want to have a process step being generated only for one dedicated event, the generation condition would look like this:

Value = CBOOL(EventName = <Name of the Event>“)

Just wanted to share this, it might be a helpful snippet in the one or the other project implementation.

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

Troubleshooting SAP .Net Connector issues

February 2, 2015 Leave a comment

While working with the SAP .Net Connector in a demo environment I was struggeling with the following error message being posted by my SAP connectivity component:

The type initializer for 'SAP.Middleware.Connector.RfcConfigParameters' threw 
an exception.

Checking the application eventlog I found the following error message:

Activation context generation failed for "C:\Program Files (x86)\Quest Software\Quest One Identity Manager\sapnco_utils.dll". Dependent Assembly Microsoft.VC80.CRT,processorArchitecture="x86",

publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.4053" could not be found. Please use sxstrace.exe for detailed diagnosis.

This came with the Event-ID 33 of source SideBySide.

This error message indicates that the Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update is missing. The update is available here:Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update

More details on the Security Update is available here: Description of the security update for Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package: July 28, 2009

Categories: Programming