1

I am trying to work out a method that is easy to use, quick to enable and quick to deactivate when it comes to users requesting elevated permissions to carry out administrative tasks on their entra joined Windows devices.

I have been experimenting with EPM and PIM (Just in time) access, but these both have their issues and don’t quite cut the mustard in the way I was hoping. The EPM seemed ok at first for installing apps and running ‘some’ things as administrator, but it falls short on downloaded msi’s and doesn’t allow the user to change path variables and other system settings.

The PIM worked, eventually, but it took a while for a user to be added to the entra joined local admin group on the device, even after a reboot. I had to run some command to update the PRT and then log off and back on again for me to finally get admin rights. Not only that, but it’s the same in reverse, if I don’t log out after the expiry time, I still had admin access. Plus, we don’t like the idea of a standard user having admin rights, it’s just not best practice.

So, is there a way where a primary user of an Entra device can access the LAPS password for the configured user on their own device, use this to carry out the task at hand and then for the password to automatically rotate ready for the next use?

2 Spice ups
2

You can create a custom Entra role and assign the microsoft.directory/deviceLocalCredentials/password/read permission to it. Then anyone with the role can view LAPS passwords. The scope of the role can be limited with administrative units, but I’m not aware of a way to limit the user to viewing the password only for their workstation(s).

I guess you could use Graph API to retrieve the LAPS password and limit it to the user’s workstation(s), but that would require your users to run a custom script.

When this sort of situation has happened in the past, I looked up the LAPS password and sent it to the user in an encrypted email. Our LAPS policy would automatically log out the admin account and reset the password after a set number of hours.

1 Spice up
3

Thanks, that’s really interesting to know. Gives me something to research for tomorrow anyway! I just wish Microsoft would simply make a product that works and it’s easy to implement and use!!

4

giving the user the ability to lookup the Admin password anytime they want would seem equivalent to just giving them admin access.

LAPs would as you can have it automatically rotate the password once its been used, but I would make the end user request access so you still have control of the admin access.

1 Spice up
5

I understand where you are coming from, but one of the sole aims of this project is to reduce the amount of tickets put into the help desk. So requesting this password in a ticket is still creating work for the help desk team and delaying these users from doing their work. I have been looking at AdminByRequest but it’s a third party tool that needs sign off, but it does absolutely everything I need it to do!

6

Blockquote
I just wish Microsoft would simply make a product that works and it’s easy to implement and use!!

Microsoft thinks EPM is the solution.

7

How often would this be required?

If they can access the LAPS password any time they want, they’re effectively an admin.

I assume these are ‘IT’ type users, such as developers, rather than end users, like Toby in accounts.

2 Spice ups
8

Exactly that! Queue frequent looking at the amount of tickets raised for various software to be installed and path variables to be changed.

9

Any reason these users are on Intune managed machines in this case?

Our developers have been left on-prem, domain joined. If we ever do migrate them, they will be granted local admin access for the very reason you describe.

You have to weigh up the pros and cons of each situation, if they are going to frequently be a pain, LAPS may not be the solution either - have you seen the length of the codes. You may receive just as many tickets for people struggling to get the code right or it being ‘too stressful’ using it frequently, in which case you will likely add them as local admin anyway.

Setting the first logged on user as local admin, is as it’s name suggests, local to that device only.

Outside of the MS offerings, are 3rd party products as you have discovered, but this is an additional cost, is it going to be value for the number of users who may need this?

Good luck.

2 Spice ups
10

What we do, is establish a local administrative user with a strong password unique to each workstation. And, we provide this information only to the users who exercise good judgement. Many users do require administrative permission from time to time to install updates to software, install a piece of software they need, or configure something.
Not requiring IT for assistance with these tasks is important in our environment as well. Obviously this would not work for a bank, but for us it has been fine.

11

I don’t understand any of this - sorry if that seems uncaring.
If we are talking admins, then they should be able to see LAPS passwords.

If these are end users, even developers, they might need to elevate from time to time, and a ticketed trail SHOULD be necessary. Volume of tickets might escalate for sure, but there is a reason to maybe get some more help. Like others said, to do otherwise, you might just be better served making them local admins, which is a huge risk (only you can say if that is justified).

12

If the users in question are developers who need admin permissions on a regular basis over an extended period of time, LAPS is not the best solution for that scenario. For developers, I would give them a separate local admin account on the workstation. This way their regular user account is not an admin, but they can elevate to install software whenever they need it.