The SysAdmin Network

No more hiding in the server room

Hey folks,

I was wondering how many of you run with your users having full administrative privileges to their desktops? 

We have recently made the switch to locking down our desktops and we have understandably hit some resistance. Many people see their machine as their own (They don't realise it belongs to the company), and as such they have historically installed whatever they wanted to the machines.

Whichever side of the fence you're on could you try and explain why you do or don't give your users administrative rights?

Our reasons for removing them were to allow us to manage the software installed on our systems (For license compliance reasons) and to attempt to address the number of PC issues which were related to people fiddling with their PC's settings (Hint, there were lots of those).

Dan

Edit: Modified the title as it no longer made sense once the post was written.

Tags: Admin, Privilages

Views: 926

Reply to This

Replies to This Discussion

We give staff Local Admin rights to thier PC's. However we also use Group Policy to limit what they recieve to thier desktop. We also redirect folders this way to. Those settings that we really don't want people altering such as AntiVirus are limited this way. Some of our more IT literate staff such as School of Computing are able to push their machine settings to the limit but more routine users such as Administrative staff never look to change much more than thier desktop theme. As you say we do this to ensure compliance. Our users accept this and there is never any real complaints. We also have a Security Officer that we freighten people with if they get bolshie.
I've never worked in a place where users were completely restricted to user level accounts across the board. One place was always in a struggle to remove admin rights from it's 200+ userbase, but it always seemed like a distant dream. We would remove admin rights when a user would receive a new computer or had to have some major overhaul on an existing PC. Our motives were to restrict virus problems and problems that were traced back to some crazy piece of flash-and-glam software (I'm looking at YOU stardock!!).

The ultimate problem with it all was that users could not install software and patches could not be applied. Adobe Reader, Java Runtime, and a few others were problems. We were looking into SMS 2003 as a means of automated software deployment, but lacked the resources to implement it correctly.

In the future, I'd love to automate software deployment and collection through something like SCCM so that users can have user accounts as well as the flexibility of easy software installation. Until then, it's an administrator zoo out there.
We don't have anyone running as a local admin bar a few laptop users. Yes even the Managing Partner, Senior Partners and me only run as normal users. I implemented this years ago as there was no software control, no AV control, no standard images etc etc.

Did it cause a lot of grief pushing it through? Sure. Was it worth it? HELL YES!

Combining restricted local rights with group policy defined settings and deploying of applications has cut the desktop support cost by at least two thirds. The whole IT team now knows that they can walk up to any PC and it will have the company standard image on it, no OEM bloat-ware and only applications that have been approved and deployed.

To my way of thinking it takes a little bit longer to do a few minor things (eg: install local printers as opposed to hosting them on a server) but once this is in place you save so much time and effort.

Using the printer example you need elevated rights to install a local printer so if you have 30 people doing this you'll end up with about 20 different configurations. However if you host the printer on a server and then either push via GPO / logon script or allow the use to connect (ie: right click printer and hit connect) you'll have a total of one printer driver in use and one printer configuration. Image how much easier that is to troubleshoot.

As another example let us consider Microsoft Office. How many different configurations could you get if you simply gave the install CDs to 200 users and told them to install it locally however they like? Now consider how many possible issues that could cause. Things like people setting their Outlook accounts different alone cause nightmares. However if you were to create an admin install point on a server, or better in a dfs, and then deploy it to 200 users using GPO's you have a total of one configuration and only very minor tweaks for each user. Take this one from me - that is a lot easier to support!

Admin rights don't just affect software installations though. Think about updates to the OS or hardware. If you've got the users doing that manually I guarantee you there will be nothing like a standard approach. Some machines will still be exactly as they were issued whilst some will be using bleeding edge patches and updates....... no idea which one would be more stable but both worry me! :o) lol However by implementing restricted rights and a centralised patching system such as WSUS, which is free BTW, then you can control a lot of this. Don't know if IE8 will work with your web based accounts package? block it in WSUS, manually install it on a few machines and test it. If it works, roll it out but if it doesn't you've only lost those few machines which you can easily roll back.

Admin rights are the bain of an IT admin's life. Removing them automatically is a piece of ease though. We use a few scripts at logon to sneakily remove the user from that admin group without them knowing. As soon as they log off they are no longer part of the group but a restricted user.
Thanks for your replies so far guys, its quite illuminating.

Wesley, you're right that the ultimate problem is that users can't install software or deploy updates. That's something we are attempting to over come, we're running System Center Configuration Manager 2007 (SCCM) here and quite often it feels like we're using a sledge hammer to crack a nut.

We only have 50 users, but we're support as many servers too which is where the majority of my time disappears too. Having our general user base modifying their computers just adds extra problems we don't need. I would guess that our problem is exacerbated by the fact that most of our employees are highly intelligent, they enjoy being able to play with things and see what happens when they do.

We have managed to get everyone down to a restricted account with our new hardware except for a few of our developers who have a secondary admin account for their PC to allow them to install software without raising a support ticket.

Incidentally, those developers are now the largest end user drain on the support resources - as their PC's are still exhibiting odd behaviours.

We are trying to apply the same software deployment approach to our servers, using SCCM to automate software installations and patch management. That little project is going slower as we have a large number of legacy systems that we're just too worried about adding to SCCM in case they go bang. As they're transitioned over to new hardware we hope to rectify this.

I do have a few questions / comments though:

Kev - What's a security officer and where can we get one! ;)

Wesley - SCCM will likely be over kill, WSUS and judicious use of GPO Software Deployment might serve you better.

Greycat - Do your users actually know how to right click on a printer and click connect? Ours find that task too difficult!
Our Security Officer is a singelton role at the moment and grew out of tasks covering network security anti-virus. At present the role involves formulating the University's IT Security policy, coordinating our Anti-Virus solution (McAffee EPO), Network Security monitoring (Languard) and Update Management Advisory role. This is a usefull role as our user base covers staff and students and therefore we have a range of issues (naive staff and over inquisitive students). Both user groups present thier own range problems. Our student desktop service is locked down tight. Our Staff service is manged by Group Policy but staff are also local admins for thier own PC's. We encourage staff to save data to our networked data areas which is backed up nightly. We also develop a Desktop Image(currently XP but now piloting Win 7) which we use to create a standard desktop.
Our staff users range from non it literate users to highly trained Computing Lecturers. On the whole everyone accepts that security is a requirement but that doesn't stop people failing to understand that thier request does have security implictions. For example we do not allow generic accounts which are used by more than one person. Staff continually request an account that can be used this way or reveal that two people have been sharing passwords (i.e. maternaty leave ).
@Dan, you're right about WSUS being good for Windows updates. I love it. As far as non-Windows patches, I haven't found a solution yet even though I know plenty exist. I'm thinking of Lumension née Patchlink.

AD for software deployment is fine, but I've heard unpleasant things about attempting to deploy larger softwares through it such as Office. I also don't like having to mess with AD structure just for the purpose of targeting software deployment. I suppose that's better now with different methods for applying GPOs.
Wes,

Deploying "large applications" is easy in GPO / AD. Office is not a large application and certainly the 2007 version is even easier! If you want a large application to try deploying look at something like AutoCAD 2010 - that's a 2Gb+ install package not including .NET, Direct X 9 and numerous other bits. Office 2007 Pro is less than 500Mb so a lot easier to deploy.

As to messing with AD infrastructure to target the deployment GPO's you can simply apply the GPO high enough and then use security group membership to filter it out.

I'm always kinda surprised that people don't use GPO's to deploy software as it is so so so so so simple to achieve so much with little effort.
While 2GB is massive, word on the street (I love using that phrase) is that even 500MB can be tough for an AD install. At least in the days of Server 2003's implementation of AD.

Also, security group filtering, so I've been told, is the hardest on the domain controllers so if you have a not insignificant amount of users (or an insignificantly sized server), then it can hammer it a bit hard in the mornings when people sign on and you've got dozens ore more GPOs that are being filtered by security groups.

I think the only thing that uses more resources is WMI filtering for GPOs.

What's your experience been with DCs and filtering?
Personally, we've never had a problem deploying 500 mb to users via GPO. Its how we used to provide Office to all of our test VM's once they went live. We were running Server 2003 AD at that point.

Security groups do make it easier to target the installs as Greycat suggested.
You're right, 2Gb is a large deployment and about as large as I'd like to go really. The problem isn't the AD side of things as it just processes the policy and kicks off the installation package to do it's thing. The problem becomes the speed of your network (both in raw grunt and also latency etc) and the power of the PC itself. Even installing AutoCAD 2010 from DVD takes a good while so network deploying it isn't not as quick as I'd like but then it is 2Gb so pros and cons.

We're running a 2003 AD infrastructure and have no major problems with policy speed at the moment. The times we have is when the sheer number of policies was causing a lag in the processing as each had to be checked. You can limit the impact of this with some good design work though such as disabling the user side of a GPO if it is just computer settings, not repeating settings in policies (consolidate down in other words) and intelligent placement of the policies.

As of today I think we have about 80 GPO's doing everything from default settings through to software deployment and WSUS configurations. Most of these are using filtering of some kind be it security group or WMI.

WMI can be a complete pain to sort 100% too so we generally only use it when we have no other solution to get the filtering we want.
We've got ~ 300 users, with maybe 3-4 having admin rights. (Not counting system admins - though we run with regular accounts normally. Of course it's easy for us to elevate when we need to.)

Our reasons are primarily security related, though keeping machines relatively standard is a big plus.

That's one of the up-sides of working at a financial institution, IMO - our crazy paranoia is mostly justified. :)

The thing that never ceases to amaze me is the amount of "enterprise" software that thinks it needs to run with admin rights. I can understand cruddy "home" software, even if I don't like it. But if you're selling software to a bank, maybe you should keep security in mind!
Jason,

I'm totally with you on the software that requires admin rights, we've just had a major push to eliminate all software that falls in to this category - sadly most of what is left is used by our finance department. Go figure!

You do raise an interesting point there, your paranoia is justified, ours sometimes seems a little over the top to the management team. We've tried illustrating the point to them recently, we ran virus scans on the whole network and we discovered key loggers on our finance PC's. I think they're starting to get the message that security isn't just for financial institutions its for everyone.

RSS

© 2012   Created by Elizabeth Ayer and Michael Francis.   Powered by

Badges  |  Report an Issue  |  Terms of Service