Directory Synchronization and Single Sign-On in Office 365

Christopher Webb

MCM: SharePoint 2010MCSM SharePointMCT

• 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

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.

Additional Considerations

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

Activate Directory Sync on Tenant Admin site

• Users and Groups• Active Directory Synchronization

• Takes 24 hours, do it first

1 2

34

Adding domains for synchronization

1 2

3

DNS Verification

• Just a simple txt record in public DNS

Download & Install DirSync

• Download DirSync from tenant admin site

1 2

3

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

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.

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 proxyAddressesgroup proxyAddressesinetOrgPerson proxyAddressesuser msExchArchiveStatus

msExchBlockedSendersHashmsExchSafeRecipientsHashmsExchSafeSendersHashmsExchUCVoiceMailSettingsproxyAddresses

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)

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

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/jj151786http://technet.microsoft.com/en-us/library/jj205462

More not-so-well documented ADFS notes• 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

ADFS Install

• 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.

ADFS Configuration

• 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

If only using for O365, this is what you want

Configuring ADFS Proxy (For 2012 R2 == WAP• 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

Configuring ADFS Proxy cont.

• 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

Installing Azure AD Module & Federating Domain

• 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.

Activate Users

Internet Zones for SSO

• 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

Q & A

Christopher WebbMCM: SharePoint 2010MCSM SharePointSenior EngineerPlanet Technologies

@chriswebb18http://www.ChristopherMichaelWebb.com