Sean Wallbridge
O365 rocks but it can frustrate your users if they have to remember one set of credentials for Windows and another set for O365. I mean we all have way too many logins and passwords nowadays so why burden your users with yet another set of creds? Small O365 installs might get away with simply setting the user passwords to be the same password in Windows and in O365 even if the account used to login is different (eg in Windows it is my login name, rdick; in O365 it is my email address [email protected]). But once you have more than a few users the management piece starts to get a little crazy.
This is where the DirSync tool and the three types of sign-in models that O365 supports comes in to play!
The first model that O365 supports is “Cloud Identity”. This is simply the basic identity that you use to authenticate to O365 on login. It has zero ties back to your local on-premises domain (your AD), your “identity” lies inside O365 itself. In most cases you would use your email as your O365 login. Nice and simple.
The second model that O365 supports is “Syncronized Identity”, aka “Same Sign On” (NOTE: This is NOT Single Sign On and that is a very important distinction). This model relies on DirSync to provide O365 with users and user passwords through a password sync mechanism. It is NOT Single Sign On because you can be asked to sign in more than once even though you use the same sign in and password (as in you have to sign in to the PC and also into Outlook and/or O365). It is Same Sign On because the login and password are the same everywhere. Note the arrows in the graphic depicting the info flow, it is one way from AD to O365.
The third model that O365 supports is “Federated Identity”, aka “Single Sign On” which is the full meal deal two-way federation between your AD and O365. This model also relies on DirSync but it does considerably more work, here, than in the “Syncronized Identity” model. This is well and truly Single Sign On which means you sign in in either place and have immediate access to the other without further credential challenges. Note the arrows in the graphic depicting the info flow, it is definitely bi-directional.
Syncronized Identity or Same Sign In is probably the appropriate model for many small to medium organizations because it is relatively easy to implement and does not require a tonne of additional resources. Let’s look at the process more closely for what you would do in a small user count install of 100 users on less(I’ll defer to my friend and colleague Stephanie Kahlam’s blog posts about setting up DirSync for the gory step-by-step details, see here for more info. Also note that since Steph wrote this post Microsoft has updated the DirSync installation and the Powershell information has changed. The DirsyncConfigShell.ps1 is no longer included, you need to open Powershell and import-module Dirsync).
The whole idea of the sync process is to have your local AD act as the “source of authority” for your O365 and your O365 users. This means that you explicitly want to control your O365 users (creation, modification, deletion) from the AD and NOT from O365 (more about this in a bit). DirSync provides this control by syncing user information from specified OU’s in your domain up to O365. By default, DirSync is configured to sync everything in your AD (all OU’s) up to O365 and this is something you really don’t want to do. Therefore, you are best to either create a net-new OU for your O365 users and put them into this OU OR ensure that all of your users are already in a “clean” OU. You do not want “junque” in the OU if at all possible. Then, when you are configuring DirSync, you will deselect all OU’s except the desired OU that you have just created or tidied up.
At a high level you first enable Synchronization in Office365 from the admin portal (be aware that it can take up to 72 hours to fully “light up”). You then install DirSync on one designated domain controller. If you have multiple DC’s you might want to pick the one that is “least used”. You do NOT need to install on more than one DC. Why? Because DirSync is a background, regularly scheduled process that updates O365 on a regular basis. If DirSync is NOT available for a short period of time because of an issue with the DC there is no measurable impact on the O365 users.
Note: Make note of Steph’s instructions in her blog as there are a few places during the install where you are prompted for something and your needed response is probably NOT what you would expect! In particular you don’t want to allow DirSync to just autoconfig so keep a sharp watch on the prompts. (In other words, DirSync install is NOT a Next –> Next –> Enter kind of thing).
Once you have configured DirSync you can let it attempt to run its first sync. It is going to try and do a few things:
It is going to try to match users in the OU with existing, licensed users in O365. As Steph illustrates in her blog, the match will be attempted against the user’s UPN and the email address that is listed in the AD User object with the user entry in O365.
This
Matches this
In other words, DirSync will attempt to determine if there is an entry for the user in both AD and O365 and if the AD entry has an email address that matches O365 and that the user has an active subscription and mailbox. If all this matches the user will be updated and O365 will show the user as “Sync’d with Active Directory”. If the AD User object has a blank or non-matching email address, DirSync will throw an error on the user and you will have to fix things and re-run DirSync. You will also get an error if everything matches but the O365 user entry is missing an assigned subscription and mailbox.
Next DirSync checks for users that exist in the AD but do NOT exist in O365. It will attempt to create the user in O365 using the UPN on the user account as the email address. Funnily enough, it will work backwards to the matching with an existing user … the AD object should NOT have an email address entered. If the AD User object has an email address entered there will be a failure noted in the logs. (Of course you will have made sure that you have a one-to-one match between the AD OU user objects and O365 users before you ran DirSync … yes???)
So, after the first DirSync run (and your subsequent “cleanup” runs to fix any indicated errors), all of your O365 users should now have a status of “Sync’d with Active Directory”. At this point DirSync will settle into its normal processes and will sync with O365 approximately once every three hours.
From this point forward you should always manage your users (for adds, password changes, deletions) from the AD. New users get added to the AD with proper UPN but blank email address. When DirSync next runs the O365 user account will be created and it will have the same password as the Windows account. Once the user account shows up in O365 you can attach the proper subscription to it in the O365 admin portal and the user will be good to go. As a rule of thumb, don’t panic if the user does not appear in O365 for at least three hours! And do NOT go ahead and create the user in O365 because you’ll end up messing things up; wait for DirSync to do its thing.
Users that change their password will see the password change pushed up to O365 within 3 hours of making the change at the Windows level.
If you delete a user in the AD then the user account will be deleted from O365 within 3 hours of making the change in the AD. Again, you have to wait for DirSync to do it’s thing.
Yes, having Synchronized Identity means there is a little more work for the O365 and Windows admin to perform but it means less hassles for your users. I think the effort required to set it up and the little bit of ongoing admin effort are well worth the rewards. Happy users mean happy admins!
NOTE: Microsoft has been busy polishing DirSync and updating/modifying its pre-req’s. I’ll do my best to post addendums to this post if things change substantially. Steph will probably also update her posts so we should have reasonably current info available on the itgroove blogs.