SkipToTheEndpoint
UAC prompt for standard user does not ask for username on Win11 (but does on Win10)
Believe to be related to settings in Win - OIB - Device Security - D - Local Security Policies - v3.0
On Windows 10, UAC prompts for username and password
On Windows 11, UAC prompts for Administrator password
Hi.
So I've spun up a VM of both OS versions and I'm not able to replicate that behaviour:
What Windows version are you on on the W10? April Cumulative? If it's automatically entering Administrator as the user on W11 - it may be due to LAPS. Windows 10 only supports LAPS from a more recent build I think.
What Windows version are you on on the W10? April Cumulative? If it's automatically entering Administrator as the user on W11 - it may be due to LAPS. Windows 10 only supports LAPS from a more recent build I think.
W10 is on the May 14th update, version is 10.0.19045.4412, and LAPS is working fine on both 10 and 11.
The baseline implements LAPS using the built-in Administrator account, but again, I'm not able to replicate the behaviour on any VM I've tested and always get blank username/password boxes with the ability to use a different account. Are you applying any other policies, or have you changed anything else in the baseline?
No other policies (outside of OIB) being applied.
I've found that if I disabled the built in administrator account, the UAC prompt only has a 'no' button - nothing else is configurable.
Conversely, if I create a new local account and add it to the local admins group - the UAC prompt then allows me to select from the 2 administrator accounts.
So essentially, it is only enumerating the members of the local administrators group.
This is reproducible in 2 tenants - including on a freshly autopilot deployed machine.
I just found this - suspect it is relevant, as I have enabled passwordless.
https://www.theexperienceblog.com/2023/09/18/enable-the-passwordless-experience-in-windows-11-to-enhance-identity-security/
I am having the same issue. Only the built-in administrator account is displayed.
I have the same behaviour, UAC appears but only option was to click no until I enabled LAPS on the tenant, now Administrator is selected and I can use the LAPS password. I believe this is expected behaviour with passwordless.
Yes, reading that article it looks like this is intended behavior. Luckily my helpdesk guys do not need to elevate as admin on user devices very often since I have all of our apps packaged to install if needed.
I've got this on multiple devices in multiple tenants, even with LAPS enabled, the sign-in breaks and we're now unable to use the Entra Role for administration. Using the LAPS password isn't working as the administrator get's defaulted to azuread\administrator instead of .\administrator. Have anyone found a way to circumvent this?
@SFMextrico
As others have mentioned, removing the ability to manually type an account seems to be the intended behaviour here if you're deploying the Passwordless configurations.
To be clear though, the below UAC prompt "Administrator" account is the local .\Administrator and you can utilise the LAPS password to elevate:
I've been doing some testing with some of the Insider CSP settings available for LAPS and if you utilise a different account other than the built-in, you do get the "More choices" dialogue, but still only local accounts are selectable:
There is no circumventing this, outside of removing the Passwordless config.
It should be the local administrator, but for some reason when trying to use the LAPS password it throws a password error and the user account gets changed to Azuread\administrator
I didn't know this was caused by the Passwordless experience, i'll try to remove the policy, thanks for the reply.
It seems a bit wierd that this is the intended use while also having an entra role for local administrator, imo
I just wanted to share my finding regarding this;
While on a device with the passwordless experience configured you're able to sign-in with your entra admin or any other admin account by simply using "Sign in as another user" This'll "bypass" the intended experience of only having the local administrator accounts to choose between.