计划部署 Microsoft Entra 以通过 SAP 源和目标应用实现用户预配

项目
08/13/2024

你的组织依赖 Microsoft 提供各种 Azure 服务或 Microsoft 365。 SAP 软件和服务还能为组织提供关键功能，例如人力资源 (HR) 和企业资源规划 (ERP)。你可以使用 Microsoft Entra 来协调员工、合同工和其他人的标识以及他们在 SAP 和非 SAP 应用程序中的访问权限。

本教程介绍如何根据源自 SAP HR 源的身份的属性，使用 Microsoft Entra 功能来管理 SAP 应用程序中的身份。本教程做出如下假设：

你的组织在商业云中有一个 Microsoft Entra 租户，并且该租户中至少拥有 Microsoft Entra ID P1 许可证。（一些步骤还说明使用 Microsoft Entra ID 治理功能。）
你是该租户的管理员。
你的组织拥有工作人员记录来源系统 SAP SuccessFactors。
你的组织拥有 SAP ERP 中央组件 (ECC)、SAP S/4HANA 或其他 SAP 应用程序，以及其他非 SAP 应用程序（视需求而定）。
你使用 SAP Cloud Identity Services 实现预配，并为各种 SAP 应用程序（SAP ECC 除外）提供单一登录 (SSO) 功能。

概述

本教程演示如何将 Microsoft Entra 与组织中工作人员列表的权威来源（例如 SAP SuccessFactors）连接起来。其中还会介绍如何使用 Microsoft Entra 为这些工作人员设置标识。然后，介绍如何使用 Microsoft Entra 为工作人员提供登录一个或多个 SAP 应用程序（例如 SAP ECC 或 SAP S/4HANA）的访问权限。

过程如下：

规划：定义组织中应用程序的身份验证和访问控制权限要求。确保 Microsoft Entra ID 和相关的 Microsoft Online Services 满足此方案的组织先决条件。
部署：将所需的用户引入 Microsoft Entra ID，并建立流程以确保这些用户获得适当的最新凭据。在 Microsoft Entra 中为用户分配所需的访问权限。预配这些用户及其对应用程序的访问权限，使他们能够登录到这些应用程序。
监视：监视身份流以监视错误，并根据需要调整策略和操作。

完成该过程后，个人可以使用 Microsoft Entra 用户身份登录到他们有权使用的 SAP 和非 SAP 应用程序。

下图描绘了本教程中使用的示例拓扑。在此拓扑中，工作人员以 SuccessFactors 表示，并且需要在 Windows Server Active Directory (Windows Server AD) 域、Microsoft Entra、SAP ECC 和 SAP 云应用程序中具有帐户。本教程将演示具有 Windows Server AD 域的组织。但是，本教程不需要 Windows Server AD。

本教程重点介绍代表员工和其他工作人员的用户的身份生命周期。来宾的身份生命周期以及角色分配、请求和审核的访问生命周期不在本教程的范围内。

规划与 SAP 源和目标的集成

在本部分，你将定义组织中应用程序所需的身份和访问权限要求。本部分重点介绍与 SAP 应用程序集成所需的关键决策。对于非 SAP 应用程序，还可以定义组织策略来管理对这些应用程序的访问。

如果一直在使用 SAP IDM，则可以将标识管理方案从 SAP IDM 迁移到 Microsoft Entra。有关详细信息，请参阅将标识管理方案从 SAP IDM 迁移到 Microsoft Entra。

确定加入应用程序的顺序以及应用程序如何与 Microsoft Entra 集成

你的组织可能已经将一些应用程序与 Microsoft Entra 集成，以实现部分可用集成方案。例如，可能已将 SAP Cloud Identity Services 与 Microsoft Entra 集成以实现 SSO，从而享受到了条件访问的优势，但仍然需要以手动方式完成预配和取消预配。或者，组织中可能有尚未与 Microsoft Entra 集成的应用程序（例如 SAP ECC）。

为要与 Microsoft Entra 集成的应用程序排定优先顺序，以便实现 SSO 和预配。 通常情况下，组织可从集成支持新式协议的软件即服务 (SaaS) 应用程序入手。对于 SAP 应用程序，建议拥有 SAP 云应用程序的组织从 SSO 开始集成，并使用 SAP Cloud Identity Services 作为中间件预配集成。在这一阶段，将用户预配和 SSO 功能与 Microsoft Entra 集成可以使多个 SAP 应用程序受益。
确认每个应用程序如何与 Microsoft Entra 集成。 如果应用程序被列为 SAP Cloud Identity Services 预配目标系统之一（例如 SAP S/4HANA），则你可以使用 SAP Cloud Identity Services 作为中间件，以便将 SSO 和预配功能从 Microsoft Entra 桥接到应用程序。如果你的应用程序是 SAP ECC，则可以将 Microsoft Entra 直接与 SAP NetWeaver 集成以实现 SSO，并将其与 SAP ECC 的业务应用程序编程接口 (BAPI) 集成以进行预配。

对于非 SAP 应用程序，请按照将应用程序与 Microsoft Entra ID 集成中的说明进行操作，以确定每个应用程序的 SSO 和预配功能支持的集成技术。
收集每个应用程序提供的角色和权限。 某些应用程序只有一个角色。例如，SAP Cloud Identity Services 仅有一个“用户”角色可供分配。 SAP Cloud Identity Services 可以从 Microsoft Entra ID 读取组以用于应用程序分配。其他应用程序可能会具有多个角色，可通过 Microsoft Entra ID 进行管理。这些应用程序角色通常对具有该角色的用户在应用中的访问权限施加广泛约束。

其他应用程序还可能依赖于组成员资格或声明进行更精细的角色检查。可以通过 Microsoft Entra ID 以预配方式将它们提供给每个应用程序，或者使用联合 SSO 协议颁发的声明来提供。还可以将其作为安全组成员资格写入 Active Directory。

注意

如果使用的是 Microsoft Entra 应用程序库中支持预配的应用程序，Microsoft Entra ID 可能会在应用程序中导入已定义的角色，并在配置预配后自动使用应用程序的角色更新应用程序清单。
选择哪些角色和组具有要在 Microsoft Entra ID 中接受管理的成员资格。 根据合规性和风险管理要求，组织通常会优先考虑授予特权访问或敏感信息访问权限的应用程序角色或组。尽管本教程不介绍配置访问权限分配的步骤，但你可能需要确定相关的角色和组，以确保将其所有成员预配到应用程序。

根据访问应用程序的用户先决条件和其他限制来定义组织的策略

在本部分中，你将确定计划用于确定对每个应用程序的访问权限的组织策略。

确定用户在获得应用程序访问权限之前是否必须满足某些先决条件要求或标准。 具有合规性要求或风险管理计划的组织拥有敏感或业务关键型应用程序。在将这些应用程序与 Microsoft Entra ID 集成之前，你可能已经记录了哪些人“应该有权访问”这些应用程序的访问策略。如果没有，你可能需要咨询合规和风险管理团队等利益干系人。需要确保用于自动化访问决策的策略适合你的方案。

例如，在正常情况下，默认只有全职员工或特定部门或成本中心的员工才有权访问特定部门的应用程序。如果你在 Microsoft Entra ID 治理中使用 Microsoft Entra 权利管理，则可以选择为请求访问权限的其他部门的用户配置权利管理策略，使其具有一位或多位审批者，以便这些用户可以凭借特殊情况获得访问权限。

在某些组织中，员工的访问请求可能要经过两个阶段的审批。第一个阶段请求用户的经理。第二个阶段请求负责应用程序中保存的数据的资源所有者之一。
决定已获准访问的用户应具有访问权限多长时间，以及该访问权限何时失效。 对于许多应用程序，用户可能会无限期地保留访问权限，直到它们不再与组织关联。在某些情况下，访问可能会绑定到特定项目或里程碑，以便在项目结束时自动删除访问权限。或者，如果只有少数用户通过策略使用应用程序，则可以通过该策略配置对每个人访问的季度或每年评审，以便定期进行监督。这些方案需要用到 Microsoft Entra ID 治理。
如果组织已使用组织角色模型来管理访问，请制定计划，以将该组织角色模型引入 Microsoft Entra ID。 你可能定义了组织角色模型，该模型根据用户的属性（例如其职位或部门）分配访问权限。即使没有预先确定的项目结束日期，这些进程也可以确保用户最终在不再需要访问时失去访问权限。

如果已有组织角色定义，则可以将组织角色定义迁移到 Microsoft Entra ID 治理。
询问是否存在基于职责分离的限制。 本教程重点介绍身份生命周期，以便为用户提供对应用程序的基本访问权限。但是，当你规划应用程序加入时，可以根据要强制实施的职责分离来确定约束。

例如，假设你的应用程序具有两个应用角色（“西部销售”和“东部销售”）。你想要确保某个用户在某个时间只属于一个销售管辖区。包括一个列表，列出与你的应用程序不兼容的所有成对应用角色。这样，如果用户拥有成对角色中的一个角色，则他们不能请求另一个角色。可通过访问包上的 Microsoft Entra 权利管理不兼容性设置强制实施这些限制。
选择适当的条件访问策略以访问各个应用程序。 我们建议你分析应用程序并将其组织成对相同用户具有相同资源要求的应用程序集合。

首次将联合 SSO 应用程序与 Microsoft Entra ID 集成时，可能需要创建新的条件访问策略来表达约束。可能需要对该应用程序和后续应用程序强制实施多重身份验证 (MFA) 或基于位置的访问的要求。还可以在条件访问中进行配置，要求用户必须同意使用条款。

有关如何定义条件访问策略的更多注意事项，请参阅规划条件访问部署。
决定如何处理标准的例外情况。 例如，应用程序通常仅适用于指定员工，但审核员或供应商可能需要对特定项目进行临时访问。或者，旅行的员工可能需要从通常被阻止的位置（因为你的组织在该位置没有办事处）进行访问。

在这些情况下，如果你使用 Microsoft Entra ID 治理，则可以选择具有不同阶段、不同时间限制或不同的审批者的权利管理策略。在 Microsoft Entra 租户中以来宾用户身份登录的供应商可能没有经理。在这种情况下，其组织的发起人、资源所有者或安全管理人员可以审批他们的访问请求。

确定预配和身份验证拓扑

确定要与 Microsoft Entra 集成以实现用户预配和 SSO 功能的应用程序后，请根据来自权威记录源系统的数据，决定如何向这些应用程序提供用户身份及其属性的数据流。

为每个身份及其属性选择权威来源。 本教程假设 SuccessFactors 是需要访问 SAP 应用程序的用户的权威记录源系统。配置从 SuccessFactors 到 Microsoft Entra ID 的云 HR 驱动的用户预配要求在规划中涵盖不同的方面。这些因素包括确定匹配 ID 和定义属性映射、属性转换和范围筛选器。

有关这些主题的综合指导，请参阅云 HR 部署计划。若要了解支持的实体、处理详细信息，以及为不同 HR 场景自定义集成的方式，请参阅 SAP SuccessFactors 集成参考。对于其他身份，你可能还拥有其他权威来源，并且某些身份（例如“破窗”帐户或其他 IT 管理员）将 Microsoft Entra ID 作为其权威来源。
确定除 Microsoft Entra ID 之外，是否存在用户或需要将用户配置到 Windows Server AD 中。 现有用户可能已经出现在 Windows Server AD 中，这些用户与权威 HR 源中的工作人员相对应。或者，你可能已通过轻型目录访问协议 (LDAP) 或 Kerberos 将 SAP ECC 或其他应用程序配置为依赖 Windows Server。在这些情况下，需要将用户预配到 Windows Server AD 中。然后，这些用户将同步到 Microsoft Entra ID。
设计 Microsoft Entra Connect 预配代理部署拓扑。 如果使用 SuccessFactors 并具有 Windows Server AD，则需要安装预配代理，将用户预配到这些域中。 Microsoft Entra Connect 预配代理部署拓扑取决于你计划集成的云 HR 应用租户和 Active Directory 子域的数量。如果有多个 Active Directory 域，它取决于 Active Directory 域是连续的还是非连续的。更多信息，请参阅设计 Microsoft Entra Connect 预配代理部署拓扑。
确定是否在 Windows Server AD 中使用多个容器。 如果使用 SuccessFactors 并具有 Windows Server AD，则需要在每个域中确定代表工作人员的用户是否组织到容器层次结构中。某些组织可能会创建代表单个 organizationalUnit 中的员工的所有用户；其他组织可能有多个。有关详细信息，请参阅配置 Azure Active Directory OU 容器分配。
决定是要使用 Microsoft Entra ID 预配到 SAP Cloud Identity Services，还是使用 SAP Cloud Identity Services 从 Microsoft Entra ID 中读取。 有关 Microsoft Entra 预配功能的更多信息，请参阅“使用 Microsoft Entra ID 自动对 SAP Cloud Identity Services 进行用户预配和取消预配”。 SAP 云标识服务也有自己的单独连接器，用于从 Microsoft Entra ID 读取用户和组。有关详细信息，请参阅 SAP 云标识服务 - 标识预配 - Microsoft Entra ID 作为源系统。
确定是否需要将用户预配到 SAP ECC。 可以将 Microsoft Entra ID 中的用户预配到 SAP ECC（以前称为 SAP R/3）NetWeaver 7.0 或更高版本中。如果使用其他版本的 SAP R/3，则仍然可以使用适用于 Microsoft Identity Manager 2016 的连接器中提供的指南作为参考，生成你自己用于预配的模板。

在配置 Microsoft Entra ID 之前，请确保满足组织的先决条件

在开始通过 Microsoft Entra ID 预配业务关键应用程序访问权限的过程之前，请确保已正确配置 Microsoft Entra 环境。

确保 Microsoft Entra ID 和 Microsoft Online Services 环境符合针对应用程序的合规性要求。合规性是 Microsoft、云服务提供商和组织的共同责任。
确保 Microsoft Entra ID 租户获得相应许可。 若要使用 Microsoft Entra ID 自动预配，租户必须拥有充足的许可证（Microsoft Entra ID P1 数量至少要充足），因为存在来自源 HR 应用程序的工作人员或预配到你系统中的成员（非来宾）用户。

此外，要使用生命周期工作流和其他 Microsoft Entra ID 治理功能（例如预配过程中的 Microsoft Entra 权利管理自动分配策略），工作人员需要拥有 Microsoft Entra ID 治理许可证。这些许可证是 Microsoft Entra ID P2 的 Microsoft Entra ID 治理或 Microsoft Entra ID 治理升级版。
检查 Microsoft Entra ID 是否已将其审核日志以及可选的其他日志发送到 Azure Monitor。 Azure Monitor 是可选的，但可以用于治理应用的访问权限，因为 Microsoft Entra 最多只能在其审核日志中存储 30 天的审核事件。可以将审核数据保留更长时间（超过此默认保留期）。有关详细信息，请参阅 Microsoft Entra ID 将报表数据存储多长时间？。

还可以使用 Azure Monitor 工作簿和有关历史审核数据的自定义查询和报表。你可以检查 Microsoft Entra 配置以确认它是否在使用 Azure Monitor，方法如下：在 Microsoft Entra 管理中心内的“Microsoft Entra ID”中选择“工作簿”。如果未配置此集成，而你拥有 Azure 订阅并且角色至少为安全管理员，则可以将 Microsoft Entra ID 配置为使用 Azure Monitor。
确保只有授权用户在 Microsoft Entra 租户中具有高度特权的管理角色。 至少具有以下角色的管理员可以更改用户及其应用程序角色分配：全局管理员、标识治理管理员、用户管理员、应用程序管理员、云应用程序管理员或特权角色管理员。如果最近尚未审查这些角色的成员资格，你将需要一个角色至少为特权角色管理员的用户，以确保开始对这些目录角色进行访问审查。

你还应审查订阅中拥有 Azure Monitor、逻辑应用和运行 Microsoft Entra 配置所需的其他资源的 Azure 角色用户。
检查租户是否进行适当的隔离措施。 如果你的组织在本地使用 Active Directory，并且这些 Active Directory 域连接到 Microsoft Entra ID，则你需要确保云托管服务的高特权管理操作与本地帐户隔离。确保已完成配置以保护 Microsoft 365 云环境免受本地入侵。
根据安全最佳做法评估环境。 若要评估如何保护 Microsoft Entra ID 租户，请查看所有隔离体系结构的最佳做法。
记录令牌生命周期和应用程序的会话设置。 在本教程结束时，你能够把 SAP ECC 或 SAP Cloud Identity Services 应用程序与 Microsoft Entra 集成以实现 SSO。被拒绝继续访问的用户能够继续使用联合应用程序的时长取决于应用程序自己的会话生存期和访问令牌生存期。应用程序的会话生命周期取决于应用程序本身。若要了解有关控制访问令牌生存期的详细信息，请参阅可配置令牌生存期。

确认 SAP Cloud Identity Services 具有应用程序所需的架构映射

组织的每个 SAP 应用程序可能都有自己的要求，也就是说，在向这些应用程序预配用户时，需为用户提供某些属性。

如果使用 SAP Cloud Identity Services 预配 SAP S/4HANA 或其他 SAP 应用程序，请确保 SAP Cloud Identity Services 具有映射，可通过 SAP Cloud Identity Services 将这些属性从 Microsoft Entra ID 发送到这些应用程序。如果未使用 SAP Cloud Identity Services，请跳到下一部分。

确保 SAP 云目录具有 SAP 云应用程序所需的用户架构。 在 SAP Cloud Identity Services 中，配置的每个目标系统都会添加从提供给 SAP Cloud Identity Services 的身份源的数据模型到目标要求的转换。可能需要更改 SAP Cloud Identity Services 中的这些转换，以符合你计划对身份进行建模的方式，在配置了多个目标系统时，更要如此。然后，记录 Microsoft Entra 所需的架构，以通过 SAP Cloud Identity Services 提供给 SAP 云应用程序。

在记录源系统中定义工作人员记录与 Microsoft Entra 中的用户之间的关系

应用程序所需的每个属性都需要来自组织中的某个来源。有些属性可能具有常量值或从其他属性转换而来的值。其他值可能由 Microsoft 联机服务分配，例如用户的电子邮件地址。其他属性（如用户名、部门或其他组织属性）通常源自权威的 HR 记录系统。为了确保正确的 HR 记录对应到 Microsoft Entra ID (Entra ID)/本地 Active Directory (AD) 中的用户，请与 HR 和 IT 团队合作，确保数据一致性并规划任何数据清理任务。

确定如何映射记录源系统中的更改以加入和离开事件。 如果要自动执行工作人员加入和离开过程，则需要将工作人员的状态信息与 Microsoft Entra 中的属性相关联。有关详细信息，请参阅确定用户帐户状态。
确保 HR 来源具有能够为这些 SAP 云应用程序提供所需架构的工作人员架构。 请确保并非源自 Microsoft Entra 或其他 Microsoft Online Service 的 SAP 云或本地应用程序的每个必需属性都可以跟踪到源中可用的属性，例如 SuccessFactors。如果源没有所需的架构，或者没有为将被授予应用程序访问权限的一个或多个身份提供属性，或者这些属性无法供 Microsoft Entra 读取，则必须在启用预配之前满足这些架构要求。
记录用于 Microsoft Entra ID 和记录系统之间关联的架构。 Windows Server AD 或 Microsoft Entra ID 中可能存在与 SAP SuccessFactors 中的工作人员相对应的现有用户。如果这些用户不是由 Microsoft Entra ID 创建的，而是由其他流程创建的，请参阅 SAP SuccessFactors 属性参考和 Windows Server 或 Microsoft Entra 用户架构，以选择用户对象上的哪些属性包含 SAP SuccessFactors 中工作人员的唯一标识符。

此属性必须具有与工作人员相对应的每个用户的唯一值，以便 Microsoft Entra 入站预配可以确定工作人员角色下已包含哪些用户并避免创建重复用户。默认匹配属性基于员工 ID。从 HR 源导入工作人员之前，需要确保此属性的值（例如员工 ID）在Microsoft Entra ID（仅限云用户）和 Windows Server AD（适用于混合用户）中填充，然后才能启动完全同步，并且其值唯一标识每个用户。有关详细信息，请参阅确定匹配的属性和生成唯一的属性值。
选择范围筛选器以跳过不再相关的 HR 记录。 HR 系统有多年的就业数据，包括多年来一直未就业的工作人员。另一方面，IT 团队可能只对当前在职员工列表以及上线后出现的离职记录感兴趣。若要从 IT 团队的角度筛掉不再相关的 HR 记录，请与 HR 团队协作，在可在 Microsoft Entra 预配范围筛选器中使用的 HR 记录上添加标志。有关详细信息，请参阅定义范围筛选器。
计划处理可能构成新用户的用户名的特殊字符。 使用工作人员的名字和姓氏为用户创建唯一 userPrincipalName 是一种常见做法。在 Windows Server AD 和 Microsoft Entra ID 中，userPrincipalName 不允许重音字符，只允许以下字符A - Z, a - z, 0 - 9, ' . - _ ! # ^ ~。使用函数 NormalizeDiacritics 处理重音字符并构造适当的 userPrincipalName。
计划处理源自 HR 源的长字符串。 检查 HR 数据是否具有与 HR 字段关联的长字符串值，这些值将用于填充 Entra ID 和 Windows Server AD 属性。每个 Entra ID 属性都具有最大字符串长度。如果映射到 Entra ID 属性的 HR 字段中的值包含更多字符，则属性更新可能会失败。一个选项是查看属性映射，并检查是否有可能截断/更新 HR 系统中的长字符串值。如果无法使用该选项，则可以使用 Mid 等函数截断长字符串，也可以使用 Switch 等函数将长值映射到较短的值/缩写。
解决必需属性的潜在空值。 必须在 Microsoft Entra ID 或 Windows Server AD 中创建帐户时填充某些属性，例如 firstName、lastName、CN 或 UPN。如果映射到此类属性的相应 HR 字段为 null，则用户创建操作将失败。例如，如果将 AD CN 属性映射到“显示名称”，并且没有为所有用户设置“显示名称”，则会遇到错误。一个选项是查看此类必需的属性映射，并确保在 HR 中填充相应的字段。还可以考虑以下选项，即在表达式映射中检查 null 值。例如，如果显示名称为空，则将名字和姓氏连接起来形成显示名称。

确认 SAP ECC 所需的 BAPI 已可供 Microsoft Entra 使用

Microsoft Entra 预配代理和通用 Web 服务连接器提供与本地 SOAP 端点（包括 SAP BAPI）的连接。

如果未使用 SAP ECC 并且仅预配到 SAP 云服务，请跳到下一部分。

确认已发布预配所需的 BAPI。 在 SAP ECC NetWeaver 7.51 中公开创建、更新和删除用户所必需的 API。名为 Deploying SAP NetWeaver AS ABAP 7.pdf 的适用于 Microsoft Identity Manager 2016 的连接器文件将逐步讲解如何公开必要的 API。
记录现有 SAP 用户可用的架构。 也许 SAP ECC 中已存在与权威记录源系统中的工作人员相对应的用户。但是，如果这些用户不是由 Microsoft Entra ID 创建的，则需要对这些用户填充一个字段，用作工作人员的唯一标识符。此字段必须存在，并且每个用户都有一个与工作人员对应的唯一值。然后，Microsoft Entra 预配可以确定哪些用户存在对应的工作人员，并避免创建重复的用户。

例如，你可能正在使用 SAP BAPI BAPI_USER_GETLIST 和 BAPI_USER_GETDETAIL。应选择 BAPI_USER_GETDETAIL 返回的字段之一作为与源关联的唯一标识符。如果没有与源中唯一标识符对应的字段，你可能需要使用不同的唯一标识符。例如，如果 SAP 字段 address.e_mail 的值在每个 SAP 用户上都是唯一的，并且在 Microsoft Entra ID 用户中也存在，则可能需要使用该字段。
记录要提供给 SAP BAPI 的 Microsoft Entra 所需的架构。 例如，你可能正在使用 SAP BAPI BAPI_USER_CREATE1，它需要 ADDRESS、COMPANY、DEFAULTS、LOGONDATA、PASSWORD、SELF_REGISTER 和 USERNAME 字段来创建用户。配置从 Microsoft Entra ID 用户架构到 SAP ECC 要求的映射时，请将 Microsoft ID 用户属性或常数映射到每个字段。

记录端到端属性流和转换

你已从记录源系统中确定了应用程序的架构要求和可用的工作人员字段。现在记录这些字段如何通过 Microsoft Entra 以及（可选）Windows Server AD 和 SAP Cloud Identity Services 流向应用程序的路径。

在某些情况下，应用程序所需的属性并不直接对应于源中可用的数据值。在这种情况下，需要先转换这些值，然后才能将这些值提供给目标应用程序。

可以应用转换的几个处理阶段。

阶段	注意事项	有关详细信息的链接
在记录本身系统中	Microsoft Entra 标识生命周期管理可能不是从记录源系统读取数据的唯一解决方案。在将数据公开给 Microsoft Entra 之前执行数据规范化也可能使需要类似数据的其他解决方案受益。	请参阅记录文档系统
在入站配置流中，从记录系统到 Microsoft Entra 或 Windows Server AD	可以根据一个或多个 SuccessFactors 属性将自定义值写入 Windows Server AD 用户属性或 Microsoft Entra ID 用户属性。	具有用于自定义的函数的表达式
从 Windows Server AD 同步到 Microsoft Entra ID 时	如果 Windows Server AD 中已有用户，可能会在将这些用户引入 Microsoft Entra ID 时转换这些用户的属性。	如何在 Microsoft Entra Connect 中自定义同步规则并将表达式生成器与 Microsoft Entra Cloud Sync 结合使用
在从 Microsoft Entra ID 到 SAP Cloud Identity Services、SAP ECC 或其他非 SAP 应用程序的出站预配流中	配置应用程序的设置时，可以指定的属性映射类型之一是将 Microsoft Entra ID 中的一个或多个属性映射到目标中的属性的表达式。	具有用于自定义的函数的表达式
在出站联合 SSO 中	默认情况下，Microsoft 标识平台会向应用程序颁发一个包含声明的 SAML 令牌，该声明的值为用户的用户名（也称为用户主体名称），可以唯一标识该用户。 SAML 令牌还包含其他声明，其中包括用户的电子邮件地址或显示名称，可以使用声明转换函数。	自定义 SAML 令牌声明和客户 JSON Web 令牌声明
在 SAP Cloud Identity Services 中	在 SAP Cloud Identity Services 中，配置的每个目标系统都会添加从提供给 SAP Cloud Identity Services 的身份源的数据模型到目标要求的转换。可能需要更改 SAP Cloud Identity Services 中的这些转换，以符合你计划对身份进行建模的方式，在配置了多个目标系统时，更要如此。如果属性要求特定于连接到 SAP Cloud Identity Services 的一个或多个 SAP 应用程序，则此方法可能适用。	SAP Cloud Identity Services - 管理转换

准备颁发新的身份验证凭据

如果使用的是 Windows Server AD，请计划为需要应用程序访问权限且之前没有 Windows Server AD 用户帐户的工作人员颁发 Windows Server AD 凭据。 从历史上看，在某些组织中，用户被直接预配到应用程序存储库中。仅当工作人员需要 Microsoft Exchange 邮箱或访问 Windows Server AD 集成应用程序时，他们才会收到 Windows Server AD 用户帐户。

在此方案中，如要配置 Windows Server AD 的入站预配，则 Microsoft Entra 将在 Windows Server AD 中为以前没有 Windows Server AD 用户帐户的现有工作人员以及任何新工作人员创建用户。用户登录 Windows 域后，我们建议用户注册 Windows Hello 企业版以获得比效果强于密码的强身份验证。
如果不使用 Windows Server AD，请计划为需要应用程序访问权限且之前没有 Microsoft Entra ID 用户帐户的工作人员颁发 Microsoft Entra ID 凭据。 如要配置 Microsoft Entra ID 的入站预配，而不是首先进入 Windows Server AD，则 Microsoft Entra 将在 Microsoft Entra 中创建用户，适用范围包括以前没有 Microsoft Entra ID 用户帐户的现有工作人员以及任何新工作人员。

如果用户需要密码，可以推出 Microsoft Entra ID 自助式密码重置 (SSPR) 功能，以便用户重置其密码。可以从云 HR 应用中预配“移动电话号码”属性。在“移动电话号码”属性在 Microsoft Entra ID 中之后，可以为用户的帐户启用 SSPR。新用户在第一天可以使用已注册和已验证的移动电话号码进行身份验证。请参阅 SSPR 文档，详细了解如何预先填充身份验证联系信息。

如果用户将使用更强的身份验证，请启用“临时访问密码”策略，以便为新用户生成临时访问密码。

验证用户是否已准备好使用 Microsoft Entra MFA。 我们建议要求通过联合集成的业务关键应用程序使用 Microsoft Entra MFA。对于这些应用程序，策略应该要求用户在允许他们登录应用程序的 Microsoft Entra ID 之前满足 MFA 要求。某些组织还可以按位置阻止访问，或者要求用户从已注册的设备进行访问。

如果还没有合适的策略包含身份验证、位置、设备和使用条款所需的条件，请将策略添加到条件访问部署。
准备为新工作人员颁发临时访问密码。 如果你使用的是 Microsoft Entra ID 治理并且正在配置 Microsoft Entra ID 的入站预配，则需计划配置生命周期工作流，为新工作人员颁发临时访问密码。

规划试点

将 HR 业务流程和身份工作流从 HR 资源集成到目标系统需要进行大量的数据验证、数据转换、数据清理和端到端测试，然后才能将解决方案部署到生产中。

请先在试点环境中运行初始配置，然后再将其扩展到生产中的所有用户。

部署 Microsoft Entra 集成

本部分的操作：

将用户从权威来源系统引入 Microsoft Entra ID。
将这些用户预配到 SAP Cloud Identity Services 或 SAP ECC，使他们能够登录 SAP 应用程序。

更新 Windows Server AD 用户架构

若要将用户预配到 Windows Server AD 和 Microsoft Entra ID 中，请确保 Windows Server AD 环境和关联的 Microsoft Entra 代理已准备好使用 SAP 应用程序所需的架构将用户传入和传出 Windows Server AD。

如果未使用 Windows Server AD，请跳到下一部分。

根据需要扩展 Windows Server AD 架构。 对于 Microsoft Entra 和应用程序所需的每个尚未成为 Windows Server AD 用户架构一部分的用户属性，需要选择一个内置的 Windows Server AD 用户扩展属性。或者需要扩展 Windows Server AD 架构，以便为 Windows Server AD 提供一个位置来保存该属性。此要求还包括用于自动化的属性，例如工作人员的加入日期和休假日期。

例如，一些组织可能使用属性 extensionAttribute1 和 extensionAttribute2 来保存这些属性。如果选择使用内置扩展属性，请确保 Windows Server AD 的任何其他基于 LDAP 的应用程序或与 Microsoft Entra ID 集成的应用程序尚未使用这些属性。其他组织使用特定于其要求的名称（例如 contosoWorkerId）新建 Windows Server AD 属性。
确认任何现有的 Windows Server AD 用户都具有与 HR 源关联的必需属性。 也许 Windows Server AD 中已有与工作人员对应的用户。这些用户必须具有一个属性，该属性的值是唯一的，并且与这些工作人员的权威记录源系统中的属性相对应。

例如，某些组织在 Windows Server AD 中使用 employeeId 等属性。如果有用户不具备该属性，他们可能不会在后续集成中被考虑在内。然后自动预配会导致在 Windows Server AD 中创建重复的用户。当用户离职时，原始用户不会被更新或删除。可用工具如下：
- 已加入域的计算机上的 PowerShell 管道使用命令 Get-ADUser 来获取 Active Directory 容器中的所有用户。
- where-object 命令使用类似于 {$_.employeeId -eq $null} 的筛选器来筛选出缺少属性的用户。
- export-csv 命令将获取的用户导出到 CSV 文件。
确保没有任何用户对应于缺少该属性的工作人员。如果有，则必须在 Windows Server AD 中编辑这些用户以添加缺少的属性，然后再继续。
扩展 Microsoft Entra ID 架构并配置从 Windows Server AD 架构到 Microsoft Entra ID 用户架构的映射。 如果你正在使用 Microsoft Entra Connect 同步，请执行 Microsoft Entra Connect 同步：目录扩展中的步骤，使用属性扩展 Microsoft Entra ID 用户架构。将 Windows Server AD 的属性的 Microsoft Entra Connect 同步映射配置为这些属性。

如果你正在使用 Microsoft Entra 云同步，请执行 Microsoft Entra 云同步目录扩展和自定义属性映射中的步骤，以使用任何其他所需的属性扩展 Microsoft Entra ID 用户架构。将 Windows Server AD 的属性的 Microsoft Entra 云同步映射配置为这些属性。确保同步生命周期工作流所需的属性。
等待从 Windows Server AD 同步到 Microsoft Entra ID 完成。 如果已更改映射以从 Windows Server AD 预配更多属性，请等待用户从 Windows Server AD 到 Microsoft Entra ID 进行这些更改，以便用户的 Microsoft Entra ID 表示形式具有来自 Windows Server AD 的完整属性集。

如果你正在使用 Microsoft Entra 云同步，可以通过检索代表 Microsoft Entra 云同步服务主体的同步作业来监视同步状态的 steadyStateLastAchievedTime 属性。如果没有服务主体 ID，请参阅查看同步架构。
在 Windows Server AD 中创建任何必要的容器。 如果要将用户预配到域中的组织单位，则在启用预配代理之前，请确保存在这些 organizationalUnit 容器。

更新 Microsoft Entra ID 用户架构

如果使用的是 Windows Server AD，则已经在从 Windows Server AD 配置映射的过程中扩展了 Microsoft Entra ID 用户架构。如果此步骤已完成，请跳到下一部分。

如果未使用 Windows Server AD，请按照本部分中的步骤扩展 Microsoft Entra ID 用户架构。

创建用于保存 Microsoft Entra 架构扩展的应用程序。 对于未从 Windows Server AD 同步的租户，架构扩展必须是新应用程序的一部分。如果尚未这样做，请创建一个应用程序来表示架构扩展。此应用程序不会获配任何用户。
识别与记录系统相关的属性。 也许 Microsoft Entra ID 中存在与工作人员对应的用户。在这种情况下，这些用户必须具有一个属性，该属性的值是唯一的，并且与这些工作人员的权威记录源系统中的属性相对应。

例如，某些组织已扩展其 Microsoft Entra ID 用户架构，以拥有用于此目的的新属性。如果尚未为此目的创建属性，请在下一步中将其作为属性包含在内。
为新属性扩展 Microsoft Entra ID 用户架构。 为尚未加入 Microsoft Entra ID 用户架构的 SAP 应用程序所需的每个属性创建目录架构扩展。这些属性为 Microsoft Entra 提供了一种方法来存储有关用户的更多数据。可以通过创建扩展属性来扩展架构。

确保 Microsoft Entra ID 中的用户可以与 HR 源中的工作人员记录相关联

也许 Microsoft Entra ID 中存在与工作人员对应的用户。在这种情况下，这些用户必须具有一个属性，该属性的值是唯一的，并且与这些工作人员的权威记录源系统中的属性相对应。

例如，某些组织可能已扩展其 Microsoft Entra ID 用户架构，以拥有用于此目的的新属性。如果有用户不具备该属性，他们可能不会在后续集成中被考虑在内。然后自动预配会导致在 Windows Server AD 中创建重复的用户。当用户离职时，原始用户不会被更新或删除。

从 Microsoft Entra ID 检索用户。确保 Microsoft Entra ID 中已存在代表工作人员的任何用户都具有一个属性，以便可以进行关联。 通常，Microsoft Entra ID 中的少数用户与权威记录源系统中的工作人员不对应。这些用户包括用于紧急管理访问的紧急帐户、IT 供应商帐户和商业来宾帐户。其余用户必须已有一个具有唯一值的属性才能用于关联。

如果某些用户不关联，他们可能会错过更新和取消预配。 Microsoft Entra 甚至可能创建重复的用户。例如，如果要求所有成员用户（除“破窗”帐户外）都具有 employeeid 属性，那么可以使用类似于以下脚本所示的 PowerShell 命令管道来识别这些用户：
```
$u = get-mguser -all -property id,displayname,userprincipalname,usertype,employeeid | Where-Object {$_.UserType -ne 'Guest' -and $_.EmployeeId -eq $null}
```

设置身份治理功能的先决条件

如果确定需要 Microsoft Entra ID 治理功能（例如 Microsoft Entra 权利管理或 Microsoft Entra 生命周期工作流），请在将工作人员作为用户引入 Microsoft Entra ID 之前部署这些功能。

如果需要，请上传使用条款文档。 如果你要求用户在访问应用程序之前接受使用条款，请创建并上传使用条款文档，以便将其纳入条件访问策略中。
按需创建目录。 默认情况下，当管理员首次与 Microsoft Entra 权利管理交互时，系统会自动创建默认目录。但是，受治理应用程序的访问包应位于指定目录中。若要在 Microsoft Entra 管理中心中创建目录，请按照“创建目录”部分中的步骤操作。

若要使用 PowerShell 创建目录，请按照向 Microsoft Entra ID 进行身份验证部分中的步骤操作并创建目录。
创建入职者工作流。 如果要配置 Microsoft Entra ID 的入站预配，请配置生命周期工作流入职者工作流，其中包含为新工作人员颁发临时访问密码的任务。
创建阻止登录的离职者工作流。在 Microsoft Entra 生命周期工作流中，使用阻止用户登录的任务配置离职者工作流。此工作流可以按需运行。如果未配置记录源的入站预配，以阻止工作人员在计划的离职日期后登录，则需配置一个离职者工作流，以在这些工作人员的计划离职日期运行。
创建一个离职者工作流以删除用户帐户。 （可选）使用删除用户的任务配置离职者工作流。安排此工作流在工作人员的计划离职日期之后运行一段时间，例如 30 或 90 天。

连接 Microsoft Entra ID 中的用户与 HR 源中的工作人员记录

本节说明如何将 Microsoft Entra ID 与 SAP SuccessFactors 集成作为 HR 源记录系统。

使用服务帐户配置记录系统并为 Microsoft Entra ID 授予适当的权限。 如果使用 SAP SuccessFactors，请按照配置 SuccessFactors 进行集成部分中的步骤操作。
配置从记录系统到 Windows Server AD 或 Microsoft Entra ID 的入站映射。 如果使用 SAP SuccessFactors 并将用户预配到 Windows Server AD 和 Microsoft Entra ID，然后按照配置从 SuccessFactors 到 Active Directory 的用户预配部分中的步骤进行操作。

如果使用 SAP SuccessFactors 而不预配到 Windows Server AD，请按照配置从 SuccessFactors 到 Microsoft Entra ID 的用户预配部分中的步骤进行操作。

配置映射时，请确保按照使用此属性匹配对象中的说明，为用于关联的 Windows Server AD 属性或 Microsoft Entra ID 用户属性配置映射。此外，可以为工作人员入职和离职日期所需的属性以及源自 HR 源的目标应用程序所需的所有属性配置映射。
在记录系统中执行初始入站预配。 如果使用 SAP SuccessFactors 并将用户预配到 Windows Server AD 和 Microsoft Entra ID，请按照启用和启动预配部分中的步骤操作。如果使用 SAP SuccessFactors 而不预配到 Windows Server AD 中，请按照启用和启动预配部分中的步骤进行操作。对于大型云 HR 应用租户（>30,000 名用户），请按照初始周期计划中所述，分阶段逐步运行初始周期。
等待记录系统的初始同步完成。 如果从 SAP SuccessFactors 同步到 Windows Server AD 或 Microsoft Entra ID，则在完成与目录的初始同步后，Microsoft Entra 会在 Microsoft Entra 管理中心的 SAP SuccessFactors 应用程序的“预配”选项卡上更新审核摘要报告。
如果预配到 Windows Server AD，请等待在 Windows Server AD 中创建的新用户或在 Windows Server AD 中更新的用户从 Windows Server AD 同步到 Microsoft Entra ID。 等到系统已将 Windows Server AD 中的用户更改传递到 Microsoft Entra ID，以便用户的 Microsoft Entra ID 表示形式具有 Windows Server AD 中的完整用户集及其属性。

如果你正在使用 Microsoft Entra 云同步，则可以通过检索代表 Microsoft Entra 云同步服务主体的同步作业来监视同步状态的 steadyStateLastAchievedTime。如果没有服务主体 ID，请参阅查看同步架构。

确保已将用户预配到 Microsoft Entra ID 中。 此时，用户应存在于 Microsoft Entra ID 中，其中包含目标应用程序所需的属性。例如，你可能要求用户具有 givenname、surname 和 employeeID 属性。若要显示具有特定属性或缺少属性的用户数量，可以使用类似于以下脚本的 PowerShell 命令：

$u = get-mguser -all -property id,displayname,userprincipalname,usertype,givenname,surname,employeeid
$u2 = $u | where-object {$_.usertype -ne 'Guest' -and $_.employeeid -ne $null}
$u2c = $u2.Count
write-output "member users with employeeID attribute: $u2c"
$u3 = $u| Where-Object {$_.UserType -ne 'Guest' -and ($_.EmployeeId -eq $null -or $_.GivenName -eq $null -or $_.Surname -eq $null)}
$u3c = $u3.Count
write-output "member users missing employeeID, givenname or surname attributes: $u3c"

确保 Microsoft Entra ID 中没有意外的不相关帐户。 通常，Microsoft Entra ID 中的少数用户与权威记录源系统中的工作人员不对应。这些用户包括用于紧急管理访问的紧急帐户、IT 供应商帐户和商业来宾帐户。

但是，他们也可能是 Microsoft Entra 中的孤立帐户，类似于当前工作人员的帐户，但未与工作人员记录同步。孤立帐户可能是由不再在 HR 系统中的离职员工造成的。他们也可能是匹配错误造成的。或者他们可能由数据质量问题造成，例如某人更改了姓名或被被重新雇用。
测试上游记录系统中的加入、更新和退出活动是否能够正确流向 Microsoft Entra。 有关详细信息，请参阅计划测试。

现在，用户已存在于 Microsoft Entra ID 中，在接下来的部分中，你需要将他们预配到目标应用程序。

将用户预配到 SAP Cloud Identity Services

本部分中的步骤配置从 Microsoft Entra ID 到 SAP Cloud Identity Services 的预配。默认情况下会设置 Microsoft Entra ID，以便自动将用户预配到 SAP 云标识服务和取消预配。然后，这些用户可以向 SAP Cloud Identity Services 进行身份验证，并可以访问与 SAP Cloud Identity Services 集成的其他 SAP 工作负载。 SAP 云标识服务支持从其本地标识目录预配到其他 SAP 应用程序作为目标系统。

或者，可以将 SAP Cloud Identity Services 配置为从 Microsoft Entra ID 读取。如果使用 SAP Cloud Identity Services 从 Microsoft Entra ID 读取用户和组（可选），请按照有关如何配置 SAP Cloud Identity Services 的 SAP 指南进行操作。然后转到下一部分。

如果未使用 SAP Cloud Identity Services，请跳到下一部分。

确保 SAP Cloud Identity Services 租户拥有 SAP Cloud Identity Services 中具有管理员权限的用户帐户。
设置 SAP Cloud Identity Services 以进行预配。 登录 SAP Cloud Identity Services 管理控制台，然后按照设置 SAP Cloud Identity Services 进行预配部分中的步骤进行操作。
从库中添加 SAP Cloud Identity Services 并配置 SAP Cloud Identity Services 的自动用户预配。 按照从库中添加 SAP Cloud Identity Services 和配置 SAP Cloud Identity Services 的自动用户预配部分中的步骤进行操作。
将新的测试用户从 Microsoft Entra ID 预配到 SAP Cloud Identity Services。 按照将新测试用户从 Microsoft Entra ID 预配到 SAP Cloud Identity Services 部分中的步骤，验证预配集成是否已准备就绪。
确保 Microsoft Entra 和 SAP Cloud Identity Services 中的现有用户可以关联。 若要将 Microsoft Entra ID 中的用户与 SAP Cloud Identity Services 中已有的用户进行比较，请按照以下部分中的步骤进行操作：
- 确保现有 SAP 云标识服务用户具有必要的匹配属性
- 确保现有 Microsoft Entra 用户具有必要的属性
将 SAP Cloud Identity Services 的现有用户分配给 Microsoft Entra ID 中的应用程序。 按照将用户分配到 Microsoft Entra ID 中的 SAP Cloud Identity Services 应用程序部分中的步骤进行操作。在这些步骤中，应该：
- 解决所有预配问题，以便预配不会被隔离。
- 检查 SAP 云标识服务中是否存在尚未分配给 Microsoft Entra ID 中的应用程序的用户。
- 分配剩余用户。
- 监视初始同步。
等待从 Microsoft Entra ID 同步到 SAP Cloud Identity Services。 等待分配给应用程序的所有用户都已预配完毕。初始周期需要 20 分钟到几个小时。时间取决于 Microsoft Entra 目录的大小，以及预配范围内的用户数。可以通过检索代表 SAP Cloud Identity Services 的服务主体的同步作业来监控同步状态的 steadyStateLastAchievedTime 属性。
检查是否存在预配错误。 通过 Microsoft Entra 管理中心或 Graph API 检查预配日志。按状态“失败”筛选日志。

如果出现错误代码为 DuplicateTargetEntries 的故障，此代码表示预配匹配规则存在歧义。为了确保每个 Microsoft Entra 用户与一个应用程序用户匹配，需要更新 Microsoft Entra 用户或用于匹配的映射。然后按操作“创建”和状态“已跳过”来筛选日志。

如果跳过了用户并出现 SkipReason 代码 *NotEffectivelyEntitled，则此日志事件可能表明 Microsoft Entra ID 中的用户帐户不匹配，因为用户帐户状态为“已禁用”。
将 SAP Cloud Identity Services 中的用户与 Microsoft Entra ID 中的用户进行比较。 重复确保现有 SAP Cloud Identity Services 用户具有必要的匹配属性部分中的步骤，以便从 SAP Cloud Identity Services 重新导出用户。然后，检查导出的用户是否具有 SAP 应用程序所需的属性。可以使用 PowerShell where-object 命令筛选用户列表，以仅筛选具有缺失属性的用户，其筛选器如 {$_.employeeId -eq $null} 所示。
配置从 Microsoft Entra 到 SAP Cloud Identity Services 的联合 SSO。 为 SAP Cloud Identity Services 启用基于 SAML 的 SSO。按照 SAP Cloud Identity Services 单一登录教程中提供的说明进行操作。
将应用程序 Web 终结点纳入相应的条件访问策略的范围。 也许你有一个现有的条件访问策略，它是为另一个受相同治理要求约束的应用程序创建的。在这种情况下，你可以更新该策略，使其同样适用于此应用程序，以避免出现大量策略。

完成更新后，请检查以确保应用预期的策略。你可以使用条件访问假设分析工具查看哪些策略适用于用户。
验证测试用户可以连接到 SAP 应用程序。 可以使用 Microsoft 中的“我的应用”来测试应用程序 SSO。确保已将测试用户分配到 SAP Cloud Identity Services 应用程序，并从 Microsoft Entra ID 预配到 SAP Cloud Identity Services。然后，以该用户身份登录 Microsoft Entra，并转到 myapps.microsoft.com。

选择“我的应用”中的 SAP Cloud Identity Services 磁贴时，如果是在服务提供商 (SP) 模式下配置的，则系统会重定向到应用程序登录页面以启动登录流。如果是在标识提供者 (IDP) 模式下配置的，系统会自动登录到为其设置 SSO 的 SAP 云标识服务。

将用户预配到 SAP ECC

有了 Microsoft Entra ID 中的用户后，即可将其预配到 SAP 本地。

如果未使用 SAP ECC，请跳到下一部分。

配置预配。 按照配置 Microsoft Entra ID 以使用 NetWeaver AS ABAP 7.0 或更高版本将用户预配到 SAP ECC 中中的说明进行操作。
等待从 Microsoft Entra ID 同步到 SAP ECC。 等待分配给 SAP ECC 应用程序的所有用户都已预配完毕。初始周期需要 20 分钟到几个小时。时间取决于 Microsoft Entra 目录的大小，以及预配范围内的用户数。可以通过检索服务主体的同步作业来监控同步状态的 steadyStateLastAchievedTime 属性。
检查是否存在预配错误。 通过 Microsoft Entra 管理中心或 Graph API 检查预配日志。按状态“失败”筛选日志。

如果出现错误代码为 DuplicateTargetEntries 的故障，此日志事件表示预配匹配规则存在歧义。需要更新 Microsoft Entra 用户或用于匹配的映射，以确保每个 Microsoft Entra 用户与一个应用程序用户匹配。然后按操作“创建”和状态“已跳过”来筛选日志。

如果跳过了用户并出现 SkipReason 代码 NotEffectivelyEntitled，则此代码可能表明 Microsoft Entra ID 中的用户帐户不匹配，因为用户帐户状态为“已禁用”。
将 SAP ECC 中的用户与 Microsoft Entra ID 中的用户进行比较。 在托管用于预配到 SAP ECC 的预配代理的 Windows 服务器上，重新启动 Microsoft ECMA2Host Windows 服务。服务重启时，它将从 SAP ECC 执行用户的完整导入。
配置从 Microsoft Entra 到 SAP 的联合 SSO。 为 SAP 应用程序启用基于 SAML 的 SSO。如果使用 SAP NetWeaver，请按照 SAP NetWeaver SSO 教程中提供的说明进行操作。
将应用程序 Web 终结点纳入相应的条件访问策略的范围。 也许你有一个现有的条件访问策略，它是为另一个受相同治理要求约束的应用程序创建的。在这种情况下，你可以更新该策略，使其同样适用于此应用程序，以避免出现大量策略。

完成更新后，请检查以确保应用预期的策略。你可以使用条件访问假设分析工具查看哪些策略适用于用户。
验证可以对测试用户执行预配，且他们能够登录 SAP NetWeaver。 按照测试 SSO 部分中的说明操作，确保在配置条件访问后，用户可以登录。

配置 SuccessFactors 和其他应用程序的预配

可以配置 Microsoft Entra，以将特定属性从 Microsoft Entra ID 写入 SAP SuccessFactors Employee Central，包括工作电子邮件。有关详细信息，请参阅在 Microsoft Entra ID 中配置 SAP SuccessFactors 写回。

还可以将 Microsoft Entra 预配到许多其他应用程序中，包括使用 OpenID Connect、SAML、SCIM、SQL、LDAP、SOAP 和 REST 等标准的应用。有关详细信息，请参阅将应用程序与 Microsoft Entra ID 集成。

在 Microsoft Entra 中为用户分配必要的应用程序访问权限

除非配置的租户是专门为 SAP 应用程序访问而配置的完全独立的租户，否则无需令租户中的每位用户都具备对 SAP 应用程序的访问权限。按如下要求配置租户中的 SAP 应用程序：仅将具有应用程序角色分配的用户预配到应用程序，并且他们能够从 Microsoft Entra ID 登录到该应用程序。

在 Microsoft Entra ID 中更新分配给应用程序的用户时，这些更改将自动预配到该应用。

如果你拥有 Microsoft Entra ID 治理，则可以自动更改 Microsoft Entra ID 中 SAP Cloud Identity Services 或 SAP ECC 的应用程序角色分配。当用户入职、离职或更改角色时，你可以使用自动化功能来添加或删除分配。

更新现有分配。 （可选）对应用程序角色分配执行一次性访问评审。此评审完成后，访问评审将删除不再需要的分配。
配置过程，及时更新应用程序角色分配。 如果使用 Microsoft Entra 权利管理，请参阅使用 PowerShell 在权利管理中为具有单个角色的应用程序创建访问包来配置对代表 SAP Cloud Identity Services 或 SAP ECC 的应用程序的分配。

在该访问包中，可以制定策略，以便在用户请求访问权限时为其分配访问权限。分配可由管理员进行、根据规则自动进行，或通过生命周期工作流生成。

如果你没有 Microsoft Entra ID 治理，可以在 Microsoft Entra 管理中心将每个用户分配到应用程序。可以通过 PowerShell cmdlet New-MgServicePrincipalAppRoleAssignedTo 将单个用户分配到应用程序。

将凭据分发给新建的 Microsoft Entra 用户或 Windows Server AD 用户

此时，所有用户都将出现在 Microsoft Entra ID 中，并预配到相关的 SAP 应用程序。对于以前未出现在 Windows Server AD 或 Microsoft Entra ID 中的工作人员，在此过程中创建的任何用户都需要新凭据。

如果 Microsoft Entra 入站预配正在 Windows Server AD 中创建用户，则为新创建的用户分发 Windows Server AD 初始凭据。 可以使用 Get-MgAuditLogProvisioning 命令检索 Microsoft Entra 与 Windows Server AD 交互的事件列表。

可以在加入域的计算机上使用带 -Reset 参数的 Set-ADAccountPassword 命令为用户设置新的 Windows Server AD 密码。然后使用带 -ChangePasswordAtLogon 参数的 Set-ADUser 命令要求用户在下次登录时选择一个新密码。
如果 Microsoft Entra 入站预配正在 Microsoft Entra ID 中创建用户，则为新创建的用户分发 Microsoft Entra ID 初始凭据。 可以使用 Get-MgAuditLogDirectoryAudit 命令检索新创建的用户列表，所用参数如 Get-MgAuditLogDirectoryAudit -Filter "category eq 'UserManagement' and activityDisplayName eq 'Add user' and result eq 'success' and activityDateTime+ge+2024-05-01" -all 所示。

若要为用户生成临时访问密码，可以使用 New-MgUserAuthenticationTemporaryAccessPassMethod 和 Get-MgUserAuthenticationTemporaryAccessPassMethod 命令，如创建临时访问密码中所示。
确认用户已注册 MFA。 可以通过运行有关注册 MFA 的用户的 PowerShell 报告部分中的 PowerShell 命令来识别未注册 MFA 的用户。
如果任何用户需要临时策略排除项，请创建定期访问评审。 在某些情况下，可能无法立即为每个授权用户强制实施条件访问策略。例如，某些用户可能没有适当的已注册设备。如果需要从条件访问策略中排除一个或多个用户并允许这些用户访问，请为从条件访问策略中排除的用户组配置访问评审。

监视身份流

为应用程序配置入站和出站预配后，可以使用 Microsoft Entra 中的自动化来监视从权威记录系统到目标应用程序的持续预配。

监视入站预配

Microsoft Entra 预配日志中记录了用户预配服务执行的活动。可在 Microsoft Entra 管理中心访问预配日志。你可以根据用户的名称或者根据源系统或目标系统中的标识符来搜索预配数据。有关详细信息，请参阅预配日志。

监视 Windows Server AD 中的更改

如 Windows Server 审核策略建议中所述，确保在所有域控制器上启用用户帐户管理成功审核事件，并收集这些事件以进行分析。

监视应用程序角色分配

如果将 Microsoft Entra ID 配置为将审核事件发送到 Azure Monitor，则可以使用 Azure Monitor 工作簿来深入了解用户如何接收其访问权限。

如果使用 Microsoft Entra 权利管理，则名为“访问包活动”的工作簿会显示与特定访问包相关的每个事件。
若要查看应用程序的应用程序角色分配是否由于访问包分配而未发生更改，请选择名为“应用程序角色分配活动”的工作簿。如果选择省略权利活动，那么只显示不是由权利管理对应用程序角色所做的更改。例如，如果另一位管理员直接将用户分配给应用程序角色，会显示一行信息。

监视出站预配

对于每个与 Microsoft Entra 集成的应用程序，可以使用“同步详细信息”部分来监视进度并跟踪指向预配活动报告的链接。该报告描述了 Microsoft Entra 预配服务对应用程序执行的所有操作。还可以通过 Microsoft 图形 API 监视预配项目。

要详细了解如何读取 Microsoft Entra 预配日志，请参阅有关自动用户帐户预配的报告。

监视 SSO

可以在 Microsoft Entra 管理中心的登录报告中或通过 Microsoft Graph 查看应用程序过去 30 天的登录情况。还可以将登录日志发送到 Azure Monitor，以存档长达两年的登录活动。

Microsoft Entra ID 治理中的监视分配

如果你使用的是 Microsoft Entra ID 治理，则可以报告用户使用 Microsoft Entra ID 治理功能获取访问权限的方式。例如：

管理员或目录所有者可以通过 Microsoft Entra 管理中心、Microsoft Graph 或 PowerShell 检索具有访问包分配的用户列表。
还可以将审核日志发送到 Azure Monitor，并在 Microsoft Entra 管理中心中或通过 PowerShell 查看访问包更改历史记录。

有关这些方案和其他身份治理方案的详细信息，请参阅如何监视以按需调整权利管理策略和访问权限。

通过