I tried SSO linking Okta and Microsoft 365
Introduction
According to Okta's annual survey report "Businesses at Work 2021 (https://www.okta.com/businesses-at-work/2021)", SaaS used via Okta in 2020 is by far the Microsoft 365” is the top. "If it's the most used, I have no choice but to do this", so I actually tried to cooperate.
When I actually linked Okta and Microsoft 365, the SSO linkage method was "WS-Federation" instead of "SAML", and the attribute "Immutable ID" was required for linkage, etc. Differences from other SaaS I have found the point.
In this blog, I summarize what I struggled with and what I learned in the actual collaboration. We hope that you will find it helpful when linking Okta and Microsoft 365 with SSO.
What is WS-Federation?
Standard protocols such as SAML and OpenID Connect are usually used when SSO linking many SaaS such as Salesforce, Box, and DocuSign with IDaaS represented by Okta. Since OpenID Connect was created relatively recently, currently SSO linkage using SAML is the mainstream.
However, when linking IDaaS (Okta) and Microsoft 365 with SSO, the “WS-Federation” protocol is used.
WS-Federation uses Security Token Service (STS) like SAML to achieve SSO. Okta also uses this WS-Federation when linking with Microsoft 365 with SSO. You may be confused because you can only select “WS-federation”, which is unfamiliar, but basically it is the same as SAML and there is no problem.
For details on WS-Federation, please refer to the official website of Microsoft.
https://docs.microsoft.com/en-us/previous-versions/dotnet/articles/bb498017(v=msdn.10)?redirectedfrom=MSDN
What is Immutable ID?
When SSO linking Okta and SaaS using SAML, basically by setting only the user name on the SaaS side as an attribute, it is possible to log in to SaaS via Okta without using a password. However, in the case of Microsoft365, in addition to the user name on the Microsoft365 side, an attribute called “Immutable ID” is required.
<Required setting value in Box (user name only)>
<Required settings for Microsoft365 (user name + Immutable ID)>
Immutable ID is an attribute used to uniquely identify and link users on the IDaaS (Okta) side and users on the Microsoft365 (Azure AD) side.
The Immutable ID is also called the sourceAnchor attribute, and details are described on Microsoft's official website, so please check below.
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts
How to check and set Immutable ID
You can check the Immutable ID given to the user on Microsoft365 by connecting to Microsoft365 with PowerShell and executing the following command.
<Immutable ID confirmation command>
Get-MsolUser –UserPrincipalName <account address> | Select-Object ImmutableID
< Immutable ID confirmation command execution result>
If you manually create a user on Microsoft365, an Immutable ID will not be given, so you can give the user an Immutable ID by connecting to Microsoft365 with PowerShell and executing the following command.
<Immutable ID assignment command>
Set-MsolUser –UserPrincipalName <account address> -ImmutableID <unique ID for linkage>
< Immutable ID grant command execution result>
Immutable ID should be a unique value for each Microsoft365 user, and you can also give a value together with an email address.
Grant Immutable ID from Okta using provisioning function
The custom domain registered when Okta and Microsoft 365 are linked with SSO is a federated domain. As it is a federated domain, it is not possible to create a new user from Microsoft 365, and there is a specification issue.
As an example of countermeasures, you can cancel the federation status of the target domain by executing the following command and create a new user on Microsoft365.
<federated domain release command>
Set-MsolDomainAuthentication -Authentication Managed -DomainName <target domain>
<Federation domain release command execution result>
The target domain is converted to Managed (normal domain), and the domain status can be confirmed with the command "Get-MsolDomain".
When resetting to a federated domain, it is possible to resave (edit without changing settings → save) on the Sign On tab of the Microsoft 365 setting screen on the Okta administrator screen.
しかし、上記手法では新規ユーザ作成の度にフェデレーションドメインの解除及びImmutable ID付与が必要となり、ユーザ管理が煩雑かつ運用工数・コストが発生してしまいます。
Therefore, it is recommended to use the "provisioning function". This is because there is no need to release the federated domain, and just by creating a user in Okta, an Immutable ID can be given to the user linked to Microsoft 365.
*Please note that the provisioning function requires a Lifecycle Management (LCM) license.
The provisioning function of Okta and Microsoft 365 can be performed from the Provisioning tab of the Microsoft 365 setting screen of the Okta administrator screen.
<Provisioning setting screen>
The Immutable ID to be given can be set in the Okta to Microsoft 365 mapping rule in Directory > Profile Editor.
< Immutable ID mapping setting screen>
Immutable ID is set as follows by default.
<Default Immutable ID settings from Okta to Microsoft365>
hasDirectoryUser()?findDirectoryUser().externalId: null
If the user on Okta is synchronized with Active Directory, the GUID of the ID assigned to all objects on Active Directory (128-bit random value), if not synchronized, NULL (empty string of length 0) ) is set.
In addition, it will be NULL when creating a user on the Okta side, but when creating a new user from Okta to Microsoft 365 using the provisioning function or giving an Immutable ID to an existing user on the Microsoft 365 side, the Immutable ID will have a random value. Granted automatically.
Note that once the Immutable ID is set, it cannot be overwritten. If you overwrite with a value different from the original Immutable ID value, the original Immutable ID will be retained on Okta.
Summary
In this blog, we introduced the “WS-Federation” protocol used for SSO integration between Okta and Microsoft 365, “Immutable ID”, and the necessity of provisioning integration.
Okta and Microsoft 365 SSO integration itself can be achieved by clicking a few buttons, but I feel that the details are difficult to understand. I myself had some troubles with the cooperation, and I sincerely hope that those who have the same problem will read this blog and solve it.
If you are interested in linking Okta and Microsoft 365, please contact Macnica.
Inquiry/Document request
In charge of Macnica Okta Co., Ltd.
- TEL：045-476-2010
- E-mail：okta@macnica.co.jp
Mon-Fri 8:45-17:30