Документація містить приклад:
New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true
Цей параметр обов'язковий. Що саме є ціллю DNSHostNameі як я повинен вирішити, для чого його встановити?
Документація містить приклад:
New-ADServiceAccount service1 -DNSHostName service1.contoso.com -Enabled $true
Цей параметр обов'язковий. Що саме є ціллю DNSHostNameі як я повинен вирішити, для чого його встановити?
Відповіді:
Попрацювавши деякий час з цими обліковими записами, я думаю, що я з’ясував причину:
Вони є деякими підмножинами або, можливо, похідними від облікових записів машинного типу. Тому вони успадковують цю властивість від них, і оскільки вона потрібна для типу машини, вона також потрібна для gMSA.
Ви можете перевірити, чи обидва типи тісно збігаються в наборах атрибутів. Крім того, у всій документації TechNet вони просто дають просте унікальне значення цього атрибуту , подібно тому, як це має обліковий запис машини.gmsa-name.contoso.com
Не впевнений, чому вони просто не створили це, і шкодують нас від диву та набору тексту.
DNSHostName має бути назвою вашої служби. У випадку кластеру це буде ваше ім'я віртуальної інстанції.
DNSHostName пов'язаний з автоматичною реєстрацією облікового запису SPN. У комп'ютерах Active Directory Computers & 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 (і SPN) або якщо ви все в порядку, якщо вручну реєструвати SPN для вашої послуги, ви можете розмістити все, що завгодно, у DNSHostName. GMSA все ще працюватиме.
Я б не рекомендував розміщувати ваш DomainController в DNSName, як згадувалося раніше (якщо ви не плануєте використовувати GMSA для запуску послуги на контролері домену).
Я не є експертом у цьому. Однак є така кількість інформації з цієї теми, я вважав, що варто опублікувати те, що я знаю
Тренер курсу 70-411, який я взяв, використовував FQDN контролера домену як значення для DNSHostNameпараметра, коли він демонстрував New-ADServiceAccountкомандлет. Як я розумію, він DNSHostNameпросто каже командлету, на якому контролері домену створити обліковий запис. Я не думаю, що не важливо, який саме DC ви використовуєте, ці gMSA, схоже, негайно повторюються. Я вказував DNSHostNameна один із своїх постійних клієнтів, і, здається, працює до цих пір.
Я дійсно вважаю, що на це є якась конкретна документація. Застосовувана посилання на команду TechNet - це просто тавтологічна нісенітниця для DNSHostNameпараметра.
Коли ви додаєте параметр -RestrictToSingleComputer, він більше не потрібен. Звичайно, ви повинні прочитати про цей варіант, перш ніж використовувати його.
Подобається:
New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer
Я дуже довго шукав відповідь і нарешті знайшов одну, яка мені звучить правдиво.
-DNSHostName має бути FQDN того постійного струму, який містить головний ключ KDS - msKds-ProvRootKey.
Швидше за все, ви вже створили це - подивіться на контейнер служби розподілу групових ключів у розділі Конфігурація вашого лісу AD.
І, ймовірно, ви могли використовувати будь-який DC у цьому лісі до тих пір, поки ви встановите їх імена в -PrincipalsAllowedToRetrieveManagedPassword
Все вищевикладене являє собою "новий" gMSA, тому якщо ви хочете використовувати старий MSA замість цього, просто забудьте про це -DNSHostName, оскільки його тоді не потрібно, і просто використовуйте -RestrictToSingleComputer, блокуючи обліковий запис на якомусь сервері.
Сподіваюся, що це допомагає.
Цитуючи відповідь Пройда 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