Windows Administrator to work like "root" in Linux? Any work around

Has any one tried some thing in Windows for an Administrator account not making it able to login through the regular Welcome screen, but it should work only when an administrative privilege is required while been logged in to Windows as normal user?

I am just trying to get a work around for it to do like the supper user "root" in Linux. As I do have an option in Linux to enable/disable "root" account and only give a password when ever a privilege is needed. Just like that I want an Administrator account in Windows, which should not be able to login via the Welcome screen but I could use this account for some or all administrative tasks while being logged in as normal user...

I hope it makes some sense to Linux users.

The example of it is already in the Windows systems. Which is when we are logged in to Windows with a normal User account and try to perform a task, which requires an administrative privilege, Windows prompts with a Login dialog to login as an Administrator. But the problem is, I tried hard but, I couldn't manage to "set an Administrator not able to login on welcome screen but to be used when ever needed a privilege". I only have one option for any account in windows, that is to enable or disable the account which will be set for that account globally.

Means that if I enable an Administrator account it will be available to login with it on welcome screen and as well it will be available to login when a User account performs an administrative task.

And if I disable an Administrator account it will be disabled fully. I won't be able to login with it on Welcome screen (which is good in the desired case). but the bad as well as I also won't be able to use this account when ever a privilege is needed while logged in as normal User account.

I've tried reading a lot in policies and even tried different set of values and parameters in them. But I didn't get such a solution which I just needed.

^Thanks sah. but these all are representing the same elevation control for getting authorized for privileged tasks as I said in my ending text. Windows performs "elevation control" by prompting with the Login dialog to give the User opportunity to log in with an administrative account.

As in the listed articles above, "runas" command is just a command line interface for those elevation purposes. So that the same bad thing is there as well with this command to pass elevation if the Administrative account (which a user is going to use) is disabled. It will work only if the Administrative account is enabled and if it is enabled it will be able to login as well from the Welcome screen, which is actually what I am not happy with.

For the time being I have done a little bad trick by enabling the Administrative account for Normal User to get elevated with. And for that purpose I have to tell the password to that user for this administrative account but I don't want him to login via this Administrative account. So for now I just used a trick to logout this administrative account automatically if any one logs in to this account...

But I would really be in search for the subjected problem.

^ I don't think there is any other way to do it. Windows is not Linux after all!

^ Yeah! it is not for sure.... but I really think there should be a workaround for this one specifically..

The question is, what specific tasks do you want to run as administrator. If those tasks only include running EXE files then one workaround is:

1) Administrative Tools->Local security policy->Local Policies->User Rights Assignment->Deny logon locally . Add the administrator account to the policy. This will disable logging in from welcome screen.

2) Run EXEs using the following command

runas /netonly /user:administrator

After pressing ENTER, enter the password for administrator.

^ Great!! thanks


- An entry in "Deny log on locally" for that specific administrator. And then in the command prompt

>> "runas /netonly /user:administrator "

This combination worked. I, however, had tried both of them but not at the same time....

Any ways. it worked as desired.

Thanks sah as well as finally the "runas" command did the job because "/netonly" parameter couldn't be passed via GUI.

Damn :mad:

This solution(with command "runas") worked only with unsigned executables Or if UAC is set to "Never notify" which is normally set up to some level for all type of accounts to notify them before every sophisticated operation or to require any elevation when the operation is performed by a normal user.

Last time I just tested with it on the Laptop where UAC is already set to "Never notify" and as well I tested with an executable which in real didn't need any administrative privilege. Because I thought that the problem was just the Account, therefore I just tested the account if it was able to log in when needed. And it worked.

The issue was occurred when I tried the same on the PC where I actually was willing to do it. And it just sent the error "Access denied". I was stuck at it just thinking that what the hell is now the problem with it. Then I matched the policy settings on both the PC and the Laptop, they were also same. Then I just tried to re-produce the problem on the Laptop this time. So I copied that specific executable to the Laptop to see what the above procedure would do with it on Laptop(where the procedure worked good previously).

And what I found was that the executable was just able to be executed by double clicking it without any kind of higher privilege. That was the point I thought of the UAC settings which I have set on the Laptop to "Never notify". In the same way on PC, I set the UAC to "Never notify" to check again and it worked just like it did on the Laptop. Means I just have to give to Normal User, the full control of executing most of the things on the computer :/ huh... Just looking again in policy settings for some thing else....

Right now just switched back to last trick as in Post #3