0

We have configured Okta as a trusted authentication provider to out SharePoint 2013 On-Premises environment. The user can log into Okta and access the SharePoint 'app' but when it connects them to the homepage, they are met with 'Sorry this site has not been shared with you'. It's like their account does not have access to SP, or is not being recognised. I can see in the logs that a valid SAML token is coming in, but I think we might be missing a step where that is converted to a valid Active Directory account.

In the deployment guide they talk about 'recommending' that we install the Okta People Picker plugin. I don't want to do this if we don't have to, I was under the impression we didn't need to add 'Okta' users into SharePoint as it would map the SAML claim to their Active Directory account and grant them the same access they would have if they were inside the network...

Any help would be appreciated.

1 Answers1

-1

First off, in order for users to be able to be looked up you'll need to definitely add the people picker plugin in. The biggest snag that the documentation doesn't accurately describe is that you'll need to import the okta cert chain to the server and establish trust in central admin for 2013 (not just 2010 only). Following all steps in the guide (including certs) got that going.

Okta-SharePoint on-prem guide: https://support.okta.com/help/articles/Knowledge_Article/Microsoft-SharePoint-On-Premises-Deployment-Guide

As for access to the site: once you get the people picker configured then you need to ensure you have migrated your user profile users from AD as the new type of claim for your identity provider. For the most part you can follow the guide below and just update the appropriate spots for Okta:

https://blogs.msdn.microsoft.com/sambetts/2014/09/03/how-to-migrate-sharepoint-users-to-adfs/

For extended troubleshooting I would recommend leveraging a ULS log viewing tool and to filter the results by the name of your claim identity provider.

iamjaredm
  • 11
  • 3