Windows hosts file, - Unable to edit issue - Can anyone advise please?

[O365-Zende]

We have hit an issue with a user being unable to edit the Windows hosts file; he is a developer, so he does do this from time to time.

He tries to open it as admin, but it won't let him in with his normal auth. He is a local admin. Oddly, it states that Notepad will be installed for the admin.

Yes, I'm aware it's not ideal having users as LA, but this is what I have to work with.

You guys know these policies way better than I do
Are there any specific policies you could point me towards that would affect the access to that file to make edits, by account blocking, etc.?

I have already disabled these.
Win - OIB - ES - Local Group Membership - D - Local Administrators - v3.7
Win - OIB - SC - Device Security - D - Local Security Policies (24H2+) - v3.6
Win - OIB - SC - Microsoft Accounts - D - Configuration - v3.2

Hopefully your better knowledge of OIB can point me to the right place

Many thanks

[incedIT]

If he is a local admin then he can complete UAC and perform admin functions. Have you looked at the security tab of the hosts file and tried removing write permissions for the local administrator group? If he has local admin then you would also want to block PsExec so he can't operate as the SYSTEM account, maybe ASR can help with this or a WDAC/Applocker block.

These are just ideas off the top of my head, you should consider repercussions of each. If he needs to edit HOSTS for his dev work then maybe suggest a VM?

[O365-Zende]

I mis-read the original message, I read it as he can edit when he shouldn't be able to. What happens when he runs as admin?

It puts the box up but he cant auth with his account,

Thats what he sent me

[incedIT]

I mis-read the original message, I read it as he can edit when he shouldn't be able to. What happens when he runs as admin?

It puts the box up but he cant auth with his account

Ok, try the changes I suggested in my last message and see if that helps, rather than just ask for UAC consent, it should prompt for creds.

[O365-Zende]

Ok many thanks for the help, ill report back

[O365-Zende]

Ok, try the changes I suggested in my last message and see if that helps, rather than just ask for UAC consent, it should prompt for creds.

Hi, ok, that's spawned through to one test machine. I'm struggling for the others to collect the setting.

1. Is it an Entra ID-only thing?
2. On the test machine that has worked, it gives a username and password box.
   Then when you use them, it follows with this box
   Sorry, bad image

And then it won't go any further; even the account has a warning that you need to log in as admin (its already an admin or should be) to make device changes.

I even logged in a separate local device admin and i get the same errors

So it can't elevate like it's supposed to.. very weird

[incedIT]

The only other thing I can think for you to try is if that user signs into their system using an AAD account, add that account as a local admin on that machine:
Net localgroup Administrators /add "AzureAD\**FullEmailAddress**"
If it still doesn't work then I am unsure what is causing it as I haven't had issues like this.

[Michael-eit]

Unsure if this will help but I vaguely remember SSO causing issues. I do however forget what policy it was tied under. (we had a client that had to log into AD so having the username autofill out with LAPS or themselves was causing issues)
Also I noticed incorrect Pin, Has password been tried?
Lastly if your using a "Local user group membership" and using a group you will need to login as that user before the policy applied to a members group.

[O365-Zende]

Update
Still wading through the clear-up and resolving issues with user accounts, but we are getting there now.

From what I can tell this was the main culprit, which was allowed to access machines it shouldn't have.
Win - OIB - ES - Local Group Membership - D - Local Administrators - v3.7 Add(Replace)

Because it accessed non-LAPS-capable machines, it downgraded everyone's account to standard.
All our guys run with Admin (yes, I'm aware it's bad, but our team is very specialised)

It's been a steep curve to get them operational again, fortunately with a small team.

Possibly because of the extra machines which are non-autopiloted, LAPS didn't seem to work right either. So we have had to go back to the smaller policy, and I'll have to rebuild it slowly again.

Life and times of IT lol

Thanks for the help guys