Home > IT Answers > CIO > Best practices involving admin rights for use...
kevins74
0 pts.
 Best practices involving admin rights for user on user system
Tech support, Disaster Recovery, Hardware, Network security, Firewalls, Intrusion management, Incident response, Forensics, Wireless, Security, Servers, Identity & Access Management, Digital certificates, provisioning, Biometrics, Routers, Security Program Management, Compliance, Risk management, Policies, Current threats, Viruses, worms, Hacking, Spyware, Trojans, backdoors, human factors, Application security, Encryption, Database, Secure Coding, Platform Security, vulnerability management, patching, configuration, PEN testing, Desktop management applications, Microsoft Systems Management Server, Systems management software, Project management, Business/IT alignment, VPN, Exchange security, Web security, Access control, Browsers, SSL/TLS, filtering, CRM, DataCenter, DataManagement, Single sign-on, Instant Messaging, Security tokens, Exchange
We are currently in the middle of figuring out the approach we are going to take in regard to a user having admin rights on their system. Typcially we set up a new user as an administrator on their system when they are logged into the domain. They don't have a local admin account on the system, just when they log in under our domain with their system, they have admin rights on their system.

I know the pro and cons of doing this in regard to security, but I will give an example. A user can load whatever software they want on the system. Good for the ones that are putting work type applications (not our standard Office, Adobe, spybot, adaware, etc..) bad for the ones that are loading any piece of software the found or heard about on tech TV the night prior.

By makign them just a user, they need to come to us for everything. Oh, you need to plug in a USB, talk to IT, oh you need activeX loaded for that one site you are going to, call IT.

I'd like to find the happy middle ground if that even exists. What are others doing in regard to controlling or for that matter, allowing what the users to do on their laptops. We have a pretty in depth setup with many offices and more then 1,000 users, so we are looking into the best approach.

Please let me know in as much detail as you are willing to type here, how you handle this issue in your environment. Right now we have security rules (paperwork) on how the computers are to be used but we all know, people are people and what they think they can get away with, they typcially will.

Thanks for any help,

KevinS
ASKED: Sep 26, 2006  4:23 PM GMT
UPDATED: August 18, 2010  7:58:34 PM GMT
RELATED QUESTIONS
Rschauer
15 pts.
Answer Wiki:
Not to resurrect this, but I came across this while looking for some best practices for restricting admin rights on workstations and think that our current configuration may help others.

Using a VB script we add a group that includes all IT service staff as local admin on each workstation. We also add "authenticated users" or "Everyone" to remote desktop users to enable all users to remotely access each machine. This makes swapping PC's less work.

***Start Script Code***
'File: ADGroupToLocal.vbs
option explicit
on error resume next 'this hides error messages like "group name already exists" from the user.
Dim DomainName, net, local
Dim UserAccount, group
set net = WScript.CreateObject("WScript.Network")
local = net.ComputerName
DomainName = "DomainName"

'first the local admin group
set group = GetObject("WinNT://"& local &"/Administrators")
group.Add "WinNT://"& DomainName &"/"& "Domain Admins"

'next the remote desktop users group
set group = GetObject("WinNT://"& local &"/Remote Desktop Users")

group.Add "WinNT://"& DomainName &"/"& "Domain Admins"

'wscript.echo "Done!"
***End Script***

We then removed all local admin rights to each user on each computer starting with a department at a time, picking a power user from each department as the pilot guinea pig. If any piece of software doesn't function properly, we go into program files and grant full access to "Authenticated Users" to that program's folder and all subfolders and files (make sure to propagate permissions down after changing the top level). We then document the changes required on the pilot and replicate them to the rest of the machines in the department. Once complete, we move to the next department.

What brought me here is my curiousity as far as how safe it would be to just grant full access to authenticated users to the whole program files folder. The theory behind removing admin rights is that viruses and users can not install software into critical areas of the OS. Enabling full access to Program Files I believe still follows this standard, but I'm concerned that viruses may use the program's ability to access the registry to get manipulative.

Does anyone do this currently and how does it work for you? Any virus issues?
Last Wiki Answer Submitted:  Aug 17, 2010  11:11 PM (GMT)  by  Rschauer   15 pts.
Latest Answer Wiki Contributors:  tobascofred   0 pts.
To see other answers submitted to the Answer Wiki View Answer History.
RSS - Discussions Help
Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



 

We have a large global base of users (15,000) and allow local system admin rights. We have also researched the option of ‘locking down’ the desktop and determined that it is not worth the trouble. (Windows Vista may resolve this through UAP.) From the companies we talked to that did reduce user privileges (in Windows XP Pro) they tell a tale of the difficulty to implement; the increased support costs; and lack of real security benefit. Our conclusion is that for our environment (manufacturing) reducing user privilege prior to Windows Vista is ‘all pain and no gain’.

I imagine that in certain high risk environments (financial, defense, etc) the equation might lead to a different conclusion.

stuberman
 0 pts.
 

I have many of the same problems as the both of you before me…..what I can tell you is that I am in a smaller shop so it is not as bad for me. The things that come to mind when I am dealing with this issue are 1) what is the need? 2)why is the need? 3) what are the iplications of giving rights to certain people? 4)what is the damage to my department in terms of extra work, and my relationship to the other staff for saying no about somehting? I should tell you that none of my users have Admin rights and I intend to keep it that way. I have run across the odd app that wants to run under Admin only and these can usually be fixed. I have a good policy in place, but as usual, the policy is only as good as the consequences and managment’s committment to them. I would be on the developers to make sure that all software written can be launched by any user on that machine.

Just some quick thoughts….

Best,
Paul

DrillO
 0 pts.
 

I have to say that your solution while seeming to create less work for yourself can lead to a true nightmare situation. I would not for a moment give users local admin rights as long as they’re on a domain. It’s an open invitation to fill your network with malware and opens you up to possible legal situations with users downloading and installing unlisenced software.

If you’re on a domain it’s easy and managable to control all software distribution through Active directory. You can published authorized software packages through group policy which the users will be able to install through the add/remove software applet in the control panel. Also when it comes to USB and other PnP devices, these should be controlled by you. If they have devices they use on a regular basis, you only need to allow installation once as an Admin, once the drivers are loaded they can use them in the future. I would also reccomend setting up a SUS server to allow you to test and authorize any windows updates and then automatically deploy them to your work stations. If you need help with this let me know.

Kjella
 0 pts.
 

I support a small manufacturing firm and also give several users priviledges on the local machine. However, my primary job is with a much bigger company. If you fall under any of the data protection acts (sorbanes oxley, medical data protection act, or have other personal data that could be compromised including credit card numbers, SSNs, or DoB) the pain is actually worth the benefit. Once you go through an investigation that leads to an employee “accidentally” installing software that allowed a trojan or someone taking personal data out on a USB drive, all the pain was worth it and will usually result in much less time overall.
Much of the decision will be based on whether you have corporate backing to implement this type of lockdown. It costs dollars now against a future risk of larger dollars and company embarassment.
Just some things to consider.

FlyNavy
 0 pts.
 

Thanks for the responses so far. I will give a little more info about my situation. Most of our people understand computers and work on contracts for their customers providing similiar services to what we provide our users. Everything from computer analysts, integrators, administrators, engineers, etc… This has good and bad points of course since everyone thinks they have the best way of doing things. Granted, these are the same guys that need help with their homes systems and their wireless networks. So we have all types. I guess it will probably come down to a few that have admin rights and a few that don’t have admin rights. Like if you are in accounting, perhaps you having admin rights isnt’ the best thing.

kevins74
 0 pts.
 

Five years ago, I made the decision to remove admin privileges from all users. They had been, intentionally sometimes and mostly not, downloading all sorts of garbage (malware, software that interferred with other programs, spyware, to mention just the most common) and we were totally unable to keep up with the clean-up jobs. That helped a lot. (I had a new supervisor come in four years ago who insisted on having admin rights, pushed pretty hard. So he got them. the result: twice in the first year, his computer had to be totally reformatted, losing all that he had installed. He is our biggest supporter now.)
We have had problems with required admin rights for some software only for some of the older packages. We have worked around the issue on anything written in the past three+ years.
This past summer, I took the next step: we went to a Citrix (terminal server) environment: it is a bear to set up, but now that it is running, I have total control over licensing (I have users in groups, although they can be treated individually) and I just drag that group to an application and all of those users (from any computer in the world!) have access to those apps, and no others. We did have to set up an https server for security but that was a small cost and time compared to the benefit. Now I can install an app on just a handful of servers in the “Citrix farm” and drag user group(s) to it, and I’m done. Same with updates.
The initial costs are more than offset by the ability to run older desktop units on the system, and they perform great. Then I have the added savings of personnel: don’t need as many technicians, who are hard to find to find anyway (good ones).
Don

dhindsley
 0 pts.
 

If you are regulated (SOx, etc.) or certified (ISO, etc.) or audited (CoBiT, etc.) local admin permissions are just another control objective to explain - and it is really easy to avoid with Microsoft Active Directory (see above.) Plus, providing local admin permissions opens your entire network up to malware until your enterprise anti-virus/anti-spyware system gets the new definitions deployed. With all the logging Trojan programs being deployed these days, don’t risk it. Use AD GPO to create a lock-down environment. This eliminates the risk of unlicensed/unauthorized software installations. Both unlicensed and unauthorized software installations are problems.

You can easily create Windows Security Template INF files to provide application specific permissions to the local file system and registry using the Windows Console (MMC). We also create a little EXE that implements them for either Windows 2000 (SecEdit) or XP (GPUpdate). As part of the installation, we copy the template to %WinDir%SecurityTemplates and execute the implementation script. This results in the permissions database (SBD) being created in %WinDir%SecurityDatabase and policy being refreshed. For the very few cases (

KingTut
 0 pts.
 

The person that suggested using active directory and placing users into groups, then giving rights based on group needs was right. That is the best solution. do yourselves a favor and close the ports to ftp and the like by using your firewall. active directory is easy to use once you get into it a little, it is VERY similar to Novell’s directory. giving users admin priv is asking for trouble. my masters degree is in information security, my best advice is that you can trust no one!! good luck

sandman328
 0 pts.
 

While I cannot hardly conceive giving all of my users Admin rights, if you must I guess you must. I would have something in writing when the network takes a left turn, and yes it will eventually. As you may have read in the recent VA Laptop story; the DB Admin initially took all of the blame for have the laptop with the un-encrypted info. Later it was revealed that he had written instructions to do exactly that and to work from home.

Anyway, I digress…

Look up Secure Wave’s Application Control. You will have initial calls but once it is set you should be good to go and you will be able to sleep at night knowing that they cannot download and install the App of the Day. I would also highly recommend their Device Control. You can specify which PC will allow a USB and restrict it to specific users. You can also specify which USB stick is allowed.

I would do this at a minimum for your circumstance.

Tim Bolton

Timbol
 0 pts.
 

I have been told by a colleague that AppSense works very good as well, compared to Secure Wave. I have not tried it myself but I do trust their advice.

Tim

Timbol
 0 pts.
 

Here are some links that may be just what you need…

SoftGrid which was recently purchased by Microsoft.

http://redmondmag.com/reviews/article.asp?editorialsid=519

http://www.microsoft.com/presspass/press/2006/jul06/07-17SoftricityPR.mspx

http://www.softricity.com/

Timbol
 0 pts.
 

As a small non-profit that supports a database app at several customers I can say that remote support on any XP systems that have been locked down by Admin folks proves in some cases to be very difficult if not impossible. Case in point, we are working with a customer currently that has just started using the database product we support. They, for administrative reasons, have their XP PCs locked down extreamly tight and while the office users do have “Admin” rights on the Local PC - they lack *any* items on desktop, no access to My Computer, Control Panels, Command Line and Scheduled Tasks (Which the product we support has about 7 Scheduled Tasks it requires). Keep in mind the DB product we support does communicate with other MS SQL Desktop boxes in their enviroment. It is an amaizing testment that MS SQL Desktop even runs on these boxes, but it does. Even to change something as minor as Date/Time we need for them to have their Admin folks come down and log in as Domain Admin (?) to do so. Big pain. They are having some issues and quite honestly it is turning into a finger pointing game on who’s fault the issues are. (Customers, SW Vendor or Ours) :-

r8escjohn
 0 pts.
 

As a small non-profit that supports a database app at several customers I can say that remote support on any XP systems that have been locked down by Admin folks proves in some cases to be very difficult if not impossible. Case in point, we are working with a customer currently that has just started using the database product we support. They, for administrative reasons, have their XP PCs locked down extreamly tight and while the office users do have “Admin” rights on the Local PC - they lack *any* items on desktop, no access to My Computer, Control Panels, Command Line and Scheduled Tasks (Which the product we support has about 7 Scheduled Tasks it requires). Keep in mind the DB product we support does communicate with other MS SQL Desktop boxes in their enviroment. It is an amaizing testment that MS SQL Desktop even runs on these boxes, but it does. Even to change something as minor as Date/Time we need for them to have their Admin folks come down and log in as Domain Admin (?) to do so. Big pain. They are having some issues and quite honestly it is turning into a finger pointing game on who’s fault the issues are. (Customers, SW Vendor or Ours) :-

r8escjohn
 0 pts.