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.
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:
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:
gryphon.wonderland.lab
server, with a public name adfs1.absoluteuc.biz
. It is exposed by using IIS ARR (dormhouse.wonderland.lab
).As soon as the setup is complete, you will have the icon shown in the following screenshot:
$cred=Get-Credential
(you will be prompted for the username and password of an Office 365 administrator)Connect-MsolService –Credential $cred
Set-MsolAdfscontext -Computer "internal FQDN of your AD FS server"
. For example, we have Set-MsolAdfscontext –Computer Gryphon.wonderland.lab
Add-MsolDomainToFederated –DomainName "FQDN of our public domain"
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 SupportMultipleDomain
switch. In our scenario, the cmdlet was Convert-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).
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:
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.