Endpoints
Endpoints play an important role throughout the entire Microsoft 365 security conversation. Microsoft 365 allows services to be accessed from a myriad of clients and device types, such as web, desktop, and mobile devices. As an administrator, you should plan which devices users will be allowed to access Microsoft 365 services from, whether devices will be managed, and which protection controls, such as Windows 10 security features, are configured on those devices.
From a zero-trust perspective, it’s important to verify that the devices accessing data are allowed and accessing it under the correct circumstances.
You will explore the following concepts for devices:
- Device access
- Device management
- Device protection
Device Access
Managing device access for Microsoft 365 is the key to ensuring that only known devices can access the service or store company data. Two main strategies are used to control device access for Microsoft 365:
- Network restriction: Microsoft 365 services can only be accessed from authorized network locations. For example, managed devices reside inside the organization’s perimeter. This scenario is enforced in the service during the authentication and authorization phase, where users identify themselves and their locations before being granted access to services.
- Conditional Access: Services can only be accessed when conditions, such as group membership, device compliance, network region, or MFA, are satisfied.
A network restriction can be implemented with one or more of the following four features:
- Conditional Access: As mentioned previously, Conditional Access interrogates devices accessing the service for their IP address information and then grants or denies access based on that (among other conditions). Microsoft recommends configuring Conditional Access as the best way to manage device and application access.
- AD Federation Services (AD FS) claims rules: In an identity federation scenario, claims are information about users that is exchanged between different Identity Providers (IdPs), such as between a local AD and AAD. In this case, claims rules allow administrators to configure conditions that must be satisfied to enable authorization. Organizations frequently use AD FS claims rules to limit access to services based on IP addresses.
AD FS claims rules for Microsoft 365 services do not work effectively for geofencing purposes. In most Microsoft 365 application scenarios, users attempting to access the Microsoft 365 service from their device are redirected to the on-premises environment. The result is that the client IP address presented to AD FS is from the Microsoft 365 service and not the originating client device.
- Exchange Online client access rules: Administrators can configure conditions to authorize access to EXO services. Among the services that administrators can configure EXO client access rules for are the Exchange Admin Center (EAC), PowerShell, Exchange ActiveSync, and Exchange Web Services (EWS).
- OneDrive for Business (ODFB) and SharePoint Online device access: Administrators can configure the network users who are authorized to access OneDrive and SharePoint content. This setting also applies to external users and administrator access, so it is recommended to think things through before the settings are rolled out for users. It affects all services that use SharePoint (such as OneDrive, SPO, and Microsoft Teams). Misconfiguring the allowed networks will prevent users from accessing the service. This issue will require a phone call to Microsoft Support.
Figure 7.11 shows the device access control configuration options in the SharePoint admin center:

Figure 7.11 – Device access controls in the SharePoint admin center
Conditional Access provides the most granular control for defining conditions, restrictions, and other actions. The most flexible (and preferred) approach for controlling authorized locations is to create Conditional Access policies. Figure 7.12 shows the high-level components and an operational overview of a Conditional Access policy:

Figure 7.12 – Conditional Access overview
The core conditions for building a Conditional Access policy are set out as follows:
- Users and groups
- Sign-in risk
- Device platform
- Location
- Client apps
- Device state
Following validation, administrators can configure actions such as the following:
- Blocking access
- Granting access, but requiring MFA
- Granting access, but requiring a device to be compliant with Intune requirements
- Enforcing limited session usage, such as preventing users from opening SharePoint documents locally
As part of testing a Conditional Access policy, administrators can simulate a set of conditions, such as user and location, to understand which policy should be set up and what would happen as a result of this policy being implemented.
In the next section, you’ll look into device management.