Many people use Okta with Office 365 because of its simple architecture and powerful cloud identity management features. With Office 365, Okta can replace the need for ADFS (Active Directory Federation Services - Wikipedia, the free encyclopedia(http://en.wikipedia.org/wiki/Active_Directory_Federation_Services)) and therefore avoid the need for a lot of servers deployed in your data center to support single sign on to Office 365.

If you have multiple email domains in a single Office 365 instance, you may run into confusion on how to use this with Okta. This article describes how to configure Office 365 and Okta to support the single sign of of many email domains.

Office 365 lets you host your email in the cloud along with other Microsoft services like SharePoint and Lync. Typically when you purchase Office 365 and move your users to it, you register your company email domain so that email can get to your Office 365 instance. Okta can then easily be configured to leverage your existing Active Directory accounts to seamlessly login to Office 365. However, if your company wishes to use more than one email domain, it's not straight forward how to configure Office 365 and Okta to support this.

First you need to ensure all domains you wish to federate are assigned in Office 365. By default when domains are assigned, their authentication mode will be "Standard", meaning the username and password is stored in Office 365. You are likely reading this article because you've already followed the instructions to federate one domain in Office 365 but need to add another.

There are two methods for federating a second or more domains. One is to use the same end point information for the federation system. That is to say when you add the Office 365 app to your Okta org, it auto generates the details you need to setup single sign on. Office 365 doesn't support multiple domains with a single end point for anything other than ADFS. Therefore it is not possible to have one app in your Okta org work with all the domains you might have in Office 365. Instead, you need to create an Office 365 app per domain. It is wise to configured each Office 365 app in Okta with a name that clearly states which domain is being federated for that app assignment.

For example if you have corpdomain.com and productcorpdomain.com registered with Office 365, it would be wise to label the Okta Office 365 apps, "corpdomain.com" and "productcorpdomain.com" respectively.

With two apps in Okta for each Office 365 domain, you simply click on the "View Setup Instructions" for the WS-Federation section in the Sign-On Options for the app. This gives you the PowerShell commands to run to configure the Office 365 domains correctly. Once this has been done, you need to assign the users the right Office 365 app in Okta. The best way to do this would be to create a group (in Okta, or you can sync on from AD) and add each user to the right group. Then assign to the groups to the apps. Using our example above, you could have a group called "Corp Office 365 users" that is assigned to the "corpdomain.com" Okta app. Then populate that with the users who need to access email using the domain corpdomain.com

At this point you will have Okta configured for two or more Office 365 Apps, each of which responsible for the single sign on for one domain. Office 365 should also have those domains registered and setup to federate to Okta. If we follow the example above, there is also a group which manages the assignment of the right Okta Office 365 app to the right person.

Now you need to ensure the users have the right data and are synchronized to the Office 365 system correctly. Firstly, you will need to ensure the User Principal Name (UPN) in Active Directory matches the user@domain.com(mailto:user@domain.com) combination for their email in Office 365. To do this first add the domain suffix to the Active Directory Forest, follow this article here, HOW TO: Add UPN Suffixes to a Forest(http://support.microsoft.com/kb/243629/en-us).

Once you have added this to the Active Directory schema, you can now select the users in Active Directory and change their domain for their User login name. This is found on the Account tab on the properties page for users in the Active Directory Users and Computers administrative tool.

Now at this point, you need to get this user and the change into Office 365. Typically customers are using a free product from Microsoft called DirSync or Windows Azure Active Directory Sync tool. This copies ALL user and group information from your Active Directory into Office 365. DirSync will add the user or update the existing user in Office 365 so they have the right UPN needed for federated single sign on. However, you might run into a bug where DirSync is unable to change a UPN for a user that has one already associated with a domain that is federated. In this instance, you will need to perform a manual process (which could be automated with PowerShell scripts) to switch the users UPN to a domain that is set to Standard authentication (typically the default yourdomain.onmicrosoft.com). Details on how to work around this DirSync bug are here, http://community.office365.com/en-us/wikis/sso/renaming-a-upn-to-another-federated-domain.aspx(http://community.office365.com/en-us/wikis/sso/renaming-a-upn-to-another-federated-domain.aspx)

Note you maybe using Microsoft Forefront Identity Manager (FIM 2010 R2) to sync identities into Office 365. This may work fine and not run into the problem above.

Once the users are in Office 365 with the right UPN and they also exist in Okta with the right Office 365 app assigned, you are good to go. You can now use Okta to authenticate users for multiple domains in Office 365.

If you run into a problem with the above and need to revert to a work environment, these are the actions you need to take.

• Run the PowerShell command Get-MsolDomainFederationSettings to be sure you know what domain and what configuration you are about to change.
• Unassign the Okta Office 365 app for the new domain from any Okta users. You don’t have to delete the app.
• Switch the Office 365 domain authentication back to it’s original state. Run the Convert-MsolDomainToStandard PowerShell command. http://technet.microsoft.com/en-us/library/dn194122.aspx(http://technet.microsoft.com/en-us/library/dn194122.aspx)
• Switch back the UPN suffix in Active Directory for the affected users.
• Depending on your Microsoft Office 365 licensing requirements/restrictions, you may also need to remove licenses for any users you migrated to Office 365.

In theory you can add the Okta app and configure the new domain without affecting anyone. (assuming this domain isn’t being used at all in Office 365). It isn’t till you change the UPN, run DirSync and then assign the app in Okta that you actually affect users.