Summary: Quick guide
-
Create 1 provisioning app for all licenses
- Create a user profile attribute (enumerated) for static attribute values
- Distribute through rules and groups - using group combined attribute mappings
- Make app hidden
-
Create SSO apps for every domain that needs SSO
- Turn on provisioning without any data pushing to import the ImmutableID
- Distribute through rules and groups - leveraging the user profile
- Make app hidden
- Name app correctly as warning for the manual import problem
-
Create bookmark apps for the SSO sub tiles per SSO app
- Use the deeplinks per SSO sub app and add them to the SSO group
Introduction
In a perfect world we only have one domain in everything we do. But that's not nearly the case in most situations.
This is a setup we follow when encountering multi-domain Office 365 tenants and Okta.
It's based on cloud setups without interaction with AD, even though it will work too, AD can have advantages or problems with this setup.
Pre-requisites
- An Office 365 tenant with more than one tenant besides the onmicrosoft.com domain
- Okta with provisioning turned on for at least 1 app
- Global administrator account for provisioning and WS-Fed setup (preferable in the onmicrosoft.com domain)
- Different types of licenses (or possibility to provision semi sets of one license type)
Situation
The issue at hand is that Okta can't SSO multi-domains from one app. It would have been so easy if you could add more domains, by a comma separated list. Like this:
Unfortunately, that's not something that exists right now. So that brings us to the problem;
- How do I make sure license distribution, group management and SSO are all taken care of, without manual steps or to much upkeep?
We want to make sure we're able to manage everything from one place and have Okta distribute to all the rest, without an admin constantly checking if everything's okay.
In all of this we also have another part in this puzzle and that's Office 365 user ImmutableID, which we get from Office, but can't redistribute to other apps in Okta. Mapping is out of the question here.
Setup
So we have to create multiple and separate apps to do all this.
Access
First we start with a simple office 365 global admin app, that will store your secure 64 character password, which we'll need more than once.
We suggest creating a service account without licenses in Office 365 with Global admin rights in the onmicrosoft.com domain for this reason.
Office 365 provisioning app
Now the setup of the provisioning is relatively straight forward. Creating the API connection setting up mappings and groups for licenses management. We recommend turning on Combined group assignment for attributes, to be even more granular when it comes to group license assignments with groups.
To make sure you have no issues with signing on, making this app hidden for end-users both on the dashboard and Okta mobile is needed.
This gives you the ability to keep close control over the provisioning of your users (for every domain) with specific sets of licenses and roles. Secondly you don't have to copy over to other apps when changes are needed, because this is always a fluid setup, changes come and go, better just change it in one app than multitudes because of the diverse setup.
By using group rules (provisioning is needed as a Okta SKU to have that), you can completely automate this from a user's profile perspective. Okta has released the feature for enumerated attributes, which will give you the ability to create a dropdown or selectlist and other items with fixed values.
In this setup we create a dropdown and select a specific value that will trigger rules to provision the user to the correct group or groups:
By choosing one of the options, triggers fire, to assign you to the correct groups with provisioning setup.
As you can see, we even have an option to deprovision you from a license, by selecting the none option.
Don't forget: You still have to delete that license from your Office 365 portal if you don't want to be charged for it, even if it's not in use.
When this part has been set up and your comfortable with the provisioning, we can continue to the next part.
Office 365 single Sign on app(s)
Now we land on the harder part of this setup. We need to SSO an array of domains within Office365. The first step is to create all the apps for each domain. The steps for the setup are straightforward and Okta has made it simple because they will do all the powershell commands for you.
Once setup up, you'll have a list of Office 365 apps in your app catalog:
The tricky part here is; when assigning a user to this App, Office365 will not allow you to sign in, because the ImmutableID isn't passed along. Unfortunately we can't map that over from the provisioning app, because there is no way (yet) in the Universal Directory to map over details to Okta without having the app be a Master (which Office365 can't be).
So, we have a provisioning app with an ImmutableID, and SSO apps without an ImmutableID.
Funny enough, if provisioning is turned on for the SSO app, but you don't use it at all, and you add users to the app, Okta will automagically retrieve the ImmutableID from Office and add it to the user. You don't have to do anything.
Turning on the provisioning is the same as the original provisioning app, only now, just make sure nothing int the "from and to" Okta is turned on or configured.
From okta:
To Okta:
This way users won't be updated by the SSO app, but do have a connection with Office365 to update user info, including the ImmutableID:
Assigning a user:
After assignment the user is instantly updated:
And now the user is able to sign in with the SSO app, without any admin manually copying over values to make sure the user has the right data.
This also works with groups. Thus we can automate the assignment to the SSO apps directly from the user profile and with almost no extra additional info.
Because we are leveraging the username, which got provisioned, we can setup rules that check the domain and license (we don't want to assign users who don't have licenses) and then add them to the correct SSO groups.
Groups:
Have the corresponding SSO apps be added to the groups.
Than create the rules:
These will assign users based on your enumerated attribute and check the correct domain in the email, making sure your not switching users to the wrong SSO app.
Warning: Keep in mind that the SSO apps are using a method that, unfortunately, can break easily. Because when you run a manual import on the SSO app, it will delete the users from the app. This is built as designed and there is no way to turn off the import function here.
Based on that, we need to be sure no admins go into the app and starts clicking away, that will just give you more headaches.
A recommendation is to name these apps in a way that it's clear from the start:
Only thing here is, is that the name of the app is also reflected in the app tiles on the end-user dashboard.
Which doesn't look that nice:
We recommend to hide the SSO apps too (together with the provisioning app) and create bookmarks for the apps used or needed.
These bookmarks can use the deeplink found the the SSO app to start an IdP initiated flow to Office 365.
You can add these bookmarks (a tile per SSO app) to the SSO group in Okta and have these assigned to the users in that group.
Make sure you have the correct URL in the bookmark apps, otherwise IdP initiated flows will try to sign in users with different SSO apps.
That's it, now we've setup a master provisioning app to make sure we have that under control, with limited groups based on the licenses your assigning to users. We have set up apps, groups and rules for the SSO to make sure users are getting the correct SSO flow with automatic importing of the ImmutableID and we created bookmarks for easy access from the enduser dashboard.
If you have any questions please use our support form or contact us at support@realconnections.nl