2

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

EEAA
  • 109,363
  • 18
  • 175
  • 245
René Kåbis
  • 107
  • 2
  • 3
  • 9
  • Silly question, but did you run 'import-module activedirectory' prior to 'install-adserviceaccount'? – ErikE Nov 21 '13 at 18:49
  • Your question reads as if you are attempting to make things more difficult than they need to be. Before I answer, are you just wanting to run an app on a user's machine that requires admin privileges on that machine? Or does it really require domain admin rights? – TheCleaner Nov 21 '13 at 18:52
  • @ErikE PS C:\Users\René Kåbis.BABYANDME> import-module activedirectory import-module : The specified module 'activedirectory' was not loaded because no valid module file was found in any module directory. At line:1 char:1 + import-module activedirectory + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (activedirectory:String) [Import-Module], FileNotFoundException + FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand – René Kåbis Nov 21 '13 at 18:58
  • @TheCleaner - The app only needs admin privileges on whatever machine it's installed on, but this app will be used throughout the organization. So either I have to hump my butt to custom-tool admin access on each and every machine, or I try to make something work that works across the whole domain transparently. – René Kåbis Nov 21 '13 at 18:58
  • So you create a local admin account on each machine (push out a generic Domain\localadmin if you want via GPO to add it to the local admins group), and do a RUNAS with that account. No need to get fancy. – TheCleaner Nov 21 '13 at 19:02
  • @TheCleaner - But that means watching and managing a local admin on every workstation that needs the software. That could end up being an absolute nightmare in terms of password management. And if I use a common password, all local admins on all workstations are vulnerable. I also have a situation where I have a single external RDP machine (a VM) for the business owners to access (for some remote business functions when they can’t make it in), I do NOT want this machine to have a local admin installed!! – René Kåbis Nov 21 '13 at 19:14
  • @TheCleaner - just tried using a local admin account via RunAs. Same problem - “740: The requested operation requires elevation.” The same account used when the icon is just double-cicked works just fine. – René Kåbis Nov 21 '13 at 19:54
  • That's due to UAC. You can test by launching a cmd prompt as Administrator and then do the runas command. If you want the app to actually run as administrator you'll need to change that apps properties/compatibility before using runas. – TheCleaner Nov 21 '13 at 20:04
  • @TheCleaner - You’re talking about going to the Executable, pulling up the properties, and then checking off the checkbox that says “run this program as an administrator” under the compatibility tab, correct? If so, no dice - “740: The requested operation requires elevation” – René Kåbis Nov 21 '13 at 20:53

2 Answers2

3

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

ErikE
  • 4,746
  • 1
  • 20
  • 27
  • My servers are running Windows 2012 R2. I am using Active Directory straight from the AD controller. The machine in question is a Windows 8.1 Enterprise workstation. It is on this workstation that I cannot get either Install-ADServiceAccount *or* Import-Module ActiveDirectory to work. There does not seem to be any RSAT tools for Windows 8.1 available yet. – René Kåbis Nov 21 '13 at 19:09
  • http://www.microsoft.com/en-us/download/details.aspx?id=39296 – ErikE Nov 21 '13 at 19:10
  • looks like my Google-Fu could use a bit of improvement. Thank you for the link. – René Kåbis Nov 21 '13 at 19:15
  • Aw, dangnabbit: PS C:\Windows\system32> Install-ADServiceAccount Services Install-ADServiceAccount : Cannot install service account. Error Message: 'An unspecified error has occurred'. At line:1 char:1 + Install-ADServiceAccount Services + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : WriteError: (Services:String) [Install-ADServiceAccount], ADException + FullyQualifiedErrorId : InstallADServiceAccount:PerformOperation:InstallServiceAcccountFailure,Microsoft.ActiveD irectory.Management.Commands.InstallADServiceAccount – René Kåbis Nov 21 '13 at 19:43
  • I wrote my reply as an edit to above answer, as it would have cluttered the comment field beyond hope. – ErikE Nov 21 '13 at 20:59
  • I have installed the RSAT tools, and while they allowed `Import-Module ActiveDirectory` to work, the importing of the actual service account still failed, as per the error message in *this* thread. – René Kåbis Nov 21 '13 at 21:05
  • Yes, I understand that. See my marked edit in the answer to which these posts are comments. – ErikE Nov 21 '13 at 21:07
  • First paragraph, yes. I am running a domain admin account on the computer in question when I do these operations, plus I am elevating a PS console when I do so. Second paragraph, not sure. – René Kåbis Nov 21 '13 at 22:52
  • Then I would venture to guess a 'no' to the second paragraph, as it seems to involve actively configuring it. I read that in the MS blog-link, so it's all there. I'm working 100% by theory here right now, but am very interested in how it works out for you as this is on my own "list of things" too. – ErikE Nov 21 '13 at 23:26
  • I followed each and every step on the page that I linked to. The page that you linked to seems to be not that much more extensive (at least, in terms of *creating* the service account), so I am not sure what you are talking about when you say it’s a “slimmed down” copy. The only point where I hit a roadblock is when I switched over to the client computer and attempted to import the service account - initially with the import command itself, but after your fine instructions above (to make the importing command function in the first place), with the importing of the service account as a whole. – René Kåbis Nov 22 '13 at 00:31
  • When I examine all of the reference screenshots that show the service account, I have the exact same thing (just named differently) on my own server. – René Kåbis Nov 22 '13 at 00:31
  • Is the computer where you try to execute the command a member of the group you created to access and use the gmsa? I notice they use the group "domain controllers" in the example, whilst you have a win8 in the mix which would need to be 'memberized' in whatever you called the group. – ErikE Nov 22 '13 at 04:51
  • I have determined that service accounts wouldn’t help me with a normal program because RUNAS always expects a password anyhow, even when you trail a username with $. The only way around it is with a weird scheduled task hack. So I have abandoned service accounts anyhow, and have posted my answer to my original question. Thanks anyhow for your help, it was appreciated. I may come back to you later to get the services account debugged for actual scheduled tasks. – René Kåbis Nov 27 '13 at 17:34
1

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.

René Kåbis
  • 107
  • 2
  • 3
  • 9