IISでNTLMではなくKerberosを使用する理由
これは、私が本当に答えることができず、好きなものでもありません：NTLMの代わりにIISでKerberos認証を使用する本当の利点は何ですか？
多くの人々がそれをセットアップするのに本当に苦労しているのを見てきました（私も含めて）、それを使用する正当な理由を思い付くことができませんでした。しかし、かなり重要な利点がいくつかあるに違いありません。そうでなければ、セットアップするのに苦労する価値はないでしょう。
Windowsの観点からのみ：
NTLM
- bothexternal（non-domain）とinternalクライアントの両方で動作します
- IISボックスでドメインアカウントとローカルユーザーアカウントの両方で機能します
- ドメインアカウントを使用、サーバーのみドメインコントローラー（DC）への直接接続が必要
- ローカルアカウントを使用すると、どこにも接続する必要がありません:)
- 資格情報を使用するために、問題のユーザーとしてログオンする必要はありません
- 脇：DCがNTLMリクエストの量が多いビジーなNTLMサーバー（IIS、Exchange、TMG/ISAなど）に圧倒されることはそれほど珍しいことではありません（緩和：
MaxConcurrentAPI、AuthPersistSingleRequest（false） 、より高速なDC。）（ 自己参照ボーナス =。）
- IISサーバーへのクライアント接続が必要only（サイトポート上、それ以外。つまりEverythingHTTP（またはHTTPS）で発生します。）
- HTTP Keep-Alives をサポートする任意のプロキシを通過できます
- tLS/SSLを使用して他の人を回避できる場合があります
- 複数のラウンドトリップが認証に必要小さなパケット
- （ログパターンは401.2、401.1、2ユーザー名付き）
- ダブルホップ認証が必要なシナリオでは使用できません
- つまり、ユーザーの資格情報が別のコンピューターのサービスに転送されます。
- 古いクライアントをサポート（<Win2000）
- LM認証レベルの不一致の影響を受けやすい（不一致
lmcompatibilitylevel） - 縁石が失敗した場合のネゴシエートパッケージによるフォールバックとして使用されます。
- （not "アクセスがdeniedwith Kerbの場合"、NTLMを使用するには縁石がbreakである必要があります-通常、これはチケットを取得していないように見えます。クライアントがチケットを取得し、それが完全でない場合、フォールバックは発生しません。）
ケルベロス
- currentlydomain-joined clients only で動作します
- AD DC（tcp/udp 88）へのクライアント接続が必要AND the server（チケットは、DCからCurbポート経由でクライアントによって取得されます。次に、HTTPを使用してサーバーに提供されます）
可能性プロキシを通過できますが、上記のDCポイントを参照してください：サーバーと同様に、アクティブなDCと同じネットワーク上にある必要があります。
- したがって、理論的にはインターネットに接続されたクライアントがインターネットに接続されたDCと直接チャットするドメインがある場合、それは機能します。しかし、あなたがすでにそれを知らない限り、それをしないでください。
- リバースプロキシシナリオ（ISA/TMG）では、 プロトコル遷移 サーバーがそのネットワーク上にある必要があります。つまり、クライアントではありません...しかし、クライアントは実際にはKerberosビットを実行しているわけではありません（必ず-フォーム認証から縁石への移行を考えてください）。
ticket is long-lived（10h）意味less DC通信チケットの有効期間中-そして強調します：これは数千を節約できますその存続期間中のクライアントごとの数百万のリクエスト---（
AuthPersistNonNTLMはまだ物事です Kerberos PAC検証 以前は物でした）- 認証には1回の往復が必要ですが、認証ペイロードサイズは比較的大きい（通常6-16K）（401、{（encoded ）トークンサイズ} 2）
- （ください、常にconstrained）delegationと共に使用して、次のサービスへの接続ユーザーのWindows認証を有効にすることができます
- たとえば、
UserAにIISへのアクセスを許可し、IISがSQL Serverにアクセスするときに同じユーザーアカウントを使用するには、これが「認証の委任」です。 - （このコンテキストでの制約付きは、「しかし何もない」ことを意味します。例：Exchangeまたは別のSQLボックス）
- たとえば、
- 現在、ネゴシエート認証の主要なセキュリティパッケージです。
- windowsドメインメンバーが取得できる場合は、それを優先することを意味します
- SPNの登録が必要であり、注意が必要です。 役立つルール 。
- nameをIPアドレスではなくターゲットとして使用する必要があります
- 縁石が失敗する理由：
- 名前の代わりにIPアドレスを使用する
- sPNが登録されていません
- 重複したSPNが登録されています
- 間違ったアカウントに対して登録されたSPN（
KRB_ERR_AP_MODIFIED） - クライアントDNS/DC接続なし
- クライアントプロキシ設定/ローカルイントラネットゾーンがターゲットサイトに使用されていません
私たちがそれをしている間：
ベーシック
- マルチホップできます。 ユーザー名とパスワードを直接公開を使用して、ターゲットのWebアプリにそれを行います
- これにより、必要な処理をすべて実行できます。 すべて。
- 「ああ、ドメイン管理者は自分のアプリを使用しただけなのか？そして、彼らのメールを読んだだけなのか？それからパスワードをリセットしたのか？Awww。Pity」
- 必要なセキュリティトランスポート層セキュリティ（つまり、TLS/SSL）。あらゆる形式のセキュリティ。
- そして、前の問題を見る
- どのブラウザでも動作します
- （ただし最初の問題を参照）
- 認証には1回の往復が必要（401、2）
- windowsは基本的な資格情報を使用して対話型ログオンを実行できるため、マルチホップシナリオで使用できます
LogonTypeを構成してこれを実現する必要がある場合があります（デフォルトが2000から2003の間にネットワークのクリアテキストに変更されたと思いますが、覚えていない場合があります）- again、最初の問題を参照。
- 最初の問題が本当に、本当に重要であるという印象を得ていますか？そうです。
まとめると：
縁石はセットアップが難しい場合がありますが、プロセスを簡略化しようとするガイド（ my one ）がたくさんあり、ツールがvastly2003年から2008年まで（SetSPNは、最も一般的な重大な問題である重複を検索できます; se SETSPN -S -Aを使用するためのガイダンスが表示されたらいつでも、幸せになります）。
制限された委任は、入場料に見合う価値があります。
- 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が必要です。