La documentación contiene el ejemplo:
New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true
Este parámetro es obligatorio ¿Cuál es exactamente el propósito de a DNSHostNamey cómo debo decidir en qué configurarlo?
La documentación contiene el ejemplo:
New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true
Este parámetro es obligatorio ¿Cuál es exactamente el propósito de a DNSHostNamey cómo debo decidir en qué configurarlo?
Respuestas:
Después de trabajar durante un tiempo con estas cuentas, creo que descubrí la razón:
Son algunos subconjuntos, o quizás derivados de las cuentas de tipo máquina. Por lo tanto, heredan esta propiedad de ellos, y dado que se requiere para el tipo de máquina, también se requiere para gMSA.
Puede verificar que ambos tipos coincidan estrechamente en sus conjuntos de atributos. Además, en toda la documentación de TechNet solo dan un valor único y simple para este atributo , al igual que lo tiene una cuenta de máquina.gmsa-name.contoso.com
No estoy seguro de por qué simplemente no lo autogeneraron, y nos ahorramos el asombro y el tipeo.
DNSHostName debe ser el nombre de su servicio. En el caso de A Cluster, este sería su nombre de instancia virtual.
DNSHostName está relacionado con el registro automático de SPN de la cuenta. En Active Directory, las computadoras y los GMSA tienen el permiso "Permitir escritura validada en ServicePrincipalName". Esto significa que una computadora solo puede registrar SPN que contienen el nombre de sí misma. Ejemplo: Un servidor web con nombre de computadora1 (DNS: servidor web1.midominio.net) puede registrar automáticamente http: /Webserver1.mydomain.net: 443 pero no puede registrar http: /Webserver55.mydomain.net: 443
Por lo tanto, el DNSHostName de un GMSA debe reflejar qué SPN desea registrar para un servicio.
En un clúster de SQL, tendría 2 hosts: Host1 y host2. Un clusterName: Clu1 y una instancia virtual de SQL: SQL1 Si desea utilizar un GMSA para ejecutar el servicio SQL1, lo crearía de esta manera.
$comp1 = get-adcomputer Host1
$comp2 = get-adcomputer Host2
New-ADServiceAccount -Name gmsa01 -DNSHostName sql1.mydomain.net -PrincipalsAllowedToRetrieveManagedPassword $comp1, $comp2
(también puede usar un grupo en lugar de asignar derechos a los hosts directamente).
Cada vez que se inicia el servicio SQL, registrará automáticamente 2 SPN: MSSQLSvc / sql1.mydomain.net MSSQLSvc / sql1.mydomain.net: 1433
Si coloca algo más en DNSHostName (por ejemplo, gmsa01.mydomain.net), el servicio aún se iniciará, pero no podrá registrar SPN (y volverá a la autenticación NTLM).
Si no le importa la autenticación Kerberos (y los SPN) o si está de acuerdo con registrar manualmente los SPN para su servicio, puede poner lo que quiera en el DNSHostName. El GMSA seguirá funcionando.
No recomendaría poner su DomainController en el DNSName como se mencionó anteriormente (a menos que planee usar el GMSA para ejecutar un servicio en un controlador de dominio).
No soy un experto en esto. Sin embargo, hay tanta escasez de información sobre este tema que pensé que valía la pena publicar lo que sé
El entrenador de un curso 70-411 que tomé usó el FQDN de un controlador de dominio como el valor del DNSHostNameparámetro cuando demostró el New-ADServiceAccountcmdlet. Según tengo entendido, DNSHostNamesolo le dice al cmdlet en qué controlador de dominio crear la cuenta. No creo que importe qué DC usas, esos gMSA parecen replicarse inmediatamente de todos modos. He estado apuntando DNSHostNamea uno de mis DC y parece estar funcionando hasta ahora.
Realmente preferiría que hubiera documentación concreta sobre esto. La referencia de comando de TechNet aplicable es simplemente una tontería tautológica para el DNSHostNameparámetro.
Cuando agrega el parámetro -RestrictToSingleComputer ya no es necesario. Por supuesto, debe leer sobre esa opción antes de usarla.
Me gusta:
New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer
Estuve buscando una respuesta durante mucho tiempo y finalmente encontré una que me parece verdadera.
-DNSHostName debe ser el FQDN de ese DC que contiene la clave maestra KDS: msKds-ProvRootKey.
Lo más probable es que ya lo haya creado: eche un vistazo al contenedor del Servicio de distribución de claves de grupo en la partición de Configuración de su bosque AD.
Y probablemente podría usar cualquier DC en ese bosque siempre que establezca sus nombres en -PrincipalsAllowedToRetrieveManagedPassword
Todo lo anterior representa el "nuevo" gMSA, por lo que si desea utilizar el antiguo MSA en su lugar, simplemente olvídese de ese -DNSHostName ya que no es necesario y simplemente use -RestrictToSingleComputer bloqueando una cuenta en algún servidor.
Espero que ayude.
Citando la respuesta de Proed el 17 de enero de 2018 en ¿Por qué un gMSA necesita un nombre de host DNS? (Gracias a @Daniel por citarlo antes).
Recomendaría configurarlo
dNSHostNametal como está configurado para el objeto AD-Computer (sAMAccountName+ y su sufijo de dominio)
… porque:
msDS-GroupManagedServiceAccounthereda de AD-Computer(en términos de esquema AD), lo que requiere que se suministreConsulte este enlace: http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx
DNSHostName es el nombre de dominio completo de su nombre de cuenta de servicio.
New-ADServiceAccount -name -DNSHostName