Active Directory の監査データを解釈するのは、思っているほど簡単ではありません！

イベントログを調べて、ある変化が何だったのかを把握する必要があったのは、しばらく前のことでした。 Active Directory。Netwrix に入社したばかりだったので、Windows の監査（Windows auditing）を見直す時間を少し取るのは良い考えかもしれないと思い、特に AD DS（ドメイン サービス）のログ記録に関する What’s New Windows Server を確認しました。進展があったにもかかわらず、いくつかの AD DS のログ記録の問題がいまだに残っていることに驚きました。

私は、AD オブジェクトに適用された変更について「変更前」と「変更後」の値を提供する新しい 2008 AD DS の設定をすでに見ていましたが、この機能が実際に使えるのかどうかは分かっていませんでした。ところが、このケースでは昔からの格言 “You may get more than you bargain for…” がそのまま当てはまることを見つけました。AD DS の監査に関するいくつかの問題は、回避するのがかなり大変でした。

単純なデータ変更であれば、ネイティブのログ記録はかなりうまく機能します——ログを整理して正しいイベントを見つけられればの話です。イベントが見つかったら、何が変わったのかを把握するために詳細を確認するだけです。これは簡単な作業です。

より複雑な変更への対応は、主に Windows がイベントデータを書き込む方法のせいで、私が想像していたより直感的ではありませんでした。私は、グループに対してユーザーのセキュリティ権限を委任するという手順で、単純な変更を行ったつもりでした。そこで、変更の痕跡を探すためにイベント ログを確認しました。数十件のイベントをフィルタリングした後、実際の変更内容を示すイベントを見つけました。イベントを確認すると、更新されたセキュリティの詳細が、人が読める形式ではなく内部の AD 形式のまま残っていることが分かりました。グループの「セキュリティ」タブに表示されるようなデータが見られると期待していたのですが、手に入ったのは意味のない「ごちゃごちゃ」した情報ばかりで、何が変わったのか理解できませんでした。

少し調べ始めたところ、ほかにもいくつかの属性が、まったく判読不能な“生の” AD DS 形式のままイベント ログに書き込まれていることを見つけました。そこで、この問題をさらに掘り下げるのに 1 時間以上かけているうちに、これらの情報が単に“そのまま使える”形でレンダリングされないことへのいらだちが強くなっていきました。さらに、私たちの change auditing ソリューションが、正しいイベント（またはイベント群）に的確に絞り込み、このデータをシンプルで効率的、かつ人が読める形式で素早く表示してくれる点を、これまで以上にありがたく感じるようになりました。

Netwrix Active Directory Change Reporter の詳細についてはこちらをクリックしてください。