web-dev-qa-db-ja.com

lockoutTime属性のレプリケーションはAD-LDSでは緊急ではありません

同じサブネット上に2つのLDSサーバーがあります。それらはよく複製します。属性を変更すると、15秒後に複製されます。

LDSは、パスワードポリシーを尊重するように構成されています。ユーザーが間違ったパスワードを何度も試行すると、アカウントがロックされ、それに応じてそのユーザーのlockoutTime属性が設定されます。

ただし、lockoutTimeはurgentとして複製されません。実際、ディレクトリのどこかに別の変更がない限り、複製されません。 lockoutTime属性が複製されます。

これが（編集されたWireshark）トレースです。通常のレプリケーショントラフィックを示しています

No.   Time     Protocol Length Info
  133 16:23:02 DRSUAPI  562    DsGetNCChanges request
  134 16:23:02 DRSUAPI  3042   DsGetNCChanges response
  152 16:23:17 DRSUAPI  562    DsGetNCChanges request
  157 16:23:17 DRSUAPI  242    DsGetNCChanges response
  230 16:24:57 DRSUAPI  562    DsGetNCChanges request
  231 16:24:57 DRSUAPI  2930   DsGetNCChanges response
  246 16:25:12 DRSUAPI  562    DsGetNCChanges request

その直後に、ユーザーをロックします（FORループとldifdeを使用）。ユーザーのdescription属性をあきらめて変更するまで、何も起こりません。その後、約15秒後にレプリケーションが実行されます。

 1984 16:31:05 DRSUAPI  562    DsGetNCChanges request
 1985 16:31:05 DRSUAPI  2930   DsGetNCChanges response

LockoutTimeと説明が複製されます。 ここに記載 のように、lockoutTime=0を設定すると、15秒後に通常のレプリケーションが発生します。

レプリケーション診断 を有効にしました。レプリケーションがないため、インスタンスのログには何も表示されません。レプリケーションがトリガーされると、最新の属性のイベント1239の束、2つの1240イベントが表示されます。 1つは属性lockoutTime用で、もう1つはdescription用です（これはレプリケーションをトリガーするために使用しました）。

サイト間の変更通知 を有効にし、両方のサービスを再起動しましたが、違いはありませんでした。 2つのサーバーが同じサブネット上にあるためかもしれません。

Active Directory技術仕様 は 複製する緊急属性の1つとしてlockoutTime を明確にリストしています。

lockoutTime属性の緊急レプリケーションを妨げている可能性があるのは何ですか？

windows-server-2008replicationad-ldsactive-directory
5
ixe013

（マイクロソフトへのサポートコールの結果で私自身の質問に答える）

これはAD-LDSのバグです（バグチェックID 354126）。 Windows Server 2008に影響しますが、Server2012についてはわかりません。

問題は、レプリカに通知が送信されないことです（緊急でも通常でもありません）。アカウントのロックアウトがDBに保存されている場合、LDSはグローバル通知リストを更新しません。したがって、スケジュールされたレプリケーションが開始された後にのみ、レプリケーションが発生します。

途中で、を呼び出すスケジュールされたタスクを作成することです

repadmin /syncall localhost:389

複製するものがない場合、この呼び出しは約42kのネットワークトラフィックを生成します。

問題を回避するもう1つの方法は、何もしないことです。このバグにより、攻撃者はパスワードを推測する可能性が2倍になります。ユーザーは通常LDSを直接呼び出さないため、悪用するのは困難です。そして、たとえ彼らがそうしたとしても、このバグは彼らのチャンスを2倍にするだけでしょう。

3
ixe013