In this configuration, new users are automatically provisioned to SharePoint during the login process, provided they have the correct required role.

Any user information changed in SharePoint will not be updated to the Ubilogin Directory or Active Directory. SharePoint provides its own user account data synchronization capabilities. Configuration instructions of SharePoint's user account data synchronization process are provided by Microsoft. Support for user account data synchronization is beyond the scope of this integration and is not provided by Ubisecure.

Please refer to SharePoint product documentation for more information on user provisioning and control user access rights to modify personal user attributes.

Custom People Picker for improved usability

By default, when using claims based authentication without Integrated Windows Authentication, the SharePoint people picker will accept any entered user or group identifier, even if that user or group does not exist. The reason for this is to support users and groups from non-linked user repositories where dynamic filtering is not possible.

An example of the default functionality is shown in Figure 22. By default, it is possible to enter the group name "no such group" and create an access rule based on this, even if the "no such group" does not exist. In a federated sign-in environment, this could make it assign a user access rights to a resource, even before that user has been provisioned.

In many SharePoint use cases, all users are found in the Active Directory and access to SharePoint is limited to these AD users. For these use cases, the claims-based people picker is undesirable due to the poor user experience – a confusing concept and error prone user interface.


Figure 1. People picker functionality with default claims provider

Unfortunately, Microsoft provides no native method to filter claims against an existing AD user repository. This functionality is only enabled if Integrated Windows Authentication is enabled for a published site. Using Integrated Windows Authentication in turn disables the ability to use external authentication providers such as ADFS2 – effectively making strong authentication impossible in this configuration.

A custom claims provider must be used to filter the possible claims against real users in Active Directory. The open source project LDAPCP https://ldapcp.codeplex.com/ offers the required functionality and the deployment information. The LDAPCP project is subject to a BSD license and used under those terms.

Ubisecure recommends using LDAPCP. This component can be modified to match the needs of your own project. As seen in figure 1, a searching for the word "sharepoint" returns only valid AD groups containing the word "sharepoint". The functionality for user filtering is similar, allowing searching based on user email or display name. The functionality is described in the LDAPCP project page.


Figure 2. People picker functionality with LDAP claims provider

By default, user search returns only the user email address in the results panel and shows the user display name only after hovering over an added search result. Although this is functional, the end-user experience is not optimal and presents a risk of incorrect user selection. For this reason, Ubisecure will customize the LDAPCP claims provider to display the user's AD displayname field and email address in the search results panel. This will help to ensure an unambiguous and user-friendly user selection process.

The default text "LDAP Claim Provider" shown in Figure 1 can be modified to display a more user-friendly title, such as "Active Directory".

TIP: When testing and comparing the default claims provider and custom claims provider, please note that once you attach the custom claims provider to a SPTrustedIdentityTokenIssuer it is not possible to revert to the default claims provider. To restore the default claims provider, you first have to create a new SPTrustedIdentityTokenIssuer and then remove the old one.

Browser not supported