Windows – Read access to Active Directory property (uSNChanged)

active-directorywindows

I have an issue with read access to the uSNChanged property when doing LDAP searches.

If I do an LDAP search with a user that is a member of the Domain Admins group (UserA), I can see the uSNChanged property for every user.

The problem is that if I do an LDAP search with a user (UserB) that is not a member of the Domain Admins group, I can see the uSNChanged property for some users (UserGroupA) and not for some users (UserGroupB).

When I look at the users in UserGroupA and compare them to the users in UserGroupB, I see a crucial difference in the "Security" tab. The users in UserGroupA have the "Include inheritable permissions from this object's parent" unchecked. The users in UserGroupB have that option checked.

I also noticed that the users in UserGroupA are users that were created earlier. The users in UserGroupB are users created recently. It's difficult to quantify, but I estimate the border between creation time between the users in UserGroupA and UserGroupB is about 6 months ago.

What can cause the user creation to default to having that security property checked as opposed to unchecked? A while back (maybe around 6 months ago?) I changed the domain functional level from Windows Server 2003 to Windows Server 2008 R2. Would that have had this effect? (I can't exactly downgrade the domain functional level to test it out.)

Is this security property actually the cause of the issue with read access to the uSNChanged property on LDAP searches? It seems correlated, but I'm not sure about causation.

What I want in the end is for all authenticated users to have read access to the uSNChanged property for all users when doing an LDAP search. I would also be OK if I could grant read access for that property to an AD group. Then I can control access by adding members to the group.

Best Answer

I can't figure out how to comment on Craig620's answer, but he offered some good info. Something that strikes me as odd is that you are unable to read uSNChanged, which should still be readable by Authenticated Users and the Pre-Windows 2000 Compatible Access group (which by default contains Authenticated Users). Those groups by default are stamped by AdminSdHolder with "Read all properties" on protected objects.

Although it appears to be the opposite of your situation, I ran into the opposite issue in an environment I managed where, unbeknownst to me, Authenticated Users had been removed from Pre-Windows 2000 Compatible Access. This had the effect of removing most users' ability to read most properties on accounts not protected by AdminSdHolder, but they WERE able to read those properties on AdminSdHolder-protected accounts. Just to be safe though, you should probably check the membership of Pre-Windows 2000 Compatible Access.

You may also want to check the default ACL for newly created users in the forest. Rather than reinvent the wheel, take a look at http://www.windowsitpro.com/article/security/defining-an-ad-object-s-default-security-descriptor and check the User class default ACL. That is what determines a newly created user's permissions.

Either way, take a look and compare the ACLs on "readable" and "nonreadable" objects looking for ACEs that one has that the other doesn't.

Related Solutions

Ldap – SquidGuard and Active Directory groups

Solved.

Assuming the following:

- Domain name: "domain.com"
- Group name: "Internet Users"
- User name: "UserName"
- Path to group: "domain.com\OU1\OU2\Internet Users"

The query for checking if the user is member of that group would be:

(&(memberOf=CN=Group Name,OU=OU2,OU=OU1,DC=domain,DC=com)(SAMAccountName=UserName))

So you would have to add the following to squidGuard.conf to identify the members of that group ("%s" is squidGuard.conf's placeholder for "the client's user name"):

src Internet_Users {
    ldapusersearch  ldap://dc.domain.com/DC=domain,DC=com?sAMAccountName?sub?(&(sAMAccountName=%s)(memberOf=CN=Internet Users,OU=OU2,OU=OU1,DC=domain,DC=com))
}

Caveat: it will not work if written as above, giving you a laconic "syntax error" message; this is because (part of) the statement is treated like a URL, so you have to escape special characters such as commas and whitespaces; the correct form would thus be this one:

src Internet_Users {
    ldapusersearch  ldap://dc.domain.com/DC=domain,DC=com?sAMAccountName?sub?(&(sAMAccountName=%s)(memberOf=CN=Internet%20Users%2cOU=OU2%2cOU=OU1%2cDC=domain%2cDC=com))
}

Also, in order to avoid problems with Active Directory referrals (sometimes a DC will just redirect you to another one, even if you are on the same domain it manages), it might be useful to query a global catalog:

src Internet_Users {
    ldapusersearch  ldap://gc.domain.com:3268/DC=domain,DC=com?sAMAccountName?sub?(&(sAMAccountName=%s)(memberOf=CN=Internet%20Users%2cOU=OU2%2cOU=OU1%2cDC=domain%2cDC=com))
}

Domain Admin Group User Cannot Access Directory – Permission Fix

This is by design. UAC strips the admin credential from any un-elevated process. If you're attempting to use an un-elevated process to access a remote share using only admin credentials, UAC will strip the admin credentials from the process' security token and the process will receive an "access denied" error.

To remedy this you can:

Don't use admin credentials to secure the folder (create a generic group just for this purpose), or
Disable UAC on the fileserver (not recommended), or
Enable the following registry key on the fileserver to disable just this portion of UAC.

More info: Description of User Account Control and remote restrictions in Windows Vista

Best Answer

Related Solutions

Ldap – SquidGuard and Active Directory groups

Domain Admin Group User Cannot Access Directory – Permission Fix

Related Topic