Hybrid AAD Join with Okta as Identity Provider

Okta (https://www.okta.com ) offers access and authentication management capabilities just like Microsoft with Azure AD. A current scenario that continues to cause problems is the combination of both solutions: Hybrid AAD Join with Okta as Identity Provider.

In general, the combination of Azure AD and Okta works. Okta provides various HowTo articles, FAQ and whitepapers on this. For example Add Office 365 to Okta or, focusing hybrid AAD Join with Okta as Identity Provider, this:

• Hybrid AAD Join with Okta as your Federation Provider FAQ
• Using Okta for Hybrid Microsoft AAD Join
• Okta’s identity and access management solutions are compatible with Windows 10
• This PDF document describes the settings in the Okta system: Okta + Windows 10 Azure AD Join

However, there is another option to continue using Okta as an identity provider and to register devices in Azure AD independently. In the end, this was the solution that worked for us in a project with a customer, because the following options can only be used when a device is registered in Azure AD:

• Endpoint Manger / Microsoft Intune
• Windows Hello for Business
• Windows Autopilot
• Conditional Access Policies
• Etc.

Configure hybrid Azure Active Directory join bypassing Okta

When Okta is used as the identity provider, all authentication requests use the Okta service. This is also true when a device wants to authenticate or tries to join Azure AD.

This Microsoft tutorial describes step-by-step how to setup a hybrid Azure AD join: Configure hybrid Azure Active Directory join for managed domains

Here are the steps to „Configure hybrid Azure Active Directory join bypassing Okta“:

1. Changed the Service Connection Point configuration in Azure AD Connect to Azure AD:

2. Set machine proxy configuration on Win10 device: Win10 (1709 and later) tries to complete the hybrid Azure AD join via a scheduled task. This is done in the machine context. To get this done a machine proxy is needed. This can be done via netsh winhttp set proxy proxy:port. You can also do it using a GPO in local Active Directory: https://support.microsoft.com/en-us/help/4494447/use-group-policy-to-apply-winhttp-proxy-settings-to-clients

3. Configure the auto-enrollment Group Policy for a single PC. The necessary change here is:  Change the policy from device to user credentials: https://docs.microsoft.com/en-us/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy#configure-the-auto-enrollment-group-policy-for-a-single-pc

At the end Okta is no longer involved if a device joins Azure AD but still the Identity Provider if a user is doing a log-in to Office 365.

Onetime Passcode Authentication to access Microsoft 365 Group resources

Onetime passcode authentication via email is an Azure AD feature and currently still in preview. The preview function must be activated in Azure AD under User Settings -> Manage external collaboration settings:

Starting March 2021, the Onetime Passcode feature will be enabled by default for all new and existing tenants. If the feature should not be available, it must be disabled.

Users who want to use Onetime Passcode for login must login using a link that contains the Tenant context. For example: https://%tenant name%.sharepoint.com/teams/demo

Direct links to applications and resources also work if they contain the tenant context. Logging in using endpoints that do not contain the Tenant context is currently not possible. For example, using https://myapps.microsoft.com, https://portal.azure.com results in an error.

User experience for Onetime Passcode

When accessing an Office 365 resource, the user is prompted to authenticate. It does not matter whether the access is done via the browser or via an app. If an Onetime Passcode is used for authentication, the dialog looks like this:

Onetime Passcodes are valid for 30 minutes. After 30 minutes, the respective one-time passcodes is no longer valid and the user must request a new one. Sessions expire after 24 hours.

Access works for services belonging to the Microsoft 365 Group, such as SharePoint, Planner or Teams. Access to, for example, PowerBI or Microsoft Stream did not work when this article was written.

Administration / Inviting a guest user via Onetime Passcode

To enable a guest user to log in via the Onetime Passcode feature, they must be created/invited as follows. The guest user is invited in Azure AD to the Microsoft 365 group belonging to the SharePoint site or Microsoft Team with his email address:

The user will then receive the following email:

When clicking on the link in the mail, the steps described under "User experience for Onetime Passcode" will follow. It depends on the user / account whether he can log in via username & password or the Onetime Passcode option is used. The user will receive an email / Onetime Passcode if:

• He does not have an Azure AD account.
• He does not have a Microsoft account (Live ID)

At the time of invitation, there is no way to verify whether the user being invited will use the Onetime Passcode option or not. The option, if enabled in the tenant, is available as a fallback if no other authentication method can be used.

Whether a user will use the Onetime Passcode method can be checked in the user profile details after the first login:

Update on Information Protection, Azure Purview & GDPR

Information Protection

The settings for a Sensitivity Label have changed since Ignite in September 2020. One of the first steps is now to specify whether the label should be used for “Files & Email”, for “Groups & Sites” or also for the new Azure Purview integration:

Even if the dialog looks a bit different in detail, no new feature has been added to the „Files & Email“ section.

In the „Groups & Sites“ area we now have the feature "Control External Sharing for SharePoint Online Sites":

The settings in the label override the settings in the SharePoint Admin Center when the label is assigned to a site.

Note that SharePoint Online caches these settings. If a label is reassigned or updated, it can take up to 24 hours for the changes to take effect. If a label is assigned directly when the page is created, the settings take effect within 15 minutes.

Azure Purview:

Sensitivity labels can now be extended to Azure Purview. This enables labels to be applied to SQL columns and files in Azure Blob Storage.

This is also a relevant new function, especially in the context of GDPR, as personal data is usually stored and processed in various IT systems. Details on this: Microsoft Information Protection and Microsoft Azure Purview: Better Together

The function is currently still in preview status and can be activated in the Security Center in the Sensitivity Labels area:

What is Azure Purview

Azure Purview is a data governance service. The service aggregates data from on-premises systems, multi-cloud scenarios and software-as-a-service (SaaS) applications. The service creates a Purview data map based on this data:

Details: https://azure.microsoft.com/en-us/services/purview/

GDPR

Both features, sensitivity labeling and integration with the Azure Purview service, support the requirements of the GDPR. Parallel to the updates of the technical features, Microsoft has taken action in response to the decisions of the EuGH (Privacy Shield agreement / Schrems II).  

In this press release, which is unfortunately only available in German, Microsoft explains the details of the Defending Your Data program and that these efforts will be part of future contracts with enterprise and public sector customers. The two most important details are:

·        Microsoft is committed to challenging any request by a government entity for data from enterprise or public sector customers where there is a legal basis for doing so.

·        Microsoft will compensate customers for financial damages if their data must be released to a government agency in violation of the EU General Data Protection Regulation (EU GDPR).

Details in the press release linked above.