Every organisation experiences user frustrations and complications that result in support calls to the help desk. While each call may seem to suggest a unique problem, have you ever stopped to ask whether there could be a common root cause? While it may seem black and white – the machine works and now it doesn’t, I’d argue that the majority of scenarios can actually be pinpointed to the same problem, just in different ‘grey’ guises? Let’s look at the evidence.
Every day the IT help desk receives hundreds of calls from the user base. While many will be straight forward, with an obvious underlying cause – such as a forgotten password, there will be some that will leave the IT team scratching their heads – sometimes for months. How many of the following sound familiar?
- It worked yesterday but today it doesn’t!
- It’s gradually been getting worse but now it seems to have stopped!
- I don’t know what I did but now nothings happening!
- My machine won’t turn on!
- It says it’s a compatibility issue!
What will resonate is – I need it done now!
The calls keep on coming
The issue for the help desk is, with little to go on, it can be difficult to pinpoint what exactly has happened. What is evident is that the device isn’t functioning the way it should, but how it got to this state well, that could quite literally be one of a million reasons. Using hypothetical situations to illustrate the point, here are some common scenarios:
Ron in accounts is having trouble with his printer. Yesterday his laptop happily connected to the Canon Deskjet in his office but today it doesn’t. He’s tried to ‘fix’ the problem himself but can’t so now he’s called for help. What Ron fails to mention – because he doesn’t actually see the connection, is that last night he installed a printer driver so he could connect to his home printer. Eventually the relation to last night’s antics and this morning’s problem is made, and rectified, and now he can print and get on with his day until he prints at home again!
Frank in despatch has a computer that has been giving ‘trouble’ for months but he can’t seem to sort the problem this time. It started when he couldn’t open an attachment and he’d ‘resolved’ the issue himself, without troubling the help desk, by downloading some software from the internet. As IT investigate further it’s revealed that Frank has been making similar little ‘tweaks’ to his system for months. Each new modification has inadvertently clashed with other elements eventually causing the system to crash. The extreme solution is to rebuild the device.
Susan in HR is distraught – she doesn’t know what’s happened. The last thing she did was open an attachment from a friend and suddenly everything on her screen disappeared. After a lengthy investigation a virus is blamed, but it’s a mystery how it slipped through the security net as the AVsoftware had been patched. What wasn’t immediately evident, but later became clear, is that Susan had ‘switched off’ her automatic upgrades because they took too long.
The Common Factor I would argue that many of your ‘problems’ have one common factor – your users have admin rights, or at least some of them do. If you think about it, take the problem with Ron – what has the ‘issue’ been chalked up to? Is it a printer driver issue or the fact that Ron has admin rights? What about Frank – there were so many conflicts that it’s hard to pinpoint exactly which caused the final meltdown but its his admin rights that allowed him to tinker with the build!
Ask yourself the same question for each of the other scenarios you face on a daily basis –malware, spyware, Active X, compatibility conflicts, etc. Can you see a connection – how many will have admin rights as the underlying cause? How many open tickets in the system right now would have happened if your user base did not have admin rights?
To give users control of their desktop, in a corporate environment, is bad news. They’ll introduce or change things that can, at best, cause compatibility issues resulting in problematic devices, at worst they can cause serious security breaches, all of which cost money and time.
Solving one problem but creating a nightmare
Of course, I can hear you screaming that removing admin rights is a problem in itself. Too restrictive and users are left struggling to perform every day tasks, too lenient and it could bring the organisation to its knees. But it doesn’t have to be that way and, let’s face it, the consequences of admin rights isn’t a picnic either. Here are three steps that will help you strike a better balance:
- Group policy
A feature of Microsoft, you can use group policy to control what users can and cannot do on the system. By restricting certain actions, such as blocking access to the task manager, disabling the downloading of executable files, etc., many of the ‘problems’ can be prevented.
- Don’t give users admin rights
Having made the decision to remove admin rights, don’t let them seep out. Often considered a quick fix, IT will bestow admin rights on users to try and resolve a problem. While it might work in the short term, you’re just creating another in the long term. Instead, a least privilege approach will remove the risk of installing malicious software – intentionally or accidentally, as well as restricting users’ inept behaviour. This means controlling, either manually or with software, which applications and devices can run in your environment.
- Talk to users
Introduce customised messaging that allows IT to communicate an appropriate message to the user based on their activity so they know, and understand, exactly what it is that they’re being stopped from doing – and why. It could include, if appropriate, an alternative course of action. This can reduce costly support and improve the user experience.
While on the surface it may seem a knee jerk reaction to remove privileges from all users, just because a few tie themselves up in knots, the reality is it is impossible to support a non-standard user base. So if you want to protect your Achilles heel, then your security mantra needs to focus on effectively managing user rights.