Migrate to claims-based authentication

This document describes how to migrate SharePoint from classic authentication to claims-based authentication when using Nintex Workflow.

Two main issues may occur in Nintex Workflow when upgrading to claims-based authentication.

1. Workflows which contain actions with embedded credentials will fail.
2. Workflows which wake after a Delay action will fail to continue after the migration.

Issue 1: Workflows which contain actions with embedded credentials will fail.

If embedded credentials are stored in the workflow definition, the workflow can fail as the credentials no longer match the new domain. Actions which may result in embedded credentials include Call Web Service, Execute SQL, Copy to SharePoint, etc.

Issue 2: Workflows which wake after a Delay action fail to continue after the migration.

When a workflow is initiated, it is compiled, and that "snapshot" of the workflow is stored within SharePoint until the workflow completes. Workflow instances that "sleep" as a result of a Delay or Task action are stored within the SharePoint content database. When the workflow wakes, SharePoint takes the stored credentials and attempts to execute the workflow in the context of the original initiator. If the migration is completed while the workflow was asleep, the (Compiled) credentials are invalid and the workflow will end in error.

We have also noticed the following when migrating to a new domain, or to claims based authentication when using Nintex Workflow.

• Workflows become un-published
• Workflow history is unavailable
• Tasks associated with the workflow do not appear when viewing the workflow history
• Workflow tasks cannot be approved
• Workflows miss altogether from the SharePoint Workflows page
• The workflow status column is missing from the list on which the workflow ran

While the above list isn't definitive, these are some of the issues that our customers see during their migrations. The key to most of these issues is to make sure you have your users complete as many outstanding workflows as they can before the migration and ensure that you perform the steps to migrate users inside of the Nintex database.

Follow the steps below to update the domain of all users within the “Old_domain” to “New_domain.

Note: If you're upgrading Nintex Workflow, do that first. Nintex Workflow 2016 contains the required stored procedures.

1. Run the following SQL statement against the NW config database.

exec dbo.MigrateDomainInConfigDB @OldDomain = 'domain\', @NewDomain = 'domain\'

2. Run the following SQL statement against each NW Content database:

exec dbo.MigrateDomainInContentDB @OldDomain = 'domain\', @NewDomain = 'domain\'

Note: The MigrateDomainInContentDB needs to be run against every Nintex Workflow database that is acting as a content database. If you have a single database acting as a config and content database, this script will need to be run.

Example of users before a claims-based authentication migration: 

Example of users after a claims-based authentication migration: 

Note: You must specify both old and new domains in the format domain\ (including the trailing "\"), to ensure the script does not update a username and also remember to add the claims designation to the new domain name (“i:0#.w|domain” for example) if you are also moving to claims at the same time. The “i:0#.w|domain” claims identifier is based off of windows authentication. If you are using another form of authentication (such as Kerberos, forms, ADFS, etc.) please confirm the claims identifier. (Example: “i:05t|adfs|username” adfs through claims.)

As always we'd recommend thorough testing wherever possible before performing the migration.