DirSync コントロールを使用した変更のポーリング
Active Directory ディレクトリ同期 (DirSync) コントロールは、アプリケーションが以前の状態以降に変更されたオブジェクトのディレクトリ パーティションを検索できるようにする LDAP サーバー拡張機能です。
IDirectorySearch の使用時にADS_Standard EditionARCHPREF_DIRSYNC検索設定を指定して、ADSI を介して DirSync コントロールを使用します。 詳細とコード例については、「ADS_Standard EditionARCHPREF_DIRSYNCを使用したコード例」を参照してください。 LDAP API を使用して DirSync 検索を実行することもできます。 以下では ADSI の実装について説明します。そのほとんどは、このトピックの最後で説明する場合を除き、LDAP を直接使用する場合にも当てはまります。
DirSync 検索を実行すると、以前の DirSync 検索時のディレクトリの状態を識別するプロバイダー固有のデータ要素 (Cookie) を渡します。 最初の検索では、null Cookie を渡すと、フィルターに一致するすべてのオブジェクトが返されます。 この検索では、有効な Cookie も返されます。 Active Directory サーバーと同期しているのと同じストレージに Cookie を格納します。 以降の検索では、ストレージから Cookie を取得し、検索要求と共に渡します。 検索結果には、Cookie によって識別された以前の状態以降に変更されたオブジェクトと属性のみが含まれるようになりました。 検索では、次の検索用に格納する新しい Cookie も返されます。
次の表に、クライアント検索要求で指定できる検索パラメーターを示します。
| パラメーター | 説明 |
|---|---|
| 検索のベース | DirSync 検索のベースはディレクトリ パーティションのルートである必要があります。ディレクトリ パーティションのルートは、doメイン パーティション、構成パーティション、またはスキーマ パーティションのいずれかになります。 |
| 範囲 | DirSync 検索のスコープは、パーティションのサブツリー全体ADS_SCOPE_SUBTREnterprise Editionする必要があります。 doメイン パーティションを検索する場合、サブツリーには構成パーティションとスキーマ パーティションのヘッドは含まれますが、内容は含まれません。 より小さいスコープの変更をポーリングするには、DirSync の代わりに USNChanged 手法を使用します。 |
| Assert | 任意の有効な検索フィルターを指定できます。 null Cookie を使用した最初の検索では、フィルターに一致するすべてのオブジェクトが結果に含まれます。 有効な Cookie を使用した後続の検索の場合、検索結果には、フィルターに一致し、Cookie によって示された状態以降に変更されたオブジェクトのデータのみが含まれます。 検索フィルターの詳細については、「クエリ フィルターの作成」を参照してください。 |
| 属性 | 変更が発生したときに返される属性の一覧を指定できます。 オブジェクトごとに、最初の結果には、オブジェクトに設定されたすべての要求された属性が含まれます。 後続の検索結果には、変更された指定した属性のみが含まれます。 変更されていない属性は検索結果に含まれません。 ADSI 実装では、検索結果には常に各オブジェクトの objectGUID と instanceType が 含まれます。 また、指定した属性リストは追加のフィルターとして機能します。最初の検索結果には、指定した属性の少なくとも 1 つが設定されているオブジェクトのみが含まれます。後続の検索には、1 つ以上の属性が変更されたオブジェクトのみが含まれます (値の追加または削除)。 |
また、次の点に注意してください。
増分検索の場合、ベスト プラクティスは、前の検索で使用したのと同じ doメイン コントローラー (DC) 、つまり Cookie を生成した DC にバインドする方法です。 同じ DC が使用できない場合は、それが使用できるようになるまで待つか、新しい DC にバインドして完全同期を実行します。 セカンダリ ストレージに DC の DNS 名を Cookie と共に格納します。
1 つの DC によって生成された Cookie を、同じディレクトリ パーティションのレプリカをホストする別の DC に渡すことができます。 ある DC の Cookie を別の DC で使用することで、クライアントが変更を見逃す可能性はありません。 ただし、新しい DC からの検索結果に、古い DC によって報告された変更が含まれる可能性があります。場合によっては、完全同期と同様に、新しい DC はすべてのオブジェクトと属性を返す場合があります。 クライアントは、特定の DirSync 呼び出しで報告された検索結果とデータベースの整合性を保つ必要があります。つまり、すべての増分結果を最新の状態であるかのように処理します。 増分同期の繰り返しは一貫性に収束するため、前に変更を確認したか、以前の状態に戻る場合でも関係ありません。
また、他の DC が元の DC から返された Cookie を拒否する可能性もあります。 この検索では、"0000203D: LdapErr: DSID-xxxxxxxx, comment: Error processing control, data 0" のような LDAP エラーがサーバーで生成され、クライアント アプリケーションで "System.DirectoryServices.Protocols.DirectoryOperationException: プロトコル エラーが発生しました" などのエラーが生成される可能性があります。これは、たとえば、Cookie が古く、別のバージョンの Windows を実行している LDAP サーバーによって処理されるときに、Cookie の内部コンテンツが異なることが予想される場合などに発生する可能性があります。 Cookie は不透明な構造であり、すべての Windows OS バージョンで構造的に一貫性があることは保証されていません。 クライアント アプリケーションはこのケースを処理し、このエラーが発生した場合は完全同期で再試行する必要があります。
オブジェクトの名前が変更または移動されると、子オブジェクトの識別名が変更されていても、その子オブジェクト (存在する場合) は検索結果に含まれません。 同様に、オブジェクト セキュリティ記述子で継承可能な ACE が変更された場合、子オブジェクトのセキュリティ記述子が変更された場合でも、オブジェクトの子オブジェクトは検索結果に含まれません。
objectGUID 属性を使用して、追跡対象のオブジェクトを識別します。 各オブジェクトの objectGUID はメインフォレスト内のオブジェクトの移動場所に関係なく変更されません。
DirSync 検索の検索結果は、検索時のディレクトリ パーティションのレプリカ上のオブジェクトの状態を示していることに注意してください。 つまり、他の DC で行われた変更は、ターゲット DC にレプリケートされていない場合は含まれません。 また、以前の DirSync 検索以降にオブジェクトの属性が複数回変更された可能性がありますが、検索では一連の変更ではなく、最終的な状態のみが表示されます。
ADSI 実装では、アプリケーションは Cookie を不透明として処理する必要があり、内部の組織や価値に関する想定を行う必要はありません。
クライアントは、同期されたオブジェクト データを含むのと同じストレージに、DC の Cookie、Cookie の長さ、DNS 名を格納していることに注意してください。 これにより、ストレージがバックアップから復元された場合に、Cookie やその他のパラメーターがオブジェクト データと同期してメインされます。
DirSync コントロール用に構築された parentGUID 属性を取得するには、name 属性を要求する必要もあります。
DirSync コントロールを使用するには、呼び出し元に、監視対象のパーティションのルートに "ディレクトリの変更を取得する" 権限が割り当てられている必要があります。 既定では、この権限は、管理istrator アカウントと Doメイン コントローラー上の LocalSystem アカウントに割り当てられます。 呼び出し元には、 DS-Replication-Get-Changes 拡張制御アクセス権も必要です。 この権限を持たないアカウントで実行する必要があるアプリケーションの変更追跡メカニズムの実装の詳細については、「USNChanged を使用した変更のポーリング」を参照してください。 特権の詳細については、「特権」を参照してください。
DirSync 検索を使用して削除されたオブジェクトを取得する
ADS_Standard EditionARCHPREF_DIRSYNC検索結果には、指定した検索フィルターに一致する削除されたオブジェクト (廃棄石) が自動的に含まれます。 ただし、オブジェクトがライブのときにオブジェクトと一致する検索フィルターは、削除後にオブジェクトと一致しない可能性があります。 これは、廃棄石が元のオブジェクトに存在する属性のサブセットのみを保持するためです。 たとえば、通常、ユーザー オブジェクトには次のフィルターを使用します。
(&(objectClass=user)(objectCategory=person))
objectCategory 属性は、オブジェクトが削除されると削除されるため、上記のフィルターは廃棄オブジェクトと一致しません。 逆に、 objectClass 属性は廃棄オブジェクトに保持されるため、"(objectClass=user)" のフィルターは削除されたユーザー オブジェクトと一致します。
DirSync 検索で指定した属性リストもフィルターとして機能します。検索結果には、以前の DirSync 検索以降に指定した属性の 1 つ以上が変更されたオブジェクトのみが含まれます。 属性リストに廃棄石に保持されている属性が含まれていない場合、検索結果には廃棄石は含まれません。 これを処理するには、null 属性リストを指定してすべての属性を要求します。または、isDeleted 属性を要求し、すべての廃棄石で TRUE に設定できます。 Tombstone 属性には、attributeSchema 定義の searchFlags 属性に0x8 ビットが設定されています。
詳細については、「削除されたオブジェクトの取得」を参照してください。
DirSync コントロールの LDAP 実装
LDAP_Standard EditionRVER_DIRSYNC_OID コントロールで LDAP API を使用して DirSync 検索を実行することもできます。 LDAP API を使用する場合は、LDAP_Standard EditionRVER_EXTENDED_DN_OIDコントロールとLDAP_Standard EditionRVER_SHOW_DELETED_OID コントロールも指定します。 LDAP_Standard EditionRVER_EXTENDED_DN_OID コントロールにより、LDAP 検索は、ユーザー、グループ、コンピューターなどのセキュリティ プリンシパル オブジェクトの objectGUID と objectSID を含む識別名の拡張形式を返します。 LDAP_Standard EditionRVER_SHOW_DELETED_OID コントロールを使用すると、削除されたオブジェクトのデータが検索結果に含まれます。 これらのコントロールは ADSI 実装に自動的に含まれていることに注意してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示