Microsoft Entra 應用程式 Proxy 常見問題

否，應用程式 Proxy 會使用下列設定項目，而且不得加以變更或刪除：

• 啟用/停用 [允許公用用戶端流程]。
• CWAP_AuthSecret (用戶端祕密)。
• API 權限。 在 [應用程式註冊] 頁面上修改上述任何設定項目，會中斷 Microsoft Entra 應用程式 Proxy 的預先驗證。

否，您應該從 Microsoft Entra 系統管理中心的 [企業應用程式] 區域刪除應用程式 Proxy 應用程式。 若從 Microsoft Entra 系統管理中心的 [應用程式註冊] 區域刪除應用程式 Proxy 應用程式，則可能會遇到問題。

若要使用 Microsoft Entra 應用程式 Proxy，您必須擁有 Microsoft Entra ID P1 或 P2 授權。 如需授權的詳細資訊，請參閱 Microsoft Entra 價格

若授權過期，系統會自動停用應用程式 Proxy。 您的應用程式資訊最多會儲存一年。

請確定您至少擁有 Microsoft Entra ID P1 或 P2 授權，並已安裝 Microsoft Entra 私人網路連接器。 在您成功安裝第一個連接器之後，系統會自動啟用 Microsoft Entra 應用程式 Proxy 服務。

除了埠 80 和/或 443 之外，在應用程式 Proxy 公用端點上使用連接埠掃描公用程式 (msappproxy.net 或自訂) 可能會顯示 TCP 連接埠 10200 和 10201 已開啟。 這些連接埠用於內部服務健康情況監視用途。 無法透過這些連接埠存取客戶資料，且其背後的服務不會處理任何資訊；他們只是簡單以 「確定」 回應。

是，應用程式 Proxy 和 Microsoft Entra 私人存取都使用 Microsoft Entra 私人網路連接器。 若要深入了解連接器，請參閱 Microsoft Entra 私人網路連接器。 若要針對連接器設定進行疑難排解，請參閱針對連接器進行疑難排解。

雖然這些尾碼出現在尾碼清單中，但您不應該使用這些尾碼。 這些網域尾碼並非要與 Microsoft Entra 應用程式 Proxy 搭配使用。 若使用這些網域尾碼，則已建立的 Microsoft Entra 應用程式 Proxy 應用程式將無法運作。 您可以使用標準網域尾碼 msappproxy.net 或自訂網域。

Microsoft Entra ID 有一項應用程式 Proxy 服務，可讓使用者使用其 Microsoft Entra 帳戶登入來存取內部部署應用程式。 若已在不同區域中安裝連接器，則可選取最接近的應用程式 Proxy 雲端服務區域來與每個連接器群組搭配使用，以將流量最佳化，詳情請參閱使用 Microsoft Entra 應用程式 Proxy 將流量最佳化。

上傳 SSL 憑證之後，您在入口網站上收到 "Invalid certificate, possible wrong password" (無效憑證，可能密碼錯誤) 的訊息。

以下是針對此錯誤進行疑難排解的一些提示：

• 檢查憑證是否有問題。 在您的本機電腦上安裝憑證。 如果您沒有遇到任何問題，則代表憑證是正常的。
• 確定密碼未包含任何特殊字元。 密碼只能包含 0-9、A-Z 和 a-z 字元。
• 如果是使用 Microsoft 軟體金鑰儲存體提供者來建立憑證，則必須使用 RSA 演算法。

預設長度為 85 秒。 「長」設定為 180 秒。 無法延長逾時限制。

否，目前不支援。

建立 Microsoft Entra 應用程式 Proxy 應用程式時，系統會自動將用戶端密碼 (也稱為 CWAP_AuthSecret) 新增至應用程式物件 (應用程式註冊)。

用戶端密碼有效期限為一年。 在目前的有效用戶端密碼過期之前，系統會自動建立一個新的一年用戶端密碼。 系統會一律在應用程式物件中保存三個 CWAP_AuthSecret 用戶端密碼。

否，您必須使用原始後援網域。

提到的文章：在 Microsoft 365 中新增和取代您的 onmicrosoft.com 後援網域

從 [應用程式註冊] 頁面，您可以將登陸頁面的首頁 URL 變更為想要的外部 URL。 從 [我的應用程式] 或 Office 365 入口網站啟動應用程式時，系統會載入指定的頁面。 如需設定步驟，請參閱使用 Microsoft Entra 應用程式 Proxy 為發佈的應用程式設定自訂首頁

如果已設定 Microsoft Entra 預先驗證，且在您第一次嘗試存取應用程式時，應用程式 URL 包含 "#" 字元，則會重新導向至 Microsoft Entra ID (login.microsoftonline.com) 進行驗證。 完成驗證之後，您會重新導向至 "#" 字元之前的 URL 部分，而 "#" 之後的所有內容似乎都會被忽略/移除。 例如，如果 URL 是 https://www.contoso.com/#/home/index.html，完成 Microsoft Entra 驗證後，使用者就會重新導向至 https://www.contoso.com/。 這是基於瀏覽器對 "#" 字元的處理方式，而刻意設計的行為。

可能的解決方案/替代方案：

• 設定從 https://www.contoso.com 到 https://contoso.com/#/home/index.html 的重新導向。 使用者必須先存取 https://www.contoso.com。
• 第一次存取嘗試所使用的 URL，必須包含編碼格式的 "#" 字元 (%23)。 已發佈的伺服器可能不接受此格式。
• 設定傳遞預先驗證類型 (不建議使用)。

否，針對已發佈的應用程式並沒有 IIS 需求。 您可以發佈在 Windows Server 以外的伺服器上執行的 Web 應用程式。 不過，您可能無法對非 Windows Server 使用預先驗證，這取決於該 Web 伺服器是否支援 Negotiate (Kerberos 驗證)。 安裝連接器的伺服器上不需要 IIS。

應用程式 Proxy 不會自動將 HTTP Strict-Transport-Security 標頭新增至 HTTPS 回應中，但若標頭存在於已發佈應用程式所傳送的原始回應中，則會維持該標頭。 我們預計於未來提供啟用此功能的設定。

否，如果通訊協定 http 是在外部 URL 中設定，則 Microsoft Entra 應用程式 Proxy 端點會接受連接埠 TCP 80 上的連入要求，如果通訊協定為 https，則接受連接埠 TCP 443 上的連入要求。

是，有些內部 URL 範例可以，包括連接埠：http://app.contoso.local:8888/、https://app.contoso.local:8080/、https://app.contoso.local:8081/test/。

已發佈 Web 應用程式所傳送的某些回應可能會包含硬式編碼 URL。 在此情況下，必須使用用戶端一律使用正確 URL 的連結轉譯解決方案予以確保。 連結轉譯解決方案可能十分複雜，而且可能無法在所有案例中運作。 您可以在這裡找到我們記載的連結轉譯解決方案。

最佳做法是建議使用相同的外部和內部 URL。 如果外部和內部 URL 中的 protocol://hostname:port/path/ 相同，則會將這兩個 URL視為相同。

這可以使用自訂網域功能來達成。

範例：

相同：

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

不相同：

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

如果內部 URL 包含非標準連接埠 (TCP 80 / 443 以外)，則完全無法讓外部和內部 URL 相同。

在某些情況下，必須在 Web 應用程式的設定中完成變更。

當連接器伺服器與 Web 應用程式服務帳戶位於不同的網域時，會使用 PrincipalsAllowedToDelegateToAccount 方法。 其需要使用資源型限制委派。 若連接器伺服器和 Web 應用程式服務帳戶位於相同的網域中，您可以使用 Active Directory 使用者和電腦來設定每個連接器電腦帳戶上的委派設定，使其可以委派至目標 SPN。

若連接器伺服器和 Web 應用程式服務帳戶位於不同的網域，則會使用資源型委派。 系統會在目標 Web 伺服器和 Web 應用程式服務帳戶上設定委派權限。 這種限制委派的方法還很新。 此方法是在 Windows Server 2012 引進的，可讓資源 (Web 服務) 擁有者控制有哪些電腦和服務帳戶可以委派至該資源，以支援跨網域委派。 沒有 UI 可協助進行此設定，因此您需要使用 PowerShell。 如需詳細資訊，請參閱白皮書了解使用應用程式 Proxy 的 Kerberos 限制委派。

NTLM 驗證無法作為預先驗證或單一登入方法使用。 只有當您可以在用戶端和已發佈的 Web 應用程式之間直接對 NTLM 驗證進行交涉時，才可以使用 NTLM 驗證。 使用 NTLM 驗證通常會造成登入提示出現在瀏覽器中。

否，您無法這麼做，因為 Microsoft Entra ID 中的來賓使用者沒有上述任何登入身分識別所需的屬性。

在此情況下，會遞補成「使用者主體名稱」。 如需 B2B 案例的詳細資料，請參閱授與 Microsoft Entra ID 的 B2B 使用者您內部部署應用程式的存取權。

條件式存取原則只會針對在 Microsoft Entra ID 中成功預先驗證的使用者強制執行。 傳遞預先驗證不會觸發 Microsoft Entra 驗證，因此無法強制執行條件式存取原則。 使用傳遞預先驗證時，必須盡可能在內部部署伺服器上實作 MFA 原則，或透過 Microsoft Entra 應用程式 Proxy 啟用 Microsoft Entra ID 預先驗證。

否，不支援此案例，因為應用程式 Proxy 會終止 TLS 流量。

請參閱使用 Microsoft Entra 應用程式 Proxy 發佈遠端桌面。

否，不支援此案例。

是，這是預期的現象。 預先驗證案例需要 ActiveX 控制項，但協力廠商瀏覽器中並不支援。

是，此案例目前處於公開預覽狀態。 請參閱使用 Microsoft Entra 應用程式 Proxy 發佈遠端桌面。

是，這是預期的現象。 如果使用者的電腦已聯結 Microsoft Entra，則使用者會自動登入 Microsoft Entra ID。 使用者只需要在 RDWeb 登入表單上提供其認證。

此選項可讓使用者下載 rdp 檔案，並另一個 RDP 用戶端加以使用 (在遠端桌面 Web 用戶端以外)。 一般而言，其他 RDP 用戶端 (如 Microsoft 遠端桌面用戶端) 無法以原生方式處理預先驗證。 這就是為什麼案例無法運作的原因。

請參閱使用 Microsoft Entra 應用程式 Proxy 啟用對 SharePoint 的遠端存取。

SharePoint 行動應用程式目前不支援 Microsoft Entra 預先驗證。

否，Microsoft Entra 應用程式 Proxy 是設計用來與 Microsoft Entra ID 搭配使用，且無法滿足作為 AD FS Proxy 的需求。

不行，目前不支援此功能。

現在支援使用 WebSocket 通訊協定的應用程式，例如 QlikSense 和遠端桌面 Web 用戶端 (HTML5)。 以下是已知的限制：

• 在開啟 WebSocket 連線時，應用程式 Proxy 會捨棄在伺服器回應上設定的 Cookie。
• 沒有任何 SSO 套用至 WebSocket 要求。
• 無法透過 Microsoft Entra 應用程式 Proxy 運作 Windows Admin Center (WAC) 中的功能 (Eventlogs、PowerShell 和遠端桌面服務)。

WebSocket 應用程式沒有任何特有的發佈需求，且可以用其他所有應用程式 Proxy 應用程式的相同方式來發佈。

是。 連結轉譯會影響效能。 應用程式 Proxy 服務會掃描應用程式中的硬式編碼連結，並將其取代為其各自發佈的外部 URL，然後再呈現給使用者。

為了達到最佳效能，建議您透過設定自訂網域來使用完全相同的內部和外部 URL。 若無法使用自訂網域，您可以透過在行動裝置上使用 [我的應用程式安全登入延伸模組] 或 [Microsoft Edge 瀏覽器] 來改善連結轉譯效能。 請參閱針對使用 Microsoft Entra 應用程式 Proxy 發佈的應用程式，重新導向硬式編碼的連結。

無法直接支援此案例。 針對此案例，您的選項為：

1. 使用萬用字元將 HTTP 和 HTTPS URL 發佈為個別的應用程式，但個別為這兩個應用程式提供不同的自訂網域。 這種設定之所以可行，是因為這兩者具有不同的外部 URL。

2. 透過萬用字元應用程式發佈 HTTPS URL。 使用下列應用程式 Proxy PowerShell Cmdlet 個別發佈 HTTP 應用程式：

   • 應用程式 Proxy 應用程式管理
   • 私人網路連接器管理