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).
