AD User account not found in GC search on port 3268
Hello all -
have a 3rd party application that queries our 2003 Active directory domain for User account information. I have configured the application to query port 3268. I have set the Base DN: to the root of the forest.
I can search every user in the forest successfully except 4 random User accounts that are not found by the application. The accounts are active and I see nothing peculiar about them in ADSIEdit. The accounts vary in age (3 are over 5 years old and the other is less than 6 months)
If I change the port to 389, and point the Base DN: to the child domain the accounts reside in, they are found by the application. (389 finds all accounts in child domain plus the 4 'trouble' accounts)
I have tried querying many different GC's in our organization all with the same results (finds all other domain accounts except these 4...)
It seems that there is something preventing these 4 accounts from being found in a Global Catalog search (3268).
Any ideas or pointers for trouble shooting this is VERY much appreciated.
have a 3rd party application that queries our 2003 Active directory domain for User account information. I have configured the application to query port 3268. I have set the Base DN: to the root of the forest.
I can search every user in the forest successfully except 4 random User accounts that are not found by the application. The accounts are active and I see nothing peculiar about them in ADSIEdit. The accounts vary in age (3 are over 5 years old and the other is less than 6 months)
If I change the port to 389, and point the Base DN: to the child domain the accounts reside in, they are found by the application. (389 finds all accounts in child domain plus the 4 'trouble' accounts)
I have tried querying many different GC's in our organization all with the same results (finds all other domain accounts except these 4...)
It seems that there is something preventing these 4 accounts from being found in a Global Catalog search (3268).
Any ideas or pointers for trouble shooting this is VERY much appreciated.
Dusan_Bajic
Are there multiple domains in the forest? If so, do you get the same result when you query GC on DC where accoutns reside?
ASKER
there are multiple domains in the forest (6 total) and the same results occur on any Global Catalog DC in any of those domains - including the root. Port 389 resolves the 4 people (and other users in the specified Base DN) but 3268 still represses just those 4 users.
I suspect that there are other users that will pop up with the same issue at a later date, but these are the only identified ones thus far.
I suspect that there are other users that will pop up with the same issue at a later date, but these are the only identified ones thus far.
Are users active and experience no problems? Can you recall anything unusual being done with these accounts (restoring from backup or something like that?)
Can you tell what LDAP query the application is making? Can you very the results with a manaul query (ie. with something like the Softerra LDAP Browser)?
ASKER
All of the users are working correctly, appear in the Global Address List (Exchange) and have no issues accessing domain resources. As far as the Users are concerned, they are experiencing no issues. The accounts havent been edited (at least not manually) by myself or any other admins.
ASKER
Softerra LDAP Browser is able to navigate to the 4 user accounts with no issues. I just installed and connected to a GC DC outside of the users' domain (DC in Root) over 3268 and was able to do a quick search for the users. So it appears that Softerra can see them.
I have a hard time believing that the 3rd party application is restricting certain users from the search, but I see nothing specifically wrong with the AD user accounts. Any other thoughts?
I have a hard time believing that the 3rd party application is restricting certain users from the search, but I see nothing specifically wrong with the AD user accounts. Any other thoughts?
That is really odd.
Are you using the same account for this test as the 3rd party app is using.
Are you using the same account for this test as the 3rd party app is using.
Any unusual characters in account names or other properties?
The ideal situation is to try to replicate exactly what the 3rd party app is doing. By that, I mean figure out what queries the 3rd party application is using. If it were me, I'd install Wireshark on the application server to sniff the LDAP traffic and go from there.
ASKER
I am launching Softerra using a 'run as' to speciify the same credentials that the 3rd party server is using.
I have looked at the ADSIEdit properties of all 4 of the accounts versus 'working' accounts and there is nothing odd about them. No special characters, extra spaces or anything... Every attribute falls in line with working accounts.
I will try the Wireshark app and see what that produces.
Thanks for the tips - keep them coming! I know this ultimately has to be a simple fix. The 3rd party app (Openfire IM chat 3.6.3) support state that they think the AD accounts are corrupt. I personally disagree with them. I will also try to determine the LDAP query that Openfire is using to query the users from AD.
I have looked at the ADSIEdit properties of all 4 of the accounts versus 'working' accounts and there is nothing odd about them. No special characters, extra spaces or anything... Every attribute falls in line with working accounts.
I will try the Wireshark app and see what that produces.
Thanks for the tips - keep them coming! I know this ultimately has to be a simple fix. The 3rd party app (Openfire IM chat 3.6.3) support state that they think the AD accounts are corrupt. I personally disagree with them. I will also try to determine the LDAP query that Openfire is using to query the users from AD.
Aww...Openfire. You may not need Wireshark.
Look at conf\openfire.xml. Set ldapDebugEnabled to "true" and then enable debugging in the admin console. Also, what is your searchFilter string?
Look at conf\openfire.xml. Set ldapDebugEnabled to "true" and then enable debugging in the admin console. Also, what is your searchFilter string?
ASKER
searchFilter string? Not sure where to get that information from... Sorry.
Check you openfire.xml file.
ASKER
Openfire configuration is no longer stored in the Openfire.xml file. It is located in the DB. Let me work to get that info now.
Here is a link where one of the experts state that the openfire.xml file is no longer used for the config...
http://www.igniterealtime.org/community/message/182214#182214
Here is a link where one of the experts state that the openfire.xml file is no longer used for the config...
http://www.igniterealtime.org/community/message/182214#182214
ASKER
okay - here is the search configuration info
ldap.groupSearchFilter (objectClass=group)
ldap.searchFilter (objectClass=organizationa
plugin.search.excludedFiel
plugin.search.serviceEnabl
plugin.search.serviceName search
ldap.groupSearchFilter (objectClass=group)
ldap.searchFilter (objectClass=organizationa
plugin.search.excludedFiel
plugin.search.serviceEnabl
plugin.search.serviceName search
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
For what it's worth, I've supplied my searchFilter below. You will notice that I'm checking for objectCategory and not objectClass. I'm not sure why that would matter.
(&(objectCategory=Person)(memberOf=CN=JabberAccess,OU=Security Groups,OU=Groups,DC=example,DC=com))
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
When using (objectClass=organizationa
I am completely lost as to why they do not appear in Openfire. here is another bit of interesting info - If I change the port to 389 the 4 users are found in Openfire (of course only the users in the specified child domain appear as well). But when I change it to 3268, the rest of the organization users appear except those 4.
I will change the query to (objectCategory=user) tomorrow on port 3268 and report the results
I am completely lost as to why they do not appear in Openfire. here is another bit of interesting info - If I change the port to 389 the 4 users are found in Openfire (of course only the users in the specified child domain appear as well). But when I change it to 3268, the rest of the organization users appear except those 4.
I will change the query to (objectCategory=user) tomorrow on port 3268 and report the results
ASKER
Okay - I have edited the search to (&(objectCategory=person)(
Can I use (objectclass=*) to attempt and pull everything in AD?
Can I use (objectclass=*) to attempt and pull everything in AD?
You could use that but not sure why you would want to
Just for another test download adfind
http://www.joeware.net/fre
run
adfind -gcb -f "samaccountname=<username of one of the 4>"
Do they return in that command?
Thanks
Mike
Just for another test download adfind
http://www.joeware.net/fre
run
adfind -gcb -f "samaccountname=<username of one of the 4>"
Do they return in that command?
Thanks
Mike
ASKER
I will test and post findings on Monday.
Thanks mkline71 and moorereason for following up on this thread. Hopefully I (we) will get to the bottom of this soon.
Thanks mkline71 and moorereason for following up on this thread. Hopefully I (we) will get to the bottom of this soon.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Good work, this will help others when they run into this issue in the future.