Presented at SharePoint TechFest Dallas 2014. All rights reserved.

1. Directory Synchronization and Single Sign-On
in Office 365
Christopher Webb
MCM: SharePoint 2010
MCSM SharePoint
MCT

2. • Create your tenant
• http://office.microsoft.com/en-us/business/office-365-enterprise-e3-business-software-
FX103030346.aspx
• Activate Directory Synchronization - http://technet.microsoft.com/en-
us/library/jj151831
• Prepare Active Directory
• Activate Directory Sync feature on tenant admin site
• Add Domain
• DNS Verification
• Configure UPNs & Prep AD
• Download DirSync tool
• Account Permissions for synchronization
• Install DirSync
• Configure Single Sign-On - http://technet.microsoft.com/en-us/library/jj151786
• ADFS install
• ADFS Configuration
• ADFS Proxy Configuration
• Azure AD Module for PowerShell Install
• Connecting to O365 and converting to a federated domain
• Activate Users
• Internet Zones for SSO

3. Prepare Active Directory
• Deployment Readiness Tool - http://community.office365.com/en-us/forums/183/p/2285/8155.aspx or
https://portal.microsoftonline.com/tools
• The UPN domain suffix must be under the domain that you choose to set up for single sign-on.
• The domain you choose to federate must be registered as a public domain with a domain registrar or within
your own public DNS servers.
• To create UPNs, follow the instructions in the Active Directory topic Add User Principal Name Suffixes. Keep
in mind that UPNs that are used for single sign-on can only contain letters, numbers, periods, dashes, and
underscores.
• If your Active Directory domain name is not a public Internet domain (for example, it ends with a “.local”
suffix), you must set a UPN to have a domain suffix that is under a Internet domain name that can be
registered publically. We recommend that you use something familiar to your users, such as their email
domain.
• If you have already set up Active Directory synchronization, the user’s UPN may not match the user’s on-
premises UPN defined in Active Directory. To fix this, rename the user’s UPN using the Set-
MsolUserPrincipalName cmdlet in the Windows Azure Active Directory Module for Windows PowerShell.
• Be sure to set UPNs prior to DirSync, as this can be harder to fix than running this command. Including, sometimes, having
to delete users from cloud and re-setup the DirSync wizard.

4. Additional Considerations
• DirSync is designed for only 1 domain. FIM can handle multiforest
scenarios, but requires customization.
• DirSync requires Server 2003+ Forest functional level

5. Activate Directory Sync on Tenant Admin site
• Users and Groups
• Active Directory Synchronization
• Takes 24 hours, do it first
1 2
3
4

6. Adding domains for synchronization
1 2
3

7. DNS Verification
• Just a simple txt record in public DNS

8. Download & Install DirSync
• Download DirSync from tenant admin site
1 2
3

9. DirSync Machine notes
• http://technet.microsoft.com/en-us/library/jj151831#BKMK_ComputerRequirements
• The Windows Azure AD service supports synchronization of up to 50,000 objects
• It must run 64-bit Windows Server OS
• 64-bit edition of Server 2008 R2 SP1 Standard or Enterprise, or Server 2008 Datacenter or Server 2008 R2
Datacenter.
• 64-bit edition of Server 2012 Standard or Datacenter or 2012 R2 S/D.
• It must be joined to Active Directory.
• It cannot be a domain controller New version was released 11/2 that allows install on DC
http://social.technet.microsoft.com/wiki/contents/articles/18429.windows-azure-active-directory-sync-tool-version-
release-history.aspx
• It must run .NET Framework 3.5 SP1 and .NET Framework 4.0.
• You can only have one instance of the Directory Sync tool between an on-premises Active
Directory and an Office 365 tenant.
• Must be local admin to install

10. DirSync Install and Configuration
• Access account on AD side
• Must have Domain Administrator as well as Enterprise Administrator permissions for the
domain being synchronized
• Access account on O365 side
• Must be Global Administrator. Also will need to have a license if it’s a service account
• Follow the wizard, only has a couple steps
• If installing DirSync on ADFS box, MUST install DirSync first. It will not install after
ADFS is added.
• All documentation says to have dedicated DirSync box, but it is supported to use the same
machine
• Sync Passwords option allows you to sync the domain account passwords to O365
as well as the account. This is not required if you use ADFS, but if you are not
doing single sign-on, this helps to make things easier for your end users.

11. DirSync “Hybrid Mode” option
• Hybrid Mode is only for Exchange & Lync hybrid deployments, not
SharePoint. It allows DirSync to modify mailbox server attributes and
ProxyAddresses.
Object Type (objectClass) Property (LDAP attribute
name)
contact proxyAddresses
group proxyAddresses
inetOrgPerson proxyAddresses
user msExchArchiveStatus
msExchBlockedSendersHash
msExchSafeRecipientsHash
msExchSafeSendersHash
msExchUCVoiceMailSettings
proxyAddresses

12. Source of Authority
• When you create objects by using either the Windows PowerShell cmdlet or account
portal tools such as the Office 365 portal, you are mastering objects from within the
cloud. All subsequent changes to these objects are also made by using the same tools. In
this scenario, the source of authority is in the cloud. For more information about the
various tools that you can use to create and manage objects in Windows Azure AD, see
Administering your Windows Azure AD tenant.
• Alternatively, when you are running Active Directory synchronization, you are mastering
objects from within your on-premises Active Directory. Once Directory Synchronization
has been activated, and after the first sync cycle has been completed, the source of
authority is transferred from the cloud to the on-premises Active Directory. In this
scenario, users, contacts, and groups are created on-premises and then synchronized to
the cloud. All subsequent changes to the cloud objects (with the exception of licensing)
are mastered from the on-premises Active Directory tools. The corresponding cloud
objects are read-only. Administrators cannot edit cloud objects if the source of authority
is on-premises.
• *This means 1-way sync from AD to O365 (consider UPS can not sync updates back to AD, but Lync
still pulls from O365 if Lync is O365 license. On-Prem Lync is configurable to either)

13. Soft Matching
• New feature of DirSync
• Matches accounts that exist in O365 to accounts in AD based off of
PrimarySMTPAddress attribute
• In my experience, it will match based on UPN over the
PrimarySMTPAddress, but documentation does not say anything on
this.
• Details: http://support.microsoft.com/kb/2641663

14. Requirements for single sign-on
•Server 2003 R2, Server 2008, Server 2008 R2, or Server 2012 mixed or native mode functional
Forest and Domain levels.
•If you plan to use AD FS as your STS, you will need to do one of the following:
•Download, install and deploy AD FS 2.0 on a Server 2008 or Server 2008 R2 server.
•Install the AD FS role service on a Windows Server 2012 server.
•Also, if users will be connecting from outside your company’s network, you must deploy an AD FS 2.0 proxy.*
•Use the Windows Azure Active Directory Module for Windows PowerShell to establish a federated
trust between your on-premises STS and Windows Azure AD.
•Ports 80 & 443 must be open bi-directionally to the ADFS Proxy and outbound for ADFS Back End
Server
http://technet.microsoft.com/en-us/library/jj151786
http://technet.microsoft.com/en-us/library/jj205462

15. • Must have SAN (UCC) certificate or named certificate.
• Wildcards not supported
• ADFS service account needs to be a domain admin initially to configure the ADFS
container. Then can be rolled back to a standard domain user. Service account
must remain local admin on ADFS box, though.
• Public cert and full cert chain imported to the certificate store on ADFS and Proxy
• Internal DNS record for the ADFS service endpoint pointing to the ADFS server.
Proxy must be able to resolve the service endpoint to the ADFS server.
• Port 443 Open between Proxy and ADFS
• External DNS record for the ADFS endpoint that points to the public IP that is
NAT'd to the ADFS Proxy

16. • For a base installation platform, AD FS requires either Server 2008, Server
2008 R2, or Server 2012. AD FS has a separate install package for Server
2008, Server 2008 R2 operating systems (and it is commonly referred to as
AD FS 2.0) or it can be installed by adding the Federation Service server
role as part of the Server 2012 operating system.
• The ADFS Role included in 2008/2008R2 is v1.0. Do NOT use it. You cannot upgrade
the version without uninstalling, just download the package, or use the ADFS Role
built into 2012
• For Server 2012, Server Manager>Roles>Add Roles>ADFS
• Use defaults, don’t add the ADFS 1.1 features or the proxy service as 1.1 causes
issues with O365 and the proxy wont install on the same machine as the full ADFS
service.

17. • Add your certificates and the chains to the machine store on ADFS
box
• Make sure they show in IIS manager as selectable
• Load the AD FS Management console and start the configuration
wizard
• Create new Federation Service and a New Farm.
• Select the SSL certificate desired, a name for the service, and enter
Service account credentials.
• That’s it, no need to configure anything from the O365 tenant
• Test ADFS basic function via
https://<ADFS_FQDN>/adfs/ls/IdpInitiatedSignon.aspx

18. If only using for O365, this is what you want

19. • Install the certificate & chain on the
proxy server
• Proxy server should be on a non-
domain computer
• Same pre-reqs as ADFS service,
recommend sticking with 2012 again
• Proxy must resolve the token signing
address to the service, not the public
URL. (host-file or internal DNS)
• Install only the Proxy, not the 1.1
services or the ADFS service

20. • Assign certificate to default
site in IIS
• Run the configuration wizard
• It should AutoDetect the
service name from the
certificate
• Insert the ADFS service account
credentials when prompted
• Done

21. • Set up trust between ADFS and Azure AD -
http://technet.microsoft.com/en-us/library/jj205461
• Download Azure AD Module from Tenant Admin site and install on
any domain-joined machine where tenant will be managed from
• When converting domains to federated (final line in script below), this
is not your AD domain, but the public DNS Domain used as UPN suffix
and verified through DNS TXT records previously.
$cred=Get-Credential. ##When the cmdlet prompts you for credentials, type your cloud service administrator account credentials.
Connect-MsolService –Credential $cred. ##This cmdlet connects you to Windows Azure AD. Creating a context that connects you to Windows Azure AD is required before running any of the additional cmdlets installed by the tool.
Set-MsolAdfscontext -Computer <AD FS primary server> ##, where <AD FS primary server> is the internal FQDN name of the primary AD FS server. This cmdlet creates a context that connects you to AD FS.
Convert-MsolDomainToFederated –DomainName <domain> ##, where <domain> is the domain to be converted. This cmdlet changes the domain from standard authentication to single sign-on.

23. • You need to include only the URL of the service endpoint in the local
intranet zone.
• https://<tenant and/or tenant-my>.sharepoint.com should probably still be
included for other features of SharePoint, but not required for SSO

24. Christopher Webb
MCM: SharePoint 2010
MCSM SharePoint
Senior Engineer
Planet Technologies
@chriswebb18
http://www.ChristopherMichaelWebb.com