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.

Secure your environment by Conditional Access & App Controls

With the Azure AD Conditional Access feature, rules for access to Microsoft Cloud Services and other apps registered in Azure AD can be bound to conditions.

An example is the rule: When accessing with an unmanaged device, the user is prompted to use multi-factor authentication.

With the feature "Use Conditional Access App Control" as an option in the Session Controls area within Azure AD Conditional Access, advanced scenarios can be setup.

Options:

• Prevent data exfiltration
• Protect on download
• Prevent upload of unlabeled files
• Block potential malware
• Monitor user sessions for compliance
• Block access
• Block custom activities

Example:

• Automatically assign a sensitivity label when a file is downloaded.
• Filter based on regular expressions: “Include Files that match a custom expression”
• Block Upload if Maleware is detected.
• This is can be done because the Cloud App Security service then acts as a proxy for accessing the application:

Setup Conditional Access App Control

The options listed above affect all resisted apps under https://portal.cloudappsecurity.com/#/connected-apps?tab=proxy.  By default, this list is empty:

To register an app, the wizard can be used in Cloud App Security via Investigate -> Connected Apps -> Conditional Access App Control Apps. Another and much simpler way is to use a conditional access policy as an easy start:

1. Azure AD Security -> Conditional Access

2. New Policy

3. Section „Access controls“ -> „Session“

4. Use „Use Conditional Access App Control“

5. Use „Use custom policy to set an advanced policy in Cloud App Security“

Configure the policy in the menus "Users and Groups" etc. that it will be applied the next time the app to be registered is started. This then results in apps that are authenticated via Azure AD being automatically registered in Cloud App Security under „Conditional Access App Control“:

The above method works for the so called featured apps. In order to make this option work for the Office 365 Featured Apps, Office 365 must be registered under "Connected Apps" in Cloud App Security:

Once an app is registered, session policies can be created that will take effect when the app is used.

Example: If the user Oliver Hardy tries to download a document from Microsoft Teams (SharePoint) that contains the term "confidential", the download is blocked.

Further scenarios

• Monitor / block activities based on file conditions like Classification Label, File Name, Files Size or File Extension
• Apply rules based on Maleware detection
• Apply classification label to downloads
• Block downloads based on conditions
• Monitor / block activities like Cut/Copy Item, Paste Item, Print Item, Send Item

Impact from the user's perspective

When opening the app, the user is notified that access is monitored by Cloud App Security. The fact that a proxy is involved can also be recognized by the URL. This now has the addition access-control.cas.ms:

If the user Oliver Hardy now tries to download a document he gets the following message:

Microsoft Information Protection – News from Ignite 2020

The Microsoft Ignite Conference 2020 was held online from 22.09. - 24.09. Besides many announcements around Microsoft Teams and Office 365 there were also some news about Microsoft Information Protection.

News from Ignite

Microsoft is combining data loss prevention and protection of sensitive data. DLP rules can now be defined in the sensitivity label:

Data Loss Prevention is an area that is currently under strong focus. This is a current and important topic not least because of the strong growth of home office regulations in the context of CORONA. Here an overview of the announcements:

• Devices / Endpoint Integration and the Cloud App Security service can now be set as targets for DLP policies:

• In the context of the Cloud App Security service, it is also possible to restrict which registered apps are affected by the policy:

• Under the topic "Policy Settings" you can then control the effects of the policy in a very granular way:

• A DLP policy can be run in test mode in the first step:

There will also be changes from the user's perspective. Here is an example of how DLP will affect Microsoft Teams:

Conclusion

By integrating DLP functions into Sensitivity Label and coupling it with the Cloud App Security and Endpoint Manager / Intune services, sensitive data can now be protected in a holistic approach. With the new options, protection is independent of the storage location, the tool used for editing and the device used. Nevertheless, users can still work flexibly with the data - even from the home office.

The key topics on the current roadmap at https://www.microsoft.com/en-us/microsoft-365/roadmap are: