Azure AD Connect 同步服务影子属性Azure AD Connect sync service shadow attributes

大多数属性在 Azure AD 中的表示方式与其在本地 Active Directory 中的表示方式相同。Most attributes are represented the same way in Azure AD as they are in your on-premises Active Directory. 但是,一些属性有一些特殊的处理方式,而且 Azure AD 中的属性值可能不同于 Azure AD Connect 所同步的属性值。But some attributes have some special handling and the attribute value in Azure AD might be different than what Azure AD Connect synchronizes.

影子属性简介Introducing shadow attributes

在 Azure AD 中,某些属性有两种表示形式。Some attributes have two representations in Azure AD. 本地值和计算所得的值都会进行存储。Both the on-premises value and a calculated value are stored. 这些额外的属性称为影子属性。These extra attributes are called shadow attributes. 表示此行为的两个最常用属性是 userPrincipalNameproxyAddressThe two most common attributes where you see this behavior are userPrincipalName and proxyAddress. 当这些属性中有表示非已验证域的值时,属性值将发生更改。The change in attribute values happens when there are values in these attributes representing non-verified domains. 但是,Connect 中的同步引擎会读取影子属性中的值,因此从该引擎的角度来看,属性是经过 Azure AD 确认的。But the sync engine in Connect reads the value in the shadow attribute so from its perspective, the attribute has been confirmed by Azure AD.

无法使用 Azure 门户或 PowerShell 查看影子属性。You cannot see the shadow attributes using the Azure portal or with PowerShell. 但是,了解这些概念有助于排查某些情况下本地属性值不同于云中属性值的问题。But understanding the concept helps you to troubleshoot certain scenarios where the attribute has different values on-premises and in the cloud.

为了更好地了解该行为,请看下述来自 Fabrikam 的示例:To better understand the behavior, look at this example from Fabrikam:
域
其本地 Active Directory 中存在多个 UPN 后缀,但只验证了一个。They have multiple UPN suffixes in their on-premises Active Directory, but they have only verified one.

userPrincipalNameuserPrincipalName

用户在非验证域中具有下列属性值:A user has the following attribute values in a non-verified domain:

属性Attribute Value
本地 userPrincipalNameon-premises userPrincipalName lee.sperry@fabrikam.com
Azure AD shadowUserPrincipalNameAzure AD shadowUserPrincipalName lee.sperry@fabrikam.com
Azure AD userPrincipalNameAzure AD userPrincipalName lee.sperry@fabrikam.partner.onmschina.cn

userPrincipalName 属性是在使用 PowerShell 时看到的值。The userPrincipalName attribute is the value you see when using PowerShell.

由于真实的本地属性值存储在 Azure AD 中,因此在验证 fabrikam.com 域时,Azure AD 会使用 shadowUserPrincipalName 的值更新 userPrincipalName 属性。Since the real on-premises attribute value is stored in Azure AD, when you verify the fabrikam.com domain, Azure AD updates the userPrincipalName attribute with the value from the shadowUserPrincipalName. 不需同步 Azure AD Connect 中的任何更改即可更新这些值。You do not have to synchronize any changes from Azure AD Connect for these values to be updated.

proxyAddressesproxyAddresses

proxyAddress 也会发生这个只包括验证域的相同过程,但有一些额外的逻辑。The same process for only including verified domains also occurs for proxyAddresses, but with some additional logic. 仅对邮箱用户检查验证域。The check for verified domains only happens for mailbox users. 启用邮件的用户或联系人代表其他 Exchange 组织中的用户,可以将 proxyAddress 中的任何值添加到这些对象。A mail-enabled user or contact represent a user in another Exchange organization and you can add any values in proxyAddresses to these objects.

对于邮箱用户(不管是在本地还是在 Exchange Online 中),仅显示验证域的值。For a mailbox user, either on-premises or in Exchange Online, only values for verified domains appear. 它看起来可能如下所示:It could look like this:

属性Attribute Value
本地 proxyAddresson-premises proxyAddresses SMTP:abbie.spencer@fabrikamonline.com
smtp:abbie.spencer@fabrikam.com
smtp:abbie@fabrikamonline.com
Exchange Online proxyAddressExchange Online proxyAddresses SMTP:abbie.spencer@fabrikamonline.com
smtp:abbie@fabrikamonline.com
SIP:abbie.spencer@fabrikamonline.com

在本例中,smtp:abbie.spencer@fabrikam.com 已删除,因为该域尚未验证。In this case smtp:abbie.spencer@fabrikam.com was removed since that domain has not been verified. 但是,Exchange 还添加了 SIP:abbie.spencer@fabrikamonline.comBut Exchange also added SIP:abbie.spencer@fabrikamonline.com. Fabrikam 尚未使用本地 Lync/Skype,但 Azure AD 和 Exchange Online 为其做了准备。Fabrikam has not used Lync/Skype on-premises, but Azure AD and Exchange Online prepare for it.

这个针对 proxyAddress 的逻辑称为 ProxyCalcThis logic for proxyAddresses is referred to as ProxyCalc. 每当出现以下情况,导致用户出现变化时,就会调用 ProxyCalc:ProxyCalc is invoked with every change on a user when:

  • 已为用户分配包含 Exchange Online 的服务计划,即使用户没有获得 Exchange 的许可。The user has been assigned a service plan that includes Exchange Online even if the user was not licensed for Exchange. 例如,需要为用户分配 Office E3 SKU,但只为其分配了 SharePoint Online。For example, if the user is assigned the Office E3 SKU, but only was assigned SharePoint Online. 即使邮箱仍在本地,也是如此。This is true even if your mailbox is still on-premises.
  • 属性 msExchRecipientTypeDetails 有一个值。The attribute msExchRecipientTypeDetails has a value.
  • 更改 proxyAddresses 或 userPrincipalName。You make a change to proxyAddresses or userPrincipalName.

ProxyCalc 可能需要一些时间才能处理对用户的更改,并且不与 Azure AD Connect 导出过程同步。ProxyCalc might take some time to process a change on a user and is not synchronous with the Azure AD Connect export process.

Note

对于本主题未记录的高级方案,ProxyCalc 逻辑有一些其他的行为。The ProxyCalc logic has some additional behaviors for advanced scenarios not documented in this topic. 本主题的目的是方便你了解相关行为,不会记录所有内部逻辑。This topic is provided for you to understand the behavior and not document all internal logic.

隔离的属性值Quarantined attribute values

存在重复的属性值时,也会使用影子属性。Shadow attributes are also used when there are duplicate attribute values. 有关详细信息,请参阅重复属性复原For more information, see duplicate attribute resiliency.

另请参阅See also