次の方法で共有

SharePoint: MIM 2016 Export for SharePoint MA fails

  • [アーティクル]

 

 

Consider the following scenario:

You have SharePoint 2016 set up to import user profiles from an External Identity Manager.

We'll say you're using Microsoft Identity Manager (MIM) 2016 to import profiles from some 3rd party LDAP directory. The profiles should be imported as Trusted Provider type users (SAML-claims).

You run a Sync, and everything goes fine until the export step for the SharePoint Management Agent (SP MA).

There are export errors for each user object "Error returned during object Export"

The error detail may show something like this:

"Export retry FAILED for Entity(ObjectType: user, Anchor: User1__8c9c474c-a26c-4295-aedc-739d547a2f15).

Error System.Web.Services.Proptocols.SoapExtension: Server was unable to process request - One or more errors occurred. - The trust relationship between the primary domain and the trusted domain failed."

Note: Instead of the "trust relationship" error above, you may see this as your error detail: "Some or all identity references could not be translated"

You may also notice that exporting each user from MIM is very slow and that the profiles created on the SharePoint side do not have the proper account name format. For example, they may have account names like "ADFS:User1" instead of "i:0e.t|ADFS|User1@contoso.com".

In the SharePoint ULS logs, you may see this error for each user:

w3wp.exe (0x30E4) 0x172C SharePoint Foundation Runtime aoxsq Medium Sending HTTP response 500 for HTTP request POST to https://yourCentralAdminServer:5555/_vti_bin/ProfileImportExportService.asmx

 

Cause:

You did not configure your property mappings correctly in MIM.

See my colleague Adams blog post on the subject: https://blogs.technet.microsoft.com/adamsorenson/2018/01/31/sharepoint-2016-mim-and-samlfba-user-profiles/

 

Specifically, the mappings for SPS-ClaimProviderType, SPS-ClaimProviderID, and SPS-ClaimID are either missing or not mapped properly.

These need to be configured properly so that SharePoint can construct the proper account name for the user profile. For example: i:0e.t|ADFS|User1@contoso.com

In this case, the "i:0e.t" part comes from the identity claim type (UPN in my case), "ADFS" comes from SPS-ClaimProviderID, and of course "User1@contoso.com" is the value for SPS-ClaimID, which comes from the UPN attribute.

Without these mappings, SharePoint will receive an "Add" for an isolated (not qualified) account name like "User1". Because it doesn't know any better, SharePoint assumes that this must be a local Active Directory user, so it makes a call to the LsarLookupNames4 method in an attempt to resolve the user.

In this case, the user comes from a 3rd party LDAP directory, so it does not exist in Active Directory. Because the user name is not qualified (ie: not in domain\username or username@domain.com format) every trusted Active Directory domain and forest will be searched, which could take a long time and fail with the "The trust relationship between the primary domain and the trusted domain failed", or "Some or all identity references could not be translated" errors.

 

 

Resolution:

Map SPS-ClaimProviderType, SPS-ClaimProviderID, and SPS-ClaimID properly.

 

Mappings in the LDAP provider Management Agent

We're doing Trusted Provider (SAML claims) on the SharePoint side, so SPS-ClaimProviderType should be mapped to a Constant of "Trusted"

SPSClaimProviderID should be mapped to a Constant and contain the name of your SharePoint Trusted Identity Token Issuer. In my case, it is named "ADFS".

To get the proper name, you would run this PowerShell on the SharePoint server:

Get-SPTrustedIdentityTokenIssuer | select name

 

You take that provider name and set it as a constant for SPS-ClaimProviderID.

 

SPS-ClaimID needs to be mapped to whatever your Identity / Identifier claim is. In my case it's User Principal Name (UPN).

You can check that by running this PowerShell on the SharePoint server:

$ti = Get-SPTrustedIdentityTokenIssuer

$ti.IdentityClaimTypeInformation

 

 

 

Mappings in the SharePoint Management Agent:

In the SharePoint MA, these three properties should just flow through as-is:

 

If you're not seeing SPS-ClaimProviderType, SPS-ClaimProviderID, and SPS-ClaimID in either of the management agents, I again refer you to my colleague Adams post on the subject. He walks through the whole thing.