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

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

• 启用/禁用“允许公用客户端流”。
• CWAP_AuthSecret（客户端机密）。
• API 权限。 若在“应用注册”页上修改上述任何配置项目，则将破坏 Microsoft Entra 应用程序代理的预身份验证。

否，应该从 Microsoft Entra 管理中心的“企业应用程序”区域删除应用程序代理应用。 如果从 Microsoft Entra 管理中心的“应用注册”区域删除应用程序代理应用，则可能会遇到问题。

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

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

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

是，应用程序代理和 Microsoft Entra 专用访问都使用 Microsoft Entra 专用网络连接器。 要详细了解连接器，请参阅 Microsoft Entra 专用网络连接器。 要排查连接器配置问题，请参阅连接器疑难解答。

虽然后缀列表中包含这些后缀，但不应使用它们。 这些域后缀不用于与 Microsoft Entra 应用程序代理。 如果使用这些域后缀，则创建的“Microsoft Entra 应用程序代理”应用程序将不起作用。 你可以使用标准域后缀 msappproxy.net 或自定义域。

Microsoft Entra ID 具有应用程序代理服务，使用户能够通过使用其 Microsoft Entra 帐户登录来访问本地应用程序。 如果已在不同区域安装了连接器，可以通过选择距离最近的应用程序代理云服务区域来优化流量，以便与每个连接器组配合使用，详见使用 Microsoft Entra 应用程序代理优化通信流。

上传 SSL 证书后，门户上出现消息“证书无效，密码可能不正确”。

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

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

默认时长为 85 秒。 “长”超时设置为 180 秒。 无法延长超时限制。

不能，目前不支持。

创建 Microsoft Entra 应用程序代理应用时，会自动将客户端机密（也称为 CWAP_AuthSecret）添加到应用程序对象（应用注册）。

客户端机密的有效期为一年。 在当前的有效客户端机密过期之前，会自动创建有效期为一年的新客户端机密。 应用程序对象中始终保留三个 CWAP_AuthSecret 客户端密码。

否，必须使用原始回退域。

所述文章：在 Microsoft 365 中添加和替换 onmicrosoft.com 回退域

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

如果已配置 Microsoft Entra 预身份验证，并且在第一次尝试访问应用程序时应用程序 URL 包含“#”字符，则你会被重定向到 Azure AD (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 服务器是否支持“协商”（Kerberos 身份验证）。 在安装连接器的服务器上不需要 IIS。

应用程序代理不会自动在 HTTPS 响应中添加 HTTP 严格传输安全性标头，但如果标头位于所发布的应用程序发送的原始响应中，则应用程序代理会保留标头。 我们正在开发一项可靠的设置来启用此功能，此项工作已纳入路线图。

不可以，如果在外部 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 用户和计算机”在每个连接器计算机帐户中配置委派设置，使这些帐户可委派到目标 SPN。

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

NTLM 身份验证不能用作预身份验证或单一登录方法。 仅当可以直接在客户端与发布的 Web 应用程序之间协商时，才能使用 NTLM 身份验证。 使用 NTLM 身份验证通常会导致浏览器中出现登录提示。

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

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

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

不可以，不支持此方案，因为应用程序代理将终止 TLS 流量。

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

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

是的，这是预期的情况。 预身份验证方案需要某个 ActiveX 控件，而第三方浏览器并不支持此控件。

支持，此方案目前为公共预览版。 请参阅使用 Microsoft Entra 应用程序代理发布远程桌面。

是的，这是预期的情况。 如果用户的计算机已与 Microsoft Entra 联接，则用户会自动登录到 Microsoft Entra ID。 用户只需在 RDWeb 登录窗体中提供凭据。

使用此选项，用户可下载 rdp 文件，并通过（远程桌面 Web 客户端之外的）其他 RDP 客户端使用它。 通常，其他 RDP 客户端（如 Microsoft 远程桌面客户端）无法本机处理预身份验证。 这就是方案不起作用的原因。

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

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

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

否，不支持。

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

• 在打开 WebSocket 连接时，应用程序代理会丢弃在服务器响应上设置的 Cookie。
• 没有应用于 WebSocket 请求的 SSO。
• Windows 管理中心 (WAC) 内的功能（事件日志、PowerShell 和远程桌面服务）无法通过 Microsoft Entra 应用程序代理运行。

WebSocket 应用程序没有任何唯一的发布要求，其发布方式可以与所有其他“应用程序代理”应用程序相同。

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

为获得最佳性能，我们建议通过配置自定义域来使用相同的内部和外部 URL。 如果无法使用自定义域，可以使用“我的应用安全登录扩展”或手机版 Microsoft Edge 浏览器来改进链接转换性能。 请参阅使用 Microsoft Entra 应用程序代理重定向已发布应用的硬编码链接。

无法直接支持此方案。 对于此方案，可行的做法如下：

1. 使用通配符将 HTTP 和 HTTPS URL 发布为单独的应用程序，但为每个应用程序指定不同的自定义域。 此配置会起作用，因为应用程序具有不同的外部 URL。

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

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