Restricting Admin Access to Your PCs

How secure are your PCs? Do you know who all of the administrators are on them? Do all of the people that are administrators on them really need to be?

In order to maintain good security in your environment you need to know for certain what is going on and who is doing it. You need to know who has access to what, why they have access to these devices, and what they are doing on them. If you do not know who the administrators are on your PCs and what they are doing to them you are in a very unsecure state.

Best practice computer security guidelines state that a person should only have access to the applications and computers that enable them to do their job. Any access beyond that is an unnecessary risk.

This was a challenge that our company faced. We found ourselves with over 100 people having PC Admin access to all of the PCs in the company. Obviously that was not a good idea. Especially since most of these people only needed it to support their one application that might only be installed on 50 PCs. We needed to find a solution to shrink the number of PC administrators we had while still allowing them to do their needed jobs.

We tossed around several possible ideas of how to solve this problem.

1. Have people request access to the individual PCs that they require rights to. Then a system administrator could add them into the admin groups on those PCs only.
   Pro: Limits the access to only what they need.
   Con: Large amount of management time and complicated auditing.
2. Create domain groups for each Application Team and add these to computers that they support.
   Pro: Limits the access to only what they need. Simple to manage as users would only have to be placed in one group.
   Con: Hard to know what PCs to add the domain groups to. Many Application Teams support multiple applications and some team members work for multiple teams.
3. Create a web page that people could go to and request access to a PC. The background process would add them to the local administrator group on the PC and later remove them from it automatically.
   Pro: Easy to manage. Allows access to only what is needed and only while they are using it.
   Con: System fails if PC is turned off or having other WMI issues. No way to tell if they legitimately need access to the PC. Would require time to audit the usage of the system.
4. Create a web page for people to request access to a PC. This would create two tasks in Altiris. One to add them to the local Administrators group and a second to remove them from the group. The second task would be scheduled 24 hours later and would run regardless of the network connectivity of the PC.
   Pro: Easy to manage. Works regardless of the state the PC is in. Only gives access to the systems that are needed.
   Con: Complicated setup process to create the web page. Requires people to submit manual requests for every PC they support.

While these ideas would all accomplish the task we really did not like all of the disadvantages that they came with. We wanted something that would not require a lot of setup and would integrate into the existing structure that we already had. We also had the challenge of making the application teams happy and allow them to do their jobs. After all a project is only successful if people actually use it.

Another huge hurdle was that this had to be implemented in a way that did not cause a big upset. If managers start getting complaints that their people are not able to do their job because the security teams are hard to work with you will immediately lose. So we had to pick a solution that would give us the security standards we wanted, give application teams the access they needed, and do it all without investing hundreds of hours in development or management.

What We Did

After beating our brains on this for weeks we finally realized that the answer was in front of us the whole time. Use Notification Server to do all the work for us. With Inventory Solution we have a list of every application that is installed and where it is installed. We have a list of who is in the Administrators group on each PC. With Software Delivery Solution we can execute any script we want based on the above criteria.

We took this knowledge and developed what we call Application Admins. We created Active Directory domain groups for each application. Created collections for all of the PCs that had these applications installed. Then created scripts to add and remove these domain groups from the PCs based on the collections that they were in.

That was the high level view and here are the details of how it is implemented.

In this example we will setup access for our DBA's who support Microsoft SQL Server.

Create the Group

The first step is to create your Active Directory domain group. This is the group that you are going to place all of your users in that support MS SQL. The benefit here is that a person would simply request access to support SQL and not have to request access to individual PCs. It also wouldn't matter what department they are in since this is application driven not department driven. So create a domain group called "AppAdmins - MS SQL Server".

Create the Collections

Now we can go and create our collections. To make this work we will need to have two collections. One collection will be a list of all the PCs that have MS SQL Server installed. The second collection will be a list of all the PCs that do not have MS SQL Server installed but do have AppAdmins - MS SQL Server in the local administrators group.

Create a collection called "MS SQL Server Installed" using the SQL code shown below.

Select v.[Guid]  
FROM dbo.Inv_AeX_OS_Add_Remove_Programs SW   
Left Join vComputer v ON SW.[_ResourceGuid] = v.[Guid]  
WHERE SW.[Name] Like 'Microsoft SQL Server%'

Create a second collection called "AppAdmins - MS SQL Server in Local Admins and MS SQL Server not installed" using the SQL code shown below.

Select v.[Guid]   
From  Inv_AeX_OS_Admin_Group lg   
Left Join vComputer v ON lg.[_ResourceGuid] = v.[Guid]   
Where lg.[Member] = 'AppAdmins - MS SQL Server'

In the Exclusions for this collection add in the first collection we made called "MS SQL Server Installed".

We now have our list of PCs that should have the domain group in their local administrator group and the list that should not have it. Now we need to setup the scripts that will add and remove the domain group from the PC.

Create the Jobs

We will need to create 2 packages and 2 tasks. One of these jobs will be to add the domain group to the administrator group. The second job will be to remove the domain group from the administrator group. We will also have 2 VB Scripts to go along with these jobs.

Use the Software Delivery Solution wizard to create two new packages and tasks. Name the first one "MS SQL Server Admins Add" and point the package to the attached VB Script named MSSQLServerAdd.vbs. Have this task use the "MS SQL Server Installed" collection. This will add our "AppAdmins - MS SQL Server" domain group into the local administrator group for all of the PCs in this collection.

Create a second package and task named "MS SQL Server Admins Remove" and point the package to the attached VB Script named MSSQLServerRemove.vbs. Have this task use the "AppAdmins - MS SQL Server in Local Admins and MS SQL Server not installed" collection. This will remove the "AppAdmins - MS SQL Server" domain group from PCs that no longer have MS SQL Server installed. This way you have a process that will automatically clean up the administrator groups on the PCs.

Your Done

Once you Enable these new tasks your process is now in place. Users that need to be able to support MS SQL Server just have to be added into your domain group and they will immediately have access to all the PCs that they need to support without having access to the entire company.

To set this process up for other applications just change the names in the SQL query and in the VB Scripts. Everything else can be just be cloned and named accordingly.

This is a very simple process to implement and has proven very effective for us. We have implemented this with about 10 applications so far and have not had any complaints.

The one thought you might have is how do the applications get installed on the PC in the first place? Think about this, should you really be deploying software using manual installs? Isn't that why you bought Notification Server in the first place? What a great time to setup deployment packages for your software with Software Delivery Solution or Task Server. This way you are moving towards a much more automated and controlled environment.

There is a small amount of overhead in building all of these groups and collections but this could all be scripted using the ASDK. That is another project that I will post on later once I have it built.