In my previous blog post, I talked about a scenario where the Intune compliance policy for evaluating passwords, when misconfigured, can lead to non-compliance issues even when users set the password in adherence to the policy.
This is a continuation of the same blog post, but in here, we will talk about another scenario.
Table of Contents
Decoding Intune Password Compliance for Windows BYOD: Continuation Post | Part 2
Scenario:
You have a personal Windows device that is configured with an MS account and have it registered and enrolled as BYOD in Intune. Depending on the grace period state of the enforced password compliance policy, when you check the status of the device in the company portal, you see that the device status is marked either as,
- Can access company resources, but action required (device is non-compliant but in grace period), or,
- Can’t access company resources (post grace period expiration)
as it does not meet several compliance checks, one of which is the password requirements.
In the Intune portal, when you check for the device compliance state, you see the device is non-compliant against the compliance policy that enforces password requirement checks.
The compliance policy in effect is configured as below.
Here as you can see, the compliance policy to evaluate password compliance for Windows BYOD devices is correctly configured taking into account the supported password enforcement requirement for Microsoft Account as explained in my earlier blog post.
So here, you know that the password compliance policy is not at fault for marking the device as non-compliant.
Hence the question of the blog,
Why Intune compliance evaluation is failing thus marking the device as non-compliant even when the compliance policy is correctly configured to support MS account password enforcement requirements?
Answer/Clarification:
Here, the non-compliance is simply because of user behavior and knowledge.
Many of the Windows BYOD users have a notion that there is no account (local or MS account) on the device and as such are not aware of how to resolve the non-compliance.
To understand this, we first need to understand the different account types with which we can provision a Windows device.
Different account types with which we can provision a Windows device:
There can only be 4 types of accounts with which a device running Windows 10/11 OS can be provisioned
- Domain account
- Enterprise Cloud account
- Microsoft account
- Local account
Leaving the domain join scenario aside, for most general cases, during the OOBE setup of a Windows device, you have the opportunity to provision the device with only 3 types of accounts.
- Enterprise Cloud account
- Microsoft account
- Local account
- Set up for work or school, which as the name suggests, is for CORP scenario, and requires an Enterprise Cloud account for Autopilot or Entra ID Join from OOBE.
- Set up for personal use, which as the name suggests, is for BYOD scenario, in which you can use either a
- Microsoft Account (default), or
- Offline Local Account (requires bypassing Windows network requirement)
If setting up the device for personal use during the OOBE, Microsoft actually prevents recent Windows 11 builds from being provisioned without an active internet connection, and thus an offline local account.
This means you will be required to provide an active network connection for the setup to continue. Thus, Windows OOBE locks you to sign in with a Microsoft Account for the setup to continue.
As such, most of the users will end up having a BYOD Windows device that is set up with a Microsoft Account, rather than an offline local account.
It is important to note here that the connected experience of signing in with MSA do not include the usual Windows local account setup experience like providing a local account name and setting up the password, recovery questions, and all those.
But it includes Windows Hello PIN setup as part of the OOBE provisioning flow.
If you provision the device using MSA and then set up Windows Hello PIN as part of the OOBE experience, the Windows Hello PIN becomes the only sign-in option available to you to sign in to Windows and get to the desktop.
Notice in the above sign-in screen that no other credential provider is present.
To confirm the same, you can sign in to Windows and once you get to the desktop, go to Settings > Accounts > Sign-in options and under Additional settings, you will see the configuration item “only allow Windows Hello sign-in for MSA on this device” is “Enabled”.
This is by default when you complete the Windows Hello setup in OOBE during device provisioning with an MSA.
And thus, users get the notion that there is no local account or password associated with the device, because post provisioning, they only use Windows Hello sign-in to access the device and get to the Windows desktop.
Until this, it was about provisioning the device with a Microsoft Account.
Earlier above, I said that with the current OS builds of Windows 11, MS now deliberately does not allow provisioning a Windows device with a local account anymore.
But that does not mean you cannot!
If you are an enthusiast, you can still bypass the network and MSA requirement of MS as enforced during OOBE. While provisioning the device, when you are on the OOBE network screen as below, you can press shift + F10 to bring up the command prompt and in there, type in OOBE\BYPASSNRO and hit enter.
The device will restart and this time, when you get back to the same screen, you will now have the option to bypass the network requirement.
Clicking on that I don’t have internet link, which was not available earlier by default, you will now get to another OOBE screen where you get the option to Continue with limited setup.
Which will finally and eventually lead you to set up the device with an offline local account.
The limited setup experience takes you through creating a local account and password and setting recovery questions, and it does not include the Windows Hello PIN setup as part of the process.
Thus, because you go through the account creation and use the credential to sign in to Windows to get to the desktop, as a user, you are aware that there is an account in play.
Any which way you complete the Windows OOBE provisioning and reach to the desktop, either
- going with the default connected experience and signing in with a Microsoft account, or
- bypassing the network requirement to go with a limited setup and thereby creating an offline local account,
by virtue of device provisioning, for both cases, there is an account created on the device, and that account does have an associated password.
- If you have used a Microsoft Account for the provisioning, then the password in context is the password for that Microsoft Account.
- If you have used a local offline account instead, then the password in context is the password for that local account.
Now let’s get back to the point of our blog.
How to resolve password non-compliance for Windows BYOD?
The first step is to determine the Windows Account type you are using on your BYOD Windows device.
To do that, open PowerShell and type “Get-LocalUser | Where-Object { $_.Enabled -match "True"} | Select-Object Name,PrincipalSource” without the quotes and press ENTER to find out the account type of the current user.
For Local Account:
If you observe that you are using a local account, then to resolve the password compliance issue, you will need to reset the password of the local account to meet the length and complexity requirements.
To reset your local account password, you can go to Settings > Accounts > Sign-in options and in there expand Password and click on Change.
You will be first asked to provide your current password. Once you confirm your current password, you will be asked to set up a new password. Ensure you set up the new password to meet the compliance requirements.
Post resetting the password of the local account, sign out of Windows, and then while signing in, instead of using the existing Windows Hello sign-in method (if you have set it up), from the sign-in options, choose Password and use the newly set password to log in.
Post login, use the Check access button to confirm device compliance status in the Company Portal app.
For Microsoft Account (MSA):
If you observe that you are using an MSA, then to resolve the password compliance issue, you will need to reset the password of the associated MSA to meet the password length and complexity requirement.
But before that, first, go to Settings > Accounts > Sign-in options, and from under Additional settings, disable the option to only allow Windows Hello sign-in.
Now sign out and you will find sign-in options available on the Windows sign-in screen. You will now be able to sign in to Windows using both the currently set Windows hello PIN or the Microsoft account password.
Sign in to Windows as per the method you wish to use.
After getting to Desktop, open the Company Portal app, go to the Device, and under Device status, expand the action item “Set a longer device password” and click on Resolve.
his brings you again to Settings > Accounts > Sign-in options. Expand Password and click on Change button.
You will need to verify first with your current Windows Hello PIN.
Next, you will be asked to provide the current password for your MSA.
Next, if you have 2FA configured, you will be asked to verify your identity for the same. And finally, you will be asked to create your new password.
Create a new password that matches the length and complexity requirements and click on Next. If the process is successful, you will get the below screen.
Click on Finish.
Now do a sign-out from Windows, and then while signing in back, instead of using the existing Windows Hello PIN, use the new password that you just created for your MSA, to sign in.
Post login, use the Check access button to confirm device compliance status in the Company Portal app.
Ending
As an Intune administrator, it’s crucial not only to understand the available configuration options and their limitations but also to comprehend how the policy behaves on the user’s device. This knowledge enables us to effectively educate users, as their interpretations and expectations often differ from reality.
