委任管理サービスアカウントの概要

  • [アーティクル]

重要

Windows Server Insider ビルドはプレビュー段階にあります。 この情報はプレリリース製品に関連するものであり、リリース前に大幅に変更される可能性があります。 ここに記載された情報について、Microsoft は明示または黙示を問わずいかなる保証をするものでもありません。

Windows Server Insiders Previewでは、委任されたマネージドサービスアカウント（dMSA）として知られる新しいアカウントタイプが導入され、従来のサービスアカウントから、管理され完全にランダム化されたキーを持つ機械アカウントへの移行が可能になります。 dMSAの認証はデバイスIDにリンクされ、ADにマップされた指定された機械IDのみがアカウントにアクセスできます。 dMSAを使用することで、従来のサービスアカウントでよくある問題である、漏洩したアカウント（ケルベロースティング）を使用した認証情報のハーベスティングを防ぐことができます。

dMSAとgMSAの比較

dMSAとgMSAは、Windows Serverでサービスとアプリケーションを実行するために使用される 2 種類の管理対象サービスアカウントです。 dMSAは管理者によって管理され、特定のサーバ上でサービスまたはアプリケーションを実行するために使用されます。 gMSAはADによって管理され、複数のサーバでサービスまたはアプリケーションを実行するために使用されます。 どちらも、セキュリティの向上とパスワード管理のシンプル化を実現します。 dMSAは以下の点で異なります。

  • クレデンシャルガード（CG）を使って機械認証をバインドし、利用範囲を制限するためにgMSAの概念を利用します。
  • CGを使用すると、パスワードを自動的に回転させ、すべてのサービスアカウントチケットをバインドすることで、dMSAのセキュリティを強化できます。 その後、レガシーアカウントは無効にされ、セキュリティがさらに向上します。
  • gMSAは機械生成および自動回転パスワードで保護されますが、パスワードは機械バインドされておらず、盗難に遭う可能性があります。

dMSAの機能

dMSAを使用すると、スタンドアロンアカウントとして作成したり、既存の標準サービスアカウントを置き換えることができます。 dMSAが既存のアカウントに取って代わると、パスワードを使用した既存のアカウントへの認証はブロックされます。 要求はローカルセキュリティ管理局（LSA）にリダイレクトされ、dMSAを使用して認証されます。dMSA は、前のアカウントがADでアクセスできるすべてのものにアクセスできます。

移行中、dMSAはサービス アカウントが使用されるデバイスを自動的に学習し、その後、既存のすべてのサービス アカウントから移動するために使用します。

dMSAは、ドメイン コントローラ（DC）によって保持されるランダム化された秘密（機械アカウントのクレデンシャルから取得）を使用してチケットを暗号化します。 この秘密は、CGを有効にすることでさらに保護できます。 dMSAによって使用される秘密は、gMSAのようなエポックで定期的に更新されますが、重要な違いは、DC 以外ではdMSAの秘密を取得または検出できないことです。

dMSAの移行フロー

dMSAの移行フロー プロセスの簡単な概念には、次の手順が含まれます。

  1. CGポリシーは、機械IDを保護するように設定できます。
  2. 管理者がサービスアカウントの移行を開始し、完了します。
  3. サービスアカウントによって、チケット認可サーバ（TGT）がリフレッシュされます。
  4. サービスアカウントは、原則を許可するために機械IDを追加します。
  5. 元のサービスアカウントが無効になります。

dMSAを移行するときは、次の点に注意してください。

  • 管理対象サービスアカウントまたはgMSAからdMSAに移行することはできません。
  • セキュリティ記述子（SD）を変更してからdMSAの移行を完了するまでに、少なくとも2つのチケットのライフタイム（14日相当）を待ちます。 サービスを開始状態にして、チケットの有効期間（28 日間）を4回維持することをお勧めします。 DCがパーティション化されているか、またはオンボード中にレプリケーションが中断された場合は、移行を遅らせます。
  • レプリケーション遅延がデフォルトのチケット更新時間である10時間よりも長いサイトに注意してください。 groupMSAMembershipアトリビュートは、チケット更新のたびにチェックされ、更新されます。また、「移行開始」状態中に元のサービスアカウントがログオンするたびに、groupMSAMembershipに機械アカウントが追加されます。
    • たとえば、2つのサイトが同じサービスアカウントを使用し、各レプリケーションサイクルはチケットのライフタイムごとに10時間以上かかります。 このシナリオでは、最初のレプリケーションサイクル中にグループメンバーシップが失われます。
  • 移行するには、SDのクエリと変更に読み書きドメインコントローラ（RWDC）にアクセスする必要があります。
  • 以前のサービスアカウントが使用していた場合、移行が完了すると、制約のない委任は動作を停止します。 CGで保護されたdMSAを使用している場合、制約のない委任は動作を停止します。 詳細については、クレデンシャルガードを使用する際の考慮事項と既知の問題を参照してください。

警告

dMSAに移行する場合は、サービスアカウントを使用しているすべての機械をdMSAをサポートするために更新する必要があります。 これが当てはまらない場合、移行中にアカウントが無効になると、dMSAをサポートしていない機械は既存のサービスアカウントでの認証に失敗します。

dMSAのアカウントアトリビュート

ここでは、ADスキーマでdMSAのアトリビュートがどのように変更されるかについて説明します。 これらのアトリビュートは、Active DirectoryユーザーとコンピュータスナップインまたはDCでADSI Editを実行して表示できます。

Note

アカウントに設定された数値アトリビュートは、次のことを示します。

  • 1 - アカウントの移行が開始されました。
  • 2 - アカウントの移行が完了しました。

Start-ADServiceAccountMigrationを実行すると、次のように変更されます。

  • サービスアカウントは、dMSA上のすべてのプロパティに「一般的な読み取り」が付与される
  • サービスアカウントはmsDS-groupMSAMembershipに「書き込み」プロパティが付与されている
  • msDS-DelegatedMSAStateが1に変更される
  • msDS-ManagedAccountPrecededByLinkがサービスアカウントに設定される
  • msDS-SupersededAccountStateが1に変更される
  • msDS-SupersededManagedServiceAccountLinkがdMSAに設定される

Complete-ADServiceAccountMigrationを実行すると、次のように変更されます。

  • サービスアカウントが、dMSA上のすべてのプロパティの「一般的な読み取り」から削除される
  • サービスアカウントがmsDS-GroupMSAMembership属性の「書き込み」プロパティから削除された
  • msDS-DelegatedMSAStateが2に設定される
  • サービス プリンシパル名（SPN）がサービスアカウントからdMSAアカウントにコピーされる
  • 該当する場合、msDS-AllowedToDelegateToがコピーされる
  • 該当する場合、msDS-AllowedToActOnBehalfOfOtherIdentityのセキュリティ記述子がコピーされる
  • サービスアカウントのmsDS-AssignedAuthnPolicyに割り当てられたAuthNポリシーがコピーされる
  • サービスアカウントがメンバーであったすべてのAuthNポリシーシロにdMSAが追加される
  • 信頼できる「委任認証」ユーザーアカウント制御（UAC）ビットは、サービスアカウントに設定されている場合にコピーされる
  • msDS-SupersededServiceAccountStateが2に設定される
  • サービスアカウントは、UAC無効ビットを使用して無効にされる
  • SPNがアカウントから削除される

関連項目

委任管理サービスアカウントの設定