管理されたサービスアカウントのDNSホスト名を設定しますか？

ドキュメントには、例が含まれています。

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

このパラメーターは必須です。の正確な目的はDNSHostName何ですか？また、何に設定するかをどのように決定すればよいですか？

これらのアカウントでしばらく働いた後、私は理由を見つけたと思います：

それらは一部のサブセットであるか、マシンタイプアカウントの派生物である可能性があります。したがって、それらはこのプロパティを継承します。また、マシンタイプに必要なため、gMSAにも必要です。

属性セットで両方のタイプが厳密に一致することを確認できます。また、TechNetの すべてのドキュメントでgmsa-name.contoso.comは、マシンアカウントが持っているように、この属性に単純な一意の値を指定しています。

なぜ自動生成されなかったのかわからず、不思議とタイピングをtypingしみません。

DNSHostNameはサービスの名前である必要があります。クラスターの場合、これは仮想インスタンス名になります。

DNSHostNameは、アカウントのSPN自動登録に関連しています。Active Directoryでは、コンピューターとGMSAに「ServicePrincipalNameへの検証済み書き込みを許可する」権限があります。つまり、コンピューターは自分の名前を含むSPNのみを登録できます。例：Webserver1という名前のコンピューター（DNS：Webserver1.mydomain.net）は、http：/Webserver1.mydomain.net：443を自動登録できますが、http：/Webserver55.mydomain.net：443を登録できません

したがって、GMSAのDNSHostNameは、サービスに登録するSPNを反映する必要があります。

SQLクラスターには、Host1とhost2の2つのホストがあります。clusterName：Clu1およびVirtual SQL Instance：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は引き続き機能します。

前述のようにDomainNameをDNSNameに入れることはお勧めしません（GMSAを使用してドメインコントローラーでサービスを実行する予定がない場合）。

私はこれに関する専門家ではありません。ただし、このトピックに関する情報が不足しているため、自分が知っていることを投稿する価値があると思いました

私が受講した70-411コースのトレーナーはDNSHostName、New-ADServiceAccountコマンドレットのデモを行う際に、パラメーターの値としてドメインコントローラーのFQDNを使用しました。私が理解しているDNSHostNameように、アカウントを作成するドメインコントローラをコマンドレットに伝えるだけです。どのDCを使用するかは問題ではないと思います。これらのgMSAはとにかくすぐに複製されるようです。私はDNSHostName自分のDCの1つを指していましたが、今のところ機能しているようです。

これについては、具体的なドキュメントがあったほうがいいと思います。該当TechNetのコマンドリファレンスには、のためだけトートロジーナンセンスであるDNSHostNameパラメータ。

パラメーター-RestrictToSingleComputerを追加すると、それはもう必要ありません。もちろん、使用する前にそのオプションについて読む必要があります。

お気に入り：

New-ADServiceAccount service1 -Enabled $true -RestrictToSingleComputer

私は非常に長い間答えを探していましたが、ようやく自分に合った答えを見つけました。

-DNSHostNameは、KDSマスターキー-msKds-ProvRootKeyを保持するDCのFQDNである必要があります。

ほとんどの場合、既に作成済みです。ADフォレストの構成パーティションにあるグループキー配布サービスコンテナーを見てください。

-PrincipalsAllowedToRetrieveManagedPasswordで名前を設定する限り、おそらくそのフォレストで任意のDCを使用できます。

上記はすべて「新しい」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？forum = winserver8gen

私の経験は、DCを探していることを示しているようです。メンバーサーバーでテストを実行し、-DNSHostNameの入力を求められました。DCから同じテストを実行しましたが、プロンプトが表示されませんでした。

2018年1月17日にProMSがgMSAにDNSホスト名が必要な理由の答えを引用します。 （以前に引用してくれた@Danielに感謝します）。

dNSHostNameAD-Computerオブジェクトの場合と同じように設定することをお勧めしsAMAccountNameます（+およびドメインサフィックス）

…なぜなら：

• msDS-GroupManagedServiceAccountAD-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