Service Accounts: Active Directory Permissions Issues: Part #4 Conclusion

Published on Friday, May 18, 2012 in ,

In the last three posts:

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:

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

Related Posts

7 Response to Service Accounts: Active Directory Permissions Issues: Part #4 Conclusion

05 July, 2012 16:26

Thank you! So so much! I finaly got this fixed in my ADFS servers!

28 July, 2012 01:17

thanks for the thumbs up!

09 May, 2013 20:31

Thanks ! , the second time you got me out of a jam !

12 May, 2013 17:21

Thanks for taking the time to past back!

27 September, 2013 18:18

Thank you so much! We had error log files over 50GBs because of this. Simple fix once you find the right solution.

18 December, 2013 02:28

I was upgrading from AX 2012 CU6 to CU7 and all of a sudden, the .Net business connector proxy account was no longer recognized as a valid domain account. I was left scratching my head until I came across this post. Appreciate it! Thanks

30 April, 2015 05:47

I have same issue as Part#3. Again no visible functional impact but just the warning events.
But in my case we have ADFS service account in other forest (with one way trust) and option for providing that ADFS service account with "Read Permission" for "Authenticated Users" won't work and even not politically possible. Any solutions?

Add Your Comment