Adding additional SharePoint Connections to account for multiple User Directories with differing UPN's.

Document ID : KB000009148
Last Modified Date : 14/02/2018
Show Technical Document Details
Issue:

The R12.52 SP1 Agent for SharePoint 2013 fails to generate the Assertion for new Users added to a SharePoint Connection from a second User Directory with the required Virtual Attribute Mappings defined in the User Directory Definition.

Environment:
R12.52 SP1 Single Sign On Agent for SharePoint 2013
Cause:

The SharePoint Connection that was originally created via the SharePoint Connection Wizard was created with a "UserIdentifier" mapped to "USER_ID" in a DB2 DataBase. This creates the associated Legacy Resource Partnership within SSO with the UPN defined as "USER_ID". All User Directories that are configured within a SharePoint Connection must contain the "UPN" attribute defined for the Resource Partnership. The second User Directory did not contain the "USER_ID" attribute, which prevented the Assertion Generator from generating the Assertion.

Resolution:

Resolution #1:

 

1.) Create an attribute in the second User Directory with a name that matches the defined "UPN" of the SharePoint Connection, and that contains a value that is the "Unique User Id" of the user.

 

Resolution #2:

 

1.) Create a second SharePoint Connection via the SharePoint Connection Wizard, and define a "UserIdentifier" attribute that is appropriate for the second User Directory.

2.) Create the second Trusted Identity Provider in SharePoint by modifying the newly generated ".PS1" script, properly modified with a "separate" Signing Certificate. 

Note: Microsoft SharePoint does not allow multiple Trusted Identity Providers to be configured with the same Signing Certificate.

3.) Update the Claims Provider of the new Trusted Identity Provider with the "Update-SMTrustedIdentityTokenIssuer.ps1" script.

4.) Modify the "Users" in each Legacy Resource Partnership within SSO to utilize the appropriate User Directory for the SharePoint Connection.

5.) Select the new Trusted Identity Provider for the Application in the SharePoint Central Admin Console.

6.) Create User Policies in SharePoint for the new Users.

 

This solution will result in the user being prompted by SharePoint to select the appropriate Trusted Identity Provider (TIP) to perform the Authentication. This is the same prompt received if the Application supports both Windows Authentication as well as "Claims Authentication".

Additional Information:

The following link is a KB Article which discusses a method to utilize the ProxyRules.xml file to build FORWARD links for Login Requests to perform the function of determining the appropriate Trusted Identity Provider for the request so that the user is not prompted by SharePoint.

 

TEC1519392