The given key was not present in the dictionary Error When Validating User Accounts

This is a problem that I’ve seen come up a few times now, with a particularly nasty side effect for sites using SAML claims with ADFS.  Where I first saw this problem was when I created a new farm and I went into add a service account.  I typed in the alias for the account and clicked resolve, which it seemed to do okay.  Then when I tried saving the new managed account, it failed and gave me an error along the lines of key not found in dictionary.  This one drove me nuts for a while before I figured out a solution.  What I needed to do to get past that error was:

  1. Go into Active Directory Users and Computers snap-in
  2. Click View…Advanced Features on the menu
  3. Find my service account in the directory
  4. Right-click on it and select Properties from the menu
  5. Click on the Security tab
  6. Click on Authenticated Users in the top part of the dialog
  7. Check the Read box in the Allow column
  8. Click the OK button to save the changes

After doing that, I could successfully create my new managed account.  There are a couple of other things to note:

  • My current domain functional level is Windows Server 2003
  • The error ONLY occurs when the application server is Windows Server 2008 R2; the original Windows Server 2008 does not have this problem

Okay, so while that is a little unpleasant, I don’t have so many managed accounts that I can’t work around it.  Until, possibly, today.  Here’s where I discovered this little bugger again.  This time, I was trying to log into a claims auth site as some random user.  ADFS v2 is the STS I’m connected to, and it is using Windows auth over there, then grabs some attributes from the user to do some claims processing.  I found when I tried to log in that it failed on the ADFS server, and gave me an error like this:  An error occurred during processing of the request.  MSIS7012: The request failed.  Contact your administrator for details.  Additional data:  some guid.  Hmm…so what was that all about?

Next I looked on the ADFS server and found these two entries in the application event log:

  1. The Federation Service encountered an error while processing the WS-Trust request, then an object reference not set to an instance of an object error further down in the stack (i.e. a NullReferenceException).
  2. An error occurred during federation passive sign-out.

The NullReferenceException for some reason made me think hmm, I wonder if it can’t read the user object from the directory?  So I went in and changed the properties for the user in the AD Users and Computers snap-in as I described above.  After that – boom! – everything works great; the user can now log in.

For now, unfortunately, I can only offer this as a warning.  I don’t completely understand why the error is happening or why it only happens when the application server is Windows Server 2008 R2.  If/when I get more information on it or on possible fixes I’ll try and update this or post something new.

Comments (6)

  1. Anonymous says:

    I also saw this error recently. I was using a custom SAML post to ADFS and my form had the element "SamlResponse" rather than "SAMLResponse". I looked in Reflector for the ADFS server code and it actually had "SAMLResponse" hard coded like this. I am guessing this must be based on a SAML spec that it be in all caps. I was able to change the form element to have all caps for SAML and it solved it.

    If you get this error I would get the stack trace from the error and open Reflector on the Microsoft.IdentityServer.dll and try to figure out where the dictionary error occurs.

  2. alexandrad9x says:

  3. Anonymous says:

    Any word on this?

    This also happens in my native mode Windows 2008 R2 domain where all the servers are Windows 2008 R2. I was performing the "Configure Service Account" procedure when I ran into this problem.

  4. Tristan Watkins says:

    Was getting nowhere until I found this. NetMon suggested NetBIOS queries for the DCs were returning no results, although I could only get this result via SharePoint. Also thought it could be to do with Windows 200 Native Domain Functional Level somehow. Any more thoughts on this one?

  5. Arthur Dent says:

    The error "key not present in the dictionary" is a very generic error.  For those of you familiar with the oh-so-popular "general protection fault" errors, you will understand what I mean.  This error is worthless within the construct of setting up ADFS and you will not find an answer in any knowledge base that will help.

    The error has nothing to do with rights, database or any other dark rat hole they will lead you down.  There are a couple of factors that will cause the error.

    1. The ADFS server cannot use the FQDN of the ADFS server.  You will need to use KERBEROS authenticate and when you run setspn using the FQDN of the server, you will get an error stating the server computer account  is not trusted.  Use a certificate that is associated with a CNAME (alias) for the ADFS server (ex. ADFS2.domain.local is the CNAME for server1.domain.local)

    When you setup your ADFS server, you will need to run setspn -a host/[CNAME of the ADFS server] [domain][service account] in order to establish kerberos authentication.  Also, you will notice that if you fail to do this, you can only access the federationmetadata.xml file using the NETBIOS name of the ADFS URL.  setspn fixes that issue.

    2. Certificate trust is key.  You will need to export your certificates from both the ADFS IIS interface and the SharePoint 2007 server as x509 certs and import them as trusted root certificates onto the SP 2007 and ADFS server.

    Perform all imports using the MMC Certificate snap-in in order to ensure the trusted root certificate is added

    3. You will need to extend your SharePoint web application to create an INTRANET or EXTRANET application using SSL.  Simply adding alternate access mappings will not help.  Create or Extend a Web Application is performed through the SharePoint Central Admin Console.

    You will need to change your bindings on the default SharePoint-80 site to not use 443 for SSL and if you want to use port 80 on the SharePoint 80 application, set the HTTP port on your new INTRANET web application to another port.

    I hope this clarifies some of the causes of the "key not present" error when running the Federation Utility for SharePoint 2007.

  6. SDF says: