Setting up office 365 federation when MFA is enabled
04-02-2017 11:30 PM
I am currently using Centrify cloud identity service and want to try using it to authenticate users into Office 365. Firstly I want to say the centrify documentation on this seems to be horribly one sided - it assumes you have an on prem AD to sync with, and also that you're using exchange online for for email. Neither of these situations apply to me - I am using purely Centrify cloud directory for my primary user store, and I am using office 365 only for the office apps, not for email, skype or anything else.
I tried to add the centify app for office 365(WS Fed) to see if I could get it working through trial and error, but I am not getting past the first step : the setup requires you to enter the username and password for the office 365 admin account. I cannot get past this step because my office 365 account has MFA enabled and I am guessing that the centrify app does not know how to deal with this.
So, has anyone got a cloud only directory working as an IDP for Office 365 where MFA is required? And/or has anyone got it working where office 365 is just for apps and not email?
Solved! Go to Solution.
04-03-2017 01:12 PM
Hello @Cory and welcome back to the Centify Community!
It sounds like you may need to use an App Specific password to authenticateyour Admin account for the token used to connect the Centrify app to your tenant in Azure Active directory.
Once you have connected, the remaining Centrify documentation regarding usernames, etc is relevant since the User will be logging in using a Federated account. (If you plan to use Centrify to manage which and when MFA mechanisms are used.).
In any event, once you have the Admin account connected, next you can proceed through the docs to Federate the domain that your User's log in to Office with, and this will redirect them to the Centrify portal for authentication.
Please let us know if you need more information. A good starting point is this kb, paying specific attention to the username matching and role mapping sections.
I hope this helps.
Please let me know if you need any more assistance.
Have a great day!
04-03-2017 08:40 PM
I tried creating an app specific password but it still doesn't work, I am getting the following error when I try to verify the admin account:
Centrify.Cloud.Core.UIException: Failed to connect to Office 365. Failed to get securityToken. Please check username and password. at Centrify.Saas.Office365V2.Utilities.GetProvisioningClient2(String adminUser, String adminPassword) at Centrify.Saas.Office365V2.O365Helper.GetLicenseProfiles(String adminUser, String adminPassword) at Centrify.Cloud.Saas.Provisioning.o365.UserSync.O365Context..ctor(o365CredsSchemaReader creds, DataEntity app) in c:\Perforce.Production\Production\Saas\Provisioning\office365v2\o365.UserSync\o365Context.cs:line 46
I tried with multiple app passwords and double checked the user name, it just doesn't work.
I read through the link you provided but again, it is focused on connecting to an on prem AD, most of the content is irrelevant in the O365 or AzureAD context.
04-04-2017 11:43 AM
Hi @Cory and thank you for the reply.
I just tested as well, and see the same issue (for my Admin user with MFA on the Office 365 side enabled.) I have filed an internal RFE to allow for App Password to be used if the Admin has MFA enabled in the Office 365 Admin portal.
In the interim, it looks like we need to first disable, and allow the oAUTH token to be fetched and used from the Office 365 app in the Centrify Admin portal .
Once this is complete, you can re-enable MFA (*although I would instead create a new Global Admin in Office 365 Admin portal without MFA called something like, "CentrifySyncServiceAccountAdminUser@yourOnmicrosoftAlias.com" and make a very long, un-guessable password that does not change, instead.) Either way, once completed, this Admin account should never be modified or touched again in the Centrify portal as well as in the Office 365 portal moving forward.
The KB provided is very lengthy, and mostly concerned with using Centrify for mailbox access, however the same principals are used for authenticating the User into Office 365 /Azure Active Directory)...meaning the User will authenticate using Centrify once the domain is Federated.
First, you will want to make sure the Centrify User login name matches the username for Office 365.
Licenses can be assigned using the Roles, mapped to the licenses in your Office 365 tenant. *Note that only the licenses which are available for your tenant will appear (one you are logged in/ have received the oAUTH token by authenticating your Office 365 Admin User in the App Settings).
You will want to have a role, or roles in the Centrify Admin portal which match the App or License name for simplicity. Assign the Members to the Role (since you are using only Centrify directory Users, they will need to be created first.) In my example, I have a Role called 'Office Users', where I add all Users as members to the role to give out my E3 licenses.
For Sync, you likely want to have something like I have shown below
Remember, after the above is properly configured, and you initiate a provisioning sync in Preview mode (Find User, select and choose 'Sync all Apps') and you have cut over the provisioning to 'Live' mode,' the domain can be Federated using the option to 'Federate Domain'once the domain is selected in the App settings (again, once the Admin account is added to fetch the oAuth token).
FEDERATING THE DOMAIN WILL BE CONSIDERED THE CUTOVER STAGE and should NOT be done until you are sure that your Users are provisioning as expected. ALL USERS logging in with the domain you are Federating will be redirected to Centrify and MUST
1. be in the Role mapping Role to distribute licenses AND
2. also assigned Access to the App (usually also using the same Role) first, and need to know the new username/password for Centrify, in order to succeed in authenticating their licenses for Office 365 log in at the Centrify portal.
More info on Provisioning is here.
I hope this helps with your configuration. If you would like to add your own request to "Support authenticating the Admin user for the oAuth token creation for the App configuration when MFA is enabled", feel free to add here, to our Idea Exchange.
04-04-2017 05:34 PM
Thanks for such a detailed response Ryan, I appreciate it probably took a while to write all that up.
After running into issues with the MFA on my main user I tried creating a new global admin in O365 with just a static password and was able to get through the initial setup that way.Thanks for putting in the RFE though, it's definitely needed, or at least some reference in the documentation to say that the setup step wont work on users with MFA enabled... that was the worst thing about the problem, there's no doco on the limitation anywhere.
Unfortunately that wasn't the end of my problems, I couldnt get my domain user to sync, I kept getting the following error in the email reports :
SourceAnchor is a required property for federated user. paramName: FederatedUser.SourceAnchor, paramValue: null or empty, objectType: System.String
I couldn't find any info on this anywhere, it seemed like I was the only person to have this error ever. When I finally worked it out, it was from looking at Azure AD doco - basically the users from centrify already existed in my azure AD from a previous PoC where I was using azure AD for SSO. It seems the provisioning option in centrify for overwriting existing users won't/can't clobber users which were created in the Azure AD console (as opposed to being o365 users), I think because the GUID is different. I tried deleting the user but the O365 user delete function just puts them in a recycle bin for 30 days. To permanently delete them from the recylce bin, I had to install the azure AD powershell tools and delete them using powershell cmdlets. Once I had done this, the outbound user sync was able to reprovision them as new users in O365.
Again, there's no documentation about this constraint, I guess it's an edge case which perhaps never came up in testing. For future reference, provisioning into an O365 tennancy with existing users in AzureAD doesn't work.
Anyway, it's "working" now - I can log into the portal and O365 desktop apps using my centrify credentials. One small pain point though - the O365 App in the centrify user portal automatically sends the user to OWA, which results in an error page if the user in question has only O365 business license attached (IE no exchange mailbox). It would be good if there was an option in the app config to direct the user to the O365 portal or launcher page instead. Not everyone is using O365 for email.