Identity Synchronization between Active Directory and SharePoint Online - Part 2

This article is the second in a series on how to configure identity synchronization between on premise Active Directory and SharePoint Online within Office 365.

Part 1

In the previous post in this series we started this topic by covering the following:

-          Introducing the concepts of Identity Synchronization and Federation

-          How to synchronize a .local domain

-          How to prepare Active Directory for Directory Synchronization

                                                                                           

You can access part 1 in this series here: http://sharepoint.protiviti.com/blog/Lists/Posts/Post.aspx?ID=142.

 

We’ll continue here with the step by step process of setting up Directory Synchronization between your on premise Active Directory domain and your Office 365 tenant.

Setup Your Domain in Office 365

The next step in the process of setting up directory synchronization is registering your domain in your Office 365 tenant.  You do this by logging in to your Office 365 tenant as a tenant administrator and clicking DOMAINS in the left hand menu.

You’ll see your Office 365 domain listed (*.onmicrosoft.com), but you need to add your on premise domain to this list and Microsoft needs to verify that you own that domain.  This must be a publicly routable internet domain and it must be the same domain that you setup as the Alternate UPN Suffix in the 1^st post in this series.

 

Click +Add domain in center of the window.   

There are 3 steps in the process of adding a domain:

Step 1 here, specifying the domain name and confirming ownership is the most critical step to Directory Synchronization. 

 

-          Click Start Step 1 and specify the domain name.  In my case I used maiolabs.com.  Click Next.

-          Now you’ll need to confirm that you own this domain.  This can be done a couple of different ways.

If your domain is managed at GoDaddy, Office 365 will allow you to confirm ownership simply by performing a secure login to your GoDaddy account that you use to manage this domain.  To do this, click Confirm Ownership on the screen above.  A window will appear asking you to sign into your GoDaddy account.

If you use this option to confirm ownership of your GoDaddy domain, the process will complete immediately and you can continue to Step 2 and Step 3 with adding a domain. 

Alternatively, if you manage your domain elsewhere, you can follow the manual steps required to verify ownership.  Simply click Follow the manual steps in the window above.

The manual steps require you to add a particular record to your DNS configuration at your DNS hosting provider.  I typically add the TXT record with the code specifically provided by Microsoft here because it’s quite simple to do.  Once added to the DNS record, you’ll have to come back here and click Done, Verify Now.  This typically does not work immediately after adding the DNS record.  You usually have to wait several hours for the record to be updated and accessible.  You can return to DOMAINS in your Office 365 tenant later and try to verify again. 

Ensure that you spell the code correctly when you add it.  It can take up to 72 hours for the updated DNS record to be accessible by Office 365 to verify ownership, and you don’t want to have a typo require you to have to wait excessively. 

Once the domain ownership is verified, you must proceed through Step 2 and Step 3 in the process of adding a domain, however each step allows you to skip that step once you’re into it.  Once Step 3 is complete, your publicly routable internet domain will now appear in your domain list with the status Setup complete.

 

Activate Directory Synchronization in Office 365

The step in this process is to activate directory synchronization in your Office 365 tenant.  You do this by clicking USERS in the menu on the left and then clicking Set up beside Active Directory synchronization.

Clicking Set up will bring up the following screen.  Click the Activate button.

This will bring up a confirmation window which contains a very important point about this process.

The important point here is that once identities and groups are synchronized to Office 365 from an on premise AD domain, those objects can only be edited within the on premise AD domain.  Click Activate here to continue.

Installing and Configuring the Directory Synchronization Server On Premise

Now it’s time to actually install and configure the Directory Synchronization server - this server application is also called DirSync and the install file is DirSync.exe.  You can download DirSync.exe by clicking USERS in the left hand menu, then clicking Set up beside Active Directory synchronization as shown above, and then clicking the Download button.

DirSync must be installed on a domain joined server.  In its earlier releases DirSync had to be installed on the domain controller itself, but now it can be installed on its own dedicated server, which is recommended.   Ensure that you have the following prerequisites in place for the Directory Synchronization Server before proceeding with the install:

-          Domain joined to the Active Directory forest you will be synchronizing.

-          64 bit Windows Server Operating System (2008 with SP1 or later, 2008 R2 with SP1 or later, 2012, 2012 R2, all either standard, enterprise or data center)

-          .NET 3.5.1 and .NET 4.0 Frameworks must be installed

-          PowerShell must be enabled in Windows Server 2008

Other notes:

-          Access to the computer running DirSync should be limited to users who have access access and permissions to make changes to the Active Directory domain controllers.

-          Ensure that Microsoft Online Sign-In Assistance is not already installed.  If it is, uninstall it.  The DirSync installation will try to install this and the entire installation will fail if it is already installed.

-          Only 1 instance of DirSync can be installed within an on premise AD forest

-          DirSync will synchronize all domains within the AD forest

To install and run DirSync, you must have the following permissions:

-          Local administrator permissions to the computer running the Directory Synchronization server

-          Administrator permission to the local Active Directory forest (part of the Enterprise Administrators group)

-          A service administrator in the Office 365 tenant

During the DirSync install process, you’ll need to provide the username and password for the on premise Active Directory administrative account and the service administrator for Office 365.  When installing DirSync, the Configuration Wizard will create a service account that is used to read from the local Active Directory and write to Azure AD. The wizard creates this account using both your local Active Directory admin permissions and your cloud admin permissions, which must be provided during the installation process.

You can deploy and host DirSync within an Azure VM as long as you have network connectivity  between your on-premises network and your Azure Virtual Network.  However, that's beyond the scope of this article.

Installing DirSync.EXE

Once you’ve downloaded DirSync.exe to the Directory Synchronization server, start the installation process:

-          Welcome screen - click Next

-          Accept the EULA and click Next

-          Select the installation folder and click Next

-          The installation process takes about 10 minutes

-          When the installation process is complete, ensure the Start Configuration Wizard now check box is on and click Finish

DirSync Configuration Wizard

Once the configuration wizard starts, you’ll be asked to specify the Azure Active Directory Administrator credentials.  Enter the username and password of the service administrator account for Office 365 and click Next.

Click Next.  You’ll then be asked to specify the Active Directory Enterprise Administrator credentials.  Enter the username and password for an administrative user that is part of the Enterprise Administrators group of the local Active Directory and click Next.

-          You’ll then be asked if you would like to Enable Hybrid Deployment.  This feature allows Office 365 (Azure Active Directory) to write changes to identities back into the on premise Active Directory.  An example of this is if a user changes their password – with a Hybrid Deployment, this change will be synchronized back to the on premise AD.  Select Enable Hybrid Deployment and click Next.

-          You’ll then be asked to Enable Password Sync.  This feature allows password changes within the on premise AD to be synchronized to Office 365.  Although this is not true single sign on, it does make the end user experience much better because they use the same username and password for both on premise resources and Office 365, even as passwords change.

Once the configuration process is complete, you’ll be asked to run your 1^st directory Synchronization.

Click Finish.  The directory synchronization process will begin immediately.

If you return to Office 365, click USERS in the left hand menu and then Click Active Users, after a few minutes you’ll see user accounts and groups from the on premise AD appearing in your Office 365 tenant.

My on premise user accounts here are obviously dwarfs.  J  You’ll notice that user accounts that are synchronized from on premise AD have a status of Synched with Active Directory and, as mentioned earlier, cannot be edited in Office 365.

In order to login to Office 365 and SharePoint Online with these new users, you’ll still need to assign an Office 365 license to each user individually here.  This directory synchronization process will now occur automatically every 3 hours.

Once licenses are assigned, user accounts that were synched from on premise AD can now login to Office 365 using their same on premise username and password!

 

Identity Synchronization between Active Directory and SharePoint Online - Part 1

Introduction
Many organizations are in the process of moving internal services like SharePoint to cloud service providers like Office 365 or Azure.  As part of this trend, they’re considering whether they can move all currently internal systems to the cloud, and many are finding that they cannot.  This blog post is the first in a series that will walk through the process step-by-step of configuring Directory Synchronization and Single Sign On between an on premise Active Directory and SharePoint Online
 

Often, the systems which manage an organization’s user accounts or identities are kept on premise, while other services like SharePoint are moved to the cloud.  These are systems like Active Directory or other LDAP directories, and keeping them on premise can be due to several reasons:

·         Identities represent sensitive or classified individuals and must remain on premise for security reasons (primarily in the military or intelligence community)

·         Identities represent the general public and once again security or privacy regulatory standards require more control (health care, pensions, etc.)

·         An organization wants to maintain ultimate control over their employee identities

·         Identities are currently stored in non-Active Directory LDAP systems which are working, and there is no strong reason for changing those systems or moving them to the cloud

·         Other proprietary or legacy enterprise systems which must remain on premise rely on a close connection to the identity system

As a result, Microsoft has provided organizations with the option of leaving Active Directory running on premise and synchronizing user accounts to the Office 365 cloud environments.  This type of deployment constitutes a hybrid cloud deployment, where part of the organization’s infrastructure remains on premise while services in the cloud can use those identities (like SharePoint, Exchange or Lync). 

Concepts
The following concepts and terms will be used throughout this series:

·         Hybrid Deployment

A hybrid deployment of SharePoint involves having some components of the SharePoint farm on premise, and some components sitting in a cloud service provider, like Office 365 or Azure.

·         Identity Synchronization

Identity Synchronization means that the on premise Active Directory remains the master identity system, where all updates to identities are made and those identities are copied to the Azure Active Directory system and kept up to date through an automatic synchronization process.

·         Single Sign On

Single sign on is the process of controlling access to multiple related, but independent systems such that a user logs in once and gains access to all systems without being prompted to log in again for each system.

·         Identity Federation

Identity federation is the process of linking a user’s identity and attributes stored across multiple identity management systems.  With identity federation, a user’s identity is trusted across multiple systems or even across organizations when that user authenticates to a particular system.

Preparing Active Directory

In order to successfully synchronize identities between on premise Active Directory and SharePoint Online, the Active Directory must be correctly configured.  This is a critical step in this process which must not be missed.  This process begins by verifying the configuration of Active Directory and correcting any issues that may be found.

In order to perform the steps described in this article, you will require administrative permissions on Active Directory.

Supported Active Directory Versions and Limits

The directory synchronization process is only supported in Active Directory domain controllers on Windows Server 2003 (forest functional mode) or higher.  This article assumes Windows Server 2012 R2.

Office 365 has a default object limit of 50,000 mail-enabled objects by default – these are users, mail-enabled contacts and groups. This limit determines how many objects you can create in your Office 365 tenant, regardless of if they are created manually, through the directory synchronization process or through some API.  When you verify your first domain as part of setting up directory synchronization (a process I’ll describe in a later post in this series) this object limit is automatically increased to 300,000 objects.

Working with an Internal or .local Domain – Setting up the Alternate UPN Suffix

An internal corporate AD domain will of course have a domain name, typically something that looks like ABCCORP, so that a user would login with the username ABCCORP\John.Smith.  A domain name could also look something like abccorp.local and the user would then login to the internal domain with a username that looks something like abccorp.local\John.Smith. 

The domain name used to configure Office 365 must be a publically-routable internet domain name, and Microsoft will verify that you own that domain as part of the synchronization process (steps for that are in a future post in this series).  If internally you are using a .local domain name or one that is not available on the internet, as many organizations do, how do you allow Microsoft to verify that you own the domain?  As well, how do you associate a user’s corporate identity (something like abccorp.local\John.Smith) to the Office 365 domain credentials, which again must be associated with a publically routable internet domain?

This is solved with the addition of an Alternate UPN Suffix. 

·         The UPN is the userPrincipleName attribute that is part of every user’s account in AD and it typically looks like an email address or logon username with a fully qualified domain name, for example <user logon name>@<domain name>.com.  Unless you’re already using it for some specific purpose, the userPrincipleName attribute is typically blank for every user. UPNs that are used for single sign-on as we are doing here can contain letters, numbers, periods, dashes, and underscores.  They may not contain other characters.

·         A UPN suffix is the part of a UPN to the right of the @ character.

In order for a user’s internal corporate credentials to be correctly associated with the Office 365 domain it is necessary to add an Alternative UPN Suffix to the on premise AD domain.  This links the user’s internal credentials with the domain name used to setup the Office 365 domain.

An Alternate UPN Suffix is added by performing the following steps:

·         Run the “Active Directory Domains and Trusts” management console by typing “domain.msc” at the Start Menu.

·         Right click on the “Active Directory Domains and Trusts” in the left hand pane and select “Properties”.

·         In the UPN Suffix dialog which appears enter the Alternate UPN Suffix and click Add.

·         Click OK to exit the dialog.

You will now be able to use the Alternate UPN Suffix when you edit the UPN for each user (described further below).

Active Directory Cleanup

Ensure that each user has a valid and unique email address. Remove any duplicates in the proxyAddresses attribute field.  Ensure that each user has a valid and unique userPrincipleName.  Remove any duplicates of this field as well.

Ensure that each user has the following attributes populated:

·         First Name

·         Last Name

·         Display Name

The following attributes require specific configuration and it’s important to ensure that no special characters are used:

·         userPrincipleName

§  The UPN for each user must be globally unique across the entire directory forest

§  The domain portion (after the @ symbol) must be a publically routable internet domain (you cannot use .local or internal domains)

§  Must be in the Internet-style logon format where the user name is followed by the symbol @ and a domain name, for example user@contoso.com

§  Maximum 113 characters (64 allowed before @ symbol and 48 after)

§  Special characters include: \ % & * + / = ? ‘ { } | < > ( ) ; : , [ ] “

§  @ symbol is required and cannot be 1^st character

§  Username portion (before @ symbol) cannot contain spaces, nor can it end in period, ampersand, space or @ symbol

§  Unicode characters will be converted to _

·         sAMAccountName

§  This value must be globally unique across the entire directory forest

§  Maximum 19 characters

§  Special characters include: [ \ “ | , / : < > + = ; ? * ]

§  If sAMAccountName is invalid but the userPrincipleName is valid, then the account is synchronized to Office 365 and the userPrincipleName is used

§  If both sAMAccountName and userPrincipleName are invalid, then the userPrincipleName in the on premise AD must be modified

·         proxyAddresses

§  This value must be globally unique across the entire directory forest

§  Maximum 256 characters

§  Special characters include: \ % & * + / = ? ‘ { } | < > ( ) ; : , [ ] “

§  Must not contain a space

§  Must comply with email messaging standards

·         givenName

§  If this value exists for a user’s account in AD it will be synchronized to Office 365, but Office 365 does not use it

§  Maximum 63 characters

§  Special characters include: ? @ \ +

·         sn(surname)

§  this value exists for a user’s account in AD it will be synchronized to Office 365, but Office 365 does not use it

§  Maximum 63 characters

§  Special characters include: ? @ \ +

·         displayName

§  If this value exists for a user’s account in AD then it must contain a value and it will be synchronized to Office 365

§  Maximum 255 characters

§  Special characters include: ? @ \ +

·         mailNickname (Exchange Alias)

§  This value must be globally unique across the entire directory forest

§  Maximum 63 characters

§  Special characters include: [ \ ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ‘ ; : , ] “ @

§  The value must not contain a space and it cannot begin or end with a period

·         mail

§  If this value exists for a user’s account in AD it will be synchronized to Office 365, but Office 365 does not use it

§  If this value exists for a user’s account in AD it must be globally unique across the entire directory forest

§  Maximum 255 characters

§  Special characters include: [ \ ! # $ % & * + / = ? ^ ` { } ]

Note:  Most of the attributes which list that they must be globally unique across the entire directory forest relate to email addresses which must be globally unique across the world anyway, so these typically are not an issue.

Focusing on userPrincipleName (UPN) and proxyAddresses

Out of all the attributes listed above the most important attributes to this process are the userPrincipleName (UPN) and the proxyAddresses attributes.  The others listed typically are already setup fine from an AD point of view.  Unless you are already using these attributes for some other specific purpose, they will likely be blank when you start this process.

Once the Alternate UPN Suffix is configured, as mentioned above, then configuring the UPN is simply a matter of following these steps:

·         Run the “Active Directory Users and Computers” management console by typing “dsa.msc” at the Start Menu.

·         Ensure that you’ve turned on Advanced Features by clicking the View menu and selecting the “Advanced Features” menu.

·         In order to set the UPN for each user, you will need to select the Alternate UPN Suffix (configured earlier) for each user individually.  To do this, find the first user account you wish to edit and right click on the user and select “Properties”.

·         In the Properties window select the “Account” tab.

·         Click the dropdown which appears beside the ‘User logon name” field and select the Alternate UPN Suffix that you configured earlier (in this case its “@demo.com”).

·         Click Apply.

·         After clicking Apply, you can verify that the userPrincipleName has been set correctly by switching to the Attribute Editor tab (note this tab only appears if you have enabled Advanced Features as mentioned above) and scrolling down to the userPrincipleName field.  It is now set to <user logon name>@<alternate domain suffix>.

To configure the proxyAddresses attribute perform following these steps:

·         While in the Attribute Editor tab for the user account you were just editing the UPN for, scroll down to the proxyAddresses attribute.

·         Double click on the proxyAddresses attribute and enter in the following (ensuring that there are no spaces):   SMTP:<userPrincipleName>.   In this case its SMTP:sally@demo.com.

·         Click Add, then click OK and then click Apply.

Note: this attribute is a multi-value attribute so there may already be some values listed.  It’s important as part of this process to ensure that there are no duplicate values listed.

You will need to follow this process for every user account that will be required to login to Office 365.  Sometimes this involves all accounts in AD (minus disabled accounts), but more often it involves a subset of on premise AD accounts.  If you have a large number of user accounts to modify in Active Directory then I encourage you to explore using the PowerShell AD Provider to modify the attributes mentioned here in bulk.  There is a great article available on how to do this found here:  http://blogs.technet.com/b/heyscriptingguy/archive/2013/03/21/use-the-powershell-ad-provider-to-modify-user-attributes.aspx.

By default, the Directory Synchronization process will occur for all user and group objects in the Active Directory forest, including any child domains and disabled user accounts.  It will also synchronize user accounts for which the UPN and proxyAddresses attributes have not been set correctly, but these users will not be able to login.  Be sure to follow the cleanup and preparatory steps here for all users in Active Directory which will be assigned an Office 365 or SharePoint Online license.

Final Thoughts

It’s important to note that setting up Directory Synchronization is a multi-step process, and preparing Active Directory for the synchronization here is a critical step.  If Active Directory is not prepared and cleaned up appropriately prior to performing directory synchronization it can cause very negative impacts that can take days to recover from.  In the next article in this series I’ll cover the following topics:

·         Preparing and Verifying the Domain DNS

·         Activating Directory Synchronization

·         Installing and Configuring the Directory Synchronization Server

·         First Directory Synchronization

 
   -Antonio