Set DNS host name for managed service account?
Solution 1:
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.
Solution 2:
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).
Solution 3:
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.
Solution 4:
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