Has anyone used SailPoint for SharePoint as an Identity Provider?

As opposed to limiting to governing entitlements in SharePoint, has anyone skipped Active Directory using LDAP to IIQ? This would require User Profile Synchronization in SharePoint via LDAP to create SharePoint user profiles. Additionally, the use of the LDACP solution in SharePoint to resolve people picker issues.

Hi @sschaff

If by “Identity Provider” you mean the system SharePoint trusts for user authentication / tokens, SailPoint IdentityIQ (and ISC) aren’t designed to be that. SailPoint is an IGA platform (governance + provisioning). It can integrate with SSO, but in that model IIQ is the Service Provider (SP) and you still need a real IdP (AD FS / Entra ID / other) to authenticate users.

For SharePoint:

  • SharePoint Online authentication sits under the Microsoft 365 tenant and relies on Microsoft Entra ID (Azure AD).

  • SharePoint Server (on-prem) supports federation via AD FS (SAML/WS-Fed) and newer options like OIDC with Entra ID (Subscription Edition guidance).

On the “skip AD and use LDAP-to-IIQ” idea: SharePoint’s AD Import for User Profile synchronization explicitly does not support generic (non-AD) LDAP sources.

And the common “people picker” fix you referenced is likely LDAPCP (not “LDACP”) — it’s a SharePoint claims provider that queries AD/LDAP directories to resolve users/groups; it’s not an IIQ feature and it expects a directory to query.

Practical pattern I’ve seen work:

  1. Keep a real directory/IdP (Entra ID / AD DS + AD FS / another LDAP directory behind a proper STS).

  2. Use SailPoint IIQ/ISC to govern and provision access (groups, SharePoint permissions, lifecycle), but not to replace the IdP/directory.

check those resourcs for more details if you like to dig deep in the topic