web-dev-qa-db-ja.com

IE HTTPKerberosがADドメインと一致しないFQDN上のサイトへの認証で問題が発生する

Kerberos自動ログインを使用して認証する企業ドメイン上のサイトがありますIE and Chrome DNSがアクセスに使用されている限り、問題ありませんADFQDNに該当します

ADドメインはパブリックドメインではありません。この例では、ADドメインをcompany.internal.corp.netと呼びます。標準SPNは、IISHTTP/somesite.company.internal.corp.net mycompany\svc_iisなどのドメインユーザーアカウント、および= IEは、このサイトをイントラネットサイトとして表示するように構成されています(自動ログインを許可します)

FQ AD Domain: company.internal.corp.net
NETBIOS domain name: MYCOMPANY
DNS for my website: somesite.company.internal.corp.net
IIS App Pool account: MYCOMPANY\svc_iis
SPN: HTTP/somesite.company.internal.corp.net MYCOMPANY\svc_iis

公開証明書のSSL認証チェーンを利用するために、このサイトのDNSを別の名前somesite.mycompanypublic.comに変更することにしました。 サイトを外部からアクセスできるようにする予定はありません。 DNSレコードは、内部解決とアクセスのみを目的として同じサーバーを指します。IEは、これを表示するように構成されています。イントラネットサイトとしてのサイト(自動ログインを許可)。これで、次の設定ができました。

FQ AD Domain: company.internal.corp.net
NETBIOS domain name: MYCOMPANY
DNS for my website: somesite.mycompanypublic.com  <-- new DNS name, not same as AD domain
IIS App Pool account: MYCOMPANY\svc_iis
SPN: HTTP/somesite.mycompanypublic.com MYCOMPANY\svc_iis  <-- new DNS name, not same as AD domain

この新しい構成では、DNSサービス名がADドメイン名と一致しなくなりましたが、それが問題になるかどうかはわかりません

上記のように構成すると、Kerberosは機能しなくなります。 IE NTLMのユーザー名/パスワードの入力を求められます。chromeプロンプトが表示されることもあれば、失敗ページが表示されることもあります。フィドラートレースでは、Kerberosチケットは通過していますが、サーバーは拒否しています。毎回別の401を毎回使用します。IE isこのサイトをイントラネットサイト(自動ログインを許可)として表示するように構成されているため、問題ではありません-チケット通過。

この構成はサポートされていますか?トラブルシューティングのアイデア?

SPNが適切に構成されていないかのように動作します。必要に応じて、フィドラートレースまたはwiresharkキャップを提供できます。

1
TheSoftwareJedi

SPNはADドメインと一致する必要はありません。接続に使用される名前と一致するSPNが必要です。 「Kerberosチケットの受け渡し」とはどういう意味かわかりません。 Kerberos資格情報がサーバーに渡される場合、HTTP認証ヘッダーは「ネゴシエートY」で始まる必要があります。

おそらく最も簡単な方法は、DelegConfigツールをセットアップし、レポート/ウィザードを使用して構成をテストすることです。

http://blogs.msdn.com/b/chaun/archive/2013/09/15/some-tips-on-setting-up-the-delegconfig-tool.aspx

http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx

ASP.NETのトラブルシューティング
http://support.Microsoft.com/kb/891032

1
Greg Askew

この問題は、ドメインが異なることとはまったく関係がありませんでした。 IEがチケットを渡すように正しく構成され、SPNがADで正しく構成されている限り、任意のドメインを使用できます。グレッグの回答から、いくつかのリンクが提供されました。 SPNの問題を解決するためにここに来るかどうかを調べてください。

カーネルモード認証を無効にする必要があることを発見しました。これには、その構成セクションのロックを解除する必要もありました。また、サイトのDNSエントリがCNAMEの場合、Internet Explorer(Chromeではない)は、SPNチケットの作成時にCNAMEが指しているホストの名前を使用することもわかりました。


アプリプールの資格情報をそのまま使用するようにサーバーを構成する必要がありました

<system.webServer>
   <security>
      <authentication>
         <windowsAuthentication enabled="true" useAppPoolCredentials="true" />
      </authentication>
   </security>
</system.webServer>

カーネルモードの理解と構成


ただし、その構成ブロックを変更するには、次のものが必要でした。

同僚が、IIS Manager(Thanks、Ryan)のルート(コンピューター)レベルにある[Feature Delegation]アイコンを指さしました。FeatureDelegationページをクリックすると、機能とその現在のリストが表示されます。設定を上書きします。いくつかの例外を除いて、各機能を読み取り/書き込み、読み取り専用、または委任なしに変更できます。

構成セクションのロック解除

0
TheSoftwareJedi