Surviving the Triangle - Windows in Higher Education

Surviving the Triangle:
Shibboleth, ADFS, Office 365
An Adventure Story of
the High Seas by:
J. Greg Mackinnon
Systems Architect
Not a Ship Captain
Enterprise Technology
University of Vermont
• “Fun Parts” Edition (FUN = PAIN x TIME):
• Design an AD FS / Shibboleth / Office 365 solution for our school.
• Deploy of Active Directory Federation Services on Windows Server 2012 R2
(“ADFS 3.0”)
• Integrate AD FS with existing Shibboleth 2 IdP
• Sync on-premises Active Directory to Azure AD/Office 365 using
The Windows Azure Active Directory Sync Tool (DirSync)*
• Provision users with Office 365 services using PowerShell using
The Microsoft Azure Active Directory Module for Windows PowerShell
(formerly “Microsoft Online Services Module for Windows PowerShell”.)
• Simplify access to Office 365 using Smart Links
• Overcome presentation boredom though exciting narrative tools.
• Familiarity with concepts behind:
Federated SSO
Office 365 / Azure AD
Claims Authentication
Act 1: The Gathering Storm
Scene 1: A Gift Horse is Presented
• Spring 2014: The Student Advantage program is announced:
Free Office software for all students at institutions with Office site
licenses for faculty and staff. Three cheers for Microsoft!
Scene 2: The Gift Becomes a Task
• Provision Office 365 Pro Plus to 14,000+ active students
• Do not provision services to faculty/staff
• Make it work with the existing UVM Web Single Sign-On system.
• Do not disclose any information other than Name, NetID, and active
student status to Microsoft. For students requesting additional
privacy protection under FERPA, do not even disclose Name.
• Do it all before students get back on campus.
• Your budget is $0.
Scene 3: Backstory Time!
[The Slides you Hate]
• University of Vermont:
• Land grant school founded by Ira Allen “a long time ago”.
• Over 1,300 faculty, perhaps 2,200 staff
• [MORE BORING NUMBERS NUMBERS] 14 thousand something students
• Enterprise Technology Services
• Central IT Services for the institution, 60+ employees, about half of all IT pros
on campus.
• Systems Architecture and Administration
• 9 System Admins
• 3 Windows guys
• We do it all, with probably the lowest support ratios of any peer institutions
Scene 3 (Continued): The Cast of Characters
Our plucky IT Hero:
The dastardly villains:
The mysterious benefactor:
The ship’s crew:
Colorful Characters:
Scene 4:
Core Technologies Debated
• BOSS: UVM web services will use a single web SSO solution. (WebAuth)
• The Boss notes the MS supports Shibboleth as an Identity Provider for Office 365:
• But Boss, read the fine print… Office 365 ProPlus licensing is not supported with Shibboleth
as the primary identity provider!
• IT Hero: AD FS already is in pre-production for a SharePoint 2013 upgrade project.
Let’s do interop!
• AD FS provides the broadest client support (at present).
• AD FS lets “Microsoft be Microsoft”. (Support for WS-Federation “active authentication
scenarios” in addition to SAML 1 and 2)
• Supports Windows Authentication (allows single sign-on from the Windows desktop)
• Added benefit of the Web Application Proxy service, which can aid with NTLM remediation.
Scene 4 (continued): The Best Laid Plans…
• A service architecture is developed
• An authentication workflow is mapped
Service Architecture: Work To Do
Federated SSO: The Whole Ugly Truth
Scene 5: A Likely Conversation
• IT Hero:
‘Hey Boss… this whole Federated SSO thing is really complicated.
Have you seen this diagram of the planned authentication workflow?’
• Boss:
‘Yeah… What’s your point? That’s what we do.’
• (But is SCALE x COMPLEXITY > SKILL ? Let’s find out!)
Act 2: The Adventure Begins
Scene 1: Our Heroes Tackle an Easy Task
(AD FS production deployment):
• For HA deployments, have a SQL
Server ready
• Install the AD FS role (2+ Servers):
• Configure the role (2+ Servers):
• Install and configure the Web Application Proxy Role
Scene 1 (continued) [FX: queue thunder clap]:
Load Balancing AD FS
• Use F5 Load Balancer in “Direct Server Return”, or “nPath Routing”
mode. [LINK]
• F5 monitor for HTTPS services on ADFS servers fails!
• ADFS 3.0 runs in HTTP.SYS: Requires SNI. OpenSSL 0.98 libraries on
F5 do not support SNI. [LINK]
• Use NETSH to add additional http.sys binding for “legacy” clients.
This will be helpful with Shibboleth interoperability as well. [LINK]
Scene 2: The Crew Conquers AD FS / Shibboleth
Interoperability, With a Little Help From Friends.
• Get the whitepaper:
• Back to school: A Claims Interoperability Primer… [LINK]
• Setup Claims Provider Trust in AD FS:
• Reduce token signing requirement to SHA1 (default is SHA256) [LINK]
• Must use NETSH to allow ADFS to accept non-SNI connections.
(Java SSL libraries used in our Shibboleth deployment do not support SNI.)
• Setup Relying Party Trust in Shibboleth:
• Import token signing certificate into Shibboleth
• Play with XML configuration files (Note OID of released attributes) [LINK]
Scene 2 (continued):
Beyond the Whitepaper
• ADFS now generates tokens based
on Shib tokens, but how do I get
useful AD data into the token?
• A knowledgeable old salt stops in to
explain Claims Transformation
Language. [LINK]
• The Divine Secrets of Claims
Transformation Language allows
Microsoft applications natively to
consume claims generated by
Scene 3: A Foray Under the Storm Clouds
• Setup an Office 365 Tenant [LINK]
• Select “Office 365 Education E3 for Students Trial”, and then add “E1” licenses to your Tenant.
• Plan for UPN-based authentication:
Does AD UPN match the Shibboleth ePPN?
Does the AD UPN match a domain configured in Office 365?
• Enroll for the Student Advantage Program*
Get your EES program administrator to accept $0 Purchase Order
Contact Microsoft Sales to assign Student Advantage licenses to your tenant.
Request more licenses
Request even more licenses
• Install and Configure DirSync [LINK]
• Create Office 365 sync account (* recommended)
• Create AD sync account
Apply ACLs to satisfy UVM legal privacy requirements
• Configure attribute filtering
• Apply PowerShell-Foo to assign licenses to students. [LINK]
Scene 4: A Plan Comes Together
• Hero: “It all works! Hurray, time to take vacation!”
• Boss: “This user experience is unacceptable! Fix it!” [LINK]
• Create Smart Links to make it all invisible:
BUT is this really simpler?
Federated SSO: “Simplified” with Smart Links
Scene 5: Students Invade Campus,
and Our Hero Takes a Vacation
• The Client Services team prepares
“Go: Get Office” materials for
residence halls and for students
picking up new computers.
• 1,256 downloads in the first month.
(First-time student count is
approximately ~2,450)
• Zero Complaints
(Or if there were, they were not
heard from the Outer Banks, NC.)
Full of sound and fury, signifying nothing.
• September 15th, 2014:
Microsoft Releases “Azure Active Directory Sync Services”, obsoleting
DirSync only three weeks after UVM go-live.
• September 20th, 2014:
Microsoft ‘enhances’ the Student Advantage program with emailaddress-based opt-out self-enrollment.
• October 1st, 2014:
Rumors arise that Office 365 Pro Plus will be made available to all
Faculty and Staff for EES customers with coverage for Office software.
Full of sound and fury, signifying nothing something.
Unified SSO Achieved
Cloud Ready
Follow up questions to:
mailto: [email protected]
Twitter: @jgregmac
Facebook: j.greg.mackinnon
Ello: @jgreg
And more fun at:
• F5 Guide to Layer 4 nPath Routing (Direct Server Return):
• General guidance from F5:
• Specific directions for configuring Loopback on Server 2008+
• AD FS:
• Windows Server 2012 R2 AD FS Deployment Guide:
• Step-by-Step Guide: Federation with Shibboleth 2 and the InCommon Federation:
• HTTP.SYS Binding and SNI at UVM (SharePoint Configuration Entry):
• User Alternate Login IDs with ADFS and Office 365:
Resources (continued…):
• Claim Rule Language References:
“Understanding Claim Rule Language” [HA!]:
Regular Expressions in Claim Rule Language:
Attribute Stores and Queries: The Ugly Internals:
AD FS Claims Rule Language Deep Dive (with Win-HiEd favorite Laura Hunter!):
UVM Transformations for Sharepoint 2013:
• DirSync:
Setup of Directory Sync computer:
Release History (Useful for determining if you have the current release):
Deploy “Directory Sync with Single Sign-On” scenario for Office 365:
Handling the “Replicating Directory Changes” permission:
Resources (continued…)
• Azure AD Module for PowerShell:
• Download: Always get the latest version!
• Provisioning students with O365 ProPlus using PowerShell at UVM:
• Microsoft Azure Active Directory Sync Services
(DirSync, the next generation):
• Microsoft guide to creating Smart Links:
nPath Routing (Direct Server Return):
• The Load Balancer forwards the entire Layer 4 TCP
packet to the back-end server.
• Reduces load on the expensive F5
• Reduces complexity of the configuration:
• Only on SSL certificate needed.
• No complex SSL termination and reencapsulation at the load balancer.
• Kerberos-compatible.
• Each back-end server has the IP address for the
cluster assigned to a “loopback” adapter with a 28bit netmask. Each back-end “thinks” it has the
cluster IP.
• The back-end server forwards the incoming packet
from its public interface to the loopback interface.
• The back-end server replies directly to the client.
HTTP.SYS Binding (1 of 2)
• Modern browsers (and SSL Libraries) support the SNI, or “server_name” extension.
• Older Java runtimes (1.6), OpenSSL libraries (0.98), and IE6 do not support SNI.
HTTP.SYS Binding (2 of 2)
• On each ADFS server and proxy, open an elevated command prompt
• Run>
netsh http show sslcert
Certificate Hash
: aBunchOfRandomLookingNumbers
Application ID
: {yet-another-ugly-product-guid}
Certificate Store Name
: MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
• Record the certificate hash and application ID for the certificate used by
• Run>
netsh http add sslcert ipport=
certhash=aBunchOfRandomLookingNumbers appid={yet-anotherugly-product-guid}
A Claims Interoperability Primer:
• Guidance available from Microsoft!
• Claims Authentication:
• An Internet-friendly, token-based authentication system.
• SAML 1, SAML 2, and WS-Federation
• Security Token Service (STS):
• A service that generates claims tokens. (ADFS, Shibboleth)
• In Shibboleth terms, an Identity Provider (IdP)
• Claim (ADFS) = Attribute (Shib2) = Assertion (Shib1)
• Relying Party (RP) = Service Provider (SP)
• Claim Provider Trust:
• A back-end source of user data (AD, LDAP, SQL, or other SAML provider)
• AD FS 2 and Shibboleth 2 are both SAML 2 token providers
• Different Claim Description formats hamper interoperability. [BACK]
AD FS Claims Provider Trust Configuration
• You may need to set the ‘secure hash
algorithm’ to “SHA-1”:
• Transform Shibboleth/InCommon
“attributes” into “claims” that more
easily can be used by Microsoft
Shibboleth Relying Party Trust Configuration
Relying Parties to the IdP are defined in a file (i.e. relying-party.xml):
With AD FS 2+, you will need to import your ADFS token signing certificate into the IdP config:
Get the token signing cert from the AD FS console:
• View the certificate
• Export in Base64 (PEM) format
Shibboleth RP Configuration (continued)
Attribute release rules are controlled in an “Attribute Filters” file (i.e. attribute-filters.xml).
Attributes to be released generally are grouped into policies. (i.e. uvm-common)
Displayed attributeID values are friendly names for the attributes, as defined in a resolver file (attribute-resolver.xml):
Note both old (and sane) SAML1 names, and new (incomprehensible) SAML2 names. [BACK]
Divine Secrets of the
Claims Transformation Language (1 of 3)
• Hard task: Convert Shib attribute “ePPN” to ADFS “UPN”
c:[Type == "urn:oid:"]
=> issue(Type =
upn", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer,
Value = c.Value, ValueType = c.ValueType);
Divine Secrets of the
Claims Transformation Language (2 of 3)
• Difficult task:
Convert ePPN domain suffix to match the AD UPN suffix:
c:[Type == "urn:oid:”, Value =~
=> issue(Type =
", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer,
Value = regexreplace(c.Value, "^(?<user>[^@]+)@(.+)$",
"[email protected]"), ValueType = c.ValueType);
Divine Secrets of the
Claims Transformation Language (3 of 3)
• Seemingly Impossible Task:
Augment incoming Shib claims with user attributes from AD:
(Used for an on-premise SharePoint project)
c:[Type == "urn:oid:”, Value =~ "@uvm\.edu$”]
issue(store = "Active Directory", types =
query = “samAccountName{0};tokenGroups;CAMPUS\foo", param =
regexreplace(c.Value, "^(?<user>.+)$", "${user}"));
Setup a new Office 365 Tenant
• Domain considerations:
• Does O365 Domain must match the user’s ePPN/UPN suffix?
(I.e. Will the UPN [email protected] be used to login to the O365 domain
• If no, plan on:
• Transforming the UPN suffix in the relying party trust with Office 365 (maybe?) -or• Changing the UPN suffix for your AD users -or• Using the supported Alternate Login ID method (see references)
• Configure the domain for SSO using PowerShell:
• Set-MsolAdfscontext -Computer <AD FS primary server>
• Convert-MsolDomainToFederated –DomainName <domain>
Configuring DirSync for Filtered Replication:
• Dedicate a Windows Server OS:
• Must use SQL Server Standard/Enterprise if >50,000 objects will be synchronized.
• Installer will create an “MSOL_*” user account in your forest root domain:
• Documentation claims the name will be “AAD_*”.
• Assumption: MSOL account will not be able to read FERPA-protected data,
because it is not in a group that can read this info.
• Fact: The MSOL account syncs FERPA data anyway. WHY??!?!
• MSOL is a powerful account with “Replicating Directory Changes” rights:
This right will need to be removed if you need to filter user
attributes (regulatory compliance/privacy concerns).
OR, just create a new service account for DirSync (supported by
Configuring DirSync for Filtered Replication
• DirSync is FIM-based. Same user interface as seen in FIM and the
SharePoint User Profile Synchronization Tool.
• Launch from:
C:\Program Files\Windows Azure Active Directory
Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe
• FIM has a lot of filtering options, but for DirSync, support is limited to
filtering out whole domains, whole OUs, or to filtering entire accounts
based on a limited set of pre-defined attributes.
(e.g. extensionAttribute1)
Configuring DirSync for Filtered Replication
• Remove any explicit allow ACE that will allow non-privileged accounts
from reading FERPA-protected attributes. (Already Done!)
• Grant access to required rights using inherited ACLs
• Apply an inherited deny ACE that will block access non-exportable
user data.
Configuring DirSync for Filtered Replication
• DirSync will read
values into the “metaverse”
• Populate
extensionAttribute1 with
affiliation type data
• Configure the agent to send
only users with
extensionAttribute1 =
Provisioning Office 365 Users Using
• Requires “Microsoft Azure Active Directory Module for Windows
PowerShell” (make sure you have the latest build!)
• Azure-only accounts have password expiration:
Set a reminder to prevent provisioning failures.
• >Connect-MsolServices
• >Get-MsolUser -UnlicensedUsersOnly -Synchronized -All
• >Set-MsolUser -UsageLocation 'US'
• >Set-MsolUserLicense -AddLicenses
• See the blog entry for more details.
PowerShell Send-MailMessage
Provisioning report for Office 365/Azure AD for: 10/13/2014 10:15:01 PM
Office 365 ProPlus for Student - license report:
Total licenses: 18000
Consumed licenses: 15959
Remaining licenses: 2041
Retrieved active students from Active Directory.
Active student count: 15335
Retrieved unlicensed MSOL users.
Unlicensed user count: 4
Provisioning successfully completed at: 10/13/2014 10:15:22 PM
Provisioned 0 accounts.
Elapsed Time (hh:mm:ss): 0:0:21
Frank Oobarthsen’s Sign-In Experience, Take 1:
GOAL: Get to the login page, login successfully on the first try.
Frank Oobarthsen’s Sign-In Experience, Take 2:
Enables Frank to login successfully on the
first try.

similar documents