• [アーティクル]

Reporting Services で Windows 認証を構成する方法

Reporting Services は、既定では、ネゴシエート認証または NTLM 認証を指定する要求を受け入れます。これらのセキュリティ プロバイダを使用するクライアント アプリケーションおよびブラウザが配置に含まれている場合は、追加の構成なしで既定値を使用できます。Windows 統合セキュリティの別のセキュリティ プロバイダを使用する場合 (たとえば Kerberos を直接使用する場合)、または既定値を変更した後に元の設定を復元する場合は、このトピックの情報を使用して、レポート サーバーで認証設定を指定できます。

Windows 統合セキュリティを使用するには、レポート サーバーにアクセスする必要がある各ユーザーに、有効な Windows ローカル ユーザー アカウントまたはドメイン ユーザー アカウントを割り当てるか、そのユーザーを Windows ローカル グループ アカウントまたはドメイン グループ アカウントのメンバにする必要があります。信頼されている他のドメインのアカウントを含めることもできます。このアカウントは、レポート サーバー コンピュータにアクセスできる必要があります。また、レポート サーバーの特定の操作を実行できるように、後でこのアカウントをロールに割り当てる必要があります。

次の追加要件も満たす必要があります。

  • RSReportServer.config ファイルの AuthenticationType が、RSWindowsNegotiate、RSWindowsKerberos、または RSWindowsNTLM に設定されている必要があります。レポート サーバー サービス アカウントが NetworkService または LocalSystem である場合、RSReportServer.config ファイルには、既定で RSWindowsNegotiate 設定が含まれます。それ以外の場合は、RSWindowsNTLM 設定が使用されます。Kerberos 認証のみを使用するアプリケーションがある場合は、RSWindowsKerberos を追加できます。

    重要な注意事項重要

    レポート サーバー サービスをドメイン ユーザー アカウントで実行するように構成し、かつそのアカウントのサービス プリンシパル名 (SPN) を登録していない場合は、RSWindowsNegotiate を使用すると Kerberos 認証エラーが発生します。詳細については、このトピックの「レポート サーバー接続時の Kerberos 認証エラーの解決」を参照してください。

  • ASP.NET で Windows 認証を構成する必要があります。既定では、レポート サーバー Web サービスおよびレポート マネージャの Web.config ファイルに、<authentication mode="Windows"> が設定されます。この設定を <authentication mode="Forms"> に変更すると、Reporting Services の Windows 認証が失敗します。

  • レポート サーバー Web サービスおよびレポート マネージャの Web.config ファイルに、<identity impersonate= "true" /> が設定されている必要があります。

  • クライアント アプリケーションまたはブラウザが、Windows 統合セキュリティをサポートしている必要があります。

レポート サーバーの認証設定を変更するには、RSReportServer.config ファイルの XML 要素と値を編集する必要があります。特定の組み合わせを実装するために、このトピックの例をコピーして貼り付けることもできます。

既定の設定は、すべてのクライアント コンピュータとサーバー コンピュータが同じドメインまたは信頼されているドメインにあり、かつレポート サーバーがイントラネット アクセス用に企業のファイアウォールの内側に配置されている場合に最も適しています。Windows 資格情報を渡すには、ドメインが信頼されていて単一であることが必要です。サーバーで Kerberos Version 5 プロトコルを有効にした場合は、資格情報を複数回渡すことができます。それ以外の場合は、資格情報をその有効期限が切れる前に 1 回だけ渡すことができます。複数のコンピュータ接続に対する資格情報の構成の詳細については、「レポート データ ソースに関する資格情報と接続情報の指定」を参照してください。

次に示す手順は、ネイティブ モードのレポート サーバーを対象としています。レポート サーバーを SharePoint 統合モードで配置する場合は、Windows 統合セキュリティを指定する既定の認証設定を使用する必要があります。レポート サーバーでは、既定の Windows 認証拡張機能の内部機能を使用して、SharePoint 統合モードのレポート サーバーがサポートされます。

レポート サーバーを構成して Windows 統合セキュリティを使用するには

  1. テキスト エディタで RSReportServer.config を開きます。

  2. <Authentication> を探します。

  3. 次に示す XML 構造の中でニーズに最も合うものをコピーします。RSWindowsNegotiate、RSWindowsNTLM、および RSWindowsKerberos は、任意の順序で指定できます。個々の要求ではなく接続を認証する場合は、認証の永続化を有効にする必要があります。認証の永続化を有効にすると、接続が続いている間は、認証を必要とするすべての要求が許可されます。

    1 番目の XML 構造は、レポート サーバー サービス アカウントが NetworkService または LocalSystem である場合の既定の構成です。

    <Authentication>
      <AuthenticationTypes>
             <RSWindowsNegotiate />
      </AuthenticationTypes>
      <EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>

    2 番目の XML 構造は、レポート サーバー サービス アカウントが NetworkService と LocalSystem のいずれにも該当しない場合の既定の構成です。

    <Authentication>
      <AuthenticationTypes>
             <RSWindowsNTLM />
      </AuthenticationTypes>
      <EnableAuthPersistence>true</EnableAuthPersistence>

    </Authentication>

    3 番目の XML 構造は、Windows 統合セキュリティで使用されるすべてのセキュリティ パッケージを指定します。

          <AuthenticationTypes>
             <RSWindowsNegotiate />
             <RSWindowsKerberos />
             <RSWindowsNTLM />
      </AuthenticationTypes>

    4 番目の XML 構造は、配置が Kerberos をサポートしていない場合、または Kerberos 認証エラーに対処する場合にのみ、NTLM を指定します。

          <AuthenticationTypes>
             <RSWindowsNTLM />
      </AuthenticationTypes>

  4. これを <Authentication> の既存のエントリ上に貼り付けます。

    RSWindows の各種類と Custom は併用できないので注意してください。

  5. ファイルを保存します。

  6. スケールアウト配置を構成した場合は、配置内の他のレポート サーバーに対して上記の手順を繰り返します。

  7. レポート サーバーを再起動して、現在開いているセッションを消去します。

レポート サーバー接続時の Kerberos 認証エラーの解決

ネゴシエート認証または Kerberos 認証が構成されているレポート サーバーでは、Kerberos 認証エラーが発生すると、レポート サーバーへのクライアント接続が失敗します。Kerberos 認証エラーは、次の場合に発生します。

  • サービス プリンシパル名 (SPN) を登録していない Windows ドメイン ユーザー アカウントでレポート サーバー サービスが実行されたとき。

  • レポート サーバーが RSWindowsNegotiate 設定で構成されているとき。

  • ブラウザがレポート サーバーに送信する要求の認証ヘッダーで、NTLM ではなく Kerberos が選択されたとき。

Kerberos のログ記録を有効にしていれば、エラーを検出できます。資格情報の入力を複数回要求された後に空のブラウザ ウィンドウが表示された場合も、エラーが発生しています。

Kerberos 認証エラーが発生していることを確認するには、構成ファイルから < RSWindowsNegotiate /> を削除し、接続を再試行します。

問題を確認したら、次の方法で問題に対処できます。

  • ドメイン ユーザー アカウントでレポート サーバー サービスの SPN を登録します。詳細については、「レポート サーバーのサービス プリンシパル名 (SPN) を登録する方法」を参照してください。

  • ネットワーク サービスなどのビルトイン アカウントで実行されるように、サービス アカウントを変更します。ビルトイン アカウントは、HTTP SPN を Host SPN にマップします。これは、コンピュータをネットワークに追加するときに定義されます。詳細については、「Reporting Services のサービス アカウントを構成する方法」を参照してください。

  • NTLM を使用します。NTLM は一般に、Kerberos 認証が失敗した場合に機能します。NTLM を使用するには、RSReportServer.config ファイルから RSWindowsNegotiate を削除し、RSWindowsNTLM のみが指定されていることを確認します。この方法を選択すれば、SPN を定義していないドメイン ユーザー アカウントでも、引き続きレポート サーバー サービスに使用できます。

ネゴシエートされた Kerberos またはネゴシエートされた NTLM がブラウザで選択されるしくみ

Internet Explorer を使用してレポート サーバーに接続すると、認証ヘッダーでネゴシエートされた Kerberos または NTLM が指定されます。次の場合は、Kerberos に代わって NTLM が使用されます。

  • 要求がローカル レポート サーバーに送信された場合。

  • 要求が、ホスト ヘッダーまたはサーバー名ではなく、レポート サーバー コンピュータの IP アドレスに送信された場合。

  • Kerberos 認証に使用されるポートがファイアウォール ソフトウェアでブロックされた場合。

  • 特定のサーバーのオペレーティング システムで Kerberos が有効になっていない場合。

  • ドメインに含まれている古いバージョンの Windows クライアントおよびサーバー オペレーティング システムが、そのオペレーティング システムの新しいバージョンに組み込まれている Kerberos 認証機能をサポートしていない場合。

さらに Internet Explorer では、URL、LAN、およびプロキシの設定内容に応じて、ネゴシエートされた Kerberos または NTLM が選択されることがあります。

レポート サーバーの URL

URL に完全修飾ドメイン名が含まれている場合、Internet Explorer は NTLM を選択します。URL で localhost が指定されている場合も、Internet Explorer は NTLM を選択します。URL でコンピュータのネットワーク名が指定されている場合、Internet Explorer はネゴシエートを選択します。この認証は、レポート サーバー サービス アカウントに SPN が存在するかどうかによって成功または失敗します。

クライアントでの LAN とプロキシの設定

Internet Explorer での LAN とプロキシの設定によって、NTLM が Kerberos の代わりに選択されるかどうかが決まります。ただし、LAN とプロキシの設定は組織間で異なるため、Kerberos 認証エラーがどの設定に起因するかを正確に特定することは不可能です。たとえば所属する組織で、URL を、イントラネット URL から完全修飾ドメイン名 URL (インターネット接続経由で解決される URL) に変換するようなプロキシ設定が実施されているとします。種類の異なる URL に種類の異なる認証プロバイダが使用されると、失敗すると予想した接続が成功することがあります。

認証の失敗が原因と考えられる接続エラーが発生した場合は、問題の原因を特定するために、LAN とプロキシの設定の組み合わせを変えてみてください。Internet Explorer では、LAN とプロキシの設定を [ローカル エリア ネットワーク (LAN) の設定] ダイアログ ボックスで行います。このダイアログ ボックスを開くには、[インターネット オプション] の [接続] タブで [LAN の設定] をクリックします。