Ems on Ru Campbell MVP

Entra ID Protection - Common Microsoft 365 Security Mistakes Series

Wed, 07 Feb 2024 17:54:59 +0000

Signals from across Microsoft’s services and ecosystems inform Entra ID Protection to detect risk. The risk detections can alert administrators or, better still, combine with other Entra and Defender XDR capabilities to perform remediation and prevention. The most obvious example of this may be preventing a risky sign in. Contrary to popular understanding, not all of Entra ID Protection’s detections are limited to the Entra ID P2 license: the nonpremium risks listed here don’t require P2.

Three Cool Things To Do With Azure Information Protection

Sun, 13 Jun 2021 17:38:11 +0000

In my last blog, I wrote about three considerations for your Azure Information Protection deployments and commented on often overlooked potential downsides, or at least areas with which to be cautious. In hindsight, it all feels a bit negative. I am, for the record, an advocate of Microsoft 365 customers using AIP (sensitivity labels) in basically any circumstance it’s appropriate to do so. So in this blog, I’ll counter the earlier post with three often overlooked useful things you can do with it.

Conditional Access: Skip MFA for Company Devices on the Company Network

Wed, 31 Mar 2021 07:13:29 +0000

A common Conditional Access policy is to add trusted locations as an exception to multi-factor authorisation requirements. The logic goes, if you accessing resources such as Office 365 from a location such as the corporate office, that’s an element of verification in itself that your login should be trusted, so we should improve your user experience by removing MFA. Personally, I support the use of MFA regardless of where you are authenticating (at the very least, if you have an Azure AD admin role assigned). However, doing something like this is a great option if you are introducing MFA from scratch: you will improve user buy in the less you change their standard experience. Then, increase the scope gradually.

Microsoft Information Protection Sensitivity Labels - Custom User Permissions and Do Not Forward

Thu, 25 Feb 2021 15:02:30 +0000

With Microsoft Information Protection, you can apply sensitivity labels to files, emails, and containers such as SharePoint Libraries. These labels apply protection which, in the context of files and emails, really means encryption using AES-128 or 256 (key size depends on file type). The great thing about Information Protection is that you control an access control list of who is allowed to access the content and it’s managed as a cloud service by Microsoft. The document or message, when opened, checks who is authenticated (who is signed to Outlook or the Office 365 app, for example) and only allows access if they have permission.

Turn Existing Azure AD Devices into Windows Autopilot Devices

Sat, 06 Feb 2021 09:19:13 +0000

To provision Windows 10 PCs using Autopilot and Intune, they must first be registered as Windows Autopilot devices in the Device Directory Service, which is really the cloud Autopilot service. When a device is registered to the Autopilot service, its hardware hash is used to generate a Zero Touch Device ID(ZTDID) - a globally unique identifier for that device based on hardware information such as (but not only) MAC address, disk serial number, and system serial number.

Store BitLocker Recovery Keys in Azure AD for Devices Already Encrypted

Fri, 15 Jan 2021 18:18:36 +0000

As you move from on-premises or third-party infrastructure to Microsoft 365 and Azure AD, you will want to keep those BitLocker recovery keys safe. You can store those keys either in on-premises Active Directory or in the cloud with Azure AD.

The behavior of the BitLocker / Azure AD relationship is that the recovery keys will only be stored against the device object in Azure AD if the encryption happens when the device is already Azure AD or Hybrid Azure AD Joined. You can then retrieve the recovery keys from the Azure AD portal or Microsoft Endpoint Manager (which really just takes you back to Azure AD’s properties for the device).

Getting Started with Azure AD Identity Governance – Part 3: Privileged Identity Management (PIM)

Sun, 16 Aug 2020 14:13:09 +0000

This blog is the last in a small series on Azure AD Premium P2’s Identity Governance toolkit.

Part 1: Entitlement Management

Part 2: Access Reviews

Part 3: Privileged Identity Management (PIM) (this post)

PIM is an Azure AD P2 feature that enables just-in-time (JIT) admin rights in Azure and Azure AD. Historically, best practice has been for users to have a separate account for admin tasks, as protection against the primary account if breached. While this is still supported under PIM, it’s less of a requirement - PIM makes admin rights time bound on the same account and optionally require approval to activate.

Getting Started with Azure AD Identity Governance – Part 2: Access Reviews

Sun, 02 Aug 2020 14:46:34 +0000

This blog is the second in a small series on Azure AD Premium P2’s Identity Governance toolkit.

Part 1: Entitlement Management

Part 2: Access Reviews (this post)

Part 3: Privileged Identity Management (PIM)

Historically, the apps, groups, and rights a user had were all under central and constant management by IT. Azure AD and modern management have pushed this towards ‘self-service’, including guest users, which improves productivity. The goal of Azure AD access reviews is to improve the management of user rights and access, in this modern environment, throughout their lifecycle in your tenant. It empowers you with automated tools to control their groups, apps, and roles (admin rights).

Getting Started with Azure AD Identity Governance - Part 1: Entitlement Management

Sun, 26 Jul 2020 17:27:32 +0000

This blog is the first in a small series on Azure AD Premium P2’s Identity Governance toolkit.

Part 1: Entitlement Management (this post)

Part 2: Access reviews

Part 3: Privileged Identity Management (PIM)

Azure AD entitlement management is a bit of an overlooked gem. It’s a feature that automates the processes for giving users access to resources. The typical scenario is a user has just joined a new department or is a new employee. Over time, the resources their team need access to have sprawled across the M365 estate and it would be laborious to give permission to them all manually - if you even remember them all. Additionally, you want to ensure the user’s access is time-controlled so that as their role changes, their access does too.