web-dev-qa-db-ja.com

「匿名ログオン」と「NTLM V1」の違い

AD環境でNTLM V1ログインをすべて取り除くことに取り組んでいます。多くのイベントが見つかりました。ほとんどすべてのユーザーからの「匿名ログオン」(4624イベント)、その他の1(4624イベント)パーセントは一部のユーザーからのものです。だから、ここでいくつか質問があります。

  • 「GPOセキュリティ設定)経由で」「匿名ログオン」を無効にするか、「NTLM V1」接続をブロックする方が良いですか?どちらかまたは両方のリスクは何ですか?これらのログオンイベントは主にその他のMicrosoftメンバーサーバー。
  • 匿名ログオンは "NTLM V1"を100%使用しますか?つまり、匿名ログオンが表示された場合、NTLM V1を確実に使用していると想定できますか?
  • 匿名ログオンイベント540と4624の違いは何ですか? ->注:機能レベルは2008 R2です。

追加情報が必要な場合はお知らせください。

5
Darktux

あなたが提起した質問、 ""匿名ログオン "を無効にするか(GPOセキュリティ設定)経由)、または" NTLM V1 "、これは非常に良い質問ではありません。これらの2つのことは相互に排他的ではないためです。両方を実行することも、どちらも実行しないことも、1つだけを実行することも、さまざまな程度で実行することもできます。灰色の階調はたくさんあり、 t白黒に凝縮します。

通常、NTLMv1を無効にすることをお勧めします。これは、LmCompatibilityLevelレジストリ設定を使用するか、グループポリシーを介して行われます。マシンがドメインコントローラーであるかドメインメンバーであるかに応じて、同じ設定の動作が少し異なることに注意してください。

LmCompatibilityLevel

http://technet.Microsoft.com/en-us/library/cc960646.aspx

ここでNTLMv1を無効にすることによる潜在的なリスクは、very古いWindowsクライアントとの下位互換性を壊すことであり、NTLMv2を話さないMicrosoft以外のクライアントとの可能性が高くなります。それらをテストする必要があります。 Windowsの適度に近代的でパッチが適用されたバージョンは、セッションセキュリティを備えたNTLMv2を問題なく処理します(サーバー2000以降と同じように話します)。

匿名ログオンを無効にすることは、まったく別のことです。匿名ユーザーが共有、SAMアカウント、レジストリキー、これらのすべてまたはすべて、またはそれらの組み合わせを列挙する機能を無効にすることができます。匿名ログオンを制限するほど、仮想ポスチャのセキュリティポスチャが増加し、使いやすさと利便性が失われます。 (たとえば、ユーザーがサーバー上のファイルまたはプリンター共有を列挙する機能を失う可能性があります)。

つまり、どちらが優れているかを実際に言うことはできません。どちらも、2つのまったく異なるメカニズムを実行する2つの異なるメカニズムです。

イベント540は、netwokを介して共有フォルダーまたはプリンターに接続しているユーザーなど、「ネットワーク」ログオンに固有です。これは、Win 2003スタイルのイベントIDでもあります。たった3桁なのでわかります。 Vista/2008での対応するイベントは、4桁のIDに変換されました。

エリックフィッツジェラルドは言った:WS03と以前のバージョンのWindowsの「古い」イベントID(5xx-6xx)の間、および「新しい」セキュリティイベントID(4xxx-5xxx)の間の関係について(こことここ)を2回書いた)Vista以降。

つまり、WS03のほとんどすべてのセキュリティイベントのEventID(WS03)+ 4096 = EventID(WS08)です。

例外はログオンイベントです。ログオン成功イベント(540、528)は、単一のイベント4624(= 528 + 4096)にまとめられました。ログオン失敗イベント(529-537、539)は、1つのイベント4625(= 529 + 4096)にまとめられました。

それ以外に、古いイベントが廃止された場合(IPsec IIRC)や、新しいイベントが追加された場合(DS変更)があります。これらはすべて新しい機器であり、「マッピング」は不可能です。新しいDS変更監査イベントは古いDSアクセスイベントを補完します。これらは古いイベントとは異なる何かを記録するので、古いとは言えません。イベントxxx =新しいイベントyyyは同等ではないためです。古いイベントは1つのことを意味し、新しいイベントは別のことを意味します。これらは、OSでのインストルメンテーションのさまざまなポイントを表しており、ログのイベント表現のフォーマット変更だけではありません。

もちろん、イベントの番号を付け直した理由と、(同じ場所で)違いが「+1000」のようなより人間に優しいものではなく「+4096」である理由を先に説明しました。要点は、イベントスキーマが異なるため、イベントIDを変更することで(再利用せずに)、オートメーションがWindowsのバージョンを認識していないときに、イベントを誤って解釈するのではなく、既存のオートメーションを強制的に更新することです。イベントをプロデュースしました。私たちはそれが苦痛であることに気づきましたが、すべてのイベントコンシューマーが同じIDを持つがスキーマが異なるビスタ前のイベントとビスタ後のイベントを認識し、特別なケースを持っている必要があるかのように苦痛に近いものではありません。

したがって、Vistaより前のセキュリティイベントを知っている場合は、4000を加算し、100を加算し、4を減算することで、既存の知識をVistaにすばやく変換できます。これは頭の中で行うことができます。

ただし、いくつかの自動化を実装しようとしている場合は、イベントID番号の「= Vista」列を使用してチャートを作成することは避けてください。これにより、1つのイベントセットが誤って解析される可能性があり、 1:1マッピングがない(そして場合によってはまったくマッピングされていない)ことにイライラします。

エリック

http://blogs.msdn.com/b/ericfitz/archive/2009/06/10/mapping-pre-Vista-security-event-ids-to-security-event-ids-in-Vista。 aspx

6
Ryan Ries