From Chris Urban's Web blog:
Over the course of my years as an IT professional, I've read numerous threads, had discussions, and architected solutions for many clients around a single topic near and dear to my heart. For example: Reasons why a corporate user needs to have local administrator rights over their workstation. I believe I've heard them all! Such as:
1. We need to be flexible to our user's needs.
2. There's a specific application which requires it.
3. We need our user to install or update software.
The list can go on and on -- and it does!
I am here today to put a line in the sand and make a bold statement (okay, not bold to some but others just don't "get it" yet):
"In a corporate, managed environment, there should be no valid reason for granting a domain user to have local administrative privileges on their assigned corporate asset."
So, out of the gate you may be scratching your head and saying to yourself, "Why did he go out of his way to call a workstation an assigned corporate asset?" For starters, I believe this is the root of all evil. For some unknown reason -- somewhere at the beginning of Information Technology (IT) time -- when the first corporate user received their first machine, they dubbed it "mine." They leaned over to their cube buddy and said, "Hey, look at MY new machine!" I believe the twisted corporate culture started back then.
Allow me to dissect the remainder of my statement, if you will. "In a corporate, managed environment" meaning any company (big or small, it doesn't have to be an S-Corp or C-Corp) which manages (through a simple change control process or a more complex change and configuration management tool such as Microsoft Systems Management Server 2003) their workstations and/or servers. I am attempting to parse out any organization which does not have any type of change control process or tool in place. For these organizations, there "might" be a reason (and I tread on thin ice there!) for a user to do "stuff" to their machines. These reasons might include:
1. No support staff or limited support for the organization
2. Lack of corporate IT direction
3. Company policy which states the owner of the assigned asset will support their own machine.
I'm sure there are more but those were for conversation's sake. I do believe that over a period of time, an unmanaged environment eventually moves toward a managed environment due to excessive pain and loss of time and revenues.
Allow me to address the first three "excuses" of why an end user NEEDS to be a local administrator:
1. We need to be flexible to our user's needs.
I recall sitting down with the VP of Operations and Development when I was the Director of Operations for a telecommunications company. It was my annual review and the point was made (negative, may I add) that when an end user would engage me after going over my Help Desk Supervisor's head (big mistake), the conversation would always start out, "No, now what do you want?" My VP felt that I was not being flexible enough for my end users to make them as productive as possible. My retort was that if he felt that I needed to be more flexible to meet my end user's needs to make them productive, then I clearly wasn't doing my job. By this, I meant that somehow when we were in the process of building our base image for the enterprise, I must have missed a core requirement that made all the end users less productive. When he redirected me by stating that this particular case was an "exception," I had to ask how this and all exceptions affected the base image. Clearly, I could not certify this "exception case's" workstation and applications anymore without doing regression testing to ensure that the "certified enterprise core applications" functioned properly. In addition, once an exception is made and an application is installed onto a workstation, it's fair game to receive a help desk call on that application at a later date and time. The bottom line is that if an application is SO critical to deem it as an exception, why isn't it part of the core business?
I once saw an organization which took the support life cycle and had the supporting OLA (Operating Level Agreement) / SLA (Service Level Agreement) in place:
1. Help desk receives a call. Help Desk Technician attempts to troubleshoot the issue for 15 minutes. If unsuccessful to resolve, ticket is escalated to the Desktop Support Team.
2. Desktop Support Team visits end user in an attempt to resolve the issue. Desktop Support Technician attempts to resolve within 15 minutes.
3. If Desktop Technician is unsuccessful within 15 minutes, they are instructed to communicate to the end user that they will return with the solution. That solution being that the Desktop Technician returns with another desktop to swap out. No questions asked! That's it? A 30-minute Help Desk ticket! Imagine that!
2. There's a specific application which requires it.
Do you recall the days of 16 bit applications? (Forget about punch cards or magnetic tape for a moment, will ya?) "Back in the days," I do recall applications "requiring" this. With the advent of 21st Century technology (yes, if you're not using it? get there), there shouldn't be an application on the market which "requires" it. If there is, then you shouldn't be using it. I'm not talking about service accounts, connection accounts and the likes. I'm talking about the USER having to log on as an administrator to run an application!
3. We need our user to install or update software.
In a managed environment, there should be a traceable mechanism in place (process or software) to expose the who, what when, where and how software was installed. Even with software, such as SMS 2003, the tool gives an administrator the ability to present an installation routine to an end user without having to compromise the integrity of the managed-state machine. Once the software is regression tested against the base build, the software is packaged in a "known configured state" and delivered to a managed desktop. If it is an optional installation and the end user elects to install it, SMS will elevate the rights at that specific point in time just for the specific purpose of software installation on this package. Not only does the organization have control of "how" that software is configured on the machine, but gaining insight into which specific machines it's installed on for support and licensing issues.
That's just the tip of the iceberg in a managed environment. The first steps in gaining a managed enterprise environment, in my humble opinion, is to gain complete control of corporate assets to achieve a locked, known state.
For comments, questions or rebuttals, please direct them to chris@learnsms.com.