SSRSでレポートのセキュリティを変更した直後に「An error occurred when invoking the authorization extension.」というエラーが出てしまうと、突然レポートの管理メニューが消えてしまったり、ユーザーがアクセスできなくなったりするため戸惑いがちです。本記事では、その原因と具体的な解決策を詳しく解説します。
SSRSエラー「An error occurred when invoking the authorization extension.」とは
SSRS(SQL Server Reporting Services)は、Microsoft SQL Serverのレポート機能を構築・管理するためのプラットフォームです。通常、Windows認証によるアクセス制御や、SSRSが標準で提供するロール管理を用いてセキュリティを設定します。しかし、要件に応じてカスタムの認証・承認拡張(Authentication/Authorization Extension)を導入している場合、セキュリティ設定を誤って変更すると「Authorization Extension」呼び出し時にエラーが発生し、レポート管理機能やアクセス権に問題が生じるケースがあります。
このエラーが出ると「Manage folder」などの管理メニューが消えたり、一部ユーザーのアクセスが一切できなくなったりするため、管理者にとって深刻なトラブルとなるのが特徴です。特に「System.NullReferenceException」がログに見られる場合、拡張機能の内部コードでユーザーオブジェクトやロール情報を正しく取得できていない可能性があります。
エラーが発生しやすい典型的なシナリオ
SSRSにおけるエラーはさまざまな原因で発生するものの、以下のようなシナリオで特に問題が顕在化しやすいです。
1. レポートやフォルダーに独自の権限を付与・変更した直後
- 個別のレポート、あるいは特定のフォルダーにのみ新しいユーザーやロールを追加した際に、既存の「System Administrator」や「Content Manager」の権限が外れてしまうことがあります。
- 結果として、管理メニューが表示されない、既存ユーザーのアクセスが失われるなどの事象が起こり、エラーが多発します。
2. カスタムの承認拡張機能を導入している環境
- SSRSのデフォルト認証(Windows認証)ではなく、LDAPやデータベースの認証情報を利用するなど、独自にカスタマイズしている場合に発生しやすいです。
- ロール判定やユーザー情報の取得処理が空(null)になっているときや、不整合が起こったときに「NullReferenceException」を伴うエラーが頻発します。
3. 構成ファイルの編集・アップデート直後
- RSReportServer.configやRSSrvPolicy.configなど、SSRSの動作を制御する重要なファイルを直接編集したり、システムアップデート後に設定が上書きされたりすると、アクセス権の管理に不具合が生じる場合があります。
- また、複数台のWebサーバーでSSRSを運用している際に、一部のサーバーのみ設定が更新されていないなどの齟齬が起こることも問題の原因になります。
権限構造の再確認と変更の手順
エラーが起こった場合、まずはSSRSの標準ロールによる権限構造をしっかり把握することが重要です。SSRSには「サイトレベルのロール」と「アイテムレベルのロール」があり、それぞれに応じて設定を見直す必要があります。
1. ホームレベルとアイテムレベルの違い
SSRSの「サイトレベル(ホームレベル)」は、SSRSの管理全般を行うためのロールを割り当てる場所です。たとえば「System Administrator」や「System User」などが該当します。一方、フォルダーやレポートなどの「アイテムレベル」では「Content Manager」「Publisher」「Browser」などのロールを割り当てます。
以下の表は、SSRSにおけるロールの一例です。
レベル | ロール名 | 主な権限内容 |
---|---|---|
サイトレベル | System Administrator | サイト全体の管理(システム設定、ロールの作成・削除) |
サイトレベル | System User | サイト全体へのアクセス(閲覧)、アイテムレベルでの権限設定はなし |
アイテムレベル | Content Manager | レポートの作成・削除・管理メニューの表示など全般 |
アイテムレベル | Publisher | レポートの発行 |
アイテムレベル | Browser | レポートの閲覧のみ |
もし管理者自身が「Site Settings(サイト設定)」で「System Administrator」を外されてしまった場合、ホーム画面の管理機能が消えてしまい、さらにアイテムレベルを変更する権限も失われてしまいます。まずはサイトレベルのロールが正しく割り当てられているかどうかを確認しましょう。
【チェックポイント】
- サイト設定(「Site Settings」)の「Security」で、Administratorアカウントや必要なユーザーが「System Administrator」ロールに入っているか。
- フォルダーやレポートの「Manage Folder」「Manage Reports」メニューが表示されなくなっていないか。
2. アイテム単位の権限を再設定する
アイテム(フォルダー、レポート)ごとに権限を付与している場合、誤って管理ロールを解除してしまうと、アクセスできるはずのユーザーが排除されることがあります。確認方法としては、SSRSポータルで各フォルダーやレポートの「Manage」→「Security」を開き、誰にどのロールが割り当てられているかをチェックするのが基本的な手順です。
もしトラブルに陥って管理画面にアクセスできない場合は、サイトレベルで強制的に権限を付与する方法を検討してください。また、可能であれば一時的にデフォルトセキュリティに戻す(親フォルダーから継承を再度行う)ことで状況を改善できることもあります。
カスタム承認(Authorization)拡張機能の確認
標準のWindows認証ではなく、外部システムとの認証連携や独自認証を行っている場合、「An error occurred when invoking the authorization extension.」はカスタム拡張が原因である可能性が高いです。
1. 拡張機能の動作原理
SSRSのカスタム拡張機能では、以下のような仕組みでユーザー認証と承認を行います。
- ユーザーがSSRSポータルにアクセスした際に、拡張機能が呼び出され、認証プロセスを実行する。
- ユーザーがログインすると、SSRS内部におけるロール割り当てが動的に判断される。
- 承認プロセスが完了し、ユーザーが許可されたレポートや管理機能にアクセスできる。
もしセキュリティ設定の変更に伴い、拡張機能側のコードでユーザー情報が取得できなくなる(nullになる)と「System.NullReferenceException」が発生しやすくなります。例えば、拡張機能内部でユーザーのグループ情報を取得しようとした際に、グループ情報が存在しない、または対応テーブルが削除されているなどが考えられます。
2. カスタム拡張のデバッグ方法
カスタム拡張を導入している環境では、Visual Studioなどで拡張機能のDLLを開発していることが多いです。デバッグのポイントとしては、以下のようなステップがおすすめです。
- 拡張機能のプロジェクトをVisual Studio上で開き、例外ハンドリングのログ出力を強化する。
- SSRSのログ(通常、Reporting Servicesのログフォルダーに配置)と拡張機能が出力するログを両方確認し、エラーが発生する具体的な箇所を特定する。
- 必要に応じて拡張機能を一時的に無効化(またはデフォルトの認証に戻す)し、問題が再現するかどうかをテストする。
- 拡張機能内部でnullが返される原因がユーザー情報やロール判定ロジックにある場合は、該当箇所を修正する。
以下は、拡張機能内でユーザー情報を取得する際のイメージコード例です(C#)。実際の環境に合わせて書き換えてください。
public override string[] GetUserRoles(string userName)
{
// 例外対策のログ出力を追加
Logger.Write("GetUserRoles called with userName: " + userName);
if (string.IsNullOrEmpty(userName))
{
Logger.Write("userName is null or empty");
return new string[] { };
}
// ユーザー情報をデータベースなどから取得
var userData = userRepository.GetUserData(userName);
if (userData == null)
{
Logger.Write("userData is null for userName: " + userName);
throw new NullReferenceException("User data not found");
}
// 取得したデータを元にロールを決定
List<string> roles = new List<string>();
// 例: 管理者フラグが立っていればContent Managerを付与
if (userData.IsAdmin)
{
roles.Add("Content Manager");
}
else
{
roles.Add("Browser");
}
return roles.ToArray();
}
このように、nullとなる可能性のある箇所にログを仕込んで原因を特定し、ロールの割り当てが確実に行われるように修正することで、エラーの根本解決を図ります。
構成ファイルとログの詳細な調査
SSRSの設定ファイル(RSReportServer.configやRSSrvPolicy.configなど)やログをチェックすることも重要です。特に、拡張機能を導入している場合は「RSReportServer.config」にカスタムライブラリのパスやクラス名を設定しているはずです。
1. RSReportServer.configの確認ポイント
<Authentication>
または<Security>
のセクション内にカスタム拡張に関する設定があるか。<Extension Name="CustomSecurity">
のようなタグがあり、そこに正しいDLLパスやType(クラス名)が設定されているか。- 設定ファイルの変更履歴(バックアップ)を比較して、最近の変更点を洗い出す。
2. RSSrvPolicy.configの確認ポイント
- コードアクセスセキュリティ(CAS)ポリシーを編集している場合、拡張機能のアセンブリに対して適切なPermissionSetが付与されているか。
- SSRSのバージョンアップやセキュリティ更新プログラムの適用時にCASポリシーが上書きされた可能性がないか。
3. Reporting Servicesのログとイベントビューアの確認
- 通常、
<インストールパス>\Microsoft SQL Server\MSRSXX\Reporting Services\LogFiles
配下にログが保存されるケースが多いです(XXはバージョン番号)。 - ログに「An error occurred when invoking the authorization extension.」や「System.NullReferenceException」のスタックトレースが出ていないか。
- Windowsイベントビューアのアプリケーションログにも、SSRSや拡張機能に関するエラーが記録される場合があります。そちらも併せて確認してください。
エラー解消への具体的アプローチ
ここまで述べてきたポイントを踏まえ、エラー解消に向けた具体的な流れをまとめます。
1. サイトレベルとアイテムレベルのロール再割り当て
- 管理者ユーザーや必要なユーザーが「System Administrator」「Content Manager」などのロールを確実に持っていることを確認し、足りなければ再割り当てを行います。
- アクセスできないフォルダーやレポートがある場合は、継承設定をリセットして、必要最低限のロールを再度付与します。
2. 拡張機能のコード・設定を確認
- カスタム拡張を使用している場合は、拡張機能内でユーザーやロール情報が正しく取得できるように修正します。
- デバッグ時にログ出力を充実させ、どのタイミングでnullが返っているかを突き止めます。
3. 構成ファイルの整合性チェック
- RSReportServer.configやRSSrvPolicy.configのバックアップと比較し、変更点を特定します。
- 設定が不正になっている場合は元の状態に戻し、機能するかどうかをテストします。
4. サーバー全体の同期・再起動
- 負荷分散(ロードバランサー)構成などでSSRSを運用している場合は、全サーバーの設定を一致させます。
- 設定の変更後にReporting Servicesのサービス再起動が必要な場合は忘れずに実施します。
5. 公式ドキュメント・フォーラムでの情報収集
- Microsoft Q&Aや、Tech Communityなどのフォーラムで同様のエラー事例を参照します。
- 特定バージョンのSSRSで類似の既知の問題(不具合)が報告されている場合もあるため、サービスパックや累積アップデートの適用も検討します。
まとめ
SSRSで「An error occurred when invoking the authorization extension.」というエラーが発生すると、管理メニューが消えてしまったり、ユーザーがアクセスできなくなったりと大きな混乱を招きます。しかし、エラーの本質は「ロール設定や拡張機能内でユーザー情報が正しく扱われていない」場合がほとんどです。
特にカスタム承認機能を導入している環境では、セキュリティ設定を変更すると拡張機能内のコードでデータ取得がnullになることが多いため、拡張機能の動作をデバッグしながらロール割り当てを正しく修正する必要があります。また、RSReportServer.configなどの構成ファイルやサイトレベルとアイテムレベルのロール設定が整合性を保っているかを確認しましょう。
問題を根本から解決するには、SSRSのロールや承認拡張機能、構成ファイルの仕組みをよく理解し、ロール設定と拡張機能の両面を丁寧に見直すことが近道です。最終的には公式のドキュメントやフォーラムも活用しつつ、段階的に調整することでエラーを解消し、再度安定したレポート管理が行えるようになるでしょう。
コメント