Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2013-05-14) ADFS Managed Certificates Supporting Auto Certificate Rollover

Posted by Jorge on 2013-05-14


In the following blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x I wrote about the certificates used by ADFS v2.x. In summary, you can use CA issued certificates for all certificates required by ADFS or you can use ADFS managed self-signed certificates for both the Token Signing Certificate and the Token Decryption Certificate. When automated certificate rollover has been enabled, ADFS managed self-signed certificates for both the Token Signing Certificate and the Token Decryption Certificate will be used!

Let’s first have a look at the characteristics self-signed certificates in general. It is considered a bad practice to use self-signed certificates because by default those certificates are not trusted by any entity. Self-signed certificates do not leverage CRLs and cannot be revoked, only replaced. And to my knowledge you cannot store its private key in an HSM. However, in the case of ADFS, the valid usage of a self-signed certificate, and also CA Issued Certificates, (for both the Token Signing Certificate at the IdP STS and the Token Decryption Certificate at the SP STS/App) is determined by the existence of the certificate, its configuration as the certificate for a specific purpose and the publication of such in the federation metadata. Something to be aware of is that other parties, such as both STS’es and applications, still must become aware of the information available in the federation metadata, either manually or automatically.

The usage of ADFS managed self-signed certificates lowers the management overhead that comes with the usage of certificates in common. ADFS managed self-signed certificates, and their corresponding private keys are not stored on individual servers, but rather in the ADFS configuration database. In the context of security, all ADFS STS servers and all servers hosting the ADFS configuration database should be secured, physically and logically, in at least the same way as securing RWDCs. Access to these servers should ONLY be allowed to highly skilled knowledgeable and authorized people that understand the working of ADFS. Why? Let’s do a comparison!

In a Windows world, resources are secured through Windows Security Groups. To gain access to those resources you must be a member of the corresponding Windows Security Groups and the DC must hand out an Access Token that contains those Windows Security Groups. If the RWDC has been compromised, the person that compromised the RWDC will also have access to any resource secured by Windows Security Groups because it will be able to generate Access Tokens with any required Windows Security Groups.

In a Claims Based Authorization world, resources are secured through specific Claims. To gain access to those resources you must be able to provide the corresponding Claims and the ADFS STS must hand out a Security Token that contains those Claims. If the ADFS STS has been compromised, the person that compromised the ADFS STS will also have access to any resource secured by Claims because it will be able to generate Security Tokens with any required Claims.

To be able to test this all, I have changed the default values to lower values as shown below. Later on I will explain each and every property.

image

Figure 1: Automated Certificate Rollover Related Properties

AutoCertificateRollover

When set to True, Automated Certificate Rollover is enabled for both the Token Signing Certificate and Token Decryption Certificate. CA issued certificates cannot be used for both.

When set to False, Automated Certificate Rollover is disabled for both the Token Signing Certificate and Token Decryption Certificate. CA issued certificates must be used for both.

CertificateThresholdMultiplier

The default value is 1440 minutes (24 hours/1 day).

This is a multiplier unit used by the other parameters and it is measured in the number of minutes.

CertificateRolloverInterval

The default value is 720 minutes (12 hours).

This is the frequency in minutes in which the federation service checks the current ADFS managed self-signed certificates.

CertificateDuration

The default value is 365 units.

This is the validity period of ADFS managed self-signed certificate. Defined by the number of multiplier units. In this custom scenario, the validity of the ADFS managed self-signed certificate is 10 units of 30 minutes, or 300 minutes (5 hours).

CertificateGenerationThreshold

The default value is 20 units.

This is the period of time before expiration of the current primary certificate, a new ADFS managed self-signed certificate is generated and marked as secondary. Defined by the number of multiplier units. In this custom scenario, a new ADFS managed self-signed will be generated and marked as secondary 2 hours (4 units of 30 minutes, 120 minutes) before the expiration of the current primary ADFS managed self-signed certificate.

CertificatePromotionThreshold

The default value is 5 units.

This is the period of time after which the previously newly generated ADFS managed self-signed certificate will be promoted to become the primary ADFS Managed self-signed certificate. Defined by the number of multiplier units. In this custom scenario, a new ADFS managed self-signed will be promoted to primary 1 hour (2 units of 30 minutes, 60 minutes) after it was generated.

CertificateCriticalThreshold

The default value is 2 units.

This is the period of time before expiration of the current primary certificate, a new ADFS managed self-signed certificate is generated and marked as primary immediately. This only occurs is everything else before failed and went down the drain. Defined by the number of multiplier units. In this custom scenario, a new ADFS managed self-signed will be generated and promoted to primary immediately half an hour (1 units of 30 minutes, 30 minutes) before the expiration of the current primary ADFS managed self-signed certificate.

When you put everything in a diagram, it looks like as shown below.

image

Figure 2: Automated Certificate Rollover Related Properties In A Diagram

As an example I will show the corresponding event IDs, for every moment, except the one for “CertificateCriticalThreshold”

image

Figure 3: The Generation Of The Very First ADFS Managed Self-Signed Token Decryption Certificate (“Valid From”)

image

Figure 4: The Generation Of The Very First ADFS Managed Self-Signed Token Signing Certificate (“Valid From”)

image

Figure 5: The Federation Service Checking The Current Certificates (CertificateRollOverInterval)

image

Figure 6: The Generation Of The (New) Next ADFS Managed Self-Signed Token Decryption Certificate And Configured As Secondary (CertificateGenerationThreshold)

image

Figure 7: The Generation Of The (New) Next ADFS Managed Self-Signed Token Signing Certificate And Configured As Secondary (CertificateGenerationThreshold)

image

Figure 8: The Promotion Of The Secondary ADFS Managed Self-Signed Token Decryption Certificate To Primary

image

Figure 9: The Promotion Of The Secondary ADFS Managed Self-Signed Token Signing Certificate To Primary

image

Figure 10: The Removal Of The (Old/Expired) Secondary ADFS Managed Self-Signed Token Signing Certificate (“Valid To”)

image

Figure 11: The Removal Of The (Old/Expired) Secondary ADFS Managed Self-Signed Token Decryption Certificate (“Valid To”)

For additional details also see:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

3 Responses to “(2013-05-14) ADFS Managed Certificates Supporting Auto Certificate Rollover”

  1. […] To determine if ADFS Managed Self-Signed certificates are being used for the Token Signing cert and the Token Encryption cert, you can execute the "Get-ADFSProperties" CMDlet and check if the property "AutoCertificateRollOver" is set to True. When set to True ADFS Managed Self-Signed certificates are being used. When set to False ADFS Managed Self-Signed certificates are NOT being used and you are then using CA issued certificates. All yellow marked properties below are used if the property "AutoCertificateRollOver" is set to True. For more information see (2013-05-14) ADFS Managed Certificates Supporting Auto Certificate Rollover. […]

  2. John said

    Good write up, though I believe that CertificatePromotionThreshold is actually the age (in units) that a newly-generated certificate will remain secondary certificate before being promoted to primary. Per MS http://technet.microsoft.com/en-us/library/ee892317.aspx. In your example, the age of the certificate and the time remaining before the existing primary certificate expiration is the same, so it worked as expected.

  3. Rich said

    I have found that the certification promotion threshold is actually 5 days after the auto generated cert is created. So if your generation threshold is 20 days, at 20 days it generates a new cert as a secondary. Then at 5 days after the new generation it makes the secondary the primary. Which at that point SSO stops working unless the cert was updated with the other parties.

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

 
%d bloggers like this: