AD FS 329: The certificate that is identified by thumbprint ‘<thumbprint>’ could not be decrypted using the keys for X.509 certificate private key sharing

Scenario

The Active Directory Federation Services (AD FS) 2.x service ADFSSRV will not start.  Event ID 329 is logged in the AD FS 2.0/Admin event log.  The pertinent text from event 329 is as follows:

Description:
The certificate that is identified by thumbprint ‘041EB761382E43FF4232B1926DBA4FB4D62A2D86’ could not be decrypted using the keys for X.509 certificate private key sharing.

Additional Data:
X.509 certificate private key sharing diagnosis: MSIS7707: The container for X.509 certificate private key sharing with the distinguished name ‘CN=ADFS, CN=Microsoft, CN=Program Data, DC=domain-name, DC=com’ does not exist.

User Action
You may have to restore all Active Directory objects underneath the specified distinguished name in the diagnostic information above for X.509 certificate private key sharing.

Issue

When the AD FS service starts it looks for the certificate sharing objects underneath the ADFS container inside the Program Data/Microsoft container of the default domain.  The default domain is the domain that the service account is a member of.

The certificate sharing objects are created when you create the first node in the AD FS farm.  The FSCONFIG application retrieves the Program Data container from the default domain and creates the Microsoft/ADFS containers and the subsequent certificate sharing container and contact objects.  The default domain is the domain of the user performing the configuration, i.e. the user context running FSCONFIG.

The reason the service account cannot find the necessary container is because the service account is in a different domain to the account that created the farm and as such the certificate sharing information has been created in a different domain.

Note.

There are potentially different causes, such as accidental deletion of the container, accidental permissions change of the container, etc. however I have now seen this exact issue due to the service account and installation account residing in different domains in two customer environments and have reproduced in the lab, ergo this post.

Resolution

Uninstall AD FS, reinstall and run the farm configuration using an account (that is a member of domain admins, or has the necessary delegated permissions on the domain/Program Data/Microsoft container) in the same domain as the service account.  For example, if you have a root domain and three child domains with a relatively even distribution of users in the child domains you are likely installing AD FS on member servers in the root domain.  In this scenario ensure that the service account is in the root domain and that the user installing AD FS and/or performing the initial configuration is in the root domain.

Unfortunately I have not yet identified a supported way of remedying this issue without uninstalling and reinstalling.  Although that sounds like a massive endeavour it really isn’t if you have this issue for the reason described above, i.e. you have just installed and created your first FS farm node incorrectly.

If the farm was up and running and now you have this issue you have likely actually lost the container and/or contact objects and that requires a different fix, i.e. recovery from backup (authoritative restore).

Advertisements

About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in AD FS, Troubleshooting and tagged , , , , , . Bookmark the permalink.

8 Responses to AD FS 329: The certificate that is identified by thumbprint ‘<thumbprint>’ could not be decrypted using the keys for X.509 certificate private key sharing

  1. Chris R says:

    Paul,

    What if we have a root domain with multiple child domains, and the users and computers are all on a specific child domain? Is there a way to install ADFS to the child domain, as that is where the servers, users, and computers are? I have noticed that the program data->microsoft ou’s are not on the child domain…
    Thanks

    • Yes, be sure that the account performing the installation is a member of the domain that you are installing into, e.g. if your users are in child.contoso.com and you want AD FS in that domain install AD FS using an administrative account in child.contoso.com and also make sure that the AD FS service account is a member of the same domain.

      You’ll probably find the account in some other domain, this is the issue I’ve seen with three customers now – AD FS has been going in the root but they’re using their admin account from the child (or vice versa).

      • Chris R says:

        That’s where I’m running into an issue. The srevice accont is a member of the child domain, however the only way I could get ADFS to configure was by using my enterprise admin account that is on the root domain. My domain admin account on the child domain wouldn’t let me do it, and the errors I got pointed at the inability to write to the root->program data->microsoft folder in AD….. Even granting my child domian admin account permissions didn’t allow it.

      • Interesting. I don’t have a multi-domain forest handy now and am travelling so can’t knock one up. In my customer environments membership in Domain Admins in the child domain was sufficient. If that isn’t sufficient for you perhaps you have non-standard permissions on the Program Data container?

      • Chris R says:

        Paul,
        Our program data container had default permissions, with some others added as well. I had even granted the service account (and my domain admin account for the child domain) full access to it and its sub-ous. Still no go. I ended up having to use my enterprise admin account to get it to work.

  2. Rob says:

    Paul, can you please explain why the Certificate Sharing Container is necessary in the first place? I have an ADFS 2.0 farm using SQL Server and have no Certificate Sharing Container in AD. Everything seems to work just fine without it. No errors about it anywhere. All the certificates used by my ADFS servers have been created using my own ADCS. I can’t find any good information about this on the web. TechNet has a note that says: “AD FS 2.0 does not share private keys in a federation server farm for administrator-specified certificates, such as certificates that a certification authority (CA) issues”. Does this mean the the Certificate Sharing Container is only necessary when self-signed certificated are used by ADFS?

    • There’s not much info. out there on the certificate sharing container is there? I don’t have as much info. on this topic as I would like. It is my understanding that it is used only when AutoCertificateRollover is enabled, i.e. when AD FS generates self-signed token signing/encryption and decryption certificates automatically.

      I will try and do some more digging and come back with more info. or if the information warrants it, come back with a follow-up post.

  3. Pingback: The use of Distributed Key Manager (DKM) in Active Directory Federation Services (AD FS) | Yet another identity management blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s