Design and implement Microsoft 365 services

Skill 1.2: Plan a Microsoft 365 implementation

This section deals with the steps that your organization needs to take to plan a Microsoft 365 deployment. This includes understanding what you’ll need to do to prepare the infrastructure for a brand-new deployment for a new organization, as well as what steps to take to integrate Microsoft 365 into an organization that already has an on-premises Active Directory and network infrastructure present. To master this skill, you’ll need to understand the types of planning steps that you’ll need to undertake to prepare your organization for Microsoft 365, and understand what the most appropriate identity and authentication solution is for your organization.

Plan for Microsoft 365 on-premises infrastructure

When planning a migration to Microsoft 365, or starting from scratch, “green-field,” or a brand-new deployment, you’ll have to make sure certain on-premises infrastructure prerequisites have been met. These on-premises infrastructure requirements relate to networking configuration, identity dependencies, client operating systems, deployment of Office 365 pro plus, as well as choices on strategy for mobile device management and information protection.

Networking

Traditional networks have provided users with access to data and applications hosted on datacenters owned and operated by the organization, and protected by strong perimeter defenses such as firewalls. In this traditional model, users primarily access resources from protected internal networks, over WAN links from branch locations, or remotely via VPN connections.

The M365 and O365 model shifts some, if not all, applications and data from locations on protected internal networks to locations hosted beyond the network perimeter in the public cloud. When moving from an environment where all resources are hosted on-premises, to where a substantial amount of infrastructure is hosted in the cloud, it is necessary to ensure that the on-premises networking environment is configured in such a way that M365 can function effectively and efficiently. Unless steps are taken to optimize the flow of traffic between users and M365 and O365 services, this traffic will be subject to increased latency caused by packet inspection, network hairpins, and possible inadvertent connections to geographically distant M365 and O365 service endpoints.

Understanding the networking requirements for M365 also allows you to make an assessment as to whether M365 is appropriate for a particular organization. For example, there are challenges around deploying M365 effectively at a scientific base in Antarctica where there is limited low bandwidth connectivity to the Internet.

Internet Connectivity for Clients

To use Office 365, clients need to establish unauthenticated connections over port 80 and port 443 to the Microsoft 365 and Office 365 servers on the Internet. On some networks, especially those configured for small businesses, you may run into the following network connectivity problems:

• Clients configured with APIPA addresses If clients are configured with IP addresses in the APIPA range (169.254.0.0 /16), they most likely cannot make a connection to the Internet. This means they can’t interact with M365 and O365 resources. Clients configured with an APIPA address should be configured with IP addresses in the private range with an appropriate default gateway configured to connect either directly or indirectly to the Internet.

• No default gateway Clients need to be configured with a default gateway address of a device that can route traffic to the Internet. The default gateway device doesn’t need to be directly connected to the Internet, but it needs to be able to route traffic to a device that eventually does connect to the Internet. Clients without a default gateway configured will not be able to connect to M365 and O365 resources.

• Firewall configuration Clients require access to certain endpoints used by M365 and O365. The details of these endpoints will be outlined later in this chapter.

• Proxy server authentication M365 and O365 will not function if an intervening proxy server requires authentication for connections. You’ll have to configure an authentication bypass for M365 and O365 endpoints, or disable proxy server authentication to Microsoft 365 and Office 365 endpoints on the Internet.

Managing Office 365 Endpoints

A Microsoft 365 or Office 365 endpoint is a URL or IP address that hosts a specific Microsoft 365 or Office 365 service, such as the addresses used when connecting an Outlook client to Exchange Online or a mobile device to an enrollment point. Organizations that have one or more office locations need to ensure that their network is configured to allow access to these endpoints.

Microsoft recommends that organizations optimize traffic for M365 and O365 endpoints by routing all traffic directly through the perimeter firewall and having that traffic be made exempt from packet level inspection or processing. Taking these steps will reduce latency to M365 and O365 resource endpoints. This configuration will also reduce the impact on those perimeter devices, which will ignore this traffic to known trusted locations.

Microsoft places each M365 and O365 endpoint into one of three categories. These categories allow you to deal with traffic to M365 and O365 endpoints in the most appropriate manner. The category endpoints that Microsoft uses are: Optimize, Allow, and Default. These endpoint categories have the following properties:

• Optimize Endpoints with this classification are required for connectivity for every M365 and O365 service. Optimize classified endpoints will account for approximately 75% of bandwidth, volume of data, and individual connections. Endpoints with the Optimize classification cause the most problems when there are disruptions to network performance, latency, and availability.

• Allow Endpoints with this classification are also required for connectivity for every M365 and O365 service, but differ from Optimize classified endpoints in that they are less problematic when there are disruptions to network performance, latency, and availability.

• Default Endpoints with this classification don’t require any specific optimization and can be treated the same as other traffic bound for locations on the Internet.

Microsoft provides recommendations for how to configure traffic flow to endpoints. These recommendations are listed in Table 1-5.

Table 1-5 Endpoint optimization methods

Endpoint Type	Recommendation
Optimize, Allow	Bypass or whitelist endpoints on network devices and services that perform TLS decryption, traffic interception, content filtering, and deep packet inspection.
Optimize	Bypass on-premises and cloud based proxy devices or services used for general Internet browsing.
Optimize, Allow	Treat these endpoints as fully trusted by network infrastructure and perimeter systems.
Optimize, Allow	Reduce or eliminate WAN backhauling. Facilitate direct distributed internet egress for endpoints from branch office locations.
Optimize	Configure split tunneling for VPN users to allow direct connectivity to these endpoints.
Optimize, Allow	Configure prioritization for endpoints when configuring SD-WAN to minimize latency and routing.
Optimize, Allow	Ensure DNS name resolution matches routing egress path for endpoints.

In the past, Microsoft provided alternate guidance categories to the ones listed earlier. The prior guidance categories were Required and Optional, rather than the current categories of Optimize, Allow, and Default. Some documentation still refers to these earlier endpoint categories.

Outbound Firewall Ports

Clients, such as computers running Windows 10, need to be able to make connections to the M365 and O365 endpoints on the Internet using specific protocols and ports. If certain ports and protocols are blocked by a perimeter network firewall, clients will be unable to use specific M365 and O365 services. Table 1-6 lists the protocols and ports that need to be open for clients on an internal network to hosts on the Internet.

Table 1-6 Office 365 Outbound Port requirements

Protocol	Port	Used by
TCP	443	Office 365 portal Outlook Outlook Web App SharePoint Online Skype for Business client ADFS Federation ADFS Proxy
TCP	25	Mail routing
TCP	587	SMTP relay
TCP	143/993	IMAP Simple Migration Tool
TCP	80/443	Microsoft Azure Active Directory Connect tool Exchange Management Console Exchange Management Shell
TCP	995	POP3 secure
PSOM/TLS	443	Skype for Business Online: Outbound data sharing
STUN/TCP	443	Skype for Business Online: Outbound audio, video, and application sharing sessions
STUN/UDP	3478	Skype for Business Online: Outbound audio and video sessions
TCP	5223	Skype for Business mobile client push notifications
UDP	20000-45000	Skype for Business Online outbound phone
RTC/UDP	50000-59000	Skype for Business Online: Outbound audio and video sessions.

The number of IP addresses and URLs that you need to configure for exclusion is substantial and a complete list is beyond the scope of this book. The URLs and IP address ranges that are associated with Microsoft and Office 365 are always changing, and it is possible to subscribe to a REST based web service that provides the list of endpoints, the current version of the list, and changes made to the list for use in configuring network perimeter devices including firewalls and proxy servers.

Egress Network Connections Locally

A method of reducing connection latency is to ensure that you configure branch office networks for local DNS and Internet egress, rather than forcing all DNS and Internet egress traffic to be routed over a WAN link to a head office before being routed to the Internet. Routing Internet bound branch office traffic across a WAN before allowing it to egress is also termed “WAN Backhauling,” and should be avoided when it comes specifically to M365 and O365 traffic that has the Optimize categorization.

M365 and O365 services run on the Microsoft Global Network. This network is configured with servers around the world. This means that there is likely to be a front end server in proximity to each branch office location and that routing traffic across a WAN rather than letting it egress directly from the branch office will introduce unnecessary latency. DNS traffic to M365 and O365 endpoints should also egress at the branch office, as this will ensure that DNS servers respond with the closest local frond end server. If DNS queries are relayed across WAN links and only egress through a single head office location, clients will be directed to front end servers closest to the head office location, rather than the branch office where the DNS query originated.

Avoiding Network Hairpins

Network hairpins occur when VPN or WAN traffic destined for a specific endpoint must first pass through an intermediate location, such as a security appliance, cloud-based web gateway, or cloud access broker, which may introduce a redirection to a geographically distant location. For example, if Tailwind Traders has an Australian branch office, but all traffic to M365 and O365 endpoints need to go through a cloud-based security device located in a Canadian cloud provider datacenter, then it’s likely that unnecessary latencies will be introduced. Even if branch office traffic is egressed locally, there will be a deleterious impact on performance if it is routed through a geographically distant intermediate location.

There are several methods that minimize the chance of network hairpins, including:

• Ensure that the ISP that provides Internet egress for the branch office has a direct peering relationship with the Microsoft Global Network in proximity to that location.

• Configure egress routing to send trusted M365 and O365 traffic directly to M365 and O365 endpoints rather than having them processed by intermediate services and devices.

Deploy SD-Wan Devices

Software Defined Wide Area Network (SD-WAN) devices are networking devices that can be configured automatically so that traffic is most efficiently routed to M365 and O365 Optimize and Allow endpoints. When configured, other network traffic, including traffic to on-premises workloads, general Internet traffic, and traffic to M365 and O365 default endpoints can be forwarded to appropriate locations including network security devices. Microsoft has a partner program for SD-WAN providers to enable automatic configuration of devices.

Recommend Bandwidth

There are many factors that influence the amount of bandwidth that an organization will require to successfully use Office 365. These factors include:

• The specific Office 365 services to which the organization has subscribed.

• The number of client devices connecting to Office 365 from a site at any point in time.

• The type of interaction the client is having with Office 365.

• The performance of the Internet browser software on each client computer.

• The capacity of the network connection available to each client computer.

• Your organization’s network topology.

Microsoft provides a number of tools that can be used to estimate the bandwidth requirements of an Office 365 deployment. These include:

• Exchange client network bandwidth calculator This tool allows you to estimate the bandwidth required for Outlook, Outlook Web App, and mobile device users.

• Skype for Business Online bandwidth calculator This tool allows you to estimate the amount of bandwidth you will require based on the number of Skype for Business users and the specific features those users will be leveraging.

• OneDrive for Business synchronization calculator This tool provides network bandwidth estimates based on how users use OneDrive for Business.

Windows 10 Enterprise

A Microsoft 365 Enterprise license includes a license for the Windows 10 Enterprise edition operating system. Part of the process of adopting M365 will involve ensuring that all Windows client computers are running this edition of the Windows 10 operating system.

Organizations that have an existing Windows 7 or Windows 8.1 deployment should perform an in-place upgrade using System Center Configuration Manager or Microsoft Deployment Toolkit. System Center Configuration Manger (Current Branch) provides organizations with the most automated method of upgrading and migrating existing computers from previous versions of the Windows client operating system to Windows 10.

Organizations that are deploying new computers that have Windows 10 Enterprise edition version 1703 or later can use Windows Autopilot to trigger the deployment and configuration process by signing in using their school or work credentials. Organizations running the Pro edition can also have those computers automatically updated to the Enterprise edition through Windows Autopilot.

Information protection

When planning your organization’s M365 information protection strategy, the first and perhaps most important step is to liaise with the organization’s legal and compliance teams to determine which compliance standards, such as the General Data Protection Regulation (GDPR) or Health Insurance Portability and Accountability Act (HIPAA) that the organization is subject to. Once you’ve determined the specific compliance standards, or regulation to which your organization must adhere, you will need to make determinations for the following questions:

• What are the appropriate security and information protection levels for our organization?

• What is an appropriate document classification schema for our organization?

• What steps must be taken to ensure the appropriate security level is configured within M365 and O365?

• Is it necessary to configure privileged access management for M365 and O365?

Security and Information Protection Levels

M365 allows organizations to develop their own security and protection levels. While it’s possible to create a bewildering number of information protection security levels, doing so increases complexity both for end users attempting to understand which level is appropriate, and for compliance staff who have to make a determination as to whether the appropriate level has been selected.

Microsoft recommends that organizations plan to use at least three separate information protection security levels. As information protection security levels increase, data becomes more protected, but it also becomes more cumbersome for users to interact with that data. Only accessing the most sensitive data should require a user to go through a multi-factor authentication process each time they open a document. Microsoft suggests the following levels:

• Baseline Organizations should have a minimum standard for the protection of data, identities, and the devices used to interact with organizational data.

• Sensitive This intermediate standard is appropriate for data that is considered sensitive, but for which the most stringent security controls are not appropriate.

• Highly regulated This standard requires the most stringent security controls, and is likely to be appropriate only for a small amount of the organization’s data. For example, you may require that data only be accessed from a managed device for a limited amount of time after a user has performed multi-factor authentication.

Classification Schemas

Classification schemas allow you to assign an information protection level to specific information such as a document or email message. Microsoft 365 includes the following three classification schemas:

• Sensitive information types for Office 365 Office 365 automatically recognizes specific information types, such as credit card or passport numbers. You can leverage Office 365 sensitive information types to automatically apply data loss prevention rules and policies so that this data has the appropriate level of protection.

• Office 365 retention labels Office 365 retention labels allow you to determine how long specific data should be stored in Exchange, SharePoint Online, and OneDrive for Business. Office 365 retention labels can use the security and information protection levels outlined earlier: baseline, sensitive, highly regulated, or the custom information protection levels determined by the organization.

• Azure Information Protection (AIP) labels and protection AIP provides another set of options for the classification and protection of documents and email messages. An advantage of AIP is that it can be used with documents stored beyond Office 365 locations such as Exchange Online, SharePoint Online, and OneDrive for Business. AIP labels of protection can be applied automatically based on rules and conditions defined by an administrator, manually by users, or in conjunction with automatic recommendations displayed to users.

Improving Security Levels

When planning your M365 information protection strategy, you’ll need to go beyond information classification, retention policies, and information protection. You’ll also need to enable additional M365 security technologies. These technologies include:

• Threat management policies You can configure threat management policies in the Security & Compliance Center. Policies include ATP (Advanced Threat Protection) anti-phishing, anti-malware, ATP Safe Attachments, ATP Safe Links, Anti-Spam (Mail Filtering) and Email Authentication.

• Exchange Online tenant wide settings You can improve security by implementing appropriate Mail Flow, also known as Transport Rules, and enabling modern authentication, which allows you to then use multi-factor authentication (MFA).

• SharePoint tenant wide settings Security can be strengthened by configuring external sharing settings. Options include limiting sharing to authenticated external users, allowing anonymous access links, configuring anonymous access link expiration, and default link types.

• Azure Active Directory settings You can enhance security by configuring named locations, which is part of conditional access, and to also block apps that don’t support modern authentication.

• Cloud App Security Cloud App Security allows organizations to improve their security posture by providing evaluations of risk, and alerts against suspicious activity and automatic remediation actions. Cloud App Security requires an M365, O365 or EMS E5 plan.

Privileged Access Management

The effectiveness of an information protection strategy depends on how secure the administrative accounts used to manage that strategy are. If the accounts that can be used to configure and manage an information protection strategy aren’t properly secured, then the information protection strategy itself can be easily compromised.

Privileged access management allows you to configure policies that apply just-in-time administrative principles to sensitive administrative roles. For example, if someone needs access to configure an information protection policy, they would need to go through an approval process to temporarily gain access to that set of rights as opposed to having an Azure AD account that had permanently been assigned those rights.

Plan identity and authentication solution

Identity providers are the primary source of authority and host user and group accounts. When you select a primary source of identity, that location is where authoritative changes to an account or group are made. For example, if you perform a password change, the password change isn’t understood to apply unless it applies at the primary source of identity. For example, in a hybrid scenario it’s possible to change the password of an account that is replicated from an on-premises directory to a cloud based Azure Active Directory. You might change the password of the account in the cloud, but that change may be overwritten the next time synchronization occurs from the primary identity source.

M365 and O365 use Azure Active Directory (Azure AD) as the user and group identity and authentication service. This means that Azure AD stores user, group, and device account objects and is also responsible for performing M365 and O365 authentication. When deploying M365 and O365 you can choose whether identity management is cloud only or whether a relationship exists between an on-premises identity provider such as Active Directory Domain Services (AD DS) and Azure AD.

Cloud authentication

When you select cloud authentication, authentication occurs against Azure Active Directory. How you implement cloud authentication depends on whether or not your organization has an existing on-premises Active Directory Domain Services deployment and what your plans are for that deployment in the future.

Cloud-Only

The cloud-only authentication model addresses management of user and group accounts that exist only from within M365. You can create and manage users in the M365 admin center shown in Figure 1-27, in the Azure Active Directory portal or blade, or by using the appropriate PowerShell cmdlets.

A cloud only identity and authentication solution is appropriate if:

• Your organization has not deployed an on-premises Active Directory Domain Services environment.

• Your organization has a very complex on-premises directory solution and wants to avoid attempting to integrate it.

• Your organization has an on-premises Active Directory Domain Services environment, but wants to run a pilot or trial of M365 and will worry about integrating with the existing environment if the pilot or trial proves successful.

Password Hash SYNC with Single Sign-On

When planning an identity and authentication solution using password hash synchronization, your organization will synchronize on-premises AD DS user accounts with the Azure AD service used by M365 and O365. When you adopt this strategy, cryptographic hashes of on-premises user passwords are synchronized to Azure AD.

The cryptographic hashing operation is one way. This means that it’s not possible to run a reverse cryptographic operation on the hash to derive the password it was generated from, although there are techniques that iterate possible passwords to see if they match a cryptographic hash should one manage to be captured. The use of cryptographic hashes means that the user passwords aren’t stored in Azure AD. When authentication occurs, the password the user enters has the same cryptographic operation performed on it, and the hash of that password is then compared to the one stored in Azure AD. If the hashes match, the user is authenticated. If the hashes do not match, the user is not authenticated. If a password is changed in the on-premises account database, a new password hash is calculated and the new cryptographic hash is synchronized to and stored in Azure AD.

Choose this method when you want to have on-premises Active Directory Domain Services remain the authoritative source for user accounts and the regulations that your organization is subject to allow for cryptographic hashes of passwords to be stored in the cloud. This solution requires Azure Active Directory Connect, which you’ll learn about in Chapter 2, “Manage User Identity and Roles”.

Pass-Through Authentication with Single Sign-On

When you implement pass-through authentication with single sign-on, you install a software agent on one or more on-premises Active Directory Domain Services (AD DS) domain controllers. When a user authenticates against Azure Active Directory, the request is passed through to the on-premises Active Directory instance through the agent to determine whether the authentication request is valid.

This solution is appropriate when your organization is constrained from allowing any form of password synchronization to the cloud. This may include being restricted from allowing cryptographic hashes of passwords to be stored in the cloud. In this scenario, you would choose pass through authentication with single sign-on as an appropriate solution. It is also appropriate where on-premises account states, password policies, and logon hours must be enforced. You’ll learn more about configuring pass-through authentication with single sign-on in Chapter 2, “Manage User Identity and Roles”.

Federated authentication

Federated authentication is an alternative to cloud authentication, although it’s often substantially more complicated to configure and maintain. Most organizations use Azure AD Connect to synchronize identity information between on-premises Active Directory Domain Services and Azure AD. Organizations that want to allow additional authentication options, such as smart-card based authentication, or third-party multi-factor authentication such as an RSA token device.

Federated Identity with Active Directory Federation Services

When you use federated identity with Active Directory Federation Services (AD FS), you deploy servers hosting the AD FS role on your organization’s on-premises network and perimeter network. You then will need to configure federation between your on-premises AD FS instance and Azure AD. When you implement this identity and authentication technology, users use the same authentication options to access M365 and O365 resources as they do on-premises resources. This authentication method is generally chosen by organizations that have authentication requirements that are not natively supported by Azure AD.

Third-Party Authentication and Identity Providers

Organizations that use a non-active Directory on-premises identity provider can integrate that identity provider with Azure AD through federation as long as that third party identity provider’s federation solution is compatible with Azure AD. When this solution is implemented, users are able to access M365 and O365 resources using their on-premises identity provider username and password.