One of my colleagues was having troubles accessing an HTTPS site. The site is secured with a certificate coming from an Active Directory Certificate Authority. Now I know of a bug where if you have a pinned website on your taskbar, and from that browser instance you open an HTTPS site with an untrusted certificate, there’s no "continue anyway” button…

Now this wasn’t the case today. He had the “continue anyway” option, where you typically click on, load the site and check the certificate. However, after clicking, it didn’t go trough, it just remained at the same page. We installed the root CA manually in the trusted root authorities, but still no improvements. When verifying the root certificate in the MMC we also saw it mentioned that the digital signature was invalid.. odd!

Using that as a query for google we quickly came across this:

• RSA keys under 1024 bits are blocked
• Blocking RSA Keys less than 1024 bits (part 2)
• How to identify if your ADCS has issued any certificates with public keys <1024 bits (in preparation for KB2661254)

If you read those first two carefully you’ll see the update will be released as a critical non-security update on august 14th for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

An example of a bad certificate:

Now how come he was having this issue now already?! Ahah, now comes the clue! He was using Windows 8! Now I am too, and I’m not having that problem with that specific site, but here’s the difference:

• Windows 8 with issue: Windows 8 Release Preview: build 8400
• Windows 8 without issue: Windows 8 Consumer Preview: build 8250

So it seems they’ve included this update somewhere in the build process of Windows 8.

Having certificates with an RSA key < 1024 is probably not really the case for most of us, but be sure to double check those certificates and their (intermediate) roots! Especially for those customer facing sites where you can’t control what updates hit the clients and thus potentially might be denied access to your sites.

I was assisting a colleague which was installing the Ax 2010 Enterprise Portal on a SharePoint Farm. The farm consisted of 2 servers hosting the SharePoint web applications (the actual sites), and 2 servers hosting the central admin and application services roles. We wanted to start with installing the Enterprise Portal bits on both web front servers without actually choosing the “create site” option in the installer. This would just prep the server and then we’d finalize it by running the “create site” option on the central admin server.

Here’s the screenshot where we selected the Enterprise Portal (and some other prereqs for the Portal):

Some steps further we were supposed to get a dropdown with an overview of all sites hosted by SharePoint. Although SharePoint was installed, and we had multiple sites created, we were greeted with an error stating “Microsoft SharePoint 2010 is not installed or running. Please run the prerequisite utility for more information. Operation is not valid due to the current state of the object.”

Going back and clicking next again doesn’t really solve the problem. Going to the installer log file (which is located in \Program Files\Microsoft Dynamics AX\60\Setup Logs\[Date]) showed us that the installer seemed to query the local IIS configuration just fine. As far as I could tell no actually error was given, but it started processing shortly after trying to get information regarding the first actual SharePoint site.

After staring a bit at the log my eye fell on the “GetFirstHostHeaderOfWebSite” method. It seemed to have ran fine for the default website, but it wasn’t executed for the first actual SharePoint site. And it rang a bell as we have customized this a bit. We had in fact 3 host headers for each SharePoint site. One for the virtual name, one for the virtual name but dedicated to the node and one which was just blank with the IP. I know the last one more or less make the others unnecessary, but we added that one later on when we figured our hardware load balancer status probing wasn’t playing nice with the host headers.

Long story short, after modifying ALL sites found in the IIS configuration so that thed have one or no host headers, the setup was able to enumerate the potential sites to configure the AX Enterprise Portal for just fine. Bit weird and seems like a bug in the installer to me…

Recently some colleagues of me logged a case because a GPO which worked fine before didn’t seem to work anymore. In the GPO the security of c: was redefined. In the end the root cause of that problem was McAfee. Whilst troubleshooting with Microsoft, in one of the generated log files we noticed SYSVOL mismatch errors.

When troubleshooting GPO’s often an utility called GPOtool.exe is used. This tool is available in the Windows 2003 resource kit tools. Since that tool I’ve never seen a newer version been released. I always assumed it just worked with Windows 2008 or 2008 R2 Domain Controllers. So when we got the following errors, we assumed we had a problem with some of our GPO’s:

In words: Error: sysvol mismatch. At first sight the version in the output seem identical. Also when verifying using ADSIedit, the GPO Management Console & in the SYSVOL share, all GPO related versions seemed to be correct. One thing we noticed though, only GPO’s which were exported and imported in a newer GPO seemed to be mentioned. Although I see no reason for that to cause versioning issues. After some googling I came across this: http://kb.elmahdy.net/2011/02/gpotool-for-windows-server-2008-r2.html

So it seems Microsoft (internally) has a more recent build of GPOtool.exe which plays nicer with Windows 2008 R2 domain controllers. I am by no means responsible for the tool provided on that blog, but I tested it in my environment and it worked fine. The exe seems to be signed by Microsoft, so I would assume it’s safe. To conclude the correct output:

And some GPOtool.exe version information (gpotool1 is the old one):

P.S. It is to my understanding that the Windows Server 2012 will have a GPMC which has enhanced capabilities regarding the GPO health. Way to go!

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.