In the last three posts:

• Service Accounts: Active Directory Permissions Issues: Part #1 SharePoint
• Service Accounts: Active Directory Permissions Issues: Part #2 Dynamics Ax 2012
• Service Accounts: Active Directory Permissions Issues: Part #3 SQL 2008 R2

I came to the conclusion that given Authenticated Users Read permissions seems to solve some issues. However providing the “full read” permission might be a bit blunt. I was wondering what property is there that the default permissions don’t cover….

I didn’t see the link at first, but suddenly all puzzle pieces fell together. When trying to find a solution for Part 3 of my AD Service Account Permissions Issues I came across these posts which provide an alternative solution:

• Issues with SQL Server in a Windows 2008 Domain
• Windows 2008 and xp_logininfo

They say to add the service account, which requires a higher level of read access on the involved service accounts, to the built-in group “Windows Authorization Access Group”.

When this group hasn’t been moved you can find it in the Builtin container:

And the group we are discussing:

Now how does this help with our case? When adding users to this group they are granted read access to the tokenGroupsGlobalAndUniversal attribute on all users. And this seems to be the exact permission we were looking after! Instead of granting Authenticated Users Read, it would be sufficient to grant them Read to the tokenGroupsGlobalAndUniversal attribute. But then again, that would be a lot of work compared to just adding them to the built-in group.

After some more research the “Pre-Windows 2000 Compatible Access” seems also tightly coupled to this permissions related stuff. My guess is that choices in the past (during the DCpromo) and manual modifications to either of this groups might determine whether or not you are seeing these kind of issues. Here are the members of these groups after a Windows 2008 R2 being DC Promo-ed into a new domain.

• Pre-Windows 2000 Compatible Access: only Authenticated Users are member
• Windows Authorization Access Group: only Enterprise Domain Controllers are member

In my domain neither of these groups had the “Authenticated Users” in them. So that’s why adding the service accounts made sense. It would by my guess that the far easiest workaround would be to add the authenticated users to the pre-windows 2000 compatible access group. After all in a new 2008 R2 domain this is done for you so this would mimic a standard installed domain based on 2008 R2 media. So I would conclude that this isn’t against best practices or that no security holes are being created. Do you agree?

Some more technical background regarding this attribute: KB331951: Some applications and APIs require access to authorization information on account objects