Random users not found in search / Can not log in

Openfire Openfire Support
1

Hello all -

We are using Openfire 3.6.0a with Active Directory querying LDAP port 3268 for the entire forest. I have now run into 6 random users that are unable to login at all through Spark. Also, I am unable to find these people when using the ‘Search’ feature in Spark or using the ‘User Search’ feature on the Openfire Server console.

The affected accounts are all active and have no settings/group policy that prevent them from being found in Spark or through LDAP. I have gone through every Active Directory Attribute for these people in ADSIEdit and see no differences in their accounts. I CAN find these people using different LDAP lookup utilities, so I know this is not a domain or LDAP issue.

The work around is to delete or create a new Active Directory account for these people with a different User Logon Name (pre-windows 2000).

With a couple of the affected people, I have attempted changing the Alias, with no luck. I have found that to get this to work, I must delete their current account, or create a separate domain account for them, with a different Pre-Windows 2000 logon name.

For example in Active Directory, John Doe with a logon name of ‘DoeJ’ can not be found in Spark through searching nor can they log in. If I create a different account with ‘Doe’ as the new logon name the person is found.

I have even deleted the ‘DoeJ’ account (and what a headache that is to recreate the users profile, mail, etc…), allowed for replication across the forest to occur, then recreated another account with ‘DoeJ’ and it still does NOT work…

It seems that Openfire just does not like random User Logon Names and will not work with these people.

Does anyone have any information or thoughts on this? Of course, the VP of HR is one of the few affected people and recreating her account is not an option, and creating secondary accounts for people just are not a realistic solution (security reasons, password change policy headaches, etc. just for secondary ‘IM’ AD accounts).

2

This is a common problem with AD. It could be caused by account corruption in AD (again very common, it is windows after all) or by AD query limits as only the first 1000 results are returned by default. Creating a new account changes the query results order.

3

Thanks for the reply…

Even if the query order is changed, Deleting an existing account (with Openfire Lookup issues), and creating a new account with the same Pre Windows 2000 Logon Name - it still does not work. This seems to be a bit odd that I can look up these accounts through any other 3rd party LDAP tool over port 3268, yet Openfire is the only application that is having problems.

And you are correct that by default return value is 1000, but this does not affect the total # of accounts in OpenFire. This is evident through the ‘User Search feature’ in the Openfire Admin console.

Any other ideas?

4

It still has something to do with the account in AD. You have confirmed this by creating a new account with a new name. The old account may be cached somewhere in Openfire which is why it will not find it when it is recreated with the same name. It also may be a case of AD replication, when deleteing and recreating. Maybe yoiu did not allow enough time to propigate the deletion change before you recreated. Additionally if you are using exchange try seeing the account prior to reattaching the mailbox to the new account. The issue could be exchange related. this has happened before as well, where the corruption is at the mailbox level of the account.

5

Hello all - I have found the issue… And it is due to the way Openfire Auto creates accounts when performing LDAP lookups.

I have figured out why random users are not found in the LDAP search with Spark/Openfire. I have configured Openfire to search the entire forest (port 3268) for users in our organization - obviously this includes all of our child domains in the forest.

When Openfire queries AD, it completely ignores the child domain and only looks at the pre-windows 2000 user id. If there are two user id’s that match identically, Openfire does not know what to do with them, so the application simply does not return a result for that person.

For Example - John Doe in Child domainA would have the pre-Windows login of ‘domainA\doej’. Jane Doe in Child domainB would have the pre-windows login of ‘domainB\doej’. Openfire ignores the ‘domainX’ information and will not create an Openfire account for the users since they both have the ‘doej’ username.

I am working to configure Openfire to include the domain in the Openfire login name, but havent tested as of yet, nor know what implications this will have to existing users. I will update at a later date when I have that information.