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/ ########
———————————————————————————————
Jorge's Quest For Knowledge! 