Power BI サービスからオンプレミス データ ソースへの Kerberos ベースの SSO を構成する
SSO を有効にすると、Power BI レポートおよびダッシュボードでは、オンプレミスのソース上で構成されているユーザー レベルのアクセス許可を考慮しながら、それらのソースからのデータを簡単に更新できるようになります。 Kerberos の制約付き委任を使用して、シームレスな SSO 接続を有効にします。
この記事では、Power BI サービスからオンプレミスのデータ ソースへの、Kerberos ベースの SSO を構成するために必要な手順について説明します。
必須コンポーネント
Kerberos の制約付き委任が正しく機能するためには、*サービス プリンシパル名 (SPN) やサービス アカウントでの委任の設定など、いくつかの項目を構成する必要があります。
Note
SSO での DNS エイリアスの使用はサポートされていません。
構成の概要
ゲートウェイ シングル サインオンを構成するために必要な手順を以下に示します。
「セクション 1: 基本的な構成」のすべての手順を完了します。
Active Directory 環境と使用するデータ ソースに応じて、「セクション 2: 環境固有の構成」で説明されている構成の一部またはすべてが必要になります。
追加の構成が必要になる可能性があるシナリオを次に示します。
シナリオ 移動 Active Directory 環境のセキュリティが強化されている。 Windows 認証およびアクセス グループにゲートウェイ サービス アカウントを追加する ゲートウェイが偽装するゲートウェイ サービス アカウントとユーザー アカウントが別々のドメインまたはフォレストにある。 Windows 認証およびアクセス グループにゲートウェイ サービス アカウントを追加する ユーザー アカウントの同期が構成された Microsoft Entra Connect がなく、ユーザーの Power BI 内で使用されている UPN が、ローカルの Active Directory 環境内の UPN と一致しない。 ゲートウェイ コンピューターでユーザー マッピングの構成パラメーターを設定する SSO で SAP HANA データ ソースを使用する予定がある。 データソース固有の構成手順を完了する SSO で SAP BW データ ソースを使用する予定がある。 データソース固有の構成手順を完了する SSO で Teradata データ ソースを使用する予定がある。 データソース固有の構成手順を完了する 「セクション 3: 構成を検証する」の説明に従って構成を検証し、SSO が正しく設定されていることを確認します。
セクション 1: 基本的な構成
手順 1: Microsoft オンプレミス データ ゲートウェイをインストールして構成する
オンプレミス データ ゲートウェイでは、インプレース アップグレードと、既存のゲートウェイの "引き継ぎの設定" がサポートされています。
手順 2: SPN (SetSPN) および Kerberos の制約付き委任の設定を構成するためのドメイン管理者権限を取得する
SPN と Kerberos 委任の設定を構成するために、ドメイン管理者は、ドメイン管理者権限を持たないユーザーに権限を付与しないようにする必要があります。 次のセクションでは、推奨される構成手順について詳しく説明します。
手順 3: ゲートウェイ サービス アカウントを構成する
下記のオプション A が必要な構成ですが、Microsoft Entra Connect が構成されており、かつユーザー アカウントが同期されている場合は除きます。 その場合は、オプション B をお勧めします。
オプション A: SPN でゲートウェイの Windows サービスをドメイン アカウントとして実行する
標準のインストールでは、ゲートウェイは、マシンのローカル サービス アカウント NT Service\PBIEgwServiceとして実行されます。
Microsoft Entra インスタンスが既に (Microsoft Entra DirSync/Connect を使用して) ローカルの Active Directory インスタンスと同期されている場合を除き、Kerberos の制約付き委任を有効にするには、ゲートウェイをドメイン アカウントとして実行する必要があります。 ドメイン アカウントに切り替えるには、「ゲートウェイ サービス アカウントの変更」を参照してください。
ゲートウェイ サービス アカウントに SPN を構成する
最初に、ゲートウェイ サービス アカウントとして使われるドメイン アカウントに SPN が既に作成されているかどうかを調べます。
ドメイン管理者として、Microsoft 管理コンソール (MMC) スナップインの [Active Directory ユーザーとコンピューター] を起動します。
左側のペインでドメイン名を右クリックし、[検索] を選択して、ゲートウェイ サービス アカウントのアカウント名を入力します。
検索結果で、ゲートウェイ サービス アカウントを右クリックし、[プロパティ] を選択します。
[委任] タブが [プロパティ] ダイアログに表示される場合は、SPN は既に作成されているため、「Kerberos の制約付き委任を構成する」に進むことができます。
[委任] タブが [プロパティ] ダイアログ ボックスにない場合、アカウントに SPN を手動で作成し、有効にすることができます。 Windows に付属する setspn ツールを使用してください (SPN を作成するにはドメイン管理者権限が必要です)。
たとえば、ゲートウェイ サービス アカウントが Contoso\GatewaySvc で、ゲートウェイ サービスが MyGatewayMachine という名前のマシンで実行されているとします。 ゲートウェイ サービス アカウントの SPN を設定するには、次のコマンドを実行します。
setspn -S gateway/MyGatewayMachine Contoso\GatewaySvcまた、[Active Directory ユーザーとコンピューター] MMC スナップインを使用して、SPN を設定することもできます。
オプション B: Microsoft Entra Connect 用にコンピューターを構成する
Microsoft Entra Connect が構成済みで、かつユーザー アカウントが同期済みの場合、実行時にゲートウェイ サービスでローカル Microsoft Entra 参照を実行する必要はありません。 代わりに、単にゲートウェイ サービスのローカル サービス SID を使用して、Microsoft Entra ID 内で必要なすべての構成を完了することができます。 この記事で説明する Kerberos の制約付き委任の構成手順は、Microsoft Entra 内のコンテキストにおいて必要な構成手順と同じです。 それらは、ドメイン アカウントではなく、Microsoft Entra ID 内の (ローカル サービス SID によって識別された) ゲートウェイのコンピューター オブジェクトに適用されます。 NT SERVICE/PBIEgwService のローカル サービス SID は次のとおりです。
S-1-5-80-1835761534-3291552707-3889884660-1303793167-3990676079
Power BI のゲートウェイ コンピューターに対してこの SID の SPN を作成するには、管理コマンド プロンプトから次のコマンドを実行する必要があります (<COMPUTERNAME> を Power BI Gateway のコンピューター名に置き換えます)。
SetSPN -s HTTP/S-1-5-80-1835761534-3291552707-3889884660-1303793167-3990676079 <COMPUTERNAME>
Note
ローカルのセキュリティ設定によっては、ゲートウェイ マシンのローカルの Administrators グループにゲートウェイ サービス アカウント NT SERVICE\PBIEgwService を追加し、ゲートウェイ アプリでのゲートウェイ サービスの再起動が必要になる場合があります。 Active Directory ではフォレスト全体に一意の SPN が適用されるため、このオプションは、複数のゲートウェイがあるシナリオではサポートされていません。 このようなシナリオの場合は、代わりにオプション A を使用してください。
手順 4: Kerberos の制約付き委任を構成する
委任の設定は、標準の Kerberos の制約付き委任またはリソースに基づく Kerberos の制約付き委任のいずれかに対して構成することができます。 2 つの委任方法の違いの詳細については、「Kerberos の制約付き委任の概要」を参照してください。
次のサービス アカウントが必要です。
- ゲートウェイ サービス アカウント: 手順 3 で SPN が構成された Active Directory のゲートウェイを表すサービス ユーザー。
- データ ソース サービス アカウント: Active Directory のデータ ソースを表すサービス ユーザー。SPN がデータ ソースにマップされています。
注意
ゲートウェイとデータ ソース のサービス アカウントは別々である必要があります。 ゲートウェイとデータ ソースの両方を表すために、同じサービス アカウントを使用することはできません。
使用する方法に応じて、次のいずれかのセクションに進みます。 両方のセクションを実行しないでください。
- オプション A: 標準の Kerberos の制約付き委任。 これは、ほとんどの環境に対する既定の推奨事項です。
- オプション B: リソースに基づく Kerberos の制約付き委任。 これは、データ ソースがゲートウェイとは異なるドメインに属している場合に必要です。
オプション A: 標準の Kerberos の制約付き委任
ここでは、ゲートウェイ サービス アカウントに対する委任の設定を行います。 この手順は複数のツールを使って実行できます。 ここでは [Active Directory ユーザーとコンピューター] を使用します。これは、ディレクトリ内の情報の管理と発行を行うための MMC のスナップインです。 ドメイン コントローラーでは既定で利用できますが、他のマシンでは Windows 機能の構成を使用してこれを有効にすることができます。
プロトコル遷移のある Kerberos の制約付き委任を構成する必要があります。 制約付き委任では、ゲートウェイが委任された資格情報を提示できるサービスを明示的に指定する必要があります。 たとえば、SQL Server または SAP HANA サーバーだけが、ゲートウェイ サービス アカウントからの委任呼び出しを受け入れます。
このセクションでは、基になるデータ ソース (SQL Server、SAP HANA、SAP BW、Teradata、Spark など) に対して SPN を既に構成してあるものとします。 これらのデータ ソース サーバーの SPN を構成する方法については、各データベース サーバーの技術ドキュメントを参照してください。また、ブログ記事「私の Kerberos チェックリスト」の「アプリに必要な SPN」セクションを参照してください。
次の手順では、同じドメイン内に次の 2 台のコンピューターがあるオンプレミス環境を想定しています: ゲートウェイ コンピューターと、Kerberos ベースの SSO に対して構成済みの SQL Server が実行されているデータベース サーバー。 この手順は、データ ソースが Kerberos ベースのシングルサインオン用に既に構成されている場合に限り、サポートされている他のデータ ソースの 1 つに対して使用できます。 この例では、次の設定を使用します。
- Active Directory ドメイン (Netbios): Contoso
- ゲートウェイ コンピューター名: MyGatewayMachine
- ゲートウェイ サービス アカウント: Contoso\GatewaySvc
- SQL Server データ ソースのコンピューター名: TestSQLServer
- SQL Server データ ソースのサービス アカウント: Contoso\SQLService
委任設定を構成する方法を次に示します。
ドメイン管理者権限で、[Active Directory ユーザーとコンピューター] MMC スナップインを開きます。
ゲートウェイのサービス アカウント (Contoso\GatewaySvc) を右クリックし、[プロパティ] を選択します。
[委任] タブを選びます。
[指定されたサービスへの委任でのみこのコンピューターを信頼する]>[任意の認証プロトコルを使う] をオンにします。
[このアカウントが委任された資格情報を提示できるサービス] で [追加] を選択します。
新しいダイアログ ボックスで、[ユーザーまたはコンピューター] を選びます。
データ ソースのサービス アカウントを入力し、[OK] を選択します。
たとえば、SQL Server データ ソースには、Contoso\SQLService のようなサービス アカウントを設定できます。 このアカウントには、データ ソース用に適切な SPN が既に設定されている必要があります。
データベース サーバー用に作成した SPN を選びます。
この例では、SPN は MSSQLSvc で始まります。 データベース サービスに FQDN と NetBIOS 両方の SPN を追加した場合は、両方とも選びます。 表示されるのは 1 つだけです。
[OK] を選択します。
これで、ゲートウェイ サービス アカウントが委任された資格情報を提示できるサービスの一覧に SPN が表示されるはずです。
セットアップ プロセスを続行するには、「ゲートウェイ マシンでゲートウェイ サービス アカウントにローカル ポリシー権限を付与する」に進みます。
オプション B: リソースに基づく Kerberos の制約付き委任
リソースに基づく Kerberos の制約付き委任を使用して、Windows Server 2012 以降のバージョンに対するシングル サインオン接続を有効にします。 この種類の委任によって、フロントエンドおよびバックエンド サービスを異なるドメインに配置できるようになります。 これを機能させるには、バックエンド サービスのドメインでフロントエンド サービスのドメインを信頼する必要があります。
次の手順では、ゲートウェイ コンピューターと、Kerberos ベースの SSO を構成済みの SQL Server が実行されているデータベース サーバーの、異なるドメインの 2 つのコンピューターで構成されるオンプレミス環境を想定しています。 これらの手順は、データ ソースが Kerberos ベースのシングル サインオン用に既に構成されている場合に限り、サポートされている他のデータ ソースの 1 つに対して使用できます。 この例では、次の設定を使用します。
- Active Directory フロントエンド ドメイン (Netbios): ContosoFrontEnd
- Active Directory バックエンド ドメイン (Netbios): ContosoBackEnd
- ゲートウェイ コンピューター名: MyGatewayMachine
- ゲートウェイ サービス アカウント: ContosoFrontEnd\GatewaySvc
- SQL Server データ ソースのコンピューター名: TestSQLServer
- SQL Server データ ソースのサービス アカウント: ContosoBackEnd\SQLService
次の構成手順を実行します。
ContosoFrontEnd ドメイン用のドメイン コントローラーで [Active Directory ユーザーとコンピューター] MMC スナップインを使用して、ゲートウェイ サービス アカウントに委任設定が適用されていないことを確認します。
ContosoBackEnd ドメインのドメイン コントローラーで [Active Directory ユーザーとコンピューター] を使用して、バックエンド サービス アカウントに委任設定が適用されていないことを確認します。
アカウントのプロパティの [属性エディター] タブで、msDS-AllowedToActOnBehalfOfOtherIdentity 属性が設定されていないことを確認します。
[Active Directory ユーザーとコンピューター] で、ContosoBackEnd ドメインのドメイン コントローラー上にグループを作成します。 GatewaySvc ゲートウェイ サービス アカウントを ResourceDelGroup グループに追加します。
信頼されたドメインからユーザーを追加するには、このグループのスコープが [ドメイン ローカル] である必要があります。
ContosoBackEnd ドメインのドメイン コントローラーでコマンド プロンプトを開いて次のコマンドを実行し、バックエンド サービス アカウントの msDS-AllowedToActOnBehalfOfOtherIdentity 属性を更新します。
$c = Get-ADGroup ResourceDelGroup Set-ADUser SQLService -PrincipalsAllowedToDelegateToAccount $c[Active Directory ユーザーとコンピューター] で、バックエンド サービス アカウントのプロパティの [属性エディター] タブに更新が反映されていることを確認します。
手順 5: サービス アカウントで AES 暗号化を有効にする
ゲートウェイ サービス アカウントと、ゲートウェイによる委任が可能なすべてのデータ ソース サービス アカウントに次の設定を適用します。
注意
サービス アカウントで定義されている既存の enctypes がある場合は、Active Directory 管理者に問い合わせてください。これは、次の手順に従うと既存の enctypes 値が上書きされ、クライアントが破損する可能性があるという理由のためです。
ドメイン管理者権限で、[Active Directory ユーザーとコンピューター MMC] スナップインを開きます。
ゲートウェイ サービス アカウントまたはデータ ソース サービス アカウントを右クリックして、[プロパティ] を選択します。
[アカウント] タブを選択します。
[アカウント オプション] で、次のオプションのうち少なくとも 1 つ (または両方) を有効にします。 すべてのサービス アカウントで同じオプションを有効にする必要があることに注意してください。
- このアカウントで Kerberos AES 128 ビット暗号化をサポートする
- このアカウントで Kerberos AES 256 ビット暗号化をサポートする
注意
使用する暗号化スキームがわからない場合は、Active Directory 管理者に問い合わせてください。
手順 6: ゲートウェイ コンピューターでゲートウェイ サービス アカウントのローカル ポリシー権限を付与する
最後に、ゲートウェイ サービス (この例では MyGatewayMachine) が実行されているマシンで、ゲートウェイ サービス アカウントにローカル ポリシーの [認証後にクライアントを偽装] と [オペレーティング システムの一部として機能 (SeTcbPrivilege)] を付与します。 この構成は、ローカル グループ ポリシー エディター (gpedit.msc) で実行できます。
ゲートウェイ マシンで、gpedit.msc を実行します。
[ローカル コンピューター ポリシー]>[コンピューターの構成]>[Windows の設定]>[セキュリティの設定]>[ローカル ポリシー]>[ユーザー権利の割り当て] に移動します。
[ユーザー権利の割り当て] で、ポリシーの一覧から [認証後にクライアントを偽装] を選択します。
ポリシーを右クリックし、[プロパティ] を開いて、アカウントの一覧を表示します。
一覧には、ゲートウェイ サービス アカウント (制約付き委任の種類に応じて、Contoso\GatewaySvc または ContosoFrontEnd\GatewaySvc) が含まれている必要があります。
[ユーザー権利の割り当て] で、ポリシーの一覧から [オペレーティング システムの一部として機能 (SeTcbPrivilege)] を選択します。 アカウントの一覧にゲートウェイ サービス アカウントが含まれることを確認します。
オンプレミス データ ゲートウェイ サービス プロセスを再起動します。
手順 7: Windows アカウントがゲートウェイ コンピューターにアクセスできる
SSO によって Windows 認証が使用されるため、Windows アカウントでゲートウェイ コンピューターにアクセスできることを確認してください。 確認できない場合は、ローカル コンピューターの "Users" グループに NT-AUTHORITY\Authenticated Users (S-1-5-11) を追加してください。
セクション 2: 環境固有の構成
Windows 認証およびアクセス グループにゲートウェイ サービス アカウントを追加する
このセクションは、次のいずれかの状況に該当する場合に完了してください。
- Active Directory 環境のセキュリティが強化されている。
- ゲートウェイが偽装するゲートウェイ サービス アカウントとユーザー アカウントが別々のドメインまたはフォレストにあるとき。
ドメイン/フォレストが強化されていない状況で、ゲートウェイ サービス アカウントを Windows 認証およびアクセスグループに追加することもできますが、これは必須ではありません。
詳細については、Windows 認証およびアクセスグループに関する記事を参照してください。
この構成手順を完了するには、ゲートウェイ サービス アカウントを偽装できるようにする Active Directory ユーザーが含まれるドメインごとに、次の手順を実行します。
- ドメイン内のコンピューターにサインインし、Active Directory ユーザーとコンピューター MMC スナップインを起動します。
- [Windows Authorization and Access Group](Windows 認証およびアクセス グループ) グループを見つけます。これは、通常は、Builtin コンテナー内にあります。
- グループをダブルクリックし、[メンバー] タブをクリックします。
- [追加] をクリックし、ドメインの場所をゲートウェイ サービス アカウントが存在するドメインに変更します。
- ゲートウェイ サービス アカウント名を入力し、[名前の確認] をクリックして、そのゲートウェイ サービス アカウントにアクセスできることを確認します。
- [OK] をクリックします。
- [適用] をクリックします。
- ゲートウェイ サービスを再起動します。
ゲートウェイ コンピューターでユーザー マッピングの構成パラメーターを設定する
このセクションは、次の場合に完了してください。
- Microsoft Entra Connect とユーザー アカウントの同期が構成されておらず、かつ
- ユーザーの Power BI で使用されている UPN が、ローカルの Active Directory 環境の UPN と一致しない。
この方法でマップされた各 Active Directory ユーザーは、データ ソースに対する SSO アクセス許可を持っている必要があります。
メインのゲートウェイの構成ファイル
Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dllを開きます。 既定では、このファイルはC:\Program Files\On-premises data gatewayに格納されます。ADUserNameLookupProperty を未使用の Active Directory 属性に設定します。
msDS-cloudExtensionAttribute1は、以降の手順で使用します。 この属性は、Windows Server 2012 以降でのみ使用できます。ADUserNameReplacementProperty を
SAMAccountNameに設定し、構成ファイルを保存します。注意
マルチドメイン シナリオでは、ユーザーのドメイン情報を保持するために、ADUserNameReplacementProperty を
userPrincipalNameに設定することが必要な場合があります。タスク マネージャーの [サービス] タブで、ゲートウェイ サービスを右クリックして [再起動] を選択します。
![タスク マネージャーの [サービス] タブのスクリーン ショット](media/service-gateway-sso-kerberos/restart-gateway.png)
Kerberos SSO を有効にする Power BI サービス ユーザーごとに、(データ ソースへの SSO アクセス許可を持つ) ローカル Active Directory ユーザーの
msDS-cloudExtensionAttribute1プロパティを、Power BI サービス ユーザーの完全なユーザー名 (UPN) に設定します。 たとえば、Power BI サービスに test@contoso.com としてサインインしていて、このユーザーを SSO アクセス許可を持つローカル Active Directory ユーザー (例: test@LOCALDOMAIN.COM) にマップする場合は、このユーザーのmsDS-cloudExtensionAttribute1属性を test@contoso.com に設定します。msDS-cloudExtensionAttribute1プロパティは、[Active Directory ユーザーとコンピューター] MMC スナップインで、次のように設定できます。ドメイン管理者として [Active Directory ユーザーとコンピューター] を起動します。
ドメイン名を右クリックし、[検索] を選択して、マップするローカル Active Directory ユーザーのアカウント名を入力します。
[属性エディター] タブを選びます。
msDS-cloudExtensionAttribute1プロパティを見つけてダブルクリックします。 その値を、Power BI サービスへのサインインに使用するユーザーの完全なユーザー名 (UPN) に設定します。[OK] を選択します。
![[文字列属性エディター] ウィンドウ](media/service-gateway-sso-kerberos/edit-attribute.png)
[適用] を選択します。 [値] 列に正しい値が設定されていることを確認します。
データソース固有の構成手順を完了する
SAP HANA、SAP BW、Teradata の各データ ソースについては、ゲートウェイ SSO で使用するために次の追加の構成が必要です。
- SAP HANA への シングル サインオン (SSO) に Kerberos を使用する。
- CommonCryptoLib (sapcrypto.dll) を使用して SAP BW への SSO に Kerberos シングル サインオンを使用する。
- Teradata へのシングル サインオン (SSO) に Kerberos を使用する。
Note
他の SNC ライブラリも BW SSO で機能する可能性はありますが、Microsoft は公式にはサポートしていません。
セクション 3: 構成を検証する
手順 1: Power BI でデータ ソースを構成する
すべての構成手順が完了したら、Power BI の [Manage Gateway](ゲートウェイの管理) ページを使って、SSO に使用するデータ ソースを構成します。 複数のゲートウェイがある場合は、Kerberos SSO 用に構成したゲートウェイを選択してください。 次いで、データ ソースの [設定] で、DirectQuery ベースのレポートの場合は、[DirectQuery クエリには Kerberos 経由で SSO を使用します] チェックボックスまたは [Kerberos を使用した SSO を DirectQuery とインポート クエリに使用する] チェックボックスのいずれかをオンにし、インポート ベースのレポートの場合は、[Kerberos を使用した SSO を DirectQuery とインポート クエリに使用する] チェックボックスをオンにします。
[DirectQuery クエリには Kerberos 経由で SSO を使用します] と [Kerberos を使用した SSO を DirectQuery とインポート クエリに使用する] の設定では、DirectQuery ベースのレポートとインポート ベースのクエリに対し、それぞれ異なる動作が実行されます。
[DirectQuery クエリには Kerberos 経由で SSO を使用します] :
- DirectQuery ベースのレポートでは、ユーザーの SSO 資格情報が使用されます。
- インポート ベースのレポートでは、SSO 資格情報は使用されず、データ ソース ページで入力した資格情報が使用されます。
[Kerberos を使用した SSO を DirectQuery とインポート クエリに使用する] :
- DirectQuery ベースのレポートでは、ユーザーの SSO 資格情報が使用されます。
- インポート ベースのレポートでは、インポートをトリガーしたユーザーに関係なく、セマンティック モデルの所有者の SSO 資格情報が使われます。
手順 2: シングル サインオンをテストする
「シングルサインオン (SSO) 構成のテスト」に進んで、構成が正しく設定されていることを簡単に検証し、一般的な問題のトラブルシューティングを行います。
手順 3: Power BI レポートを実行する
複数のゲートウェイがある場合は、発行時に、SSO 用に構成したゲートウェイを選択してください。
関連するコンテンツ
オンプレミス データ ゲートウェイと DirectQuery の詳細については、次のリソースを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示