conversion from ADFS to Shibboleth for Office 365 ?

Michael O Holstein michael.holstein at csuohio.edu
Mon Nov 6 15:27:10 EST 2017


Talk to your Microsoft rep and ask for a test tennant. Call EDUCAUSE and setup a similar domain name to yours for it (eg: we are csuohio.edu in prod /// clevelandstate.edu for dev)


Add a domain controller to your forest, then remove it, then change the UPN to something like bloomuniversity.edu and do the customary ad-sync, adfs, etc. The how-to on this is easy to find.


We have 110k users in prod and 110k in test. Test costs nothing. They still honor your production support contract for test stuff.


I'm all for "move fast and break things" and "nope, we didn't .. did you try rebooting?" .. but I would not screw with SAML in a prod Azure tenant without having tested it .. twice.


But yes, your commands are right. I have a write-up on it from a year(ish) back that does step-by-step.


The gotchas:


The cert can't have newlines in it. Meaning cut/paste line by line into notepad to be safe.

The ECP is tricky to get working. It expects to return sourceAnchor which is a bin->base64 of the GUID, IIRC .. Shib does this natively but it's not well documented. I can give you the config snips if you want from a fairly basic setup.


Free advice? .. if you are buying O365 on an educational (E3?) schedule you probaby get free Azure credits ... just throw a pair of samba/openldap boxen up in there along with your cas/adfs/shib/whatever and load-balance it. It'll cost you like $100/mo and you don't have to deal with outages. You can use their NLB as long as you're willing to do a NS2 -> azure. You can do mix of on/off prem too, the GLSB/NLB has all softs of fancy probes. IDK what your contract has but we get something like $6k per quarter in Azure IaaS money. Bonus? : it's pre-configured to work with ADAL (yes, even Cas/Shib) so you can dole it out to students/compSci/devOps/whatever and the billing API you can suck right into Excel.


Also, and I realize this is sacrilege here .. but have you considered using CAS instead? .. O365 is native and so is Shib fed. Plus you get OAUTH, PAC4J, and other goodies.


Hit me off-list (you or anyone else) for more on any of this ...


Cheers,


Michael Holstein CISSP

Mgr. Network & Data Security

Cleveland State University

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Kozlek, Vincent <vkozlek at bloomu.edu>
Sent: Monday, November 6, 2017 2:15:59 PM
To: Shib Users
Subject: RE: conversion from ADFS to Shibboleth for Office 365 ?


No guarantee this will still work, but in the past (2013-2016) when I’ve had to make any changes to the federation config of an office365 domain, I typically had to temporarily change the domain auth back to office365 managed, then back to federated with the new settings.  The user auth outage in my experience is very short, but still nerve-racking.  I never had a problem in the past doing this and in fact it was the only way to effectively change federation config (i.e. even just changing the entityId or a URL).  Changing back to Office365 managed auth clears out all of the federation configuration in my experience, and then when you change back to federation, all the new values take effect.



Commands/timing from my notes…



Set-MSOLDomainAuthentication -Authentication Managed -DomainName office365.domainname.edu



<wait some time, typically just a couple minutes – actually hit the office365 login page (i.e. portal.office.com or outlook.com/office365.domainname.edu) and enter a [valid or fake] username in your domain, such as a at office365.domainname.edu<mailto:a at office365.domainname.edu>  to make sure office365 stops redirecting to a federated login page before running the next step>



Set the variables equal to the desired configuration…  i.e.

$dom = “office365.domainname.edu”

$url = “https://sso.domainname.edu/idp/profile/SAML2/POST/SSO”

$ecpUrl = “https://sso.domainname.edu/idp/profile/SAML2/SOAP/ECP”

$uri = “https://sso.domainname.edu/idp/shibboleth”

$logouturl = “https://sso.domainname.edu/idp/profile/Logout”

$cert = “<actual cert>”



Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $dom -Authentication Federated  -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -PreferredAuthenticationProtocol SAMLP



Not sure if any of those cmdlets have changed in the past year.  I last performed these steps on 10/5/16 and it always worked flawlessly to get federation values to successfully change and take effect.



If it’s not clear, while the domain is set to managed authentication, your users will be unable to authenticate.  For me it was such a short outage that I don’t even notify users and instead just perform the change at a low-usage time.



It is important to wait until the first command takes effect.  If you try setting it back to federation prematurely, it may not take effect correctly and you’ll have to set it back to Managed and wait for that to take effect prior to changing back to Federation a second time.



Good luck.  It’s amazing to me that Microsoft support is unable to instruct you on a method to handle this.  I guess I had to figure out my method on my own back in 2013.  I hope it still works for you.  You could always run it by support to see what they think.



From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Robert Rust
Sent: Monday, November 6, 2017 11:58 AM
To: users at shibboleth.net
Subject: conversion from ADFS to Shibboleth for Office 365 ?



Has anybody on the list moved from ADFS to Shibboleth authentication for Office 365?  I’m running into some headaches with one of the Office 365 federation attributes, specifically the MetadataExchangeURI.  All the docs and examples I’ve found indicate it should be left blank for Shibboleth, but I’m not finding a way to clear the value.  Working with MS, I managed to get it changed to a new value (that doesn’t work), but I haven’t been able to clear it.  So, I’m looking to see if anybody else has made this move and encountered similar issues.



-Robert

--

~~~~~~~~~~~~~~~~~~~~~~~~~

Robert J. Rust

Systems Administrator

Division of Technology Services

Univ. of Wisc. - River Falls

~~~~~~~~~~~~~~~~~~~~~~~~~

[ps://www2.uwrf.edu/static/images/email-wordmark.png]

*******   BE ALERT   *******

Technology Services will never ask you for your password, personal information, or to verify your account via e-mail.

If you receive a request for your password or personal information, delete immediately and do not reply.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171106/e4994724/attachment-0001.html>


More information about the users mailing list