您組織中的使用者可以看到您的內部部署資料 (他們已經具有存取授權),但在那些使用者能夠連接至內部部署資料來源之前,內部部署資料閘道必須先行安裝和設定。 此閘道有助於讓雲端的使用者快速安全地以幕後通訊方式,在內部部署資料來源和雲端之間往返。

安裝和設定閘道器通常是由系統管理員完成。 此作業也許需要對內部部署伺服器的專業知識,而且在某些情況下可能需要伺服器管理員權限。

本文不會提供如何安裝和設定閘道器的逐步指引。 為此,請務必查看內部部署資料閘道。 本文旨在讓您深入了解閘道器的運作方式。 我們也將深入探討 Azure Active Directory 和 Analysis Services 中使用者名稱和安全性的相關詳細資料,以及雲端服務如何運用使用者用以登入的電子郵件地址、閘道和 Active Directory,進而安全地連接及查詢內部部署資料。

閘道運作方式

on-prem-data-gateway-how-it-works

我們先來看看使用者與連接至內部部署資料來源的項目互動時的情形。

注意:

Power BI 必須設定閘道的資料來源。

  1. 雲端服務會建立查詢,和內部部署資料來源的加密認證一起傳送到佇列,以供閘道處理。

  2. 閘道雲端服務會分析此查詢,並將要求推送到 Azure 服務匯流排

  3. 內部部署資料閘道會輪詢 Azure 服務匯流排,得知是否有擱置的要求。

  4. 閘道收到查詢、將認證解密,然後使用該認證連接至資料來源。

  5. 閘道將查詢傳送到資料來源以用於執行。

  6. 結果會從資料來源傳回閘道,然後傳送到雲端服務。 服務接著使用該結果。

可用的資料來源類型清單

資料來源 即時/DirectQuery 使用者設定的手動或排程重新整理
Analysis Services 表格式
Analysis Services 多維度
檔案
資料夾
IBM DB2
IBM Informix 資料庫
Impala
MySQL
OData
ODBC
Oledb
Oracle
PostgresSQL
SAP BW
SAP HANA
SharePoint 清單 (內部部署)
雪花式
SQL Server
Sybase
Teradata
Web

登入帳戶

使用者將會使用公司或學校帳戶登入。 這是您的組織帳戶。 如果您註冊 Office 365 供應項目,而且未提供實際的公司電子郵件,其看起來可能會類似 nancy@contoso.onmicrosoft.com。您在雲端服務中的帳戶會儲存在 Azure Active Directory (AAD) 租用戶中。 在大部分情況下,您的 AAD 帳戶 UPN 會比對電子郵件地址。

內部部署資料來源的驗證

預存的認證將用來從 Analysis Services 以外的閘道連接至內部部署資料來源。 不論是哪位個別使用者,閘道都會使用預存的認證進行連接。

即時 Analysis Services 資料來源的驗證

每次使用者和 Analysis Services 互動時,有效使用者名稱皆會傳遞至閘道,然後傳到內部部署 Analysis Services 伺服器。 使用者主體名稱 (UPN),通常是您用以登入雲端的電子郵件地址,即為當作有效使用者傳遞給 Analysis Services 的內容。 傳遞此 UPN 時是使用連接屬性 EffectiveUserName。 此電子郵件地址應符合本機 Active Directory 網域內定義的 UPN。 UPN 是 Active Directory 帳戶的屬性。 接著,該 Windows 帳戶就必須出現於 Analysis Services 角色中,以取得伺服器的存取權。 如果沒有在 Active Directory 中找到符合的項目,登入不會成功。

Analysis Services 也可以提供根據此帳戶進行篩選。 可以根據角色型安全性或資料列層級安全性來篩選。

角色型安全性

模型會依據使用者角色來提供安全性。 針對特定模型專案來定義角色的方式為使用 SQL Server Management Studio (SSMS),時間點可能在使用 SQL Server Data Tools – 商業智慧 (SSDT-BI) 撰寫期間,或者在部署模型之後。 角色所包含的成員依 Windows 使用者名稱或 Windows 群組而定。 角色定義了使用者在模型上查詢或執行動作的權限。 大部分的使用者將屬於擁有讀取權限的角色。 其他角色適用於具有處理項目、管理資料庫函數及管理其他角色等權限的系統管理員。

資料列層級安全性

資料列層級安全性為 Analysis Services 資料列層級安全性所特有。 模型會提供動態的資料列層級安全性。 不同於具有至少一個使用者隸屬的角色,動態安全性並非任何表格式模型所需。 在較高的層級,動態安全性定義使用者讀取資料的權限,用於讀取特定資料表中特定資料列的資料。 動態資料列層級安全性與角色類似,也仰賴使用者的 Windows 使用者名稱。

查詢和檢視模型資料的使用者功能,首先由 Windows 使用者帳戶所隸屬的角色而定,其次由動態資料列層級安全性而定 (如果已設定的話)。

在模型中實作角色和動態資料列層級安全性已超出本文的範圍。 若要深入了解,您可以前往 MSDN 上的角色 (SSAS 表格式)安全性角色 (Analysis Services - 多維度資料)。 此外,為了徹底了解表格式模型安全性,請下載並閱讀保護表格式 BI 語意模型技術白皮書

Azure Active Directory 的情況為何?

Microsoft 雲端服務會使用 Azure Active Directory 來負責驗證使用者。 Azure Active Directory 是包含使用者名稱和安全性群組的租用戶。 一般而言,使用者登入時使用的電子郵件地址與帳戶的 UPN 相同。

我的本機 Active Directory 角色是什麼?

為了讓 Analysis Services 可判斷予以連接的使用者所屬角色是否具有讀取資料的權限,該伺服器需要轉換從 AAD 傳遞到閘道再傳遞到 Analysis Services 伺服器的有效使用者名稱。 Analysis Services 伺服器會將有效使用者名稱傳遞至 Windows Active Directory 網域控制站 (DC)。 Active Directory DC 接著會驗證此有效使用者名稱是否為有效 UPN (於本機帳戶上),然後將該使用者的 Windows 使用者名稱傳回給 Analysis Services 伺服器。

EffectiveUserName 不能用在未加入網域的 Analysis Services 伺服器上。 Analysis Services 伺服器必須已加入網域中,以避免任何登入錯誤。

如何判斷我的 UPN 為何?

您可能不知道您的 UPN 為何,且您可能不是網域系統管理員。 您可以從工作站使用下列命令來查明您帳戶的 UPN。

whoami /upn

結果看起來類似電子郵件地址,但這是您本機網域帳戶上的 UPN。 如果您使用 Analysis Services 資料來源進行即時連線,則必須符合從閘道傳遞給 EffectiveUserName 的資料來源。

對應 Analysis Services 資料來源的使用者名稱

Power BI 可讓您對應 Analysis Services 資料來源的使用者名稱。 您可以設定規則,將登入 Power BI 的使用者名稱對應至 Analysis Services 連線上傳遞給 EffectiveUserName 的名稱。 當您在 AAD 中的使用者名稱不符合本機 Active Directory 中的 UPN 時,使用者名稱對應功能是解決問題的好方法。 比方說,如果您的電子郵件地址為 nancy@contoso.onmicrsoft.com,您可以將其對應至 nancy@contoso.com,然後該值就會傳遞至閘道。 您可以深入了解如何對應使用者名稱

同步處理內部部署 Active Directory 和 Azure Active Directory

如果您打算使用 Analysis Services 即時連線,建議您讓本機 Active Directory 帳戶符合 Azure Active Directory。 因為帳戶之間的 UPN 必須相符合。

雲端服務只了解 Azure Active Directory 內的帳戶。 是否將帳戶加入您的本機 Active Directory 並不重要,如果其在 AAD 中不存在,就無法使用。 有不同的方式可以將本機 Active Directory 帳戶和 Azure Active Directory 比對。

  1. 您可以手動將帳戶加入 Azure Active Directory。

    您可以在 Azure 網站或 Office 365 管理入口網站上建立帳戶,帳戶名稱必須符合本機 Active Directory 帳戶的 UPN。

  2. 您可以使用 Azure AD Connect 工具,將本機帳戶同步處理至您的 Azure Active Directory 租用戶。

    Azure AD Connect 工具提供目錄和密碼同步處理使用的選項。 如果您不是租用戶管理員或本機網域系統管理員,您必須連絡您的 IT 管理員來進行這項設定。

  3. 您可以設定 Active Directory 同盟服務 (ADFS)。

    您可以使用 Azure AD Connect 工具將 ADFS 伺服器與 AAD 租用戶建立關聯。 ADFS 使用以上所討論的目錄同步作業,但允許單一登入 (SSO) 體驗。 例如,如果您位於您的公司網路中,當您前往雲端服務並移至登入後,系統可能不會提示您輸入使用者名稱或密碼。 您必須與您的 IT 管理員討論這是否可供您的組織使用。

使用 Azure AD Connect 可確保 UPN 會在 AAD 與本機 Active Directory 之間相符。

注意:

使用 Azure AD Connect 工具同步處理帳戶會在 AAD 租用戶內建立新的帳戶。

這就是閘道器現在的運作方式

閘道可作為雲端和內部部署伺服器之間的橋接器。 雲端和閘道之間的資料傳輸會透過 Azure 服務匯流排加以保護。 此服務匯流排會透過閘道上的輸出連線,建立雲端與內部部署伺服器之間的安全通道。 您不需要在內部部署防火牆上開啟任何輸入的連線。

如果您有 Analysis Services 資料來源,則需要在與 Analysis Services 伺服器加入同一個樹系/網域的電腦上安裝閘道器。

閘道器越接近伺服器,連接速度就越快。 如果您可以取得與資料來源位於相同伺服器上的閘道器,就最能夠避免閘道器和伺服器之間的網路延遲。

下一個步驟是什麼?

安裝閘道之後,您將需要建立該閘道的資料來源。 您可以在 [管理閘道] 畫面內加入資料來源。 如需詳細資訊,請參閱管理資料來源文章。

管理您的資料來源─Analysis Services
管理您的資料來源 - SAP HANA
管理您的資料來源 - SQL Server
管理您的資料來源 - Oracle
管理您的資料來源 - 匯入/已排程的重新整理

可能發生錯誤之處

有時候,閘道器會安裝失敗; 或者閘道看似安裝成功,但服務仍然無法搭配運作。 在許多情況下,錯誤的起因很簡單,例如閘道器用以登入資料來源的認證密碼。

在其他情況下,問題則可能出在使用者登入的電子郵件地址類型,或 Analysis Services 無法解析有效使用者名稱。 如果您有多個互相信任的網域,且閘道位於其中一個,而 Analysis Services 位於另一個,則這種情況有時會造成一些問題。

我們不會在這裡進行閘道問題的疑難排解,而是在另一篇文章為內部部署資料閘道進行疑難排解中,提供一系列的疑難排解步驟。 希望您不會遇到任何問題。 但如果您遇到了問題,則了解這裡所有步驟和疑難排解文章將有所幫助。

登入帳戶

使用者將會使用公司或學校帳戶登入。 這是您的組織帳戶。 如果您註冊 Office 365 供應項目,而且未提供實際的公司電子郵件,其看起來可能會類似 nancy@contoso.onmicrosoft.com。您在雲端服務中的帳戶會儲存在 Azure Active Directory (AAD) 租用戶中。 在大部分情況下,您的 AAD 帳戶 UPN 會與電子郵件地址相符。

Windows 服務帳戶

內部部署資料閘道已設定為使用 NT SERVICE\PBIEgwService 來表示 Windows 服務的登入認證。 根據預設,其具有「以服務方式登入」的權限。 這在您要安裝閘道的電腦內容中。

注意:

如果您選取個人模式,請另外設定 Windows 服務帳戶。

這不是用來連接至內部部署資料來源的帳戶。 這也不是您登入雲端服務所用的工作或學校帳戶。

若您的 Proxy 伺服器發生驗證問題,可以將 Windows 服務帳戶變更為網域使用者或受管理的服務帳戶。 您可以學習如何從 Proxy 設定變更此帳戶。

連接埠

閘道會建立 Azure 服務匯流排的輸出連線。 它會在輸出連接埠上進行通訊:TCP 443 (預設)、5671、5672、9350 到 9354。 閘道不需要輸入連接埠。 深入了解

建議您將您資料區域的 IP 位址加入防火牆的允許清單中。 您可以下載 Microsoft Azure 資料中心的 IP 清單。 此清單會每週更新。 閘道會使用 IP 位址及完整網域名稱 (FQDN) 來與 Azure 服務匯流排通訊。 如果您強制閘道器使用 HTTPS 進行通訊,閘道器會嚴格限於使用 FQDN,使用 IP 位址則不會發生通訊。

注意:

Azure Datacenter IP 清單中所列的 IP 位址採用 CIDR 標記法。 例如 10.0.0.0/24 並不等於 10.0.0.0 到 10.0.0.24。 深入了解 CIDR 標記法

下列清單包含閘道所使用的完整網域名稱。

網域名稱 輸出連接埠 描述
*.download.microsoft.com 80 下載安裝程式所使用的 HTTP。
*.powerbi.com 443 HTTPS
*.analysis.windows.net 443 HTTPS
*.login.windows.net 443 HTTPS
*.servicebus.windows.net 5671-5672 進階訊息佇列通訊協定 (AMQP)
*.servicebus.windows.net 443, 9350-9354 透過 TCP 之服務匯流排轉送上的接聽程式 (需要 443 以取得存取控制 Token)
*.frontend.clouddatahub.net 443 HTTPS
*.core.windows.net 443 HTTPS
login.microsoftonline.com 443 HTTPS
*.msftncsi.com 443 在 Power BI 服務無法與閘道連線時,用於測試網際網路連線。
*.microsoftonline-p.com 443 用於依據組態進行驗證。
注意:

前往 visualstudio.com 或 visualstudioonline.com 的流量是供 App Insights 使用,對閘道的運作並非必要。

強制與 Azure 服務匯流排進行 HTTPS 通訊

您可以強制閘道器使用 HTTPS 與 Azure 服務匯流排進行通訊,而不使用直接 TCP。 這可能會對效能產生影響。 若要這樣做,請修改 Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config 檔案,方法是將值從 AutoDetect 變更為 Https,如本段後面接著的程式碼片段所示。 該檔案 (依預設) 位於 C:\Program Files\On-premises data gateway。

<setting name="ServiceBusSystemConnectivityModeString" serializeAs="String">
    <value>Https</value>
</setting>

您也可以使用 2017 年 3 月版本開始提供的閘道器使用者介面,強制閘道器採用此行為。 在閘道器使用者介面中選取 [網路],然後將 [Azure 服務匯流排連線模式] 切換為 [開啟]。

變更後,當您選取 [套用] (進行變更才出現的按鈕) 時,「閘道 Windows 服務」會自動重新啟動,讓變更生效。

為供日後參考,您可以選取 [服務設定],然後選取 [立即重新啟動],從使用者介面對話方塊重新啟動「閘道 Windows 服務」。

TLS 1.1/1.2 支援

有了 2017 年 8 月更新和以上版本之後,內部部署資料閘道預設會使用傳輸層安全性 (TLS) 1.1 或 1.2,以與 Power BI 服務進行通訊。 舊版內部部署資料閘道預設會使用 TLS 1.0。 在 2017 年 11 月 1 日,TLS 1.0 支援將結束 (包括閘道使用 TLS 1.0 與 Power BI 服務互動的功能),因此您必須在屆期前將內部部署資料閘道安裝升級為 2017 年 8 月版本或更新版本,以確保閘道持續運作。

請務必注意,在 11 月 1 日之前,內部部署資料閘道仍然支援 TLS 1.0,而且閘道會使用它作為後援機制。 若要確保所有閘道流量使用 TLS 1.1 或 1.2 (以及避免在閘道上使用 TLS 1.0),您必須新增或修改執行閘道服務之電腦上的下列登錄機碼:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]"SchUseStrongCrypto"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]"SchUseStrongCrypto"=dword:00000001

注意:新增或修改這些登錄機碼會將變更套用至所有 .NET 應用程式。 如需影響其他應用程式之 TLS 之登錄變更的資訊,請參閱 Transport Layer Security (TLS) registry settings (傳輸層安全性 (TLS) 登錄設定)。

如何重新啟動閘道

閘道會當作 Windows 服務來執行。 您可以像是任何 Windows 服務啟動及停止這項服務。 有多種方式可以執行這項操作。 以下示範如何從命令提示字元執行這項操作。

  1. 在執行閘道的電腦上,啟動系統管理員命令提示字元。

  2. 使用下列命令停止服務。

    net stop PBIEgwService

  3. 使用下列命令啟動服務。

    net start PBIEgwService

另請參閱

為內部部署資料閘道進行疑難排解
Azure 服務匯流排
Azure AD Connect
有其他問題嗎? 試試 Power BI 社群