Domain – Running an administrative program under user account – domain edition

domainpermissionsuser-accountswindows-8.1

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??

Best Answer

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

Related Topic