Definir nome do host DNS para a conta de serviço gerenciado?

A documentação contém o exemplo:

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

Este parâmetro é obrigatório. Qual é exatamente o objetivo de a DNSHostNamee como devo decidir o que definir?

Depois de trabalhar um pouco com essas contas, acho que descobri o motivo:

Eles são um subconjunto ou talvez derivado das contas de tipo de máquina. Portanto, eles herdam essa propriedade e, como é necessária para o tipo de máquina, também é necessária para o gMSA.

Você pode verificar se os dois tipos correspondem de perto nos conjuntos de atributos. Além disso, em toda a documentação do TechNet , eles apenas fornecem um valor único e simples para esse atributo gmsa-name.contoso.com, assim como a conta de uma máquina.

Não sei por que eles simplesmente não o geraram automaticamente e nos poupam da imaginação e da digitação.

O DNSHostName deve ser o nome do seu serviço. No caso de um cluster, esse seria o nome da sua instância virtual.

o DNSHostName está relacionado ao registro automático de SPN da conta. No Active Directory, computadores e GMSAs têm a permissão "Permitir gravação validada no ServicePrincipalName". Isso significa que um computador pode registrar apenas SPNs que contenham o próprio nome. Exemplo: Um computador chamado Webserver1 (DNS: Webserver1.mydomain.net) pode registrar automaticamente http: /Webserver1.mydomain.net: 443, mas não pode registrar http: /Webserver55.mydomain.net: 443

Portanto, o DNSHostName de um GMSA deve refletir quais SPNs você deseja registrar para um serviço.

Em um cluster SQL, você teria 2 hosts: Host1 e host2. Um clusterName: Clu1 e uma Virtual SQL Instance: SQL1 Se você deseja usar um GMSA para executar o serviço SQL1, crie-o assim.

$comp1 = get-adcomputer Host1

$comp2 = get-adcomputer Host2

New-ADServiceAccount -Name gmsa01 -DNSHostName sql1.mydomain.net -PrincipalsAllowedToRetrieveManagedPassword $comp1, $comp2 (você também pode usar um grupo em vez de atribuir direitos diretamente aos hosts).

Sempre que o serviço SQL for iniciado, ele registrará automaticamente 2 SPNs: MSSQLSvc / sql1.mydomain.net MSSQLSvc / sql1.mydomain.net: 1433

Se você colocar outra coisa no DNSHostName (por exemplo, gmsa01.mydomain.net), o serviço ainda será iniciado, mas falhará ao registrar os SPNs (e voltará à autenticação NTLM).

Se você não se importa com a Autenticação Kerberos (e SPNs) ou se concorda com o registro manual de SPNs para seu serviço, você pode colocar o que quiser no DNSHostName. O GMSA ainda funcionará.

Eu não recomendaria colocar seu DomainController no DNSName, como mencionado anteriormente (a menos que você planeje usar o GMSA para executar um serviço em um controlador de domínio).

Eu não sou especialista nisso. No entanto, há uma escassez de informações sobre esse tópico que achei que valeria a pena postar o que sei

O instrutor de um curso 70-411 que eu fiz usou o FQDN de um controlador de domínio como o valor do DNSHostNameparâmetro quando ele demonstrou o New-ADServiceAccountcmdlet. Pelo que entendi, DNSHostNameapenas informa ao cmdlet qual controlador de domínio no qual criar a conta. Eu não acho que importa qual controlador de domínio você usa, esses gMSA parecem replicar imediatamente de qualquer maneira. Eu tenho apontado DNSHostNamepara um dos meus DCs e parece estar funcionando até agora.

Eu realmente prefiro que haja alguma documentação concreta sobre isso. A referência de comando do TechNet aplicável é apenas um absurdo tautológico para o DNSHostNameparâmetro.

Quando você adiciona o parâmetro -RestrictToSingleComputer, ele não é mais necessário. Claro que você deve ler sobre essa opção antes de usá-la.

Gostar:

New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer

Eu procurava uma resposta há muito tempo e finalmente encontrei uma que me parecesse verdadeira.

-DNSHostName deve ser o FQDN daquele controlador de domínio que contém a chave mestre do KDS - msKds-ProvRootKey.

Provavelmente você já criou esse - dê uma olhada no contêiner do Serviço de Distribuição de Chaves de Grupo na partição Configuração da sua floresta do AD.

E provavelmente você pode usar qualquer controlador de domínio nessa floresta, desde que defina seus nomes em -PrincipalsAllowedToRetrieveManagedPassword

Todas as opções acima representam o "novo" gMSA; portanto, se você deseja usar o MSA antigo, esqueça o -DNSHostName, pois ele não é necessário e simplesmente use -RestrictToSingleComputer bloqueando uma conta em algum servidor.

Espero que ajude.

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

Minha experiência parece indicar que está procurando um controlador de domínio. Fiz um teste em um servidor membro e foi solicitado o -DNSHostName Fiz o mesmo teste em um controlador de domínio e não recebi o prompt.

Citando a resposta de Proed em 17 de janeiro de 2018 na seção Por que um gMSA precisa de um nome de host DNS? (obrigado a @ Daniel por citá-lo anteriormente).

Eu recomendaria definir dNSHostNameexatamente como está definido para o objeto AD-Computer ( sAMAccountName+ e o sufixo de domínio)

… Porque:

• msDS-GroupManagedServiceAccountherda de AD-Computer(em termos de esquema do AD), exigindo que isso seja fornecido
• a convenção recomendada faz sentido de todos os exemplos existentes

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

O DNSHostName é o nome de domínio totalmente qualificado do seu Nome de Conta de Serviço.

New-ADServiceAccount -name -DNSHostName