<

Go Premium for a chance to win a PS4. Enter to Win

x

Free yourself of your administrative account

Published on
13,156 Points
2,556 Views
16 Endorsements
Last Modified:
Recently, I read that Microsoft has analysed statistics for their security intelligence report. It revealed: still, the clear majority of windows users do their daily work as administrator. An administrative account is a burden, security-wise. My article will show an alternative.

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.


Notes on

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

Registry settings:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\CredUI, Dword32-Entry: EnumerateAdministrators, set its value to 1.

 

5 This is done through two scheduled tasks,

First: “adminactive”

Action: cmd /c net user admin /active

Trigger1: on workstation unlock of yourweakuser

Trigger2: on local connection of yourweakuser

Trigger3: at logon of yourweakuser

Executor:System

Second: “adminlocked”

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

Executor:System

 

16
Comment
Author:McKnife
  • 4
  • 3
  • 2
9 Comments
 
LVL 37

Expert Comment

by:Shaun Vermaak
Maybe I do not understand properly...

Any process can enumerate users and try weak passwords such as BLANK, 123456 to elevate.
Such a process can then change the registry to allow remote use of blank passwords and/or undo your block of interactive login.

Anyone will then be able to login local and remote with blank password
0
 
LVL 57

Author Comment

by:McKnife
No, to overcome the policy that disallows blank password usage in scripts, you already need to act as administrator. And that, an attacker can't do, because it would need to be done interactively (click ok to continue), because in scripts, it is disallowed.
0
 
LVL 37

Expert Comment

by:Shaun Vermaak
Can this account be used in Start-Up repair?
0
Lessons on Wi-Fi & Recommendations on KRACK

Simplicity and security can be a difficult  balance for any business to tackle. Join us on December 6th for a look at your company's biggest security gap. We will also address the most recent attack, "KRACK" and provide recommendations on how to secure your Wi-Fi network today!

 
LVL 57

Author Comment

by:McKnife
That account is deactivated whenever the user that should have access to it is not logged on or has locked the screen, so no.
Also, if we take it seriously, no one should have access to startup repair because we encrypt our drive.
0
 
LVL 37

Expert Comment

by:Shaun Vermaak
Interesting concept, thank you for sharing.
I would just add a deny set-value System on these registry keys (such as LimitBlankPasswordUse) so that they are not changes by software etc.
0
 
LVL 57

Author Comment

by:McKnife
You are welcome.
Denying access to the system account - well, we could do that, but that would imply that we use a software that acts extremely unsafe and no software that we trust should do that - but well, we never know, so I'll add your idea and recommend that we enforce the GPO that denies the blank password usage, so no installation can change it. Thanks for that.
0
 
LVL 12

Expert Comment

by:Andrew Leniart
A highly interesting concept I've never considered McKnife, but I'm not sure I fully understand your methodology here. For instance..
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
It's "harsh" in what way?  Can you expand on what you meant by that?

If a machine is left logged on 24/7, is there any need to disable the suggested admin account? If yes, then what possible problems do you foresee by not having the admin account disabled?

Can this account be used in Start-Up repair?
Assuming that a machine's drive is not encrypted so that Start-Up repair remains a viable option for when things go belly up, wouldn't it be prudent to have a secondary administrator account, protected by a strong password to use in that circumstance?  Or even trigger it to be deactivated while any users are logged on, but reactivated when the last user is logged off prior to Windows shutting down?
0
 
LVL 57

Author Comment

by:McKnife
Hi Andrew.

It is "harsh", because we deny something to the system account and the admin account. Normally, these accounts are not denied anything. But if you put this into context, it will not really matter to deny it or not, since the risk that Shaun mentions is theoretical.

"If a machine is left logged on 24/7, is there any need to disable the suggested admin account?" - Why would you even worry? Setting up the tasks automates the process. Well, if a machine is logged on 24/7, that does not imply it's unattended. So if you don't use these tasks to deactivate the account on lock/logoff, an attacker could simply logoff the logged on user and (if he knows or guesses the account name) logon with that admin account without a password.

"Assuming that a machine's drive is not encrypted..." - if we assume that, we imply that the guy using this PC has no real interest in securing his system. Full disk encryption is the very baseline for any security concept. In case we ever need to do emergency repairs, we can always activate administrative accounts using boot disks - after mounting the encrypted drives by using tools that allow that. In case of bitlocker, any setup disk allows it.
2
 
LVL 12

Expert Comment

by:Andrew Leniart
Thank you for expanding on your comments McKnife. An excellent article that inspires thinking more about security!  

Thanks for sharing your ideas. Endorsed.
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

Join & Write a Comment

With the advent of Windows 10, Microsoft is pushing a Get Windows 10 icon into the notification area (system tray) of qualifying computers. There are many reasons for wanting to remove this icon. This two-part Experts Exchange video Micro Tutorial s…
The Task Scheduler is a powerful tool that is built into Windows. It allows you to schedule tasks (actions) on a recurring basis, such as hourly, daily, weekly, monthly, at log on, at startup, on idle, etc. This video Micro Tutorial is a brief intro…

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month