One of the trends in the market today is enforcing MFA at additional endpoints. Even Microsoft has Microsoft-Managed Conditional Access policies coming down automatically to organizations in the next 90 days. Today, we’re going to cover building out Windows 365 Boot with Okta MFA. We have a few areas to tackle on this:

• Configuring the Windows 365 Conditional Access Policy in Entra ID
• Configuring Okta Authentication Policies to Enforce MFA
• Configuring Office 365 in Okta to Pass MFA to Azure
• Windows 365 Boot Demo with Okta MFA

Configuring the Windows 365 Conditional Access Policy in Entra ID

Creating the Conditional Access policy for Windows 365 Boot isn’t too complicated.

We start with targeting groups that contain our Windows 365 users as you can see below:

The second part, we target the specific Cloud apps that are part of Windows 365. Microsoft covers it in depth here.

The Windows 365 cloud app is used when retrieving the list of resources for the user or user-initiated actions like Restart.

Azure Virtual Desktop /Windows Virtual Desktop Client is used when authenticating to the Gateway during connecting and when the client sends diag info to backend services.

Microsoft Remote Desktop and Windows Cloud Login are used if you’re using SSO in your provisioning policy as they facilitate Cloud PC authentication:

From here, we move onto the “Grant” where we enforce multifactor authentication. In our environment, we use that option as we’re using Okta:

The new “authentication strength” option is good for full Entra environments as you can force someone to use a FIDO key or Microsoft Authenticator.

The last part if our MFA policy, which I decided to put in is sign-in frequency to enforce periodic reauthentication. I would recommend at worst case make this every 4 hours, but we’re doing this every hour for our offshore resources:

Configuring Okta Authentication Policies to Enforce MFA

In my environment, we just do straight “possession factor” so you don’t need to use passwords at all. One of the challenges here, is how they view “MFA” at Okta. Even though Okta Verify can satisfy two factors, it you don’t enforce two factor types it doesn’t see this as MFA. Without setting this up, you will run into infinite loops created by the SAML response back to Microsoft and MFA not being properly satisfied.

So if you do this below, it will not work as expected:

We need to modify our auth policy for Office 365 to a “two factor” type policy like this:

Once that is done, you’re ready to configure the Microsoft Office 365 application in Okta for passing through MFA.

Configuring Office 365 in Okta to Pass MFA to Azure

Now, we enable a great feature in the Office 365 application, which will let Entra ID use Okta MFA to satisfy the multifactor (MFA) requirements:

Simply, this table below from the Okta help article shows you what will happen depending on the status of Okta MFA and requirements of Entra ID MFA:

Okta App-level MFA	Azure AD MFA	What Happens
Disabled	Enabled	End users enter an infinite sign-in loop. To prevent this, you must configure Okta MFA to satisfy the Azure AD MFA requirement.
Enabled	Enabled	End users complete an MFA prompt in Okta. Okta passes the completed MFA claim to Azure AD. Azure AD accepts the MFA from Okta and doesn’t prompt for a separate MFA. The user is allowed to access Office 365.

Once you enable it, you should check the status of the “SupportsMFA” attribute for your domain:

Connect-MsolService
Get-MsolDomainFederationSettings -DomainName <yourDomainName>

The sample result looks like this:

ActiveLogOnUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/active
DefaultInteractiveAuthenticationMethod :
FederationBrandName : Okta
IssuerUri : issueruri
LogOffUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/signout
MetadataExchangeUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/mex
NextSigningCertificate :
OpenIdConnectDiscoveryEndpoint :
PassiveLogOnUri  : https://example.okta.com/app/office365/issueruri/sso/wsfed/passive
SigningCertificate : <SigningCertificate>
SupportsMfa : True

Now, we’re ready to see what the end result looks like.

Windows 365 Boot Demo with Okta MFA

Now, we can see this amazing experience from Windows login screen to work in under 75 seconds coupled with MFA. Enjoy the demo below!

Final Thoughts

We definitely learned a bunch today. In this article we covered building the ideal MFA policy and configuring Okta to ensure we don’t get 97 MFA prompts. It’s a great learning experience in building platforms correctly. When we do things poorly, the user experience suffers. When we do things well, people are excited and everyone wins!