次の方法で共有

Microsoft Defender for Identity のディレクトリ サービス アカウント

  • [アーティクル]

この記事では、Microsoft Defender for Identity がディレクトリ サービス アカウント (DSA) を使用する方法について説明します。

Note

構成されているディレクトリ サービス アカウントに関係なく、センサー サービスは LocalService ID で動作し、アップデーター サービスは LocalSystem ID で動作します。

DSA は一部のシナリオで省略可能ですが、完全なセキュリティ カバレッジのためにも Defender for Identity の DSA を構成することをお勧めします。

たとえば、DSA を構成すると、DSA は起動時にドメイン コントローラーに接続するために使用されます。 また、DSA は、ドメイン コントローラーに対して、ネットワーク トラフィック、監視対象イベント、監視対象 ETW アクティビティに表示されるエンティティに関するデータをクエリするために使用することもできます。

DSA は、次の機能に必要です。

  • AD FS/AD CS サーバーにインストールされているセンサーを使用するとき。

  • デバイスへの SAM-R 呼び出しによって、ネットワーク トラフィック、イベント、ETW アクティビティに表示されるデバイスからローカル管理者グループのメンバー リストを要求する。 収集されたデータは、潜在的なラテラル ムーブメント パスを計算するために使用されます。

  • DeletedObjects コンテナーにアクセスして、削除されたユーザーとコンピューターに関する情報を収集する。

  • ドメインと信頼のマッピング。これはセンサーの起動時に発生し、10 分ごとに繰り返されます。

  • 他のドメイン内のエンティティからのアクティビティを検出する場合、LDAP 経由で他のドメインに詳細をクエリする。

1 つの DSA を使用する場合、DSA にはフォレスト内のすべてのドメインに対する読み取りアクセス許可が必要です。 信頼されていないマルチフォレスト環境では、フォレストごとに DSA アカウントが必要です。

各ドメインに 1 つのセンサーはドメイン シンクロナイザーとして設定され、ドメイン内のエンティティに対する変更を追跡します。 たとえば、変更点には、作成されたオブジェクト、Defender for Identity によって追跡されるエンティティ属性などが含まれます。

Note

デフォルトでは、Defender for Identity で最大 30 個の資格情報がサポートされます。 さらに多くの資格情報を追加するには、Defender for Identity のサポートまでお問い合わせください。

サポートされている DSA アカウント オプション

Defender for Identity では、次の DSA オプションがサポートされています。

オプション 説明 構成
グループ管理サービス アカウント gMSA (推奨) より安全なデプロイとパスワード管理を提供します。 Active Directory は、コンピューター アカウントのパスワードと同様に、アカウントのパスワードの作成とローテーションを管理し、アカウントのパスワードを変更する頻度を制御できます。 詳細については、「gMSA を使用して Defender for Identity のディレクトリ サービス アカウントを設定する」を参照してください。
通常のユーザー アカウント 使い始めは簡単で、信頼されたフォレスト間の読み取りアクセス許可を設定するのが簡単ですが、パスワード管理のための余分なオーバーヘッドが必要になります。

通常のユーザー アカウントは、パスワードを作成して管理する必要があるため、安全性が低く、パスワードの有効期限が切れ、ユーザーと DSA の両方で更新されない場合にダウンタイムにつながる可能性があります。		 DeletedObjects コンテナーへのアクセス許可を含め、すべてのオブジェクトに対する読み取りアクセス許可を持つ DSA として使用する新しいアカウントを Active Directory に作成します。 詳細については、「必要な DSA アクセス許可を付与する」を参照してください。
ローカル サービス アカウント ローカル サービス アカウントはそのまま使用され、DSA が構成されていない場合に既定で使用されます。
注:
  • このシナリオでは、潜在的なラテラル ムーブメント パスに対する SAM-R クエリはサポートされていません。
  • LDAP クエリは、センサーがインストールされたドメイン内でのみ実行されます。 同じフォレストまたはフォレスト間の他のドメインへのクエリは失敗します。
    		•  なし

    Note

    既定では、ローカル サービス アカウントがセンサーで使用され、一部のシナリオでは DSA はオプションですが、完全なセキュリティ カバレッジのために Defender for Identity の DSA を構成することが推奨されます。

    DSA エントリの使用方法

    このセクションでは、DSA エントリの使用方法と、任意のシナリオでセンサーが DSA エントリを選択する方法について説明します。 センサーの試行は、DSA エントリの種類によって異なります。

    型 説明
    gMSA アカウント センサーは、Active Directory から gMSA アカウントのパスワードを取得し、ドメインにサインインしようとします。
    通常のユーザー アカウント センサーは、構成されたユーザー名とパスワードを使用してドメイン コントローラーへのサインインを試みます。

    次のロジックが適用されます。

    1. センサーは、ターゲット ドメインのドメイン名と完全に一致するエントリを探します。 完全一致が見つかった場合、センサーはそのエントリの資格情報を使用して認証を試みます。

    2. ドメイン名の完全一致がない場合、または認証に失敗した場合、センサーは DNS FQDN を使用して親ドメインのエントリを一覧から検索し、代わりに親エントリの資格情報を使用して認証を試みます。

    3. 親ドメインのエントリがない場合、または認証に失敗した場合、センサーは DNS FQDN を使用して兄弟ドメインのエントリを一覧から検索し、代わりに兄弟エントリの資格情報を使用して認証を試みます。

    4. 兄弟ドメインのエントリがない場合、または認証に失敗した場合、センサーは一覧をもう一度確認し、成功するまで各エントリで再認証を試みます。 DSA gMSA エントリは、標準の DSA エントリよりも優先度が高くなります。

    DSA を使用したサンプル ロジック

    このセクションでは、gMSA アカウントと通常のアカウントの両方を含む複数のアカウントがある場合に、センサーが DSA エントリを試行する方法の例を示します。

    次のロジックが適用されます。

    1. センサーは、ターゲット ドメインの DNS ドメイン名 (emea.contoso.com など) と DSA gMSA エントリ (emea.contoso.com など) との間の一致を検索します。

    2. センサーは、ターゲット ドメインの DNS ドメイン名 (emea.contoso.com など) と DSA 標準エントリ DSA (emea.contoso.com など) との間の一致を検索します。

    3. センサーは、ターゲット ドメインのルート DNS 名 (emea.contoso.com など) と DSA gMSA エントリのドメイン名 (contoso.com など) との間の一致を検索します。

    4. センサーは、ターゲット ドメインのルート DNS 名 (emea.contoso.com など) と DSA 標準エントリのドメイン名 (contoso.com など) との間の一致を検索します。

    5. センサーは、兄弟ドメインのターゲット ドメイン名 (emea.contoso.com など) と DSA gMSA エントリのドメイン名 (apac.contoso.com など) との間の一致を検索します。

    6. センサーは、兄弟ドメインのターゲット ドメイン名 (emea.contoso.com など) と DSA 標準エントリのドメイン名 (apac.contoso.com など) との間の一致を検索します。

    7. センサーは、すべての DSA gMSA エントリのラウンド ロビンを実行します。

    8. センサーは、すべての DSA 標準エントリのラウンド ロビンを実行します。

    この例で示したロジックは、以下の構成で実装されています。

    • DSA エントリ:

      • DSA1.emea.contoso.com
      • DSA2.fabrikam.com

    • センサーと最初に使用される DSA エントリ:

      ドメイン コントローラー FQDN 使用される DSA エントリ
      DC01.emea.contoso.com DSA1.emea.contoso.com
      DC02.contoso.com DSA1.emea.contoso.com
      DC03.fabrikam.com DSA2.fabrikam.com
      DC04.contoso.local ラウンド ロビン

    重要

    センサーが起動時に Active Directory ドメインに対して LDAP 経由で正常に認証できない場合、センサーは実行状態に入らず、正常性の問題が発生します。 詳細については、「Defender for Identity のヘルス問題」を参照してください。

    必要な DSA アクセス許可を付与する

    DSA には、Active Directory 内のすべてのオブジェクト (削除済みオブジェクト コンテナを含む) に対する読み取り専用のアクセス許可が必要です。

    削除済みオブジェクト コンテナーに対する読み取り専用アクセス許可により、Defender for Identity は Active Directory からのユーザーの削除を検出できます。

    gMSA アカウントを使用しているかどうかに関係なく、削除済みオブジェクト コンテナーに必要な読み取りアクセス許可を付与するには、次のコード サンプルを使用します。

    ヒント

    アクセス許可を付与する DSA がグループ管理サービス アカウント (gMSA) の場合は、まずセキュリティ グループを作成し、gMSA をメンバーとして追加し、そのグループにアクセス許可を追加する必要があります。 詳細については、「gMSA を使用して Defender for Identity のディレクトリ サービス アカウントを設定する」を参照してください。

    # Declare the identity that you want to add read access to the deleted objects container:
$Identity = 'mdiSvc01'

# If the identity is a gMSA, first to create a group and add the gMSA to it:
$groupName = 'mdiUsr01Group'
$groupDescription = 'Members of this group are allowed to read the objects in the Deleted Objects container in AD'
if(Get-ADServiceAccount -Identity $Identity -ErrorAction SilentlyContinue) {
    $groupParams = @{
        Name           = $groupName
        SamAccountName = $groupName
        DisplayName    = $groupName
        GroupCategory  = 'Security'
        GroupScope     = 'Universal'
        Description    = $groupDescription
    }
    $group = New-ADGroup @groupParams -PassThru
    Add-ADGroupMember -Identity $group -Members ('{0}$' -f $Identity)
    $Identity = $group.Name
}

# Get the deleted objects container's distinguished name:
$distinguishedName = ([adsi]'').distinguishedName.Value
$deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName

# Take ownership on the deleted objects container:
$params = @("$deletedObjectsDN", '/takeOwnership')
C:\Windows\System32\dsacls.exe $params

# Grant the 'List Contents' and 'Read Property' permissions to the user or group:
$params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
C:\Windows\System32\dsacls.exe $params
  
# To remove the permissions, uncomment the next 2 lines and run them instead of the two prior ones:
# $params = @("$deletedObjectsDN", '/R', ('{0}\{1}' -f ([adsi]'').name.Value, $Identity))
# C:\Windows\System32\dsacls.exe $params

    詳細については、「Changing permissions on a deleted object container (削除されたオブジェクト コンテナーのアクセス許可を変更する)」を参照してください。

    PowerShell を使用して DSA のアクセス許可と委任をテストする

    次の PowerShell コマンドを使用して、強力な管理者アクセス許可など、DSA に多すぎるアクセス許可がないことを確認します。

    Test-MDIDSA [-Identity] <String> [-Detailed] [<CommonParameters>]

    たとえば、mdiSvc01 アカウントのアクセス許可をチェックし、完全な詳細を指定するには、次を実行します。

    Test-MDIDSA -Identity "mdiSvc01" -Detailed

    詳細については、DefenderForIdentity PowerShell リファレンスを参照してください。

    次のステップ

    gMSA を使用して Defender for Identity のディレクトリ サービス アカウントを設定する »