What’s In This Chapter?
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.
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:
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:
Office 365 provides two ways to master identities using a purely Office 365–based identity system:
This section explores these options and the pros and cons associated with each.
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:
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
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:
When working with an on-premises AD, your infrastructure needs to meet some general requirements:
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.
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:
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.
The following are the caveats you should consider when you work with directory synchronization:
AD Object | DirSync Filter to Remove |
Contact | MSOL in DisplayNamemsExchHideFromAddressLists = TRUE |
SecurityEnabledGroup | isCriticalSystemObject = TRUE |
MailEnabledGroupsMailEnabledContacts | The proxy address does not have a primary SMTP address, and the mail attribute is not present. |
iNetOrgPerson | sAMAccountName is not present.isCriticalSystemObject is present. |
User | mailNickName starts with "SystemMailbox{"mailNickName contains "{"mailNickName starts with "CAS_"sAMAccountName starts with "CAS_"sAMAccountName has "}"sAMAccountName equals "SUPPORT_388945a0"sAMAccountName equals "MSOL_AD_Sync"sAMAccountName is not presentisCriticalSystemObject is present |
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.
Scenario Name | SSO Details |
Computer domain-joined | Requires no additional sign-in |
Roaming with domain-joined machine | Requires no additional sign-in |
Nondomain-joined machine off network | Requires additional sign-in with ADFS proxy |
Nondomain-joined machine on corporate network | Requires additional sign-in without ADFS proxy |
Office Client Applications | Requires additional sign-in |
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.
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.
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
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:
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.
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.
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.