
priyashil.gupta1.5450658651416614E12 (Customer) asked a question.
Hi Okta Team,
We have integrated OKTA as a SAML identity provider for our SharePoint 2016 environment. Please note that we already have latest people picker WSP installed on the SharePoint severs.
We have included firstName, lastName and email to be sent as SAML assertion(email as login name) from OKTA but noticing that only email id as display name is synced back to SharePoint user profiles. We need all user properties firstName, lastName and email synced to corresponding SharePoint profile properties.
Additionally we need to know if user profile service application(UPS) is a must have for profile sync from OKTA? Please be noted that we already have UPS configured.
Your response is greatly appreciated.
Thanks

Can anybody from OKTA respond to this. Its really urgent.
Hi Priyashil,
I am not sure why my comments didn't get posted originally, but I hope that you find the below helpful:
Thank you for creating a communities post for your issue.
Have a look at the following documentation regarding Profile Mappings:
https://help.okta.com/en/prod/Content/Topics/Directory/Directory_UD_Profile_Editor_Tasks.htm
On that page, under "Map Profile Attributes", you will want to review the steps to map the Okta attributes to their respective Sharepoint attributes.
Additionally, you may want to also review the "Configure Expressions" section for further details.
If the above helps, please let us know. Otherwise, this may be better suited for a full support case, in which we can assist with troubleshooting the issue further.
Thank you,
Brandon Wendorf
Technical Support Engineer
Thanks Brandon for your response.
I have checked the "Map Profile Attributes" setting and these attributes are mapped properly from OKTA to SharePoint but still issue persist.
I know that OKTA get a custom claim provider deployed with people picker WSP on SharePoint severs. I went further to disassemble the DLL and can see following lines to sync user profile attributes:
if (!OktaClaimsProvider.OktaClaimsProvider.FarmConfig.SyncUserProfile)
return;
try
{
this.SyncUserProfile(context, entity);
}
catch (Exception ex)
{
OktaClaimsProvider.OktaClaimsProvider.Logger.LogHigh("Error in FillClaimsForEntity when synchronizing user profile. Exception {0}, Stack {1}", (object) ex.Message, (object) ex.StackTrace);
}
}
It means that the code look for SyncUserProfile property at SPFarm to get attributes synched. I went through the OKTA documentation and installation instruction (https://support.okta.com/help/s/article/Microsoft-SharePoint-On-Premises-Deployment-Guide) but could not get any reference on this property.
I have set this property at farm level in my test environment and can see attributes syncing to User Profile Service Application in SharePoint.
I am curious to know if it is safe to use "SyncUserProfile" without any negative impact or if there is other workaround to achieve this as I cannot see this mentioned in any documentation.
Thanks,
Priyashil Gupta
Hi Priyashil,
As SyncUserProfile is not an Okta-specific property, and because I am unable to find any instances of this being used in an Okta-specific use-case, I can't really speak on whether or not it would have an impact.
If you are using it in a test environment with no issues, then I would advise that you use it in a production environment at your own risk.
Keep in mind that if you do encounter an issue should you choose to implement this, we would be able to troubleshoot it to a reasonable effort until we can say with confidence that the changes made are what are causing the issue.
Thank you,
Brandon
Thanks for quick response Brandon,
I am not sure why SyncUserProfile is not an Okta-specific property? This is a part of people picker WSP provided by OKTA. My intention to raise this question to OKTA was because I thought you can get the reference on it somehow internally or I can get any alterative to achieve this.
Thanks again for all your help.
My apologies for any misdirection I may have caused.
The reason I mention that SyncUserProfile is not specific to Okta is mainly because I can't find any evidence of this property in any of our documentation. I could be looking in the wrong place, but when I did not find it, I assumed that it was a Sharepoint property.
At any rate, as I mentioned in my last post, if you are using it in a test environment with no issues, then I would expect that it wouldn't have negative effects in production, but I would be sure to test and take extra care when deploying a change like this.
I would expect that the support ticket you've opened as supplement to this communities post would shed some more light on the resolution, as we would be able to help troubleshoot in the event there was an issue following deployment of this chance. I will let the engineer working with you on that take it from here, and I hope that you receive the answer you're looking for through that. Feel free to come back to this thread and post your findings, should you wish to share them.
Thank you,
Brandon