Jorge's Quest For Knowledge!

All 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!

Archive for the ‘Auto Certificate Rollover’ Category

(2014-03-14) Gathering Architectural Details From Your ADFS Infrastructure – ADFS Certs

Posted by Jorge on 2014-03-14


If ADFS was installed in the past by someone else and there is little to no documentation, how do you know if you are you using ADFS Managed Self-Signed Certs Or CA Issued Certs for your Token Signing and Token Encryption certs? Keep reading to find out how to determine that!

ADFS Managed Self-Signed Certs Or CA Issued Certs For Your Token Signing and Token Encryption Certs?

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.

One important thing to remember is:

  • The value for CertificateSharingContainer is NOT populated when ADFS is in StandAlone mode
  • The value for CertificateSharingContainer is populated when ADFS most likely in Farm mode and when ADFS Managed Self-Signed certificates are actually being used OR have been used (after changing to CA issued certs)
  • If CA issued certs are being used, and you were using ADFS Managed Self-Signed certificates before that, you can safely delete the Certificate Sharing Container from AD (test first and be able to fully restore deleted objects as needed!)

image

Figure 1: Are ADFS Managed Self-Signed Certificates Being Used For The Token Signing Cert And The Token Encryption Cert Or Not?

With ADFS Managed Self-Signed Certificates the "Issued To" and the "Issued By" are always the same. The part before the dash (-) is always "ADFS Signing" and the part after the dash (-) is always "<the FQDN of the Federation Service>"

image

Figure 2: Are ADFS Managed Self-Signed Certificate For The Token Signing Cert

With ADFS Managed Self-Signed Certificates the "Issued To" and the "Issued By" are always the same. The part before the dash (-) is always "ADFS Encryption" and the part after the dash (-) is always "<the FQDN of the Federation Service>"

image

Figure 3: Are ADFS Managed Self-Signed Certificate For The Token Encryption Cert

Either the ADFS MMC or the PowerShell CMDlet "Get-ADFSCertificate" will tell you which certificates are in use by ADFS. Also see: (2013-05-13) Certificates Used In Active Directory Federation Services (ADFS) v2.x

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/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Auto Certificate Rollover, Certificates | Leave a Comment »

(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/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Auto Certificate Rollover, Certificates | 3 Comments »

 
%d bloggers like this: