IISでNTLMではなくKerberosを使用する理由

これは、私が好きなだけでなく、実際に答えることができなかった ものです。NTLMの代わりにIISでKerberos認証を使用することの本当の利点は何ですか？

多くの人々が本当にそれをセットアップするのに苦労しているのを見てきました（私自身も含めて）、そしてそれを使う正当な理由を思い付くことができませんでした。ただし、いくつかの非常に重要な利点がなければなりません。

Windowsの観点からのみ：

NTLM

• 外部（非ドメイン）クライアントと内部クライアントの両方で 動作します
• IISボックスのドメインアカウントとローカルユーザーアカウントの両方で動作します
  • ドメインアカウントを使用すると、サーバーのみがドメインコントローラー（DC）への直接接続を必要とします。
  • ローカルアカウントを使用すると、どこにも接続する必要はありません:)
  • 資格情報を使用するために問題のユーザーとしてログオンする必要はありません
  • 脇：それはDC珍しくはNTLM要求の量で忙しいNTLMサーバ（IIS、取引所、TMG / ISAなど）に圧倒されることはありません（軽減するために：MaxConcurrentAPI、AuthPersistSingleRequest（偽）。、速いのDC）（自己参照ボーナス。）
• IISサーバーへのクライアント接続のみが必要です（サイトポートで、それ以外は何もしません。つまり、すべてがHTTP（またはHTTPS）で行われます）。
• サポートするすべてのプロキシ通過できるHTTPキープアライブ秒
  • TLS / SSLを使用して他のユーザーを回避できる場合があります
• 認証には小さなパケットで複数の往復が必要です
  • （ログパターンは ユーザー名で401.2、401.1、200）
• ダブルホップ認証が必要なシナリオでは使用できません
  • つまり、ユーザーの資格情報は別のコンピューター上のサービスに転送されます
• 古いクライアントをサポート（<Win2000）
• LM認証レベルの不一致の影響を受けやすい（不一致lmcompatibilitylevel）
• Curbが失敗した場合、Negotiateパッケージによってフォールバックとして使用されます。
  • （ない「アクセスがされた場合に拒否された、縁石をしなければならないカーブで」壊す使用されるようにNTLMのために- 。通常、このルックスは、チケットが届かないようなクライアントは、チケットを取得し、それは完璧ではない場合は、フォールバック引き起こさないこと。）

Kerberos

• 連携し、現在のドメインに参加しているクライアントのみ
  • AD DC（tcp / udp 88）およびサーバーへのクライアント接続が必要です（チケットはクライアントがCurbポート経由でDCから取得し、HTTPを使用してサーバーに提供されます）

• プロキシを通過できる可能性がありますが、上記のDCポイントを参照してください。サーバーと同様に、アクティブなDCと同じネットワーク上にいる必要があります。

  • したがって、理論的には、インターネット接続されたクライアントがインターネット接続されたDCと直接チャットするドメインがあれば、それは実行可能です。しかし、あなたが既にそれを知っていなければ、それをしないでください。
  • リバースプロキシシナリオ（ISA / TMG）では、プロトコル移行サーバーはそのネットワーク上にある必要があります。つまり、クライアントではありません...しかし、クライアントは実際にはKerberosビットを実行するものではありません（必然的にForms auth to Curb遷移）。

• チケットは、長寿命であるという意味（10H）より少ないDC通信をチケットの有効期間中に-と強調して：これは、リクエストの数百万人に数千人を救うことができる クライアントごとにその生涯にわたり- （AuthPersistNonNTLMまだのものであり、KerberosのPAC検証がものにするために使用しました）

• 認証には1回のラウンドトリップが必要ですが、認証ペイロードサイズは比較的大きい（通常6〜16K）（401、{（encoded）token size} 200）
• （必ず、常に制約された）委任で使用して、次のサービスへの接続ユーザーのWindows認証を有効にすることができます
  • たとえば、UserAIISへのアクセスを許可し、IISがSQL Serverにアクセスするときに同じユーザーアカウントを使用する場合、これは「認証の委任」です。
  • （このコンテキストでの制約とは、「他の何かではなく」という意味です。たとえば、Exchangeまたは別のSQLボックス）
• 現在、ネゴシエート認証の主要なセキュリティパッケージです
  • つまり、Windowsドメインメンバーは、入手できるときにそれを好む
• SPNの登録が必要です。これは注意が必要です。役立つルール。
• IPアドレスではなく、名前をターゲットとして使用する必要があります
• 縁石が失敗する理由：
  • 名前の代わりにIPアドレスを使用する
  • SPNが登録されていません
  • 登録済みの重複したSPN
  • 間違ったアカウントに対して登録されたSPN（KRB_ERR_AP_MODIFIED）
  • クライアントDNS / DC接続なし
  • クライアントプロキシ設定/ローカルイントラネットゾーンはターゲットサイトには使用されません

私たちがそれにいる間：

ベーシック

• マルチホップできます。ただし、ユーザー名とパスワードをターゲットのWebアプリに 直接公開することでそうします
  • その後、必要なことは何でもできます。何でも。
  • 「ああ、ドメイン管理者は私のアプリを使用しただけですか？そして、彼らのメールを読んだだけですか？それからパスワードをリセットしましたか？Awww。残念 "
• 必要トランスポート層セキュリティセキュリティのあらゆる形態のための（すなわちTLS / SSLを）。
  • そして、前の問題を参照してください
• どのブラウザでも動作します
  • （ただし、最初の問題を参照）
• 必要と単一往復認証するために（401、200）
• Windowsは基本的な資格情報を使用して対話型ログオンを実行できるため、マルチホップシナリオで使用できます。
  • LogonTypeこれを実現するために構成する必要がある場合があります（2000年から2003年の間にネットワーククリアテキストに変更されたデフォルトを考えてください。
  • しかし、再び、最初の問題を参照してください。
  • 最初の問題は本当に重要だという印象を受けますか？そうです。

総括する：

縁石を設定するのは難しいかもしれませんが、プロセスを簡素化しようとするガイド（私のもの）がたくさんあり、ツールは2003年から2008年にかけて大幅に改善されました（SetSPN重複を検索できます。 ; -Aを使用するためのガイダンスが表示されたらいつでも使用しSETSPN -Sてください。

制約された委任は、入場料の価値があります。

• Kerberosは、NTLMよりも高速で安全な認証メカニズムであるという評判があります。
• また、NTLMの接続ベースの性質により、歴史的にはNTLMよりもプロキシサーバーを介して接続する方が簡単でした。
• ただし、ご指摘のように、Kerberosは立ち上げて実行するのが難しく、常に実用的ではないADへの接続が必要です。

別のアプローチは、認証を設定しnegotiate、他の代わりに一方ではなく両方を使用することです。

一般的な開発者の間違いを検出するMicrosoft Application Verifierから。それらの間違いの1つはNTLMの使用です：

NTLMは、アプリケーションやオペレーティングシステムのセキュリティを侵害する可能性のある欠陥を持つ古い認証プロトコルです。最も重要な欠点は、サーバー認証がないことです。これにより、攻撃者はユーザーをだまして、なりすましのサーバーに接続させることができます。サーバー認証の欠落の結果として、NTLMを使用するアプリケーションは、「リフレクション」攻撃として知られるタイプの攻撃に対しても脆弱になる可能性があります。この後者により、攻撃者はユーザーの認証会話を正当なサーバーにハイジャックし、それを使用してユーザーのコンピューターに対して攻撃者を認証できます。NTLMの脆弱性とそれらを悪用する方法は、セキュリティコミュニティでの研究活動の増加の標的です。

Kerberosは長年使用されてきましたが、多くのアプリケーションはNTLMのみを使用するように作成されています。これにより、アプリケーションのセキュリティが不必要に低下します。ただし、KerberosはすべてのシナリオでNTLMを置き換えることはできません。主に、クライアントがドメインに参加していないシステム（ホームネットワークがおそらく最も一般的です）に対して認証する必要がある場合です。Negotiateセキュリティパッケージは、可能な限りKerberosを使用し、他のオプションがない場合にのみNTLMに戻る下位互換性のある妥協を可能にします。NTLMの代わりにNegotiateを使用するようにコードを切り替えると、アプリケーションの互換性をほとんどまたはまったく導入せずに、お客様のセキュリティが大幅に向上します。ネゴシエート自体は特効薬ではありません。攻撃者がNTLMに強制的にダウングレードできる場合もありますが、これらを悪用するのは非常に困難です。ただし、すぐに改善される点の1つは、Negotiateを正しく使用するように作成されたアプリケーションがNTLMリフレクション攻撃の影響を自動的に受けないことです。

NTLMの使用に対する注意の最後の言葉として：Windowsの将来のバージョンでは、オペレーティングシステムでNTLMの使用を無効にすることが可能になるでしょう。アプリケーションがNTLMに強く依存している場合、NTLMが無効になっていると認証に失敗します。

非常に重要な点を追加する必要があります。

Kerberosは20年以上にわたりUnixの標準およびオープンプロトコルでしたが、NTLMはMicrosoftの純粋に独自のソリューションであり、Microsoftだけが知っています。

iisサーバー上にないリソースにアクセスするためにユーザーを偽装する必要がある場合は、Kerberosが必要です。