レポートサーバーで Windows 認証を構成する

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

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

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

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

重要

ドメインユーザーアカウントで実行するようにレポートサーバーサービスを構成し、アカウントのサービスプリンシパル名 (SPN) を登録しなかった場合、 RSWindowsNegotiate を使用すると Kerberos 認証エラーが発生します。詳細については、このトピックの「レポートサーバーに接続するときの Kerberos 認証エラーの解決」を参照してください。
ASP.NET は Windows 認証用に構成する必要があります。既定では、レポートサーバー Web サービスとレポートマネージャーの Web.config ファイルには、 <認証モード ="Windows"> 設定が含まれます。 <認証モード="フォーム">に変更すると、Reporting Services の Windows 認証は失敗します。
レポートサーバー Web サービスとレポートマネージャーの Web.config ファイルには、<identity impersonate= "true"> の設定が必要です。
クライアントアプリケーションまたはブラウザーは、Windows 統合セキュリティをサポートしている必要があります。

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

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

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

認証の拡張保護 (Extended Protection for Authentication)

SQL Server 2008 R2 以降では、認証の拡張保護のサポートを利用できます。 SQL Server 機能により、認証の拡張保護に対するチャネルバインドとサービスバインドの使用がサポートされます。 Reporting Services の機能は、拡張保護をサポートするオペレーティングシステムで使用する必要があります。拡張保護のための Reporting Services の構成は、RSReportServer.config ファイルの設定によって決まります。ファイルは、ファイルを編集するか、WMI API を使用して更新できます。詳細については、「 Reporting Services を使用した認証の拡張保護」を参照してください。

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

テキストエディターで RSReportServer.config を開きます。
< Authentication >を見つけます。
ニーズに最も適した次の XML 構造のいずれかをコピーします。 RSWindowsNegotiate、RSWindowsNTLM、RSWindowsKerberosは任意の順序で指定できます。個々の要求ではなく、接続を認証する場合は、認証の永続化を有効にする必要があります。認証の永続化では、認証を必要とするすべての要求が接続の間許可されます。

最初の XML 構造は、レポートサーバーサービスアカウントが NetworkService または LocalSystem である場合の既定の構成です。
```
<Authentication>  
      <AuthenticationTypes>  
             <RSWindowsNegotiate />  
      </AuthenticationTypes>  
      <EnableAuthPersistence>true</EnableAuthPersistence>  
</Authentication>  
```
2 番目の XML 構造は、レポートサーバーサービスアカウントが NetworkService または LocalSystem でない場合の既定の構成です。
```
<Authentication>  
      <AuthenticationTypes>  
             <RSWindowsNTLM />  
      </AuthenticationTypes>  
      <EnableAuthPersistence>true</EnableAuthPersistence>  
```
</認証>

3 番目の XML 構造では、Windows 統合セキュリティで使用されるすべてのセキュリティパッケージを指定します。
```
      <AuthenticationTypes>  
             <RSWindowsNegotiate />  
             <RSWindowsKerberos />  
             <RSWindowsNTLM />  
      </AuthenticationTypes>  
```
4 番目の XML 構造体では、Kerberos をサポートしていない展開または Kerberos 認証エラーを回避する展開にのみ NTLM を指定します。
```
      <AuthenticationTypes>  
             <RSWindowsNTLM />  
      </AuthenticationTypes>  
```
< Authentication >の既存のエントリに貼り付けます。

RSWindows型ではCustomを使用できないことに注意してください。
必要に応じて、拡張保護の設定を変更します。拡張保護は既定で無効になっています。これらのエントリが存在しない場合、現在のコンピューターが、拡張保護をサポートするバージョンの Reporting Services を実行していない可能性があります。詳細については、「 Extended Protection for Authentication with Reporting Services」をご覧ください。
```
      <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>  
      <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>  
```
ファイルを保存します。
スケールアウト配置を構成した場合は、展開内の他のレポートサーバーに対してこれらの手順を繰り返します。
レポートサーバーを再起動して、現在開いているセッションを消去します。

レポートサーバーに接続するときの Kerberos 認証エラーの解決

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

レポートサーバーサービスは Windows ドメインユーザーアカウントとして実行され、アカウントのサービスプリンシパル名 (SPN) を登録しませんでした。
レポートサーバーは、 RSWindowsNegotiate 設定で構成されます。
ブラウザーは、レポートサーバーに送信する要求の認証ヘッダーで NTLM 経由で Kerberos を選択します。

Kerberos ログを有効にした場合は、エラーを検出できます。このエラーのもう 1 つの症状は、資格情報の入力を複数回求められた後、空のブラウザーウィンドウが表示されるということです。

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

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

ドメインユーザーアカウントでレポートサーバーサービスの SPN を登録します。詳細については、「レポートサーバーのサービスプリンシパル名 (SPN) を登録する」を参照してください。
ネットワークサービスなどの組み込みアカウントで実行するようにサービスアカウントを変更します。組み込みアカウントは、HTTP SPN をホスト SPN にマップします。これは、コンピューターをネットワークに参加させるときに定義されます。詳細については、「サービスアカウントの構成 (SSRS 構成マネージャー)」を参照してください。
NTLM を使用します。 NTLM は通常、Kerberos 認証が失敗した場合に機能します。 NTLM を使用するには、RSReportServer.config ファイルから RSWindowsNegotiate を削除し、 RSWindowsNTLM のみが指定されていることを確認します。この方法を選択した場合は、SPN を定義していない場合でも、レポートサーバーサービスのドメインユーザーアカウントを引き続き使用できます。

ログ情報

Kerberos 関連の問題の解決に役立つログ情報には、いくつかのソースがあります。

User-Account-Control 属性

Reporting Services サービスアカウントに Active Directory に十分な属性が設定されているかどうかを確認します。 Reporting Services サービスのトレースログファイルを確認して、UserAccountControl 属性に対してログに記録された値を見つけます。ログに記録される値は 10 進形式です。 10進数の値を16進数形式に変換し、その値をユーザー-Account-Control属性を説明するMSDNトピックで見つける必要があります。

Reporting Services サービスのトレースログエントリは、次のようになります。

appdomainmanager!DefaultDomain!8f8!01/14/2010-14:42:28:: i INFO: The UserAccountControl value for the service account is 590336

10 進数の値を 16 進数形式に変換するオプションの 1 つは、Microsoft Windows 電卓です。 Windows 電卓では、"Dec" オプションと "Hex" オプションを表示するいくつかのモードがサポートされています。 [12 月] オプションを選択し、ログファイルで見つかった 10 進値を貼り付けるか入力し、[Hex] オプションを選択します。
次に、「 User-Account-Control 属性」トピックを参照して、サービスアカウントの属性を派生させます。

Reporting Services サービスアカウント用に Active Directory で構成された SPN。

Reporting Services サービスのトレースログファイルに SPN を記録するには、Reporting Services 拡張保護機能を一時的に有効にします。

次を設定して、構成ファイル rsreportserver.config を変更します。

<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>   
<RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>

Reporting Services サービスを再開します。

拡張保護を引き続き使用しない場合は、構成値を既定値に戻し、Reporting Services サービスアカウントを再起動します。

<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>  
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

詳細については、「Reporting Services を使用した認証の拡張保護」を参照してください。

ブラウザーがネゴシエートされた Kerberos またはネゴシエートされた NTLM を選択する方法

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

要求はローカルレポートサーバーに送信されます。
要求は、ホストヘッダーまたはサーバー名ではなく、レポートサーバーコンピューターの IP アドレスに送信されます。
ファイアウォールソフトウェアは、Kerberos 認証に使用されるポートをブロックします。
特定のサーバーのオペレーティングシステムで Kerberos が有効になっていません。
ドメインには、新しいバージョンのオペレーティングシステムに組み込まれている Kerberos 認証機能をサポートしていない古いバージョンの Windows クライアントおよびサーバーオペレーティングシステムが含まれています。

さらに、Internet Explorer では、URL、LAN、およびプロキシ設定の構成方法に応じて、ネゴシエートされた Kerberos または NTLM のいずれかを選択できます。

レポートサーバーの URL

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

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

Internet Explorer で設定した LAN とプロキシの設定によって、Kerberos 経由で NTLM が選択されているかどうかを判断できます。ただし、LAN とプロキシの設定は組織によって異なるため、Kerberos 認証エラーの原因となる正確な設定を正確に判断することはできません。たとえば、組織では、イントラネット URL からインターネット接続経由で解決される完全修飾ドメイン名 URL に URL を変換するプロキシ設定を適用できます。異なる種類の URL に対して異なる認証プロバイダーが使用されている場合は、一部の接続が失敗すると予想される場合に成功することがあります。

認証エラーが原因と思われる接続エラーが発生した場合は、LAN とプロキシ設定のさまざまな組み合わせを試して問題を特定できます。 Internet Explorer の LAN とプロキシの設定は、[ローカルエリアネットワーク (LAN) の設定] ダイアログボックスに表示され、[インターネットオプション] の [接続] タブの [LAN 設定] をクリックして開きます。

外部リソース

Kerberos とレポートサーバーの詳細については、「SharePoint、Reporting Services、および PerformancePoint Monitoring Server と Kerberos を使用したビジネスインテリジェンスソリューションの展開」を参照してください。

こちらもご覧ください

レポートサーバーでの認証
 ネイティブモードのレポートサーバーに対する権限の許可
 RSReportServer 構成ファイル
 レポートサーバーで基本認証を構成する
 レポートサーバーでカスタム認証またはフォーム認証を構成する
 Reporting Services での認証の拡張保護

Last updated on 2017-06-13

次の方法で共有

レポート サーバーで Windows 認証を構成する