Something that crops up quite a lot when you’re involved in planning and designing an Active Directory Federation Services (AD FS) infrastructure is certificates and, for those of you who have worked anywhere where you have to justify your design to various control and governance authorities (think banks, government and defence for sure), what the certificates do and how they are controlled and protected. Many people take for granted that an AD FS farm shares a set of common certificates. Some have wondered how AD FS shares the private keys for the signing and encryption certificates. Others have wondered why is there a bunch of containers with some blobs in some of the attributes created and maintained in the Active Directory Domain Services (AD DS) domain.
Well, hopefully I can explain this.
The token signing and token decryption certificates, including the corresponding private keys, are stored in the AD FS configuration database. The certificates are encrypted using a technology called Distributed Key Manager (DKM). AD FS creates and uses these DKM keys as and when needed, which basically means when you initialise the farm and when a key expires.
During the initial configuration of an AD FS farm the FS farm creation process creates a dedicated container in the on-premises AD DS domain of the account installing AD FS (which should be in the same domain as the service account for AD FS otherwise the service account can’t locate the container and will fail to start) to store a master encryption key using the aforementioned DKM solution (a more detailed explanation of the cryptography aspects of DKM can be found here). This container is permissioned such that only the FS service account can read the key.
When a new certificate requires creation (either initially, during setup, or in an automatic roll over scenario), one of the nodes is elected to perform the following task:
- The server generates the certificate and stores it in the service account’s certificate store (the MY store for the service account)
- The certificate (the .PFX structure) is serialised; encrypted with the master key generated during farm initialisation, using DKM client APIs; and stored in the configuration database
When the AD FS service starts on one of the nodes the following happens:
- The server decrypts the table that contains all encrypted certificate information using the DKM client API
- The deserialised certificate is then stored in the service account’s certificate store on the local server
Lastly, the encryption key used by DKM, stored in AD DS, expires after a year. AD FS manages the creation of a new key – AD FS uses a valid DKM key to encrypt the PFX to store in it’s configuration database; if a valid DKM key is not present, AD FS creates a new one.
So, in summary:
- The token signing and decryption certificates are stored as PFX blobs in the AD FS configuration database
- The table that houses the blobs is encrypted using a technology called Distributed Key Manager (DKM) and the DKM master key(s) are stored AD DS
- The DKM master keys are created when required, i.e. during farm initialisation and when they expire
- AD FS servers retrieve the DKM master key from AD DS and use this to decrypt the encrypted table in the AD FS configuration database; the decrypted PFX is installed into the MY store of the AD FS service account
- Only the AD FS service account has permissions to read the key material stored in AD DS and only the AD FS service account has permissions to read certificates in its MY store by default
- All federation service servers in the AD FS farm share the same token signing and decryption certificates
I hope you find this useful. Special thanks to Ramiro Calderon for his assistance in making sense of this process.