AD 環境で NTLM V1 ログインをすべて削除する作業を行っています。多数のイベントが見つかりました。そのほとんどはユーザー「匿名ログオン」(4624 イベント) からのもので、その他の 1% (4624 イベント) は一部のユーザーからのものです。そこで、いくつか質問があります。
- 「匿名ログオン」を無効にする (GPO セキュリティ設定経由) か、「NTLM V1」接続をブロックする方がよいでしょうか。どちらかまたは両方を実行する場合のリスクは何ですか。これらのログオン イベントは、主に他の Microsoft メンバー サーバーから発生します。
- 匿名ログオンでは、常に「NTLM V1」が使用されますか? つまり、匿名ログオンが表示された場合、間違いなく NTLM V1 が使用されていると想定できますか?
- 匿名ログオン イベント 540 と 4624 の違いは何ですか? -> 注: 機能レベルは 2008 R2 です
追加情報が必要な場合はお知らせください。
答え1
あなたが投げかけた質問は、「匿名ログオン」を無効にする（GPO セキュリティ設定経由）か、「NTLM V1」をブロックする方がよいですか？、これはあまり良い質問ではありません。なぜなら、これら 2 つは相互に排他的ではないからです。両方行うことも、どちらも行わないことも、どちらか一方だけ行うことも、程度はさまざまです。グレーの色合いが多く、白黒にまとめることはできません。
NTLMv1 を無効にすることは、一般的には良い考えです。これは、LmCompatibilityLevelレジストリ設定またはグループ ポリシーを使用して行われます。同じ設定でも、マシンがドメイン コントローラーであるかドメイン メンバーであるかによって動作が若干異なることに注意してください。
http://technet.microsoft.com/en-us/library/cc960646.aspx
ここでNTLMv1を無効にすると、下位互換性が失われるという潜在的なリスクがあります。とても古い Windows クライアント、そしておそらく NTLMv2 に対応していない Microsoft 以外のクライアント。これらをテストする必要があります。比較的新しい、パッチを適用したバージョンの Windows であれば、問題なく NTLMv2 とセッション セキュリティを処理できます (Server 2000 以上のバージョンがこれに該当します)。
匿名ログオンを無効にすることは、まったく別のことです。匿名ユーザーが共有、SAM アカウント、レジストリ キーを列挙する機能を無効にすることができます。これらのすべてまたはいずれか、あるいは組み合わせを無効にすることもできます。匿名ログオンを制限するほど、セキュリティ体制は強化されますが、使いやすさと利便性は失われます。(たとえば、ユーザーがサーバー上のファイルまたはプリンターの共有を列挙できなくなる可能性があります。)
だから、どちらがより良い。これらはどちらも、まったく異なることを実行する 2 つの異なるメカニズムです。
イベント 540 は、ネットワーク経由で共有フォルダやプリンタに接続するユーザーなどの「ネットワーク」ログオンに固有のものです。これは、Win 2003 スタイルのイベント ID でもあります。3 桁しかないので、すぐにわかります。Vista/2008 の対応するイベントは、4 桁の ID に変換されました。
Eric Fitzgerald 氏は次のように語っています。「私は、WS03 およびそれ以前のバージョンの Windows の「古い」イベント ID (5xx-6xx) と、Vista 以降の「新しい」セキュリティ イベント ID (4xxx-5xxx) の関係について、2 回 (こちらとこちら) 書きました。」
つまり、WS03 のほぼすべてのセキュリティ イベントの EventID(WS03) + 4096 = EventID(WS08) です。
例外はログオン イベントです。ログオン成功イベント (540、528) は、1 つのイベント 4624 (=528 + 4096) にまとめられました。ログオン失敗イベント (529-537、539) は、1 つのイベント 4625 (=529+4096) にまとめられました。
それ以外にも、古いイベントが廃止された場合 (IPsec IIRC) や、新しいイベントが追加された場合があります (DS Change)。これらはすべて新しいインストルメンテーションであり、「マッピング」は不可能です。たとえば、新しい DS Change 監査イベントは、古い DS Access イベントを補完するものであり、古いイベントとは異なる内容を記録するため、古いイベント xxx = 新しいイベント yyy とは言えません。これらは同等ではないためです。古いイベントは 1 つのことを意味し、新しいイベントは別のことを意味します。これらは、ログ内のイベント表現のフォーマット変更だけでなく、OS のインストルメンテーションの異なるポイントを表します。
もちろん、イベントの番号を変更した理由と、(同じ場所で) 違いが「+1000」のようなわかりやすいものではなく「+4096」である理由については、前に説明しました。要するに、イベント スキーマが異なるため、イベント ID を変更 (再利用しない) することで、オートメーションがイベントを生成した Windows のバージョンを認識していない場合にイベントを誤って解釈するのではなく、既存のオートメーションを強制的に更新します。これは面倒な作業であることは認識していましたが、すべてのイベント コンシューマーが、同じ ID でスキーマが異なる Vista 以前のイベントと Vista 以降のイベントを認識し、特別なケースを用意しなければならない場合に比べれば、はるかに面倒ではありません。
したがって、Vista 以前のセキュリティ イベントについて知っている場合は、4000 を足し、100 を足し、4 を引くことで、既存の知識を Vista に簡単に変換できます。これは頭の中で行うことができます。
ただし、何らかの自動化を実装しようとしている場合は、イベント ID 番号の "=Vista" 列を含むチャートを作成しないようにしてください。これは、イベント セットの 1 つが誤って解析される可能性が高く、1:1 のマッピングがない (場合によってはマッピングがまったくない) ことに不満を感じることになるためです。
エリック