Running an administrative program under user account - domain edition

Question

I am tearing my hair out here - could use a little help.

It appears that the classic RUNAS does not function under a Domain environment. At least, I cannot get it to run in a Windows Server 2012 R2 and Windows 8.1 domain-based environment.

I initially tried to set up Managed Service Accounts as per this article, in order to create an administrative account that could be used for privilege escalation for a program that’s too bossy for its own britches, but while I was able to do everything on-server, the final steps (the operation on the Win8,1Ent workstation that needs the account) did not fare so well. Essentially, the command required, Install-ADServiceAccount throws an error because it cannot be found:

PS C:\Users\René Kåbis.DOMAIN> Install-ADServiceAccount Services
Install-ADServiceAccount : The term 'Install-ADServiceAccount' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is
correct and try again.
At line:1 char:1
+ Install-ADServiceAccount Services
+ ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Install-ADServiceAccount:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

So, I was forced to abandon that method and turn to standard administrative accounts. Oh, joyous rapture of potentially hackable accounts!

Problem is, those don’t work, either. Well, they do, just not in the way I need them to.

I created an administrative account under a different name (just in case there was a collision between the existing service account and this new admin account). When I go to the workstation, log in under a limited username, and double-click the prima-donna application I get the standard “this program requires admin access” yaddah, yaddah, yaddah. And into the resulting login box I am able to put the new admin account credentials and log in. So far, so good, but this is NOT SAFE because anyone who knows these credentials can use those to gain admin access to any machine.

So I try runas. Well, I use the following string:

C:\Program Files (x86)\Microsoft Retail Management System\Store Operations>runas
 /user:rms@domain /savecred SOMANAGER.exe
Attempting to start SOMANAGER.exe as user "rms@domain" ...
Enter the password for rms@domain:
Attempting to start SOMANAGER.exe as user "rms@domain" ...
RUNAS ERROR: Unable to run - SOMANAGER.exe
1783: The stub received bad data.

Ummm… okay. But a check of rundll32.exe keymgr.dll, KRShowKeyMgr shows the credentials existing within the machine! So I try again,

C:\Program Files (x86)\Microsoft Retail Management System\Store Operations>runas
 /user:rms@domain /savecred SOMANAGER.exe
Attempting to start SOMANAGER.exe as user "rms@domain" ...
RUNAS ERROR: Unable to run - SOMANAGER.exe
740: The requested operation requires elevation.

Whisky. Tango. Foxtrot.

The account I am using has the ability to elevate the program. I proved that by opening the program normally, and putting those exact same credentials into the login box that appeared. So why the hell is this happening??

Answer 1

To install the active directory powershell module:

On a server install the remote server admin tools feature.

On a client install the rsat tools after downloading the rsat installer.

Then run 'import-module activedirectory'.

This makes the active directory cmd-lets available for use.

Reference link: http://technet.microsoft.com/en-us/magazine/gg413289.aspx

It is a slightly unwieldy process if the only goal is a service account though, and leaves a residue to be cleaned up.

---

[EDIT based on your new error message in the commentary] I don't have access to a 2012 domain at the moment so can only guess and look carefully. It appears the command in the guide is run with the domain admin account, presumably in an elevated ps console. Does the account you are using have the corresponding level of access?

Also, do you fulfil the requirement "Usage of the gMSA is restricted to only those computers specified in the security descriptor, msDS-GroupMSAMembership."?

Finally, it appears the guide you are following is a largely copy/pasted but also much slimmed down copy of the Microsoft original blog post. Without scrutinizing it too much I would suggest you will find far more complete instructions in the original: http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx

Answer 2

The only way I have discovered to make the Microsoft Dynamics Retail Management System function correctly under a limited user domain account is with one way and one way only: Turn of UAC.

I’m sure User Access Control is a wonderful idea and has dramatically improved security within the Windows ecosystem since Vista, unfortunately Dynamics RMS appears to be a COM/DCOM-based software that was written before 2007. As such, it can only function properly under a non-administrative domain-based account when UAC is turned off entirely.

Granted, non-domain based accounts are something else entirely. If you have a standalone computer, getting RUNAS to launch Dynamics RMS properly is a walk in the park. Under a domain-based system it is a nightmare of any sysadmin’s worst fears.

I did several things to get RMS up and running, however in the wild and wooly trail I blazed during my efforts, I am not sure exactly what was effective and what did nothing much at all. So therefore here is a list of those things that I did not “unwind” to their default settings (I was always careful to unwind a setting once I was sure it wasn’t doing anything productive - but that’s the rub. Some things I just wasn’t sure about).

• Go into the program executables’ properties and for ‘all users’ (the extra button at the bottom when in a domain environment) set compatibility to Windows XP SP3 and set to launch as an administrator.
• Go into each program executable’s Manifest file (yes, they have manifest files) and comment out the XML declarative demanding administrative execution levels.
• Go into the Group Policy for the Domain, and change the following:
  • User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval mode - Elevate without prompting
  • User Account Control: Detect application installations and prompt for elevation - Disabled
  • User Account Control: Only elevate UIAccess applications that are installed in secure locations - Disabled
  • User Account Control: Run all administrators in Admin Approval Mode - Disabled

Once these settings were fully set up (and the computers rebooted, so that the computer GPO could take effect) RMS was able to start from the executable itself without asking for any sort of login credentials at all, even from a confirmed limited user account in the domain.

If anyone follows in my footsteps, I would strongly recommend you do not try this first. Do everything in your power to avoid turning off UAC. UAC is indeed a very important part of Windows Security, and it is only with the heaviest of hearts that I have disabled it. It is only because I am dealing with a relatively old program (with no current equivalent - a completely new and rebuilt variation is expected some time in 2014) that I am doing this.