Otdfbt

The documentation contains the example:

New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true

This parameter is required. What exactly is the purpose of a DNSHostName and how should I decide what to set it to?

After working for a while with these accounts, I think I found out the reason:

They are some subset, or maybe derivative of the machine type accounts. Therefore they inherit this property from them, and since it's required for the machine type, it's also required for gMSA.

You can check that both types closely match in they attribute sets. Also in all of the TechNet documentation they just give a simple unique value for this attribute, gmsa-name.contoso.com, just like a machine account is having it.

Not sure why they just didn't autogenerate it, and spare us the wondering and the typing.

I am no expert at this. However, there is such a dearth of information on this topic I thought it worth posting what I do know

The trainer of a 70-411 course I took used the FQDN of a domain controller as the value for the DNSHostName parameter when he demonstrated the New-ADServiceAccount cmdlet. As I understand it, DNSHostName just tells the cmdlet which domain controller on which to create the account. I don't think it matters which DC you use, those gMSA's seem to replicate immediately anyway. I have been pointing DNSHostName to one of my DCs and it seems to be working so far.

I'd really rather there were some concrete documentation on this. The applicable TechNet command reference is just tautological nonsense for the DNSHostName parameter.

When you add the parameter -RestrictToSingleComputer it's not required anymore. Of course you should read about that option before using it.

Like:

New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer

The DNSHostName should be the name of your service.
In case of A Cluster this would be your Virtual instance name.

the DNSHostName is related to SPN Auto-registration of the account.
In Active Directory Computers & GMSAs have the Permission "Allow Validated write to ServicePrincipalName".
This means that a computer can only register SPNs that contain the name of itself.
Example: A computer Named Webserver1 (DNS: Webserver1.mydomain.net) can auto-register http:/Webserver1.mydomain.net:443 but cannot register http:/Webserver55.mydomain.net:443

So, the DNSHostName of a GMSA Should reflect what SPNs you want to register for a service.

On a SQL cluster, you would have 2 hosts: Host1 and host2. A clusterName: Clu1 and a Virtual SQL Instance: SQL1
If you want to use a GMSA to run the SQL1 service, you would create it like this.

$comp1 = get-adcomputer Host1

$comp2 = get-adcomputer Host2

New-ADServiceAccount -Name gmsa01 -DNSHostName sql1.mydomain.net -PrincipalsAllowedToRetrieveManagedPassword $comp1, $comp2
(you could also use a group instead of assigning rights to the hosts directly).

Whenever the SQL service starts, it will automatically register 2 SPNs:
MSSQLSvc/sql1.mydomain.net
MSSQLSvc/sql1.mydomain.net:1433

If you put something else in the DNSHostName (for example gmsa01.mydomain.net), The service will still start, but it will fail to register SPNs (and fall back to NTLM authentication).

If you don’t care about Kerberos Authentication (and SPNs) or
If you are ok with Manually registering SPNs for your service,
You can put whatever you want in the DNSHostName. The GMSA will still work.

I would not recommend putting your DomainController in the DNSName as mentioned earlier (unless you plan on using the GMSA to run a service on a domain controller).

I was looking for an answer for a very long time and finally found one that sounds true to me.

-DNSHostName should be the FQDN of that DC which holds KDS Master key - msKds-ProvRootKey.

Most likely you already created that one - take a look at Group Key Distribution Service container in Configuration partition of your AD forest.

And probably you could use any DC in that forest as long as you set their names in -PrincipalsAllowedToRetrieveManagedPassword

All of the above represents the "new" gMSA, so if you wish to use old MSA instead, just forget about that -DNSHostName since it's not required then and simply use -RestrictToSingleComputer locking an account to some server.

Hope that helps.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/9a66d1d5-44e9-4ea1-ba9c-88862023c4e1/why-does-a-gmsa-need-a-dns-host-name-e-g-newadserviceaccount-dnshostname?forum=winserver8gen

My experience seems to indicate that it's looking for a DC. I ran a test on a member server and was prompted for the -DNSHostName I ran the same test from a DC and did not receive the prompt.

Check out this link: http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx

The DNSHostName is the fully qualified domain name of your Service Account Name.

New-ADServiceAccount -name -DNSHostName

Quoting the answer by Proed on January 17, 2018 in the Why does a gMSA need a DNS host name? (thanks to @Daniel for citing it earlier).

I would recommend to set the dNSHostName just like it is set as for
the AD-Computer Object (sAMAccountName + and your Domain Suffix)

… because:

• 
  msDS-GroupManagedServiceAccount inherits from AD-Computer (in terms of AD schema), thus requiring this to be supplied


• the recommended convention makes sense of all the extant examples