Ustawić nazwę hosta DNS dla konta usługi zarządzanej?

Dokumentacja zawiera przykładowe:

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

Ten parametr jest wymagany. Jaki jest dokładnie cel DNSHostNamei jak powinienem zdecydować, na co go ustawić?

Po dłuższej pracy z tymi kontami, chyba znalazłem powód:

Są to niektóre podzbiory, a może pochodne kont typu maszyny. Dlatego dziedziczą po nich tę właściwość, a ponieważ jest wymagana dla typu komputera, jest również wymagana dla gMSA.

Możesz sprawdzić, czy oba typy są ściśle ze sobą zgodne w zestawach atrybutów. Również we wszystkich dokumentacjach TechNet podają po prostu prostą unikalną wartość tego atrybutu , tak jak ma to konto komputera.gmsa-name.contoso.com

Nie jestem pewien, dlaczego po prostu nie wygenerowali go automatycznie i oszczędzają nam zastanawiania się i pisania.

DNSHostName powinna być nazwą twojej usługi. W przypadku klastra będzie to nazwa instancji wirtualnej.

nazwa DNSHostName jest związana z automatyczną rejestracją konta SPN. W usłudze Active Directory komputery i GMSA mają uprawnienie „Zezwalaj na sprawdzanie poprawności zapisu do ServicePrincipalName”. Oznacza to, że komputer może rejestrować tylko nazwy SPN, które zawierają jego nazwę. Przykład: komputer o nazwie Webserver1 (DNS: Webserver1.mydomain.net) może automatycznie zarejestrować http: /Webserver1.mydomain.net: 443, ale nie może zarejestrować http: /Webserver55.mydomain.net: 443

Zatem nazwa DNSHostN GMSA powinna odzwierciedlać nazwy SPN, które chcesz zarejestrować w usłudze.

W klastrze SQL masz 2 hosty: Host1 i Host2. Nazwa klastra: Clu1 i wirtualna instancja SQL: SQL1 Jeśli chcesz użyć usługi GMSA do uruchomienia usługi SQL1, możesz ją utworzyć w ten sposób.

$comp1 = get-adcomputer Host1

$comp2 = get-adcomputer Host2

New-ADServiceAccount -Name gmsa01 -DNSHostName sql1.mydomain.net -PrincipalsAllowedToRetrieveManagedPassword $comp1, $comp2 (możesz także użyć grupy zamiast przypisywać prawa bezpośrednio do hostów).

Za każdym razem, gdy usługa SQL się uruchamia, automatycznie rejestruje 2 nazwy SPN: MSSQLSvc / sql1.mydomain.net MSSQLSvc / sql1.mydomain.net: 1433

Jeśli umieścisz coś innego w DNSHostName (na przykład gmsa01.mydomain.net), usługa nadal będzie działać, ale rejestracja nazw SPN (i powrót do uwierzytelniania NTLM) nie powiedzie się.

Jeśli nie obchodzi Cię uwierzytelnianie Kerberos (i nazwy SPN) lub jeśli nie masz nic przeciwko ręcznej rejestracji nazw SPN dla swojej usługi, możesz wpisać dowolną nazwę w DNSHostName. GMSA nadal będzie działać.

Nie polecam umieszczania kontrolera domeny w nazwie DNSName, jak wspomniano wcześniej (chyba że planujesz używać GMSA do uruchamiania usługi na kontrolerze domeny).

Nie jestem w tym ekspertem. Jest jednak tak mało informacji na ten temat, że uznałem, że warto opublikować to, co wiem

Trener kursu 70-411, który wziąłem, użył nazwy FQDN kontrolera domeny jako wartości DNSHostNameparametru, gdy zademonstrował polecenie New-ADServiceAccountcmdlet. Jak rozumiem, DNSHostNamepo prostu informuje cmdlet, który kontroler domeny ma utworzyć konto. Nie sądzę, że ma to znaczenie, jakiego DC używasz, te gMSA wydają się zresztą natychmiast replikować. Wskazałem DNSHostNamena jedno z moich DC i wydaje się, że do tej pory działa.

Naprawdę wolałbym, żeby była na to konkretna dokumentacja. Dotyczy odniesienie komenda TechNet tylko tautologiczna nonsens dla DNSHostNameparametru.

Po dodaniu parametru -RestrictToSingleComputer nie jest już wymagany. Oczywiście powinieneś przeczytać o tej opcji przed jej użyciem.

Lubić:

New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer

Bardzo długo szukałem odpowiedzi i wreszcie znalazłem taką, która wydaje mi się prawdziwa.

-DNSHostName powinna być nazwą FQDN tego kontrolera domeny, który przechowuje klucz główny KDS - msKds-ProvRootKey.

Najprawdopodobniej już go utworzyłeś - spójrz na kontener usługi Group Key Distribution Service na partycji konfiguracji lasu AD.

I prawdopodobnie możesz użyć dowolnego kontrolera domeny w tym lesie, o ile ustawisz ich nazwy w -PrincipalsAllowedToRetrieveManagedPassword

Wszystkie powyższe reprezentują „nowy” gMSA, więc jeśli zamiast tego chcesz użyć starego MSA, po prostu zapomnij o tej -DNSHostName, ponieważ nie jest to wtedy wymagane, i po prostu użyj -RestrictToSingleComputer blokując konto na jakimś serwerze.

Mam nadzieję, że to pomaga.

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

Moje doświadczenie wskazuje, że szuka DC. Przeprowadziłem test na serwerze członkowskim i zostałem poproszony o podanie -DNSHostName. Uruchomiłem ten sam test z kontrolera domeny i nie otrzymałem monitu.

Cytując odpowiedź Proed 17 stycznia 2018 r. W Dlaczego gMSA potrzebuje nazwy hosta DNS? (dzięki @Daniel za zacytowanie go wcześniej).

Poleciłbym ustawić dokładnie dNSHostNametak, jak jest ustawiony dla obiektu komputera AD ( sAMAccountName+ i sufiks domeny)

… bo:

• msDS-GroupManagedServiceAccountdziedziczy po AD-Computer(pod względem schematu AD), co wymaga dostarczenia tego
• zalecana konwencja ma sens dla wszystkich zachowanych przykładów

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

DNSHostName to w pełni kwalifikowana nazwa domeny Twojego konta usługi.

New-ADServiceAccount -name -DNSHostName