Установить DNS-имя хоста для учетной записи управляемого сервиса?

Документация содержит пример:

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

Этот параметр является обязательным. Какова цель a DNSHostNameи как мне решить, на что его установить?

Поработав некоторое время с этими учетными записями, думаю, я выяснил причину:

Они представляют собой некоторое подмножество или, возможно, производные от учетных записей машинного типа. Поэтому они наследуют это свойство от них, и поскольку оно требуется для типа машины, оно также требуется для gMSA.

Вы можете проверить, что оба типа близко совпадают в наборах атрибутов. Также во всей документации TechNet они просто дают уникальное значение для этого атрибута , точно так же, как его имеет учетная запись компьютера.gmsa-name.contoso.com

Не уверен, почему они просто не сгенерировали его, и избавили нас от удивления и набора текста.

DNSHostName должно быть именем вашей службы. В случае кластера это будет ваше имя виртуального экземпляра.

DNSHostName связано с автоматической регистрацией учетной записи SPN. В Active Directory компьютеры и GMSA имеют разрешение «Разрешить проверенную запись в ServicePrincipalName». Это означает, что компьютер может регистрировать только имена участников-служб, содержащие имя самого себя. Пример: компьютер с именем Webserver1 (DNS: Webserver1.mydomain.net) может автоматически зарегистрировать http: /Webserver1.mydomain.net: 443, но не может зарегистрировать http: /Webserver55.mydomain.net: 443

Таким образом, DNSHostName GMSA должно отражать, какие SPN вы хотите зарегистрировать для службы.

В кластере SQL у вас будет 2 хоста: Host1 и host2. Имя кластера: Clu1 и экземпляр виртуального SQL: SQL1 Если вы хотите использовать GMSA для запуска службы SQL1, вы должны создать ее следующим образом.

$comp1 = get-adcomputer Host1

$comp2 = get-adcomputer Host2

New-ADServiceAccount -Name gmsa01 -DNSHostName sql1.mydomain.net -PrincipalsAllowedToRetrieveManagedPassword $comp1, $comp2 (Вы также можете использовать группу вместо назначения прав хостам напрямую).

Каждый раз, когда служба SQL запускается, она автоматически регистрирует 2 SPN: MSSQLSvc / sql1.mydomain.net MSSQLSvc / sql1.mydomain.net: 1433

Если вы поместите что-то еще в DNSHostName (например, gmsa01.mydomain.net), служба все равно запустится, но не сможет зарегистрировать имена участников-служб (и вернуться к аутентификации NTLM).

Если вас не волнует аутентификация Kerberos (и SPN) или если вы не согласны с регистрацией SPN вручную для своей службы, вы можете поместить в DNSHostName все, что захотите. GMSA все еще будет работать.

Я бы не рекомендовал помещать ваш DomainController в DNSName, как упоминалось ранее (если только вы не планируете использовать GMSA для запуска службы на контроллере домена).

Я не эксперт в этом. Тем не менее, существует такая нехватка информации по этой теме, я думал, что стоит опубликовать то, что я знаю

Тренер курса 70-411, который я взял, использовал полное доменное имя контроллера домена в качестве значения DNSHostNameпараметра, когда демонстрировал New-ADServiceAccountкомандлет. Насколько я понимаю, DNSHostNameпросто сообщает командлету, какой контроллер домена на каком аккаунте создать. Я не думаю, что имеет значение, какой DC вы используете, эти gMSA, похоже, сразу же реплицируются. Я указывал DNSHostNameна один из моих DC, и кажется, что он работает до сих пор.

Я бы предпочел, чтобы была какая-то конкретная документация по этому вопросу. Применимая ссылка команды TechNet просто тавтологическое нонсенс для DNSHostNameпараметра.

Когда вы добавляете параметр -RestrictToSingleComputer, он больше не требуется. Конечно, вы должны прочитать об этой опции, прежде чем использовать ее.

Подобно:

New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer

Я очень долго искал ответ и, наконец, нашел тот, который звучит правдоподобно для меня.

-DNSHostName должно быть полным доменным именем того DC, который содержит мастер-ключ KDS - msKds-ProvRootKey.

Скорее всего, вы уже создали это - взгляните на контейнер службы распределения ключей группы в разделе конфигурации вашего леса AD.

И, возможно, вы могли бы использовать любой DC в этом лесу, если вы указали их имена в -PrincipalsAllowedToRetrieveManagedPassword

Все вышеперечисленное представляет собой «новый» gMSA, поэтому, если вы хотите использовать вместо него старый MSA, просто забудьте об этом -DNSHostName, поскольку он не требуется, и просто используйте -RestrictToSingleComputer, блокируя учетную запись на каком-либо сервере.

Надеюсь, это поможет.

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? форум = winserver8gen

Мой опыт показывает, что он ищет DC. Я запустил тест на рядовом сервере и получил запрос на имя -DNSHostName. Я запустил тот же тест из DC и не получил приглашение.

Цитирую ответ Proed от 17 января 2018 г. в разделе Почему gMSA требуется имя хоста DNS? (спасибо @Daniel за цитирование ранее).

Я бы порекомендовал установить так dNSHostNameже, как и для объекта AD-Computer ( sAMAccountName+ и суффикс вашего домена)

… так как:

• msDS-GroupManagedServiceAccountнаследуется от AD-Computer(с точки зрения схемы AD), что требует его предоставления
• рекомендуемое соглашение имеет смысл всех существующих примеров

Проверьте эту ссылку: http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx

DNSHostName - это полное доменное имя вашей учетной записи службы.

New-ADServiceAccount -name -DNSHostName