В документация содержит пример:
New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true
Этот параметр обязателен. Какова именно цель DNSHostName и как мне решить, на что его установить?
Поработав какое-то время с этими учетными записями, я думаю, что выяснил причину:
Они являются некоторым подмножеством или, возможно, производными от учетных записей машинного типа. Поэтому они наследуют это свойство от них, и, поскольку оно требуется для типа машины, оно также требуется для gMSA.
Вы можете проверить, что оба типа точно соответствуют в наборах атрибутов. Также во всех TechNet документация они просто дают простое уникальное значение для этого атрибута, gmsa-name.contoso.com, точно так же, как учетная запись машины.
Не уверен, почему они просто не сгенерировали его автоматически и избавили нас от удивления и набора текста.
DNSHostName должно быть именем вашей службы. В случае кластера это будет имя вашего виртуального экземпляра.
DNSHostName связано с автоматической регистрацией SPN учетной записи. В Active Directory компьютеры и GMSA имеют разрешение «Разрешить подтвержденную запись в ServicePrincipalName». Это означает, что компьютер может регистрировать только те SPN, которые содержат его собственное имя. Пример: компьютер с именем 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), служба все равно запустится, но не сможет зарегистрировать SPN (и вернуться к проверке подлинности NTLM).
Если вас не интересует аутентификация Kerberos (и имена участников-служб) или если вас устраивает ручная регистрация имен участников-служб для своей службы, вы можете указать все, что хотите, в DNSHostName. GMSA по-прежнему будет работать.
Я бы не рекомендовал помещать ваш DomainController в DNSName, как упоминалось ранее (если вы не планируете использовать GMSA для запуска службы на контроллере домена).
Я не специалист в этом. Однако информации по этой теме так мало, что я подумал, что стоит опубликовать то, что я знаю
Тренер 70-411 конечно, я использовал полное доменное имя контроллера домена в качестве значения для DNSHostName параметр, когда он продемонстрировал New-ADServiceAccount командлет. Как я понимаю, DNSHostName просто сообщает командлету, на каком контроллере домена нужно создать учетную запись. Я не думаю, что имеет значение, какой DC вы используете, эти gMSA, похоже, в любом случае немедленно реплицируются. Я указывал DNSHostName на один из моих контроллеров домена и, похоже, пока он работает.
Мне бы очень хотелось, чтобы по этому поводу была какая-то конкретная документация. В применимый справочник команд TechNet это просто тавтологическая чушь для DNSHostName параметр.
Когда вы добавляете параметр -RestrictToSingleComputer, он больше не требуется. Конечно, вы должны прочитать об этой опции, прежде чем использовать ее.
Подобно:
New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer
Я очень долго искал ответ и наконец нашел тот, который мне кажется верным.
-DNSHostName должно быть полным доменным именем того контроллера домена, который содержит главный ключ KDS - msKds-ProvRootKey.
Скорее всего, вы уже создали его - взгляните на контейнер службы распределения ключей группы в разделе конфигурации вашего леса AD.
И, вероятно, вы могли бы использовать любой DC в этом лесу, если вы задали их имена в -PrincipalsAllowedToRetrieveManagedPassword
Все вышеперечисленное представляет собой «новый» gMSA, поэтому, если вы хотите использовать вместо него старый MSA, просто забудьте об этом -DNSHostName, поскольку в этом случае оно не требуется, и просто используйте -RestrictToSingleComputer, блокируя учетную запись на каком-либо сервере.
Надеюсь, это поможет.
Мой опыт, кажется, указывает на то, что он ищет 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