none
Why does a gMSA need a DNS host name? (e. g. New-ADServiceAccount ... -DNSHostName ITFarm1.contoso.com) RRS feed

Answers

  • Something that dind't meansioned in this thread already (or i over read it: in this case - sorry about my interrupt)

    In my understanding, the dNSHostName attribute comes because of the type of the object.

    A gMSA object is more like a AD-Computer Object (as Password change behavior is also the same etc.). I believe, the gMSA Account is in fact almost a copy & paste of the computer object with some enhancements (e.g. functions to utilities PrincipalsAllowedToRetrieveManagedPassword etc.).

    i believe this, because of the following attribute & values on a gMSA Account:
    sAMAccountName <myName>$ (ends with "$")
    sAMAccountType = MACHINE_ACCOUNT
    userAccountControl = WORKSTATION_TRUST_ACCOUNT
    primaryGroupID = GROUP_RID_COMPUTERS

    and guess which is the parent class from msDS-GroupManagedServiceAccoount? .. right Computer

    ... all pointing to a well known AD-Computer Object and thats also fine and gives me the clue for the dNSHostName Attribute:

    Each Computer Object has it's FQDN in that attribute.
    I would recommend to set the dNSHostName just like it is set as for the AD-Computer Object (sAMAccountName + and your Domain Suffix). Of course sAMAccountName without the "$".

    And now you can see, it doesn't matter if you are deploying a multi server farm / application or something with a single server, as the Attribute is not relevant for authentication (like SPN) etc.



    • Edited by Proed Wednesday, January 17, 2018 5:48 PM
    • Proposed as answer by andresz Tuesday, May 8, 2018 10:05 PM
    • Marked as answer by ϻοϰsϯεr Sunday, March 10, 2019 5:06 PM
    Wednesday, January 17, 2018 5:46 PM
  • I have done some reading...

    I have done some testing...

    the -DNSHostName is simply an account attribute refering to the FQDN of the service account you are creating. My test was simply to give it a silly name 'bob.domain.com' where the service account name was 'service'. So just call it the name of the service account with the domain name tacked on the end e.g. 'service.domain.com'. This is the same as if you were setting up a normal user account in AD. you can change the FQDN if you want to but it is not advised unless you have a very specific reason for it.

    The whole concept of the MSA/gMSA is that the domain manages the service account for you so as long as it knows which domain it is in it can manage the rest. As the service you are assigning the service account to is on a "domain Member Server" it already knows the domain so (as Markus E infers) those that use the domain controller are missing the point of the FQDN and a server being a member of a domain.

    The whole problem with the Microsoft documentation is that (as Peter Baumert mentioned) it refers to -DNSHostName as the "DNS host name of Service". What they should refer to it as is "DNS host name of Service Account". I'm not sure why they use "DNS Host" in the description and not "FQDN" but I'm sure Microsoft had their reasons beyond my mere mortal comprehension.

    For most people the -DNSHostName will have very little bearing on the service account setup as long as they use the format serviceaccountname.domain.com as the variable. I would imagine it may have more bearing when you are dealing with more complex AD environments such as farms or forest management.

    The important variable to specify in the account creation is the PrincipalsAllowedToRetrieveManagedPassword variable. This is either the single server you want to use the service account on or a group you have created in AD with the membership of all the servers you want to be able to use the service account on (The main point of g in gMSA).

    I hope this helps clarify things for people.

    • Proposed as answer by JinjaAdmin Wednesday, July 18, 2018 12:04 PM
    • Marked as answer by ϻοϰsϯεr Sunday, March 10, 2019 5:07 PM
    Wednesday, July 18, 2018 11:58 AM

All replies

  • Hi,

    Thank you for your posting.

    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

    Best Regards,

    Amy
    Monday, May 19, 2014 8:15 AM
    Moderator
  • Much appreciated!
    Monday, May 19, 2014 10:42 AM
  • Hi,

    -DNSHostname parameter defines the host that uses the managed service account.

    You could check the following post to learn details: http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx

    Regards, Brian


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, May 20, 2014 10:26 AM
  • Hi Brian,

    thanks for your reply. However, I don't think it is correct. A gMSA may be used by a group of computer accounts defined by the parameter PrincipalsAllowedToRetrieveManagedPassword.

    Also, the linked article does not explain the DNSHostName parameter. Plus, the DNSHostName used in the example does not represent a computer or computer account.

    Regards,

    Monster

    Tuesday, May 20, 2014 12:51 PM
  • DNSHostName is the Computer that will use MSA, you could do this on multiple computer; Group name is defined by PrincipalsAllowedToRetrieveManagedPassword

    You could open up a Support ticket to confirm this point.

    Regards, Brian


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by ϻοϰsϯεr Monday, May 26, 2014 10:40 AM
    • Unmarked as answer by ϻοϰsϯεr Monday, May 26, 2014 10:46 AM
    Wednesday, May 21, 2014 9:52 AM
  • If it is so, then what happens if I want to use it on multiple computers (members of the group PrincipalsAllowedToRetrieveManagedPassword) run the command, defining the DNSHostName's of all the computers? If so, then what is the purpose of the group anyway? If not, then what is the purpose of DNSHostName then?!

    Thursday, May 22, 2014 6:33 AM
  • Yes, modify the DNSHostName if you want an additional host to use MSA. It's why we call it gMSA. sMSA, one account for one host only. Adding these hosts to a group makes it more convenient in management.

    Regards, Brian


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, May 23, 2014 6:08 AM
  • Hi Brian, it is not the DNShostname of the host where you want to use it. In all documention even of MS itself it has the servicename as DNShostname.

    //EDIT:

    http//technet. microsoft. com/en-us/library/jj128431.aspx

    Here you can see it is stated as "DNS host name of Service".

    Kind Regards,

    Peter


    • Edited by Peter Baumert Tuesday, July 22, 2014 1:31 PM added link
    Tuesday, July 22, 2014 1:20 PM
  • Peter, I still have problems understanding this. Could you give me a practical example?
    Friday, July 25, 2014 8:44 AM
  • I can't tell you where or what it is used for, because I have simply never seen it being used. I guess the reason it is there is because the "Managed Service Account" is kind of a child-object of an Computer Account and inherits its properties from that one.

    But as I said this is just a guess ;)

    Kind Regards,

    Peter

    Monday, August 4, 2014 8:34 AM
  • this is not an answer, Moderator.

    Friday, February 20, 2015 5:59 PM
  • I too am wondering what this parameter means. Signs point to it simply being the FQDN of the MSA but no one has in fact verified this.
    Friday, April 3, 2015 2:34 AM
  • -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.

    Saturday, May 9, 2015 12:59 PM
  • The help documentation has been updated, and as of August, 2015, the parameters are now described as follows:

    Parameter String Example

    Name

    Name of the account

    ITFarm1

    DNSHostName

    DNS host name of the service

    ITFarm1.contoso.com

    KerberosEncryptionType

    Each of the host server supported encryption type

    RC4, AES128, AES256

    ManagedPasswordIntervalInDays

    Password change interval in days (default is 30 if not specified)

    90

    PrincipalsAllowedToRetrieveManagedPassword

    The computer accounts of the member hosts or security group that is hosting the Member, are members of

    ITFarmHosts

    SamAccountName

    NetBIOS name for the service, unless this "name" corresponds to

    ITFarm1

    In my testing, this seems to be correct.


    If this post was helpful, please vote up or 'Mark as Answer'! More of this sort of thing at www.foxdeploy.com

    Wednesday, August 26, 2015 3:12 PM
  • Why would a service have a hostname? Does this mean the hostname of the computer that is RUNNING the service?
    Thursday, February 11, 2016 6:28 PM
  • -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.

    Sorry this is the wrongest of all interpretations. I wonder how/where you have constructed this DC/KDS theory from? Yes, you need a specific KDS key for gMSA - whose creation is a separate act from account creation using a separate cmdlet.

    As others posted and as can be seen from https://technet.microsoft.com/en-us/library/jj128431(v=ws.11).aspx DNSHostName relates to a "farm"/service name where it is used. This is easy to understand in load balancing/IIS scenarios. What bugs me too, however, is how this farm name relates in scenarios where there might be more servers but technically not really a farm name, round robin or the likes.

    For example Software Inventory Logging (SIL) supports gMSA accounts for the Aggregator service. However, the documentation is scarce about how this account will be used. Maybe it shall be interpreted as an outbound-only account which does not require DNSHostName; but this just isn't documented.

    So as of now I only see two possibilities: The computer FQDN where it is used (a sound suggestion several people made here); or an arbitrary DNS name like username.domain.tld as used in the article above and in the example: https://blogs.technet.microsoft.com/askpfeplat/2012/12/16/windows-server-2012-group-managed-service-accounts/
    For farms it is pretty obious to me that it is the farm name; so if your users use something like https://intranet.mydomain.net to access a web site comprised of/balanced between server1.mydomain.net and server2.mydomain.net, then the DNSHostName for the shared gMSA has to be intranet.mydomain.net.

    To add some more thoughts, I see some attempts at justifying the DC theory here: https://serverfault.com/questions/503823/set-dns-host-name-for-managed-service-account

    However, this makes me ask two questions:

    1. How could I then create a gMSA from my workstation PC with an arbitrary user-based DNS name not a DC name? The account has been created successfully without asking anything.

    2. What good would it do to specify a single DC in a fault-tolerant meshed AD as it is expected to be? Single DC deployments are a no-go far from any MS best practices. And ANY DC has the KDC role and the KDS root key must be distributed to all DCs before it can be used at all (https://technet.microsoft.com/en-us/library/jj128430%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396).

    So I see no sound reasoning for the DC theory at all.

    • Edited by Markus E Wednesday, October 11, 2017 12:33 PM Added some more thoughts about the DC theory.
    Wednesday, October 11, 2017 12:19 PM
  • Something that dind't meansioned in this thread already (or i over read it: in this case - sorry about my interrupt)

    In my understanding, the dNSHostName attribute comes because of the type of the object.

    A gMSA object is more like a AD-Computer Object (as Password change behavior is also the same etc.). I believe, the gMSA Account is in fact almost a copy & paste of the computer object with some enhancements (e.g. functions to utilities PrincipalsAllowedToRetrieveManagedPassword etc.).

    i believe this, because of the following attribute & values on a gMSA Account:
    sAMAccountName <myName>$ (ends with "$")
    sAMAccountType = MACHINE_ACCOUNT
    userAccountControl = WORKSTATION_TRUST_ACCOUNT
    primaryGroupID = GROUP_RID_COMPUTERS

    and guess which is the parent class from msDS-GroupManagedServiceAccoount? .. right Computer

    ... all pointing to a well known AD-Computer Object and thats also fine and gives me the clue for the dNSHostName Attribute:

    Each Computer Object has it's FQDN in that attribute.
    I would recommend to set the dNSHostName just like it is set as for the AD-Computer Object (sAMAccountName + and your Domain Suffix). Of course sAMAccountName without the "$".

    And now you can see, it doesn't matter if you are deploying a multi server farm / application or something with a single server, as the Attribute is not relevant for authentication (like SPN) etc.



    • Edited by Proed Wednesday, January 17, 2018 5:48 PM
    • Proposed as answer by andresz Tuesday, May 8, 2018 10:05 PM
    • Marked as answer by ϻοϰsϯεr Sunday, March 10, 2019 5:06 PM
    Wednesday, January 17, 2018 5:46 PM
  • Think like a virtual name for a cluster or load balancer, that might be the best analogy. Whether this is "single node" or not - you can't/mustn't give it the same value of an existing computer account. Two discrete objects with the same name can only mean trouble. I'd say choose a service name then <YourServiceName>$ and <YourServiceName>.<YourDnsDomain> will be your "Name" and "DnsHostName".
    Wednesday, May 9, 2018 7:51 AM
  • That's a brilliant investigation and explanation - I come to think of gMSA now like a virtual cluster or load balancer name, single node or multiple nodes doesn't matter.

    Wednesday, May 9, 2018 7:56 AM
  • I have done some reading...

    I have done some testing...

    the -DNSHostName is simply an account attribute refering to the FQDN of the service account you are creating. My test was simply to give it a silly name 'bob.domain.com' where the service account name was 'service'. So just call it the name of the service account with the domain name tacked on the end e.g. 'service.domain.com'. This is the same as if you were setting up a normal user account in AD. you can change the FQDN if you want to but it is not advised unless you have a very specific reason for it.

    The whole concept of the MSA/gMSA is that the domain manages the service account for you so as long as it knows which domain it is in it can manage the rest. As the service you are assigning the service account to is on a "domain Member Server" it already knows the domain so (as Markus E infers) those that use the domain controller are missing the point of the FQDN and a server being a member of a domain.

    The whole problem with the Microsoft documentation is that (as Peter Baumert mentioned) it refers to -DNSHostName as the "DNS host name of Service". What they should refer to it as is "DNS host name of Service Account". I'm not sure why they use "DNS Host" in the description and not "FQDN" but I'm sure Microsoft had their reasons beyond my mere mortal comprehension.

    For most people the -DNSHostName will have very little bearing on the service account setup as long as they use the format serviceaccountname.domain.com as the variable. I would imagine it may have more bearing when you are dealing with more complex AD environments such as farms or forest management.

    The important variable to specify in the account creation is the PrincipalsAllowedToRetrieveManagedPassword variable. This is either the single server you want to use the service account on or a group you have created in AD with the membership of all the servers you want to be able to use the service account on (The main point of g in gMSA).

    I hope this helps clarify things for people.

    • Proposed as answer by JinjaAdmin Wednesday, July 18, 2018 12:04 PM
    • Marked as answer by ϻοϰsϯεr Sunday, March 10, 2019 5:07 PM
    Wednesday, July 18, 2018 11:58 AM
  • I like this analogy and have added my own comment above with more flesh on the bone for those (like me) that need more detail before they fully grasp the idea.

    Thanks

    Wednesday, July 18, 2018 12:03 PM
  • I rarely use groups for PrincipalsAllowedToRetrievePassword. If there is more than one server, I just specify all of them using a comma separated list. If I need to add or remove a server, I update the parameter using Set-ADServiceAccount. Groups certainly work as well though.
    • Edited by Evan T Wednesday, July 18, 2018 2:16 PM Spelling error
    Wednesday, July 18, 2018 2:16 PM
  • Hi All,

    Great thread.

    My concern with the DNSHostName setting is what happens when this DNS server is decommissioned/unavailable?

    This requirement seems to have created a single point of failure. If so, perhaps using the domain controller's configured DNS servers would be a better solution.

    Has anyone tried decommissioning the server defined in the DNSHostName setting?

    Wal.


    Sunday, August 5, 2018 10:34 PM