Introduction
I’m currently blogging about a series of DEM in 20 webinars from 1E, you can find each episode that I’ve blogged about (including this one) below:
- Episode 1. How to find and fix Slow Endpoints
- Episode 2. That crashy app
- Episode 3. Dealing with annoying admin requests <- you are here
- Episode 4. That Change Management Success Rate Struggle
- Episode 5. Will Printer Audits continue to exist?
- Episode 6. Are non compliant devices dangerous ?
In a previous blog post I explained how to sign up for a webinar series and by doing so, learn from industry experts and Microsoft MVP’s about how and why they use tools like Tachyon from 1E to make things work better for your users, including how to deal with slow endpoints, or how to deal with apps that crash or for todays blog post, how to deal with those annoying admin requests.
Security
Love it or hate it, without security we’d all be in a worse situation. However security mandates as a best practice that the user logged on to Windows should be a standard user and not a local administrator. Why ? because that helps thwart the spread of damage to the operating system from running files that could overwrite operating system kernel files for example, or simply to keep root kits or viruses in check. Bad software can do bad things especially if you are a local administrator.
That said, most users will need to be able to install legitimate software or configure things that require local administrator permissions on their computer, so how can we deal with that in a seamless, automated way with Tachyon.
“Maybe you need an application for a demo, in 30 minutes.”
Software Installation Requests are the probably the most common reason why people request admin elevation. Here are some ways that people typically deal with local admin rights requests.
- Group Policy – It’s a bit of a legacy dinosaur. Not that granular. The downside is knowing did it apply to the right group, did you clean it up after wards.
- Local Admin Password solution – LAPS, giving out a password for the local admin account and risks associated with it, able to add others to the local admin group, security team not so happy about that.
How does Tachyon deal with this problem ?
Tachyon deals with this seamlessly and fast, but it doesn’t sacrifice security to enable this ability. It’s part of the Guaranteed state module, specifically the real time security broker (RSB) shown below.
This is made up of three rules listed here.
- RSB: Disable Inactive RDP
- RSB: Remove ‘Own Machine’ Local Admin escalations once timeout is exceeded.
- RSB: Remove unauthorised local admins.
Here’s an example of it how Tachyon deals with this from start to finish. This is broken down into a couple of actions which are security focused, in that the user must be whitelisted in order to be allowed local administrative privileges.
- Whitelisting an account/Verifying whitelisted account
- Adding that whitelisted account to the local admins group
Whitelisting an account
Below we can see a user (aneel) is logged on to PC0004 and we can clearly see that the user is not a member of the Local Admins group on that PC.
In the Tachyon Explorer console, you can search for RSB and then select RSB Whitelist: <Action> user <UserName> to add (or remove) a user.
Next, click on Edit (shown below with the red arrow) to add Parameters to your action.
In the parameters section on the right side of the console, select the device name that you want that user to have local admin permissions on.
Adding a user to local admin on PC0004 in Tachyon
After clicking Perform this action the request is then validated and any alternative accounts needed to approve the request will be informed to approve it.
After the instruction was approved you can see that the user has been whitelisted and all of this is in real time.
Verifying whitelisted account
To verify that the whitelist request has succeeded you can use the List Real-time Security Broker Whitelist action in Tachyon Explorer.
and in an instant you can see that the user has been added to the whitelist.
Adding the user to the Local Admins group
Next, you actually add the user (aneel) to the Local Admins Group. In Tachyon Explorer use the RSB Command: Add user <UserName> to the Local Administrators group, ONLY ON HOST: <hostname>.
After performing the action you can see that the user is added to the Local Admins group.
The entire process took less than a minute to whitelist and then add the user to the local admins group including the secondary approvals.
You can also set the amount of time needed, for example give the user 30 minutes of Local Admin time.
What about Self service for the end user ?
If you want to allow your users to do this on their own, to elevate on demand using self-service, it’s possible as long as they’ve been given the correct permissions/ability. We can deploy an app called “Escalate to local admin” via Tacyhon to a small subset of users whom we trust to use appropriately.
Below we can see another user (Ataylor) is logged on to PC0005 and this user is not a member of the Local admins group.
This user launches the “Escalate to local admin” app so that they can self-service (with 2FA) the action themselves.
and after clicking Go and satisfying the security prompts, the user is now added to the local admins group.
Users behaving badly
What about users adding other accounts without permission, below we can see a user that was granted local admin permissions has decided to add another user (sneakyadmin) to the local admins group.
But no sooner than they click Apply, they are informed that the unauthorized action was denied. This is because the user added was not authorized via the Tachyon platform, and was instantly denied, not only that but the action has been logged and undone.
going back into the Local Admins group you can see that the sneakyadmin account is not listed any more.
Reporting on actions
If you look in the Guaranteed State rules which drive this you can see that the action has been remediated, this is revealed under Report, Remediations.
Conclusion
Using Tachyon to provide admin credentials using security focused methods is easy and painless, yet retains useful features such as auditing, whitelisting and the ability to deny unapproved users.
That’s it for this blog post, I hope to see you in the next one. In the meantime, I’d suggest that you sign up for the next DEM webinar, it’s free, tell them Niall sent you ?.
And for those of you who want to see previously published episodes on youtube please click here.
