Companies with an on-premises Directory Services deployment often require using the same account information to access both on-premises and Office 365 resources. We have two solutions available to achieve the previously mentioned result.
The first one is named same sign on and it is based on DirSync. It enables the user to log on with the same username and password (if we have also enabled password synchronization) on the legacy data centre and in the cloud. It is easier to deploy this solution because AD FS is not required. The downside is that the user will be required to enter their credentials more than once every time they move from on-premises to the cloud.
Note
Sometimes, the password synchronization to the cloud creates security-related concerns. Quoting the TechNet (Implement Password Synchronization at http://technet.microsoft.com/en-us/library/dn246918.aspx):
"When synchronizing passwords using the password sync feature, the plain text version of a user's password is (never) exposed. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer's on-premises environment."
The second solution, Single Sign On, requires both DirSync and AD FS, but enables the user to authenticate once on our domain and then access Office 365 resources with no additional verification required. In the schema shown in the following screenshot, we can see the logic used in the Same Sign On and in the Single Sign On scenarios:
We will see the configuration required to use Single Sign On. Regarding the AD FS part of the configuration, the steps required to configure it are the same as we saw previously. Inside your Office 365 subscription portal, there is a Set up and manage single sign-on page that is a high-level overview of the required steps. You are able to find it by selecting Users and Groups | Active users and opening the Manage shortcut for the Single sign-on:
The Set up page, however, is only a quick overview, so here we will try to add the missing information.
DirSync installation has some software-specific prerequirements:
- The Windows Server operating system (Windows Server 2008, 2008 R2, 2012, or 2012 R2)
- A server joined to the Active Directory forest that we are going to synchronize
- Microsoft .NET Framework 3.5 SP1 and the Microsoft .NET Framework 4.5.1
- It must run (at least) Windows PowerShell 2.0
If we are going to install DirSync on a domain-joined Windows Server 2012 R2, the only requirement missing is the .NET Framework 3.5, which we are able to add as a Windows feature from Server Manager.
Usually, the AD DS domain and the public domain have different names. To make it easier for users to use Single Sign On, with a username such as user@publicdomain (in our scenario, for example, [email protected]), we have to enable User Principal Name (UPN). The feature is available inside Active Directory Domains and Trusts, and can be accessed by right-clicking on the root and selecting properties. This screen is shown in the following screenshot:
- Configure an AD FS server accessible from the Internet, with an FQDN published on the public DNS servers and with an SSL certificate issued from a well-known public certificate authority. It is required to create a secure communication channel between the on-premises deployment and Office 365. We have used the
gryphon.wonderland.labserver, with a public nameadfs1.absoluteuc.biz. It is exposed by using IIS ARR (dormhouse.wonderland.lab). - On a server with an Internet connection available, we have to install the following two different components:
- Windows Azure AD Module for Windows PowerShell
- The Directory Synchronization tool (DirSync)
- To install Windows Azure AD Module, the Microsoft Online Services Sign-In Assistant for IT Professionals RTW (http://www.microsoft.com/en-us/download/details.aspx?id=28177) is required, so we have to install it.
- The next action required to be performed is the installation of the Windows Azure AD Module that is available on Technet at http://go.microsoft.com/fwlink/p/?linkid=236297 or in the previously mentioned Office 365 page.
As soon as the setup is complete, you will have the icon shown in the following screenshot:
- It is required to activate the Active Directory synchronization inside Office 365. This operation is available from the dashboard or inside the Single sign-on setup page introduced in the Getting ready section.
- The setup process for DirSync requires administrative credentials on the server where we are performing the installation, on the local Active Directory, and in our Microsoft Cloud service.
- Now, we are able to install DirSync. At the end of the installation, we will see a lot of additional software installed, as you can see in the following screenshot. This are required to make DirSync work.
- Back to the users and groups, Active users we should see our domain users in the list, with the Synced with Active Directory text on the right, as we can see in the next screenshot:
- What we have done until now is enough to have Same Sign On enabled. However, we are going to do more and enable Single Sign On.
- If we have enabled UPNs, we are able to modify user logon names so that they include our domain public name. We can see it in the drop-down menu shown in the following screenshot:
- Launch the Windows Azure AD Module for Windows PowerShell and use the following statements to register the Office 365 credentials and enable communication between your AD FS and the cloud:
$cred=Get-Credential(you will be prompted for the username and password of an Office 365 administrator)Connect-MsolService –Credential $credSet-MsolAdfscontext -Computer "internal FQDN of your AD FS server". For example, we haveSet-MsolAdfscontext –Computer Gryphon.wonderland.labAdd-MsolDomainToFederated –DomainName "FQDN of our public domain"
Note
We need to use the convert option for domains that are already defined inside Office 365. Also, if we are going to use multiple domains, we need to add the
SupportMultipleDomainswitch. In our scenario, the cmdlet wasConvert-MsolDomainToFederated –DomainName ucconfidential.onmicrosoft.com –SupportMultipleDomain.
This configuration unifies the account log on. If a user logs on to a domain-joined workstation and tries to log on to Office 365, they will be redirected to our company's authentication page just after typing their username. Then, they will be able to authenticate with the domain user and password, as shown in the following screenshot:
Starting with the June 2013 updates, it is possible to install the Windows Azure Active Directory (WAAD) Directory Sync (DirSync) tool on a domain controller. This solution makes sense for companies that want to have as few servers running as possible and prefer not to dedicate a machine to DirSync. However, it is also a solution that Microsoft recommends only in a development environment. The DirSync tool uses a scaled-down version of the Microsoft Forefront Identity Management (FIM) server and also installs other components such as SQL Express. The overhead associated with the previously mentioned solution is something that we have to consider on a Domain Controller (we should also consider whether we can change some configuration on DirSync, such as the interval between synchronizations, to reduce the overhead).
Note
In some scenarios, such as companies with a limited number of available servers, it could also be interesting to install AD FS and DirSync on the same server. There is no rule that prohibits such a solution, but we have to consider that the deployment of AD FS (especially if we aim to have a highly available situation) mixed with DirSync increases the complexity of the configuration.
A useful tool to debug Single Sign On is the Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/) Office 365 and Office 365 Single Sign-On Test, as shown in the following screenshot:
Note
In Chapter 7, Lync 2013 in a Resource Forest, we will also talk about Azure Active Directory Synchronization Services (AAD Sync). This is a recently released solution that could (also) replace DirSync as an account synchronization tool.