Windows Server 2025 では、委任された管理サービス アカウント (dMSA) と呼ばれる新しいアカウントの種類が導入されました。これにより、従来のサービス アカウントから、マネージド キーと完全ランダム化キーを持つマシン アカウントに移行して、元のサービス アカウント パスワードを無効化できます。 dMSAの認証はデバイスIDにリンクされ、Active Directory (AD) にマップされた指定されたマシン ID のみがアカウントにアクセスできます。 dMSAを使用することで、従来のサービスアカウントでよくある問題である、漏洩したアカウント（ケルベロースティング）を使用した認証情報のハーベスティングを防ぐことができます。
dMSAとgMSAの比較
dMSAとgMSAは、Windows Serverでサービスとアプリケーションを実行するために使用される 2 種類の管理対象サービスアカウントです。 dMSAは管理者によって管理され、特定のサーバ上でサービスまたはアプリケーションを実行するために使用されます。 gMSAはADによって管理され、複数のサーバでサービスまたはアプリケーションを実行するために使用されます。 どちらも、セキュリティの向上とパスワード管理のシンプル化を実現します。 dMSAは以下の点で異なります。
- Utilizing gMSA concepts to limit scope of usage using Credential Guard (CG) to bind machine authentication.
- CGを使用すると、パスワードを自動的に回転させ、すべてのサービスアカウントチケットをバインドすることで、dMSAのセキュリティを強化できます。 その後、レガシーアカウントは無効にされ、セキュリティがさらに向上します。
- gMSA はマシンによって生成され、自動ローテーションされたパスワードで保護されますが、パスワードは引き続きマシンにバインドされず、盗まれる可能性があります。
dMSAの機能
dMSAを使用すると、スタンドアロンアカウントとして作成したり、既存の標準サービスアカウントを置き換えることができます。 dMSA が既存のアカウントに取って代わると、パスワードを使用した既存のアカウントへの認証はブロックされます。 要求はローカルセキュリティ管理局（LSA）にリダイレクトされ、dMSAを使用して認証されます。dMSA は、前のアカウントがADでアクセスできるすべてのものにアクセスできます。
移行中、dMSAはサービス アカウントが使用されるデバイスを自動的に学習し、その後、既存のすべてのサービス アカウントから移動するために使用します。
dMSAは、ドメイン コントローラ（DC）によって保持されるランダム化された秘密（機械アカウントのクレデンシャルから取得）を使用してチケットを暗号化します。 この秘密は、CGを有効にすることでさらに保護できます。 dMSAによって使用される秘密は、gMSAのようなエポックで定期的に更新されますが、重要な違いは、DC 以外ではdMSAの秘密を取得または検出できないことです。
dMSAの移行フロー
dMSAの移行フロー プロセスの簡単な概念には、次の手順が含まれます。
- CGポリシーは、機械IDを保護するように設定できます。
- 管理者がサービスアカウントの移行を開始し、完了します。
- サービスアカウントによって、チケット認可サーバ（TGT）がリフレッシュされます。
- サービスアカウントは、原則を許可するために機械IDを追加します。
- 元のサービスアカウントが無効になります。
dMSAを移行するときは、次の点に注意してください。
- 管理対象サービスアカウントまたはgMSAからdMSAに移行することはできません。
- セキュリティ記述子（SD）を変更してからdMSAの移行を完了するまでに、少なくとも2つのチケットのライフタイム（14日相当）を待ちます。 Keeping a service in the start state for four ticket lifetimes (28 days) is recommended. DCがパーティション化されているか、またはオンボード中にレプリケーションが中断された場合は、移行を遅らせます。
- Pay attention to sites where replication delays are longer than the default ticket renewal time of 10 hours. The groupMSAMembership attribute is checked and updated at every ticket renewal, and every time the original service account logs on during the "start migration" state, which adds the machine account to the groupMSAMembership of the dMSA.
- たとえば、2つのサイトが同じサービスアカウントを使用し、各レプリケーションサイクルはチケットのライフタイムごとに10時間以上かかります。 このシナリオでは、最初のレプリケーションサイクル中にグループメンバーシップが失われます。
- 移行するには、SDのクエリと変更に読み書きドメインコントローラ（RWDC）にアクセスする必要があります。
- 以前のサービスアカウントが使用していた場合、移行が完了すると、制約のない委任は動作を停止します。 CGで保護されたdMSAを使用している場合、制約のない委任は動作を停止します。 詳細については、クレデンシャルガードを使用する際の考慮事項と既知の問題を参照してください。
Warning
dMSAに移行する場合は、サービスアカウントを使用しているすべての機械をdMSAをサポートするために更新する必要があります。 これが当てはまらない場合、移行中にアカウントが無効になると、dMSA をサポートしていないマシンは既存のサービス アカウントでの認証に失敗します。
dMSAのアカウントアトリビュート
ここでは、ADスキーマでdMSAのアトリビュートがどのように変更されるかについて説明します。 これらのアトリビュートは、Active DirectoryユーザーとコンピュータスナップインまたはDCでADSI Editを実行して表示できます。
Note
アカウントに設定された数値属性は、次を示します。
- 1 - Account migration has begun.
- 2 - Account migration has completed.
Start-ADServiceAccountMigrationを実行すると、次のように変更されます。
- The service account is granted Generic Read to all properties on the dMSA
- The service account is granted Write property to msDS-groupMSAMembership
- msDS-DelegatedMSAState is changed to 1
- msDS-ManagedAccountPrecededByLink is set to the service account
- msDS-SupersededAccountState is changed to 1
- msDS-SupersededManagedServiceAccountLink is set to the dMSA
Complete-ADServiceAccountMigrationを実行すると、次のように変更されます。
- The service account is removed from Generic Read to all properties on the dMSA
- The service account is removed from Write property on the msDS-GroupMSAMembership attribute
- msDS-DelegatedMSAState is set to 2
- サービス アカウントから dMSA アカウントにサービス プリンシパル名 (SPN) がコピーされる
- msDS-AllowedToDelegateTo is copied over if applicable
- msDS-AllowedToActOnBehalfOfOtherIdentity the security descriptor is copied over if applicable
- The assigned AuthN policy, msDS-AssignedAuthnPolicy, of the service account are copied over
- サービスアカウントがメンバーであったすべてのAuthNポリシーシロにdMSAが追加される
- 信頼できる「委任認証」ユーザーアカウント制御（UAC）ビットは、サービスアカウントに設定されている場合にコピーされる
- msDS-SupersededServiceAccountState is set to 2
- サービスアカウントは、UAC無効ビットを使用して無効にされる
- SPN がアカウントから削除される
dMSA realms
領域は、認証境界を定義する論理グループとして機能し、ドメイン間またはフォレスト間で異なるバージョンの AD を統合するときによく使用されます。 領域は、一部のドメインが dMSA のすべての機能を完全にサポートしていない可能性があるドメイン混在環境では特に重要です。 領域を指定することで、dMSA はドメイン間の適切な通信と認証フローを確保できます。
管理者は領域を使用して、dMSA アカウントの認証とアクセスが可能なドメインまたはディレクトリ コンポーネントを指定できます。 これにより、dMSA 機能をネイティブにサポートしていない可能性のある古い子ドメインでも、セキュリティ境界を維持したままアカウントと対話できるようになります。 領域は、混合環境でのシームレスな移行と機能の共存を容易にし、ドメイン間の互換性を確保しながら、有効にすると強力なセキュリティを維持します。
たとえば、Windows Server 2025 で実行されている corp.contoso.com というプライマリ ドメインと、Windows Server 2022 で実行されている legacy.corp.contoso.com という古い子ドメインがある場合、領域を legacy.corp.contoso.com として指定できます。
環境のこのグループ ポリシー設定を編集するには、次のパスに移動します。
コンピューターの構成\管理用テンプレート\システム\Kerberos\委任された管理サービス アカウントのログオンを有効にする
