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

And yep, there’s more instances of this phenomena! I also came across the following when install an Active Directory Federation Services farm which uses SQL to store its configuration. Whilst there was not noticeable impact (yet), I saw the SQL loggings being filled with the following warnings:

In words: The activated proc '[IdentityServerPolicy].[SqlQueryNotificationStoredProcedure-616f6b36-c503-4503-a6cd-7e067a1b9e43]' running on queue 'AdfsConfiguration.IdentityServerPolicy.SqlQueryNotificationService-616f6b36-c503-4503-a6cd-7e067a1b9e43' output the following:  'Could not obtain information about Windows NT group/user '***\s_****_adfs', error code 0x5.'

And a slightly other one:

In words: An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user '***\s_****_adfs', error code 0x5.

Error: 28005, Severity: 16, State: 2.

The solution: is to give the “Authenticated Users”  “Read Permissions” on the ADFS service account. An easy way to test this solution is executing the following query:

The query xp_logininfo ‘Domain\service account’ will return something like this if things go well:

Or like this if the SQL Server service lacks the mentioned permissions:

If you’re interested in a more definite solution which does not involve modifying the security of all your service accounts, make sure to read Service Accounts: Active Directory Permissions Issues: Part #4 Conclusion.

The solution “grant Authenticated Users Read permissions on the involved service accounts” can also be applied during installations of Dynamics Ax 2012. In fact it’s twofold. We came across two instances of this problem. When installing the bits for the Enterprise Portal extensions there’s an option to prepare SharePoint for the deployment of the Ax 2012 Portal. This setup failed with the error “The given key was not present in the dictionary.” This obviously sounds very much like my post in Service Accounts: Active Directory Permissions Issue Part #1. And indeed this change allowed to setup to end gracefully.

But we also came across an other issue which does not seems so related at first sight. When trying to configure the Business Connector Proxy account in the Ax console we received the following error when clicking ok:

In words: Infolog (1). One or more critical STOP errors have occurred. Use the error messages below to guide you or call your administrator. The alias/network domain entered for the Business Connector proxy is not valid.

I don’t know why, but somehow this felt like the same issue as before. And indeed. Granting the “Authenticated Users” “Read” access on the BCP account allowed us to configure it as the BCP user.

If you’re interested in a more definite solution which does not involve modifying the security of all your service accounts, make sure to read Service Accounts: Active Directory Permissions Issues: Part #4 Conclusion.

Currently I’m involved in a project where we are setting up a lot of Windows technologies, just to name a few: Dynamics Ax 2012, BizTalk, SharePoint 2010, FIM 2010 and thus SharePoint Foundation 2010. It seems some legacy thingy in the Active Directory is biting us in the ass, so for both SharePoint (Full blown and Foundation) and Dynamics Ax we’ve had to modify the permissions on the service accounts used by those products.

So here’s the first occurrence I came across. It happened when I was running the initial configuration wizard of SharePoint Foundation 2010. This SharePoint instance will host the FIM 2010 R2 Portal in the near future. This wizard is to be executed after installing the bits & bytes of SharePoint 2010.

What it says in words: Failed to create the configuration database. An exception of type System.Collections.Generic.KeyNotFoundException was thrown. Additional exception information: The given key was not present in the dictionary.

One thing to look into would be the permissions on the SQL server instance. All in vain. In the end I fired up google and came across numerous posts like these:

• “The given key was not present in the dictionary” issue in Sharepoint 2010 RTM
• The given key was not present in the dictionary Error When Validating User Accounts

The solution is pretty simple to implement, but I’m still struggling whether there’s a “nicer” way which does not involve touchy every service account or the OU in which they reside. Using Active Directory and Computers, or the new Active Directory Administrative Center, we can modify the permissions on the involved service accounts. The ones involved or the ones which are being used by SharePoint: to run various service, application pools or the farm admin. In order to view the security tab on a given user you might have to enable the advanced features in the view option of the ADUC MMC.

Once you got your service account open, just check “Allow Read” for “Authenticated users”.

This exact same error also popped up when registering a new Managed Service Account within the Central Administration site:

If you’re interested in a more definite solution which does not involve modifying the security of all your service accounts, make sure to read Service Accounts: Active Directory Permissions Issues: Part #4 Conclusion.

A colleague of mine today learned me this neat shortcut: typing windows key + x on the Windows 8 Consumer Preview gets you a small menu with a lot of frequently used mmc’s. See for your self:

I especially like the “Command Prompt (Admin)” and “Network Connections” options. I’ve been using “ncpa.cpl” as a shortcut for network connections every since I started working with Windows 2008. But this might even be faster/easier.