次の方法で共有

SharePoint の内部

  • [アーティクル]

SharePoint での認証に Kerberos を使用する

Pav Cherny

SharePoint では複数の認証オプションと認証ゾーンが提供されていますが、イントラネット シナリオでエンタープライズ実装に使用される最も一般的なオプションは NTLM と Kerberos の 2 つです。どちらのプロトコルも、従来のチャレンジ/レスポンス スキームで、統合 Windows 認証と共に使用されます。NTLM は IIS に依存しています。IIS がチャレンジを含むトークンを生成し、これをクライアントに送信します。クライアントはトークンを使用して応答し、ドメイン コントローラーがその応答を検証します。NTLM では、ユーザー名とパスワードは、送信前に暗号化される必要があります。また、新しいネットワーク リソースにアクセスするときには、再認証 （新しいトークン） が必要です。一方、Kerberos は、チケット発行システムに依存しています。クライアントとサーバーは、このチケット発行システムによってキー配布センター (KDC) と呼ばれる信頼された機関にアクセスし、KDC はクライアント要求に応答して、ネットワーク リソースにアクセスするためにクライアントが使用できるチケットを付与します。Kerberos では複数のリソースにアクセスする場合も再認証は必要ありません。

公開されている多くのドキュメントでは、厳しいセキュリティ サービス レベル アグリーメントがあるサイトなど、どうしても必要な場合以外は、NTLM の使用を推奨しています。よく考えると、厳しいサービス レベル アグリーメントがある場合でも、NTLM を使用することが明確な答えであるように思えます。というのも、NTLM の方が、実装が簡単で、追加の手順が必要ではなく、サポートの問題も軽減できる可能性があるからです。たとえば、サポート技術情報の記事 832769 には、「… またはサービス プリンシパル名 (SPN) を構成できない場合は、NTLM 認証を選択します。Kerberos 認証を選択した場合に SPN を構成できないと、サーバー管理者のみが SharePoint サイトで認証されるようになります」と書かれています。このガイダンスは技術的には正確ですが、SPN の構成は非常に複雑であることや、Kerberos を実装する必要に迫られない限りは Kerberos を使用しない方がよいことは示されていないようです。しかし、実際には、原理を理解すれば、Kerberos の実装はそれほど難しくありません。

Kerberos に移行したり、新しい実装では最初から Kerberos を使用した方がよい理由は多数ありますが、ほとんどの場合、パフォーマンスかセキュリティに行き付きます。NTLM ベースの認証では、SharePoint Web パーツやカスタムの Web サービスにアクセスする Web アプリケーションなど、多くの SharePoint の使用シナリオにおいて、IIS とドメイン コントローラー間で複数のラウンド トリップが必要になります。そのため、NTLM を使用した場合、ユーザー ロードまたはトポロジが複雑になるにつれて、パフォーマンスの問題が発生する可能性があります。また、ドメイン コントローラーが低速または待ち時間の長いリンク経由でアクセスされる場合は、パフォーマンスの問題が発生する可能性が高くなります。セキュリティに関しては、ネットワーク リソースを明示的に委任するチケット ベースのシステム (Kerberos) の方が、ユーザー資格情報を暗号化するだけに比べて、仕様からして安全です。また、1 つのチケットを使用して複数のネットワーク リソースにアクセスするため、処理速度も速くなります。

多くのインストールでは、Kerberos ではなく NTLM が最初に使用されます。その理由は、トポロジの計画、サーバーのサイズ変更、セキュリティ サポート プロバイダー (SSP) などの設定だけでも十分困難に思えるのに、さらに複雑な作業が加わるとなると手に負えないように感じられるからです。このように気が引けるのは、もっともなことです。ですが、Kerberos を有効にした実装でも問題はあります。発生する可能性があるいくつかの問題については、サポート技術情報の記事 871179、962943 (英語)、および 832769 を参照してください。STOP エラーやブルー スクリーンと同じぐらい重大な問題が発生する可能性もあります。マイクロソフトが提供している Kerberos の実装についての詳細なガイドなど、既存のドキュメントにも、カーネル モードの認証機能を実装し、SPN の処理方法を変更する IIS 7.0 以降のバージョンについての詳細が含まれていません。しかし、心配無用です。SharePoint で Kerberos がどのように使用されるかについての基本的な概念を理解すれば、実装と構成は比較的単純です。このコラムでは、基本的なアーキテクチャー コンポーネントについて説明します。また、作業に取り掛かりやすいように、いくつかの構成の詳細情報も提供します。また、追加の参考資料として、マイクロソフト Web サイトで公開されている詳細な手順が記載さたドキュメントや、サポート技術情報の記事 832769 および 953130 (英語) を参照してください。

認証コンポーネントと依存関係

まず、統合 Windows 認証を処理する SharePoint アーキテクチャの依存関係について説明しましょう。最も基本的なレベルでは、NTLM と Kerberos のどちらでも、SharePoint に対応した .aspx Web ページを要求するクライアントが存在し、Web ページでは .NET と IIS をバックグラウンドで使用しています。Web ページは、SQL Server の構成データベースとコンテンツ データベースのデータに依存しています。認証に関係するため、IIS が SharePoint 2007 コンテキストで要求を処理する手順を図 1 に示します。クライアントのブラウザーから Web 要求が行われると、IIS でスレッドが作成され、IPrincipal オブジェクトで保持されている IIdentity オブジェクトなど、その要求に関連するオブジェクトがスレッドにアタッチされます。プログラムを使用する場合、IIdentity オブジェクトと IPrincipal オブジェクトには、HttpContext.User プロパティからアクセスし、これらのオブジェクトとプロパティは .NET パイプラインに含まれる認証モジュールによって設定されます （図 1 参照)。

 

図 1** SharePoint の共通認証コンポーネントとデータ フロー**

データ フローの詳細なプロセスは次のとおりです。

  1. クライアントのブラウザーが、匿名で HTTP GET 要求を利用して、SharePoint フロント エンド サーバーへの接続を開始します (このプロセスは IIS と .NET で処理されます)。
  2. ゾーンが匿名アクセスを使用するように構成されている場合 (インターネット シナリオの場合など)、IIS では要求の処理を続行します。それ以外の場合、IIS ではエラー 401.2 を返して、クライアント ブラウザーからの認証を要求します。
  3. クライアント ブラウザーが要求を受信し、ゾーンおよび関連付けられているオプションに応じて、クライアントを認証します。一般的な処理では、AcquireCredentialsHandle を呼び出して、ユーザー名とパスワードの入力を求め、IIS 経由で認証トークンを SharePoint に返します。
  4. IIS では、HTTP 通信の応答を待機し、認証トークンを受け取って、アクセスを承認または拒否します。この時点で、IIS は .NET 経由で要求を SharePoint に渡します。
  5. 要求されたページに、バックエンドの SQL Server データベースにアクセスする必要がある Web パーツが含まれている場合、SharePoint では SQL Server との認証を実行して、データベースにアクセスします。この SQL Server との認証方法は、構成オプションによって異なります。たとえば、SQL Server 認証、または NTLM か Kerberos を使用して統合 Windows 認証を構成できます。Kerberos と NTLM の詳細については、次のセクションで説明します。

SharePoint の認証メカニズムに含まれない最も重要なものは、それぞれに役割を果たすクライアント ブラウザー、IIS と .NET、および SQL Server の 3 層です。コンパイルされた .aspx ページを返すには、クライアントと IIS 間および IIS と SQL Server 間の両方で認証と承認を実行します。SQL Server が IIS と同じ物理サーバー上にあるシナリオで NTLM を使用する場合など、このプロセスが簡素化されることがあります。このようなシナリオでは、クライアントから IIS までは 1 ホップしかありません。.NET での認証の詳細については、「解説: ASP.NET 2.0 での Windows 認証 (英語)」を参照してください。

NTLM と Kerberos

Windows Server、IIS、および .NET がユーザーの認証と承認に使用する基盤のメカニズムについて説明したので、今度は、これが、NTLM と Kerberos を使用する統合 Windows 認証のコンテキストで、どのように当てはまるかを説明します。前述のとおり、NTLM と Kerberos の最大の違いは、NTLM では各ネットワーク リソースへのアクセスに承認と認証を必要とするチャレンジ/レスポンス メカニズムを使用するのに対し、Kerberos では認証を 1 度だけ行い、後は委任によって承認を行うチケット システムを使用することです。この違いがはっきりわからなくても心配無用です。詳細については、この後説明します。図 2 に、NTLM を使用する場合の SharePoint による要求の処理のしくみを示します。

 

図 2** SharePoint での NTLM 認証**

図 2 からわかるように、NTLM を使用するには、ユーザーを認証できるドメイン コントローラーが必要です。ドメインがネイティブ モードで実行されている場合、既定では、ドメイン コントローラーまたは別のサーバー上にグローバル カタログを用意する必要があります。ドメイン コントローラーに接続したときに、グローバル カタログがローカルにない場合、認証要求をグローバル カタログ サーバーに転送する必要があるので 2 重ホップの問題になるだけでなく、パフォーマンスの問題になり得る要素の 1 つです。低速リンクを使用する場合、この転送処理で多くのリソースと帯域幅が消費される可能性があります。NTLM 認証では、MaxConcurrentApi レジストリ エントリの値を変更するなど、パフォーマンスをわずかでも向上するための作業を追加で行えますが、NTLM 認証がチャレンジ/レスポンス スキーマに依存しているという基本的なニーズや、高い負荷がかかった場合に生じるパフォーマンスの問題が解決されるわけではありません。

同じドメイン内のアカウントの NTLM 認証プロセスは次のとおりです。

  1. 最初は前述のプロセスと同じで、クライアント ブラウザーが HTTP GET 要求を使用して、IIS と .NET を実行する SharePoint サーバーへの接続を開始し、匿名認証を試みます。
  2. IIS では匿名要求を拒否して 401.2 エラーを返し、NTLM による認証を行うよう要求を送信します (WWW-Authenticate: NTLM)。
  3. クライアント ブラウザーでは、要求を受信すると、InitializeSecurityContext を呼び出して、ドメインとコンピューター名を含む認証トークンを作成し、この認証トークンを IIS に送信します。
  4. IIS では、この詳細情報を受け入れて、NTLM チャレンジをクライアントに送信します。
  5. クライアントは、チャレンジに対する応答 (この場合も認証トークン) を使用して応答します。この応答は、ユーザーのパスワードで暗号化されます。
  6. この時点で、IIS ではドメイン コントローラーと通信する必要があります。IIS では、クライアントのユーザー名、チャレンジ、およびチャレンジ応答を送信します。
  7. ドメイン コントローラーでは、ユーザーのパスワード ハッシュを取得し、このハッシュを、ユーザーの資格情報で暗号化されているチャレンジ応答と比較します。一致するものがあった場合、ドメイン コントローラーでは、成功した認証を IIS に返し、IIS ではクライアント ブラウザーと通信できるようになります。
  8. この時点で、Web アプリケーションでは、SQL Server との認証を行い、.aspx ページのデータを保持しているコンテンツ データベースにアクセスできるようになります。

基本インストールのサーバーの全体管理 Web ページで Kerberos を構成したことがあればご存じだと思いますが、NTLM の代わりに Kerberos を選択すると、アプリケーション プールが Network Service のコンテキストで実行されていない限り、アプリケーション プール アカウントを構成して Kerberos を明示的に許可することを求めるメッセージが表示されます。これは、Kerberos ベースの認証が SPN を要求するときの動作に原因があります。WSS と MOSS のどちらでも、Web アプリケーションの実体は、組み込みアカウントまたはユーザー アカウントのコンテキストで実行されるアプリケーション プールに割り当てられた IIS Web サイトです。ベスト プラクティスではありませんが、複数の Web サイトを同じアプリケーション プールに割り当てることは可能です。ユーザーが変更しない限り、IIS では、一意のドメイン アカウントではなく、Network Service アカウントをアプリケーション プールで使用します。ただし、Kerberos を SharePoint で使用できるようにするには、アプリケーション プール アカウントに一意の SPN を設定する必要があります。

実際、Kerberos ベースの通信は、Kerberos をサポートするクライアントとサーバー、中間の認証システムとして機能する KDC、および SPN を利用することで成立しています。技術的な詳細は、少し複雑になります。たとえば、Kerberos には、Active Directory に統合された DNS、または SRV レコード、TCP/IP、タイム サービスを使用する BIND のどちらかが必要です。Windows Server 2003 または Windows Server 2008 で統合 DNS を使用している場合は、おそらく必要なコンポーネントは既にインストールされているため、必要は作業はそれらのコンポーネントを構成するだけです。図 3 に、SharePoint で Kerberos ベースの認証を行う場合に必要な各種コンポーネントとデータ フローを示します。

 


図 3 Kerberos 認証

  1. NTLM の場合と同様に、クライアント ブラウザーでは、ホスト名 (FQDN またはエイリアス) を使用して、匿名で HTTP GET 要求を発行します。
  2. フロントエンド サーバーでは、401.2 エラーと、WWW-Authenticate: Negotiate ヘッダーおよびWWW-Authenticate: Kerberos ヘッダーを使用して応答します (後者は、サーバーが Kerberos 認証をサポートすることを示します)。後で説明しますが、これは、サーバーの全体管理を使用して、フロントエンド サーバーで明示的に構成する必要があります。
  3. クライアントでは、ドメイン コントローラーの KDC に接続し、ブラウザー クライアントがホスト名として送信した内容に基づいて SPN のチケットを要求します。
  4. KDC では、一致する SPN を検出すると、チケットを暗号化して返します。
  5. ブラウザー クライアントでは、認証子を作成し、これをサービス チケットと併せて IIS サーバーに送信します。IIS サーバーでは、チケットの暗号化を解除し、ID を特定して、要求されたリソースのアクセス許可 (アクセス制御リスト) をチェックして、アクセスが許可されているかどうかを確認します。
  6. アクセスが許可されている場合、IIS では、Web アプリケーション サービス経由で SQL Server に接続し、Web アプリケーション サービスでは KDC に対して SQL Server のチケットを要求します。
  7. SPN が検出されると、KDC では、チケットを返します。Web アプリケーションでは、チケットを使用してコンテンツ データベースにクエリを発行し、委任を使用してユーザーを偽装します。
  8. SQL Server は、Web アプリケーションから渡されたチケットをチェックして検証します。検証が成功すると、SQL Server では、データをサーバーに送信し、.NET では aspx ページをコンパイルしてブラウザーに送信できるようになります。

SPN について

SPN は、特定のサーバー リソースへのアクセスが承認されているクライアント リソースの一意の ID として KDC に登録されるため、Kerberos 構成の中で扱い難い要素の 1 つです。統合 Windows 認証では、多くの場合、KDC はドメイン コントローラーでもあるため、クライアントとサーバーのどちらでも自動的に KDC を信頼します。KDC には、要求に対してチケットを付与するかどうかを決定する手段が必要ですが、これが SPN です。前述のとおり、アプリケーション プールにドメイン ユーザー アカウントを設定する場合は、これに SPN を設定して、そのアプリケーション プールに関連付けられている Web アプリケーションにユーザーがアクセスできるようにする必要もあります。

SPN は、サーバーで実行されるサービスに与えられる一意の ID 文字列です。これは、Active Directory の Service-Principal-Name というユーザー アカウントの複数値を持つ属性に格納されています。特定のホストまたは複数のホストで実行されている複数のサービスは、各サービスの一意の SPN によって区別されます。SPN の重要性について強調しすぎているかもしれませんが、これには正当な理由があります。SPN を適切に構成しないと、Kerberos 認証が実行できなくなります。同じ SPN を 2 つ設定したり、SPN を設定し忘れたり、SPN の一部の設定を誤って構成すると、Kerberos 認証は機能しません。

SPN のサンプルを使用して、Kerberos で SPN がどのように使用されるかを確認しましょう。SPN は、3 つの部分で構成されています。サービスの種類を識別するサービス クラス、サービスが実行されるホストのコンピューター名、およびポートの 3 つです。これらの構成要素を組み合わせる構文は "<サービス クラス>/<ホスト>: <ポート>" です。SharePoint の場合、関連のある名前は HTTP と MSSqlSvc の 2 つです。サービス名は任意ではなく、サービス固有のエイリアスを使用して定義されます。ホスト名の部分には FQDN または NetBIOS 名を使用し、必要に応じて、ポートを指定します。SPN を登録する際のベスト プラクティスは、NetBIOS と FQDN ホスト名の両方に SPN を登録して、クライアントが使用する方法に関係なく、ホストのリソースにクライアントがアクセスできるようにすることです。

このコラムの前半では、Network Service アカウントでアプリケーション プールを実行していない限り、明示的に SPN を登録する必要があると書きました。これは、コンピューターが Active Directory ドメインに参加するときに、HOST/<NetBIOS 名> および HOST/<FQDN> という形式で、そのコンピューター アカウント用に SPN が自動的に作成されるためです。Network Service アカウントは、ネットワーク上のコンピューターとして機能するため、SPN はこのアカウントに対して有効です。ただし、ローカルの Network Service アカウントを使用することは、セキュリティ上の問題があり、一部のシナリオで障害となる可能性があるため、お勧めしません。たとえば、Network Service アカウントが構成されているコンテンツ データベースを復元またはアタッチする場合、そのアカウントを SQL Server のローカル Administrators グループに追加し、データベースをアタッチし終えたら、アカウントを削除する必要があります。既存のドキュメントの大半では、ドメイン アカウントの使用が推奨されています。

バックエンドの構成

既存のファームから移行する場合でも、新しいファームをインストールする場合でも、まず、SQL Server で Kerberos 認証を構成する必要があります。SQL Server では、ドメインに参加している、KDC の役割を兼任しているドメイン コントローラーにアクセスできるなど、既に説明した要件を満たしている必要があります。Active Directory を統合 DNS と共に使用している場合、多くの環境では、既定で、これらの要件のほとんどが満たされています。環境でフロントエンドの SharePoint サーバーしか使用されておらず、Excel Services や SQL Reporting Services を実行するサーバーなど、アプリケーション サーバーがない場合は、Kerberos を明示的に構成する必要はありません。基本のフロントエンド接続とバックエンド接続では、SQL Server のドメイン参加時に作成される既定の SPN で十分です。

SQL Server では、比較的簡単に Kerberos を構成できます。まず、関連する SPN を設定してから、既定の NTLM ではなく、Kerberos が使用されていることを確認します。NetBIOS 名と FQDN を "MSSQLSvc/<NetBIOS 名>:1433" および "MSSQLSvc//<FQDN-ホスト名.ドメイン.ローカル>:1433" という形式で設定します (インスタンスが既定のポート 1433 を使用している場合を想定しています)。SPN の設定には setspn ツールまたは ADSIEdit を使用できますが、setspn では入力した構文を検証して構文が正しいかどうかが検証されるため、多くの場合は setspn の方が便利です。一方、ADSIEdit では、SPN を直接 servicePrincipalName 属性に書き込みます。2 つの SPN を作成するには、「setspn-A MSSQLSvc/<NetBIOS 名>:1433 <ドメイン>\<ユーザー名>」および「setspn-A MSSQLSvc/<FQDNe>:1433 <ドメイン>\<ユーザー名>」というコマンドを実行します (このとき、ユーザー名には SQL Server サービス アカウントを指定します)。

SQL Server トラフィックで Kerberos が使用されていることを確認するには、Wireshark などのパケット アナライザーを使用してトラフィックを追跡したり、Kerbtray.exe などのツールを使用したり、イベント ログを確認したりします。SQL Server Management Studio を使用して SQL Server のインスタンスに接続する場合は、セキュリティ イベント ログにイベント ID 540 が記録されます。このイベントでは、ログオン プロセスと認証パッケージで Kerberos を使用します。詳細については、「SQL 通信の Kerberos 認証を構成する」を参照してください。

フロントエンドとアプリケーション サーバーの構成

Kerberos が SQL Server で機能していることを確認したら、SharePoint の構成に移ります。それには、アプリケーション プールの SPN を設定し、SSP と Web アプリケーションで Kerberos を有効にして、いくつかの最終的な構成手順を完了します。SPN の構成は、SQL Server サービス アカウントの構成と似ていますが、より多くの SPN を構成します。SPN は、ユーザーがクライアント ブラウザーのアドレス バーに入力した内容に基づいて構成されるため、ユーザーがサイトにアクセスするために、アドレス バーに入力する可能性がある各エントリに対して SPN を設定する必要があります。これには、FQDN、NetBIOS 名、およびホスト ヘッダー形式のエイリアスが含まれます。図 4 に、リソースの種類の例と、各リソースに登録する必要がある SPN を示します。

 

図 4 基本の MOSS ファームの SPN

 

SPN を設定するときに、いくつか覚えておくべきことがあります。1 つ目は、IIS Web サイトの場合と同様に、SPN が、SharePoint に対応している Web サイトに登録されることです。各サイトでアプリケーション プールの実行に使用される適切なホスト名とアカウントを指定することが重要です。複数のホスト ヘッダーを使用している場合は、すべてのホスト ヘッダーに SPN が設定されるようにします。2 つ目は、HTTP ポートと HTTPS ポートを指定する必要はありませんが、カスタム ポートは指定する必要があるということです。3 つ目は、カスタム ポートでの SPN の生成をサポートするための IIS のレジストリ変更や、SSP をサポートするための更新など、構成が必要な依存関係が他にもいくつかあることです。詳細については、「Kerberos 認証を構成する (Office SharePoint Server)」を参照してください。

SharePoint 環境で Kerberos が機能するためには、後 2 つの手順を完了する必要があります。1 つは、コンピューター アカウントといくつかのサービス アカウントを委任のために構成することで、もう 1 つは、サーバーの全体管理を使用して、Kerberos が機能するようにファームを構成することです。Kerberos における委任の概念は、ユーザーが最終目的のリソースに対して要求を行い、中間アカウントがその要求を処理する必要がある場合、中間アカウントはユーザーの委任先として信頼できるというものです。アカウントで委任を構成するには、ドメイン管理者として Active Directory ユーザーとコンピューターを使用します。ユーザー アカウントまたはコンピューター アカウントの [委任] タブで、[任意のサービスへの委任でこのユーザーを信頼する (Kerberos のみ)] チェック ボックスまたは [任意のサービスへの委任でこのコンピューターを信頼する (Kerberos のみ)] チェック ボックスをオンにします。フロントエンド、アプリケーション、および SQL Server のコンピューター アカウント、アプリケーション プール (SSPAdmin、MySite、各種 Web アプリケーション)、およびファームのサービス アカウントで委任を有効にします。

また、コンポーネント サービスでアクセス許可を設定する必要もあります。[既定のプロパティ] の [偽装レベル] を [委任] に設定します。IIS WAMREG Admin Service で [セキュリティ] タブに移動し、"ローカルからのアクティブ化" アクセス許可をアプリケーション プール アカウントに付与します。詳細については、マイクロソフト サポート技情報の記事 917409 および 920783 (英語) を参照してください。

委任を有効にしたら、SSP と Web アプリケーションの優先プロトコルとして Kerberos を有効にして、構成の詳細設定のしあげをします。新規インストールの場合は、SharePoint 製品とテクノロジ構成ウィザードのサーバーの全体管理サイトのページで、これを構成できます。新規インストールでない場合は、サーバーの全体管理で [アプリケーション構成の管理] の [認証プロバイダ] に移動し、[既定値] をクリックして、認証方法を [ネゴシエート (Kerberos)] に設定します。設定を変更したら、iisreset /noforce というコマンドを実行してアプリケーション プールに変更を適用して、SSP で Kerberos を有効にします。

IIS 7 と Windows Server 2008 の変更点

ここまでは、基本的に Windows Server 2003 と IIS 6.0 の環境で SharePoint 2007 実行する場合に限って説明しました。Windows Server 2008 と IIS 7.0 の環境に移行する場合は、追加の構成手順が必要になる、アーキテクチャ上の変更がいくつかあります。おそらく、最も注目すべき変更は、IIS 7.0 でカーネル モードの Kerberos 認証がサポートされていることです。カーネル モードの認証では、特にユーザーの指定がない限り、Network Service アカウント (実際には、前述のとおり、コンピューター アカウントと同じです) によってチケットが暗号化されます。カーネル モードの認証は、IIS 7.0 に移行するか新しいファームをインストールすると、既定で有効になります。ただし、Network Service アカウントはローカル アカウントであることに注意してください。サーバーを 1 台しか実行していない場合、暗号化は機能します。しかし、ファーム環境では、KDC に対して検証できるドメイン アカウントを使用する必要があるため、この暗号化は機能しません。また、Network Service アカウントには、既に LocalSystem 特権があるため、この変更の結果、Network Service アカウントを使用してプロトコルの遷移が実現できるようにもなりました (クライアントでは IIS に対して非 Kerberos 認証を使用し、IIS ではバックエンド通信に Kerberos を使用できます)。

IIS 7.0 を実行している SharePoint ファームで Kerberos を構成するには、%WinDir%\System32\inetsrv\config\ApplicationHost.config ファイルを手動で変更する必要があります。現時点では、GUI は提供されていません。関連のあるエントリは、次のとおりです。

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

iisreset /noforce コマンドを実行して変更を適用し、サポート技術情報の記事 962943 (英語) で説明されているブルー スクリーン エラーに対応する更新プログラムなど、問題を修正する最新の更新プログラムがあるかどうかを確認します。

構成で ID の偽装を使用し (web.config ファイルで <identity impersonate="true" /> が設定されている)、統合モード パイプラインを使用している場合は、もう 1 つ注意が必要な構成の詳細設定があります。この場合、validateIntegratedModeConfiguration に false を設定するか、.aspx ページをクラシック モード パイプラインで実行する必要があります。

まとめ

Kerberos 認証を使用するには、追加の構成作業と NTLM で必要とされる以上の知識が必要になりますが、現在は Kerberos へ移行することをお勧めします。IIS 7.0 では、Kerberos を有効にするかどうかを既定で確認するようになっています。また、これはオープン スタンダードであるため、概して強力なサポートが提供されています。Kerberos は使用するだけの価値があります。展開、検証、およびトラブルシューティングについてのドキュメントも豊富にあります。これも、Kerberos を検討するうえで、有利な要素です。大幅な変更を加えなくても、過剰な認証ホップに起因するパフォーマンスの問題を解決し、Kerberos によるセキュリティのメリットを享受できます。

 

Pav Cherny は、主にコラボレーションとユニファイド コミュニケーションに関するマイクロソフト テクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイト ペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズ サービスの専門企業 Biblioso Corporation の代表取締役です。

 

関連コンテンツ