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