I am attempting to use ldapsearch to troubleshoot why I am having some odd issues with users.
I can run the following query and find a user that is in AD:
ldapsearch -h <my_host> -p 389 -x -b "cn=users,dc=domain,dc=name" -s sub "name=test 01"
This returns with information for the user as I would expect. If I run the same command but switch test01 to test02, I get "result:32 No such object".
I have gone into AD and I see that the user is in the same structure/folder as the other user. They have the same exact permissions. I opened both users side by side in ADSI Edit and I see the "name" attribute is correct. I disabled and reenabled the user. I even combed line by line in ADSI Edit between a working user and the one that is not working and they appear identical. I have tried to search on other attributes such as sAMAAccountName and it still fails for this individual user. I have ensured I am using the admin account with adsi and there is no difference in the structure of where the user lives
This user was working correctly until fairly recently. The only thing I have been able to find is by using ldapsearch and it failing to find the object (as everything I have searched in AD looked correct). If I run an entire search (without the -s option), I see that it finds:
# test 02, Users, domain.name
dn: CN=test 02, CN=Users,DC=domain,DC=name
but nothing else for the user attributes. The other users I see have objectclasses that return and all of the other attributes that I see in ADSI Edit underneath their entry. I have seen this happen with a couple accounts over the past few months and the only workaround I have is to simply create a new account for the user...Obviously a bad workaround.
Am I missing something obvious or what could be happening?
On the security tab of the accounts that do not return data, see if there are any "DENY" access control entries. Deny takes precedence, so a one-off deny can prevent information from being displayed where there is an allow entry at a higher level.
Check if inheritance is enabled. There are cases where this is programmatically disabled -- domain admins -- and you need to modify the permission set on AdminSDHolder to enact permission changes on the managed objects. If inheritance is disabled but the accounts are not admins where AdminSDHolder applies, add the anonymous read permission to the object (your post indicates that you want anonymous read to user objects). Or risk enabling inheritance.
If all else fails, use "Advanced" on the "Security" tab and select the "Effective Access" tab. Click to select a user and enter "Anonymous". Accept. Then click "View effective access". Compare anonymous' effective access to both a working and non-working account.