2009-05-19 11 views
3

イントラネットWebアプリケーションを独自のフォームベースのセキュリティを使用してActive Directoryに移行しようとしています。アプリケーションはさまざまなユーザーアクションをログに記録し、ユーザーアカウントに関連するデータはかなりの量です。私たちの計画は、これらのすべてのUserId列を、独自のシステムをリンクする外部キーからActive Directory GUIDに移行することでした。ログイン名は2つのシステム間で同じなので、移行は問題ではありません。ADユーザーの操作(削除されたユーザー)

しかし、我々は1つの重大な問題を特定しました。私たちのセキュリティポリシーは、非アクティブなユーザーをActive Directoryから削除する必要があると規定しています。セキュリティログの孤立したGUIDは、エントリを見ている人にとっては無意味です。

アプリケーションは、Active Directoryから削除されたGUIDについて、人間が読める基本(名前、ログインなど)をどのように維持できますか?

以下のオプションを検討しました。これらのオプションの一つが最適になってしまうかもしれませんが、私たちはより良いために試してみたい:

  • は、アクティブなデータのために多くのログではなく、大丈夫(代わりに、GUIDのログテーブルと店舗名/ログインを非正規化。 )
  • エントリが
  • を削除されることはありませんADオブジェクト情報の「キャッシュ」ADアカウントを維持するが、非アクティブ化/

答えて

0

わかりやすいユーザー情報にマッピングするGUIDの辞書を格納する「キャッシュ」テーブルを使用することにしました。これには、ADユーザーリストを抽象化し、キャッシュから不足しているエントリを統合するビューが必要です。

0

は、ロギングのために、私は非正規化のアプローチを好むそれをロックダウンですが、idを維持を維持します。私は他の人間が読める識別情報と一緒にユーザーのIDを保管します。アクティブなユーザーの場合、私はまだジョインでIDを使用できます(必要な場合)。非アクティブ(削除された)ユーザーの場合、私は監査人が人間が読める形式を使用しています。

1

私は、ログテーブルを完全に非正規化するのではなく、代わりにTimが述べたように、関連するAD情報をGUIDの横に保存します。ただし、このAD情報が他の領域に必要な場合は、ユーザーテーブルにキャッシュしてください。私はあなたのセキュリティポリシーを変更することをお勧めします。

+0

心配はいりません。オプション3はほとんどありません。これは、システム管理者のためのものです。 –

関連する問題