How to Migrate SharePoint Users to ADFS

Or “how to move users from domain A to untrusted Domain B, using ADFS from domain A”.

Moving from a domain authentication to ADFS authentication is becoming a not uncommon activity these days, partly because incorporating ADFS into your on-premises farm is the first stepping-stone in moving either completely or partially into SharePoint Online for your SharePoint needs.

I did this for a customer just recently based on this excellent article but more focused on specifically a SharePoint 2013 application/content-db + some refinements to the script.

Lab Setup

For this lab I’ve got two domains; one for on-premises only testing, “sfb-testnet.local” (“SFB-TESTNET” NetBIOS name) and another “” (“AWESOME” NetBIOS name) for hybrid SPO/on-premises testing. I actually own the actual domain for real; I’m a bit of a sci-fi fan and couldn’t think of anything else to call it but I digress…

We want to move SharePoint off the domain “” and just use the ADFS server there. Normally you’d have to modify the UPNs as an extra step so they match your Office 365 users but that’s a bit out of scope for this specific exercise.

Anyway, the point is the content DB started with native users and needs to be migrated over to my on-premises setup. Here are said setups.


Migration Steps

Just to show it working 1st; here’s SharePoint on domain “awesome”. Bob can login fine; SharePoint grants the right permissions to him.


“Awesome\Bob” and “Awesome\Jim” have access via site permissions specifically as you can see:


Content Database Migration & Application Setup

Content DB is copied over to the “sfb-testnet.local” SharePoint install; new application created with the content DB, and ADFS enabled for the zone.


A local domain user is set as the SC admin to be able to run the PowerShell:


If this doesn’t happen, “Get-SPUser” gives this error:

Get-SPUser : Access is denied. (Exception from HRESULT: 0x80070005)

User Migration Script

Here’s where most of the magic happens. We simply want to update the claim format from the previous authentication provider (awesome AD) to the new one (awesome ADFS).

These values will depend on the name of your claims setup in ADFS and the name of your SPTrustedClaimProvider. We do this with this script (note: please test & take a backup first! ):

$groupprefix = "c:0-.t|awesome adfs|"

$userprefix = "i:05.t|awesome adfs|"

$usersuffix = ""

# Get all of the users in a web application

$users = Get-SPUser -web "https://sfb-sp15-wfe1:8080/"

# Loop through each of the users in the web app

foreach($user in $users)


# Create an array that will be used to split the user name


$userlogin = $user.UserLogin

$username = “”

if($userlogin.Contains("i:")) # for users


$a = $userlogin.split('\')

$username = $userprefix + $a[1] + $usersuffix


elseif($userlogin.Contains("c:")) # for groups


$a = $displayname.split('\')

$username = $groupprefix + $a[1]


if ($userName -Like ("*" + [Environment]::UserName +"*")) {

Write-Host "Skipping this user '$user' so as to not loose SPA full-control rights..."



if ($userName -ne '') {

Write-Host "Moving '$user' to '$username'..."

Move-SPUser –Identity $user –NewAlias $username -ignoresid -Confirm:$false




This will change “i:0#.w|awesome\bob” to “i:05.t|awesome adfs|”, for example for everyone except the executing user, as that would kill the script half-way through (you don’t want to migrate the site-collection “owner”; that user needs to stay the same).

Bear in mind also that the user running this PowerShell needs to have “full control” rights to the user profile service application or else you’ll see a bunch of errors.


All being well, this is what you should see – no red text. If you do see errors of some kind, review if users have been moved (sometimes the error doesn’t seem to impact the move) and look at restoring from backup if needs be.

Testing the Migrated User Security

Assuming your output looked something like mine, logging into the new site via Awesome ADFS should now work.


ADFS now issues the logon challenge, not SharePoint.

Once authenticated, SharePoint recognises the new token and should grant access.


If you see a “sorry this site hasn’t been shared with you” then your move didn’t work.

Click on “My Settings” and you should see this:


The new token converted fine. Let’s check the permissions…


Bob still has the same admin rights as before. Users have been migrated successfully to ADFS; good times.


// Sam Betts