Part II

Office 365

• Chapter 3: Office 365 Identity Services
• Chapter 4: Introducing SharePoint Online

Chapter 3

Office 365 Identity Services

What’s In This Chapter?

• What is identity?
• An overview of identity in Office 365
• Working with role-based administration

When you work with any application, identity is important because it provides who the users are, what permissions they have, and whether they can access the resources they attempt to access. In cloud computing, identity becomes even more critical because you have a single user wanting to access resources and applications stretching beyond the premises and into the cloud, and because you want to provide a single set of login credentials and as seamless an experience as possible.

In this chapter, you learn some of the important concerns and issues with identity in this context and what Microsoft provides in the Office 365 space to help resolve them.

Understanding Identity

Before diving into the identity system in Office 365, it is worthwhile to look at some key concepts concerning the identity management space (referred to as Identify Lifecycle Management, or ILM) and to see how cloud services impact identity management.

When you hear people talking about identity management, they’re referring to a system that identifies individuals in the system and controls access to the resources in that system. An identity management system does this through the two fundamental capabilities of authentication and authorization:

• Authentication (or AuthN): The ability to verify that a user, device, or service is the entity it claims to be. This can be done in a number of ways: through a username and password, certificates, or other mechanisms.
• Authorization (or AuthZ): This determines what actions an authenticated entity is authorized to perform on resources in the system. For example, you can authorize an entity to access files, services, or other resources contained in your system.

These days, even within the enterprise, you may find it quite a challenge to have multiple client-facing and back-end systems that you need to integrate together in order to reduce the management and administrative overhead. However, the cloud introduces a whole range of additional complexities, because you now must deal with remote, cloud-based resources, further security concerns, and interacting with potentially quite disparate systems as business partners. However, providing users with only a single identity to worry about that can span across both environments is worth the complexity; it significantly reduces the hassle, the overhead, and the security risk of having multiple disparate identities, one for each environment or system.

Getting identity in the cloud working requires several important components:

• Enhanced access controls: The ubiquity of the cloud requires that you provide controlled access to services with an IP-based access control. In addition, it may require that you have a two-factor-based authentication.
• Directory management: This management is between on-premises and cloud-based identities because customers may want to store their identities in both places and require directory synchronization to ensure that both places are always kept synchronized.
• Single sign-on: This is a big feature of cloud services. Whether users’ identities are hosted in the cloud or on-premises, they only want to use a single identity to log on and access resources.

Understanding Identity in Office 365

Office 365 provides two ways to master identities using a purely Office 365–based identity system:

• Mastering on-premises and synchronizing with Office 365 using directory synchronization
• Mastering on-premises and synchronizing to the cloud and providing a federated identity between the environments by leveraging Active Directory Federation Services (ADFS) and your on-premises Active Directory (AD) infrastructure

This section explores these options and the pros and cons associated with each.

Establishing Identity Using Only Office 365 Identities

The built-in identity system in Office 365 is the easiest means to deploy, manage, and support identity because you do not have the complexity of directory synchronization; you do not configure single sign-on; and you don’t require any additional on-premises servers. In addition, the Office 365 online identities work seamlessly with the Office desktop client, web clients, and mobile clients without any other configuration.

However, using only the online identity has its downside:

• You may need to require your users to remember two sets of credentials. One set would be for their on-premises login and the other for their Office 365 login.
• You may end up with two sets of password policies. This is because the on-premises password policies may differ from the Office 365 password policies.
• You cannot use two-factor authentication or single sign-on in this scenario. This is because both require that you deploy ADFS on-premises.

The Office 365 password policy depends on which edition of Office 365 you purchase. For example, with the Professional SKU version, passwords are never set to expire. With the Enterprise SKU, passwords expire every 90 days, and this is not configurable. Using PowerShell, however, you can set your password to never expire as you’ll see later in this chapter. In addition, irrespective of the edition, Enterprise or Professional, strong passwords are required, which means having a password between 8 to 16 characters with a mix of lowercase, uppercase, numbers, or symbols. Also, you cannot use a password again in Office 365. Finally, after 10 unsuccessful logon attempts, the user needs to solve a CAPTCHA dialog as part of the log-on. After another 10 unsuccessful log-on attempts, the user is locked out for an unspecified amount of time. Further incorrect passwords cause this timeout to grow exponentially.

When you use test accounts, you may find that the 90-day password expiry makes working with the service more difficult. With a little PowerShell, you can make your password permanent; however, you should understand that doing so makes your account weaker and more vulnerable. The following PowerShell script uses the Set-MsolUser cmdlet with the -PasswordNeverExpires boolean option to turn off password expiry. You can also use the –StrongPasswordRequired boolean option to turn off strong passwords. Make sure to run this PowerShell script with the Microsoft Online Services cmdlets loaded. Figure 3-1 shows an Online Identity managed in the Office 365 Portal.

Connect-MsolService
Set-MsolUser -UserPrincipalName [email protected] -PasswordNeverExpires $true

For more information on setting up user accounts in Office 365, refer to Chapter 2.

Using Office 365 with On-Premises Active Directory

With this Office 365 option, you can integrate with an on-premises AD using either directory synchronization or federated identities and single sign-on. The benefits for integrating with an on-premises AD are as follows:

• You have a single place for your identity management through your on-premises technology. This means that you have one place in which to manage your users and groups and all your passwords.
• You can control your password policies. This means you don’t have to rely on the password policies in Office 365.
• You can leverage single sign-on. This means your users have to log on to your on-premises domain only once, and they can use that identity with both on-premises applications and services and the Office 365 services.
• You can support strong authentication. You can do this using technologies such as two-factor authentication and smartcards in addition to usernames and passwords.

Figure 3-1

General Requirements

When working with an on-premises AD, your infrastructure needs to meet some general requirements:

• Your AD Forest must be at least the 2003 functional level. For this reason, you cannot have a Windows 2000 level of functionality for your AD forest.
• You can have only a single AD forest deployed. Your forest can have multiple domains, but Office 365 currently does not support multiforest deployments. For example, you can have one forest with user accounts and another forest with resources but you must synchronize both to Office 365. To do this, you must consolidate your multiple forests into a single forest.
• To support ADFS 2.0, you need Windows Server 2008 or above for ADFS 2.0.
• To use directory synchronization, you must have Windows Server 2003 or above. Directory synchronization ships for both 32-bit and 64-bit, so you must decide which version you want depending on your server infrastructure.
• A hybrid deployment of Exchange Server requires Exchange 2010 Service Pack 1 Client Access Server and the associated schema applied to your AD infrastructure. As you’ll see in the next section, with Exchange SP1, you can manage a hybrid Exchange deployment from a single Exchange management console.

Directory Synchronization with Office 365

If you want to master your accounts on-premises and synchronize those accounts to Office 365, you must use the Office 365 directory synchronization tool to synchronize your on-premises accounts to the cloud. When you use the tool, it synchronizes your on-premises users, groups, and contacts into Office 365.

You can install either a 32-bit or 64-bit version of the directory synchronization tool. The tool is the same regardless of what version you install, but the underlying SQL Schema is different, so you need to stick with one edition of the synchronization tool. In addition, the tool installs SQL Server Express as part of its installation. This is fine for smaller directories, but if you have a large directory—over 20,000 objects—you need a full version of SQL Server, and you need the directory synchronization tool to use that full version.

Figure 3-2 shows the directory synchronization tool. The tool is easy to set up, and with a few clicks, you can have your on-premises AD synchronizing to the cloud.

Figure 3-2

The tool just asks for your Office 365 user name, your AD credentials, and whether you want to set up a hybrid Exchange environment. A hybrid Exchange environment is an Exchange environment that has some mailboxes hosted in on-premises servers and some mailboxes hosted in Exchange Online. Some of the benefits of an Exchange hybrid environment are that you can:

• Archive your on-premises mailboxes to the cloud.
• Off-board mailboxes from the cloud to on-premises.
• Maintain on-premises mail filtering, which determines how a user makes changes to safe and blocked senders in the cloud.
• Know when a user has voice mail in the cloud.

To run an Exchange hybrid environment with directory synchronization, you need to grant write access to your AD for the directory synchronization account.

Directory synchronization provides on-going synchronization of your user accounts, mail-enabled contacts, and mail-enabled groups. Without directory synchronization, you can’t have a single Global Address List (GAL) because your on-premises accounts will be unknown to Exchange Online. For those of you newer to Exchange, the Global Address List is what Exchange provides for users to look up other users, distribution groups, conference rooms, and other resources in a centralized address book.

Besides having a unified GAL, by using directory synchronization, you can manage a hybrid Exchange environment from the Exchange management console. In the console, you can work with your on-premises deployed Exchange servers and your Exchange Online services. Figure 3-3 shows how you manage both Exchange on-premises and Exchange Online in a single console.

Figure 3-3

The following are the caveats you should consider when you work with directory synchronization:

• Online objects aren’t editable: You cannot edit the online objects after synchronizing them to the cloud.
• On-premises accounts synchronized and then accessed through the online portal are read-only: Any changes to accounts, besides licensing changes, must be made in your on-premises AD and synchronized to the cloud. Figure 3-4 shows a synchronized account. Notice how the fields are grayed out so that you cannot edit them.

Figure 3-4

• You can’t customize filters: One question users always ask about Office 365 directory synchronization concerns how you customize the filters that the dirsync tool uses. Unfortunately, you cannot customize the filters. Instead, you must work within the limitations of the default filters, which are shown in Table 3-1.
• Synchronized users are deactivated by default. You either need to use PowerShell or the administration portal to activate the users. Until you do this, the users cannot use the online service.
• Passwords are not synchronized between on-premises and online with the directory synchronization tool. When the administrator activates the synchronized accounts, a new password is created for the account. If users change their passwords in either location, those passwords aren’t synchronized to the other location. There are third-party tools that provide password synchronization for Office 365, or you can use single sign-on so as not to require passwords beyond the on-premises passwords used by your AD accounts.

Table 3-1: DirSync Filters

Using Single Sign-on with Office 365

Single sign-on enables your users to enter their AD credentials to access Office 365 resources via Active Directory Federation Services (ADFS) 2.0. Your users just click to access certain services without entering their local domain credentials. One word of caution with SSO: The experience depends on whether the client machines are domain-joined as well as the services the users on these machines are accessing such as Exchange Online, SharePoint Online or others. Table 3-2 shows different scenarios and what SSO supports.

Table 3-2: SSO Scenarios

SSO provides a number of benefits that include controlling the account policies, such as password policies, workstation restrictions, lockouts, and other policies. In addition, you can implement 2-factor authentication if you implement SSO.

Please note that the 2-factor authentication supports only web clients. Figure 3-5 shows how to log into the Office 365 portal using SSO. Notice the link to log on to the domain.

Figure 3-5

When working with rich clients and SSO, you must log on to Office 365 with your domain credentials because the Office client cannot pass the Windows credentials from your machine to the service. You can use your domain credentials, but this requires an extra click. Figure 3-6 shows the Office client asking for credentials for Office 365.

Figure 3-6

Smart Linking

Another feature of ADFS and Office 365 is the capability to perform smart linking or identity provider-initiated linking. These are fancy ways to say that you can create links that have the authentication endpoint in the URL and that bypass the Office 365 logon page. This is accomplished by passing the authentication realm for the user so that the endpoint can decide where to redirect the user.

In particular, deep links send the browser to the authoritative ADFS 2.0 server passive login endpoint. The endpoint encodes any SAML token as well as the relying party service that the user attempts to reach, such as the URL for Exchange Online or the Office 365 portal. All these steps prevent the user from manually going to the portal and logging on to the service.

Currently, constructing a smart link is a manual process, with the exception of Outlook Web Access, which requires you to put only http://outlook.com/domainname or http://outlook.com/owa/domainname. For other services, you must http trace the service you want to log on to using something like Fiddler and the web address such as https://portal.microsoftonline.com/.

Then, follow these steps:

The following link shows how to log on to SharePoint Online by setting the wreply to the SharePoint Online page.

https://dc.thomrizdom.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=MEST%3D0%26LoginOptions%3D2%26wa%3Dwsignin1.0%26rpsnv%3D2%26ct%3D1323123053%26rver%3D6.1.6206.0%26wp%3DMCMBI%26wreply%3Dhttps:%252F%252Fthomrizdom.sharepoint.com%252Fsitepages%252Fhome.aspx%253Ftarget%253D%25252fDefault.aspx%26lc%3D1033%26id%3D271346

Role-Based Administration

The last area to explore is role-based administration in Office 365. Role-based administration is offered in the different products in Office 365 as well as at the all-up Office 365 administration level. At the service level, you can set up five different roles:

• Billing Administrator
• Global Administrator
• Password Administrator
• Service Administrator
• User Management Administrator

Assigning these roles does not allow the user to manage other resources by default. For example, you must set SharePoint permissions for the user. Figure 3-7 shows setting role-based administration for Office 365.

In Exchange Online, you can create roles that allow you to customize the types of activities that administrators can do—from resetting passwords to viewing audit logs. Figure 3-8 shows setting roles in Exchange Online.

Figure 3-7

Figure 3-8

In SharePoint Online, you can create groups and assign permissions to the group and then assign users in the group to give them those permissions. Figure 3-9 shows setting permissions for groups in SharePoint Online.

Figure 3-9

Summary

In this chapter, you learned about identity management and integrating Office 365 with your on-premises identity infrastructure. In addition, you learned about how to configure deep linking to make logging onto the service easier for your users without having to enter credentials. You also saw how to configure user permissions within Office 365 as a whole as well as within the individual service offerings.