Microsoft Entra应用程序代理常见问题

否，应用代理正在使用以下配置项目，不应更改或删除：

• 启用/禁用“允许公共客户端流”。
• 联合凭据。
• API 权限。 在“应用注册”页上修改上述任何配置项目会中断Microsoft Entra应用程序代理的预身份验证。

Application Proxy应用不再依赖于 CWAP 机密。 对于使用 Entra ID 预身份验证的应用，现在将改用联合标识凭据（FIC）。 FIC 更安全，不会过期，并且维护需求显著减少。 使用透传预身份验证配置的应用程序或使用访问令牌的应用程序不需要联合身份凭证，即使以前创建了 FIC。

可以安全地忽略应用代理应用程序注册中的任何现有 CWAP 机密，并清理旧的或已过期的机密。 有关联合标识凭据的详细信息，请参阅Microsoft Entra ID 中联合标识凭据的概述。

否，应从Microsoft Entra管理中心的 Enterprise 应用程序区域中删除应用程序代理应用。 如果从 Microsoft Entra 管理中心的 App registrations 区域中删除应用程序代理应用，则可能会遇到问题。

若要使用Microsoft Entra应用程序代理，必须具有Microsoft Entra ID P1 或 P2 许可证。 有关许可的详细信息，请参阅 Microsoft Entra 定价

如果许可证过期，则会自动禁用应用程序代理。 应用程序信息最多保存一年。

请确保至少安装了 Microsoft Entra ID P1 或 P2 许可证和Microsoft Entra专用网络连接器。 成功安装第一个连接器后，会自动启用Microsoft Entra应用程序代理服务。

是的，Microsoft Entra 专用网络连接器被应用程序代理和 Microsoft Entra Private Access 所使用。

ConnectorTroubleshooterLauncher.exe 已弃用，不再正常运行。 目前，没有可用的替换项。

不支持更改连接器或更新程序服务的登录用户。

正确配置：

Microsoft Entra专用网络连接器：Network Service Microsoft Entra专用网络连接器更新程序：NT Authority\System

否。 Application Proxy应用不再依赖于客户端机密（CWAP_AuthSecret）。 对于使用Microsoft Entra ID预身份验证的应用，现在将改用联合标识凭据（FIC）。 FIC 更安全，不会过期，无需手动轮换或维护。 使用直通预身份验证配置的应用程序或使用访问令牌的应用程序不需要联合标识凭据。 可以安全地忽略应用注册中的任何现有 CWAP 机密，并删除旧机密或过期的机密。 有关详细信息，请参阅 Microsoft Entra ID 中联合标识凭据的概述。

尽管这些后缀显示在后缀列表中，但不应使用这些后缀。 这些域后缀不用于Microsoft Entra应用程序代理。 如果使用这些域后缀，则创建的Microsoft Entra应用程序代理应用程序将不起作用。 可以使用标准域后缀 msappproxy.net 或 自定义域。

Microsoft Entra ID有一个应用程序代理服务，允许用户使用其Microsoft Entra帐户登录来访问本地应用程序。 如果已在不同区域安装了连接器，则可以通过选择与每个连接器组一起使用的最近的应用程序代理云服务区域来优化流量，详情请参阅 使用 Microsoft Entra 应用程序代理优化流量。

上传 SSL 证书后，会在门户中收到消息“证书无效，密码可能错误”。

下面是排查此错误的一些提示：

• 检查证书是否存在问题。 在本地计算机上安装它。 如果没有遇到任何问题，则证书是好的。
• 确保密码不包含任何特殊字符。 密码应仅包含字符 0-9、A-Z 和 a-z。
• 如果证书是使用Microsoft软件密钥存储提供程序创建的，则必须使用 RSA 算法。

默认长度为 85 秒。 “long”设置为 180 秒。 无法扩展超时限制。

否，目前不支持此功能。

否，必须使用原始备选域名。

有关提到的文章：在 Microsoft 365 中添加和替换你的 partner.onmschina.cn 回退域

在“应用程序注册”页中，可以将主页 URL 更改为登陆页面的所需外部 URL。 从My Apps或Office 365门户启动应用程序时，将加载指定的页面。 有关配置步骤，请参阅 使用 Microsoft Entra 应用程序代理为已发布的应用设置自定义主页

如果配置了Microsoft Entra预身份验证，并且首次尝试访问应用程序时应用程序 URL 包含“#”字符，则会重定向到Microsoft Entra ID（login.partner.microsoftonline.cn）进行身份验证。 完成身份验证后，你会在“#”字符之前重定向到 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。

应用程序代理不会自动将 HTTP Strict-Transport-Security 标头添加到 HTTPS 响应，但如果标头位于已发布应用程序发送的原始响应中，它将维护标头。 提供启用此功能的设置已列入路线图。

否，如果在外部 URL 中配置了协议http，则Microsoft Entra应用程序代理终结点接受端口 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 Users and Computers在每个连接器计算机帐户上配置委派设置，从而允许它们委托到目标 SPN。

如果连接器服务器和 Web 应用程序服务帐户位于不同的域中，则使用基于资源的委派。 在目标 Web 服务器和 Web 应用程序服务帐户上配置委派权限。 约束委派的此方法相对较新。 该方法是在 Windows Server 2012 中引入的，它通过允许资源（Web 服务）所有者控制哪些计算机和服务帐户可以委托给它，从而支持跨域委派。 没有 UI 可协助此配置，因此需要使用 PowerShell。 有关详细信息，请参阅白皮书 《理解使用应用程序代理的 Kerberos 约束委派》。

NTLM 身份验证不能用作预身份验证或单一登录方法。 NTLM 身份验证只能在客户端和已发布的 Web 应用程序之间直接协商时使用。 使用 NTLM 身份验证通常会导致在浏览器中显示登录提示。

否，这不起作用，因为Microsoft Entra ID中的来宾用户没有上述任何登录标识所需的属性。

在这种情况下，会退回到“用户主体名称”。 有关 B2B 场景的更多详细信息，请阅读 在 Microsoft Entra ID 中为 B2B 用户授予本地应用程序的访问权限。

仅对Microsoft Entra ID中经过身份验证的用户强制实施条件访问策略。 直通预身份验证不会触发Microsoft Entra身份验证，因此无法强制实施条件访问策略。 使用直通预身份验证时，必须在本地服务器上实现 MFA 策略（如果可能），或者通过Microsoft Entra应用程序代理启用Microsoft Entra ID预身份验证。

否，此方案不受支持，因为应用程序代理会终止 TLS 流量。

请参阅通过 Microsoft Entra 应用程序代理发布远程桌面。

不可以，不支持这种方案。

是的，这是预期的。 预身份验证方案需要 ActiveX 控件，该控件在第三方浏览器中不受支持。

是的，该方案目前正在公共预览版提供。 请参阅使用 Microsoft Entra 应用程序代理发布远程桌面。

是的，这是预期的。 如果用户的计算机已加入Microsoft Entra，则用户会自动登录Microsoft Entra ID。 用户只需在 RDWeb 登录表单上提供其凭据。

此选项允许用户下载 rdp 文件，并将其由另一个 RDP 客户端（Remote Desktop Web 客户端外部）使用。 通常，另一个 RDP 客户端（如Microsoft Remote Desktop客户端）无法本机处理预身份验证。 这就是方案不起作用的原因。

请参阅 使用 Microsoft Entra 应用程序代理启用 SharePoint 的远程访问。

SharePoint移动应用目前不支持Microsoft Entra预身份验证。

否，Microsoft Entra应用程序代理旨在与Microsoft Entra ID配合使用，并且不符合充当 AD FS 代理的要求。

否，不支持。

现在支持使用 WebSocket 协议的应用程序，例如 QlikSense 和 Remote Desktop Web 客户端（HTML5）。 以下是已知限制：

• 应用程序代理在打开 WebSocket 连接时会丢弃服务器响应中设置的 Cookie。
• WebSocket 请求没有应用 SSO。
• Windows Admin Center（WAC）中的功能（Eventlogs、PowerShell 和 Remote Desktop Services）无法通过Microsoft Entra应用程序代理工作。

WebSocket 应用程序没有任何唯一的发布要求，可以像所有其他应用程序代理应用程序一样 发布 。

是的。 链接翻译会影响性能。 应用程序代理服务扫描应用程序以获取硬编码的链接，并将其替换为其各自的已发布外部 URL，然后再将链接呈现给用户。

为了获得最佳性能，我们建议通过配置 自定义域来使用相同的内部和外部 URL。 如果无法使用自定义域，则可以通过使用My Apps安全登录扩展或移动设备上的 Microsoft Edge Browser 来提高链接转换性能。 请参阅 使用Microsoft Entra应用程序代理发布的应用的直接硬编码链接。

此方案不受直接支持。 在此场景中，您的选项是：

1. 使用通配符将 HTTP 和 HTTPS URL 作为单独的应用程序发布，但为每个 URL 提供不同的自定义域。 此配置的工作原理是因为它们具有不同的外部 URL。

2. 通过通配符应用程序发布 HTTPS URL。 使用这些应用程序代理 PowerShell cmdlet 单独发布 HTTP 应用程序：

   • 应用程序代理应用程序管理
   • 专用网络连接器管理