LDAP Changes Lockout All Users

johann.kruger

We are having an issue with LDAP authentication and user administration that is becoming a Serious and Urgent one to resolve.

The Scenario:
The Business Space (application) is hosting a business application used by a large user group within a global mining company. We are using Single Sign-on through LDAP authentication.
The AwareIM application is configured in such a way that we (an Administrator) add users manually to RegularUsers and link this user to the relevant LDAP user through the sAMAccountName attribute.
AwareIM stores the LDAP_DistinguishedName attribute for the relevant user in the LDAP Object table.

Problem Statement:
The LDAP is maintained by a Global Service provider for the client and we don't have full visibility on when and what changes are made to the LDAP configuration.
As soon as the LDAP entry for ONE of the users that has been added to the AwareIM application change in any of the following ways:

1. The DistinguishedName attribute is changed in the LDAP; or
1. The user account is removed from the LDAP.

Then all the users previously configured to have access to the AwareIM application are unable to login to the application.
The Wrapper.log file has an Error that looks like this:

jvm 1 | 2011/02/28 13:05:32 | 2011-02-28 13:05:32,219 ERROR -Unable to login due to system error
INFO | jvm 1 | 2011/02/28 13:05:32 | com.bas.basserver.executionengine.ExecutionException: Internal error. Problem in sAMAccountName.displayName for shortcut attribute SC_LDAP_User Error reading LDAP entry CN=Houghton\, Yvette (Manganese - BI Contractor),OU=Contractors,OU=Manganese 6 Hollard,OU=Users,OU=Corp Johannesburg,OU=Corporate,DC=emea,DC=ent,DC=bhpbilliton,DC=net No Such Object
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.executionengine.s.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.executionengine.s.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.executionengine.ExecutionEngine.doExecuteQuery(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.executionengine.ExecutionEngine.executeQuery(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.login(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.channels.ChannelManager.handleSocketLoginRequest(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.bsmanager.k.run(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at java.lang.Thread.run(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | com.bas.basserver.executionengine.ExecutionException: Internal error. Problem in sAMAccountName.displayName for shortcut attribute SC_LDAP_User Error reading LDAP entry CN=Houghton\, Yvette (Manganese - BI Contractor),OU=Contractors,OU=Manganese 6 Hollard,OU=Users,OU=Corp Johannesburg,OU=Corporate,DC=emea,DC=ent,DC=bhpbilliton,DC=net No Such Object
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.executionengine.s.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.executionengine.s.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.executionengine.ExecutionEngine.doExecuteQuery(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.executionengine.ExecutionEngine.executeQuery(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.a(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.session.SessionManager.login(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.channels.ChannelManager.handleSocketLoginRequest(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at com.bas.basserver.bsmanager.k.run(Unknown Source)
INFO | jvm 1 | 2011/02/28 13:05:32 | at java.lang.Thread.run(Unknown Source)

Interim Solution:
We have to find the user account that causes the problem and either correct the LDAP_DistinguishedName field in the LDAP table or delete the user and re-create the user account for the AwareIM application. (We only have to delete the entry in the RegularUser Objects to get the remaining users to be able to log on.)

Question:

1. Why does a single user entry in the RegularUser table that is linked to a invalid/non-existent LDAP account cause all the user logon attempts to result in exception and therefore they can't access the appellation?
1. Is there another/better way to configure the login option or user objects to solve this problem?

aware_support

As a workaround please remove shortcuts to the LDAP object from the RegularUser object

technobbs

I have been crawling the forums for a problem I have been having around LDAP authentication as well, the situation is pretty much the same as Johan's in that the LDAP is maintained by some other service provider and visibility is quite limited.

Scenario:
I have a few LDAP servers configured for authenticating the different users who sit at different sites.

Problem statement:
What happens is that sometimes one of these servers becomes non-operational, but when that happens it affects all the users even the ones who don't get their credentials validated against the problematic LDAP server.

Does AwareIM do a round robin with all the LDAPs? is there a different way of configuring this?

The remedy is painful because it's largely curative after the client experiences frustrations not being able to log on, I use ADexplorer to identify the problematic LDAP server and this is followed by an exclusion of that LDAP entry and a republish of a minor version, it is not ideal.

Help much appreciated.

aware_support

Is your LDAP object represented by a group? If so, Aware IM will attempt to login through each of the members of the group, but it shouldn't fail if one member is unavailable.

What is the output of the Aware IM server when the user from a good LDAP attempts to login and is affected by the bad one?

technobbs

That is correct, the LDAP object is represented by a group, LDAP_user group, and all the LDAP servers have individual entries under this group.

And it does look like the authentication process is pretty serial, going from one LDAP to another till it finds the right one, this order of interrogation I have also observed is the same order that the LDAP entries are added on the LDAP user group during configuration, I cannot seem to reorder these by the way, it gets automatically done for me.

There are 5 LDAP servers, and there is always one particular problematic LDAP server, which will always be 3rd in the list, when this server is not operational, AwareIM does not skip to 4th and 5th, it stops here, and it just so happens that most of the user base is authenticated agains LDAP servers 4 and 5.

If there was a way of ordering these entries during config I could then potentially avoid a bit of pain by putting the problematic server last in the list, I have tried this, they just get ordered for me automatically.

aware_support

Please try the latest build 1599 that has a small change that in theory could resolve this

technobbs

Thank you I will start looking at the new build.

Can you tell me why this happens, if I had to write a follow up RCA after an incident and maybe recommend this newer build to my client?

I will motivate for the new build like you recommend, but my client is quite tech savvy so I need to treat them as such, I would appreciate if you told me why this happens, and what it is that the new build does differently.

aware_support

We don't know for sure whether the change we made fixes the issue, but when looking for the user Aware IM was running a query on every object in the group. If the query on one object threw an exception the whole process was aborted. Now it keeps querying every object and doesn't stop if an exception was thrown in the middle.