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!

Archive for the ‘Web Application Proxy’ 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/ ########
———————————————————————————————

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

(2014-12-07) Web Application Proxy With Kerberos Constrained Delegation (KCD)

Posted by Jorge on 2014-12-07


I was setting the Web Application Proxy to publish three apps to the outside, 2 Claims Based Apps and 1 Windows Token Based App. All three apps were using ADFS pre-authentication. Because of that in ADFS I had 2 Claims Aware Relying Party Trusts and 1 non-Claims Aware Relying Party Trust.

image

Figure 1: Published Apps Through The Web Application Proxy (WAP)

After setting up all three apps in the WAP, I wanted to test the if all apps were working through WAP. Before doing that I tried accessing all apps from the inside. From the inside all apps worked. From the outside, through WAP, the Claims Based apps worked, but the Windows Token Based app did not work, or better said, it was not accessible.

image

Figure 2: IE Error When Trying To Access The Windows Token Based App Through WAP And ADFS

image

Figure 3: Error 1 Information In the Web Application Proxy Event Log

Web Application Proxy received an HTTP request with a valid edge token.

Audience: urn:AppProxy:com
Issuer: urn:federation:fs4.adcorp.lab
Valid From: ‎2014‎-‎10‎-‎26T21:38:41.000000000Z
Expires: ‎2014‎-‎10‎-‎26T22:38:41.000000000Z
Relying Party Trust Id: c064e4b5-345d-e411-8166-000c2929d8bc
UPN: jalmeidapinto@partner.lan
Device Registration Certificate Thumbprint: <Not Applicable>

Details:
Transaction ID: {b1f99230-f13d-0000-0da6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-03a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTU5MjEsImV4cCI6MTQxNDM1OTUyMSwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0wM2E2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMTk6NTg6MTQuODQ3WiIsInZlciI6IjEuMCJ9.Xx_NP1vZvVVewhhz0cZlY5RMKU_6q1ZuhUmZbSFHBP8bs3El6p5a_x3QfP_LxtCQFSM-vMdBQ930HwuAUq7EURoGIg5wsCQpvu-YC5CRokLSkb9pLF2_m_gnBcHxNVvGTg_3JSa0ZLUyvF3QIdNdh26E7A_msO3_PEp2m04l97OjBhFtQ1UxJhAx4NAKWMog2SwLuqP8bfpvSBrJ37Vzlr8_868QmQkuUQau-EIls4VhMTGdKXUEGrZHkOzLS2kbgAjGwX41Tl_Q_oyPfWFdAeoSee07lyvG69HmP7d_bSkje6D9Ez2xHc7GnT1VY77gSwP0-TKzGA8L8fvLPzUaQg&client-request-id=b1f99230-f13d-0000-03a6-f9b13df1cf01
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>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

image

Figure 4: Error 2 Information In the Web Application Proxy Event Log

Web Application Proxy cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: No credentials are available in the security package
(0x8009030e).

Details:
Transaction ID: {b1f99230-f13d-0000-0da6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-03a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTU5MjEsImV4cCI6MTQxNDM1OTUyMSwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0wM2E2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMTk6NTg6MTQuODQ3WiIsInZlciI6IjEuMCJ9.Xx_NP1vZvVVewhhz0cZlY5RMKU_6q1ZuhUmZbSFHBP8bs3El6p5a_x3QfP_LxtCQFSM-vMdBQ930HwuAUq7EURoGIg5wsCQpvu-YC5CRokLSkb9pLF2_m_gnBcHxNVvGTg_3JSa0ZLUyvF3QIdNdh26E7A_msO3_PEp2m04l97OjBhFtQ1UxJhAx4NAKWMog2SwLuqP8bfpvSBrJ37Vzlr8_868QmQkuUQau-EIls4VhMTGdKXUEGrZHkOzLS2kbgAjGwX41Tl_Q_oyPfWFdAeoSee07lyvG69HmP7d_bSkje6D9Ez2xHc7GnT1VY77gSwP0-TKzGA8L8fvLPzUaQg&client-request-id=b1f99230-f13d-0000-03a6-f9b13df1cf01
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode: WIA
State Machine State: BackendRequestProcessing_Pending
Response Code to Client: <Not Applicable>
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

image

Figure 5: Error 3 Information In the Web Application Proxy Event Log

Web Application Proxy encountered an unexpected error while processing the request.
Error: No credentials are available in the security package
(0x8009030e)

Details:
Transaction ID: {b1f99230-f13d-0000-0da6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-03a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTU5MjEsImV4cCI6MTQxNDM1OTUyMSwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0wM2E2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMTk6NTg6MTQuODQ3WiIsInZlciI6IjEuMCJ9.Xx_NP1vZvVVewhhz0cZlY5RMKU_6q1ZuhUmZbSFHBP8bs3El6p5a_x3QfP_LxtCQFSM-vMdBQ930HwuAUq7EURoGIg5wsCQpvu-YC5CRokLSkb9pLF2_m_gnBcHxNVvGTg_3JSa0ZLUyvF3QIdNdh26E7A_msO3_PEp2m04l97OjBhFtQ1UxJhAx4NAKWMog2SwLuqP8bfpvSBrJ37Vzlr8_868QmQkuUQau-EIls4VhMTGdKXUEGrZHkOzLS2kbgAjGwX41Tl_Q_oyPfWFdAeoSee07lyvG69HmP7d_bSkje6D9Ez2xHc7GnT1VY77gSwP0-TKzGA8L8fvLPzUaQg&client-request-id=b1f99230-f13d-0000-03a6-f9b13df1cf01
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode: WIA
State Machine State: OuOfOrderFEHeadersWriting
Response Code to Client: 500
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

Now, let’s think out loud to see why this is wrong, or not working. The following occurs in the order listed

  • The user on the external network uses the external URL in IE to target the application
  • The external URL resolves to the IP of the WAP and the WAP is targeted
  • WAP knows about the app being targeted and sees that pre-authentication through ADFS is enabled for it.
  • WAP sends the request to ADFS and because the user is coming from the extranet, the forms based logon page is presented to the user. If ADFS has more than claims provider trust, the home realm discovery page is shown first where the user must determine which identity provider will authenticate the user.
  • After the user has been authenticated, WAP goes to the next step. It sees the app being accessed is a Windows Token app
  • Because it is a Windows Token app, WAP expects to receive a the UPN claim type "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" with a value. Currently it is not possible to change that to expect another claim type like was possible in Unified Access Gateway (UAG)
  • Using the value from the UPN claim, it queries AD to determine the AD user account does exist, and assuming it exists, it will request kerberos tickets on behalf of the user for the service through kerberos constrained delegation (KCD). The service is identified through the SPN configured in the published app through WAP (WAP is able to do this when the Windows Server with WAP is joined to an AD domain! It cannot perform KCD when not joined to an AD domain! Also see: What’s New in Kerberos Authentication)

image

Figure 6: Backend Server SPN Identifying The Service Being Requested By The User

With just the errors above, I did not get it the first time. However, after thinking out loud, I realized I had forgotten to configure SPNs and delegation for the computer account of the WAP

So, let’s configure what needs to be configured.

WAP itself is running through a Network Service. It is not using some shared service account, but rather it is using its own computer account for KCD. Therefore the computer account of the individual WAP servers need to be configured, even if they are load balanced.

Doe every WAP server in the ball game, perform the following actions, as you can also see in the picture:

  • Add 2 SPNs to the WAP computer account:
    • HTTP/<FQDN> (e.g. HTTP/R1FSMBSVynext.ADCORP.LAB)
    • HTTP/<NetBIOS> (e.g. HTTP/R1FSMBSVynext)

image

Figure 7: Configuring 2 SPNs On The Computer Account Of The WAP Server

Now we need to configure delegation for the WAP computer account so that it is allowed to request kerberos service tickets for configured services. Also see: (2014-03-25) An Account With "Trusted For Delegation" – What Are The Risks?

In this case configure:

  • Trust this computer for delegation to specified services only
  • Use any authentication protocol

Then click the [Add] button to add the service to the list of allowed services

image

Figure 8: Configuring 2 SPNs On The Computer Account Of The WAP Server

However, which account do you add? There are a few ways to find out. Either query AD using the SPN specified in figure 6 using any of the three method in figure 9

image

Figure 9: Querying AD In Three ways For The Account Configured With A Specific SPN

…Or just go to the server and check which credentials the corresponding service is using. In this case it was a sharepoint site, whereas the IIS site was configured to use an application pool that was configured with an account.

image

Figure 10: Checking First If It Was Forced To Use An Application Pool

image

Figure 11: Checking The Advanced Settings Of The Service To Determine The Application Pool Name

image

Figure 12: Checking The Advanced Settings Of The Service To Determine The Application Pool Name

image

Figure 13: Specifying The sAMAccountName In The Object Dialog Window

image

Figure 14: Selecting The Service For Which The SPN Matches The SPN As Specified In Figure 6

image

Figure 15: After All, Committing The Config To The Directory

Now let’s try accessing the App again through WAP and ADFS….

image

Figure 16: Successful Access To The Windows Token App

Reviewing Web Application Proxy Event Log again…

image

Figure 17: Event ID Information In the Web Application Proxy Event Log

Web Application Proxy received an HTTP request with a valid edge token.

Audience: urn:AppProxy:com
Issuer: urn:federation:fs4.adcorp.lab
Valid From: ‎2014‎-‎10‎-‎26T22:02:06.000000000Z
Expires: ‎2014‎-‎10‎-‎26T23:02:06.000000000Z
Relying Party Trust Id: c064e4b5-345d-e411-8166-000c2929d8bc
UPN: jalmeidapinto@partner.lan
Device Registration Certificate Thumbprint: <Not Applicable>

Details:
Transaction ID: {b1f99230-f13d-0000-40a6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-30a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTczMjYsImV4cCI6MTQxNDM2MDkyNiwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0zMGE2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMjE6MDI6NTUuODA5WiIsInZlciI6IjEuMCJ9.GTOChpYcBD8zMgHvMPfrbNEEmYPDHi4iBVd513NJXYgPMTHZJMnD7n7ndAgN8sTPY330VLICHS2ccSXgRzGcayNyA_MJU-0awnklSQBLos5saAkUYi6yesZbyML0OFQ3ERL_aU-BuWMBiPE9oxG2V1v0uo6ESLAZ1Gh2KeRgDG0KiRtENzout5nz3gOprksgDGpKMIPyC5NDEotBgmOnVMQAw9UfWFALTr1Ovmuxhlp9jhbOz1EsgON8YzwHOar96DteGHX4hPPeCUzeuAERW8tUoT1FJocfEq9LtHH_oK-OLR2gLO2CMvng9AWGv4I9PLVHQp25pjyqtR6F4pOFgQ&client-request-id=b1f99230-f13d-0000-30a6-f9b13df1cf01
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>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

image

Figure 18: Event ID Information In the Web Application Proxy Event Log

Web Application Proxy successfully retrieved a Kerberos ticket on behalf of the user.

Details:
Transaction ID: {b1f99230-f13d-0000-40a6-f9b13df1cf01}
Session ID: {b1f99230-f13d-0000-30a6-f9b13df1cf01}
Published Application Name: Kerberos WAP Based Sharepoint App (RFSRWDC1)
Published Application ID: 3d096d98-4c52-d89d-b6c4-14321593fb1c
Published Application External URL:
https://app-kerb-wap2.adcorp.lab/
Published Backend URL: https://app-kerb-wap.adcorp.lab:453/
User: jalmeidapinto@partner.lan
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Device ID: <Not Applicable>
Token State: OK
Cookie State: NotFound
Client Request URL:
https://app-kerb-wap2.adcorp.lab/?authToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImRrZVpHY2VnSHVDalA0Qk9FZWY5emY4OWVNVSJ9.eyJhdWQiOiJ1cm46QXBwUHJveHk6Y29tIiwiaXNzIjoidXJuOmZlZGVyYXRpb246ZnM0LmFkY29ycC5sYWIiLCJpYXQiOjE0MTQzNTczMjYsImV4cCI6MTQxNDM2MDkyNiwicmVseWluZ3BhcnR5dHJ1c3RpZCI6ImMwNjRlNGI1LTM0NWQtZTQxMS04MTY2LTAwMGMyOTI5ZDhiYyIsInVwbiI6ImphbG1laWRhcGludG9AcGFydG5lci5sYW4iLCJjbGllbnRyZXFpZCI6ImIxZjk5MjMwLWYxM2QtMDAwMC0zMGE2LWY5YjEzZGYxY2YwMSIsImF1dGhtZXRob2QiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImF1dGhfdGltZSI6IjIwMTQtMTAtMjZUMjE6MDI6NTUuODA5WiIsInZlciI6IjEuMCJ9.GTOChpYcBD8zMgHvMPfrbNEEmYPDHi4iBVd513NJXYgPMTHZJMnD7n7ndAgN8sTPY330VLICHS2ccSXgRzGcayNyA_MJU-0awnklSQBLos5saAkUYi6yesZbyML0OFQ3ERL_aU-BuWMBiPE9oxG2V1v0uo6ESLAZ1Gh2KeRgDG0KiRtENzout5nz3gOprksgDGpKMIPyC5NDEotBgmOnVMQAw9UfWFALTr1Ovmuxhlp9jhbOz1EsgON8YzwHOar96DteGHX4hPPeCUzeuAERW8tUoT1FJocfEq9LtHH_oK-OLR2gLO2CMvng9AWGv4I9PLVHQp25pjyqtR6F4pOFgQ&client-request-id=b1f99230-f13d-0000-30a6-f9b13df1cf01
Backend Request URL: <Not Applicable>
Preauthentication Flow: PreAuthBrowser
Backend Server Authentication Mode: WIA
State Machine State: BackendRequestProcessing_Pending
Response Code to Client: <Not Applicable>
Response Message to Client: <Not Applicable>
Client Certificate Issuer: <Not Found>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: GET

That’s all folks!

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), Kerberos Constrained Delegation, Web Application Proxy | 5 Comments »

(2014-04-02) Building An ADFS Lab In W2K12(R2)

Posted by Jorge on 2014-04-02


The guys from AskPFE have written an interesting series of building an ADFS lab on W2K12 and then upgrade that to ADFS on W2K12R2 .

How to Build Your ADFS Lab on Server 2012 Part 1

How to Build Your ADFS Lab on Server 2012, Part2: Web SSO

How to Build Your ADFS Lab on Server 2012 Part 3: ADFS Proxy

How to Build Your ADFS Lab Part4: Upgrading to Server 2012 R2

With regards to migrating ADFS v2.x to ADFS v3.0, also have a look at (2014-03-12) Additional PowerShell Scripts For Migrating ADFS v2.x To ADFS v3.0

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), Claims Based Apps, Migration, Proxy Service, Security Token Service (STS), Web Application Proxy | Leave a Comment »

(2014-03-24) ADFS v3.0 In W2K12R2 And Related Features In Summary With Details

Posted by Jorge on 2014-03-24


Mylo has written a number of blog posts focusing on his first impressions regarding ADFS v3.0 in W2K12R2 and related features (e.g. Workplace Join, Device Registration, Web Application Proxy, etc). The blog posts are a perfect summary with lots of interesting details. Wow, my compliments!

First Impressions – AD FS and Windows Server 2012 R2 – Part I

First Impressions – AD FS and Windows Server 2012 R2 – Part II

First Impressions – AD FS and Windows Server 2012 R2 – Part III (to be published by Mylo)

In addition to this Ramiro Calderon has written great blog posts focusing on MFA in ADFS v3.0. Again, my compliments!

Under the hood tour on Multi-Factor Authentication in ADFS – Part 1: Policy

Under the hood tour on Multi-Factor Authentication in ADFS – Part 2: MFA aware Relying Parties

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), Device Registration, Security Token Service (STS), Web Application Proxy, Workplace Join | Leave a Comment »

(2014-02-27) Exchange OWA Through ADFS

Posted by Jorge on 2014-02-27


In following blog posts you can read how you can access OWA through federation and kerberos constrained delegation (KCD):

In the scenarios above the Claims To Windows Token Service (C2WTS) was used to perform the KCD part as ADFS itself is not capable of doing that

With the release of Exchange 2013 SP1, it is now natively supported and you do not need to perform all kinds of manual steps. Instead of using the C2WTS, you can now use the Web Application Proxy (WAP) to perform the KCD part.

see: Using AD FS claims-based authentication with Outlook Web App and EAC

Although I have not tried this myself, after reading it quickly I noticed a few weird things:

  • Step 1: Although true what is said, I would like to suggest the following regarding the certificates:
    • Service Communication Certificate for ADFS –> CA issued from an internal PKI if available, otherwise CA issued from a well-known external/third-party CA issuer (e.g. DigiCert, Thawte, Verisign, etc.)
    • Token Signing Certificate for ADFS –> CA issued from a well-known external/third-party CA issuer (e.g. DigiCert, Thawte, Verisign, etc.). Although possible, you should not use self-signed certificates or CA issued from an internal PKI
    • Token Encryption Certificate for ADFS –> CA issued from a well-known external/third-party CA issuer (e.g. DigiCert, Thawte, Verisign, etc.). Although possible, you should not use self-signed certificates or CA issued from an internal PKI
  • Step 2: If you are using CA issued certs for Token Signing Certificate and the Token Encryption Certificate you need to install ADFS through FSCONFIG.EXE (ADFS v2.0 and ADFS v2.1) or INSTALL-ADFSFARM (ADFS v3.0) and specify the thumbprint of the certificates. You need to make sure those certificates are in the local certificate store first!
  • Step 2: it is not true you require a group Managed Service Account. Sure that would be preferred, you must have at least one W2K12 DC or higher to be able to support that. However in all cases you can still use a normal service user account.
  • Step 3: I’m kind of surprised to see the so called require claims rules for both the OWA relying part trust as the EAC relying party trust. Like I said, I have not done this myself yet, but I would expect to only require the pass-through of the UPN claim on both RP trusts. Of course you need to ask yourself "if I pass it through, where do I pass it from then?" Right! You gather the UPN claim by using a claim rule on the claims provider trust. How you do that differs from ADFS v2.x and ADFS v3.0. With ADFS v2.x you need to perform an LDAP query (using the LDAP Claim Rule Template) and in ADFS v3.0 you can pass it through (see: "(2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0" and "(2014-02-10) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0 (Update 1)")
  • Step 4: No clue WHY the claims rules are being added, again. That was already done in step 3. Again no clue why you need the Primary SID and the Group SID
  • Step 5: I saw the following line: "Although Web Application Proxy isn’t required" Huh? Who’s going to do the KCD part then? I agree you should use WAP when allowing external access. But for internal access, if WAP is not required, is that the reason why they are sending the "Primary SID" claim and the "Group SID" claim? Hmmmm, interesting. I wonder if ADFS has some hidden feature regarding KCD. To be investigated!

Well, have fun!

If you try it yourself, please let me know your findings. Thanks in advance

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), Claims Based Apps, Exchange Server, OWA, Security Token Service (STS), Web Application Proxy | Leave a Comment »

 
%d bloggers like this: