Follow me on Twitter @AntonioMaio2

Monday, October 20, 2014

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 1st 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

No comments:

Post a Comment