La documentazione contiene l'esempio:
New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true
Questo parametro è obbligatorio Qual è esattamente lo scopo di a DNSHostNamee come devo decidere su cosa impostarlo?
La documentazione contiene l'esempio:
New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true
Questo parametro è obbligatorio Qual è esattamente lo scopo di a DNSHostNamee come devo decidere su cosa impostarlo?
Risposte:
Dopo aver lavorato per un po 'con questi account, penso di aver scoperto il motivo:
Sono alcuni sottoinsiemi o forse derivati degli account del tipo di macchina. Pertanto ereditano da loro questa proprietà e, poiché è richiesta per il tipo di macchina, è richiesta anche per gMSA.
È possibile verificare che entrambi i tipi corrispondano strettamente nei rispettivi set di attributi. Inoltre in tutta la documentazione TechNet forniscono solo un semplice valore univoco per questo attributo , proprio come lo ha un account macchina.gmsa-name.contoso.com
Non sono sicuro del motivo per cui non l'hanno generata automaticamente e ci hanno risparmiato lo stupore e la digitazione.
DNSHostName dovrebbe essere il nome del tuo servizio. Nel caso di un cluster, questo sarebbe il nome dell'istanza virtuale.
DNSHostName è correlato alla registrazione automatica SPN dell'account. In Active Directory Computer e GMSA dispongono dell'autorizzazione "Consenti scrittura convalidata su ServicePrincipalName". Ciò significa che un computer può registrare solo SPN che contengono il nome stesso. Esempio: un computer denominato Webserver1 (DNS: Webserver1.mydomain.net) può registrare automaticamente http: /Webserver1.mydomain.net: 443 ma non può registrare http: /Webserver55.mydomain.net: 443
Quindi, DNSHostName di un GMSA dovrebbe riflettere gli SPN che si desidera registrare per un servizio.
Su un cluster SQL, avresti 2 host: Host1 e host2. Un clusterName: Clu1 e un'istanza SQL virtuale: SQL1 Se si desidera utilizzare un GMSA per eseguire il servizio SQL1, è necessario crearlo in questo modo.
$comp1 = get-adcomputer Host1
$comp2 = get-adcomputer Host2
New-ADServiceAccount -Name gmsa01 -DNSHostName sql1.mydomain.net -PrincipalsAllowedToRetrieveManagedPassword $comp1, $comp2
(puoi anche usare un gruppo invece di assegnare direttamente i diritti agli host).
Ogni volta che si avvia il servizio SQL, registrerà automaticamente 2 SPN: MSSQLSvc / sql1.mydomain.net MSSQLSvc / sql1.mydomain.net: 1433
Se inserisci qualcos'altro nel DNSHostName (ad esempio gmsa01.mydomain.net), il servizio verrà comunque avviato, ma non riuscirà a registrare gli SPN (e tornerà all'autenticazione NTLM).
Se non ti interessa l'autenticazione Kerberos (e gli SPN) o se sei d'accordo con la registrazione manuale degli SPN per il tuo servizio, puoi inserire quello che vuoi nel DNSHostName. GMSA continuerà a funzionare.
Non consiglierei di inserire DomainController nel DNSName come menzionato in precedenza (a meno che non preveda di utilizzare GMSA per eseguire un servizio su un controller di dominio).
Non sono esperto in questo. Tuttavia, c'è una tale carenza di informazioni su questo argomento che ho pensato valesse la pena pubblicare ciò che so
Il trainer di un corso 70-411 che ho seguito ha usato l'FQDN di un controller di dominio come valore per il DNSHostNameparametro quando ha dimostrato il New-ADServiceAccountcmdlet. A quanto mi risulta, DNSHostNameindica al cmdlet quale controller di dominio su cui creare l'account. Non credo sia importante quale DC usi, quei gMSA sembrano replicarsi immediatamente comunque. Ho indicato DNSHostNameuno dei miei controller di dominio e sembra funzionare finora.
Preferirei davvero che ci fosse una documentazione concreta su questo. Il riferimento al comando TechNet applicabile è solo una sciocchezza tautologica per il DNSHostNameparametro.
Quando si aggiunge il parametro -RestrictToSingleComputer non è più necessario. Naturalmente dovresti leggere questa opzione prima di usarla.
Piace:
New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer
Stavo cercando una risposta da molto tempo e finalmente ho trovato quella che mi sembrava vera.
-DNSHostName dovrebbe essere l'FQDN di quel controller di dominio che contiene la chiave master KDS - msKds-ProvRootKey.
Molto probabilmente lo hai già creato: dai un'occhiata al contenitore del servizio di distribuzione delle chiavi di gruppo nella partizione di configurazione della tua foresta AD.
E probabilmente potresti usare qualsiasi controller di dominio in quella foresta fintanto che imposti i loro nomi in -PrincipalsAllowedToRetrieveManagedPassword
Tutto quanto sopra rappresenta il "nuovo" gMSA, quindi se si desidera utilizzare il vecchio MSA, basta dimenticare quel -DNSHostName poiché non è necessario e utilizzare semplicemente -RestrictToSingleComputer bloccando un account su un server.
Spero possa aiutare.
Citando la risposta di Proed il 17 gennaio 2018 in Perché un gMSA necessita di un nome host DNS? (grazie a @ Daniel per averlo citato in precedenza).
Vorrei raccomandare di impostare
dNSHostNameesattamente come è impostato per l'oggetto Computer AD (sAMAccountName+ e il tuo suffisso di dominio)
… perché:
msDS-GroupManagedServiceAccounteredita da AD-Computer(in termini di schema AD), richiedendo quindi che questo venga fornitoDai un'occhiata a questo link: http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx
DNSHostName è il nome di dominio completo del nome dell'account del servizio.
New-ADServiceAccount -name -DNSHostName