英語で読む

次の方法で共有

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

  • [アーティクル]

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

注意

構成されているディレクトリ サービス アカウントに関係なく、センサー サービスは 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 によって追跡されるエンティティ属性などが含まれます。

注意

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

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

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

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

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

    注意

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

    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 などの兄弟ドメインのターゲット ドメイン名と、 apac.contoso.comなどの DSA gMSA エントリ ドメイン名を検索します。

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

    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

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

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

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

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

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

    Test-MDIDSA -Identity "mdiSvc01" -Detailed

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

    次の手順