One thing I think everyone can easily agree on, if you’re running your main daily device with a user with full Admin rights, you’re just asking for trouble…
Just think about it, it only takes one malicious mail/script/executable to run on that system in the user’s context and it now basically owns that system. Certainly, for IT Support, it’s quite common for that user to also have higher privileges on that same account to backend servers and other infrastructure, which means lateral movement from that owned box becomes fairly trivial.
Don’t get me wrong, being a techie, I’ve always insisted on having local admin rights, I simply couldn’t imagine not being able to run things like PowerShell as an admin or installing a quick app myself etc.
And don’t even get me started on Developers and their needs… 😉
So… what options are there and what pain can be expected to try and remove admin rights?
Let’s start by breaking it down and focus first on getting people out of the local administrators group on devices before trying to tackle things like Exchange or SharePoint admin rights.
Option one – Additional Accounts
So this is probably the lowest cost option. Simply remove all admin permissions from the users main account (which also aligns with the recommended practice that no account used for browsing the web or e-mail ever has admin permissions!!) and give them a dedicated account which has no access to mail etc that can be used to elevate when prompted with a UAC box.
Sounds easy, which it is to implement, but it then means additional hoops to jump through and multiple credentials to remember that will need manually typing each time to perform an elevated task.
Be prepared for the “fun” conversations with people that previously had admin permissions and aren’t happy with the idea of typing in 16 character long complex passwords (you are implementing strong passwords aren’t you?) every time they want to do a quick task needing admin rights.
From an IT support (Service Desk) perspective, you may also want to consider adding their accounts to all the other devices Local Admins group to allow the support teams to elevate on those devices to perform admin tasks, however then you need to make sure those accounts are well monitored and secured otherwise lateral movement in the environment becomes easy again if one of those credentials are compromised.
Note: LAPS is another option here, but adds some more hoops for digging out passwords but is better for preventing lateral movement.
| Pro | Con |
|---|---|
|
Free – Except time to design and implement |
Users have multiple credentials to remember |
|
Introduces recommended practice for daily usage accounts |
Extra effort to authenticate |
|
|
New admin accounts at risk of compromise |
|
|
Admin account usage monitoring should be considered |
Option two – Privileged Access Management Solution
When talking to organisations about how to counter the challenges with option 1, I often get asked what we do internally.
Being a heavily technical resource biased company, it was very apparent that I would be taken outside and lynched if I removed all our consultant’s admin permissions and had them typing in passwords multiple times a day and I quite enjoy breathing…
So after looking at what options were available within the native Microsoft stack and within our licensing (Leveraging the investment in your Microsoft licensing is a key tenancy at PowerON) and, surprisingly, not finding any native solution while also ruling out any custom automation approaches, we went further afield to see what else there was in the market.
There are a few different vendors on the market with PAM solutions, each with their own approach and features, but after doing the rounds we chose to implement AdminByRequest (ABR).
Their offering gave us a quick and easy way to rollout a solution (that can automatically strip users from the local admins group) and integrates with the UAC/RunAs Administrator process and more importantly, not prompt for credentials.
Instead, we now have the capability to either whitelist applications/users to be allowed to run with elevated permissions automatically or specifically prompt for a reason that can then be reviewed by the Service Desk and approved for running.
Did you spot the important bit there? Applications are elevated… we’re not granting full administrative permissions to the full device; we’re selectively elevating an application for the duration of its running session. Users are never members of the local admins group and are never running their full system in the admin context.
We’ve also gained full auditing and reporting capabilities, enabling us to see who is elevating what and when, including child tasks that elevation spawns.
There’s a ton of other features within the solution, but I’ll leave the deeper dive for another post…
| Pro | Con |
|---|---|
|
Introduces recommended practice for daily usage accounts |
Low Cost, but easy to implement and maintain
(I had to have something in the con list!!)
|
|
Users don’t have to remember multiple credentials. |
|
|
Extra effort to authenticate |
|
|
Admin rights usage monitoring built-in |
|
|
No new admin accounts at risk of compromise |
|
|
Supports Azure AD Only Joined Devices |
|
|
Cloud Based SaaS solution |
As you can see from the Pro/Con list, it basically addresses the pain points from option 1, meaning no new accounts, no additional complex passwords to type, no worry of lateral movement from a device as accounts aren’t local admins and definitely more important, no grumpy end users!!
Another huge benefit is the support and integration into Azure AD for those organisations focused on Modern Management and moving away from on-premises traditional infrastructure, along with the fact that ABR itself is a cloud based product meaning no on-premises infrastructure required to deploy and nothing to maintain for the platform.
If you can’t wait for the next blog post where I’ll be diving into more depth on AdminByRequest, feel free to reach out to myself or the team and we’ll happily answer any questions or show you it in action.
Share on:
