There are a variety of blog posts that talk about creating a local account on a device, to be used as a “break glass” account in case anything ever happens where the user can’t sign in. That’s not too hard to do using custom OMA-URIs, since the Accounts CSP already supports that. You can specify the account name and password (together on one URI) and that the account should be an administrator (URI #2):
And sure enough, I can check an enrolled device and see that my “Dangerous” account has been created:
I would use “Get-LocalGroupMember” to show that it’s actually in the Administrators group, but that generates an error. So I’ll look in Computer Management:
Yay, so it worked. Now let me talk you out of doing it:
- First, it’s a really bad idea to have an account on every device with the same name and password, especially if anyone knows what that password is. You would be a hacker’s dream customer. Don’t become the next press headline.
- The account will be set with an expiring password. So if you ever tried to use it, the first thing it would do is ask you to change the password to something else. Same problem as above if you tell everyone what to set it to next. A new problem if everyone picks their own new password.
- You really should have a way to randomize and save the passwords, kind of like LAPS – although that requires Active Directory (no support for Azure AD yet). And LAPS works with the local Administrator account (having another local account is no more secure) too.
- If you do this as a device-targeted policy during Windows Autopilot with Hybrid Azure AD Join, the user signing into the device won’t get admin rights, even if you specified that in the Autopilot profile. That’s because the logic that assigns those admin rights won’t add a new admin account if there is already an enabled local administrator. (You could do it as a user-targeted policy, so it gets applied after the admin rights are granted.)
You could probably “build your own LAPS” solution using PowerShell as an alternative to this, but doing it securely is not an easy task.
I think it’s a better idea to think of Intune as your “break glass” account. Even if the domain trust is broken and no domain users can sign onto the device, it will still be managed by Intune. In that situation, target a script to it to create the needed account “just in time.” Use it, fix the device, remove the account.
Categories: Microsoft Intune