0

I am having trouble understanding what is going on with "runas".

Situation:

  • CLIENT is W10 Pro joined & logged in to Active Directory Domain FOODOM.
  • USER is member of FOODOM and default Domain-User, nothing elevated.
  • MYADMIN is member of FOODOM and member of Organization-Admin, Domain-Admin, etc. A typical Domain-Admin User.
  • UAC is enabled.
  • FOODOM\USER is logged in on CLIENT.

Problem:

FOODOM\MYADMIN is not allowed to runas with admin rights: from inside FOODOM\USER's session:

runas /user:FOODOM\MYADMIN cmd fails with "The requested operation requires elevation"

Hoewever, the built in administrator account works:

runas /user:FOODOM\Administrator cmd -> ok

FOODOM\MYADMIN can successfully login on CLIENT. When logged in, MYADMIN can run things with Domain Admin priveledges local and remote.

Thoughts: Am I missing some flag? None of the adminiatrive users we usually use can successfully invoke runas except built in administrator...? I suspect it only works because the local workstation is mixing up FOODOM\Administrator with .\Administrator?

Edit:

As the comments seem to ignore the real question, here as clarification: I am aware of elevation issues with UAC and are refering to DOMAIN Administrator, not the local one. What is the reason domain\Administrator actually CAN circumvent runas elevation while domain\someAdmin can NOT? LDAP Flag? Delegation? if(username==*\administrator) { do.secretElevationHack(); } ?

  • A related question: https://superuser.com/questions/661979/run-as-different-user-and-elevate – Robert Mar 25 '20 at 14:14

1 Answers1

0

While you can run a command as elevated by right-click and choosing "Run As Administrator", this does not work for runas.

The reason is that runas was created before elevation was invented, so it has no switch for running an elevated command.

An alternative is to invoke the UAC dialogue by calling the VBScript ShellExecute function.

For example, to run a batch script (.vbs) with elevated permissions, use the flag runas:

Set objShell = CreateObject("Shell.Application")
objShell.ShellExecute "cmd.exe","/k echo test", "", "runas", 1
harrymc
  • 455,459
  • 31
  • 526
  • 924
  • Thanks for your explanation.However, domain\administrator CAN successfully elevate. It seems only other admin user cannot. Is that a specific flag/group which is missing or is it a built in feature that runas only allows elevation if username==administrator? – R. Bitrary Mar 25 '20 at 15:15
  • If the built-in Administrator account is enabled, and you shift-right-click the executable or script you want to run with elevated rights, then Administrator will show in the account list. That's about all you can do if you are not a local admin yourself, short of taking ownership of the executable or script in question, which will cause other issues. As explained by harrymc, "run as" was designed to allow standard users to run programs installed by/for other standard users on shared machines. You can reintroduce "run as" in right-click menu, but you may be disappointed with how it fares –  Mar 25 '20 at 15:59
  • Doing `runas` to an administrator account requires elevation. Elevation API didn't exist at the time that it was programmed, so it doesn't know how to do that. – harrymc Mar 25 '20 at 16:04
  • @harrymc that is not correct and exactly the key of my question: runas elevation IS available for "domain\administrator" but not for "domain\someAdmin". I am not talking about local\Administrator. I am aware of that. But why is "domain\Administrator" able to elevate? Has the default "domain\Administrator" some Flag one could set with adsi-edit? Is it an invisible delegation? Or is "runas" doing some bad trickery if username == administrator? – R. Bitrary Mar 25 '20 at 18:32
  • An administrator is always able to elevate, unlike a standard user. Therefore runas any administrator is equivalent to elevation. Is that what you are asking? – harrymc Mar 25 '20 at 18:38
  • Getting close. Iam sorry if my question was unclear. **What is the configuration needed for an _Domain Admin_ User to be able to runas-elevate?** _None_ of my users with Domain Admin privileges is able to runas-elevate. In W10Pro _only_ the default Domain Administrator user is. I am looking to understand if I can change that behaviour through AD/LDAP configuration. – R. Bitrary Mar 25 '20 at 18:46
  • That's clear now. The answer is that a domain admin is not a local admin, so cannot elevate. To give a domain account local admin privileges, you need to add it to the local administrators group. See [this post](https://superuser.com/questions/954159/how-to-add-a-domain-user-to-administrators-group-in-windows-10). See also [net localgroup](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc725622(v%3Dws.11)). If this is the problem, I'll modify my answer. – harrymc Mar 25 '20 at 19:43
  • _"The answer is that a domain admin is not a local admin, so cannot elevate"._ But I CAN successfully elevate with the Domain Admin. Domain Admin has different password than local admin and I excplicitly authenticate with the domain\administrator. And yet it still works. – R. Bitrary Mar 26 '20 at 16:08
  • I'm now totally confused. Could you detail in your answer which runas works or not in a clear manner? – harrymc Mar 26 '20 at 16:19