locked
Group Managed Service Account Error: "no mapping between account names and security ids was done" RRS feed

  • Question

  • Hi, guys.  I'm a 10 year IT guy and pretty good with scheduled tasks, Windows Server, etc, but this has me stumped.  I'm testing a new thing, scheduling tasks as a GMSA, Group Managed Security Account.  I made my account according to the steps outlined under "GMSA setup" below.

    I'm testing this on 2012 Server Essentials R2 with Win10 and Win7 Pro VMs as clients.  I read a lot of posts about how to get this to work and people kept saying it only worked with the commandline (schtasks) and Powershell, so I tried both of those.  Powershell was not even possible on Win7 because "new-scheduledtaskaction" is not available there.  So, most of my efforts have been on Win10 Pro and 2012 Server Essentials R2.  I made sure that scheduling these as a regular net admin with the same commands works, netlogon service is on, firewall has remote scheduled tasks allowed, and the time server is the PDC and the time is correct.  It only fails when trying to run the commands below (posted under Powershell commands) as the GMSA. 

    The error I get, as stated above, is: "no mapping between account names and security ids was done".  I'm willing to do anything you want me to for troubleshooting and will post back.  Thanks in advance.



    GMSA setup

    ii.    Opened admin powershell and ran: "Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))" to create a kds setup to shell out keys NOW.  Note: normally, when not in a test lab, you run the following and must wait 10 hours: "add-kdsrootkey -effectiveimmediately"    
    iii.    Ran "New-ADserviceaccount -name tasker -dnshostname MailroomServer.MAILROOM.local -PrincipalsAllowedT
    oRetrieveManagedPassword administrators" to make a new GMSA account.
    iv.    Ran "install-adserviceaccount tasker" and then "test-adserviceaccount tasker", the latter of which returned "true", meaning it worked.

    Powershell commands

    PS C:\WINDOWS\system32> $action=new-scheduledtaskaction "c:\scripts\file cleanup.bat"
    PS C:\WINDOWS\system32> $trigger=new-scheduledtasktrigger -At 12am -daily
    PS C:\WINDOWS\system32> $principal=new-scheduledtaskprincipal -userid tasker -logontype password
    PS C:\WINDOWS\system32> register-scheduledtask cleanup -action $action -trigger $trigger -principal $principal

    Oh, and I tried three variations of the third line, all fail:

    1) $principal=new-scheduledtaskprincipal -userid tasker -logontype password

    2) $principal=new-scheduledtaskprincipal -userid tasker -logontype password -runlevel highest

    3) $principal=new-scheduledtaskprincipal -userid tasker -logontype serviceaccount -runlevel highest

    4) $principal=new-scheduledtaskprincipal -userid tasker -runlevel highest

    Tuesday, March 27, 2018 6:54 AM

Answers

  • Hello,

    Since a gMSA is based on the Active Directory computer object, you have to use it like it.

    Try to change the following line in your code accordingly:

     $principal=new-scheduledtaskprincipal -userid tasker$ -logontype password

    Notice the $ behind the name of the gMSA.

    Does that work?

    • Marked as answer by TimoniAl Saturday, March 31, 2018 5:12 AM
    Tuesday, March 27, 2018 7:32 AM

All replies

  • What is the complete error message.  It will contain the command and other important information.


    \_(ツ)_/

    Tuesday, March 27, 2018 7:02 AM
  • Here is an article that will show you ALL of the steps required:

    https://blogs.technet.microsoft.com/askpfeplat/2012/12/16/windows-server-2012-group-managed-service-accounts/


    \_(ツ)_/

    Tuesday, March 27, 2018 7:06 AM
  • Hello,

    Since a gMSA is based on the Active Directory computer object, you have to use it like it.

    Try to change the following line in your code accordingly:

     $principal=new-scheduledtaskprincipal -userid tasker$ -logontype password

    Notice the $ behind the name of the gMSA.

    Does that work?

    • Marked as answer by TimoniAl Saturday, March 31, 2018 5:12 AM
    Tuesday, March 27, 2018 7:32 AM
  • Oh my god...I didn't notice that.  This is why I'm an admin and not a programmer lol.  I will try it and post back.  Thanks!
    Wednesday, March 28, 2018 3:54 AM
  • One small post for you, equals one giant leap in understanding for me.  Thanks!  The missing $ was part of it, and I had to leave the logontype fully off.  So to recap, step 3 looked like this: $principal=new-scheduledtaskprincipal -userid tasker$

    Could probably put in -runlevel highest too, but I just went into the task scheduler later as admin and added that and also added "run whether or not logged on".  Without those, my script didn't run.  Oh, and when I added the gmsa to security settings for a folder (just for testing), I had to check "service accounts", not "computers" under "object types" in order for the tasker$ gmsa to be found.  So that is a bit of a mystery: is it a computer object, a service account, or both (context dependent)?

    Anyway, the test script ran great so thanks--I have a new tool to work with now.

    Saturday, March 31, 2018 5:21 AM