<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Entra-Id-Premium-(Aad-Premium) on Ru Campbell MVP</title>
    <link>https://campbell.scot/tags/entra-id-premium-aad-premium/</link>
    <description>Recent content in Entra-Id-Premium-(Aad-Premium) on Ru Campbell MVP</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <lastBuildDate>Wed, 07 Feb 2024 17:54:59 +0000</lastBuildDate>
    <atom:link href="https://campbell.scot/tags/entra-id-premium-aad-premium/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Entra ID Protection - Common Microsoft 365 Security Mistakes Series</title>
      <link>https://campbell.scot/entra-id-protection-common-microsoft-365-security-mistakes-series/</link>
      <pubDate>Wed, 07 Feb 2024 17:54:59 +0000</pubDate>
      <guid>https://campbell.scot/entra-id-protection-common-microsoft-365-security-mistakes-series/</guid>
      <description>&lt;p&gt;Signals from across Microsoft&amp;rsquo;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&amp;rsquo;s detections are limited to the Entra ID P2 license: the nonpremium risks listed &lt;a href=&#34;https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#sign-in-risk-detections&#34;&gt;here&lt;/a&gt; don&amp;rsquo;t require P2.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Privileged Identity Management (PIM) – Common Microsoft 365 Security Mistakes Series</title>
      <link>https://campbell.scot/pim-common-microsoft-365-security-mistakes-series/</link>
      <pubDate>Sun, 19 Nov 2023 14:01:41 +0000</pubDate>
      <guid>https://campbell.scot/pim-common-microsoft-365-security-mistakes-series/</guid>
      <description>&lt;p&gt;Entra ID&amp;rsquo;s P2 license (previously Azure AD Premium P2) unlocks the Privileged Identity Management (PIM). PIM is part of broader &lt;em&gt;identity governance&lt;/em&gt; features, and is most known for enabling just-in-time admin rights. For example, you are &lt;em&gt;eligible&lt;/em&gt; to become an administrator for a maximum of &lt;em&gt;X&lt;/em&gt; hours, at which point the permissions expire and you need to reactivate.&lt;/p&gt;
&lt;p&gt;This blog covers five of the common misconfigurations and misunderstandings I see with customers. Intuitive as PIM may appear, there are some gotchas you need to be aware of. It is a follow up from my previous &lt;a href=&#34;https://campbell.scot/conditional-access-common-microsoft-365-security-mistakes-series/&#34;&gt;Conditional Access – Common Microsoft 365 Security Mistakes Series&lt;/a&gt; article.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troubleshooting Hybrid Azure AD Intune Automatic Enrollment</title>
      <link>https://campbell.scot/troubleshooting-hybrid-azure-ad-intune-automatic-enrollment/</link>
      <pubDate>Mon, 19 Apr 2021 20:02:44 +0000</pubDate>
      <guid>https://campbell.scot/troubleshooting-hybrid-azure-ad-intune-automatic-enrollment/</guid>
      <description>&lt;p&gt;As I have blogged about &lt;a href=&#34;https://campbell.scot/hybrid-azure-ad-join-intune-enrollment-prerequisites-checklist-and-process-flow/&#34;&gt;a&lt;/a&gt;&lt;a href=&#34;https://petri.com/how-to-automatically-hybrid-azure-ad-join-and-intune-enroll-pcs&#34;&gt;lot&lt;/a&gt;, there are a bunch of hoops to be jumped through and prerequisites to be met for a successful hybrid Azure AD join and automatic, GPO-invoked Intune enrollment. But sometimes, you have to go back to the basics when you&amp;rsquo;re banging your head off the table, and laugh off the embarrassment of not checking the fundamentals.&lt;/p&gt;
&lt;p&gt;I was recently setting up hybrid Azure AD join and Intune enrollment, as I&amp;rsquo;ve done hundreds of times before, but this time I was hitting a strange problem.  Hybrid Azure AD join went fine, but for the Intune MDM enrollment, I was getting nowhere.  Devices showed in the Azure AD admin centre, but never showed an MDM, and therefore never showed in Endpoint Manager.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Conditional Access: Skip MFA for Company Devices on the Company Network</title>
      <link>https://campbell.scot/conditional-access-skip-mfa-for-company-devices-on-the-company-network/</link>
      <pubDate>Wed, 31 Mar 2021 07:13:29 +0000</pubDate>
      <guid>https://campbell.scot/conditional-access-skip-mfa-for-company-devices-on-the-company-network/</guid>
      <description>&lt;p&gt;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&amp;rsquo;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 &lt;em&gt;regardless&lt;/em&gt; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Turn Existing Azure AD Devices into Windows Autopilot Devices</title>
      <link>https://campbell.scot/turn-existing-azure-ad-devices-into-autopilot-devices/</link>
      <pubDate>Sat, 06 Feb 2021 09:19:13 +0000</pubDate>
      <guid>https://campbell.scot/turn-existing-azure-ad-devices-into-autopilot-devices/</guid>
      <description>&lt;p&gt;To provision Windows 10 PCs using Autopilot and Intune, they must first be registered as &lt;strong&gt;Windows Autopilot devices&lt;/strong&gt; in the &lt;strong&gt;Device Directory Service&lt;/strong&gt;, which is really the cloud Autopilot service.  When a device is registered to the Autopilot service, its &lt;strong&gt;hardware hash&lt;/strong&gt; is used to generate a &lt;strong&gt;Zero Touch Device ID&lt;/strong&gt;(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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Understanding Modern vs. Legacy Authentication in Microsoft 365</title>
      <link>https://campbell.scot/understanding-modern-vs-legacy-authentication-in-microsoft-365/</link>
      <pubDate>Sun, 24 Jan 2021 13:46:35 +0000</pubDate>
      <guid>https://campbell.scot/understanding-modern-vs-legacy-authentication-in-microsoft-365/</guid>
      <description>&lt;p&gt;Since October 2019, Microsoft has enabled Security Defaults by default in new Microsoft 365 tenants.  Security Defaults are a group of best-practice security settings, and one of note is the disablement of all &lt;strong&gt;legacy authentication&lt;/strong&gt;, which itself has been off in Exchange Online and SharePoint Online, by default, since August 2017.&lt;/p&gt;
&lt;p&gt;The term legacy authentication doesn&amp;rsquo;t refer to one particular protocol, but rather any that do not support Multi-Factor Authentication (MFA).  Protocols that support MFA are described as &lt;strong&gt;modern authentication&lt;/strong&gt;.  In the context of Microsoft 365 and Azure Active Directory, which handles Microsoft 365&amp;rsquo;s authentication, these are protocols such as ADAL and OAuth.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Difference Between Cloud App Security Discovery (CAD), Office 365 Cloud App Security (OCAS), and Microsoft Cloud App Security (MCAS)</title>
      <link>https://campbell.scot/the-difference-between-cloud-app-security-discovery-cad-office-365-cloud-app-security-ocas-and-microsoft-cloud-app-security-mcas/</link>
      <pubDate>Mon, 07 Sep 2020 19:15:17 +0000</pubDate>
      <guid>https://campbell.scot/the-difference-between-cloud-app-security-discovery-cad-office-365-cloud-app-security-ocas-and-microsoft-cloud-app-security-mcas/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Microsoft Cloud App Security&lt;/strong&gt; (MCAS), Redmond&amp;rsquo;s cloud app security broker (CASB) offering, is a powerful tool for investigating and pro-actively controlling your SaaS estate.  It includes tools such as reverse proxying to control sessions and sits inside the &lt;strong&gt;Microsoft Threat Protection&lt;/strong&gt; stack alongside Defender ATP, Office 365 ATP, and Azure ATP.  MCAS started life as Adallom prior to Microsoft&amp;rsquo;s acquisition of that company in 2015.  It&amp;rsquo;s included in Microsoft 365 E5 and numerous other licensing subsets, including EMS E5, E5 Security (an add-on for Microsoft 365 E3), Information Protection &amp;amp; Governance, or standalone.  In all cases, you&amp;rsquo;d need to make sure it includes or you also get a license for Azure AD Premium for the reverse proxy benefits, delivered via &lt;strong&gt;Conditional Access App Control&lt;/strong&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Getting Started with Azure AD Identity Governance – Part 3: Privileged Identity Management (PIM)</title>
      <link>https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-3-privileged-identity-management-pim/</link>
      <pubDate>Sun, 16 Aug 2020 14:13:09 +0000</pubDate>
      <guid>https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-3-privileged-identity-management-pim/</guid>
      <description>&lt;p&gt;This blog is the last in a small series on Azure AD Premium P2&amp;rsquo;s Identity Governance toolkit.&lt;/p&gt;
&lt;blockquote&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-1-entitlement-management/&#34;&gt;Part 1: Entitlement Management&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-2-access-reviews/&#34;&gt;Part 2: Access Reviews&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-3-privileged-identity-management-pim/&#34;&gt;Part 3: Privileged Identity Management (PIM) (this post)&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/blockquote&gt;
&lt;p&gt;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&amp;rsquo;s less of a requirement - PIM makes admin rights time bound on the same account and optionally require approval to activate.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Getting Started with Azure AD Identity Governance – Part 2: Access Reviews</title>
      <link>https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-2-access-reviews/</link>
      <pubDate>Sun, 02 Aug 2020 14:46:34 +0000</pubDate>
      <guid>https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-2-access-reviews/</guid>
      <description>&lt;p&gt;This blog is the second in a small series on Azure AD Premium P2&amp;rsquo;s Identity Governance toolkit.&lt;/p&gt;
&lt;blockquote&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-1-entitlement-management/&#34;&gt;Part 1: Entitlement Management&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-2-access-reviews/&#34;&gt;Part 2: Access Reviews (this post)&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-3-privileged-identity-management-pim/&#34;&gt;Part 3: Privileged Identity Management (PIM)&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/blockquote&gt;
&lt;p&gt;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 &amp;lsquo;self-service&amp;rsquo;, 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).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Getting Started with Azure AD Identity Governance - Part 1: Entitlement Management</title>
      <link>https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-1-entitlement-management/</link>
      <pubDate>Sun, 26 Jul 2020 17:27:32 +0000</pubDate>
      <guid>https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-1-entitlement-management/</guid>
      <description>&lt;p&gt;This blog is the first in a small series on Azure AD Premium P2&amp;rsquo;s Identity Governance toolkit.&lt;/p&gt;
&lt;blockquote&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-1-entitlement-management/&#34;&gt;Part 1: Entitlement Management (this post)&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-2-access-reviews/&#34;&gt;Part 2: Access reviews&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://campbell.scot/getting-started-with-azure-ad-identity-governance-part-3-privileged-identity-management-pim/&#34;&gt;Part 3: Privileged Identity Management (PIM)&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/blockquote&gt;
&lt;p&gt;Azure AD entitlement management is a bit of an overlooked gem.  It&amp;rsquo;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&amp;rsquo;s access is time-controlled so that as their role changes, their access does too.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
