다음을 통해 공유

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 “awesomespaceships.com” (“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 “awesomespaceships.com” 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 awesomespaceships.com native users and needs to be migrated over to my on-premises setup. Here are said setups.

image

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.

image

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

image

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.

image

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

image

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 = "@awesomespaceships.com"

# 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

$a=@()

$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..."

}

else{

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|bob@awesomespaceships.com”, 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.

image

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.

image

ADFS now issues the logon challenge, not SharePoint.

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

image

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:

image

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

image

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

Cheers,

// Sam Betts

Comments

  • Anonymous
    June 15, 2015
    Hi, great article. For this migration, how will you setup the user profile service? Will you remove the Windows Profile Sync and leave only the ADFS? Then how would you configure the Claims mapping in User Profile Sync? Will you map to UPN or email? Thanks.

  • Anonymous
    June 24, 2015
    Hey Latte, Good question. Another post coming soon(ish) on that. // Sam

  • Anonymous
    February 25, 2016
    Hi Sam, great post, do you have answer on Latte question, I am on the same issue

  • Anonymous
    March 15, 2017
    The great news is this does not imply you want to go out and get a whole new set of furniture.

  • Anonymous
    May 07, 2017
    It's really a nice and useful piece of info.I'm satisfied that you shared this useful info with us.Please stay us informed like this. Thanks for sharing.

  • Anonymous
    May 25, 2017
    I loved this post! Someone said your blogs fairly often and you're always developing great stuff.I shared this on my facebook and my follwers loved it!Keep up very good work.

    • Anonymous
      June 23, 2017
      Thanks!

  • Anonymous
    July 09, 2017
    Great post. I'm facing some of these issues as well..