User identity, Account Provisioning, Directory Synchronization,...

User identity, Account Provisioning, Directory Synchronization, Federation

Workshop Purpose and Objectives

2

Workshop Purpose

• Plan for user identity and provisioning, including discussion of Active Directory Domain Services (AD DS) cleanup, *configuration of identity federations, and planning for the installation and configuration of the Microsoft Online Services Directory Synchronization (DirSync) tool

• Establish approach for adding and provisioning

users for the service

• Understand and plan for Office 365 licensing

activation

• Understand and plan for steps required to enable

Directory Synchronization

• *Outline identity federation requirements and

provide approach

Objectives

*Denotes optional Service Enhancement features

Common Identity Platform

3

Directory

store

Authentication

platform

Windows Azure

Active Directory

Windows Azure Active Directory (WAAD or Azure AD) is the underlying identity platform for various Organizational cloud services

4

User Identity and Account Provisioning Planning

Provision Users and License Activation

Review options to provision and license users

Workshop Topics

Active Directory Synchronization

Review requirements and drive planning considerations to implement synchronization between on-premises AD DS and the Office 365 environment

*Identity Federation Review requirements to support single sign-on


Current Provisioning and Deprovisioning process

Review current identity lifecycle tools and process

5

Current Provisioning and Deprovisioning Process

• HR System • Manual process or automated

through feed • What is the most common login

identity (AD, LDAP, etc) • Employee creation • Mailbox creation • Groups • Contractors • Terminated • Mailbox retention

Provisioning Deprovisioning

Workshop participants and outcomes

Participants Technical Leads (AD DS and Provisioning)

Outcome Draft user provisioning and licensing approach

6


Differences between account provisioning and licensing

Provisioning Options

License Activation


Participants Technical Leads (AD DS and Provisioning)

Outcome Draft user provisioning and licensing approach

Provisioning Options

7

Option Considerations

Directory

Synchronization

Synchronizes users from the customer’s AD DS infrastructure to the

Microsoft Online Services environment

Synchronizes security and mail-enabled groups

*Allows for onboarding and offboarding of users when Exchange hybrid

deployment is configured

*Provides the infrastructure necessary to support single sign-on

Windows

PowerShell

Allows mass import of users via Windows PowerShell command line

interface scripting

Does not allow for single sign-on

Bulk Import Allows for an import of a comma-separated values (CSV) file to mass

populate users

Does not allow for single sign-on

Microsoft Online

Services Portal

Provides a simple web interface to add and modify user accounts

Cannot be used to modify users if Directory Synchronization is enabled

*In a federation scenario that enables single sign-on, Directory Synchronization is the only

provisioning option

User identities can be mastered on-premises

Existing end-user provisioning capabilities that integrate with on-premises AD DS can be used with

Office 365


Office 365 Management cmdlets

8

Management

categories

Description

Manage users Used to perform a variety of tasks related to managing users,

passwords, and user principal names (UPN).

Manage group and role

memberships

Used to perform a variety of tasks related to group and role

membership, including adding a user to a role or group,

creating groups, and removing groups.

Manage service principals Used to perform a variety of tasks related to service principals.

Manage domains Used to perform a variety of domain management tasks,

including creating or removing a domain.

*Manage single-sign on Used to perform tasks related to single sign-on, such as

adding a new single sign-on domain to Office 365.

Manage subscriptions and

licenses

Used to manage subscriptions, accounts, and licenses.

Manage company

information and service

Used to perform tasks related to managing your company’s

information and connecting to Office 365 for enterprises. There

are also cmdlets for tasks performed by partner companies.

Manage Microsoft

Exchange Online

Used to perform management tasks that are not available nor

practical in the Exchange Administration Console (EAC).


http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh125002.aspx
















Provisioning Gotchas

Provisioning requires several steps in order to get a new user up and running in Office 365


Participants Technical Leads (AD DS and Security)

Outcome Document plan to support single-sign and overall AD FS implementation

approach.

DirSync must sync the objects to Office 365 before a

license can be assigned

9

Users should only be licensed for what customer is

ready to support. SharePoint, Lync, OneDrive, Office

Pro Plus may not be ready for consumption

EAS, POP3, IMAP are all on by default when a mailbox

is provisioned. Powershell would need to be run to

turn these off as the mailbox is created

Microsoft has some sample scripts that can help

provision users based on group membership

10


Review requirements to drive planning considerations to implement synchronization between the on-premises AD DS and the Office 365 environment

Workshop participants and outcomes Participants Technical Leads (AD DS and Network)

Outcome Document plan to modify Domain Controller infrastructure to support Office

365 requirements, implement Direct Synchronization appliance, and clean up

required AD DS attributes

Directory

Synchronization

Overview

Source of

Authority

Two-way

Synchronization

(write-back)

AD DS

Preparation

*Multi-forest

Deployment

Considerations


Password Sync

Directory Synchronization Overview

11

Review planning considerations for installation of the Directory Synchronization tool

Follow-up actions and additional information from prior assessments

Service Enablement Plan Review AD DS object count to be synchronized, and draft Directory

Synchronization installation plan accordingly

Considerations [List specific issues uncovered or context from prior assessments]

Required permissions for installation – Enterprise

Administrator rights during the installation process. Non-

privileged AD DS account is required post-installation (this

account is automatically created during installation).

AD DS object considerations – If a domain is verified on the

tenant, by default, it will be possible to synchronize up to

300,000 AD objects (if no domain validated, no more than

50,000 objects). To sync more objects, the Office 365 support

team will need to be contacted to open a service request with

the number of objects to synchronize.

Capacity planning – For object count greater than 50,000,

Microsoft SQL Server 2008 R2 or higher is required and can

be installed on the same server as Dirsync.

Directory Synchronization Hardware Requirements

12

Active Directory

Objects

CPU Memory Hard Disk Full SQL

Required?

Less than 10,000 1.6 GHz 4 GB 70 GB No

10,000 – 50,000 1.6 GHz 4 GB 70 GB No

50,000 – 100,000 1.6 GHz 16 GB 100 GB Yes

100,000 – 300,000 1.6 GHz 16 GB 300 GB Yes

300,000 – 600,000 1.6 GHz 32 GB 450 GB Yes

More than 600,000 1.6 GHz 32 GB 500 GB Yes

This table includes SQL sizing if SQL is installed on same box than Dirsync (50.000 AD objects and

more)

If SQL is deployed on a dedicated server, use these numbers for SQL and size an additional server

for DirSync with 2 cores, 4GB RAM and 72 GB disk

Source of Authority

13

Office 365 requires a single source of authority for every object. Three scenarios exist for where source of authority is changed for an object.

Activate: When you activate Directory Synchronization and then

synchronize directories, the source of authority for any cloud object

that is matched to an on-premises object is transferred from the cloud

to your on-premises AD DS.

Deactivate: When you deactivate Directory Synchronization, the

source of authority is transferred from the on-premises AD DS to the

cloud.

Reactivate: When you reactivate Directory Synchronization, the

source of authority is transferred from the cloud back to your on-

premises AD DS (where it previously resided).


Service Enablement Plan Review concept of "source of authority" and the three scenarios it

applies to (active, deactivate, reactivate). Review steps to ensure

minimal directory data loss in the reactivate scenario by reviewing

the globally unique identifier (GUID) and Simple Mail Transfer

Protocol (SMTP) match logic. (online resource)


http://community.office365.com/en-us/w/sso/directory-synchronization-and-source-of-authority.aspx

Active Directory Preparation

14

Review tasks needed to address remediation efforts. Outline plan for addressing all directory object preparation activities.

Verify each user planning to use Office 365 has a valid and unique

email address

Remove duplicate values in the ProxyAddress attribute field and

UserPrincipalName that exists in the forest

Populate the following username attributes:

First name

Last name

Display name

Directory object preparation

Use IDFix to remediate AD


Service Enablement

Plan

Review the state of the on-premises AD DS from previous assessments.

Document remediation steps prior to first synchronization.


http://www.microsoft.com/en-us/download/details.aspx?id=36832

Directory Object Preparation Guidance

15

sAMAccountName

giveName

sn (surname)

mailNickname

mail

displayName

proxyAddresses

userPrincipalName targetAddress

Maximum number of characters: 20

Invalid characters: !#\$%\^&\{\}\\{`~"",\\/\[\]:@<>\+=;\?\*

Note: If a user has an invalid sAMAccountName but a

valid userPrincipalName, the user account is created in

Office 365.

Note: If both the sAMAccountName and

userPrincipalName are invalid, the on-premises AD DS

userPrincipalName must be updated.

Maximum number of

characters: 64

Questionable

characters: ?@\+

Maximum number of

characters: 256

Questionable characters:

?@\+

Maximum number of

characters: 64

Invalid characters:

""\\\[\]:><; and space Maximum number of characters: 256

Invalid characters: [! #$ %&*+ / = ? ^ ` { }]

The mail attribute cannot contain any duplicate values.

Note: If there are duplicate values, the first user with the

value is synchronized. Subsequent users will not appear

in the Microsoft Online Services Portal. You must modify

the value not found the in portal, or modify both of the

values in the on-premises directory in order for both

users to appear in the Office 365 service.

Maximum number of

characters: 256

Invalid characters:

\)\(;><\]\[\\,

Multi-value attribute

For mail-enabled objects and alternate addresses, the

targetAddress attribute is required. This is especially true

in third-party messaging migration and coexistence

scenarios. If the targetAddress attribute is not present,

the fallback is to the mail attribute.

Maximum number of characters: 256

Invalid characters: [! #$ %&*+ / = ? ^ ` { }]

Maximum number of characters for username: 64

Maximum number of characters for domain name: 256

Invalid characters: }{ # ‘ * + ) ( > < / \ = ? `

& character: Automatically changed to underscore: (_)

@ character is required in each userPrincipalName value.

@ character cannot be first character in each value.

Username cannot end with a period (.), an ampersand (&), a

space ( ), or an at sign (@).

Username cannot have a space ( ).

Routable domains must be used.

Unicode is converted to underscore characters.

userPrincipalName may not contain any duplicate values in the

forest.

Note: Before making changes to the attribute it is critical to

validate that there are no applications dependent on the existing

value such as smart cards, certificates, Unix, or Linux.

*Multi-forest Deployment Considerations

16

Review options for a multi-forest AD DS implementation, including forest consolidation or a primary logon forest.

Evaluate consolidation - In general, there is more overhead required to

maintain multiple forests. Unless the organization has security constraints that

dictate the need for separate forests, consider simplifying the on-premises

environment prior to deploying Office 365.

Required Multiforest Synchronization- Dirsync appliance cannot be used,

required Office 365 supported MA

Additional multi-forest options can be provided through FIM-based solutions in

place of the standard Directory Synchronization software appliance.


Remediation Checklist Review if multi-forest scenario is applicable. Document remediation

steps prior to first synchronization.



Two-Way Synchronization (write-back aka Hybrid)

17

Two-way synchronization (or write-back) is required for Office 365 features and functionality such as cloud-based archiving, safe and blocked senders configuration, and cloud voice mail

Filtering coexistence – Enables two-way synchronization on-

premises filtering and online safe and blocked sender data from

clients MSExchBlockedSendersHash, SExchSafeRecipientsHash, MSExchSafeSendersHash

Online archive – Allows archiving of mail in Office 365

MSExchArchiveStatus

Mailbox offboarding – Allows online mailboxes to move back

on-premises ProxyAddresses

*Enabled Unified Messaging online voice mail – Indicates to

Lync communications software when user has a voice mail in

Office 365 MSExchUCVoiceMailSettings

Delegates – Allows delegation of a user’s mailbox


Service Enablement

Plan

Review business requirements to determine if two-way synchronization

is to be enabled. Document steps to support the appropriate features

outlined.



Core identity scenarios with Office 365

Cloud identity

Single cloud identity

Cloud identity with directory & password

synchronization

Single identity but

separate credentials

suitable for medium

and large organizations

Federated identity

ADFS

Single identity utilizing AD

credentials & password.

Required for MFA and access

controlled environments

Federated identity

3rd Party IDM

Single identity utilizing AD

credentials & password.

Required for MFA and access

controlled environments

Identity federation

Review requirements to enable single sign-on. Identify tasks required to enable in-scope scenarios covering user experience and align customer’s AD DS implementation for federation.




approach.

Identity

Federation

Requirements

User Experience

by Location

Namespace

Considerations

and Acceptable

Domains

Virtualization

and Capacity

Planning

Infrastructure

Design

19

DirSync with Password Sync

20

Description

• Not Single Sign On (SSO), but

user experience nearly identical to

ADFS, password cached for

Outlook and Lync

• Substantially less complex, less

hardware, networking, and only a

single server to monitor

• Password is synched to cloud,

Microsoft becomes responsible

for login

• Password can be used across

cloud properties

• No longer need to route any traffic

back on premises like ADFS

• Password Changes/Deactiveated

users are high priority and force a

sync

Concerns

• Security concerns, we sync the hash,

we reverse the hash and we

obfuscate it beyond that

• Account lockouts not replicated to

cloud, DirSync syncs Account

Disabled

• Password expiry on-premises will not

result in password expiry in the cloud

• No auditing logs for logins

• Limited two factor (2FA) authentication

coming soon

• Requires customer Portal to change

passwords

• No High Availability, but not critical in

current form

• No way to control access via ADFS

claims

3rd Party IDM

21

Description

• Not all 3rd party IDM’s are

equally integrated

• Not a formal logo program

• Some 3rd parties entering this

space without a formal

relationship with Office 365

Product Group

Concerns

• Active (Outlook, Lync) vs Passive

(OWA) applications

• Some have issues with

remapping UPN and cause

AUTOD issues

• Others have issues with multiple

federated namespaces

• Not true SAML, uses WSFED in

many cases

Identity Federation Requirements

UPN Required!




approach.

User Principal Name (UPN) – available in AD since

Windows 2000, it is not tied to Sam Account Name

22

Office 365 leverages email domains to uniquely

identify customers in multi-tenant environment

UPN = [email protected]

SAM Account = contoso\eadams

SMTP [email protected]

Message to Users:

Users can now login to everything with their email

addresses! (Office 365, Windows, Applications…)

Identity federation requirements

The on-premises infrastructure must meet the following requirements to implement AD FS.

Single Active Directory forest

AD FS deployed on Windows 2008 R2 Server or higher

Supported client operating system and service packs

Unique third-party SSL certificate for AD FS proxy server to allow:

Remote workers to access the service without a virtual private network (VPN)

For ActiveSync devices

Outlook clients running on Windows XP or Windows Vista, or any version of

Windows XP, Windows Vista, and Windows 7, where NEGO2 (Nego2 HTTP

Authentication Protocol) is not implemented

For IMAP clients

For POP clients

Windows PowerShell 2.0 to provide remote access to the AD FS server


Service Enablement

Plan

Review requirements to support identity federation. Capture necessary

actions to be taken in the Prepare phase to support identity federation.


23

User experiences

A user’s experience with single sign-on varies, based on how the user’s computer is connected to the organization’s network and how an administrator has configured AD FS. Sample configurations are as follows:

Work computer on a corporate network. When users are at work and signed

into the corporate network, single sign-on allows them to access the services in

Office 365 with their corporate credentials.

Roaming with a work computer. For users who are logged onto domain-joined

computers with their corporate credentials, but who are not connected to the

corporate network (for example, a work computer at home or at a hotel), single

sign-on allows them to access the services in the Office 365.

Home or public computer. When the user is using a computer that is not joined

to the corporate domain, the user must sign in with corporate credentials to

access the services in the Office 365 suite. AD FS federation server proxies are

required in this scenario.

Non–domain-joined computer on a corporate network. This configuration is

similar to the one previously described, except that AD FS federation server

proxies are not required in this scenario.


Service Enablement Plan Review user experiences that are deemed required, and plan AD FS

design accordingly.


24

Virtualization and capacity planning

Capacity planning for AD FS is the process of forecasting peak usage periods and planning or scaling-up the AD FS server deployment to meet those load requirements.

AD FS supports software virtualization of both the federation

server and federation-server proxy roles.

To account for redundancy, Microsoft recommends that each

AD FS virtual machine be stored on a separate physical

virtual server.


Service Enablement Plan Review anticipated user count for AD FS capacity planning. Document

anticipated hardware needs or virtualization approach, if necessary.


Number of users Suggested hardware configuration

Fewer than 1,000 No dedicated federation server proxies. Two dedicated load-balanced AD FS servers.

1,000 to 15,000 Two dedicated federation server proxies.

15,000 to 60,000 At least two dedicated federation server

proxies.

More than 60,000 Use the AD FS Capacity Planning Spreadsheet.

For additional AD FS capacity

planning guidance, please refer to

Planning for AD FS Server

Capacity.

25

http://go.microsoft.com/fwlink/?LinkID=213229

http://go.microsoft.com/fwlink/?LinkID=213229

http://technet.microsoft.com/en-us/library/gg749899(v=WS.10).aspx



Office 365 identity-federation standard design

The Office 365 identity-federation standard design represents a baseline implementation for providing the single sign-on experience.

Outlines the standard design from Microsoft Services for establishing identity

federation with Office 365.

The provided architecture does not represent the only available option but,

instead, the standard design that Microsoft Services recommends and

implements.

Specific requirements or constraints that are not satisfied within the standard

design should be discussed and addressed.


Service Enablement

Plan

Review the Office 365 identity federation standard design documentation,

and validate it with the existing enterprise requirements for single sign-on.


Out of scope for the standard design:

Office 365 cloud identities that are used for authentication (user identities that

are managed fully in the cloud without integration with on-premises AD DS)

Operations guidance to run the identity federation and Directory

Synchronization infrastructure

Advanced requirements that would require custom design, such as:

Multiple forest topologies

Strong authentication or two-factor authentication

Geo-redundancy support for federation services

26

Standard design—logical view

AD FS is the logical component that implements

the federation standards required to configure

identity federation between the on-premises

Active Directory forest and Office 365.

Directory Synchronization for Office 365

performs synchronization of AD DS objects (users,

groups, and contacts) from one on-premises AD

DS into one Office 365 tenant directory.

Windows Azure Active Directory represents the

multi-tenant directory service in the cloud.

Office 365 Authentication Platform represents

the authentication platform that constitutes the

relying party for the federation with the on-

premises Active Directory forest.

Office 365 Provisioning Web Service exposes a

web service interface used by on-premises

Directory Synchronization to synchronize data

with the Microsoft Online Directory Services.

Client components use three different

authentication flows in federated identity

scenarios, based on the type of client:

The active profile is used with Microsoft

Outlook and Exchange ActiveSync devices.

The metadata exchange (MEX) is used with

Microsoft Lync and the Office Pro Plus

Subscription Agent.

The passive profile is used with web browsers

and other Office applications such as Microsoft

Word, Excel, and PowerPoint.

27

Standard design—physical view

Active Directory Federation Server is a specific

role service of AD FS, designed to implement the

federation protocols, to define and manage

relying parties, and to provide tokens in response

to requestors.

Active Directory Federation Proxy or

Application Proxy is a specific role service of AD

FS, designed to publish the AD FS on the Internet,

for federation relationships involving external

relying parties.

Directory Synchronization Server continuously

synchronizes the Active Directory forest on-

premises with Office 365.

Domain Name System (DNS): The Office 365

identity federation standard design prescribes a

split-DNS design for the AD FS internal and

external load balanced endpoints. This essentially

means that the same external fully qualified

domain name (FQDN) (typically sts.contoso.com)

must be resolved differently for internal and

external resolvers.

• Internal clients (internal DNS) must resolve the

AD FS external FQDN to the load balanced end

point of the internal AD FS federation servers.

• External resolvers (public DNS) must resolve

the AD FS external FQDN to the load balanced

end point of the AD FS proxy servers.

Additional AD FS proxy considerations and a list of required ports and protocols are provided in the Office 365 Identity Federation Standard Design documentation.

28

Understanding client authentication path

Lync 2013/Office Subscription

Active Sync

Corporate Boundary

Exchange Online

AD FS 2.0Server

MEX

Web

Active

AD FS 2.0 Proxy

MEX

Web

Active

Outlook 2013IMAP/POP

UsernamePassword

UsernamePassword

OWAInternal

Lync 2013/Office Subscription

Outlook 2013IMAP/POP

OWAExternal

UsernamePassword

Active Sync

UsernamePassword

Basic auth proposal: Pass

client IP, protocol, device name

Authentication flow (passive/web profile)

Identity federation

`

Client

(joined to CorpNet)

Authentication platformAD FS 2.0 Server

Exchange Online or

SharePoint Online

Active Directory

Customer Microsoft Online Services

Logon (SAML 1.1) Token

UPN:[email protected]

Source User ID: ABC123

Auth Token


Unique ID: 254729

Authentication flow (MEX/rich client profile)

Identity federation

`

Client

(joined to CorpNet)

Authentication platformAD FS 2.0 Server

Lync Online

Active Directory





Auth Token


Unique ID: 254729


Active flow (Outlook/Active Sync) always external

Identity federation

`

Client

(joined to CorpNet)

Authentication platformAD FS

Exchange Online

Active Directory

AD FS Proxy




Auth Token


Unique ID: 254729

Basic Auth Credentilas

Username/Password

Namespace considerations and acceptable domains

Support for multiple top domains is available within AD FS

AD FS has an update rollup that works in conjunction with

SupportMultipleDomain switch to support multiple top-level

domains for UPN suffixes.

Note: the SupportMultipleDomain switch is not required when you

have a single top-level domain and multiple subdomains.


Service Enablement Plan Review whether multiple namespaces are in use, and determine

whether the SupportMultipleDomain AD FS switch is needed.

Review whether the UPN suffix is required for instances in which the

customer has implemented AD DS with an internal namespace.


Only routable domains can be used with an AD FS deployment.

Examples of nonroutable domains are the following:

.local

.loc

.internal

33

Client access control

Block all external access to Office 365 based on the IP address of the external client

Block all external access to Office 365 except Exchange Active Sync; all other clients such as Outlook are blocked.

Block all external access to Office 365 except for passive browser based applications such as Outlook Web Access or SharePoint Online

Passiv

e Active

Passiv

e Active

Outlook 2010/2007 ActiveSync ActiveSync Outlook 2010/2007

Browser Internal AD FS 2.0 Server

AD FS 2.0 Proxy

Outlook and ActiveSync Auth

Web Auth (OWA, SharePoint)

Browser External

Identity federation


Recap and next steps


Identity Federation

Complete planning for:

Federation design for user experience requirements.

AD FS infrastructure design (validate if Standard Design will meet requirements).

Namespace and domains for federated identities.

Service Enablement plan to be completed for Assess phase completion checkpoint (mmm/dd).

35

© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or

other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must

respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided

after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION

Questions ?

© 2013 Microsoft Corporation. All rights reserved. Microsoft, Access database software, Active Directory directory service, ActiveSync technology, ActiveX controls, Excel spreadsheet software,

InfoPath information gathering program, Internet Explorer Internet browser, Lync communications software, Office 365 hosted productivity software, OneNote note-taking program, Outlook

messaging and collaboration client, PowerPoint presentation software, RoundTable communications and archival system, SharePoint services, SQL Server software, Windows operating system,

Windows Azure technology platform, Windows Intune software and services, Windows Server operating system, and Windows Vista operating system and other product names are or may be

registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation

as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft

cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE

INFORMATION IN THIS PRESENTATION

Date post:	28-May-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

User identity, Account Provisioning, Directory Synchronization,...

Documents