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