Документация содержит пример:
New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true
Этот параметр является обязательным. Какова цель a DNSHostName
и как мне решить, на что его установить?
Документация содержит пример:
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, блокируя учетную запись на каком-либо сервере.
Надеюсь, это поможет.
Цитирую ответ 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