DsAddSidHistory の使用
DsAddSidHistory 関数は、あるドメイン (送信元ドメイン) からセキュリティ プリンシパルのプライマリ アカウント セキュリティ識別子 (SID) を取得し、それを別のフォレスト内の別の (宛先) ドメインのセキュリティ プリンシパルの sIDHistory 属性に追加します。 ソース ドメインが Windows 2000 ネイティブ モードの場合、この関数はソース プリンシパルの sIDHistory 値も取得し、宛先プリンシパルの sIDHistory に追加します。
セキュリティ プリンシパルの sIDHistory に SID を追加することは、セキュリティに気を配る必要のある操作であり、適用可能なリソース ドメインから宛先ドメインへの信頼が存在する限り、ソース プリンシパルがアクセス可能なすべてのリソースへのアクセスを宛先プリンシパルに効果的に付与します。
ネイティブモードの Windows 2000 ドメインでは、ユーザーのログオンは、ユーザーのプライマリ アカウントの SID とグループの SID、ユーザーの sIDHistory とそのユーザーがメンバーであるグループの sIDHistory を含むアクセス トークンを作成します。 これらの以前のSID (sIDHistory 値) をユーザーのトークンに持つことで、以前の SID を含むアクセス制御リスト (ACL) で保護されたリソースへのアクセスをユーザーに許可します。
この操作により、特定の Windows 2000 展開シナリオが簡単になります。 特に、Windows NT 4.0 運用環境に既に存在するユーザーとグループに対して、新しい Windows 2000 フォレスト内のアカウントを作成するシナリオがサポートされています。 Windows NT 4.0アカウント SID を Windows 2000 アカウントの sIDHistory に置くことで、ネットワーク リソースへのアクセスは、新しい Windows 2000 アカウントにログオンするユーザーのために保持されます。
DsAddSidHistory は、Windows NT 4.0 のバックアップ ドメイン コントローラ (BDC) の リソース サーバー (またはネイティブ モードの Windows 2000 ドメインの DC とメンバー サーバー) の Windows 2000 ドメインへのメンバー サーバーとしての移行もサポートします。 この移行には、宛先の Windows 2000 ドメインで、sIDHistory に、ソース ドメインの BDC 上で定義された ローカル グループ (または Windows 2000 サーバー上の ACL で参照されるドメイン ローカル グループ) のプライマリ SID を含むドメイン ローカル グループを作成する必要があります。 sIDHistory とソース ローカル グループのすべてのメンバーを含む宛先ローカル グループを作成することで、ソース ローカル グループを参照する ACL で移行された宛先サーバー リソースへのアクセスが、すべてのメンバーに対して維持されます。
Note
DsAddSidHistory を使用するには、これらのシナリオやその他のシナリオにおける、より広範な管理およびセキュリティへの影響を理解する必要があります。 詳細については、Windows 2000 サポート ツールで Dommig.doc として提供されるホワイト ペーパー「Windows NT から Microsoft Windows 2000 への移行の計画」を参照してください。 このドキュメントは、製品 CD の \support\tools にも記載されています。
承認要件
DsAddSidHistory には、ソース ドメインと宛先ドメインの管理者特権が必要です。 具体的には、この API の呼び出し元は、宛先ドメイン管理者グループのメンバーである必要があります。 このメンバーシップのハードコーディングされたチェックが実行されます。 また、SrcDomainCreds パラメータで指定されたアカウントは、ソース ドメインの管理者グループまたはドメイン管理者グループのメンバーである必要があります。 SrcDomainCreds に NULL が渡される場合、API の呼び出し元は、ソース ドメインの管理者グループまたはドメイン管理者グループのメンバーである必要があります。
ドメインと信頼の要件
DsAddSidHistory では、このドメイン タイプのみが sIDHistory 属性をサポートするため、 宛先ドメインが Windows 2000 ネイティブ モード以降であることが必要です。 ソース ドメインは、Windows NT 4.0 または Windows 2000、混合またはネイティブ モードのいずれかです。 ソース ドメインと宛先ドメインは、同じフォレスト内に存在できません。 Windows NT 4.0 ドメイン は、定義上、フォレスト内にありません。 このフォレスト間制約により、プライマリ SID または sIDHistory 値として表示される場合でも、重複する SID が同じフォレスト内に作成されないようにします。
DsAddSidHistory は、以下の表に記載されている場合、ソース ドメインから宛先ドメインへの外部の信頼を必要とします。
| ケース | 説明 |
|---|---|
| ソース ドメイン は Windows 2000 です。 |
ソース sIDHistory 属性は、Windows 2000 ソース ドメインでのみ利用可能であり、完全性保護のためにこの信頼を必要とする LDAP を使用してのみ読み取ることができます。 |
| ソース ドメインは Windows NT 4.0 で、SrcDomainCreds は NULL です。 |
呼び出し元の資格情報を使用してソース ドメインの操作をサポートするために必要な権限借用は、この信頼に依存します。 また、権限借用では、宛先のドメイン コントローラーで "Trusted for Delegation" が既定で有効になっている必要があります。 |
しかし、ソース ドメインが Windows NT 4.0 で、SrcDomainCreds が NULL でない場合、 ソース ドメインと宛先ドメインの間に信頼は必要ありません。
ソース ドメイン コントローラーの要件
DsAddSidHistory では、ソース ドメインで操作のターゲットとして選択された ドメイン コントローラーが、Windows NT 4.0 ドメインでは PDC であること、 または Windows 2000 ドメインでは PDC Emulator であることが必要です。 ソース ドメインの監査は書き込み操作によって生成されるため、Windows NT 4.0 のソース ドメインでは PDC が必要であり、PDC のみの制限により、DsAddSidHistory 監査が 1 台のコンピューター上で確実に生成されます。 これにより、この操作の使用を監視するために、すべての DC の監査ログを確認する必要性が減ります。
Note
Windows NT 4.0 のソース ドメインでは、適切な監査サポートを確実にするために、PDC (ソース ドメインの操作対象) は Service Pack 4 (SP4) 以降を実行している必要があります。
次のレジストリ値は、REG_DWORD 値として作成し、Windows NT 4.0 と Windows 2000 の両方のソース DC のソース ドメイン コントローラーで 1 に設定する必要があります。
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Control
Lsa
TcpipClientSupport
この値を設定すると、TCP トランスポート経由の RPC 呼び出しが有効になります。 既定では、SAMRPC インターフェイスは名前付きパイプでのみリモート処理可能であるため、これは必須です。 名前付きパイプを使用すると、対話的にログオンしたユーザーがネットワーク呼び出しを行うのに適した資格情報管理システムになりますが、ユーザーが指定した資格情報を使用してネットワーク呼び出しを行うシステム プロセスに対しては柔軟性がありません。 RPC over TCP は、その目的に適しています。 この値を設定しても、システムのセキュリティが低下することはありません。 この値が作成または変更された場合、この設定を有効にするには、ソース ドメイン コントローラーを再起動する必要があります。
監査目的で、"<SrcDomainName>$$$" をソース ドメインに作成する必要があります。
監査
DsAddSidHistory 操作は、ソース ドメイン管理者と宛先ドメイン管理者の両方が、この関数が実行されたことを検知できるように監査されます。 監査は、ソース ドメインと宛先ドメインの両方で監査が必須です。 DsAddSidHistory は、各ドメインで監査モードがオンであり、成功/失敗イベントのアカウント管理監査がオンであることを確認します。 宛先ドメインでは、成功または失敗した DsAddSidHistory 操作ごとに、一意の "Add Sid History "監査イベントが生成されます。
Windows NT 4.0 システムでは、一意の "Add Sid History" 監査イベントは使用できません。 ソース ドメインに対する DsAddSidHistory の使用を明確に反映する監査イベントを生成するために、それは監査ログの一意識別子である名前を持つ特別なグループに対する操作を実行します。 <>DsAddSidHistory を呼び出す前に、ソース ドメインの NetBIOS 名に 3 つのドル記号 ($) (ASCII コード = 0x24、Unicode = U+0024) を付加した名前のローカル グループ "SrcDomainName$$" をソース ドメイン コントローラー上に作成する必要があります。 この操作のターゲットである各ソース ユーザーおよびグローバル グループは、このグループのメンバーシップに追加され、メンバーシップから削除されます。 これにより、ソース ドメインに [Add Member] と [Delete Member] の監査イベントが生成され、グループ名を参照するイベントを検索することで監視できます。
Note
Windows NT 4.0、または Windows 2000 の混合モード ソース ドメインのローカル グループに対する DsAddSidHistory 操作は、ローカル グループを別のローカル グループのメンバーにすることができず、したがって特別な "<SrcDomainName>$$$" ローカル グループに追加することができないため、監査することができません。 ソース ドメインのリソース アクセスはこの操作の影響を受けないので、この監査の欠如によってソース ドメインにセキュリティ上の問題は発生しません。 ソース ローカル グループの SID を宛先ローカル グループに追加しても、そのローカル グループによって保護されているソース リソースへのアクセス権は、追加ユーザーには付与されません。 宛先のローカル グループにメンバーを追加しても、ソース リソースへのアクセスは許可されません。 追加されたメンバーは、ソース ドメインから移行された宛先ドメイン内のサーバーへのアクセス権のみが付与され、ソース ドメインにはソース ローカル グループ SID によって保護されたリソースがある場合があります。
データ転送のセキュリティ
DsAddSidHistory では、次のセキュリティ対策が適用されます。
- Windows 2000 ワークステーションから呼び出された場合、呼び出し元の資格情報は、宛先ドメイン コントローラーへの RPC 呼び出しの認証とプライバシー保護に使用されます。 SrcDomainCreds が NULL でない場合、ワークステーションと宛先 DC の両方が、プライバシー保護のために 128 ビット暗号化をサポートしている必要があります。 128 ビット暗号化が利用できず、SrcDomainCreds が提供されている場合、宛先 DC で呼び出しを行う必要があります。
- 宛先ドメイン コントローラーは、SrcDomainCreds または呼び出し元の資格情報を使用してソース ドメイン コントローラーと通信し、ソース アカウントの SID (SAM 検索を使用する) と sIDHistory (LDAP 読み取りを使用する) の読み取りを相互に認証し、完全性を保護します。
脅威モデル
次の表では、DsAddSidHistory 呼び出しに関連する潜在的な脅威を示し、特定の脅威に関連するセキュリティ対策について述べています。
| 潜在的な脅威 | セキュリティ対策 |
|---|---|
| man-in–the-middle 攻撃 未承認のユーザーが、ソース オブジェクトのリターン コールのルックアップ SID を傍受し、ソース オブジェクトの SID を任意の SID に置き換えてターゲット オブジェクトの SIDhistory に挿入します。 |
ソース オブジェクトのルックアップ SID は、パケット完全性メッセージ保護機能を持つ、呼び出し元の管理者認証情報を使用した認証済み RPC です。 これにより、リターン呼び出しを検出しないと変更できなくなります。 宛先ドメイン コントローラーは、宛先アカウント sIDHistory に追加された SID を反映する一意の "Add SID History" 監査イベントを作成します。 |
| トロイの木馬ソース ドメイン 未承認のユーザーが、プライベート ネットワーク上に、正規のソース ドメインと同じドメイン SID と同じアカウント SID を持つ "トロイの木馬" ソース ドメインを作成します。 次に、未承認のユーザーは、ソース アカウントの SID を取得するために、宛先ドメインで DsAddSidHistory を実行しようとします。 これは、実際のソース ドメイン管理者の資格情報を必要とせず、実際のソース ドメインに監査証跡を残すことなく実行されます。 トロイの木馬のソース ドメインを作成するための未承認のユーザーの方法は次のいずれかになります。
|
権限のないユーザーが目的のソース オブジェクト SID を取得または作成する方法は数多くありますが、権限のないユーザーは、宛先ドメイン管理者グループのメンバーでない限り、それを使用してアカウントの sIDHistory を更新することはできません。 宛先ドメイン コントローラー上のドメイン管理者メンバーシップのチェックは、ターゲット DC 上でハードコードされているため、この機能を保護するアクセス制御データを変更するためにディスクを変更する方法はありません。 トロイの木馬のソース アカウントを複製しようとすると、宛先ドメインで監査されます。 この攻撃は、ドメイン管理者グループのメンバーシップを信頼度の高い個人のみに限定することで軽減されます。 |
| SID の履歴のディスク上での変更 ドメイン管理者の資格情報を持ち、宛先ドメイン内の DC に物理的にアクセスできる高度な未承認ユーザーは、ディスク上のアカウント sIDHistory 値を変更することができます。 |
この試行は、DsAddSidHistory を使用しても有効化されません。 この攻撃は、信頼性の高い管理者を除くすべてのユーザーによるドメイン コントローラーへの物理的なアクセスを防ぐことで軽減されます。 |
| 保護の削除に使用される不正なコード ディレクトリ サービス コードに物理的にアクセスできる権限のないユーザーまたは不正な管理者が、次のような不正なコードを作成する可能性があります。
|
DS コードに物理的にアクセスでき、不正なコードを作成する十分な知識を持つユーザーは、アカウントの sIDHistory 属性を恣意的に変更することができます。 DsAddSidHistory API では、このセキュリティ リスクは増大しません。 |
| 盗まれた SID に対して脆弱なリソース 不正なユーザーが、ここで説明される方法の 1 つを使用してアカウントの sIDHistory を修正することに成功し、関心のあるリソース ドメインが不正なユーザーのアカウント ドメインを信頼している場合、不正なユーザーは、SID が盗まれたアカウント ドメインに監査証跡を残すことなく、盗まれた SID のリソースに不正にアクセスすることができます。 |
リソース ドメインの管理者は、セキュリティの観点から適切な信頼関係のみを設定することで、リソースを保護します。 DsAddSidHistory の使用は、信頼されたターゲット ドメインのドメイン管理者グループのメンバーであって、その責任範囲内で既に広範な権限を持っている者に制限されます。 |
| 不正なターゲット ドメイン 未承認のユーザーが、sIDHistory がソース ドメインから盗まれた SID を含むアカウントで Windows 2000 ドメインを作成します。 未承認のユーザーは、このアカウントを使用してリソースへの不正アクセスを行います。 |
未承認のユーザーは、DsAddSidHistory を使用するために、ソース ドメインの管理者の資格情報を必要とし、ソース ドメイン コントローラー上に監査証跡を残します。 不正なターゲット ドメインは、不正なドメインを信頼する他のドメインでのみ不正なアクセスを獲得し、それらのリソース ドメインでは管理者権限が必要となります。 |
運用上の制約
このセクションでは、DsAddSidHistory 関数を使用する際の運用上の制約について説明します。
SrcPrincipal の SID は、プライマリ アカウントの SID として、またはアカウントの sIDHistory として、宛先フォレストにまだ存在してはなりません。 例外は、同一の SID を含む DsAddSidHistory に SID を追加しようとしても、sIDHistory がエラーを生成しないことです。 この動作により、DsAddSidHistory を同一の入力で複数回実行し、成功と一貫した最終状態を得ることができ、ツール開発者が使いやすくなります。
Note
グローバル カタログのレプリケーション待機時間は、重複した SID が作成される可能性のある期間が提供される可能性があります。 ただし、重複した SID は管理者が簡単に削除できます。
SrcPrincipal と DstPrincipal は次の種類のいずれかである必要があります。
User
次を含むセキュリティが有効なグループ
- ローカル グループ グローバル グループ ドメイン ローカル グループ (Windows 2000 ネイティブ モードのみ) ユニバーサル グループ (Windows 2000 ネイティブ モードのみ)
SrcPrincipal と DstPrincipal のオブジェクトの種類が一致する必要があります。
- SrcPrincipal がユーザーの場合、DstPrincipal もユーザーである必要があります。
- SrcPrincipal がローカルまたはドメイン ローカル グループだった場合、DstPrincipal はドメイン ローカル グループである必要があります。
- SrcPrincipal がグローバルまたはユニバーサル グループの場合、DstPrincipal はグローバルまたはユニバーサル グループである必要があります。
SrcPrincipal と DstPrincipal を次のいずれかの種類にすることはできません (このような場合、DsAddSidHistory はエラーで失敗します)
コンピューター (ワークステーションまたはドメイン コントローラー)
ドメイン間の信頼
一時的な重複アカウント (LANman のレガシである、実質的に未使用の機能)
既知の SID を持つアカウント。 既知の SID はすべてのドメインで同一です。したがって、sIDHistory に追加すると、Windows 2000 フォレストの SID 一意性の要件に違反することになります。 既知の SID を持つアカウントには、次のローカル グループが含まれます。
- Account operators Administrators Backup operators Guests Print operators Replicator Server operators Users
SrcPrincipal が既知の相対識別子 (RID) とドメイン固有のプレフィックス (Domain Administrators、Domain Users、Domain Computers) を持つ場合、DstPrincipal DstPrincipal も、DsAddSidHistory が成功するためには同じ既知の RID を持っている必要があります。 既知の RID を持つアカウントには、次のユーザーとグローバル グループが含まれます。
- Administrator
- Guest
- Domain administrators
- Domain guests
- Domain users
レジストリ値の設定
次の手順では、TcpipClientSupport レジストリ値を設定する方法を説明します。
TcpipClientSupport レジストリ値の設定
ソース ドメイン コントローラー上に REG_DWORD 値として以下のレジストリ値を作成し、その値を 1 に設定します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TcpipClientSupport
次に、ソース ドメイン コントローラーを再起動します。 このレジストリ値により、SAM は TCP/IP でリッスンします。 この値がソース ドメイン コントローラーに設定されていない場合、DsAddSidHistory は失敗します。
ユーザー/グループ管理イベントの監査の有効化
次の手順では、Windows 2000 または Windows Server 2003 のソースまたは宛先ドメインで、 ユーザー/グループ管理イベントの監査を有効にする方法を示しています。
Windows 2000 または Windows Server 2003 のソースまたは宛先ドメインで、ユーザー/グループ管理イベントの監査を有効にするには
- Active Directory ユーザーとコンピューター MMC スナップインで、宛先ドメインの Domain Controllers を選択します。
- [Domain Controllers] を右クリックし、[プロパティ] を選択します。
- [Group Policy] タブをクリックします。
- [Default Domain Controllers Policy] を選択し、[編集] をクリックします。
- Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy で、[アカウント管理の監査] をダブルクリックします。
- アカウント管理の監査 ウィンドウで、[成功] と [失敗] の両方の監査を選択します。 ポリシーの更新は、再起動後または更新後に有効になります。
- グループ ポリシー MMC スナップインで有効な監査ポリシーを表示して、監査が有効になっていることを確認します。
次の手順では、Windows NT 4.0 ドメイン でユーザー/グループ管理イベントの監査を有効にする方法を示します。
Windows NT 4.0 ドメインでユーザー/グループ管理イベントの監査を有効にするには
- ドメインのユーザー マネージャーで、[ポリシー] メニューをクリックし、[監査] を選択します。
- [これらのイベントの監査] を選択します。
- ユーザーとグループの管理では、[成功と失敗] をチェックします。
次の手順は、Windows NT 4.0、Windows 2000、または Windows Server 2003 ソース ドメインで、 ユーザー/グループ管理イベントの監査を有効にする方法を示します。
Windows NT 4.0、Windows 2000、または Windows Server 2003 ソース ドメインのユーザー/グループ管理イベントの監査を有効にするには
- ドメインのユーザー マネージャーで、[ユーザー] メニューをクリックし、[新しいローカル グループ] を選択します。
- ソース ドメインの NetBIOS 名に 3 つのドル記号 ($) を付加したグループ名 (例: FABRIKAM$$) を入力します。 説明フィールドは、このグループが DsAddSidHistory または複製操作の使用を監査するために使用されることを示す必要があります。 グループにメンバーがいないことを確認してください。 OK をクリックします。
DsAddSidHistory 操作は、ソースおよび宛先の監査がここで示されているように有効になっていない場合、失敗します。
必要に応じて信頼を設定する
次のいずれかが当てはまる場合、ソース ドメインから宛先ドメインへの信頼を確立する必要があります (これは別のフォレストで発生する必要があります)
- ソース ドメインは Windows Server 2003 です。
- ソース ドメインは Windows NT 4.0 で、SrcDomainCreds は NULL です。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示