Power BI サービスからオンプレミスデータソースへの Kerberos ベースの SSO を構成する

[アーティクル]
01/23/2024

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 に設定することが必要な場合があります。
タスクマネージャーの [サービス] タブで、ゲートウェイサービスを右クリックして [再起動] を選択します。
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 スナップインで、次のように設定できます。
1. ドメイン管理者として [Active Directory ユーザーとコンピューター] を起動します。
2. ドメイン名を右クリックし、[検索] を選択して、マップするローカル Active Directory ユーザーのアカウント名を入力します。
3. [属性エディター] タブを選びます。
  
  msDS-cloudExtensionAttribute1 プロパティを見つけてダブルクリックします。その値を、Power BI サービスへのサインインに使用するユーザーの完全なユーザー名 (UPN) に設定します。
4. [OK] を選択します。
5. [適用] を選択します。 [値] 列に正しい値が設定されていることを確認します。

データソース固有の構成手順を完了する

SAP HANA、SAP BW、Teradata の各データソースについては、ゲートウェイ SSO で使用するために次の追加の構成が必要です。

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 の詳細については、次のリソースを参照してください。

次の方法で共有

Power BI サービスからオンプレミスデータソースへの Kerberos ベースの SSO を構成する

必須コンポーネント

構成の概要

セクション 1: 基本的な構成

手順 1: Microsoft オンプレミスデータゲートウェイをインストールして構成する