Office 365 using DirSync users cannot change passwords in Office 365

If you do directory sync from AD to Office 365 users will not be able to change their passwords on the Office 365 portal. Since the AD sync is a one way process the password changes do not come back into AD locally. Thus by default the Office 365 Portal will not allow users to change their passwords as they will just be overwritten by the local AD.

The problem this creates is sometimes you have a mix of users some local and some that may not have local domain access to change their passwords. The following is a work around using OU exclusion from DirSync.

First we need to put the users in a separate OU such as “Webmail” then we will exclude that OU from DirSync. That will allow them to change from “Directory Synced” to “Cloud”. Which you can confirm in the Office 365 Admin Console. Here are the steps:

Caution: Seasoned Domain Admins Only this is Active Directory and email flow will be impacted for users as they are changed

“you break it you bought it…”

Copy Shortcut to desktop

C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe
clip_image001

Open and select Management Agents and The Active Directory Connection:

clip_image003

Right Click and Select Properties:

clip_image005

Select Configure Directory Partitions and Containers:

clip_image006

You will be prompted for credentials enter in your LOCAL ADSync Username and Password

clip_image008

Browse and Exclude the OU:
clip_image009

Select “OK” “OK”

You can now force the DirSync process.
Open up PowerShell as Administrator and Run the following command to initiate a sync:

Import-Module DirSync
Start-OnlineCoexistenceSync -fullsync

clip_image010

Select the Operations tab to view status:
clip_image012

Note Deletions in the bottom right:
clip_image013

Note: force the DirSync process 2 to 3 times to make sure all settings synchronize

Log onto Office365 portal> Deleted Users> Select Users> Restore Users:

clip_image015

clip_image017

clip_image019

The users should now be able to change their passwords from the webmail interface. If not use the admin console to force a password reset per user to purge out any AD password settings.

In my testing since I performed this process after hours and quickly restored the accounts little to no email was kicked back as “recipient does not exist” additionally the end users did not notice any impact to their email as it is in a limbo state not yet truly “deleted”

I would recommend you use a test account or 2 to make sure you have the process down before doing any mass moves.

Comments

Popular posts from this blog

FRS to DFSR Post Cleanup “File Replication NtFrs Stopped”

Domain Migration SubinACL /Migratetodomain How To:

How to configure HP LaserJet Printer IPsec Encryption