Fear not! To defend your business’ IT systems we’re going to shine a light on the seven most sinister terrors that haunt sysadmins. That way you can be sure there’s nothing in your stack waiting to go bump in the night.
You do it, your brother does it, your neighbor does it, maybe even your company's IT admin does it. Their accounts are members of the local group “administrators”. Running an administrative Windows user is still normal, at least on private machines. Microsoft has never forced users to do anything else and I doubt they ever will. Who cares?
Well, we all should care.
Running as admin implies, we potentially have the full power to do anything at our machine: Install software, format drives, create new users, read out passwords, copy data of other users, log every keystroke any user on this PC ever does, change any file, change the system configuration, deactivate security measures and many, many more.
But wait, did I write “we”? Oh, “we” is not exactly the truth, better write “we and numerous others” because any person's code that we execute, will also run with administrative rights. So the others could be: authors of websites that we visit, authors of software that we download, authors of e-mails or documents that we read, creators of sound or video or images that we like to enjoy. Well..., why not, where's the problem? The problem is that we don't know whether these people have good intentions. They might look harmless but they could intend to take control of our computer. This is realistic and happens all the time.
We cannot guarantee that all code we execute is doing what we want, that all the rich web content we are enjoying daily is really just that - “rich web content” and no trojan horse. What I am preparing to say is: “why should we invite all kind of code to do anything it likes?”
Because that is what we do, running as admin.
We could convert our account to a restricted account which offers a lot less intrusive and/or destructive potential. Still, we can do our work, we can enjoy the same content, we can communicate the same way. Wait, why did I say most people run as admin? Because it's the default? Is that the only reason? Of course not. But it's the reason why most people never even try to run as non-admin.
The main reason even for savvy IT people, guys who should know better than running as admin, is that they do not like to bother switching accounts, to enter credentials all the time and to risk running into all sorts of problems that are due to programs that are indeed relying on administrative privileges. But have they tried? Have you tried to do it, I mean, with your programs, on your current OS? Many haven't even tried.
Instead, Microsoft has taken action. Almost ten years ago, they introduced User Account Control (UAC) that, in short, gives administrators more control of their privilege usage. But to be honest, even Microsoft itself has never ever claimed that this will protect you from harm and does not consider it a security boundary. The design of UAC on Windows 7 and Windows 8, for example, is not able to prevent code from elevating. That means any code could potentially take advantage of all privileges we have and we wouldn't even notice. Microsoft has acknowledged that but will not fix it.
So this is an invitation to try and eventually get rid of your administrative rights for good. Since this can be a substantial change, be warned that although the rest is a kind of "how to", you will still need to be aware what you are doing. So although you might feel ready for this task, I would not recommend it to users that don't feel savvy about computers.
The steps won't be baby steps since again, I don't think people who don't know these steps in the first place should even be attempting them.
0 Make sure UAC is on and the slider is at top position
1 Create another account. Let's call it “admin” and leave its password blank and set it to never expire
2 Add that account to the group “administrators”
3 Remove your account from the group “administrators”. Make sure it's still part of the group “users”
4 Set a GPO so that any UAC prompt will suggest to use that account “admin”
5 Prevent interactive logon with that account
Now logoff, logon again and you are free of those administrative rights. Whenever you need to do something as admin, you can now by simply using that account named "admin" and leave the password blank. It's as easy as it was before, but a whole lot safer.
1 A blank password is the most secure choice since accounts with blank passwords cannot be used in certain attack types (remote UAC or runas) by security policy. This policy is called "Accounts: Limit local account use of blank passwords to console logon" and is part of the security options below GPO - Computer configuration - Windows Settings - Security Settings. It would be best to enable this GPO on a domain level so that no changes to this setting by whatever software we do install would persist. If you are not on a domain, you would need to deny write access for the system account and administrators to the registry branch HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa to detect changes to the value of LimitBlankPasswordUse ("1" is good, "0" is bad), which is a pretty harsh step, so you may consider not doing it but instead just monitor this registry key for changes (using the auditing functions of windows).
4 Policy path:
Computer Config.\administrative templates\Windows Components\Credential
User Interface ->Enumerate administrator accounts on elevation ->enabled
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\CredUI, Dword32-Entry: EnumerateAdministrators, set its value to 1.
5 This is done through two scheduled tasks,
Action: cmd /c net user admin /active
Trigger1: on workstation unlock of yourweakuser
Trigger2: on local connection of yourweakuser
Trigger3: at logon of yourweakuser
Action: cmd /c net user admin /active:no
Trigger1: on workstation lock of any user
Trigger2: on local disconnect from any user session
Trigger3: at system startup
If you wanted to make perfectly sure that when this account is activated, the limitblankpasswords-policy is set, you can modify the action that the account enabling task "adminactive" of step 5 does. Make it
cmd /c net user admin /active & reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /f LimitBlankPasswordUse | findstr 0x1 || msg * Attention, check LimitBlankPasswordUse-policy!
This will show a warning popup making you aware that the corresponding registry value was changed.