Azure AD Domain Join and OKTA

Recently, I have run into a scenario which OKTA is positioned as the IDaaS solution for all cloud applications and a specially for Azure AD and for Office 365.

This requires some integration with the existing identity services which might be challenging but supported and realizable, and especially in a Microsoft oriented landscape using Office 365, Intune and other Azure AD-related services.

This enables a Single Sign-On (SSO) experience to either OKTA or Azure AD federated applications by logging in just once on their own device.

The scenario

The scenario includes Microsoft cloud services with Azure AD, Office 365 and Intune and the other was OKTA as the identity solution. The goal was to establish a fully Single Sign-On experience for the end user using OKTA as the authentication source.

The expected behavior should be different and divided for managed and unmanaged devices:

  • Managed device – In this scenario, the device is managed by Intune and onboarded into Azure AD using an Azure AD Domain Join.
  • Unmanaged device – This can be considered as the ‘Bring Your Own Device type’ of scenario, but not managed by Intune.

I must emphasize that Azure AD Domain Joined is required to allow users to login with Windows 10 devices with their credentials in order to get SSO with Cloud applications without the need for on-premises federation services.

Note: Te Azure AD Domain Join can be achieved with two modes, with Azure AD Domain Join only (standalone), and with hybrid Azure AD Domain Join. In my specific scenario, it was Azure AD Domain Join only (standalone).

Diagram

  • Continuous line – Connection between platforms
  • Dashed line – user request

Highlight

  • Azure Active Directory is used for and with Intune and Office 365 purpose.
  • In our scenario, the account is provisioned using OKTA and Azure AD connect.
  • A federation is being used between OKTA and Azure AD based on the WS-Federation protocol. In this scenario, OKTA is identified as the Identity Provider and Azure AD as the Service Provider.
  • OKTA is used as the corporate authentication source (IdP), and the accounts and passwords are authenticated via the OKTA.
  • A federation is configured between OKTA and Office 365 and other application as well based on the SAML protocol.
  • Token for a machine is based on Azure AD.

User Flow

The user flow for access to Office 365 app and third-party app via OKTA iDP is:

  1. The user logs in to the machine.
  2. An Azure AD token is retrieved during the initial sign in. Refresh & access token).
  3. The Azure AD token and Okta SSO is used to access and enable a Single Sign-On (SSO) experience to the Office 365 apps.
  4. The third-party apps are selected in the application portal which points to the OKTA SSO. This includes the Okta IdP endpoint and embedded link of the Salesforce application.
  5. The SAML post request to Azure AD which consumes the already existing Azure AD token. This initiates a redirect + SAML Post request back to the Okta SAML endpoint.
  6. The SAML token is consumed by the Okta endpoints and issues an OKTA SAML token.
  7. The OKTA token is used to access third-party apps.

General Configuration

  • Azure AD Joined device
  • Okta registered device
  • Integrated Windows authentication for all browsers
  • All Azure AD, Office 365 and Okta URL’s must be in the local intranet

Notes

  • The federation described is required to enable a Single Sign-On experience for Azure AD Domain Joined devices.
  • During the login on the device, an Azure AD token is retrieved which can be used to enable a Single Sign-On experience to Azure AD federated applications.
  • OKTA is the Identity Provider which requires an OKTA token to enable the same experience, and a federation is configured as described to leverage the Azure AD token during the device login to retrieve an Okta token.

How to Integrate Azure AD & OKTA

The integration between Azure AD & OKTA is relatively simple and you need to configure the following settings:

  • Configure Single Sign-On (SSO) between Azure AD and OKTA (supposed to be configured if you’re working with OKTA and Azure AD & Office 365)
  • Setup Single Sign-On (SSO) with other application
  • Prepare Azure AD and Intune policy to allow a user to register their Windows 10 device into Azure AD and allow the provision to be automatically 

Azure AD Domain Join and OKTA

Recently, I have run into a scenario which OKTA is positioned as the IDaaS solution for all cloud applications and a specially for Azure AD and for Office 365.
This requires some integration with the existing identity services which might be challenging but supported and realizable, and especially in a Microsoft oriented landscape using Office 365, Intune and other Azure AD-related services.
This enables a Single Sign-On (SSO) experience to either OKTA or Azure AD federated applications by logging in just once on their own device.

The scenario

The scenario includes Microsoft cloud services with Azure AD, Office 365 and Intune and the other was OKTA as the identity solution. The goal was to establish a fully Single Sign-On experience for the end user using OKTA as the authentication source.
The expected behavior should be different and divided for managed and unmanaged devices:

  • Managed device – In this scenario, the device is managed by Intune and onboarded into Azure AD using an Azure AD Domain Join.
  • Unmanaged device – This can be considered as the ‘Bring Your Own Device type’ of scenario, but not managed by Intune.

I must emphasize that Azure AD Domain Joined is required to allow users to login with Windows 10 devices with their credentials in order to get SSO with Cloud applications without the need for on-premises federation services.
Note: Te Azure AD Domain Join can be achieved with two modes, with Azure AD Domain Join only (standalone), and with hybrid Azure AD Domain Join. In my specific scenario, it was Azure AD Domain Join only (standalone).

Diagram

  • Continuous line – Connection between platforms
  • Dashed line – user request

Highlight

  • Azure Active Directory is used for and with Intune and Office 365 purpose.
  • In our scenario, the account is provisioned using OKTA and Azure AD connect.
  • A federation is being used between OKTA and Azure AD based on the WS-Federation protocol. In this scenario, OKTA is identified as the Identity Provider and Azure AD as the Service Provider.
  • OKTA is used as the corporate authentication source (IdP), and the accounts and passwords are authenticated via the OKTA.
  • A federation is configured between OKTA and Office 365 and other application as well based on the SAML protocol.
  • Token for a machine is based on Azure AD.

User Flow

The user flow for access to Office 365 app and third-party app via OKTA iDP is:

  1. The user logs in to the machine.
  2. An Azure AD token is retrieved during the initial sign in. Refresh & access token).
  3. The Azure AD token and Okta SSO is used to access and enable a Single Sign-On (SSO) experience to the Office 365 apps.
  4. The third-party apps are selected in the application portal which points to the OKTA SSO. This includes the Okta IdP endpoint and embedded link of the Salesforce application.
  5. The SAML post request to Azure AD which consumes the already existing Azure AD token. This initiates a redirect + SAML Post request back to the Okta SAML endpoint.
  6. The SAML token is consumed by the Okta endpoints and issues an OKTA SAML token.
  7. The OKTA token is used to access third-party apps.

General Configuration

  • Azure AD Joined device
  • Okta registered device
  • Integrated Windows authentication for all browsers
  • All Azure AD, Office 365 and Okta URL’s must be in the local intranet

Notes

  • The federation described is required to enable a Single Sign-On experience for Azure AD Domain Joined devices.
  • During the login on the device, an Azure AD token is retrieved which can be used to enable a Single Sign-On experience to Azure AD federated applications.
  • OKTA is the Identity Provider which requires an OKTA token to enable the same experience, and a federation is configured as described to leverage the Azure AD token during the device login to retrieve an Okta token.

How to Integrate Azure AD & OKTA

The integration between Azure AD & OKTA is relatively simple and you need to configure the following settings:

  • Configure Single Sign-On (SSO) between Azure AD and OKTA (supposed to be configured if you’re working with OKTA and Azure AD & Office 365)
  • Setup Single Sign-On (SSO) with other application
  • Prepare Azure AD and Intune policy to allow a user to register their Windows 10 device into Azure AD and allow the provision to be automatically 

You may also like...

2 Responses

  1. John Q says:

    Hi I was wondering if this is still supported or not. I’m reading that Okta does not support it and will break production. We use on-prem AD with AD Sync and use Okta for MFA/SAML.
    What do we choose for the “SCP” in the Azure AD Connect Device wizard? Okta or Azure?

Leave a Reply

error: Content is Protected !!
%d bloggers like this: