<

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x

Free yourself of your administrative account

Published on
18,560 Points
3,660 Views
19 Endorsements
Last Modified:
Approved
Community Pick
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

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.

19
Comment
Author:McKnife
  • 8
  • 5
  • 3
  • +2
19 Comments
LVL 47

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 62

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 47

Expert Comment

by:Shaun Vermaak
Can this account be used in Start-Up repair?
0
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

LVL 62

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 47

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 62

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 21

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 62

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 21

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
LVL 32

Expert Comment

by:Blue Street Tech
+1, great article again!
0
LVL 2

Expert Comment

by:Peter Wilson
I love this idea but I have a few questions.
1. When you say, "Create another account. Let's call it 'admin'" are you saying I should use the default admin account for this or create an additional one to the default admin account?

2.  "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),..." I need some clarification on this. Are you saying actually "Deny" or just uncheck Allow for the system and admins for the entire LSA key? From what Shaun said, "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." it seems like he is saying set the permissions on the REG_DWORD value LimitBlankPasswordUse opposed to setting the permissions on the entire Key LSA. If it is the REG_DWORD value how does one do that (I know how to do this on the Key)? LimitBlankPasswordUse is set to "1" (enabled) by default so that is the desired value, right? What stops applications (trusted or untrusted) that use remote interactive logons to bypass this setting?

3. For the scheduled tasks, should the task be configured for win10 if that is what I'm running or should I just leave the defaults?

Thank you!
0
LVL 62

Author Comment

by:McKnife
1 Like I said: "another" account, a new account named "admin", not the built-in one which is named "administrator"
2 I wrote deny and I mean it. Deny write access on the key - you cannot set access permissions on values, only on keys. "What stops applications (trusted or untrusted) that use remote interactive logons to bypass this setting?" - Bypass? They have no write-access to bypassing it, that's why we are setting this.
3 Does not matter, leave it at defaults.
0
LVL 2

Expert Comment

by:Peter Wilson
Thank you. So would you recommend disabling the default Administrator account or leaving it active with a strong password?
0
LVL 62

Author Comment

by:McKnife
You don't need it, so leave it disabled of course.
0
LVL 2

Expert Comment

by:Peter Wilson
Final questions...is there any reason not so simply use the Default Administrator account as the "admin" account you discussed if you change the Administrator name in Local Group Policy?

Can this cause any issues with YubiKey attached to the default admin, "admin" and local user accounts?
0
LVL 62

Author Comment

by:McKnife
The built-in account administrator is always a target because it is always present. For attack monitoring purposes, leave it alone.
About your Yubikey thought: let's continue that in your question, add more details there. Article comments  are not meant to for going into details that go beyond the article.
0
LVL 2

Expert Comment

by:Peter Wilson
0
LVL 2

Expert Comment

by:Peter Wilson
Can anyone answer my questions regarding this article here: https://www.experts-exchange.com/questions/29077198/No-Admin-Password-Yubikey.html ? It would be much appreciated.
0
LVL 62

Author Comment

by:McKnife
Let me add something to the discussion Shaun started whether one should rely on GPOs to remove the danger that this account will be used in scripts (see Note 1): If you wanted to make perfectly sure that this is set, you can add a single line to 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!

Open in new window


This will show a warning popup making you aware that this value was changed.
I will edit the article now accordingly at step 5.
1

Featured Post

Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

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…
In this video, viewers will be given step by step instructions on adjusting mouse, pointer and cursor visibility in Microsoft Windows 10. The video seeks to educate those who are struggling with the new Windows 10 Graphical User Interface. Change Cu…

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month