Exploring Azure AD Connect - Part 2: Configuring SSO with AD FS

Other posts in this series:

• Exploring Azure AD Connect - Part 1: Establishing Synchronization with Express Configuration
• Exploring Azure AD Connect - Part 3: Configuring User and Password Writeback with Azure AD Premium

Configuring Azure AD Connect with AD FS for Single Sign-On (SSO)

In the last post of this series I went over the basic, and fairly pain-free, process of syncing users and passwords from an On-Prem Active Directory environment to an Azure AD instance using the Express Configuration of Azure AD Connect. However, in some organizations, a requirement for single sign-on (SSO) may exist. After all, who wants to log into their laptop at the office, and then proceed to have to login to their O365-based OWA and SharePoint sites with the same credentials?! Not this guy.

Thus, a need for SSO exists, and Azure AD Connect can help meet this need by connecting to our Azure AD from our on-prem environment, setting up synchronization, AND installing and configuring AD FS. All this is done from the Azure AD Connect wizard, which is even more amazing. The wizard installs the needed pre-requisite software on the AD-joined server that you have set aside for Azure AD synchronization, and then proceeds to walk you through connecting to Microsoft Services Online (MSOL), following up with installing and configuring AD FS on the servers that you set up ahead of time. 

Let's take a look at what this process looks like.

Office 365 Environment

I am using the same Office 365 tenant that I used in my first post, using only Skype for Business Online Plan 2 licensing. To clean things up, though, I uninstalled Azure AD Connect completely from the on-prem server, deactivated synchronization in the Office 365 portal (this can take up to 72 hours to take effect), and then deleted all users that had synced from the on-prem Active Directory from the last post. Per the last post, the custom domain "s4blab.org" is already setup in the portal, with all necessary DNS records having been created. Lastly, before getting stared, I navigated to the Active Directory synchronization line at the top of the Active Users page in the Office 365 admin portal, and clicked the Manage link button. From there, I activated AD synchronization by click the Activate button, as seen below:

On-Prem Lab Environment

My "On-Prem" environment is actually a virtual environment in Rackspace's Public Cloud. All servers in this environment are running Windows Server 2012 R2, and have been fully patched, and all are domain-joined (in a typical production environment, you would have your AD FS Web Access Proxy in a DMZ, not in the AD domain). The environment consists of:

• 1 Active Directory Domain Controller
• 1 small server for installing Azure AD Connect
• 1 AD FS server
• 1 AD FS Web Access Proxy server

Please note, for Azure AD Connect to be able to install the necessary AD FS roles on both the AD FS and AD FS WAP servers, you must enable Remote Management on these servers. You must also do this on the DC, if you plan to have the wizard automatically create a Managed Service Account in Active Directory.

Configure Synchronization with SSO in Azure AD Connect

• First, you must download the Azure AD Connect tool onto the server that you have joined to the domain for establishing your hybrid synchronization scenario: https://www.microsoft.com/en-us/download/details.aspx?id=47594
• After you double-click the Azure AD Connect installer, the first screen you will see will prompt you to agree to the terms. The next screen prompts you to either choose Express Configuration or Custom Configuration. We do not want Express, as we need to set up ADFS. So choose the Custom option.
• The next screen asks what type of Synchronization we want. The first option will only allow for synchronization, but not SSO. Select the second option, Federation with AD FS, and then click Next. 

• Next, you need to input your Azure AD credentials. This should be an account within Azure AD that has the Global Admin role, and it should be the an account with a domain of "@domain.onmicrosoft.com"; DO NOT use an account with the same domain name as the AD domain that you are trying to set up synchronization for. 
• Next, input an account with Domain Admin privileges to connect to your on-prem AD. Once you have entered the credentials for the domain that is listed in the Forest box, click on Add Directory, and the domain will be added at the bottom. 
• On the Uniquely identify your users screen, leave the defaults, and click Next 
• On the Filter users and devices screen, you can either choose to Synchronize all users and devices, or you can specify a specific group in your AD that has the users that you want to synchronize. The second option is good for pilot environments, but to be perfectly honest, I was not able to get my environment to sync until I reconfigured the Azure AD Connect tool to Synchronize all users and devices. This is very likely a config problem on my part, but still, with no errors at all indicating a problem, either in the application or in the logging, I was not able to get to far on the troubleshooting. 
• For the Optional Features, simply leave the Password Sync radio button checked. In the below example, I also checked Password Writeback, but that does not need to be done for SSO purposes.  
  
• Now it is time to set up the AD FS farm. At the top of the AD FS Farm screen, you can choose to either Configure a new Windows Server 2012 R2 AD FS farm, or you can choose to Use an existing Windows Server 2012 R2 AD FS farm. Leave the default, which is Configure a new Windows Server 2012 R2 AD FS farm (Remember, we have a server ready for AD FS, but have not yet set up AD FS itself). Click the Browse button next to the CERTIFICATE FILE field, browse to your certificate with private key (.pfx file), enter the password for it, and click OK. You will now see the certificate's Subject Name below, and the new AD FS Service Name. Click Next.
  
• Next, enter the server name in the Server field and click Add. You will now see a progress bar at the bottom of the screen as connectivity to the AD FS server is verified. If you have not ensure that Remote Management is enabled on this server, as mentioned above, this step will not work until you do so.
  
• You can now see that the AD FS server was connected to and verified. Click Next. 
  
• Repeat the above step for the AD FS Proxy server, and then click Next. 
  
• Now you need to enter credentials that the Proxy server will use to request a certificate from the AD FS server. Once you do, click Next. 
  
• On the AD FS Service Account screen, leave the first option selected, Create a group Managed Service Account. Again, this will not work if you have not enabled Remote Management on the DC that you are attempting to connect to. Click Next.
  
• Almost through the wizard! Now you are at the Azure AD Domain. Select the domain that you want to federate with from the drop-down. If you only have one custom domain added in Azure AD, then you will only have the one domain available in the drop-down. Notice the warning at the bottom, that current logons will get disrupted during this operation. Click Next. 
  
• Finally, the Ready to configure screen will give you a nice little summary of the actions that are about to be performed. Leave the box checked for Start the synchronization process as soon as the configuration completes. 
  
• A progress bar displays the Configuring progress. Here we can see where AD FS is being setup remotely via the wizard. SO cool! 
  
• After the AD FS portion is completed, we see that the synchronization is kicked off: 
  
• The last screen, the Verify one, prompts you to set up the necessary AD FS DNS records in both your internal and external DNS zones. I had already set up the records for the AD FS service URL, and thus I clicked Verify, successfully resolving the records. Once we close the wizard, we should be able to go into our Active Users page in the Office 365 portal and view all of our newly synced users: 
  

At this point, we want to test our SSO capabilities. I temporarily set up one of the newly synced users, josh@s4blab.org, as a Global Admin, within the Office 365 Admin portal. When I browsed to https://portal.office.com, I get the typical Office 365 login page. After typing in the username and tabbing to the password field, however, I get redirected to my on-prem AD FS forms-based login page. Office 365 detected that the domain I was logging into was setup for SSO, and knew where to forward my users to. Very cool, and it also confirmed that AD FS was setup, functional, and reachable publicly.

After entering my password, though, and hitting Enter, I received a fairly generic error about not being able to be logged in: "Sorry, but we're having trouble signing you in. Please try again in a few minutes. If this doesn't work, you might want to contact your admin and report the following error: 80041034".

Well, I knew that the user had synced, cause I could see him in the portal. I knew that the AD FS sign-on page was reachable. I knew that AD synchronization with SSO showed as Activated in the portal. SO what was the problem?

Well, after digging into event logs (without finding anything helpful) and doing much research online, I finally discovered that there were some certificate issues within the AD FS Management console. The publicly-issued certificate that I provided during the AADC wizard was fine, but both the Token-decrypting and Token-signing certificates showed up as not Trusted when I viewed them within the console. To correct this, I performed the below actions:

• On the AD FS server, navigate to AD FS Management console -> AD FS -> Service -> Certificates.
• Highlight either the Token-decrypting or Token-signing certificate by clicking on it, and then click on View Certificate... in the Actions pane. 
  
• Once the Certificate window pops up, we see the ugly message below telling us that the certificate is not trusted. Click on the Install Certificate button.
  
• On the Certificate Import Wizard, make sure to select the radio button next to Local Machine, and click Next. 
  
• On the Certificate Store screen, check the box for Place all certificates in the following store, and then click Browse... 
  
• In the Select Certificate Store popup window, select Trusted Root Certification Authorities, and then click OK. Click Next on the Certificate Store screen, and finish up the wizard. 
  
• You should then see the below popup telling you that the import was successful. Click OK, and then click OK on the Certificate window. 
  
• Now, you should be able to open the Certificate properties window again, and this time you should not see any unsavory message about the certificate not being trusted. 
  

And that did it! I was now able to log in to the portal, while being redirected through my AD FS sign-on page, and was successfully authenticated. I am not sure if I just initially missed something when it came to the above issue with AD FS certificates, as I am sure the intended experience is for the Azure AD Connect wizard to handle the entire setup from one place, in a simple manner. However, for those of you that run into similar issues with trying to get SSO working with your directory synchronization, I hope the above helps you. Feel free to leave comments letting me know if this helped, or if you came across another piece of the puzzle!

The next and final post in this series will be going over some of the special features that can be achieved with Azure AD Connect if you have implemented the Azure AD Premium licensing for your users.

Stay techy, my friends!

Tools of the Trade - Office 365 Tools for Hybrid Deployments and Migrations - Part 2

Other articles in this series:

• Tools of the Trade - Office 365 Tools for Hybrid Deployments and Migrations - Part 1

What is the "DirSync" Tool?

DirSync is the easire-to-say name for the Microsoft Azure Active Diretory Sync tool. And honestly, with a name that long, a much-abbreviated form was definitely needed for a tool that would be at the center of almost all Hybrid environments with Office 365. So, what is it used for? Quite simply, it is the tool that is used to synchronize your Active Directory users in your On-Prem environment to your Office 365 deployment. You can use it to sync all users, or you can apply filters and synchronize only certain groups, depending on your plans for Office 365 usage.

Why is this important?  I will answer that by also answering why it is AWESOME. Let's say your plan is to house your Lync deployment on-prem (or Skype for Business deployment because you are cool and stay up with the times), but you want to migrate your Exchange users to Exchange Online. Ok, so now you need to create all those users in Office 365, so that they can access Exchange Online. Wait, does this mean that they have to sign in to Lync using one set of credentials, and Exchange Online with another set of credentials? Well, yes, it would mean that, if you didn't synchronize all of your existing users from your on-prem Active Directory. By putting this synchronization into place, all your users will stay properly synced up to Office 365, and you can even manage their accounts and settings from your on-prem environment, with the changes being synced to the account in the cloud. And this means that SSO can also be achieved! Oh happy day!!

What are the requirements for DirSync?

First of all, this tool should only be downloaded onto, and running from, a single machine in your domain. Further more, this server is not recommended to be a Domain Controller, as issues can arise (see my previous article about a specific issue that you will encounter: http://blog.msucguy.com/2015/04/office-365-directory-synchronization.html). It doesn't mean that it won't work on a DC, but if we are talking about a production environment, I would stick to the recommended guidelines.

Secondly, you will need to deploy Active Directory Federation Services in your environment if you wish to achieve Single-Sign On (SSO) functionality. This is very important for companies that want a streamlined user experience - not wanting users to feel like they are in two different environments, but rather working out of the same single environment like they normally would. This article does a great job explaining where ADFS comes into play, and the other types of synchronizations that can be used with it: https://support.office.com/en-ca/article/Understanding-Office-365-identity-and-Azure-Active-Directory-06a189e7-5ec6-4af2-94bf-a22ea225a7a9.

Ok, what about the Technical requirements?

Alright, to get to the nitty-gritty, here is a list of system and envirnment requirements that are more technically specific:

• The server used for the DirSync tool must be running one of the following operating systems:
• Windows Server 2008 R2 w/ SP1, x64 (Standard, Enterprise, or Datacenter)
• Windows Server 2012 (Standar or Datacenter Editions)
• Windows Server 2012 R2 (Standard or Datacenter Editions)
• The server must be joined to the Active Directory domain that is being synchronized
• The AD Forest Functional level must be at least Windows Server 2003
• The server must have Powershell installed (and enabled, if relevant)
• The server requires both .NET Framework 3.5 SP1 and .NET Framework 4.5.1
• The Domain Controllers in the environment must be running one of the following operating systems:
• Windows Server 2003 SP1 (32 or 64-bit)
• Windows Server 2008 (32 or 64-bit) (Standard or Enterprise Editions)
• Windows Server 2008 R2 (Standard or Enterprise Editions)
• Windows Server 2008 Datacenter Edition
• Windows Server 2008 R2 Datacenter Edition
• Windows Server 2012 (Standard or Datacenter Editions)

While the above information may seem drab, and may not pertain to too many newer environments, it can be very good information to know if you are planning on taking the Office 365 certification exams. Just sayin'...

There are other articles out there that go into much deeper dives on this tool, and I would of course encourage you to dig into them if you are moving past this introductory phase and getting ready to do so serious DirSync management. I would especially encourage you to get very familiar with the Powershell tools and cmdlets that are available for directory synchronization and remote Office 365 management, as provisioning automation will definitely rely on a solid understanding of Powershell.

For an overview on the various tools that can be used after your Hybrid deployment (or in-between phases of the deployment), check back with me on the third and final post of this series. We will be going down the list of some great connectivity testing and troubleshooting tools.

I would also like to apologize for the lack of a borderline-sarcastic meme in this post. I shall strive to not let that happen again!

Stay techy, my friends.

Office 365 Directory Synchronization Lab "Gotcha"

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!