2.8.1 Configuring SSO to SharePoint Server

Access Manager supports the following versions of SharePoint:

SharePoint 2013
SharePoint 2016
SharePoint 2019

Access Manager supports the following versions of Operating Systems, MS Office, and Internet Explorer while integrating with SharePoint server:

Operating System	Internet Explorer Version	Microsoft Office Version
Windows 10	Internet Explorer 11	MS Office Professional Plus 2016
Windows 10	Internet Explorer 11	MS Office Professional Plus 2013
Windows 10	Internet Explorer 11	MS Office 365 ProPlus
Windows 7	Internet Explorer 11	MS Office 365 ProPlus
Windows 7	Internet Explorer 11	MS Office 365 ProPlus

For information about how to integrate Access Manager with SharePoint 10, see the following sections in the Access Manager 4.3 Administration Guide:

NOTE:Microsoft has stopped the mainstream support for SharePoint Server 10.

Integrating Access Manager with SharePoint 2013, 2016, or 2019 includes the following high-level steps:

Configuring WS Federation Claims-based Authentication between Access Manager and SharePoint Server

To enable SSO to SharePoint Server, configure WS Federation claims-based authentication. In this configuration, Access Manager works as a WS Federation claims provider for SharePoint Server.

Access Manager contains a set of claims. Each claim represents a specific information about a user, such as username, group memberships, and role on the network. SharePoint supports claims-based authentication by obtaining the security token from the user and using the information within the claims to determine access to resources.

Perform the following steps:

Exporting the Certificates

Export the token signing certificate from Access Manager.
1. In Administration Console, click Devices > Identity Servers > Edit > Security.
2. Under Keystores, click Signing.
3. Under Certificates, click the certificate.
4. Click Export Pubic Certificate, select DER File, and save the file.
5. Make a note of where you have saved the certificate and copy this file to SharePoint Server for the later reference.
6. Import this signing certificate into Internet Explorer on SharePoint Server, and then export it in the DER format.
Export the root certificate (and intermediates certificates if they exist) if it is different from the token signing certificate.
1. In Administration Console, click Devices > Identity Servers > Edit > Security.
2. Click NIDP Trust Store and select the required trusted root.
3. Click Export Pubic Certificate, select DER File, and save the file.
4. Make a note of the name and location of the file.
5. Import this trusted root certificate and intermediate certificates into Internet Explorer on SharePoint Server, and then export it in the DER format.
Export the server certificate from SharePoint Server.
1. Open IIS Manager by clicking Start > Administrative Tools > Internet Information Services (IIS) Manager.
2. Under Connections, select your server’s hostname and double-click Server Certificates.
3. Export the server and trusted root certificates by highlighting the appropriate server and trusted root certificate and clicking View > Details > Copy to File > Next.
4. While exporting the server certificate, keep the default value No, do not export the private key.
5. Click Next. Keep the default format DER encoded binary X.509.
6. Specify the name and location for the exported certificates, and then click Next > Finish > OK.
7. Take a note of the name and location of the exported certificates. These certificates are used while configuring the service provider in Access Manager.

Configuring SharePoint Server as a Service Provider

Perform the following steps to configure SharePoint Server in Access Manager as a service provider:

Enable the WS Federation protocol in Identity Server. Enabling the WS Federation protocol also enables the Secure Token Service (STS) protocol that is used in requests from and responses to SharePoint Server.
1. Click Devices > Identity Servers > Edit.
2. In the Enabled Protocols section, select WS Federation.
3. Click OK.
4. Update Identity Server.

Create an attribute set for WS Federation.

Claims contain formatted name-value pairs. In Access Manager, an attribute set represents the same concept. An attribute set allows you to map attribute values from your configured LDAP user store to be sent to SharePoint as a claim.

When using WS Federation, you need to decide which attributes you want to share during authentication and map those in an attribute set. SharePoint uses these attributes to determine whether the user has permissions to access the applications and sites.

Perform the following steps to create an LDAP mail attribute and an All Roles attribute:

Click Devices > Identity Server > Shared Settings > Attribute Sets > New.

Specify the following details:

Field	Description
Set Name	Specify a name that identifies the purpose of the set. For example, SP2013-AttrSet.
Select set to use as template	Select None.

Click Next.

To add a mapping for the mail attribute, perform the following steps:

Click New.

Specify the following details:

Field	Description
Local attribute	Select LDAP Attribute:mail [LDAP Attribute Profile].
Remote attribute	Specify emailaddress.
Remote namespace	Select the option, and then specify the following namespace: http://schemas.xmlsoap.org/ws/2005/05/identity/claims

Field

Description

Local attribute

Select LDAP Attribute:mail [LDAP Attribute Profile].

Remote attribute

Specify emailaddress.

Remote namespace

Select the option, and then specify the following namespace:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims

Click OK.

To add a mapping for the All Role attribute, perform the following steps:

Click New.

Specify the following details:

Field	Description
Local attribute	Select All Roles.
Remote attribute	Specify role. This is the name of the attribute that is used to share roles.
Remote namespace	Select the option and then specify the following namespace: http://schemas.xmlsoap.org/ws/2008/06/identity/claims

Field

Description

Local attribute

Select All Roles.

Remote attribute

Specify role. This is the name of the attribute that is used to share roles.

Remote namespace

Select the option and then specify the following namespace:

http://schemas.xmlsoap.org/ws/2008/06/identity/claims

Click OK.

Click Finish.

Enable the attribute set.

As WS Federation uses STS, you must enable the attribute set for STS.
1. Click Devices > Identity Server > Edit > WS Federation > STS Attribute Sets.
2. Select SP2013-AttrSet in Available attribute sets and move it to Attribute sets.
3. Select SP2013-AttrSet and move it to the top of the list by using the up arrow.
4. Click OK, and then update Identity Server.

Create a WS Federation service provider.

Click Devices > Identity Servers > Edit > WS Federation > New > Service Provider.

Specify the following details:

Field	Description
Name	Specify a name that identifies the service provider. For example, sp2013.
Provider ID	Specify the provider ID of the SharePoint server. This value corresponds to the realm configured on SharePoint Server. It is visible in the incoming authentication requests from SharePoint Server to Identity Server. The example value is urn:SharePoint:portal. This value can be any logical string and is unique to this trust relationship. For example, if Access Manager is providing claims to multiple SharePoint environments, each SharePoint realm must be unique.
Sign-on URL	Specify the URL that the user is redirected to after login. You can construct this URL by adding _trust at the end of the SharePoint web application URL. For example, https://sp2013.com/_trust/ NOTE:If you use a different published DNS name than the SharePoint web application URL, then configure the sign-on URL as https://<published DNS Name:port/_trust/.
Logout URL	Do not specify any value. You need to configure the logout URL in SharePoint. See Configuring Logout.
Service Provider	Specify the path to the signing certificate exported from SharePoint Server. See Exporting the Certificates.

Click Next.
Confirm the certificate, and then click Finish.

Configure the name identifier format.

The default format for a new WS Federation service provider is Unspecified. This name identifier format does not work with SharePoint Server 2013 and you must change it. Additionally, the roles claims must be satisfied to gain access to SharePoint Server.
1. Click Devices > Identity Servers > Edit > WS Federation > sp2013 > Attributes.
2. In Attribute set, select the WS Federation attribute set you created.
3. In Send with authentication, move All Roles and Ldap Attribute:mail attributes from Available to Send with authentication.
4. Click Apply.
5. Click Authentication Response.
6. Select E-mail and then select LDAP Attribute:mail [LDAP Attribute Profile] as the value.
7. Click OK > OK, and then update Identity Server.
Set up roles for SharePoint claims.

Based on roles assigned in Access Manager, users can have different levels of access to resources on SharePoint Server.
1. Click Devices > Identity Servers > Edit > Roles.
2. Click New, specify a name for the policy, select Identity Server: Roles, and then click OK.
3. On the Rule 1 page, leave Condition Group 1 blank.
  
  This rule matches all authenticated users.
4. In the Actions section, click New > Activate Role, and then specify SharePointReader.
5. Click OK > OK > Apply Changes > Close.
6. On the Roles page, select the role policy you just created, and then click Enable.
7. Click OK, and then update Identity Server.

Import the SharePoint Server signing certificate into NIDP Truststore.

Identity Server must have the trusted root of the SharePoint signing certificate or the self-signed certificate listed in its trust store. Identity Server validates the SharePoint signing certificate at initialization time. This validation process must validate the issuer of the signing certificate (or chain of certificates up to the root). Most SharePoint signing certificates are part of a certificate chain, and the certificate that goes into the metadata is not the same as the intermediate or trusted root of that certificate.

Click Devices > Identity Servers > Edit > General > Security > NIDP Trust Store.
Under Trusted Roots, click Add > Select Keystores icon.

Click Import and specify the following details:

Field	Description
Certificate name	Specify a logical name for the SharePoint trusted root. For example, SP2013-tr.
Certificate data file (DER/PEM/PKCS7)	Select the previously exported SharePoint trusted root certificate. See Exporting the Certificates.

Field

Description

Certificate name

Specify a logical name for the SharePoint trusted root. For example, SP2013-tr.

Certificate data file (DER/PEM/PKCS7)

Select the previously exported SharePoint trusted root certificate.

See Exporting the Certificates.

Click OK.
On the Select Trusted Roots page, select the SharePoint trusted root certificate that you just imported, and then click Add Trusted Roots to Trust Stores.

NOTE:This option does not exist in Access Manger Appliance. All components (Identity Server, ESP, and Access Gateway share the same key store and trust stores.
Next to Trust store(s), click the Select Keystore icon.
Select the trust stores where you want to add the trusted root certificate, and then click OK > OK.
Update Identity Server.

Configuring SharePoint Server for Claims-based Authentication

Create the Access Manager Identity Server STS for the trust relationship with SharePoint.
1. Copy the certificates that you exported from Administration Console to the SharePoint server.
2. Add the Identity Server trusted root certificate to the SharePoint Server list of trusted root authorities by using the following PowerShell script:
```
$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\users\<administrator>\downloads\<certificate.cer>")

New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root
```
3. Create the cert parameter by using the Identity Server signing certificate.
```
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\users\<administrator>\downloads\<certificate.cer>")
```
4. Map the claims. The incoming claims are the remote attribute names that are defined in the Access Manger attribute set.
  
  The name and the case must match with the value in the attribute mapping. For example, let us assume that you defined emailaddress and role and these are appended to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ and http://schemas.microsoft.com/ws/2008/06/identity/claims/ name spaces respectively. In this example, the script to define the claims looks similar to the following:
```
$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "emailaddress" -SameAsIncoming
```
5. Define the realm. The realm defined here must match the provider ID that you specified while creating the service provider in Access Manager. For example, you can define the realm as urn:SharePoint:portal by using PowerShell with the following script:
```
$realm = "urn:SharePoint:portal"
```
6. Configure the Access Manager URL by using the following parameter.
```
$signinurl = http(s)://<$idp_host_name>/nidp/wsfed/ep
```
  When users access SharePoint with claims-based authentication enabled and need a claim to get authenticated and authorized, they need to send the request to Identity Server to generate the claim. SharePoint uses this URL to send the authentication requests.
7. Assign the custom IP-STS in PowerShell by using the following script:
```
$ap = New-SPTrustedIdentityTokenIssuer -Name "NAM-WSFED-IDP/" -Description "NAM WSFED Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1, $map2 -SignInUrl $signinurl -IdentifierClaim $map2.InputClaimType
```
  The -Name option is the display name that is used in SharePoint to assign the identity provider.
Create or modify SharePoint applications to use the claims-based authentication.

The application, for which you want to enable claims-based authentication, must be a secure application that uses SSL. Ensure that you have assigned the server certificate (that you have imported into Access Manager) to the website binding in IIS.

You will also need to create a Site Collection for this application if one does not already exist. When the application is created as a secure application, it creates the /_trust directory that is defined in Access Manager as the service provider’s login directory. Access Manager sends claim to this URL when the users credentials are validated successfully.
1. In SharePoint Central Administration, go to Manage Web Applications > [Application Name] and select Authentication Providers.
2. Select Trusted Identity provider and select the claim-based authentication provider. Scroll down to the Trusted Identity Provider section and select the Access Manager identity provider (NAM-WSFED-IDP).
3. Map the incoming claim to a SharePoint application. For example, lets map the SharePointReader role from Access Manager to a SharePoint application named SP2013 Application.
  1. Log in to the SharePoint site as an admin user.
  2. Click Site Actions > Site Settings > People and Groups > [site] > New. Specify the name of the Access Manager claim that you want to map to this SharePoint group in the Find box. For example, the name of the claim is SharePointReader. In this case, the following are the two claim-based entries:
    NAM-WSFED-IDP entry with emailaddress
    NAM-WSFED-IDP entry with Role as options
  3. Highlight the role in Trusted and click Add > OK > OK.
4. Select the permissions for the users with these roles.

Configuring SharePoint Server as a Protected Resource

You must configure only domain-based proxy service for SharePoint. Path-based proxy service is not supported.

For information about how to configure SharePoint Server as a protected resource, see Section 2.6.5, Configuring Protected Resources.

NOTE:Ensure that you have disabled Session Assurance for Access Gateway. Else, the integration between Access Manager and SharePoint may not work.

Enabling Advanced Options for the Proxy Service

Click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Advanced Options.
Set one of the following advanced options depending on the version of your SharePoint server

for enabling single sign-on:
- SharepointEnable on 2013
- SharepointEnable on 2016
- SharepointEnable on 2019

IMPORTANT:Access Manager 4.5 Service Pack 1 onwards, the NAGSharepointEnable option is no longer valid. If you have set up this option, you need to replace it with the option mentioned here based on your SharePoint server version.

Enabling Global Advanced Options

Click Devices > Access Gateways > Edit > Advanced Options.
Add the following advanced option:
```
NAGGlobalOptions AllowMSWebDavMiniRedir=on
```
For more information about this option, see NAGGlobalOptions AllowMSWebDavMiniRedir=on in Table 3-1, Access Gateway Global Advanced Options.

Modifying the WS Federation Assertion Validity Time

The lifespan of SharePoint WS Federation generated persistent cookie FedAuth is based on the value of the WS Federation Assertion Validity Time.

You must configure this validity time to match the sum of the following values:

Contract timeout specified in the contract configured for the SharePoint protected resource
SharePoint STS LogonTokenCacheExpirationWindow

For example, if the contract timeout is 60 minutes and SharePoint STS LogonTokenCacheExpirationWindow is 10 minutes, then set the WS Federation Assertion Validity Time to 70 minutes that is 4200 seconds.

To get the value of SharePoint STS LogonTokenCacheExpirationWindow, open SharePoint Management Shell and run the Get-SPSecurityTokenServiceConfig command.

To set the assertion validity for WS Federation, perform the following steps:

Go to Devices > Identity Servers > Edit > Options, and click New.
Configure the following property:

Property Type: WSFED ASSERTION VALIDITY

Property Value: Specify the assertion validity time in second.
Restart Tomcat by using the following command:

Linux: /etc/init.d/novell-idp restart

Windows:

net stop Tomcat8

net start Tomcat8

Configuring the Trusted Site in Internet Explorer

Add the SharePoint sites to the Local Intranet zone or to the trusted sites zone on the Internet Explorer browser.

Open Internet Explorer and click Tools > Internet options.
In the Security tab, click Trusted sites > Sites.
Specify the SharePoint site URL and click Add.
Click Close.

IMPORTANT:To enhance the security, enable the following options in the browser:

Go to Tools > Internet Options > Advanced, and then select Empty Temporary Internet files folder when browser is closed under Security.
Go to Tools > Internet Options > General, and then select Delete Browsing history on exit.

Configuring Logout

Modify logoutSuccess_latest.jsp. Open the logoutSuccess_latest.jsp and add the following lines in which are bold. This code clears the SharePoint service-specific cookie created by Access Gateway.

Linux: /opt/novell/nids/lib/webapp/jsp/

Windows: \Program Files\Novell\Tomcat\webapps\nidp\jsp

 NativeClientPersistentAuthenticationClass.clearCookie(request, response);
   {
           final Cookie newCookie = new Cookie("_PA_SDK_SSO_", "");
    newCookie.setMaxAge(0);
    newCookie.setPath("/nidp/");
    response.addCookie(newCookie);
   }

//***Expire the MFNAMSP Cookie **
        Cookie mfcookie = new Cookie("MFNAMSP", null);
        mfcookie.setPath("/");
        mfcookie.setMaxAge(0);
        response.addCookie(mfcookie);
 NIDPSessionAssurance nidpSessAssurance = NIDPSessionAssurance.getInstance();
        nidpSessAssurance.clearIDCCookie(request,response);
        response.setHeader("Connection", "close");
        UIHandler uh = new UIHandler(request,response);

Change the logout URL to nidp/app/logout in the SharePoint identity provider by using the following command in PowerShell:
```
$ip = get-sptrustedidentitytokenissuer
$ip.ProviderSignOutUri = "https://<idp-domain.com>/nidp/app/logout"
$ip.update()
```