Transcript Federating the Enterprise - Windows-Hied

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
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
Which are you?
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
The Environment:
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?
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***
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]
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.
[Forward to SAML]
The Trouble with
SharePoint:
• Windows Integrated
Authentication Problems
• Poor Credential Hygiene
• DOMAIN\username or
[email protected]
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)
First Challenge:
Convert SharePoint 2013 to Shibboleth Auth (part 1)
1. Configure a Relying Party trust in AD FS
a)
Note that the RP uses a WS-Federation endpoint
2. Export the AD FS Token Signing Certificate
a)
Take note of the expiration date. SharePoint will not auto-update from Federation
Metadata!
3. Import the Certificate into SharePoint using PowerShell
a)
If using self-signed certs, only one import is required.
4. Convert Windows apps to Claims Apps
5. Map incoming claims to SharePoint display names
6. Create a SharePoint “Identity Provider”
a) Specify ‘UPN’ as the Identifier Claim
b) Note… while your SAML token can contain SID data, SharePoint will not persist this data
internally (loss of SID as an identity anchor)
First Challenge:
Convert SharePoint 2013 to Shibboleth Auth (part 2)
6. Configure the Web Application to use the Identity
Provider
a) Set up a second “zone” for Claims Authentication with AD FS.
Configure an Alternate Access Mapping to your public
SharePoint URL.
b) Configure the “default” zone to use Claims with Integrated
Windows Authentication, and NTLM
7. Add a Custom Claims Provider to enable user and group
lookup in the People Picker (LDAPCP)
8. Migrate Windows users to external Identity Provider
users (PoSH) – Migrate-SPUsers.PS1, saved with this
presentation.
The New Badness:
[Back to
NTLM]
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!
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”.
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.
Second Challenge: Exchange 2013 with Shibboleth
1.
2.
3.
4.
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
a)
b)
5.
Configure ALL OWA and ECP Virtual Directories to use AD FS Auth
a)
b)
6.
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+)
Disable Forms and Basic Auth. Yes, really.
IISReset ALL mailbox and CAS servers.
Disable EcpCafeLogon Health Checks
(To be removed “in a future release”*)
PS> Add-GlobalMonitoringOverride -Identity ecp\EacCtpProbe –ItemType
Probe -PropertyName Enabled -PropertyValue 0 –ApplyVersion "15.0.1200.0"
PS> Add-GlobalMonitoringOverride -Identity ecp\EacCtpMonitor -ItemType
Monitor -PropertyName Enabled -PropertyValue 0 –ApplyVersion "15.0.1200.0"
The New Badness:
So what’s the problem?
• Annoyances:
• Logon delays
• Logoff errors
• No support for Outlook
Anywhere, MAPI/HTTP*,
ActiveSync**
• Solutions:
• Go with the flow.
• Get friendly with your
Shibboleth Admin.
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
So which was it?
AND THE
ADVENTURE
CONTINUES…
Follow up questions to:
mailto: [email protected]
Twitter: @jgregmac
LinkedIn: j-greg-mackinnon
Facebook: j.greg.mackinnon
Ello: @jgreg
And more fun at: http://blog.uvm.edu/jgm
References:
• Surviving the Triangle – Shibboleth, AD FS, and Office 365 Pro Plus at UVM:
http://www.windows-hied.org/Pages/Conference2014/conf2014-Surviving-the-Triangle.aspx
• Microsoft Passport:
https://technet.microsoft.com/en-us/library/mt219734(v=vs.85).aspx
• Publishing Microsoft applications to the Web Application Proxy:
• Next-gen Web Application Proxy roadmap:
http://blogs.technet.com/b/applicationproxyblog/archive/2014/10/01/introducing-the-next-version-of-web-applicationproxy.aspx
• SharePoint 2013 (both Claims with IWA and legacy IWA), Exchange 2013, and RDGateway
https://technet.microsoft.com/en-us/library/dn765486.aspx
• AD FS / SharePoint Interop documents:
• Microsoft Guide to ADFS 2.0 / Shibboleth interop:
https://technet.microsoft.com/en-us/library/gg317734(v=ws.10).aspx
• InCommon Federation ADFS / Shibboleth interop:
https://wiki.shibboleth.net/confluence/display/SHIB2/MicrosoftInterop#MicrosoftInterop-ADFSv3(2012r2)
• Shibboleth Service Logout:
• https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPServiceLogout
• https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSingleLogoutService
References (continued)
• AD FS Hardware Load Balancing:
•
•
Microsoft Blog documenting new health check features in ADFS/WAP update from August 2014:
http://blogs.technet.com/b/applicationproxyblog/archive/2014/10/17/hardware-load-balancer-health-checks-and-web-application-proxy-adfs-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:
https://devcentral.f5.com/articles/big-ip-and-adfs-part-5-working-with-adfs-30-and-sni
• Exchange 2013 with AD FS:
•
Official Documentation:
https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx
• SharePoint 2013 with AD FS:
•
•
•
•
•
Official Microsoft Guidance:
http://technet.microsoft.com/en-us/library/hh305235(v=office.15).aspx
SharePoint 2010 integration with Shibboleth, replaced by AD FS-based turnkey solution for SharePoint 2013
(provided as example of the utility of ADFS for MS Apps… even ISVs are using ADFS to bridge to Shibboleth):
http://www.9starinc.com/activesharefs-turnkey-solution-shibboleth-saml-based-access-to-sharepoint
Blog: UVM’s SharePoint/ADFS/Shibboleth Integration – 2013 Edition
http://blog.uvm.edu/jgm/2014/03/18/sharepoint-2013-adfs-shibboleth-the-motion-picture/
Blog: UVM’s script for migrating Windows users to Claims users:
http://blog.uvm.edu/jgm/2014/04/23/migrating-windows-auth-users-to-claims-users-in-sharepoint/
General article on the X-UA-Compibility header, to be used in your non-ADFS logon portal:
https://msdn.microsoft.com/en-us/library/ff955275%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
Adventures in Redirection
Follow that Cookie!
[Back]
All or Nothing
Web Application Proxy:
[Back]
AD FS Without Shibboleth
SharePoint Authentication:
[Back]
IWA With Web App Proxy
SharePoint Authentication:
[Back]
Claims (in Windows Auth mode),
With Web App Proxy
SharePoint Authentication:
[Back]
Claims Transformations from Shibboleth:
ePPN to UPN conversion:
c:[Type == "urn:oid:1.3.6.1.4.1.5923.1.1.1.6"]
=> issue(Type =
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer =
c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType =
c.ValueType);
[Back]
Claims Transformations for Exchange 2013:
From:
c:[Type ==
"http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types =
("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"),
query = ";userPrincipalName;{0}", param = c. Value);
To:
To:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(claim = c);
[Back]
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.
[Back]
Opening Question:
• Which are you?