AD管理者に期限切れのパスワードの再利用を要求したユーザーを検出するにはどうすればよいですか？
私が働いていた企業の間では、管理者（またはヘルプデスクの人々）が、ユーザーにパスワードの変更を強制するのではなく、古い期限切れのパスワードの礼儀の延長をユーザーに与える傾向があります。
これは通常、Ctrl-Alt-Deleteを使用してパスワードを変更するのではなく、ADユーザーとコンピューターを介して期限切れのパスワードを直接再入力することによって行われます。
「最後のパスワード変更」フィールドは、この状況を検出する有効な方法ではないことを考えると、期限切れのパスワードの再利用を検出するにはどうすればよいですか？
例としては、コンプライアンスを確保するために、パスワードハッシュを頻繁に比較することがあります。しかし、私は最も論理的で安全なアプローチを探しています。
グループポリシーで監査を構成する方法は複数ありますが、（Windows Server 2003の）主な古い方法は、GPMCを開き、既定のドメインポリシー（またはOUとオブジェクトでアクティブなドメインポリシー）を編集することだと思います。での作業を再開し、[ポリシー]ノードから[Windowsの設定]から[セキュリティの設定]にドリルダウンして、[ローカルポリシーの監査ポリシー]ブランチを開きます。定義できる「監査アカウント管理」セクションがあります。
上記では、アカウントの変更を監査することしかできませんが、ユーザーのパスワードの有効期限が最近切れたなどの成功基準に関連付けて、アカウントを実行可能にする必要があります。 OSSIM（または別の強力な相関エンジン）を活用することで、すべての監査アカウント管理メッセージをチェックして、パスワードの変更であるかどうか、およびパスワードの有効期限が最近切れたかどうかを確認するADSIスクリプトを組み合わせることができます。次に、ハッシュを一致させることができます。OpenVASでさえ、パスワードをブルートフォースするためにキックオフすることができます。ただし、より多くのデータを使用してこのタスクを実行する方がおそらく良いでしょう。
これは、クライアント、サーバー、およびその他のインフラストラクチャの強化/監視のカスタマイズの演習になります。インフラストラクチャ全体の成熟度をより高いレベルに移動したいと思うでしょう-したがって、 インターネットセキュリティセンター（CIS） および/または-によって規定された作業の多くをすでに完了していると思います [〜＃〜] nist [〜＃〜] 。
あなたがよりグリーンフィールドであり、過去にこのようなカスタマイズされたソリューションを実装したことがない場合は、ForgeRockの OpenIDM などの将来性のあるソリューションにジャンプする方が確かに良いでしょう。これは数百万ドル、6年程度のプロジェクトになります。
Fortune 500などの大規模なインストールのブラウンフィールド運用を行っている場合は、IDライフサイクル管理の問題をどこに当てはめるかを適切に分析するために、既存のIAM、IDM、ディレクトリ、ESB、およびその他のバックオフィスコンポーネントを特定するのが最善です。ユーザーパスワードのリセットなど。 SAP、Oracle、TIBCO、Microsoftなどの既存のソリューションプロバイダーが簡単な答えを持っている可能性があります。
あなたがMicrosoftショップ（100％）だけの場合は、おそらく彼らの ILM 2007 製品、 FIM 201 、および関連するソリューションについて話し合うことをお勧めします。マイクロソフトには、これらの製品ラインをキャンセルしたり、大幅に変更したりする厄介な方法があります。そのため、「インサイドトラック」に腰を下ろして、アカウントマネージャーだけでなく、ILM/FIMや他の製品マネージャー（PM）と直接話し合うことをお勧めします。 （AM）またはそのWebサイトと取引情報。
Questソフトウェアの ChangeAuditor for AD など、他にもポイントソリューションがありますが、明らかにビジネスプロセスと膨大なビジネス/インフラストラクチャの成熟度がある場合、これは短期的な問題のみを解決することに注意します。問題が存在する可能性があります。
ここでの答えは、テクノロジーだけでなくプロセスでもあるかもしれません。この礼儀は、実行されるべきではなく、管理者のアクションが監査されるべきであり、それを実行している管理者は罰せられるべきです。セキュリティポリシーに準拠していない限り（ある場合）
技術レベルでは、ここでの基本的な問題は、ヘルプデスクがパスワードをリセットし、[ユーザーはパスワードを変更する必要がある]チェックボックスをオフのままにしておくことができることです。
forceこのチェックボックスをオンのままにする方法がわかりません。あるかもしれませんが、方法がわかりません。
これを回避する1つの方法は、ヘルプデスク担当者にADユーザーとコンピューターへのアクセスを委任せずに、LDAPを使用してパスワードをリセットし、同時に「ユーザーは次回のログイン時にパスワードを変更する必要がある」フラグを設定するスクリプトを作成することです。 。このスクリプトをさらに便利にすることができます（ヘルプデスクの場合）。一時パスワードとして短くて単純なパスワードを自動生成し、それをユーザーに電子メールで送信（または渡す）します。
つまり、最終的には、これは技術的な問題ではありません。今日、技術者以外のユーザーでも膨大な数のパスワードを扱っているので、私は彼らの苦痛を完全に感じています。一部のセキュリティ担当者は、これを長く主張していますが、ほとんどまたはまったく変更されない、覚えやすいパスワードの方が実際には優れている可能性があります。
多くの場合、「礼儀の拡張」がなくても、ユーザーは常に同じ短い単純なパスワードにカウンターを追加し、脆弱なシステムや機密性の高いシステム間で同じパスワードを共有することで、パスワード変更メカニズムを無効にします。または、トップマネジメントに不平を言い、ポリシーを「パスワードを変更しない」に変更することによって。
したがって、最善の戦略は、トップマネジメントレベルでこの問題に対処することです。トップマネジメントがこの問題の解決を支援していない場合、技術レベルで問題に対処しようとする試みは裏目に出る可能性があります。そして、トップマネジメントisこの問題の解決を支援する場合、技術的な解決策は必要ないかもしれません。ヘルプデスク担当者は、そのような礼儀正しい行動を具体的に禁止する新しいポリシーを取得するだけです。