Tuesday 6 July 2010

Administrator Privileges – Control and Monitoring

From Geoff Courts @macnamara_geoff

The reasons for limiting the administrator rights of users are numerous. Don’t let them install any old application they find (they can do that on their iPhone), but perhaps more importantly, don’t let them install the viruses and malware that arrive through ads and spoof e-mails, that require in some cases lengthy clean-up operations and the PC out of action for the duration.


But as an Administrator, how can you effectively monitor the administrator rights across all your machines and all your users?


At Macnamara, we developed some time ago the method of only assigning admin rights to users upon request from an authorised client contact, along with the stated reason. But, instead of assigning the user the rights to their machine, we add them to a security group in Active Directory called ‘Local PC Admins’.


The benefits of this approach are:

1. you can centrally manage the admin rights of all your users
2. you don’t need access to the user’s PC remotely to assign it
3. if their PC is off, you don’t risk them logging back on as Administrator before you can revoke their privileges
4. You can assign 1 user rights on all machines, and delegate software installs and updates (where Kaseya cannot do this) to them.


As always, however, monitoring is the key.


Monitor the local Administrator Group

We only ever have 4 members of the local Administrators group.

1. Domainname\Domain Admins (Domain Administrators Group – i.e. us!)
2. Domainname\Local PC Admins (Our group for assigning local PC administrator privileges)
3. Administrator (The local Administrator account – password protected, of course)
4. Lynx-admin (Our own fall-back local logon user account)


Since this will never change, all we have to do is to output the membership to a file on a regular basis, then use Kaseya to monitor that file for any changes. Any unauthorised additions to the account since the last hourly check will create an alert.


A Script is run every hour that runs the CMD “net localgroup administrators” and outputs the results to a text file on the PC. The same script then uses the ‘Get File’ command to upload the log to the Kaseya Server.


Under Alerts monitoring, we use the ‘Get File’ alert to call a second script if the file content has changed. This raises an alert, and sends us an e-mail with the contents of the file, and hence the membership of the local account. Any users not in the 4 listed above can be easily identified.


Monitor the Server ‘Local PC Admins’ Group


Similarly, we can monitor the membership of the group we use in Active Directory for central management of the Admin Rights of our clients. Because we assign these rights ourselves, through request, we can monitor the membership using our ticketing system. All users are requested to let us know when they can finished what they are doing so we can revoke their rights, and then a log off is requested.
We don’t therefore need to monitor membership hourly, but it is good to have a reminder at the end of the day if anyone has been added who has not been removed. We therefore check every 8 hours, starting at 08:30am, so that at 4:30pm we receive an alert if anyone has been added during the day but not yet removed.
The process is the same as for the local Administrators group, but the CMD is slightly different. At 08:30am, the first script runs ‘net group “local pc admins” /domain’ and outputs the user membership to a file, which is uploaded to the Kaseya Server using the ‘Get File’ command. This is then run again at 4:30 and any changes are seen and an alert e-mail is sent with the membership of the group.


Benefits


Since we implemented these controls on administrator rights, we have seen the number of Support calls drop substantially, since Users are just not in the same position that they were to break their machines. Without these rights they can install bad applications that ruin system performance, nor viruses and malware, nor change protected system files. The results are cleaner machines, and more time for real work.

1 comment:

  1. I don't understand where your #lynxtemp# is actually saving stuff to.

    ReplyDelete