SharePoint to Active Directory Federated Services to NetIQ Access Manager and Back

Over the past few months, I have been working with a client helping them to configure SharePoint 2016 on-premises to Microsoft Active Directory Federated Services (ADFS), specifically to allow federated users to access K2 Workflow within SharePoint. The configuration for SharePoint and Active Directory Federated Services (ADFS) is the same as I have always done with a couple of claim rule changes and additions.

K2 Workflow requires the following custom claim rule sent as part of the claim attributes into SharePoint.

## K2 Workflow Additional Claim

=> issue(Type = “http://schemas.k2.com/identity/claims/identityprovider”, Value = “ADFS”);

This claim is required for various components to work. The K2 authentication claims needed by default are:

## Common K2 Workflow Claims

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”]

=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”, “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name”, “http://schemas.microsoft.com/ws/2008/06/identity/claims/role”), query = “;userPrincipalName,mail,tokenGroups;{0}”, param = c.Value);

Once configured, users can then automatically log into SharePoint, ADFS, and also K2 Workflow (Designer, Runtime, and Workflow).

During this work, the second requirement is to allow end users accessing SharePoint outside of the network, to authenticate through ADFS, but the login request needs to be “NetIQ Access Manager.“

https://www.microfocus.com/en-us/products/netiq-access-manager/overview

Two tasks need completing for this to work. The first is to add an ADFS “Claims Provider Trust.” Most organizations use ADFS for “Relying Party Trusts,” which allows end users to authenticate directly to an application such as SharePoint via ADFS. A claims provider trust adds second authentication process into the mix, which then federates through ADFS, back to the application. The application is only aware the end users logged in via ADFS, as the SAML Token and attributes transform into the ADFS format before being sent to the application.

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts

However, during the configuration and testing, I realized that using ADFS version 4.0 (Windows Server 2016), the setting is not the same as outlined in the documentation. From the Access Manager side, all is the same as written. However, an essential item was missing within the specific client environment. In the documentation, it says to take the ADFS Signing Certificate and upload that into Access Manager. At the point, it allows for ADFS and Access Manager to communicate; however, during the testing, it would fail every time with certificate errors.

To troubleshoot this, I executed this list of tasks:

Set Private Key permissions in the Certificate store for the signing certificate
Ensured the servers fully trust the certificates (by default the Signing/Decryption certificates in ADFS are not trusted)
Re-upload the ADFS signing certificate into Access Manager
Set the Claims Provider Trust “Secure Hash Algorithm” is set to “SHA-1” instead of “SHA-256.“
Uploaded all root and intermediate certificates in the chain and trust them
Reassess permissions for services accounts

Even after checking these items, nothing worked at all. As a group, we reached out to the support team at NetIQ, to see what is missing but to no avail. However, after building a new lab at home, and installing Access Manager, I noticed that it seemed to use its own signing certificate and never used the ADFS signing certificate, at least for the SAML piece. That meant that when the SAML token is issued and sent back to the ADFS trust, it fails as the signing certificate is different from the one used in Access Manager.

The service trust endpoint is correct: https://{adfs-url}/adfs/services/trust

After debugging, with ADFS Debug log, Admin Log, Fiddler and browser tests, I realized that that ADFS could not access the SAML token because it did not use the same Certificate for signing. Within ADFS I firstly set Certificate Auto Rollover to off.

Set-AdfsProperties -AutoCertificateRollover $false

I then uploaded the same signing certificate used in Access Manager and set that as the primary signing certificate. Testing revealed it worked as expected I no longer saw the certificate issues from previously. To make this work, was as simple as using the same signing certificate on both ADFS and Access Manager to ensure the trust worked.

The next hurdle is to map the correct claims provided from Access Manager, transform them to match the ADFS ones needed for SharePoint. The following claim rules exist within the Claims Provider Trust configuration:

## Identifier Claim

c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”, Properties[“http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format”%5D == “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”]

=> issue(claim = c);

## Name Claim

c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name”%5D

=> issue(claim = c);

## Email Address Claim

c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”%5D

=> issue(claim = c);

## Role Claim

c:[Type == “http://schemas.xmlsoap.org/ws/2008/06/identity/claims/Roles”%5D

=> issue(claim = c);

Access Manager requires Claims Transformation rules within the ADFS “Relying Party“:

## Email Address Claim Transformation

c:[Type == “http://schemas.xmlsoap.org/ws/2008/06/identity/claims/emailaddress”%5D

=> issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

## UPN Claim Transformation

c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”%5D

=> issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

## Role Claim Transformation

c:[Type == “http://schemas.xmlsoap.org/ws/2008/06/identity/claims/Roles”%5D

=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/role”, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

With the transformation rules, the claims match the standard ADFS NTLM login claims ensuring that SharePoint Server 2016, sees the end user login as a single claim.