Microsoft Entra 应用程序代理是本地应用程序的安全且经济高效的远程访问解决方案。 它为“Cloud First”组织提供即时转换路径，用于管理对尚不能使用新式协议的旧本地应用程序的访问权限。 有关更多介绍性信息，请参阅 什么是应用程序代理。
建议使用应用程序代理向远程用户授予对内部资源的访问权限。 应用程序代理取代了这些远程访问用例的 VPN 或反向代理的需求。 它不适用于企业网络上的用户。 使用这些应用程序代理进行 Intranet 访问的用户可能会遇到不良性能问题。
本文包含您规划、操作和管理 Microsoft Entra 应用程序代理所需的资源。
规划实施
以下部分概述了为高效部署体验设置的关键规划元素。
先决条件
在开始实现之前，需要满足以下先决条件。 可以在 本教程中查看有关设置环境的详细信息，包括这些先决条件。
连接器：连接器是一种轻型代理，可以部署到不同的系统上：
- 本地物理硬件
- 在任何虚拟化管理程序解决方案中托管的虚拟机（VM）
- 托管在 Azure 中的 VM，用于启用与应用程序代理服务的出站连接。
有关更详细的概述，请参阅了解Microsoft Entra 专用网络连接器。
在安装连接器之前，必须为连接器计算机启用传输层安全 (TLS) 1.2。
如果可能，请在与后端 Web 应用程序服务器 相同的网络 和段中部署连接器。 完成应用程序检测后，最好部署连接器。
建议每个连接器组至少有两个连接器，以提供高可用性和扩展性。 拥有三个连接器是随时为计算机提供服务的最佳方法。
网络访问设置：Microsoft Entra 专用网络连接器 通过 HTTPS（传输控制协议（TCP）端口 443 和 HTTP（TCP 端口 80）连接到 Azure。
不支持终止连接器的 TLS 流量，这将阻止连接器与各自的 Microsoft Entra 应用程序代理终结点建立安全通道。
避免对连接器和 Azure 之间的出站 TLS 通信进行任何形式的内联检查。 连接器和后端应用程序之间的内部检查是可能的，但可能会降低用户体验，因此不建议这样做。
也不支持连接器本身的负载均衡，甚至没有必要。
配置 Microsoft Entra 应用程序代理之前的重要注意事项
必须满足以下核心要求才能配置和实现 Microsoft Entra 应用程序代理。
Azure 入门：在部署应用代理之前，必须从本地 Active Directory 同步用户身份，或直接在 Microsoft Entra 租户中创建。 标识同步允许Microsoft Entra ID 在授予用户对应用程序代理已发布应用程序的访问权限之前对其进行预身份验证，并具有执行单一登录（SSO）所需的用户标识符信息。
条件访问要求：不建议将应用程序代理用于 Intranet 访问，因为它增加了影响用户的延迟。 建议将应用程序代理与预身份验证和条件访问策略配合使用，以便从 Internet 进行远程访问。 为 Intranet 使用提供条件访问的方法是使应用程序现代化，以便它们可以直接使用 Microsoft Entra ID 进行身份验证。 有关详细信息，请参阅 用于将应用程序迁移到 Microsoft Entra ID 的资源。
服务限制：为防止单个租户过度消耗资源，每个应用程序和租户都设置了限流措施。 若要查看这些限制，请参阅 Microsoft Entra 服务限制和限制。 这些限制是基于超出典型使用量的标准制定的，为大多数部署提供了充足的余量。
公共证书：如果使用自定义域名，则必须购买 TLS 证书。 根据组织要求，获取证书可能需要一些时间，我们建议尽早开始该过程。 Azure 应用程序代理支持标准证书、 通配符或基于 SAN 的证书。 有关详细信息，请参阅 使用 Microsoft Entra 应用程序代理配置自定义域。
域要求：若要使用 Kerberos 约束委派（KCD）进行单一登录，请确保连接器服务器和应用程序服务器都已加入域，同时加入同一域或受信任的域。 连接器服务在本地系统帐户下运行，不应使用自定义标识。 有关详细信息，请参阅 KCD 单点登录。
URL 的 DNS 记录
在应用程序代理中使用自定义域之前，必须在公共域名系统（DNS）中创建 CNAME 记录，使客户端能够将自定义定义的外部 URL 解析为预定义的应用程序代理地址。 未能为使用自定义域的应用程序创建 CNAME 记录会阻止远程用户连接到应用程序。 添加 CNAME 记录所需的步骤可能因 DNS 提供程序而异，因此了解如何 使用 Microsoft Entra 管理中心管理 DNS 记录和记录集。
同样，连接器主机必须能够解析要发布的应用程序的内部 URL。
管理权限和角色
连接器安装 需要 Windows Server 的本地管理员权限，才能安装它。 它还需要至少一个 应用程序管理员 角色才能向 Microsoft Entra 租户进行身份验证和注册连接器实例。
应用程序发布和管理 需要 应用程序管理员 角色。 应用程序管理员可以管理目录中的所有应用程序，包括注册、SSO 设置、用户和组分配和许可、应用程序代理设置和许可。 它不授予管理条件访问的能力。 云应用程序管理员角色具有应用程序管理员的所有功能，但不允许管理应用程序代理设置。
许可：应用程序代理可通过 Microsoft Entra ID P1 或 P2 订阅获得。 有关许可选项和功能的完整列表，请参阅 Microsoft Entra 定价页 。
应用程序发现
通过收集以下信息编译通过应用程序代理发布的所有作用域内应用程序的清单：
| 信息类型 | 要收集的信息 |
|---|---|
| 服务类型 | 例如：SharePoint、SAP、CRM、自定义 Web 应用程序、API |
| 应用程序平台 | 例如：Windows Internet Information Services （IIS）、Linux 上的 Apache、Tomcat、NGINX |
| 域成员身份 | 网络服务器的完全限定域名（FQDN） |
| 应用程序位置 | 您的基础架构中 Web 服务器或服务器场的位置 |
| 内部访问 | 在内部访问应用程序时使用的确切 URL。 如果是服务器场，使用的是什么类型的负载均衡？ 应用程序是否从自身以外的源中提取内容。 确定应用程序是否通过 WebSocket 运行。 |
| 外部访问 | 应用程序可能已经通过供应商解决方案在外部暴露。 要用于外部访问的 URL。 如果 SharePoint，请确保根据 指南配置备用访问映射。 如果没有，则需要定义外部 URL。 |
| 公用证书 | 如果使用自定义域，请获取具有相应主题名称的证书。 如果证书存在，请记下可从中获取该证书的序列号和位置。 |
| 身份验证类型 | 应用程序支持的身份验证类型包括基本身份验证、Windows 集成身份验证、基于表单的身份验证、基于标头的身份验证和声明身份验证。 如果应用程序配置为在特定域帐户下运行，请注意服务帐户的完全限定域名（FQDN）。 如果基于 SAML，则标识符和回复 URL。 如果是基于标头的情况，则供应商解决方案和处理身份验证类型的具体要求。 |
| 连接器组名称 | 指定为向后端应用程序提供连接线和 SSO 的连接器组的逻辑名称。 |
| 用户/组访问权限 | 授予应用程序外部访问权限的用户或用户组。 |
| 更多要求 | 请注意，应在发布应用程序时考虑任何更多的远程访问或安全性要求。 |
可以下载 应用程序清单电子表格 来清点应用。
定义组织要求
组织的业务需求应在以下领域中定义。 每个区域都包含要求示例
Access
具有已加入域或Microsoft Entra 联接设备的远程用户可以使用无缝单一登录（SSO）安全地访问已发布的应用程序。
具有已批准的个人设备的远程用户可以安全地访问已发布的应用程序，前提是他们在 MFA 中注册，并在其移动电话上注册了 Microsoft Authenticator 应用作为身份验证方法。
治理
- 管理员可以定义和监视通过应用程序代理发布的应用程序的用户分配生命周期。
Security
- 只有通过组成员身份或单独分配给应用程序的用户才能访问这些应用程序。
性能
- 与从内部网络访问应用程序相比，应用程序性能不会下降。
用户体验
- 用户了解如何在任何设备平台上使用熟悉的公司 URL 访问其应用程序。
审计
- 管理员可以审核用户访问活动。
关于试点的最佳做法
确定使用单一登录（SSO）完全委托单个应用程序进行远程访问所需的时间和工作量。 通过运行一个试点项目来考虑其初始发掘、上线发布和常规测试过程。 使用为集成 Windows 身份验证（IWA）预配置的基于 IIS 的简单 Web 应用程序有助于建立基线，因为安装程序需要最少的努力才能成功试点远程访问和 SSO。
以下设计元素应直接在生产租户中提高试点实施的成功率。
连接器管理：
连接器在向应用程序提供本地管道方面起着关键作用。 使用 默认 连接器组足以在将已发布应用程序调试到生产环境之前对已发布的应用程序进行初始试点测试。 然后，成功测试的应用程序可以被移动到生产连接器组。
应用程序管理：
员工最有可能记住外部 URL 是熟悉的且相关。 避免使用预定义 msappproxy.net 或 partner.onmschina.cn 后缀发布应用程序。 而是提供熟悉的顶级验证域，其前缀为逻辑主机名，例如 Intranet。<>customers_domain.com。
通过从 Azure MyApps 门户隐藏试点应用程序的启动图标，将试点应用程序的图标的可见性限制为试点组。 准备好上线后，可以将应用的受众范围限定为其各自的目标受众，无论是在相同的“预生产租户”中，还是通过在“生产租户”中发布应用程序。
单一登录设置：某些 SSO 设置具有可能需要时间设置的特定依赖项，因此，通过确保提前解决依赖项，避免更改控制延迟。 此过程包括将连接器主机加入域以使用 Kerberos 约束委派 (KCD) 执行 SSO，并处理其他耗时的任务。
连接器主机与目标应用程序之间的 TLS：安全性至关重要，因此应始终使用连接器主机和目标应用程序之间的 TLS。 特别是如果将 Web 应用程序配置为基于表单的身份验证（FBA），则用户凭据随后会以明文形式有效传输。
以增量方式实现并测试每个步骤。 发布应用程序后进行基本的功能测试，以确保满足所有用户和业务需求：
测试并验证对禁用预身份验证的 Web 应用程序的常规访问。 如果成功，请启用预身份验证并分配用户和组。 然后测试和验证访问权限。 接下来，为应用程序添加 SSO 方法，然后再次进行测试以验证访问权限。 最后，根据需要应用条件访问和 MFA 策略。 测试和验证访问权限。
故障排除工具：通过直接从连接器主机上的浏览器检查对已发布应用程序的访问，开始进行故障排除。 确保应用程序按预期工作。 简化设置以隔离问题，例如使用单个连接器和禁用 SSO。 Telerik 的 Fiddler 等工具可以通过跟踪流量（包括适用于 iOS 和 Android 等移动平台）来帮助调试访问或内容问题。 有关详细信息，请参阅故障排除指南。
实现解决方案
部署应用程序代理
部署应用程序代理的步骤在 添加本地应用程序以实现远程访问的教程 中进行了介绍。 如果安装未成功，请在门户中选择“ 排查应用程序代理 问题”。
通过应用程序代理发布应用程序
发布应用程序假定你满足所有先决条件，并且有多个连接器在应用程序代理页中显示为已注册且处于活动状态。
还可以使用 PowerShell 发布应用程序。
发布应用程序时要遵循的最佳做法：
使用连接器组：分配指定用于发布每个相应应用程序的连接器组。 建议每个连接器组至少有两个连接器，以提供高可用性和扩展性。 在需要随时为计算机提供服务的情况下，拥有三个连接器是最佳的。
设置后端应用程序超时：在应用程序可能需要 75 秒以上的时间来处理客户端事务的情况下，此设置非常有用。 例如，当客户端向充当数据库前端的 Web 应用程序发送查询时。 前端将查询发送到其后端数据库服务器并等待响应，但客户端连接在收到响应之前就超时。将超时时间设置为 180 秒，为更长时间的事务完成提供可能。
使用适当的 Cookie 类型
HTTP-Only Cookie：通过让应用程序代理在 set-cookie HTTP 响应标头中包含 HTTPOnly 标志来提供额外的安全性。 此设置有助于缓解跨站点脚本（XSS）等攻击。 对于需要访问会话 Cookie 的客户端/用户代理，请保留为“否”。 例如，RDP/MTSC 客户端连接到通过应用程序代理发布的远程桌面网关。
安全 Cookie：使用 Secure 属性设置 Cookie 时，仅当请求通过 TLS 安全通道传输请求时，用户代理（客户端应用）才会在 HTTP 请求中包含 Cookie。 此设置有助于缓解通过明文通道泄露 Cookie 的风险，因此应启用。
持久 Cookie：允许应用程序代理会话 Cookie 即使在浏览器关闭后依然有效，直到它过期或被删除为止。 用于丰富应用程序（例如 Office）在已发布的 Web 应用程序中访问文档的场景，而不需要再次提示用户进行身份验证。 但是，请谨慎启用，因为持久性 Cookie 最终可能会使服务面临未经授权的访问风险（如果不与其他补偿控制一起使用）。 此设置仅适用于无法在进程之间共享 Cookie 的较旧应用程序。 最好更新应用程序来处理进程之间共享 Cookie 的问题，而不是依赖相应的设置。
翻译标头中的 URL：适用于无法将内部 DNS 配置为符合组织公共命名空间的场景（即拆分 DNS）的设置。 除非应用程序需要客户端请求中的原始主机标头，否则请将该值设置为“是”。 另一种方法是，连接器使用内部 URL 中的 FQDN 路由实际流量，并将外部 URL 中的 FQDN 用作主机标头。 在大多数情况下，替代方案应允许应用程序在远程访问时正常运行，但用户将失去内部和外部 URL 匹配带来的好处。
在应用程序正文中翻译 URL：如果希望应用的链接在系统响应中被转换回客户端，可以为应用启用应用程序正文链接翻译功能。 如果启用，该函数将尽最大努力尝试转换应用程序代理在 HTML 和 CSS 响应中发现的所有内部链接，并将其返回到客户端。 当发布包含内容中硬编码的绝对链接或 NetBIOS 短名称链接的应用，或者包含链接到其他本地应用程序的内容的应用时，它很有用。
对于已发布的应用链接到其他已发布应用的情况，请为每个应用程序启用链接翻译，以便你能够控制每个应用级别的用户体验。
例如，假设你有三个应用程序通过应用程序代理发布，这些应用程序都相互链接：权益、支出和旅行，以及第四个应用，即未通过应用程序代理发布的反馈。
为权益应用启用链接转换后，支出和旅行应用的链接将重定向到其外部 URL，从而允许外部用户访问它们。 除非为这些应用程序启用了链接翻译，否则从"支出"和"旅行"回到"福利"的链接不起作用。 反馈应用链接不会重定向，因为它缺少外部 URL，从而阻止外部用户通过 Benefits 应用访问它。 有关详细信息，请参阅 链接翻译和重定向选项。
访问应用程序
通过选择最适合方案和可伸缩性要求的方法来管理对应用程序代理已发布资源的访问。 常见方法包括通过 Microsoft Entra Connect 同步本地组、基于用户属性在 Microsoft Entra ID 中创建动态组、启用资源所有者管理的自助服务组或组合这些策略。 浏览链接资源以了解每个方法的优点。
将用户访问权限分配到应用程序的最直接方法是从已发布应用程序的左侧窗格中转到 “用户和组 ”选项，并直接分配组或个人。
还可以通过将用户分配到他们当前未加入的组并配置自助式访问选项，让用户自行访问您的应用程序。
如果已启用，则用户登录到 MyApps 门户以请求访问权限。 它们要么自动批准并添加到自助服务组，要么需要指定审批者的批准。
还可以邀请来宾用户 通过Microsoft Entra B2B 访问通过应用程序代理发布的内部应用程序。
对于通常可匿名访问的本地应用程序，无需身份验证，可能需要禁用位于应用程序 属性中的选项。
将选项设置为“否”可让用户通过 Microsoft Entra 应用程序代理访问本地应用程序，而无需权限，因此请谨慎使用。
发布应用程序后，你可以通过在浏览器中输入其外部 URL 或点击其图标来https://myapplications.windowsazure.cn访问该应用程序。
启用预身份验证
验证应用程序是否可通过应用程序代理通过外部 URL 访问它。
浏览到 Entra ID>企业应用>所有应用程序，然后选择要管理的应用。
选择 应用程序代理。
在 “预身份验证 ”字段中，使用下拉列表选择 Microsoft Entra ID，然后选择“ 保存”。 启用预身份验证后，Microsoft Entra ID 首先对用户进行身份验证。 如果设置了单一登录，后端应用程序还会在授予访问权限之前验证用户。 将预身份验证模式从直通切换为 Microsoft Entra ID 后，将使用 HTTPS 保护外部 URL，确保所有最初通过 HTTP 运行的应用程序现在都通过 HTTPS 运行。
启用单一登录
SSO 通过允许用户使用 Microsoft Entra ID 登录一次，从而提高用户体验和安全性。 预身份验证后，专用网络连接器将登录到用户的本地应用程序，使其看起来就像用户直接登录一样。
选择 直通 选项允许用户访问已发布的应用程序，而无需对 Microsoft Entra ID 进行身份验证。
若要启用 SSO，应用程序必须使用 Microsoft Entra ID 对用户进行预身份验证。 如果没有预身份验证，SSO 选项将不可用。
阅读 Microsoft Entra ID 中应用程序的单点登录，帮助您在配置应用程序时选择最合适的 SSO 方法。
使用其他类型的应用程序
Microsoft Entra 应用程序代理支持使用 Microsoft身份验证库（MSAL）生成的应用程序。 它通过在客户端请求标头中使用 Microsoft Entra ID 令牌进行预身份验证来处理本地客户端应用程序。
了解应用程序代理的可用配置。 请阅读 发布本机和移动客户端应用 和 基于声明的应用程序。
使用条件访问增强安全性
应用程序安全性需要一组高级安全功能，这些功能可以防范和响应本地和云中的复杂威胁。 使用条件访问策略根据许多条件（例如位置、风险、设备类型、设备符合性等）来控制对应用程序的访问。 有关可以部署的策略示例，请参阅条件 访问模板一文。
以下功能可用于支持 Microsoft Entra 应用程序代理：
基于用户和基于位置的条件访问：通过限制基于地理位置或具有 基于位置的条件访问策略的 IP 地址来限制用户访问，从而保护敏感数据。
基于设备的条件访问：确保只有已注册、批准和合规的设备才能使用 基于设备的条件访问访问公司数据。
基于应用程序的条件访问：当用户不在企业网络上时，工作不必停止。 保护对企业云和本地应用的访问 ，并维护对条件访问的控制。
基于风险的条件访问：使用可应用于所有应用和所有用户（无论是本地还是云中）的 基于风险的条件访问策略 保护数据免受恶意黑客的攻击。
Microsoft Entra My Apps：部署应用程序代理服务并安全地发布应用程序后，为用户提供一个简单的中心来发现和访问其所有应用程序。 使用自助服务功能提高工作效率，例如通过 “我的应用”请求访问新应用和组或代表其他人管理对这些资源的访问权限的能力。
管理实施
必需的角色
Microsoft主张授予尽可能少的权限以使用 Microsoft Entra ID 执行所需任务的原则。 查看可用的不同 Azure 角色 ，并选择适当的角色来满足每个角色的需求。 某些角色必须在部署完成后暂时应用和删除。
| 业务角色 | 业务任务 | Microsoft Entra 角色 |
|---|---|---|
| 技术支持管理员 | 处理基本用户支持任务，例如重置密码、使刷新令牌失效以及检查服务运行状况。 | 服务台管理员 |
| 身份管理员 | 读取 Microsoft Entra 登录报告和审核日志以调试应用程序代理相关问题。 | 安全信息读取者 |
| 应用程序所有者 | 创建和管理企业应用程序、应用程序注册和应用程序代理设置的各个方面。 | 应用程序管理员 |
| 基础结构管理员 | 证书轮换所有者 | 应用程序管理员 |
最大程度地减少有权访问安全信息或资源的人员数有助于减少恶意参与者获得未经授权的访问的机会，或者授权用户无意中影响敏感资源。
若要有效管理管理访问权限并确保进行适当的审核，建议在 Privileged Identity Management 中使用实时 （JIT） 访问。 此方法仅在需要时提供对 Azure 资源的按需特权访问和Microsoft Entra ID。
报告和监视
Microsoft Entra ID 通过审核日志和报告更深入地了解组织的应用程序使用情况和作运行状况。 应用程序代理还可以轻松地从 Microsoft Entra 管理中心和 Windows 事件日志监视连接器。
应用程序审核日志
这些日志提供了关于通过应用代理配置的应用程序的登录信息，以及访问该应用程序的设备和用户的详细信息。 审核日志位于 Microsoft Entra 管理中心和用于导出的 审核 API 中。 此外， 使用情况和见解报告 也可用于应用程序。
专用网络接口监控
连接器和服务负责处理所有的高可用性任务。 可以从Microsoft Entra 管理中心的应用程序代理页监视连接器的状态。
Windows 事件日志和性能计数器
连接器具有管理员和会话日志。 管理员日志包括关键事件及其错误。 会话日志包括所有事务及其处理详细信息。 日志和计数器位于 Windows 事件日志中。 按照 本教程在 Azure Monitor 中配置事件日志数据源。
故障排除指南和步骤
详细了解常见问题以及如何通过本指南解决错误消息。
相关内容
以下文章介绍了可用于为支持组织创建故障排除指南的常见方案。