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-13) Certificates Used In Active Directory Federation Services (ADFS) v2.x

Posted by Jorge on 2013-05-13


In ADFS v2.x the following certificates can be used:

  1. For Security Token Service (STS) servers only:
    1. Service Communications certificate
    2. Token Signing Certificate
    3. Token Decryption Certificate
  2. Proxy Service (PRX) servers
    1. Service Communications certificate

[AD.1.1 – Service Communications Certificate For ADFS STS servers]

This certificate secures all the HTTP communications with the ADFS STS servers. You should use a CA issued certificate (internal or external) for production and test systems or use a non-ADFS managed self-signed certificate if your test environment does not have a PKI infrastructure. Assuming you are not connecting the ADFS STS servers (the farm) directly to the internet, you could use a CA issued certificate from your internal PKI infrastructure instead of CA issued certificate from a public PKI infrastructure. If you are connecting your ADFS STS servers (the farm) directly to the internet (you nutball you!), you must use CA issued certificate from a public PKI infrastructure.

For this certificate you can use any certificate template as long as that certificate template has the “Enhanced Key Usage (EKU)” for “Server Authentication”. In addition, the subject or the SAN should specify the FQDN of the federation service. However, if you want the use a wildcard certificate, then that’s also possible.

The FQDN of the federation service can be found through the GUI by either selecting and right-clicking the “AD FS 2.0” node or the “Service” node and selecting the option “Edit Federation Service Properties”. The TAB “General” will show the FQDN of the federation service.

image

Figure 1: Federation Service Properties Through The ADFS MMC

The FQDN of the federation service can also be found through PowerShell by adding/loading the PowerShell snap-in (for ADFS v2.0) through “Add-PSSnapin Microsoft.ADFS.PowerShell” or the PowerShell module (for ADFS v2.1) through “Import-Module ADFS” followed by the command “Get-ADFSProperties”. The property “HostName” will show the FQDN of the federation service.

image

Figure 2: Federation Service Properties Through The ADFS PowerShell Snap-In/Module

This certificate and private key should be distributed amongst all ADFS STS servers and installed/imported into the personal store of the computers. After that, on each ADFS STS, the ADFS Service account must have at least (and that’s enough!) READ permissions on the private key. Start an MMC console, add a snap-in called “Certificates” for the computer account of the local computer. Right-click the imported certificate and select the options “All Tasks –> Manage Private Keys”, add the ADFS service account and assign it Allow:Read permissions.

image

Figure 3: Assigning The ADFS Service Account Allow:Read Permissions To The Private Key Of The Service Communications Certificate

Again, on each ADFS STS server you need to bind the (new) certificate to the default website in IIS. Open the IIS MMC, navigate to the Default Web Site, right-click it and select the option “Edit Bindings”. Select the binding “https – 443 – *”, click EDIT and select the correct certificate

image

Figure 4: Binding The Service Communications Certificate To The Default Web Site In IIS

And last but not least, you need to configure the (new) Service Communications Certificate as the ADFS Service Communications Certificate through the ADFS MMC. Open the ADFS MMC, navigate to the Certificates node, in the Actions pane click the “Set Service Communications Certificate” option and select the correct Service Communications Certificate for ADFS. This only needs to be done on one ADFS STS as this applies to the ADFS Farm. If you are using SQL you can choose any ADFS STS server and if you are using WID, you need to choose the primary ADFS STS server.

[AD.1.2 – Token Signing Certificate For ADFS STS servers]

This certificate signs every issued security token by this ADFS STS server/farm. This is also THE certificate on which the federation trust is based! For this you can use a CA issued certificate (internal or external) or you can use an ADFS managed self-signed certificate. For the first automatic certificate rollover must be disabled and for the latter it must be enabled!

When a federation trust (Relying Party Trust) with an upstream application exists, that application may need to trust the parent issuing/root CAs that issued the certificate. When using a CA issued certificate from your internal PKI infrastructure or a public PKI infrastructure, that most likely is not a problem as the issuing/root CAs are specified in the correct certificate stores. However, if you are using an ADFS managed self-signed certificate you may also need to add that ADFS managed self-signed certificate to the Trust Root Certificate Store. Whether or not that is needed depends on how the upstream application works. Is it enough for the Token Signing Certificate of the issuing ADFS STS to be listed in the federation trust OR must it in addition to that also be listed in the Trusted Root Certificate store of the computer hosting the application! For example, Sharepoint 2010 would need both!

When a federation trust (Relying Party Trust) with an upstream federation service exists, that federation service may need to trust the parent issuing/root CAs that issued the certificate. When using a CA issued certificate from a public PKI infrastructure, that most likely is not a problem as the issuing/root CAs are specified in the correct certificate stores. However, if you are using a CA issued certificate from your internal PKI infrastructure or an ADFS managed self-signed certificate you may also need to respectively add the issuing/root CAs of your internal PKI infrastructure or the ADFS managed self-signed certificate to the Trust Root Certificate Store. Whether or not that is needed depends on how the upstream federation service works. Is it enough for the Token Signing Certificate of the issuing ADFS STS to be listed in the federation trust OR must it in addition to that also be listed in the Trusted Root Certificate store of the computer(s) hosting the upstream federation service! If two ADFS based federation services have a trust between each other you can use an ADFS managed self-signed certificate for the Token Signing Certificate without adding it to the Trust Root Certificate Store.

For this certificate you can use any certificate template, when CA issued, as long as that certificate template has the “Key Usage (KU)” for “Digital Signature”. In addition, the subject or the SAN should specify something that makes sense. No known or used FQDN must be explicitly used, you can basically use anything. Preferably you specify something like “ADFS.Token.Signing” or “<FQDN Federation Service>.Token.Signing” (e.g. FS.ADCORP.LAB.TOKEN.SIGNING).

If you are using an ADFS managed self-signed certificate the next steps are not needed. However, if you are using a CA issued certificate, from either your internal PKI infrastructure or a public PKI infrastructure, you must perform the next steps.

This certificate and private key should be distributed amongst all ADFS STS servers and installed/imported into the personal store of the computers. After that, on each ADFS STS, the ADFS Service account must have at least (and that’s enough!) READ permissions on the private key. Start an MMC console, add a snap-in called “Certificates” for the computer account of the local computer. Right-click the imported certificate and select the options “All Tasks –> Manage Private Keys”, add the ADFS service account and assign it Allow:Read permissions.

image

Figure 5: Assigning The ADFS Service Account Allow:Read Permissions To The Private Key Of The Token Signing Certificate

And last but not least, you need to configure the (new) Token Signing Certificate as the (secondary) ADFS Token Signing Certificate through the ADFS MMC. Open the ADFS MMC, navigate to the Certificates node, in the Actions pane click the “Add Token Signing Certificate” option and select the correct Token Signing Certificate for ADFS. The new certificate will be listed as the secondary ADFS Token Signing Certificate. In time you need to promote the new certificate to become the primary ADFS Token Signing Certificate. This only needs to be done on one ADFS STS as this applies to the ADFS Farm. If you are using SQL you can choose any ADFS STS server and if you are using WID, you need to choose the primary ADFS STS server.

The (new) Token Signing Certificate is published automatically in the federation metadata.

[AD.1.3 – Token Decryption Certificate For ADFS STS servers]

This certificate encrypts every issued security token by this ADFS STS server/farm using the certificate of the receiving ADFS STS server/farm. For this you can use a CA issued certificate (internal or external) or you can use an ADFS managed self-signed certificate. For the first automatic certificate rollover must be disabled and for the latter it must be enabled!

When a federation trust (Claims Provider Trust) with an downstream federation service exists, that downstream federation service may need to trust the parent issuing/root CAs that issued the certificate. When using a CA issued certificate from a public PKI infrastructure, that most likely is not a problem as the issuing/root CAs are specified in the correct certificate stores. However, if you are using a CA issued certificate from your internal PKI infrastructure or an ADFS managed self-signed certificate you may also need to respectively add the issuing/root CAs of your internal PKI infrastructure or the ADFS managed self-signed certificate to the Trust Root Certificate Store. Whether or not that is needed depends on how the downstream federation service works. Is it enough for the Token Decryption Certificate of the receiving ADFS STS to be listed in the federation trust OR must it in addition to that also be listed in the Trusted Root Certificate store of the computer(s) hosting the downstream federation service! If two ADFS based federation services have a trust between each other you can use an ADFS managed self-signed certificate for the Token Decryption Certificate without adding it to the Trust Root Certificate Store.

For this certificate you can use any certificate template, when CA issued, as long as that certificate template has the “Key Usage (KU)” for “Key Encipherment”. In addition, the subject or the SAN should specify something that makes sense. No known or used FQDN must be explicitly used, you can basically use anything. Preferably you specify something like “ADFS.Token.Decryption” or “<FQDN Federation Service>.Token.Decryption” (e.g. FS.ADCORP.LAB.TOKEN.DECRYPTION).

If you are using an ADFS managed self-signed certificate the next steps are not needed. However, if you are using a CA issued certificate, from either your internal PKI infrastructure or a public PKI infrastructure, you must perform the next steps.

This certificate and private key should be distributed amongst all ADFS STS servers and installed/imported into the personal store of the computers. After that, on each ADFS STS, the ADFS Service account must have at least (and that’s enough!) READ permissions on the private key. Start an MMC console, add a snap-in called “Certificates” for the computer account of the local computer. Right-click the imported certificate and select the options “All Tasks –> Manage Private Keys”, add the ADFS service account and assign it Allow:Read permissions.

image 

Figure 6: Assigning The ADFS Service Account Allow:Read Permissions To The Private Key Of The Token Decryption Certificate

And last but not least, you need to configure the (new) Token Decryption Certificate as the (secondary) ADFS Token Decryption Certificate through the ADFS MMC. Open the ADFS MMC, navigate to the Certificates node, in the Actions pane click the “Add Token Decryption Certificate” option and select the correct Token Decryption Certificate for ADFS. The new certificate will be listed as the secondary ADFS Token Decryption Certificate. In time you need to promote the new certificate to become the primary ADFS Token Decryption Certificate. This only needs to be done on one ADFS STS as this applies to the ADFS Farm. If you are using SQL you can choose any ADFS STS server and if you are using WID, you need to choose the primary ADFS STS server.

The (new) Token Decryption Certificate is published automatically in the federation metadata.

[AD.2.1 – SSL Communications Certificate For ADFS PRX servers]

This certificate secures all the HTTP communications with the ADFS PRX servers. You should use a CA issued certificate (external only!) for production and test systems or use a non-ADFS managed self-signed certificate if your test environment does not have a PKI infrastructure. You should use a CA issued certificate from a public PKI infrastructure because you are connecting/exposing your ADFS PRX servers directly to the internet. So, if you are receiving traffic from the internet that is related to the federation service (e.g. metadata exchange, authentication, home realm discovery, etc.) you should use some kind of reverse proxy such as for example the ADFS Proxy Server!

For this certificate you can use any certificate template as long as that certificate template has the “Enhanced Key Usage (EKU)” for “Server Authentication”. In addition, the subject or the SAN should specify the FQDN of the federation service. However, if you want the use a wildcard certificate, then that’s also possible. To determine the FQDN of the federation service see above!

This certificate and private key should be distributed amongst all ADFS PRX servers and installed/imported into the personal store of the computers.

Last but not least, and again on each ADFS PRX server you need to bind the (new) certificate to the default website in IIS. Open the IIS MMC, navigate to the Default Web Site, right-click it and select the option “Edit Bindings”. Select the binding “https – 443 – *”, click EDIT and select the correct certificate

image

Figure 7: Binding The Service Communications Certificate To The Default Web Site In IIS

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

4 Responses to “(2013-05-13) Certificates Used In Active Directory Federation Services (ADFS) v2.x”

  1. […] « (2013-05-13) Certificates Used In Active Directory Federation Services (ADFS) v2.x […]

  2. […] mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x, in ADFS v2.x the following certificates can be […]

  3. […] 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 […]

  4. […] More information about certificates used in ADFS can be found through the following blog post (2013-05-13) Certificates Used In Active Directory Federation Services (ADFS) v2.x (also applies to ADFS v3 and ADFS […]

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: