<

Expiring Today—Celebrate National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x

Free yourself of your administrative account

Published on
13,018 Points
2,418 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2
9 Comments
 
LVL 35

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 56

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 35

Expert Comment

by:Shaun Vermaak
Can this account be used in Start-Up repair?
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 56

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 35

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 56

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 56

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

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Join & Write a Comment

The viewer will learn how to successfully create a multiboot device using the SARDU utility on Windows 7. Start the SARDU utility: Change the image directory to wherever you store your ISOs, this will prevent you from having 2 copies of an ISO wit…
How to fix incompatible JVM issue while installing Eclipse While installing Eclipse in windows, got one error like above and unable to proceed with the installation. This video describes how to successfully install Eclipse. How to solve incompa…

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month