SharePoint: Issues with profile pictures when MySite uses SAML auth
There are a couple known issues with user profile pictures when your Mysite web application uses Trusted Provider (ADFS / SAML) authentication.
Symptoms
There are two different known symptoms with the same cause and solution:
#1
When running User Profile Synchronization, nothing is imported or exported. In the Forefront Identity Manager (FIM) client, we see “stopped-extension-dll-exception” for the MOSS_FullImport and MOSS_DeltaImport steps.
In the Application event log on the server running the User Profile Synchronization service (Sync server), the following error is thrown at the same time as when “stopped-extension-dll-exception” is thrown in the FIM client.
Note that the 403 Forbidden is thrown at “ProfileImportExportExtension.DownloadPictures”. That's where the FIM service tries to download the user profile pictures.
Log Name: Application
Source: FIMSynchronizationService
Event ID: 6801
Task Category: Server
Level: Error
Computer: <TheSyncServer>
Description:
The extensible extension returned an unsupported error.
The stack trace is:
"System.Net.WebException: The remote server returned an error: (403) Forbidden.
at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadData(Uri address)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.DownloadPictures(ProfileChangeData[] profiles)
at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)
#2
Within site collections in your non-mysite web apps, any place that a user profile photo is supposed to be shown (user information list, site permissions, people and groups, person or group columns, etc), there is an ‘x’ shown in place of the picture. If you browse to the Mysite web application and authenticate and then go back to the previous site, the pictures are shown correctly.
Cause
The Mysite Web Application is configured for Trusted Provider (SAML / ADFS) authentication.
The profile pictures are stored at the root of the mysite host.
For example: https://MySiteRoot.contoso.com/User Photos/Profile Pictures/UserName_MThumb.jpg"
For problem #1 above, the FIM Sync service must retrieve each picture with an HTTP GET, but does not know how to do ADFS authentication, so it fails with 403 Forbidden.
For problem #2, the user is not yet authenticated to the Mysite web app, so retrieving the profile pictures to display within other web apps fails. As soon as the user authenticates to the Mysite web app, the pictures can be retrieved.
Resolution
The solution to both of these problems is to simply enable the “User Photos” library (and only that library) for anonymous access.
That way, authentication is not required to retrieve the profile pictures. The FIM Sync service and the worker processes for the non-mysite web apps can now grab the pictures with no issue.
Here’s how you would do it:
In Central Admin | Manage Web Applications, choose the MySite web app and “Authentication Providers”. Choose the zone that ADFS is enabled in and select the check box for “Enable Anonymous Access”.
Note: Just enabling it here doesn’t give anonymous users access to anything.
Browse to the Mysite host | Site Settings | Site Permissions.
Select “Anonymous Access” in the Ribbon and choose “Lists and Libraries”
Note: Anonymous users still don’t have access to anything, but now you can choose individual lists and libraries to give anonymous access to.
Browse to the view lists page for your mysite host (https://mysite.contoso.com_layouts/15/viewlsts.aspx) and choose Settings for the User Photos library.
Click “Permissions for this picture library”.
Choose “Stop Inheriting Permissions” in the Ribbon.
Choose “Anonymous Access” in the Ribbon, select “View Items” and click ok.
Note: I have not tested this yet with SharePoint 2016 and Microsoft Identity Manager (MIM) 2016, but I'm guessing MIM still lacks the capacity to authenticate via SAML, so the same resolution applies there.
More Query Words for Bing:
My Site mysite
Active Directory Federation Services ADFS
Trusted Provider
Trusted Identity Token Issuer
SAML claims
Forefront Identity Manager FIM
Microsoft Identity Manager MIM
User Profile Synchronization
Profile Sync
stopped-extension-dll-exception
Comments
- Anonymous
January 19, 2018
I'm in the process of setting up MIM User Profile Sync with a Farm that also uses ADFS for user authentication. I'm having a hard time finding any documentation online about how to prevent duplicates. MIM exports the users to SharePoint with account names in the format DOMAIN\username. It looks like profiles with SAML account names are also created by the ADFS connector. How do you correlate the two so that a user is assigned to their correct profile when they log in, and we do not have duplicate profiles for everyone?- Anonymous
January 21, 2018
You're getting duplicates because MIM is not importing the profiles with the correct account name. It should be done in SAML-claims format and look something like i:05.t|ADFS|Josh@contoso.com (where "ADFS" is the name of my trusted provider, and I'm using email is my identity claim).Like setting up ADFS profile sync in SharePoint 2010 or 2013 with the built-in FIM Sync option, in order to get the proper account names, you need to map the SPS-ClaimID (display name: "Claim User Identifier") property to whichever attribute you're using as your Identity claim. With MIM, this mapping must be done manually. My esteemed colleague Adam detailed this process here: https://blogs.technet.microsoft.com/adamsorenson/2017/02/28/sharepoint-2016-mim-and-samlfba-user-profiles/
- Anonymous