Converting ADFS domains to DirSync with Password sync, step by step

Body:

Overview of Office 365 single sign-on experience 

In this post I’m not going to cover the advantages of dirsync with password sync. You can find a lot of articles on this blog to help you with that.

But what do you do when you are convinced that you want to transition from ADFS to DirSync with password sync. First you have to realize is that it’s a completely different user experience. So make sure your users are briefed of what is going to happen. Luckily this transition will NOT result in a new outlook profile, so it’s mainly a matter of re-entering your passwords and a new log on experience with the Web Apps.

When I do a transition from ADFS to DirSync with Password Sync, these are the steps that I follow. It’s not enough to follow these steps, you have to understand as well and know where to add some checks to see if all goes well. One tip of advice, make sure you have somebody by your side who can help you if things are working for you. A well trained professional in this case is not a luxury, since we are talking about authentication and synchronization .

Step 1: Make sure you have a DirSync in place with Password Sync. You can run the configuration but do not run the synchronization yet. The reason why I put this on step 1 because there can be some issues with the uninstall / reinstall part of DirSync and you just want to take your time to get the configuration and filtering correct.

Step 2: Log on to the Office 365 PowerShell and run the following command for the domains that have to transition:

convert-msoldomaintostandard –domainname wdomain –skipuserconversion $false –passwordfile C:\password.txt

Do not forget the -skipuserconversion $false. This will convert all the users of that domain to be a regular user instead of a federated user. Check the status of the domain by using the cmdlet

Get-MsolDomain

Now the conversion can sometimes go wrong. E.g. the domain can be converted but not all the users are converted due to a connection issue, prototocol error, … If this is the case make sure you run a script that converts all users back one by one.

This can be an example of such a script:

$msolusers = get-msoluser –All | where {$_.userprincipalname –like “*@”}

foreach ($user in $msolusers)
{
try {
$Upn = $user.Userprincipalname
$pw = Convert-MsolFederatedUser -UserPrincipalName $Upn -ErrorAction "Stop"

write-host $Upn
}

Catch {
if ($_.FullyQualifiedErrorId -like 'Microsoft.Online.Administration.Automation.UserAuthenticationUnchangedException*')
{
write-host "User already converted"
}
Else
{
write-host "Exception " + $_.FullyQualifiedErrorId
}
$_.Clear
}
}

if this is finished, your users are converted and ready to accept a new password from DirSync.

Step 3:  Full Import – Full Sync on your AD Management agent in DirSync. The FI/FS within DirSync will kick in a general password change request for all synchronized users. This happens with 50 requests at a time, so it might take some time. Check your event viewer for eventids 650, 656 and 657 to monitor the progress.

Step 4: Test passwords. 

Source: http://www.office365tipoftheday.com/2014/03/10/converting-adfs-domains-dirsync-password-sync-step-step/

Category: How to do; Servers; Ideas
Published: 3/14/2014 16:13
]]>