The Plot
So, your intrigue has gotten the better of you, and you have decided to start exploring the awesome world of Office 365 (or your boss is making you for your job). You proceed to set up a small account for testing and investigation, maybe using the Business Essentials license. And hey, after tinkering around inside the Office 365 Admin Center and getting better oriented with the layout and setup, you decide it is time to take this party to the next level: exploring the full power of Directory Synchronization with SSO! Let's take a breather from the excitement, and make sure we have a few things in order first in order to make this work.
- Make sure we have a public domain name purchased and set up within Office 365 (this domain name will match the Active Directory domain that we will set up in our "on-prem" lab environment. This link will get you started with properly verifying your domain ownership within Office 365, and then adding it in: https://support.office.com/en-in/article/Verify-your-domain-in-Office-365-6383f56d-3d09-4dcb-9b41-b5f5a5efd611?ui=en-US&rs=en-IN&ad=IN
- Set up a single server as a Domain Controller in its own domain (single-forest, single domain). Ensure the Active Directory domain used matches the public domain you have setup in Office 365. For lab purposes, I would recommend setting this up in a public Cloud environment to remove any networking restriction road blocks that may be in place within your organization's internal network. Personally, I prefer the ease of use and mind-blowing fanatical support that you get with the Rackspace Managed Cloud: http://www.rackspace.com/cloud (Disclaimer: my opinion of Cloud providers may or may not be influenced by the fact that I also work for Rackspace Hosting; I'll leave that to you to decide.)
- Once your AD DS is properly installed and configured, you then need to install and configure Active Directory Federation Services through the Roles and Features wizard: http://blogs.technet.com/b/rmilne/archive/2014/04/28/how-to-install-adfs-2012-r2-for-office-365.aspx. Please note that this will require an SSL certificate to be installed, and to accomplish this, I simply installed an enterprise Certificate Authority through the Roles and Features wizard on the same Domain Controller that I already had in place (This is not a configuration that I would recommend at all in production, but it works just fine for a lab). Just a recap, this server now has AD DS, AD FS, and an AD CA installed on it. Again, only pursue this configuration in a lab environment, NOT production.
- Finally, create a few users in Active Directory Users and Computers. This will simply be to showcase that DirSync worked.
Now that we have prepped our lab (assuming no firewalls or networking roadblocks are in the way), it is time to prep Office 365 for Directory Synchronization with Password Sync. We can then actually run the sync from our lab DC.
Rather than go into detail on how to configure Office 365 for Directory Synchronization, and then subsequently how to run the tool in your lab environment, I am going to provide you a link to a well-written and documented (images) process for doing this. Why? I hate re-inventing the wheel, and that is not the aim of my article, exactly. So here you go: https://www.cogmotive.com/blog/migration/setting-up-dirsync-between-active-directory-and-office-365.
So what is the point of this post, then?
Fair question! Since I have gone to the trouble of providing all the detail above for prepping a lab environment, and then didn't follow up with detailed instructions on the actual Directory Synchronization process, it is understandable that you may be wondering what the point of all this is. Here it is: it is not recommended to install the Azure Active Directory Sync tool on an Active Directory Domain Controller, and doing so will likely present you with the an error towards the end of the wizard. Since my lab is based on a single server that includes the AD DS role, it is clearly not following recommended guidelines, and thus you will run into the following error: "Constraint Violation Error." Super helpful, right? Yeah, that's what I thought. Well, after a little bit of digging, I found the answer in the MSDN forums. If you installed the Azure Active Directory Sync tool on a Domain Controller, at the end of the wizard, uncheck the "Start Configuration Wizard Now" checkbox before finishing. THEN, log off of the DC, and log back in, starting up the Configuration wizard after your re-log.
Wasn't that super intuitive? At any rate, I had not unchecked the box, and was thus receiving the error. No problem. Just close the Configuration Wizard, re-log, and then open it again, and no more "Constraint Violation Error" message! To make sure credit is given where it is due, I found the solution posted by Susie Long of MSFT here: https://social.msdn.microsoft.com/Forums/en-US/1f104bc6-04cd-408d-9eab-d051a402d906/windows-azure-active-directory-sync-setup?forum=WindowsAzureAD.
Stay techy, my friends!
No comments:
Post a Comment