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 ‘Certificates’ Category

(2017-02-17) Accessing Published Application Through Web Application Proxy With ADFS Pre-Authentication Fails

Posted by Jorge on 2017-02-17


You are using ADFS v3.0, or higher, in combination with the Web Application Proxy (WAP) to publish internal applications to the outside. Some of those applications are published with “pre-authentication” and some of those applications are published with “pass-through”.

On a device that is on the outside of your network, in a browser you enter the URL of an application that is published through the WAP with ADFS pre-authentication. The issue I’m about to explain DOES NOT occur with applications published through the WAP with pass-through.

Most likely you will hit a similar screen as the one below that is asking for Forms Based Authentication (FBA).

image

Figure 1: The ADFS Forms Based Authentication Screen

After entering the credentials you are redirected back to the application, and you end up stuck in an empty screen. When you look up at the URL, you may see something like “authToken=”.

image

Figure 2: After Being Redirected To The Application An Empty Screen

When looking in the Web Application Proxy Event Log you may find a similar event as the one below, telling you the Edge Token signing is not correct.

image

Figure 3: Event About An Invalid Edge Token

Web Application Proxy received a nonvalid edge token signature.
Error: Edge Token signature mismatch. edgeTokenHelper.ValidateTokenSignature failed: Verifying token with signature public key failed

Received token: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InNJZ1Z6ZXVQSkVnVWtkQ1BEa3VsSHF4UVY2USJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnMuaWFtdGVjLm5sIiwiaWF0IjoxNDg3MjgzNTU5LCJleHAiOjE0ODcyODcxNTksInJlbHlpbmdwYXJ0eXRydXN0aWQiOiI4NmI1OTA2MS0yZTk2LWU1MTEtODBmYy0wMDBjMjkxNDY3NWYiLCJ1cG4iOiJqb3JnZUBpYW10ZWMubmwiLCJjbGllbnRyZXFpZCI6IjM0MTljNjA4LTg4OTQtMDAwMC0zZmM3LTE5MzQ5NDg4ZDIwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTctMDItMTZUMjI6MTk6MTguMTIyWiIsInZlciI6IjEuMCJ9.L_dnLDoEQ6U8ViJ9XWBEMdagj4QsUV4emvtHiX4dik3vos3tWN_1YWvHdVO_QLi6kVqZSqdMUcya0yJ4qFifZc4R2aodrnLnn_mVDzjBJK1nyz6x_iv7LfX9kRcIdhQRJ6UoT0y9DVDnpo6b4cgu4B38ikiohu-qOcJ22TXQqYs0hgj3TCMvzFOH17dAkgL0Z1XZvGwKJDxBXPP54sRd1k8QyMMTq30kpMLi36yl8hAIIV4RTQBAVhfs6FLTBJidl7Sq3TSQwUwhf3SMNh8UNlL0CsxlKLmt1Q45NaFcFuHXCJoMjIoN_OAe21fBfyY9vrf2KygpJv77r4qRTzIYmw

Details:
Transaction ID: {3419c608-8894-0000-40c7-19349488d201}
Session ID: {3419c608-8894-0000-3fc7-19349488d201}
Published Application Name: Show My Claims (ASP.NET) (Basic)
Published Application ID: 53B426A6-162E-C09B-4D8F-62AAB4E79989
Published Application External URL:
https://XXXXXXXXXXXXXXXXXXXXX/YYYYYYYYYY/
Published Backend URL: https://XXXXXXXXXXXXXXXXXXXXX/YYYYYYYYYY/
User: <Unknown>
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Device ID: <Not Applicable>
Token State: Invalid
Cookie State: NotFound
Client Request URL:
https://XXXXXXXXXXXXXXXXXXXXX/YYYYYYYYYY/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InNJZ1Z6ZXVQSkVnVWtkQ1BEa3VsSHF4UVY2USJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnMuaWFtdGVjLm5sIiwiaWF0IjoxNDg3MjgzNTU5LCJleHAiOjE0ODcyODcxNTksInJlbHlpbmdwYXJ0eXRydXN0aWQiOiI4NmI1OTA2MS0yZTk2LWU1MTEtODBmYy0wMDBjMjkxNDY3NWYiLCJ1cG4iOiJqb3JnZUBpYW10ZWMubmwiLCJjbGllbnRyZXFpZCI6IjM0MTljNjA4LTg4OTQtMDAwMC0zZmM3LTE5MzQ5NDg4ZDIwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTctMDItMTZUMjI6MTk6MTguMTIyWiIsInZlciI6IjEuMCJ9.L_dnLDoEQ6U8ViJ9XWBEMdagj4QsUV4emvtHiX4dik3vos3tWN_1YWvHdVO_QLi6kVqZSqdMUcya0yJ4qFifZc4R2aodrnLnn_mVDzjBJK1nyz6x_iv7LfX9kRcIdhQRJ6UoT0y9DVDnpo6b4cgu4B38ikiohu-qOcJ22TXQqYs0hgj3TCMvzFOH17dAkgL0Z1XZvGwKJDxBXPP54sRd1k8QyMMTq30kpMLi36yl8hAIIV4RTQBAVhfs6FLTBJidl7Sq3TSQwUwhf3SMNh8UNlL0CsxlKLmt1Q45NaFcFuHXCJoMjIoN_OAe21fBfyY9vrf2KygpJv77r4qRTzIYmw&client-request-id=3419c608-8894-0000-3fc7-19349488d201
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode:
State Machine State: Idle
Response Code to Client: <Not Applicable>
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>

When you look up the error in the first line you might find one of the following URLs:

In the beginning, you had to configure the WAP with the primary Token Signing certificate in use by ADFS, with the command:

Set-WebApplicationProxyConfiguration -ADFSTokenSigningCertificatePublicKey MIIFvTCCA6WgAwIBAgITPQAAAL…..

After the update http://support.microsoft.com/kb/2935608, you will the “ADFSTokenSigningCertificatePublicKey” property is marked as obsolete. That means you do not have to manually populate the public key of the ADFS Token Signing certificate, but rather WAP will leverage the ADFS metadata to discover the Token Signing certificates in use by ADFS.

Within ADFS you can define multiple Token Signing certificates and one of those certificates is marked as PRIMARY and all others are marked as SECONDARY. As you can see below you can see that my test/demo environment has 3 Token Signing certificates.

image

Figure 4: List Of Token Signing Certificates In The ADFS Console

When you look into the ADFS metadata (URL: /federationmetadata/2007-06/federationmetadata.xml">https://<FQDN ADFS Service>/federationmetadata/2007-06/federationmetadata.xml), you will find all the Token Signing certificates listed in the “IdPSSODescriptor” section (for the role of IdP) and in the “SPSSODescriptor” section (for the role of SP), which have been marked as “use=”signing””. As you can expect and compare it to figure 4 above, you will see (in my case!) 3 “KeyDescriptor”s, one for each Token Signing certificate in use by ADFS. ADFS will always publish all Token Signing certificates in the metadata. no matter if they’re primary or secondary. In addition, ADFS will always publish only the primary Token Encryption certificate in the metadata.

image

Figure 5: List Of Token Signing Certificates In The ADFS Metadata

Using this website you can check the certificates in the metadata and get some output you can understand. You copy the value between “<X509Certificate>…………..</X509Certificate> “ and enter that in the certificate text window.

After doing that 3 times I got (in my case!):

image

Figure 6: One Of The Token Signing Certificates In Use By ADFS (Marked As Secondary As Shown In Figure 4)

image

Figure 7: One Of The Token Signing Certificates In Use By ADFS (Marked As Secondary As Shown In Figure 4)

image

Figure 8: One Of The Token Signing Certificates In Use By ADFS (Marked As Primary As Shown In Figure 4)

As mentioned before, WAP reads the ADFS metadata and picks up the Token Signing certificates in use by ADFS. HOWEVER, it only picks the first 2 occurrences designated as “use=”signing”” as disregards all other occurrences!. Therefore in my case it reads the first and second occurrence (Figure 6 and 7) and ignores the third occurrence (Figure 8). However, when you look in Figure 4 you will see that the certificate listed in Figure 8 is the primary Token Signing certificate that is being actively used by ADFS to sign issued tokens. Because of that WAP can verify the signature of the issued Edge Token and fails with the error as shown in Figure 3.

The Figure below show you that WAP will only read the first 2 occurrences of the Token Signing certificates in the ADFS Metadata

image

Figure 9: WAP Reading The ADFS Metadata And Fetching The First 2 Occurrences Of The Token Signing Certificate

Web Application Proxy fetched certificate public key values from federation metadata successfully.
Primary key: MIIDXzCCAkegAwIBAgIQVR5qR+aSho5MH9eWFSXqWDANBgkqhkiG9w0BAQsFADAoMSYwJAYDVQQDDB1UT0tFTi5TSUdOSU5HLlNFTEYuU0lHTkVELk5FVzAeFw0xNjA1MjExMTAyNTFaFw0xODA1MDExMTAyNTFaMCgxJjAkBgNVBAMMHVRPS0VOLlNJR05JTkcuU0VMRi5TSUdORUQuTkVXMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyP5e8em3Y+2Yq57gePRoEjCymWjxozVoVlPn9JuZAQ94KLcVpFDAwJBoD1eNM587hX17WFDUqN6ZM6LMUuPiNSzdugieb+k3kQnTagkJV4vHiwo8qcBHX27DEri/pD81J+6DdiKjrqGVut6+llNP+ab0LXdsuEvoq89eGSNRoUTDHr556CFw4Y+VgwMuXwPVnJoLpj8I9Ml4kItGoBxyAA1RnWNzNBy1GKQ1vIBQxX4/aWAGqBzCs81vrpKhy0HfA/kR9eGoW3GvjJyeSXNkXMfI/5N7SAk11EPopqh6tt1XgjvbyJjiwdE1f79E3mX4ceaz2OQ4H17lYW4jtTZe4QIDAQABo4GEMIGBMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCBaAwMQYDVR0RBCowKIImRE5TIE5hbWU9VE9LRU4uU0lHTklORy5TRUxGLlNJR05FRC5ORVcwHQYDVR0OBBYEFODJ6In6M+5pyaZqU1ygso7MRdBoMA0GCSqGSIb3DQEBCwUAA4IBAQCddGlhNBR+HKWM9kN/EIgH6lc5HYaAzx6zdAiez3X6F/sbGzj0dSAeFrhGGMa/8S4U/lwy01z/FyDPydpoyySnVCStTRYwm1VwRKzen+YwwFWpuSZbdv/TpUm3JfPKzA6Rjaja3M+c7R+2SWZ5/lo5sJwUlhA2O+G4MZOi4F7odxa13XviOCQnnbsTM2JX8Dgue8uMe5M037xDlggeP3vNTXXChtbFTXa+S6NJksOkjL7GSC9VmHJQUPqcqyc8QJH5ynsmPtkr3txrq/HrViSEOynC3klyHOniHNitaW1TK3XHfvLK8tuNI2GL8cFmMP9hzAxANFXPA2FeESiMASJT.
Secondary key: MIIDUTCCAjmgAwIBAgIQc4D9JdgHWYxG5BMq0w06kzANBgkqhkiG9w0BAQsFADAkMSIwIAYDVQQDDBlUT0tFTi5TSUdOSU5HLlNFTEYuU0lHTkVEMB4XDTE1MDkyMTA5MDc0OVoXDTE3MDgyMjA5MDc0OVowJDEiMCAGA1UEAwwZVE9LRU4uU0lHTklORy5TRUxGLlNJR05FRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/KaQ7oQYUF7KZ7cV/PijzuxcgPurRjsoUhFOtZd0wPQz57z8dTWVa2L0Yecuu/qOXvvI5W6XtuRshhQuRpgMZohqw8/y9cVmHrLPVLsyjmSKQtXD8Xd3je+xnY01uMWW6BSB8udbPWaRKG0wnrdpFVRDVlcJKosuLAxCbwXOJbKDX27GAmYGcZSfrlCk/acTGmd7652CZKxNllPwUiX2L5zxJ0BMiEG+xurngsxqzDryrQvMz/ldzwgBZa4wQvnaoevKRTkfp/NfbY34LZxBUMNK7bwbS8dlIrGGeoGSo9q8M9QeIw5URE2CCa8/+UBZuEuorQMWQ9J5nDCzfwK+8CAwEAAaN/MH0wHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB/wQEAwIFoDAtBgNVHREEJjAkgiJETlMgTmFtZT1UT0tFTi5TSUdOSU5HLlNFTEYuU0lHTkVEMB0GA1UdDgQWBBQ61L+viK+SHtuwZ7OjXrARHQlFHzANBgkqhkiG9w0BAQsFAAOCAQEAr+cI1HlQUlZwxlXZchow3kWPc165qOGqu3xp2B3R1nDrMgTSlBPnIQwLCM9+X9xZ1PaQLRmPLDDOV+0CoimzvHJU+1AjdTnU82gNYBCM3ULQk+HTliilTZL3fcJE+QSOH/03TxGyopfw52v4kITGa5KsZpkemvFUnCEkgWk74D2AqDj9j0zwq5zSoJrC9eIWM8ztl3srmiFrhHmEsPSw8hbe20OdTu1xfmI/UgtnVBL2LwJnXuWpv/GgxSC41SS7F5AS2Y42Ojter6Tk5Vu1OnQwKjkJb6JvoHQcVYQaqSb4ufS1aU6kkC8U1qNAgwmv86Mhhqpf66H05UtMtKo/zg==.

Although this is my test/demo environment, what are the lessons learned here?

Please make sure to always follow the following guidelines:

  • Always have 1 Token Signing certificate and 1 Token Encryption certificate that are configured as primary and valid for some time (at least 2 or 3 years or more)!
  • Some time before the Token Signing certificate and/or the Token Encryption certificate are going to expire (e.g. 2 months before expiration) add a new Token Signing certificate and/or Token Encryption certificate (whatever is applicable) and make sure it is marked as secondary.
  • To all connected IdPs and connected SPs communicate you will be changing certificates, and where applicable:
    • Ask to check if they have updated metadata when consuming the metadata URL of your ADFS
    • Mail the metadata XML file containing the current and new certificates or mail the individual certificate files or just mail both
  • To all connected IdPs and connected SPs communicate you will be switching the certificates on a specific date
    • If the connected system leverages the metadata URL or metadata XML file from your ADFS and it supports 2 Token Signing certificates, the metadata can be updated right away
    • If the connected system leverages the metadata URL or metadata XML file from your ADFS and it supports only 1 Token Signing certificate, the metadata should be updated on the specified date
    • If the connected system allows the import or configuration of individual certificates and it supports at least 2 Token Signing certificates, the import or configuration of individual certificates can occur right away
    • If the connected system allows the import or configuration of individual certificates and it supports only 1 Token Signing certificate, the import or configuration of individual certificates should only occur on the specified date
  • Somewhere between 2 and 4 weeks before the certificate expires switch the certificates from primary to secondary and vice versa by configuring the new Token Signing certificate and/or Token Encryption certificate as primary
  • After the old Token Signing certificate and/or Token Encryption certificate (the one configured as secondary) have expired remove it from ADFS and remove it from the certificate store on every ADFS server

In my case the solution is: remove at least one of the secondary certs. I removed all secondaries! ending with only one as you can see below.

image

Figure 10: List Of Token Signing Certificates In The ADFS Console

On all WAP servers restart the “Web Application Proxy Service” service. You will then see the following event telling you that WAP has fetched the Token Signing certificates from ADFS

image

Figure 11: WAP Reading The ADFS Metadata And Fetching The First 2 Occurrences Of The Token Signing Certificate

Web Application Proxy fetched certificate public key values from federation metadata successfully.
Primary key: MIIFvTCCA6WgAwIBAgITPQAAALW+MGZzrC/smgAAAAAAtTANBgkqhkiG9w0BAQsFADBKMRMwEQYKCZImiZPyLGQBGRYDTkVUMRYwFAYKCZImiZPyLGQBGRYGSUFNVEVDMRswGQYDVQQDExJQS0ktUk9PVC1DQS1JQU1URUMwHhcNMTcwMTExMjI0MjM3WhcNMTkwMTExMjI0MjM3WjAlMSMwIQYDVQQDExpGUy5JQU1URUMuTkwuVE9LRU4uU0lHTklORzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMvFCaJ9uV+4PWn9x/SN9cDv1uw5iv/PAyM+0KaN9O+Z+bpC8Zg2BKG+niEnhgOL44Ju/HFq8B05ri+FTRuaF++MsbULgNspIAT/YR57O01qdHmp+/U99aAKFQGkLQzYY5H/oSvsf6KkcX/48+GdeYHJIdqaHVHoebDr/jRuFdeF+QNOhPJSa/LdFD0FkZp3E4/UbgJLNkAyI3JMfj/d0ylO/H//+/UGazfeGfCMQ25KilIjVVDypo80I9YMLuqc4SnUVLpbz907P62tL+A6bU4nsSim84zxzZ2OVqr+prCALRnQ1dGtDG1tGqGk2nCcJJrcaK6HhtalQRcypc8RZn8CAwEAAaOCAb8wggG7MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIPFnQuG8tIrgrWTDIODjlqE/NNggXmH0e1q5JkwAgFkAgEDMBMGA1UdJQQMMAoGCCsGAQUFBwMBMBEGA1UdDwEB/wQHAwUEQDAwMDAbBgkrBgEEAYI3FQoEDjAMMAoGCCsGAQUFBwMBMB0GA1UdDgQWBBRPO9BFXvhThi2Ill1j1IyuQWJVDDAlBgNVHREEHjAcghpGUy5JQU1URUMuTkwuVE9LRU4uU0lHTklORzAfBgNVHSMEGDAWgBSf9NVzUtr9IOSgZRN8SP8W+TbR5zBBBgNVHR8EOjA4MDagNKAyhjBodHRwOi8vY2RwLklBTVRFQy5ORVQvY3JsL1BLSS1ST09ULUNBLUlBTVRFQy5jcmwwgYoGCCsGAQUFBwEBBH4wfDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AuSUFNVEVDLk5FVC9vY3NwMFEGCCsGAQUFBzAChkVodHRwOi8vY3J0LklBTVRFQy5ORVQvY3J0L1IxRlNSV0RDMS5JQU1URUMuTkVUX1BLSS1ST09ULUNBLUlBTVRFQy5jcnQwDQYJKoZIhvcNAQELBQADggIBAGv392nwZGDgSq7rapUXPdDcoM69a+nsGQhdH59TYwRhHWkgcCZH7la01ZYxky0Kf9ucaAbvBDlIXP088exB44Tqal30N/umZaKpddi1l5qtyJJ2vjNbNSA8wh+iLPpNf6h3uJwGDajoSIeONnuP5imVWlH0MFNhtgcF0nTDrDiST1xzvuquWDG806NEgIZXNx2RKzEi4JHjKnMDYSaPChEF8AtUGKHKd6XfW3vtqD3PUkyTP5wF1uVJ4W7iIb9C7PcR3UlcBzs3mfUOtOUkRiKzGzPCt8agDQ+lKOXshF3vjX0oB7ZJHuGoVI9brKzI0DyxB1JJ75rvIGBIhL/CGUvYwf9tGWUr1UfXykFQGZHSw5gpNesyHlEKjfm/vmwDBDYZpkXr09/ngCJ33HKFYIdvQWZuN8GFmb14HcM5tWV+A5rJMTyAD0+ybisBIt77VZBQU3lQvdAPVeNxYePyECxPRER/Mpwmu8ctxfvkmn7a3CBa9n6G+ZPTeYLKI3vMdjUSQdCRC4/Bgupv1c9Awsf93orjaRVcu1IIfTLUlUykFTieyBzcx5jUGxvlvPNhHDDkRo9fS9eD7m/ypTEIpV2JM/0rjepE0afCva+OAlHic0T4FgZGOTguIwnAQxkVCAig3WflGRuxtqLniYllubrGkJSHQjPLT6R27QtxcxPQ.
Secondary key: <none>.

After these actions the application published through the WAP and configured with ADFS pre-authentication was accessible again from the outside!

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

Advertisements

Posted in Active Directory Federation Services (ADFS), Certificates, Forms Based AuthN, Pre-Authentication, Security Tokens, Web Application Proxy | Leave a Comment »

(2017-01-15) Azure AD Connect Health Telling The ADFS Farm Just Dropped Dead!

Posted by Jorge on 2017-01-15


When you get any or all of the following mails from Azure AD Connect, your ADFS farm is hosed and you are in big trouble. Make sure this does NOT happen to you!

(Don’t worry, this is just my test/demo environment that was turned for the holidays)

image

image

image

Figure 1: E-mail From Azure AD Connect Health Mentioning The Token Signing Certificate Has Expired

image

image

image

Figure 2: E-mail From Azure AD Connect Health Mentioning The Token Encryption/Decryption Certificate Has Expired

image

image

Figure 3: E-mail From Azure AD Connect Health Mentioning The SSL Certificate Has Expired

In addition, your ADFS Admin Event Log only displays one color, RED, lots of it!

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), Azure AD Connect Health, Certificates, Windows Azure Active Directory | Leave a Comment »

(2015-10-10) Certificate Chain Validation And Revocation Status Checking In ADFS

Posted by Jorge on 2015-10-10


Within ADFS federation trusts can be configured with one or more Token Signing certificates and/or one Token Encryption certification. 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 v4!).

For every certificate used, certificate chain validation is done if the certificate was issued by a CA. It does not apply to self-signed certificates as there is no chain. For CA issued certificates, certificate chain validation is performed online through the URL(s) specified in the AIA extension of the certificate, or offline if the certificates in the chain of the certificate are configured in the Local Machine stores for Root CAs and Intermediate CAs.

image_thumb[5]

Figure 1: The Authority Information Access (AIA) Extension Of A CA Issued Certificate

In addition, the revocation status of the certificate is checked through the URL(s) specified in the CDP extension of the certificate and/or the AIA extension of the certificate when OCSP is being used. This of course only applies to any certificate issued by a certificate authority. It does not apply to self-signed certificates.

image_thumb[7]

Figure 2: The CRL Distribution Points (CDP) Extension Of A CA Issued Certificate

Revocation status checking of a certificate used in a particular federation trust (Claims Provider Trust or Relying Party Trust) depends on the setting configured for the certificate type used by the trust (e.g. Token Signing and/or Token Encryption). Both the Token Signing certificate and the Token Encryption certificate have their own revocation status checking setting, and both support the following settings:

  • CheckChain –> Check online revocation status for every certificate that is part of the certificate chain
  • CheckChainCacheOnly  –> Check offline revocation status for every certificate that is part of the certificate chain
  • CheckChainExcludeRoot (DEFAULT) –> Check online revocation status for every certificate that is part of the certificate chain, except for the certificate of the root CA
  • CheckChainExcludeRootCacheOnly  –> Check offline revocation status for every certificate that is part of the certificate chain, except for the certificate of the root CA
  • CheckEndCert –> Check online revocation status for only the end certificate being used
  • CheckEndCertCacheOnly –> Check offline revocation status for only the end certificate being used
  • None –> Do not perform any (online or offline) revocation status checking

Certificate chain validation can be done either offline or online, and that also applies certificate revocation status checking. For certificate revocation status checking, either being performed online or offline, access to the CRL distribution points is still required.

Certificate chain validation checks the validity of the complete chain. Certificate revocation status checking checks for the revocation status of the certificates used, depending on the configured settings. It is also possible to fully disable certificate revocation status checking. But think again! You are relying on (third-party) certificates to increase the assurance of the certificates being used in some federation trusts, therefore checking the revocation status is a good idea! When disabling it or weakening it, the purpose of using certificates is defeated. So, why would you still disable certificate revocation status checking? Let me guess, the ADFS server(s) do not have any external network (e.g. internet) connectivity and can therefore not access the CRL distribution points. Remember that the federation ecosystem heavily depends on certificates, and that checking the validity of those certificates is of utmost importance. There *I* would prefer to have the ADFS servers accessing the internet to check certificate revocation lists. Any risk mitigation actions available to protect the ADFS from malicious web sites? Yes, there is and that’s for the next blog post!

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), Certificates | 1 Comment »

(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 »

(2014-03-12) Additional PowerShell Scripts For Migrating ADFS v2.x To ADFS v3.0

Posted by Jorge on 2014-03-12


In this article Microsoft explains how to migrate from ADFS v2.x to ADFS v3.0. In this blog post I have added multiple PowerShell scripts to help you migrate as automated as possible.

!!! DISCLAIMER/REMARKS !!!

  • These scripts are freeware, you are free to distribute it, but always refer to this website (https://jorgequestforknowledge.wordpress.com/) as the location where you got it
  • These scripts are furnished "AS IS". No warranty is expressed or implied!
  • Always test first in lab environment to see if it meets your needs!
  • Use these scripts at your own risk!
  • I do not warrant these scripts to be fit for any purpose, use or environment
  • I have tried to check everything that needed to be checked, but I do not guarantee these scripts do not have bugs.
  • I do not guarantee these scripts will not damage or destroy your system(s), environment or whatever.
  • I do not accept any liability in any way if you screw up, use the scripts wrong or in any other way where damage is caused to your environment/systems!
  • If you do not accept these terms do not use the scripts and delete it immediately!

!!! DISCLAIMER/REMARKS !!!

All scripts can also be downloaded from here.

+++++++++++++++++++++++++++++++++
++++++++++++++ PREPARE ++++++++++
+++++++++++++++++++++++++++++++++

# +++[P1]+++ Create Migration Folders #SCRIPT NAME --> "C:\TEMP\Create-Folders.ps1" New-Item "C:\ADFS-MIG" -ItemType Directory New-Item "C:\ADFS-MIG\Config" -ItemType Directory New-Item "C:\ADFS-MIG\Export" -ItemType Directory New-Item "C:\ADFS-MIG\Service" -ItemType Directory New-Item "C:\ADFS-MIG\Web" -ItemType Directory

++++++++++++++++++++++++++++++++

++++++++++++ EXPORT ++++++++++++

++++++++++++++++++++++++++++++++

# +++[E1]+++ Output Federation Service Properties (On ADFS STS Only!) #SCRIPT NAME --> "C:\ADFS-MIG\Output-Federation-Service-Properties.ps1" If (Test-Path -Path "C:\Program Files\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config") { Add-PSSnapIn Microsoft.ADFS.PowerShell } If (Test-Path -Path "C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config") { Import-Module ADFS } # Record ADFS Service Properties Get-Service -Name ADFSSRV | Select * | Out-File C:\ADFS-MIG\Config\ADFSService.txt Get-WmiObject win32_service | ?{$_.name -eq "ADFSSRV"} | Select * | Out-File C:\ADFS-MIG\Config\ADFSService.txt -Append # Record All ADFS Properties Get-ADFSProperties | Out-File C:\ADFS-MIG\Config\ADFSProperties.txt # Record All ADFS Endpoints Get-ADFSEndpoint | Out-File C:\ADFS-MIG\Config\ADFSEndpoint.txt # Record All ADFS Claim Descriptions Get-ADFSClaimDescription | Out-File C:\ADFS-MIG\Config\ADFSClaimDescription.txt # Record All ADFS Certificates Get-ADFSCertificate | Out-File C:\ADFS-MIG\Config\ADFSCertificate.txt # Record All ADFS Claims Provider Trusts Get-ADFSClaimsProviderTrust | Out-File C:\ADFS-MIG\Config\ADFSClaimsProviderTrust.txt # Record All ADFS Relying Party Trusts Get-ADFSRelyingPartyTrust | Out-File C:\ADFS-MIG\Config\ADFSRelyingPartyTrust.txt # Record All ADFS Attribute Stores Get-ADFSAttributeStore | %{ "##########" | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append "Store Name. = " + $_.Name | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append "Store Class = " + $_.StoreTypeQualifiedName | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append "Store Config:" | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append $_.Configuration.GetEnumerator() | %{ " * " + $_.Name + " = " + $_.Value | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append } "" | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append }

# +++[E2]+++ Export ANY CA Issued Certificate In Use By ADFS (On ADFS STS Only!) #SCRIPT NAME --> "C:\ADFS-MIG\Export-CA-Issued-Certificates-To-CER-And-PFX-From-ADFS-STS.ps1" $privateKeyProtectionPWD1 = Read-Host "Please Specify The Password To Protect The Private Keys..." $privateKeyProtectionPWD2 = Read-Host "Please Re-Type The Password To Protect The Private Keys..." If ($privateKeyProtectionPWD1 -ne $privateKeyProtectionPWD2) { Write-Host "Passwords DO NOT Match..." Write-Host "Aborting..." BREAK } Else { $certype = [System.Security.Cryptography.X509Certificates.X509ContentType]::pfx $ADFSCertificates = Get-ADFSCertificate $adfsSvcCommCert = $ADFSCertificates | ?{$_.CertificateType -eq "Service-Communications" -And $_.StoreLocation -eq "LocalMachine"} If (($adfsSvcCommCert | Measure-Object).Count -eq 1) { $adfsSvcCommCertThumbprint = $adfsSvcCommCert.Certificate.Thumbprint $adfsSvcCommCertName = "ADFS Service Communication Cert (STS)" $adfsSvcCommCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsSvcCommCertThumbprint} If ($adfsSvcCommCertInLocalStore.HasPrivateKey -eq $true -And $adfsSvcCommCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) { $adfsSvcCommCertBytesCER = $adfsSvcCommCertInLocalStore.export("Cert") [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".cer"), $adfsSvcCommCertBytesCER) $adfsSvcCommCertBytesPFX = $adfsSvcCommCertInLocalStore.export($certype, $privateKeyProtectionPWD1) [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".pfx"), $adfsSvcCommCertBytesPFX) } } $adfsTokenSignCert = $ADFSCertificates | ?{$_.CertificateType -eq "Token-Signing" -And $_.StoreLocation -eq "LocalMachine"} If (($adfsTokenSignCert | Measure-Object).Count -ge 1) { $i = 1 $adfsTokenSignCert | %{ $adfsTokenSignCertThumbprint = $_.Certificate.Thumbprint $adfsTokenSignCertName = "ADFS Token Signing Cert (STS) (" + $i + ")" $adfsTokenSignCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsTokenSignCertThumbprint} If ($adfsTokenSignCertInLocalStore.HasPrivateKey -eq $true -And $adfsTokenSignCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) { $adfsTokenSignCertBytesCER = $adfsTokenSignCertInLocalStore.export("Cert") [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenSignCertName + ".cer"), $adfsTokenSignCertBytesCER) $adfsTokenSignCertBytesPFX = $adfsTokenSignCertInLocalStore.export($certype, $privateKeyProtectionPWD1) [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenSignCertName + ".pfx"), $adfsTokenSignCertBytesPFX) } $i += 1 } } $adfsTokenEncryptCert = $ADFSCertificates | ?{$_.CertificateType -eq "Token-Decrypting" -And $_.StoreLocation -eq "LocalMachine"} If (($adfsTokenEncryptCert | Measure-Object).Count -ge 1) { $j = 1 $adfsTokenEncryptCert | %{ $adfsTokenEncryptCertThumbprint = $_.Certificate.Thumbprint $adfsTokenEncryptCertName = "ADFS Token Encryption Cert (STS) (" + $j + ")" $adfsTokenEncryptCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsTokenEncryptCertThumbprint} If ($adfsTokenEncryptCertInLocalStore.HasPrivateKey -eq $true -And $adfsTokenEncryptCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) { $adfsTokenEncryptCertBytesCER = $adfsTokenEncryptCertInLocalStore.export("Cert") [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenEncryptCertName + ".cer"), $adfsTokenEncryptCertBytesCER) $adfsTokenEncryptCertBytesPFX = $adfsTokenEncryptCertInLocalStore.export($certype, $privateKeyProtectionPWD1) [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenEncryptCertName + ".pfx"), $adfsTokenEncryptCertBytesPFX) } $j += 1 } } }

# +++[E3]+++ Export The ADFS v2.x Configuration To XML Files (On ADFS STS Only!) #Get PoSH Script From W2K12R2 Media (Folder: <CD>\Support\Adfs) Or Folder C:\Windows\Adfs After Installation ADFS Role #Copy Script To Folder "C:\ADFS-MIG" On Source ADFS Server C:\ADFS-MIG\Export-FederationConfiguration.ps1 -Path C:\ADFS-MIG\Export

# +++[E4]+++ Copy The ADFS v2.x Web Configuration Files (On ADFS STS And ADFS Proxy!) #SCRIPT NAME --> "C:\ADFS-MIG\Copy-ADFS-Web-Server-Configuration-Files.ps1" Import-Module WebAdministration $adfsWebPath = (Get-WebApplication "adfs/ls").PhysicalPath Copy-Item $($adfsWebPath + "\*") "C:\ADFS-MIG\Web" -Recurse

# +++[E5]+++ Copy The ADFS v2.x Service Configuration Files (On ADFS STS And ADFS Proxy!) #SCRIPT NAME --> "C:\ADFS-MIG\Copy-ADFS-Web-Service-Configuration-File.ps1" If (Test-Path -Path "C:\Program Files\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config") { Copy-Item "C:\Program Files\Active Directory Federation Services 2.0\*") "C:\ADFS-MIG\Service" -Recurse } If (Test-Path -Path "C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config") { Copy-Item "C:\Windows\ADFS\*") "C:\ADFS-MIG\Service" -Recurse }

# +++[E6]+++ Export ANY CA Issued Certificate In Use By ADFS (On ADFS Proxy Only!) #SCRIPT NAME --> "C:\ADFS-MIG\Export-CA-Issued-Certificates-To-CER-And-PFX-From-ADFS-PRX.ps1" $privateKeyProtectionPWD1 = Read-Host "Please Specify The Password To Protect The Private Keys..." $privateKeyProtectionPWD2 = Read-Host "Please Re-Type The Password To Protect The Private Keys..." If ($privateKeyProtectionPWD1 -ne $privateKeyProtectionPWD2) { Write-Host "Passwords DO NOT Match..." Write-Host "Aborting..." BREAK } Else { $certype = [System.Security.Cryptography.X509Certificates.X509ContentType]::pfx $adfsSvcCommCertThumbprint = (Get-WebBinding "Default Web Site" -protocol https).certificateHash $adfsSvcCommCertName = "ADFS Service Communication Cert (PRX)" $adfsSvcCommCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsSvcCommCertThumbprint} If ($adfsSvcCommCertInLocalStore.HasPrivateKey -eq $true -And $adfsSvcCommCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) { $adfsSvcCommCertBytesCER = $adfsSvcCommCertInLocalStore.export("Cert") [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".cer"), $adfsSvcCommCertBytesCER) $adfsSvcCommCertBytesPFX = $adfsSvcCommCertInLocalStore.export($certype, $privateKeyProtectionPWD1) [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".pfx"), $adfsSvcCommCertBytesPFX) } }

+++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++ CREATE/JOIN/CONFIGURE ADFS ++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++

# +++[C1]+++ Create ADFS Farm Using WID And ADFS Managed Self-Signed Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-WID-Self-Signed-Certs.ps1" $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..." $adfsSvcCreds = Get-Credential Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C2]+++ Create ADFS Farm Using WID And CA Issued Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-WID-CA-Issued-Certs.ps1" $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..." $adfsSvcCreds = Get-Credential Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint -SigningCertificateThumbprint $adfsTokenSignCertThumbprint -DecryptionCertificateThumbprint $adfsTokenEncryptCertThumbprint | FL

# +++[C3]+++ Create ADFS Farm Using SQL And ADFS Managed Self-Signed Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-SQL-Self-Signed-Certs.ps1" $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..." $adfsSvcCreds = Get-Credential $sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..." $sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True" Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -SQLConnectionString $sqlConnectionString -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C4]+++ Create ADFS Farm Using SQL And CA Issued Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-SQL-CA-Issued-Certs.ps1" $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..." $adfsSvcCreds = Get-Credential $sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..." $sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True" Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" $adfsTokenSignCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Token Signing Certificate" $adfsTokenEncryptCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Token Encryption Certificate" Add-WindowsFeature ADFS-Federation Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -SQLConnectionString $sqlConnectionString -CertificateThumbprint $adfsSvcCommCertThumbprint -SigningCertificateThumbprint $adfsTokenSignCertThumbprint -DecryptionCertificateThumbprint $adfsTokenEncryptCertThumbprint | FL

# +++[C5]+++ Join ADFS Farm Using WID And ADFS Managed Self-Signed Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-WID-Self-Signed-Certs.ps1" $adfsSvcCreds = Get-Credential $adfsPrimaryServer = Read-Host "Please Specify The FQDN Of The Primary Server..." Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Add-AdfsFarmNode -PrimaryComputerName $adfsPrimaryServer -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C6]+++ Join ADFS Farm Using WID And CA Issued Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-WID-CA-Issued-Certs.ps1" $adfsSvcCreds = Get-Credential $adfsPrimaryServer = Read-Host "Please Specify The FQDN Of The Primary Server..." Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Add-AdfsFarmNode -PrimaryComputerName $adfsPrimaryServer -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C7]+++ Join ADFS Farm Using SQL And ADFS Managed Self-Signed Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-SQL-Self-Signed-Certs.ps1" $adfsSvcCreds = Get-Credential $sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..." $sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True" Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Add-AdfsFarmNode -SQLConnectionString $sqlConnectionString -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C8]+++ Join ADFS Farm Using SQL And CA Issued Certificates #SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-SQL-CA-Issued-Certs.ps1" $adfsSvcCreds = Get-Credential $sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..." $sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True" Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Add-WindowsFeature ADFS-Federation Add-AdfsFarmNode -SQLConnectionString $sqlConnectionString -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C9]+++ Install And Configure Web Application Proxy #SCRIPT NAME --> "C:\ADFS-MIG\Install-And-Configure-Web-Application-Proxy.ps1" Add-WindowsFeature Web-Application-Proxy -IncludeManagementTools $adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..." $adfsAdminCreds = Get-Credential Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap $adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate" Install-WebApplicationProxy -FederationServiceName $adfsSvcFQDN -FederationServiceTrustCredential $adfsAdminCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

# +++[C10]+++ Add/Publish Web Applications Through Web Application Proxy Get-WebApplicationProxyApplication --> http://technet.microsoft.com/en-us/library/dn283413.aspx Get-WebApplicationProxyAvailableADFSRelyingParty --> http://technet.microsoft.com/en-us/library/dn283412.aspx Add-WebApplicationProxyApplication --> http://technet.microsoft.com/en-us/library/dn283409.aspx

++++++++++++++++++++++++++++++++

++++++++++++ IMPORT ++++++++++++

++++++++++++++++++++++++++++++++

# +++[I1]+++ Import ANY CA Issued Certificate In Use By ADFS (On ADFS STS Only!) (Only Works On W2K12R2!!!) #SCRIPT NAME --> "C:\ADFS-MIG\Import-CA-Issued-Certificates-Into-ADFS-STS-Local-Cert-Store.ps1" $privateKeyProtectionPWD = ConvertTo-SecureString -String $(Read-Host "Please Specify The Password Protecting The Private Keys...") -Force –AsPlainText $adfsSvcCommCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Service Communication Cert (STS).pfx' If (($adfsSvcCommCertPFXFile | Measure-Object).Count -ge 1) { Import-PfxCertificate -FilePath $($adfsSvcCommCertPFXFile.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD } $adfsTokenSignCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Token Signing Cert (STS)*.pfx' If (($adfsTokenSignCertPFXFile | Measure-Object).Count -ge 1) { $adfsTokenSignCertPFXFile | %{Import-PfxCertificate -FilePath $($_.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD} } $adfsTokenEncryptCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Token Encryption Cert (STS)*.pfx' If (($adfsTokenEncryptCertPFXFile | Measure-Object).Count -ge 1) { $adfsTokenEncryptCertPFXFile | %{Import-PfxCertificate $($_.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD} }

# +++[I2]+++ Import The ADFS v2.x Configuration From The XML Files Into ADFS v3.0 #Get PoSH Script From W2K12R2 Media (Folder: <CD>\Support\Adfs) Or Folder C:\Windows\Adfs After Installation ADFS Role #Copy Script To Folder "C:\ADFS-MIG" On Source ADFS Server C:\ADFS-MIG\Import-FederationConfiguration.ps1 -Path C:\ADFS-MIG\Export

# +++[I3]+++ Import ANY CA Issued Certificate In Use By ADFS (On ADFS Proxy/WAP Only!) (Only Works On W2K12R2!!!) #SCRIPT NAME --> "C:\ADFS-MIG\Import-CA-Issued-Certificates-Into-ADFS-PRX-Local-Cert-Store.ps1" $privateKeyProtectionPWD = ConvertTo-SecureString -String $(Read-Host "Please Specify The Password Protecting The Private Keys...") -Force –AsPlainText $adfsSvcCommCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Service Communication Cert (PRX).pfx' If (($adfsSvcCommCertPFXFile | Measure-Object).Count -ge 1) { Import-PfxCertificate -FilePath $($adfsSvcCommCertPFXFile.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD }

A while back I also found a blog post with PowerShell script to quickly deploy both ADFS v3.0 and WAP. You can find that blog post here.

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), Certificates, Farm, Federation Trusts, Migration, Proxy Service, Security Token Service (STS) | 4 Comments »

(2013-05-15) Replacing ADFS Certificates

Posted by Jorge on 2013-05-15


You have an ADFS infrastructure up-and-running smoothly, but your certificates are about to expire. It is very important you start renewing your current certificates as needed and in time way before your current certificates expire. In addition, you may need to notify upstream application owners, upstream federation services and downstream federation services.

As mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x, in ADFS v2.x the following certificates can be used:

  1. For Security Token Service (STS) servers only:
    1. Service Communications certificate (CA issued certificate)
    2. Token Signing Certificate (CA issued certificate or ADFS managed self-signed)
    3. Token Decryption Certificate (CA issued certificate or ADFS managed self-signed)
  2. Proxy Service (PRX) servers
    1. Service Communications certificate (CA issued certificate)

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

Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x and then:

  • Import CA issued certificate into the personal store of each ADFS STS server;
  • On each ADFS STS server, permission the private key (only if new) with the ADFS Service Account to have Allow:Read
  • On each ADFS STS server, bind the CA issued certificate to the default website in IIS
  • Using the ADFS MMC on any ADFS STS server (when using SQL) or the primary ADFS STS server (when using WID), configure the certificate as the “Service Communications” certificate

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

First you need to determine and understand if you are using a CA issued certificate or an ADFS managed self-signed certificate.

If you are using an ADFS managed self-signed certificate, then ADFS will perform the rollover (add, promote and remove) automatically.

If you are using CA issued certificate you must replace (add, publish, remove)  the certificate manually by performing the following actions:

  • Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x
  • Import CA issued certificate into the personal store of each ADFS STS server;
  • On each ADFS STS server, permission the private key (only if new) with the ADFS Service Account to have Allow:Read
  • Using the ADFS MMC on any ADFS STS server (when using SQL) or the primary ADFS STS server (when using WID), configure the certificate as the secondary “Token Signing” certificate

After that publish/communicate [*] the new ADFS Token Signing Certificate to every upstream application and/or upstream federation service that is represented as an Relying Party Trust in your ADFS based federation service and every downstream federation service that is represented as an Relying Party Trust in your ADFS based federation service [**] . The owner of the upstream application and/or upstream federation service must add the new ADFS Token Signing Certificate of your federation service to the Claims Provider Trust or Identity Provider Trust (whatever it is called) that represents your federation service. The owner of the downstream federation service must add the new ADFS Token Signing Certificate of your federation service to the Relying Party Trust or Service Provider Trust (whatever it is called) that represents your federation service [**].

After publishing/communicating [*] the new ADFS Token Signing Certificate to every upstream application and/or upstream federation service that is represented as an Relying Party Trust in your ADFS based federation service and every downstream federation service that is represented as a Claims Provider Trust in your ADFS based federation service, promote the secondary “Token Signing” certificate to become the primary “Token Signing” certificate.

[*] Publishing/Communicating New Token Signing Certificates To Upstream Applications And/Or Upstream Federation Services

If the federation metadata is published through an URL AND it is also consumed automatically by those upstream applications and/or upstream federation services, then instruct the owners of those upstream upstream applications and/or upstream federation services to import/read the updated federation metadata through the URL, if not already done automatically. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

If the federation metadata is NOT published through an URL OR it is NOT consumed automatically by those upstream applications and/or upstream federation services, then export the Token Signing Certificate from ADFS and send that certificate with the public key to the owners of those upstream upstream applications and/or upstream federation services and instruct them to import the new Token Signing Certificate into the Claims Provider Trust or Identity Provider Trust (whatever it is called) that represents your federation service. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

[**] Token Signing Certificates Also Used By Downstream Federation Services

Some relying parties require that signature certificates are applied to the relying party for SAML requests, as signature certificates provide a critical security validation function and are defined in the SAML 2.0 specification.

TIP: Know which entity consumes your federation metadata automatically and also know which ones do not! You can for example use the NOTES property of each trust to specify if your metadata URL is being used by the entity and if you are using the entity’s metadata URL! That way you would be able to easily query through PowerShell who you would need to contact!

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

First you need to determine and understand if you are using a CA issued certificate or an ADFS managed self-signed certificate.

If you are using an ADFS managed self-signed certificate, then ADFS will perform the rollover (add, promote and remove) automatically.

If you are using CA issued certificate you must replace (add, publish, remove)  the certificate manually by performing the following actions:

  • Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x
  • Import CA issued certificate into the personal store of each ADFS STS server;
  • On each ADFS STS server, permission the private key (only if new) with the ADFS Service Account to have Allow:Read
  • Using the ADFS MMC on any ADFS STS server (when using SQL) or the primary ADFS STS server (when using WID), configure the certificate as the secondary “Token Decrypting” certificate

After that publish/communicate [***] the new ADFS Token Decrypting Certificate to every downstream federation service that is represented as an Claims Provider Trust in your ADFS based federation service. The owner of the downstream federation service must add the new ADFS Token Decryption Certificate of your federation service to the Relying Party Trust or Service Provider Trust (whatever it is called) that represents your federation service.

After publishing/communicating [***] the new ADFS Token Decrypting Certificate to every downstream federation service that is represented as an Claims Provider Trust in your ADFS based federation service, promote the secondary “Token Decrypting” certificate to become the primary “Token Decrypting” certificate.

[**] Publishing/Communicating New Token Decrypting Certificates To Downstream Federation Services

If the federation metadata is published through an URL AND it is also consumed automatically by those downstream federation services, then instruct the owners of those downstream federation services to import/read the updated federation metadata through the URL, if not already done automatically. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

If the federation metadata is NOT published through an URL OR it is NOT consumed automatically by those downstream federation services, then export the Token Decrypting Certificate from ADFS and send that certificate with the public key to the owners of those downstream federation services and instruct them to import the new Token Decrypting Certificate into the Relying Party Trust or Service Provider Trust (whatever it is called) that represents your federation service. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

TIP: Know which entity consumes your federation metadata automatically and also know which ones do not! You can for example use the NOTES property of each trust to specify if your metadata URL is being used by the entity and if you are using the entity’s metadata URL! That way you would be able to easily query through PowerShell who you would need to contact!

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

Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x and then:

  • Import CA issued certificate into the personal store of each ADFS PRX server;
  • On each ADFS PRX server, bind the CA issued certificate to the default website 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/ ########
———————————————————————————————

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

(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 »

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

Posted in Active Directory Federation Services (ADFS), Certificates | 4 Comments »

 
%d bloggers like this: