1. Explorations in AD FS, Shibboleth, SharePoint, Exchange, and more.
Federating the Enterprise: Web Single Sign-On for On-Premise Applications
Explorations in AD FS, Shibboleth, SharePoint, Exchange, and more.
J. Greg Mackinnon, Whole-Systems Administrator
Enterprise Technology Services
The University of Vermont

2. Overview: AD FS Deployment and Shibboleth Integration:
Lessons from a year in production
SharePoint 2013 Web SSO configuration
…with recommended dosages of beer and Tylenol.
Exchange 2013 Web SSO configuration
…and plenty of second-guessing.
Roadmap for other on-premises Web SSO projects
Moral quandaries, ambiguity, and existential gridlock.
Absolutely no stupid Star Trek references.* *
*Actual presentation may contain Star Trek references

3. Which are you?
Two Pictures, and a show of hands… with which character do you identify with most?
The courageous star ship captain, loyal and true to his crew and command, who passionately defends the enlightened laws and standards of this country?
The unfeeling cyborg, who dispassionately executes the commands generated by the collective wisdom of his hive?
We will get back to this question later.

4. Terminology: Web SSO technologies
AD FS, Shibboleth, Web Application Proxy (WAP)
Identity Provider (IdP) / Claims Provider / Security Token Service (STS)
WS-Federation and SAML
Relying Party / Service Provider (RP/SP)
Claims / Assertions
“Traditional” authentication technologies
Kerberos, NTLM, NTLM2
SharePoint:
Web Application, Custom Claims Provider
Exchange:
OWA, ECP
Virtual Directories
Technology and Terminology that will be used in this presentation. I am assuming basic familiarity with these.

5. The Environment: The red box is the new stuff we will cover today.
Yellow = Trust Relationships.
Red = Configuration data
Blue = Flow of identity data.
Today we will be focusing on areas boxed in blue, mainly on setting up the trusts between Exchange, SharePoint, and AD FS.

6. Color Key: Does not work as documented. Hull Breach Imminent.
Potential problems, take note. Shields at 50%.
Documentation is good. We’re all good here, how are you?

7. AD FS – Microsoft’s Gift
Credential Hygiene (SAML tokens instead of passwords)
Achievable Multi-Factor Authentication (Smart Card, Certificates, Third-Parties such as Duo)
Interoperates with Shibboleth/InCommon (and other SAML 2.0 IdPs)
Enables Office 365 authentication against on-premise AD*
WAP “Protocol Transitioning”
Converts Windows web applications into to Web SSO applications
Documented Support for SharePoint and Exchange **
Support for many Server 2016 and Office 2016 products on the roadmap.
Easy Installation and Configuration***
As a refresher, I want to review why we chose to deploy AD FS, and why we still have it in our environment. When we first deployed AD FS there were questions within the University about why we needed it since we already had Shibboleth. The short answer is, “because it provides the best compatibility with our applications, and the best documentation for the services that we most need to integrate.” Fleshing that out a bit more…
When you consider the ease of deployment and potential benefits that ADFS brings to your organization, the product feels like a gift. It enables almost all web applications to participate securely, and mostly understandably, with a greater Web SSO infrastructure… not just within your organization, but potentially with people in the larger InCommon federation.
Installation really is easy, at least compared to earlier generations of Web SSO technologies. When we first deployed Shibboleth our organization, we had a room full of Sys Admins working for over a week straight to get even the most basic functionality for one web application. With AD FS, a skilled sys admin could get basic service up and running on her own in less than a week.
When used with a Web Application Proxy, ADFS opens the possibility of converting legacy Integrated Windows Authentication apps into Federated apps, without any change to your existing application code.
*You can get many Office 365 applications to authenticate against Shibboleth directly, but for best compatibility and support, use of ADFS is recommended. Not all Office client components have native support for open-standards SAML authentication at this time.
** Not all documentation is created equal, as we shall see later in this presentation.
***For a given value of “Easy”. Easy for infrastructure-critical, Internet-facing authentication and authorization services.

8. AD FS – Microsoft’s Gift Horse
Documentation? We Don’t Need No Stinking Documentation!
Claims transformation language for Shibboleth Integration:
Claims Transformation (ePPN to UPN) [LINK]
Claims Augmentation (when you need AD-only user or groups data)
“Won’t you step into my parlor?” said the spider to the fly…
New challenges in tracing login problems though a spider’s web of redirects. [Link]
Documentation:
The process of transforming MACE URNs to Microsoft Claims is, by necessity, marginally documented. Shibboleth does not mandate the use of any particular claims for user identity, so the transformations that you need to perform will almost always be site-specific.
Claims augmentation will be necessary if you ever need your users to prove their group membership, at least in cases where the claim needs to contain a group SID, of if the groups exist only in Active Directory (i.e. groups are not replicated using something spiffy like “Grouper”.
Tracing/Debugging:
Make friends with your Shibboleth team now, and better get used to debug logging in AD FS, and well-acquainted with “Fiddler”

9. AD FS Configuration Woes (updated):
AD FS Installation
Group Managed Service Accounts – DC container requirements
Load Balancer monitoring – Loosely documented health monitoring options
The truth about Web Application Proxies
If you want to proxy anything, you must proxy everything. [LINK]
Two-Farm Configuration may be required!
Certificate Pains
Friends don’t let friends use Signing and Encryption Certificate automatic rollover.
Service Communications Certificate – undocumented replacement quirks.
Install:
- gMSA accounts may be the wave of the future, but you need to get with the past to use them. Before you try to configure a gMSA, make sure that all of your domain controllers are in the default DC OU, or installation will fail! This will manifest in your DC event logs as startup failures of the “Key Management Service”.
Load Balancing – As of the August 2014 update to Server 2012 R2, both ADFS and the WAP serve up a healthcheck page on HTTP port 80 for the benefit of your hardware load balancers that do not support SNI. If you use this, be aware that your load balancer will not be aware of SSL errors that may crop up on your actual service interfaces. How do I know about this? Don’t ask. F5 offers an alternate configuration that uses an external, SNI-aware BASH script to monitor the health of your ADFS servers. I could not get this script to work.
WAP:
WAP does not support a split namespace. You can’t have ADFS accessed directly for some pre-authenticated applications, and still use the proxy for select web applications. Why would you want to do that? Maybe you wanted to use the WAP for protocol transitioning for legacy IWA app, but you are not ready to scale your WAP up to handle all traffic, or maybe you don’t feel that you don’t want to add the complexity of a WAP to all of your federated apps.
You can work around this problem by deploying two ADFS farms in separate namespaces. One farm will have a WAP, and the other will not. Perhaps it even is possible to establish a trust between these farms to hide the namespaces (I have not tested this).
Certificate Pains:
- MS docs recommend use of automatic certificate rollover, under the assumption that your relying parties and associated claims providers will see the advertised “next certificate” in your published metadata. In fact, most ADFS partners will not do this, not even SharePoint and Exchange. Further, the simultaneous publishing of multiple signing certificates will confuse Shibboleth, most likely resulting in failed logins. So What to Do?
- Instead create self-signed certs with as long a validity date as you believe to be safe, and put calendar reminders out for 5-10 people in your organization so that at least one person will get a heads up before your infrastructure goes belly up. Maybe the ADFS management pack for OpsMgr can keep track of this?
- With Service Communications certificates, note that if you are using the MS Health Check URLs to monitor ADFS health on port 80, your LB will happily continue to route users to an ADFS server that is experiencing SSL failures. This can happen if your ADFS server is presenting expired certificates to your users! When you replace your public-facing certificates, first update the cert in the MMC, and then run “Set-AdfsSslCertificate” on each server in the farm to fix the HTTP.SYS bindings, otherwise only some of your ADFS farm nodes will work with SSL!

10. The Trouble with SharePoint:
[Forward to SAML]
The Trouble with SharePoint:
Windows Integrated Authentication Problems
Poor Credential Hygiene
DOMAIN\username or authentication requirements are confusing to users.
NTLMv2 not supported on Mac/Linux clients
NTLM is deprecated on or removed from all platforms
The only other alternative, Kerberos, is not available for Internet clients (YMMV)

11. First Challenge: Convert SharePoint 2013 to Shibboleth Auth (part 1)
Configure a Relying Party trust in AD FS
Note that the RP uses a WS-Federation endpoint
Export the AD FS Token Signing Certificate
Take note of the expiration date. SharePoint will not auto-update from Federation Metadata!
Import the Certificate into SharePoint using PowerShell
If using self-signed certs, only one import is required.
Convert Windows apps to Claims Apps
Map incoming claims to SharePoint display names
Create a SharePoint “Identity Provider”
Specify ‘UPN’ as the Identifier Claim
Note… while your SAML token can contain SID data, SharePoint will not persist this data internally (loss of SID as an identity anchor)
As noted before, you need to import the ADFS token signing certificates manually. SHarePOint will not update new certificates from the ADFS published metadata.
4. The documentation does not address the various usage scenarios that will not work if you use only ADFS for authentication. For example, SharePoint Search Services will not function if Integrated Windows Authentication is not available. The solution for this is to create an “AAM” for administrative use, and for any other applications that need to log on using IWA.

12. First Challenge: Convert SharePoint 2013 to Shibboleth Auth (part 2)
Configure the Web Application to use the Identity Provider
Set up a second “zone” for Claims Authentication with AD FS. Configure an Alternate Access Mapping to your public SharePoint URL.
Configure the “default” zone to use Claims with Integrated Windows Authentication, and NTLM
Add a Custom Claims Provider to enable user and group lookup in the People Picker (LDAPCP)
Migrate Windows users to external Identity Provider users (PoSH) – Migrate-SPUsers.PS1, saved with this presentation.
This is a simply matter to substituting the UPN claim object that the docs have you create for the claims object.
Configuring the LDAPCP is beyond the scope of this discussion. Mainly because I did not document it very well and I am too embarrassed to admit it.
The script that I use, which is not overly beautiful, will be made available in the same directory as this presentation. The script uses the Move-SPUser cmdlet to convert existing IWA Users to Claims Users. The script also converts AD Groups to Claims Roles. It runs in two modes… “Document”, which generates a CSV of migrations to perform, and “convert”, which carries out the plan in the CSV.

13. [Back to NTLM]
The New Badness:

14. So what’s wrong with that?
Complexity!
Must maintain alternate access mapping for Windows Auth, with its own certificates. (This is not as easy as it sounds. )
Must maintain “Custom Claims Provider” (C#) (Or your People Picker will break)
Loss of SID data makes user renames difficult, account collisions possible.
MS support for non-ADFS SAML Authentication is “Fringe”.
May needed to set X-UA-Compatibility header SSO Portal [LINK]
Challenging to diagnose and repair.
…but your users won’t care about any of that!

15. SharePoint Federation - Alternatives
AD FS authentication only, without Shibboleth [LINK]
Only decreases logon process complexity, Web App is just a messy.
Loses ability to authenticate InCommon members.
Does not adhere to “single logon portal” ideal.
“Traditional” web application with Windows Authentication, placed behind a WAP with Kerberos protocol transitioning. [LINK]
Loses ability to authenticate non-domain users.
Deprecated configuration
What about Claims with Windows Auth behind a WAP? [LINK]
Still loses ability to authenticate non-domain users, but supported!
Easy to Implement? Just “follow the directions”.

16. The Trouble with Exchange
MAPI/HTTP, OWA, ECP, ActiveSync, EWS, Outlook Anywhere
Traditionally all support only “Windows Integrated Authentication”, Forms, or Basic Authentication over SSL.
ISO Assertion:
“All web applications should use the institution’s Web Single Sign-On Service.”
Registrar’s Assertion:
Sign-On to the student portal (Luminis) needs to provide SSO access to Exchange OWA.
Protocol problems:
Hey Greg, didn’t you just tell use that legacy protocol were a bad thing and need to go away?
Yes, but that was SharePoint, which is a different beast.
With Exchange, all clients that need to support NTLM auth already do, and for everything else we can use “basic” or “forms”.
ISO Assertion
– While we understand why unified SSO is a good thing, we also have to acknowledge that Exchange is not just another web application. It is an infrastructure service with deep access to Active Directory. If hackers get into our Exchange servers, we will have worse problems that password capture. Additionally, at this time we can only provide Web SSO for OWA and ECP. The remaining protocols will still use Basic or NTLM auth.
Registrar:
- Only alternative to AD FS is to allow “password capture” by Luminis. Unlike with Exchange, Luminis is not an “infrastructure” component. We do not want to allow it to handle raw student credentials, and so we cannot write off this demand as easily.

17. Second Challenge: Exchange 2013 with Shibboleth
Upgrade Exchange to 2013 SP1
Create a Relying Party trust for OWA and ECP
Note: It’s still WS-Federation
In a multiple-namespace environment, update the federation endpoint and identifier values
Configure Claims Transformation Rules
Adjust UPN claim transformation rules to use UPN from any source. [LINK]
Remove groupSID claim from tokens issued to Exchange. (No longer required in 2013 CU9+)
Configure ALL OWA and ECP Virtual Directories to use AD FS Auth
Disable Forms and Basic Auth. Yes, really.
IISReset ALL mailbox and CAS servers.
Disable EcpCafeLogon Health Checks
(To be removed “in a future release”*)
Official support for ADFS Authentication is introduced with SP1. Prior to SP1, most people used WAP publishing
3. This step only applies if you are not using a unified Exchange namespace (ie. All services such as OWA and ECP under one name). With multiple namespaces you need to add the URLs for all Endpoints that will be used, as well as matching identifiers. This is required because users might access the ECP though an OWA proxy, and if you only had one registered endpoint, ADFS would refuse to validate the connections.
4b. No official KB on this, but quoting our support engineer: “So the ADFS rule regrding sending AD group memberships, as you can see this was a requirement, but post CU9 it’s no longer required as it was causing issues in previous cases when users were members of a large number of groups (greater than 1000 or 1500 I believe).  They addressed this issue in CU9 and it is no longer required to this group information.“
5. Configuring all IIS Virtual Directories is a requirement because of the proxy/redirect logic used in Exchange. If you don’t do the reset, the directories may not be working with current configuration, and you may see server redirect behavior where you wanted a proxy, and authentication will be inconsistent.
6. After setting up ADFS, Exchange health monitoring went sour. The “EcpCafeLogonProbe” started failing, with errors rolling up to the general ECP health set. You need to override this monitor and probe using PowerShell. I have found best success by setting the override for the current version of Exchange, although our engineer said we could set the override to a “future release” and the override would apply to app previous versions as well. This was not my experience. No KB available here, either, but I quote: “I got on a conference call with a few other internal engineers and from our collaboration and research it seems that this probe here has/will be retired completely,which essentially means that ultimately it will most likely be pulled from the code completely.  We did find some fairly recent internal documentation from the product group that states this probe has been retired. ”
* We have not yet determined if this probe has been removed from Exchange It is still present in Exchange 2013 CU10.
PS> Add-GlobalMonitoringOverride -Identity ecp\EacCtpProbe –ItemType Probe -PropertyName Enabled -PropertyValue 0 –ApplyVersion " "
PS> Add-GlobalMonitoringOverride -Identity ecp\EacCtpMonitor -ItemType Monitor -PropertyName Enabled -PropertyValue 0 –ApplyVersion " "

18. The New Badness:

19. So what’s the problem? Annoyances: Solutions: Logon delays
Logoff errors
No support for Outlook Anywhere, MAPI/HTTP*, ActiveSync**
Solutions:
Go with the flow.
Get friendly with your Shibboleth Admin.
Outlook Anywhere (RPC over HTTP) is a legacy protocol. It can be retired when Outlook 2007/2010 are no longer in your environment.
*MAPI over HTTP scheduled to support ADAL in Exchange No documentation available at this time.
**ActiveSync pre-authentication with WAP/ADFS supported with Windows 2016 WAP/ADFS.
Alternative is to “go traditional” with Forms auth. This presents challenges with third-party integrations. At UVM, our “Luminis” student portal is used for webmail access. If Federated SSO is not available, the portal has to be configured to capture passwords and proxy access to OWA. But we don’t trust the security of Luminis, so this is a non-starter. Pity Oauth is not more widely available.

20. Future Challenges: New Integration Points:
Microsoft Passport sign-on
RDWeb and RDGateway Integration:
Publishing of RDGateway now possible when using AD FS with a WAP
VMware Horizon View:
Provides “Identity Manager” as a SAML authenticator for View clients
Allegedly integrates with AD FS or other SAML 2.0 IdP.
Proxy authentication for “legacy” web applications
Element IT – HTTP Commander
Captaris – RightFax
EMC – ApplicationXtender
Kronos – Workforce Central
Multifactor Authentication everywhere!
Duo Security, Azure MFA, and the promise of U2F
***RDGateway publishing requires August 2014 update to Server 2012 R2 WAP role.
****On the roadmap for Server 2016

21. So which was it?
I am sure we all feel at the mercy of our organizations at times. Some days we enforce policy without enthusiasm, because the cost of fighting it is too high. Sometimes you are the Borg.
But other days, we use the talents and skills granted to us to build a better organization. We do the hard job of analyzing the technology stack, making informed choices, and advocating for the right balance of security, complexity, and usability. Some days you are Jean-Luc.
Federation Services and Web Single Sign-On can seem daunting, and it is. For some sites, I have no doubt that at this time, AD FS is a poor fit. But for many, it is a powerful tool that can solve many solutions. Decide for yourself how to do the right thing.

22. AND THE ADVENTURE CONTINUES…
Follow up questions to:
mailto:
LinkedIn: j-greg-mackinnon
Facebook: j.greg.mackinnon
And more fun at:
More adventures next year. Live Long and Prosper!

23. References:
Surviving the Triangle – Shibboleth, AD FS, and Office 365 Pro Plus at UVM:
Microsoft Passport:
Publishing Microsoft applications to the Web Application Proxy:
Next-gen Web Application Proxy roadmap: proxy.aspx
SharePoint 2013 (both Claims with IWA and legacy IWA), Exchange 2013, and RDGateway
AD FS / SharePoint Interop documents:
Microsoft Guide to ADFS 2.0 / Shibboleth interop:
InCommon Federation ADFS / Shibboleth interop:
Shibboleth Service Logout:

24. References (continued)
AD FS Hardware Load Balancing:
Microsoft Blog documenting new health check features in ADFS/WAP update from August 2014: fs-2012-r2.aspx
F5 DevCentral Article on configuring an F5 LTM to work with AD FS on 2012 R2, including external script-based health monitor:
Exchange 2013 with AD FS:
Official Documentation:
SharePoint 2013 with AD FS:
Official Microsoft Guidance:
SharePoint 2010 integration with Shibboleth, replaced by AD FS-based turnkey solution for SharePoint (provided as example of the utility of ADFS for MS Apps… even ISVs are using ADFS to bridge to Shibboleth):
Blog: UVM’s SharePoint/ADFS/Shibboleth Integration – 2013 Edition
Blog: UVM’s script for migrating Windows users to Claims users:
General article on the X-UA-Compibility header, to be used in your non-ADFS logon portal:

25. Follow that Cookie! Adventures in Redirection
[Back]
Follow that Cookie! Adventures in Redirection

26. Web Application Proxy: All or Nothing
[Back]
Web Application Proxy: All or Nothing
I don’t know why this does not work. It just doesn’t. And if you call MS to ask why, they tell you something like “because it isn’t supported”.

27. SharePoint Authentication: AD FS Without Shibboleth
[Back]
SharePoint Authentication: AD FS Without Shibboleth

28. SharePoint Authentication: IWA With Web App Proxy
[Back]
SharePoint Authentication: IWA With Web App Proxy

29. [Back]
SharePoint Authentication: Claims (in Windows Auth mode), With Web App Proxy

30. Claims Transformations from Shibboleth:
ePPN to UPN conversion:
c:[Type == "urn:oid: "] => issue(Type = " Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);
Rules to be added to incoming claims from the Claims Provider trust configuration on ADFS, pointing to Shibboleth
[Back]

31. Claims Transformations for Exchange 2013:
From:
c:[Type == " Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = (" query = ";userPrincipalName;{0}", param = c. Value);
To:
Documentation instructs you to set up a claim transformation rule that searches tokens for claims of type “windowsAccountName”, but only when it is issued by an Active Directory source. The rule then queries AD for the userPrincipalName attribute, and issues this as a UPN claim.
But why do that? First, you probably will have the UPN claim in your default incoming tokens, so just use that attribute. Second, you have to remove the “Issuer” check, since in a Shibboleth-integrated environment, your tokens are not going to originate from AD.
Of course, this passthough rule does raise the risk that someone outside your institution could spoof an internal UPN in a federated logon, so maybe some caution is in order.
To:
c:[Type == "
=> issue(claim = c);
[Back]

32. X-UA-Compatibility: On assigning values to the header:
Designating 'IE=edge' is the best practice because it ensures Internet Explorer uses the latest engine. The most current Internet Explorer version includes the latest security updates as well as feature support. The current version is also the fastest version.
On how to implement the header:
The best practice is an X-UA-Compatible HTTP Header. Adding the directive to the response header tells Internet Explorer what engine to use before parsing content begins. This must be configured in the web site's server.
Not only is the HTTP Header method the best practice, it is the only practice that will be respected by Office 2013 clients attempting to use any non-ADFS logon portal.
[Back]

33. Opening Question:
Which are you?