Microsoft Intune

You can use Intune to create a local admin account, but that doesn’t mean its a good idea

By on • ( 8 Comments )

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):

image
image

And sure enough, I can check an enrolled device and see that my “Dangerous” account has been created:

image

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:

image

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

8 replies »

  1. Hi Michael,

    Great post again.
    But when will LAPS or better local admin management be foreseen in Azure AD?
    Now we have to resort to lots of powershell scripting and customisation for settting helpdesk staff per country as local admin as there is only 1 device management role available.
    This should be possible out of the box, no?

    Liked by 1 person

  3. I do advise against it in new projects, but sometimes you just need it. I have Surface Laptops which after a re-imaging and autopilot, only get their Win10Pro activation through Activation troubleshooting in Settings with the local admin account. Using an Azure AD Global Admin will give an error.

    I have pushed the wmic command below through scripts to prevent password expiration, but this does result in limited password restriction configurations and compliance. I believe an Office 365 MDM setting can force expiration as well.

    WMIC USERACCOUNT WHERE “Name=’ADMIN'” SET PasswordExpires=FALSE

    Like

    • Actually not sure about the Win10 Pro activation part, as I believe it would only give an error if enter my global admin in the elevation prompt during a standard user session.

      Liked by 1 person

  4. “And LAPS works with the local Administrator account (having another local account is no more secure) too.”
    👆🏻 while the “is no more secure” part is technically true it’s still a well known fact that using a local account INSTEAD of the builtin\administrator is worth considering because that breaks attack and intelligence gathering vectors that aim for either the default name (“administrator”, “administrateur” etc.) or the default-sid (S-1-5-21domain-500 -> https://support.microsoft.com/en-sg/help/243330/well-known-security-identifiers-in-windows-operating-systems)

    Liked by 1 person

  5. One of the main reasons I’ve considered doing this is because we’ve had a couple of laptops get bad patches and blue screen on bootup. It was only then I discovered you can’t use the Windows recovery options without a local admin account. I agree I’d rather not set one up, but unless Microsoft provides some other way to do a repair on Windows without one I’m not sure there’s another option.

    Liked by 1 person