If you are ‘scoping out’ a Local Admin rights management solution, Admin By Request hits the target!
Admin By Request enables I.T. administrators to effortlessly manage & audit the granting of Local Administrator rights throughout their organisation.
Without Admin By Request, administrators generally have to consider:
- Allowing users that need Local Admin rights to do their jobs to have it: A major security framework non-conformity.
- Deny Local Admin rights for everyone and have I.T. perform remote sessions to perform elevation actions for these users: A major productivity problem.
Neither of these options fill the I.T. manager with a particular sense of joy.
What he / she needs is a centralised privilege management solution that can:
- Identify and remove existing Local Admin accounts if they exist.
- Provide a ‘request workflow’ via a SaaS portal where users request admin as and when they need it.
- Enable control of either per ‘app’ or entire session Local Admin rights
- Grant users Local Admin for a limited period of time, on a countdown timer.
- Require users to submit a reason for the elevation request in advance if required.
- Audit installed / removed and executed programs that occur during the elevated session.
- Requires no server infrastructure, easy to set up with a free trial account.
As an I.T. manager, you will be well aware that although the ‘concept’ of Local Admin rights management is ‘palatable’ to staff (without invoking a staff revolt of yellow vest proportions) immediately after implementation, you will quickly discover two things:
- That you will need to be either more or less strict with certain groups of staff
- You will want to ‘offload’ (delegate) the ability to grant approvals directly to the managers that look after these groups
Out of the box, Admin By Request comes shipped with only ‘global’ settings enabled. So it’s one rule for everyone. To get the best out of our solution, and to give the best experience to your users (and to avoid revolts!) we recommend checking out our ‘Sub Setting’ feature. Sub Settings: Set who gets what
As previously mentioned, the global settings apply to everyone, and is how Admin By Request comes configured out of the box. Think of these settings for your entire implementation as a sort of ‘catch all’. So anyone not covered by a sub-setting, (home workers that might be off AD for example) will get caught by this. As such, we recommend making the ‘default’ global settings highly restrictive.
In the below example, we have decided we want to create a special sub setting for ‘Web Developers’. In our case, Web Developers are contained within the company wide, computer group of ‘Web-Developers’, so we add the setting in for that under ‘Computer in group’. Then we want to zero in on just those in the UK or US Development teams, by selecting the computer OUs for these developers. So these configuration options are treated as AND operators. Once the scope of the setting has been defined, you can then go and decide what elevation type settings to apply to these users.
There are only a few exceptions, so most global settings can be set at the sub setting level.
After this setting, we can now set UK and US web developers to:
- Enable ‘Run As’ type of elevations, if not enabled for the entire organisation
- Not require approval for ‘Run As Admin’ elevations, but still require approval for ‘full session’ elevations
- Increase the amount of ‘access time’ given for ‘full session’ elevation
This is all fine, but as mentioned before, if we leave the defaults as they are, the notification emails for Developer elevation requests will be taken from the Global Default settings and therefore bombard the IT Helpdesk with requests. In order to send the notifications from members of this sub setting to the Development Manager, we need to change this on the Sub Settings ‘Notifications’ tab:
Excellent, now elevation requests from Development can be all be handed ‘in department’, by the development manager. He is the best person to know what software should and should not be allowed to run from his own staff.
But wait! When the Development Manager logs into the portal to process a request, as things currently stand, he/she is going to see requests for the whole company, potentially 1,000s of computers!
So we move on the the next part – Portal User Scopes – to ensure that the Development Manager only sees requests and computers for his own team.
Portal User Scopes: Set who sees what
So with the portal user scope feature, you can filter any portal user to show just those OUs / groups that are relevant. Unfortunately this feature is not available on the trial version, so if you have signed up to the trial edition and would like to see it in action, please get in touch for a demo. Those on a production license, you access Portal User Scopes via the ‘Logins’ menu on the top right of the portal menu:
Once on the Portal User Scope page, all you have to do is select the portal user account you wish to ‘scope’ from the Portal User drop down, and then define what users / computers you would like this portal user to see:
On this screen you can also choose to filter out the type of Admin By Request agent if you are running them, you could block out servers for example.
So this is really all you have to do!
With this setup the developers get custom settings just for them, and their manager can not only process elevation requests themselves, but he only gets to see their agents in the portal. That’s awesome for productivity!
Summary
Admin By Request’s powerful granular settings deliver both increased security AND productivity for organisations struggling with their Local Admin rights management dilemma.
We have not only given IT Administrators the ability to perform very powerful granular distribution of multiple Local Admin policies, but also the ability to delegate the management of Local Admin rights to responsible & relevant departments, whilst still giving central I.T. departments a ‘global view’ of everything going on in the business.
