使用 CommonCryptoLib (sapcrypto.dll) 將 Kerberos 單一登入用於 SAP BW 的 SSO
本文說明如何使用 CommonCryptoLib(sapcrypto.dll),設定 SAP BW 數據源,從 Power BI 服務 啟用單一登錄(SSO)。
注意
在您嘗試重新整理使用 Kerberos SSO 的 SAP BW 型報表之前,請先完成本文中的步驟和設定 Kerberos 型 SSO 中的步驟。 使用 CommonCryptoLib 作為您的安全網路通訊 (SNC) 連結庫,可讓 SSO 連線至 SAP BW 應用程式伺服器和 SAP BW 訊息伺服器。
注意
在同一個閘道伺服器上設定這兩個程式庫 (sapcrypto 和 gx64krb5) 是不受支援的案例。 不建議在同一個閘道伺服器上設定這兩個程式庫,因為這將導致程式庫的混合。 如果您想要同時使用這兩個程式庫,請完全分離閘道伺服器。 例如,為伺服器 A 設定 gx64krb5,然後為伺服器 B 設定 sapcrypto。請記住,不支援使用 gx64krb5 的伺服器 A 上發生任何失敗,因為 SAP 和 Microsoft 不再支援 gx64krb5。
使用 CommonCryptoLib 來設定 SAP BW 以啟用 SSO
注意
內部部署資料閘道是 64 位元軟體,因此需要 64 位元版本的 CommonCryptoLib (sapcrypto.dll) 來執行 BW SSO。 如果您打算在透過閘道嘗試 SSO 連線之前,於 SAP GUI 中測試 SAP BW 伺服器的 SSO 連線 (建議),則也需要 32 位元版本的 CommonCryptoLib,因為 SAP GUI 是 32 位元軟體。
請確定您的 BW 伺服器已使用 CommonCryptoLib 針對 Kerberos SSO 正確設定。 如果已正確設定,則可透過 SAP GUI 之類已設定為使用 CommonCryptoLib 的 SAP 工具,使用 SSO 來存取 BW 伺服器 (直接或透過 SAP BW 訊息伺服器)。
如需設定步驟的詳細資訊,請參閱 SAP 單一登入:使用 Kerberos/SPNEGO 進行驗證。 您的 BW 伺服器應該使用 CommonCryptoLib 作為其 SNC 程式庫,並具有以 CN= 開頭的 SNC 名稱,例如 CN=BW1。 如需 SNC 名稱需求 (具體來說,是 snc/identity/as 參數) 的詳細資訊,請參閱 Kerberos 設定的 SNC 參數。
如果您尚未這麼做,請在已安裝閘道的電腦上安裝 SAP .NET 連接器的 x64 版本。
您可以透過嘗試在 Power BI Desktop 中從閘道電腦連線到 BW 伺服器,檢查元件是否已安裝。 如果您無法使用 2.0 實作進行連線,則不會安裝 .NET 連接器,或尚未安裝至全域程式集緩存。
請確定在安裝閘道的電腦上未執行 SAP 安全登入用戶端 (SLC)。
SLC 快取 Kerberos 票證時,可能會干擾閘道能否使用 Kerberos 進行 SSO。
如果已安裝 SLC,請將其解除安裝,或確定您已結束 SAP 安全登入用戶端。 以滑鼠右鍵按一下系統匣中的圖示,然後依序選取 [登出] 和 [結束],再使用閘道嘗試 SSO 連線。
Windows Server 電腦不支援使用 SLC。 如需詳細資訊,請參閱 SAP Note 2780475 (需要 s 使用者)。
如果您解除安裝 SLC 或依序選取 [登出] 和 [結束],請開啟 cmd 視窗並輸入
klist purge
以清除任何快取的 Kerberos 票證,然後嘗試透過閘道進行 SSO 連線。從 SAP Launchpad 下載 64 位元的 CommonCryptoLib (sapcrypto.dll) 8.5.25 版或更新版本,並將它複製到閘道電腦上的資料夾。 在您複製 sapcrypto.dll 的相同目錄中,建立名為 sapcrypto.ini 的檔案,其中包含下列內容:
ccl/snc/enable_kerberos_in_client_role = 1
.Ini 檔案包含 CommonCryptoLib 在閘道案例中啟用 SSO 所需的設定資訊。
注意
這些檔案必須儲存在相同的位置;換句話說,/path/to/sapcrypto/ 應該同時包含 sapcrypto.ini 和 sapcrypto.dll。
閘道服務使用者和服務使用者模擬的 Active Directory (AD) 使用者,都需要這兩個檔案的讀取和執行權限。 我們建議將 .ini 和 .dll 檔案的權限授與 [已驗證的使用者] 群組。 為了進行測試,您也可以明確地將這些許可權授與閘道服務使用者,以及您用於測試的 AD 使用者。 在下列螢幕擷取畫面中,我們已將 sapcrypto.dll 的讀取和執行權限授與 [已驗證的使用者] 群組:
如果您還沒有與閘道相關聯的 SAP BW 資料源,您希望 SSO 連線流經,請在 Power BI 服務 的 [管理連線和閘道] 頁面上新增一個 。 如果您已經有這類資料來源,請加以編輯:
- 如果您想要建立 BW 應用程式伺服器的 SSO 連線,請選擇 [SAP Business Warehouse] 作為 [資料來源類型]。
- 如果您想要建立 BW 訊息伺服器的 SSO 連線,請選取 [SAP Business Warehouse 訊息伺服器]。
針對 SNC 程式庫,請選取 SNC_LIB 或 SNC_LIB_64 環境變數,或選取 [自訂]。
如果您選取 SNC_LIB,則必須將閘道電腦上 SNC_LIB_64 環境變數的值設定為閘道電腦上 sapcrypto.dll 的 64 位元複本的絕對路徑。 例如,C:\Users\Test\Desktop\sapcrypto.dll。
如果您選擇 [自訂],請將 sapcrypto.dll 絕對路徑貼入 [管理閘道] 頁面上出現的 [自訂 SNC 程式庫路徑] 欄位。
針對 [SNC 合作夥伴名稱],輸入 BW 伺服器的 SNC 名稱。 在 [進階設定] 底下,確定已核取 [透過 Kerberos 使用 SSO 進行 DirectQuery 查詢]。 如同從 PBI Desktop 建立 Windows 驗證連線一樣,請填入其他欄位。
建立 CCL_PROFILE 系統環境變數,並將其值設定為 sapcrypto.ini 的路徑。
sapcrypto .dll 和 .ini 檔案必須存在於相同的位置。 在上述範例中,sapcrypto.ini 和 sapcrypto.dll 都位於桌上型電腦上。
重新啟動閘道服務。
疑難排解
如果無法在 Power BI 服務中重新整理報表,則您可以使用閘道追蹤、CPIC 追蹤和 CommonCryptoLib 追蹤來診斷問題。 由於 CPIC 追蹤和 CommonCryptoLib 是 SAP 產品,因此 Microsoft 無法為其提供支援。
閘道記錄
重現問題。
開啟閘道應用程式,然後從 [診斷] 索引標籤中選取 [匯出記錄]。
CPIC 追蹤
若要啟用 CPIC 追蹤,請設定兩個環境變數:CPIC_TRACE 和 CPIC_TRACE_DIR。
第一個變數會設定追蹤層級,第二個變數則會設定追蹤檔案目錄。 此目錄必須是 [已驗證的使用者] 群組成員可以寫入其中的位置。
將 CPIC_TRACE 設為 3,並將 CPIC_TRACE_DIR 設為要將追蹤檔寫入其中的任何目錄。 例如:
重現問題,並確定 CPIC_TRACE_DIR 包含追蹤檔。
CPIC 追蹤可以診斷較高層級的問題,例如,載入 sapcrypto.dll 程式庫失敗。 例如,以下是 CPIC 追蹤檔案的代碼段,其中發生.dll載入錯誤:
[Thr 7228] *** ERROR => DlLoadLib()==DLENOACCESS - LoadLibrary("C:\Users\test\Desktop\sapcrypto.dll") Error 5 = "Access is denied." [dlnt.c 255]
如果您遇到此類失敗,但您已依照上一節所述設定 sapcrypto.dll 與 sapcrypto.ini 的讀取與執行權限,請嘗試在包含檔案的資料夾設定相同的讀取與執行權限。
如果您仍然無法載入 .dll,請嘗試開啟檔案的稽核。 在 Windows 事件檢視器中檢查產生的稽核記錄,可能有助於判斷載入檔案失敗的原因。 尋找模擬 AD 使用者起始的失敗專案。 例如,針對模擬使用者
MYDOMAIN\mytestuser
,稽核記錄中的失敗看起來會像這樣:A handle to an object was requested. Subject: Security ID: MYDOMAIN\mytestuser Account Name: mytestuser Account Domain: MYDOMAIN Logon ID: 0xCF23A8 Object: Object Server: Security Object Type: File Object Name: <path information>\sapcrypto.dll Handle ID: 0x0 Resource Attributes: - Process Information: Process ID: 0x2b4c Process Name: C:\Program Files\On-premises data gateway\Microsoft.Mashup.Container.NetFX45.exe Access Request Information: Transaction ID: {00000000-0000-0000-0000-000000000000} Accesses: ReadAttributes Access Reasons: ReadAttributes: Not granted Access Mask: 0x80 Privileges Used for Access Check: - Restricted SID Count: 0
CommonCryptoLib 追蹤
將這幾行新增至您稍早建立的 sapcrypto.ini 檔案,以開啟 CommonCryptoLib 追蹤:
ccl/trace/level=5 ccl/trace/directory=<drive>:\logs\sectrace
將
ccl/trace/directory
選項變更為 [已驗證的使用者] 群組成員可以寫入的位置。或者,建立新的 .ini 檔案來變更此行為。 在與 sapcrypto.ini 和 sapcrypto.dll 相同的目錄中,使用下列內容建立名為 sectrace.ini 的檔案。 將
DIRECTORY
選項取代為您電腦上 [已驗證的使用者] 群組成員可以寫入的位置:LEVEL = 5 DIRECTORY = <drive>:\logs\sectrace
重現問題,並確認 DIRECTORY 所指向的位置包含追蹤檔案。
當您完成時,請關閉 CPIC 和 CCL 追蹤。
如需 CommonCryptoLib 追蹤的詳細資訊,請參閱 SAP Note 2491573 (需要 SAP S 使用者)。
模擬
本節說明模擬問題的疑難排解徵兆和解決步驟。
徵兆:查看 GatewayInfo[date].log 時,您會發現類似以下內容的項目:About to impersonate user DOMAIN\User (IsAuthenticated: True, ImpersonationLevel: Impersonation)。 如果 ImpersonationLevel 的值與模擬不同,模擬就不會正確發生。
解決方法:請依照授與閘道服務帳戶在閘道電腦上的本機原則權限一文中找到的步驟執行。 變更設定後重新啟動閘道服務。
驗證:重新整理或建立報表並收集 GatewayInfo[date].log。 開啟最新的 GatewayInfo 記錄檔,然後再次檢查關於模擬使用者 DOMAIN\User 的字串 (IsAuthenticated: True, ImpersonationLevel: Impersonation: Impersonation),以確保 ImpersonationLevel 的值符合模擬。
委派
委派問題通常在 Power BI 服務中會顯示為一般錯誤。 若要確定委託是否是問題所在,收集 Wireshark 追蹤並使用 Kerberos 作為篩選條件非常有用。 如需 Kerberos 錯誤參考,請參閱 此部落格文章。 本節的其餘部分說明委派問題的疑難排解徵兆和解決步驟。
徵兆:在 Power BI 服務 中,您可能會遇到類似下列螢幕快照中的非預期錯誤。 在 GatewayInfo[date].log您會看到 [DM.GatewayCore] 在 clientPipelineId 的 ADO 查詢執行嘗試期間內嵌例外狀況,而匯入 [0D_NW_CHANN] 與未匯出相符。
在 Mashup[date].log 中,您會看到一般錯誤 GSS-API(maj):未提供任何認證。
查看 CPIC 追蹤 (sec-Microsoft.Mashup.trc*), 您會看到類似下列內容:
[Thr 4896] *** ERROR => SncPEstablishContext() failed for target='p:CN=BW5' [sncxxall.c 3638]
[Thr 4896] *** ERROR => SncPEstablishContext()==SNCERR_GSSAPI [sncxxall.c 3604]
[Thr 4896] GSS-API(maj): No credentials were supplied
[Thr 4896] Unable to establish the security context
[Thr 4896] target="p:CN=BW5"
[Thr 4896] <<- SncProcessOutput()==SNCERR_GSSAPI
[Thr 4896]
[Thr 4896] LOCATION CPIC (TCP/IP) on local host HNCL2 with Unicode
[Thr 4896] ERROR GSS-API(maj): No credentials were supplied
[Thr 4896] Unable to establish the security context
[Thr 4896] target="p:CN=BW5"
[Thr 4896] TIME Thu Oct 15 20:49:31 2020
[Thr 4896] RELEASE 721
[Thr 4896] COMPONENT SNC (Secure Network Communication)
[Thr 4896] VERSION 6
[Thr 4896] RC -4
[Thr 4896] MODULE sncxxall.c
[Thr 4896] LINE 3604
[Thr 4896] DETAIL SncPEstablishContext
[Thr 4896] SYSTEM CALL gss_init_sec_context
[Thr 4896] COUNTER 3
[Thr 4896]
[Thr 4896] *** ERROR => STISEND:STISncOut failed 20 [r3cpic.c 9834]
[Thr 4896] STISearchConv: found conv without search
從閘道電腦 sec-Microsoft.Mashup.Con-[].trc 的秒數中,錯誤會變得更清楚:
[2020.10.15 20:31:38.396000][4][Microsoft.Mashup.Con][Kerberos ][ 3616] AcquireCredentialsHandleA called successfully.
[2020.10.15 20:31:38.396000][2][Microsoft.Mashup.Con][Kerberos ][ 3616] InitializeSecurityContextA returned -2146893053 (0x80090303). Preparation for kerberos failed!
[2020.10.15 20:31:38.396000][2][Microsoft.Mashup.Con][Kerberos ][ 3616] Getting kerberos ticket for 'SAP/BW5' failed (user name is affonso_v@HANABQ.COM)
[2020.10.15 20:31:38.396000][2][Microsoft.Mashup.Con][Kerberos ][ 3616] Error for requested algorithm 18: 0/C000018B The security database on the server does not have a computer account for this workstation trust relationship.
[2020.10.15 20:31:38.396000][2][Microsoft.Mashup.Con][Kerberos ][ 3616] Error for requested algorithm 17: 0/C000018B The security database on the server does not have a computer account for this workstation trust relationship.
[2020.10.15 20:31:38.396000][2][Microsoft.Mashup.Con][Kerberos ][ 3616] Error for requested algorithm 23: 0/C000018B The security database on the server does not have a computer account for this workstation trust relationship.
[2020.10.15 20:31:38.396000][2][Microsoft.Mashup.Con][Kerberos ][ 3616] Error for requested algorithm 3: 0/C000018B The security database on the server does not have a computer account for this workstation trust relationship.
如果您查看 WireShark 追蹤,您也可以看到該問題。
注意
可以安全地忽略其他錯誤 KRB5KDC_ERR_PREAUTH_REQUIRED。
解決方法:您必須將 SPN SAP/BW5 新增至服務帳戶中。 詳細的資訊和步驟可參考 SAP 文件。
您可能會遇到類似但與 WireShark 追蹤中指令清單相同的錯誤,如下列錯誤 KRB5KDC_ERR_BADOPTION:
此錯誤表示可以找到 SPN SAP/BW5,但未在閘道服務帳戶的 [委派] 索引標籤中顯示委派認證的服務下。 若要修正此問題,請依照步驟以為標準 kerberos 限制委派設定閘道服務帳戶。
驗證:適當的設定可防止網關呈現泛型或非預期的錯誤。 如果您仍然看到錯誤,請檢查閘道本身的設定或 BW 伺服器的設定。
認證錯誤
本節說明認證錯誤問題的疑難排解徵兆和解決步驟。 您可能也會看到來自 Power BI 服務 的一般錯誤,如先前的委派一節所述。
根據您在資料來源 (SAP BW) 中看到的徵兆,有不同的解決方法,因此我們將同時檢閱這兩種解決方法。
徵兆 1:在 BW Server 的 sec-disp+work[].trc 檔案中,您會看到類似下列的追蹤:
[2020.05.26 14:21:28.668325][4][disp+work ][SAPCRYPTOLIB][435584] { gss_display_name [2020.05.26 14:21:28.668338][4][disp+work ][GSS ][435584] gss_display_name output buffer (41 bytes) [2020.05.26 14:21:28.668338][4][disp+work ][GSS ][435584] CN=DAVID@XS.CONTOSO.COM@CONTOSO.COM
解決方法:完成設定步驟以在閘道電腦上設定使用者對應設定參數 (如果需要的話)。 即使您已經設定了 Microsoft Entra Connect,您也必須完成這些步驟。
驗證:您將能夠在 Power BI 服務中成功載入報表。 如果您無法載入報告,請參閱徵兆 2 中的步驟。
徵兆 2:在 BW Server 的 sec-disp+work[].trc 檔案中,您會看到類似下列的追蹤:
[2020.10.19 23:10:15.469000][4][disp+work.EXE ][SAPCRYPTOLIB][ 4460] { gss_display_name
[2020.10.19 23:10:15.469000][4][disp+work.EXE ][GSS ][ 4460] gss_display_name output buffer (23 bytes)
[2020.10.19 23:10:15.469000][4][disp+work.EXE ][GSS ][ 4460] CN=DAVID@CONTOSO.COM
解決方法:檢查使用者的 Kerberos 外部識別碼是否與 sectrace 顯示的內容相符。
- 開啟 SAP 登入。
- 使用 SU01 交易。
- 編輯使用者。
- 流覽至 [SNC] 索引標籤,並確認 SNC 名稱符合記錄中顯示的名稱。
驗證:正確完成後,您將能夠在 Power BI 服務中建立和重新整理報表。
相關內容
如需內部部署資料閘道和 DirectQuery 的詳細資訊,請參閱下列資源: