<?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>Mfa on Ru Campbell MVP</title>
    <link>https://campbell.scot/tags/mfa/</link>
    <description>Recent content in Mfa on Ru Campbell MVP</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <lastBuildDate>Wed, 31 Mar 2021 07:13:29 +0000</lastBuildDate>
    <atom:link href="https://campbell.scot/tags/mfa/index.xml" rel="self" type="application/rss+xml" />
    <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>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>
  </channel>
</rss>
