Requirements

Before we go into the details on how to set this up, we first need to ensure that we have everything in place so everything works as expected. Here’s what is needed.

• Azure AD P1 or P2 license for conditional access
• Security Administrator, Conditional Access Administrator or Global Administrator
• SharePoint Administrator or Global Administrator
• Exchange Administrator or Global Administrator
• Microsoft.Online.SharePoint.PowerShell PowerShell Module
• ExchangeOnlineManagement PowerShell Module

To touch a bit on these requirements, we need to ensure we have an Azure AD P1 or P2 license so we can have access to use conditional access policies. This is going to be the foundation of what we’re going to use to either limit or block unmanaged devices from accessing anything in the cloud. Also as of today, Security Administrator, Conditional Access Administrator or Global Administrator are the only roles that are able to modify CA policies. So we will need at least one of those.
 

Exchange Administrator and SharePoint Administrators are needed to be able to set the respective platform policies to limited access. A bit more on that later.

What Classifies as an Unmanaged Device

An unmanaged device is typically a device that is not issued by your organization. It is often synonymous with BYOD (Bring Your Own Device) and can be anything from a personal computer or phone to a machine that you use to access emails while at grandma’s house. The point here is that it doesn’t have any policies and it is not properly governed by the IT department.
 

Limit Browser Access on Unmanaged Devices for M365 Apps

If you don’t want to put a full stop on users accessing M365 resources, you do have the ability to limit what they can do while signed in from an unmanaged device. Simply put, we can enforce policies so users can still sign in using the web only methods, however, they will be blocked from downloading anything to the local machine.
 

For most, this is a great happy medium because it still keeps your data secure to a certain extent and users can access their documents if they don’t have their company issued device around.
 

This is in fact a two-step process so we’ll target SharePoint/OneDrive and Exchange Online now. Then we will finish it off with the CA Policies.

Limited Browser Access for SharePoint Online

If you want to take this in incremental steps you definitely can. Being able to set limited access on specific sites is supported so it’s definitely recommended you take that approach first. In my opinion it will be a good test to set limited access on a few SharePoint sites as well as a few OneDrive sites.
 

Let’s connect to SharePoint Online using the Microsoft.Online.SharePoint.PowerShell PowerShell Module.

Import-Module Microsoft.Online.SharePoint.PowerShell -WarningAction SilentlyContinue
$adminURL = 'https://<tenantname>-admin.sharepoint.com'
Connect-SPOService -Url $adminURL -WarningAction SilentlyContinue

Apply on a Per-Site Basis

Next, let’s take a look at the conditional access property within the Get-SPOSite cmdlet. This is what we’ll use to be able to limit access on specific SharePoint (or OneDrive) sites before we deploy this on the tenant level. By default, this should be set to allow full access. Meaning anyone can access this SharePoint site from anywhere and there wouldn’t be any restrictions in place.

With that out of the way, let’s change the access to allow limited, web only access for this site as well as a OneDrive site. To accomplish this we’re going to use the Set-SPOSite cmdlet along with the -ConditionalAccessPolicy Parameter.
 

This parameter supports the following inputs:

• AllowFullAccess: Allows full access from desktop apps, mobile apps, and the web
• AllowLimitedAccess: Allows limited, web-only access
• BlockAccess: Blocks Access
• AuthenticationContext: Assign an Azure AD authentication context. Must add the AuthenticationContextName

$SiteURL = 'https://thesysadminchannel.sharepoint.com/sites/someproject'
$OneDriveURL = 'https://thesysadminchannel-my.sharepoint.com/personal/buzz_thesysadminchannel_com'

Set-SPOSite -Identity $SiteURL -ConditionalAccessPolicy AllowLimitedAccess
Set-SPOSite -Identity $OneDriveURL -ConditionalAccessPolicy AllowLimitedAccess

$SiteURL, $OneDriveURL | ForEach-Object {Get-SPOSite -Identity $_ | select Title, ConditionalAccessPolicy}

Title          ConditionalAccessPolicy
-----          -----------------------
SomeProject         AllowLimitedAccess
Buzz Lightyear      AllowLimitedAccess

Before you start checking the sites you set the limited access on, note that nothing is limited until we configure the CA policies. It is strongly recommended that you do thorough testing before enabling this at the tenant level. Once you’ve done that and you’re ready to set it as the default, you can do that with another cmdlet. That cmdlet is Set-SPOTenant
 

Apply at the Tenant Level

Now that you’re ready to enable this as the default on the tenant level, there is one thing we need to decide on. That one thing is whether we want to enforce these restrictions on adhoc recipients. What exactly does that mean you say?
 

When the feature is enabled, all external users are going to be in scope of the restrictions and users who are accessing SharePoint Online files with a pass code are going to be blocked.
 

Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess -ApplyAppEnforcedRestrictionsToAdHocRecipients: $false

When completed, we can also check the SharePoint Admin center to see the same thing.

 

Finally, since doing this will automatically create a conditional access policy on our behalf, I would recommend disabling that and crafting one by hand so we can fine tune it to our liking.

Limited Browser Access for Exchange Online

Much like the SharePoint Online scenario, we can also limit browser access for users who are trying to access their email when on an unmanaged device. This setting is done using the OwaMailboxPolicy and is configurable for specific mailboxes or at the tenant level. Before we take a look at each one, we need to connect to Exchange Online via PowerShell.

Connect-ExchangeOnline -UserPrincipalName user@domain.com -ShowBanner: $false

Apply on a Per-Mailbox Basis

Again, it’s always a great idea to test on a few people to ensure you’re able to get the results you want. There’s nothing worse than enabling a policy and having to revert back because of incidents that could have very well been avoided if it was properly tested.
 

To set the limited access on a few mailboxes we’re going to need to create a new OwaMailboxPolicy and then set the same conditional access parameter to readonly.
 
In case you’re interested, here is what the supported inputs are for that parameter:

• Off: No conditional access policy is applied to Outlook on the web. This is the default value
• ReadOnly: Users can’t download attachments to their local computer, and can’t enable Offline Mode on non-compliant computers. They can still view attachments in the browser
• ReadOnlyPlusAttachmentsBlocked: All restrictions from ReadOnly apply, but users can’t view attachments in the browser

$OwaPolicy = New-OwaMailboxPolicy -Name LimitAccess
Set-OwaMailboxPolicy -Identity LimitAccess -ConditionalAccessPolicy ReadOnly
Get-OwaMailboxPolicy | select Name, IsDefault, ConditionalAccessPolicy

Name                     IsDefault ConditionalAccessPolicy
----                     --------- -----------------------
OwaMailboxPolicy-Default      True Off
LimitAccess                  False ReadOnly

With the OwaMailboxPolicy now created, let’s apply that policy to a few users so we can do our testing. To apply we will use the Set-CASMailbox cmdlet.

Set-CASMailbox darth -OwaMailboxPolicy LimitAccess
Get-CASMailbox darth | select DisplayName, OwaMailboxPolicy

DisplayName OwaMailboxPolicy
----------- ----------------
Darth Vader LimitAccess

Apply at the Tenant Level

After we’ve tested for a bit, we can now apply this as the default setting at the tenant level. To accomplish this, we will use the Set-OwaMailboxPolicy and and modify the “OwaMailboxPolicy-Default” to use the readonly conditional access policy.
 

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -ConditionalAccessPolicy ReadOnly
Get-OwaMailboxPolicy | select Name, IsDefault, ConditionalAccessPolicy

Name                     IsDefault ConditionalAccessPolicy
----                     --------- -----------------------
OwaMailboxPolicy-Default      True ReadOnly
LimitAccess                  False ReadOnly

Block Unmanaged Devices Using Conditional Access

If you’re wondering why nothing has changed after setting the SharePoint or Exchange settings, it’s because your conditional access policies are the tools that are going to be enforcing these restrictions. The platform settings are the underlying scoping policies, however the conditional access policies are the overlying restriction setting. Since we ended up setting both platform restrictions at the tenant level, the users we add (and ONLY those users) in the conditional access policy should have this setting enforced. Hopefully that clears up any confusion.
 

Similar to the default SharePoint policies that were automatically created, there are 2 policies we need to create so we can block unmanaged devices as well as restrict browser access if they’re not on an IT issued device. We can use those as rough templates to get us started.
 

Within Azure AD:

• Navigate to Security → Conditional Access → Policies → New Policy
• Direct Link: Conditional Access Blade
• Name: CA015: Block Unmanaged Devices for All Users
• Under Users:
• Include: All Users (or smaller groups for testing)
• Exclude: Break glass account, MFA exclude group and all Guest users



• Under Target Resources:
• Include: All Cloud Apps (or M365 Apps for testing)
• Exclude: None



• Under Conditions: No Changes needed (or exclude iOS and Android Devices for testing)
• Under Grant:
• Require device to be marked as compliant: Checked
• Require Hybrid Microsoft Entra joined device: Checked
• Require one of the selected controls: Is selected



• Under Sessions: No Changes needed

Restrict Browser Access on Unmanaged Devices Using Conditional Access

Earlier we setup the policies on Exchange Online and SharePoint to be able to limit browser access while using an unmanaged device. The policy on that platform is set, however, as mentioned earlier, we need to be able to enforce this using conditional access policies. Let’s do that now.
 

Within Azure AD:

• Navigate to Security → Conditional Access → Policies → New Policy
• Direct Link: Conditional Access Blade
• Name: CA016: Restrict Browser Access to Unmanaged Devices for All Users
• Under Users:
• Include: All Users (or smaller groups for testing)
• Exclude: Break glass account, MFA exclude group and all Guest users



• Under Target Resources:
• Include: Office 365
• Exclude: None



• Under Conditions:
• Client Apps → Browser: Checked



• Under Grant: No changes needed
• Under Sessions:
• Use app enforced restrictions: Checked

Incognito Mode and Browser Extensions

One important item to call out is that your users can continue to have issues even though their device is compliant or Hybrid Azure AD Joined. This is because certain browsers don’t have the functionality built-in to send the device payload so the CA policy can properly evaluate it.
 

• Edge: Functionality is built-in so testing with Edge is always recommended
• Chrome: Windows 10 accounts extension is required for Chrome v111+
• FireFox: FireFox Windows SSO is required
• Incognito Mode: extensions should be abled for incognito mode as well

If you’re STILL having issues after ensure your device is in the proper state and you have the proper extensions installed, one thing that I’ve learned is clear the cache and cookies and that resolves most of the issues.
 

Conclusion

Hopefully this article on how to limit or restrict browser access to Microsoft 365 apps as well as block unmanaged devices using conditional access was insightful. This should help add a bit more strength to your overall security posture so that’s always a good thing.
 

This policy is very powerful so you need to make sure you do some thorough testing before enabling the policy globally. Another policy I would highly recommend is to Enable Authentication Strengths Using Conditional Access so you can set higher profile apps to use phishing resistant MFA.

The post Block Unmanaged Devices Using Conditional Access appeared first on the Sysadmin Channel.

Requirements

If you’ve implemented MFA across the entire org or you’re just about to go down that path it is important to know there are tools and licenses you should have in place to make the experience a much better one. Let’s touch on those a bit now.
 

While Azure AD P2 licenses are preferred, having a P1 license will grant you access to conditional policies, Log Analytics and other Azure AD features. Technically all you need is a single P2 license to enable these features however, all users that are using the features should be licensed for it.

What NOT to do if Azure MFA Keeps Prompting

Before we go into detail on what MFA prompt frequency best practices are and what we can do suppress them, let’s take some time to discuss what we should NOT be doing. These “don’ts” are called out because of the security implications it can have on your AAD environment.
 

I see it time and time again when scrolling through Twitter, Reddit or other articles, people recommend whitelisting their office public IP addresses as a way to bypass MFA. After all, if you’re in a building that probably requires a badge to gain access, we should be good right? WRONG!
 

Tailgating does happen in the wild and if you set policies to bypass MFA for people in the office, you have effectively punched security holes into your environment. Aside from that, many office buildings have guest wi-fi networks for their visitors that someone can easily connect to. If the guest network is configured to use the same outbound public IP as the corporate network, you’ve just opened yourself up to a potential world of hurt. If that still doesn’t convince you, figuring out how to spoof a public IP address is just a Google search away so these methods should be avoided at all costs.
 

Another setting we want to avoid is to keep the “remember multi-factor authentication on trusted device” setting enabled in the legacy Azure service settings portal. While it does what it says and reduces the number of MFA prompts you will get, it is not the best approach for what we are trying to accomplish. Microsoft also calls this out on their documentation.

I should also mention that requiring an MFA prompt for every sign in, or otherwise purposely overly prompting for MFA can be just as bad. When someone is constantly getting prompted for MFA, they tend to become numb to the process and mindlessly hit approve. There are ways to mitigate MFA fatigue attacks by implementing MFA number matching but the point still stands. More MFA prompts does not equate to more security.
 

To summarize, here is what we should NOT be doing to reduce MFA prompts in Azure AD:

• Do NOT whitelist public IPs to bypass MFA
• Do NOT enable remember multi-factor authentication on trusted device
• Do NOT purposely over prompt for MFA

Authentication Prompts Analysis: See Whos Is Getting Prompted for MFA

Azure AD is a platform that can be used as a 100% cloud only solution for your users, or a hybrid solution if you’re still maintaining an On-Premises environment. With that said, it also comes equipped with its own audit logging and monitoring tools (when you have Azure AD P1/P2 licenses) so we can use Azure AD workbooks to get insights on who is actually getting prompted for MFA and what applications are prompting them.
 

Azure AD has done all of the hard work for you and conveniently created an authentication prompts analysis workbook.
To access it:

• Navigate to Azure AD → Workbooks
• Select Authentication Prompts Analysis workbook

If you have time I would highly suggest you take a look at the data. My only suggestion for the workbook would be that they remove “Windows Sign In” attempts since that can kind of skew the data. Windows Sign In is when a user signs in their Windows device so this will not require MFA. However, the workbook lays out several categories for prompts.

Those include:

• Authentication prompts by authentication method
• Authentication prompts by device
• Authentication prompts by user
• Authentication prompts by application
• Authentication prompts by process detail

How to Reduce MFA Prompts in Azure AD

Now that we’ve covered who is getting prompted for MFA and more importantly, what NOT to do, let’s focus on what we should be doing and the best practices for how to reduce MFA prompts in Azure AD. Remember, Azure AD is the Identity Provider (IdP) so this applies to all Azure AD cloud applications. If Office 365 MFA prompts every time, this will ensure the prompts are significantly lowered when implemented successfully.

Windows Hello for Business

If you’re looking for best practices to reduce MFA Prompts in Azure AD, Windows Hello for Business is by far the BEST way to securely accomplish this. With Windows Hello for Business enabled, you’re always using strong authentication and the MFA claims are satisfied automatically.
 

This is because when you sign in with WH4B, a Primary Refresh Token (PRT) gets generated at that initial sign in and is presented to all other Azure AD applications when they’re accessed. This allows for a truly seamless SSO experience and even better, it provides a fantastic user experience. If you’ve never heard of a PRT, I would highly suggest you take the time to learn more about Primary Refresh Tokens. The documentation for this is phenomenal.
 

Windows 10 Accounts Chrome extension

While Edge handles this capability natively in the browser, It strongly recommended that those hard chargers using Google Chrome have the Windows 10 Accounts Chrome extensions deployed on their machine. If you are NOT using Windows Hello for Business, you will need to MFA to that initial application which will create a PRT that can be used on any subsequent applications.
 

If you ARE using WH4B, you will still need to deploy this plugin because Chrome doesn’t natively support a Primary Refresh Token. As an optional step, you can enable this in incognito mode so users can continue to use their PRT while in private-mode. Again, Microsoft Edge handles this natively but this is good to know.
 

Finally, and probably more importantly, in order to successfully create PRT, the devices will need to be at a minimum Azure AD registered. Non registered devices will not be given a PRT so those devices will continue to be prompted.

Enterprise SSO for Apple Devices

We’ve covered what to do for Windows devices, but what is the recommendation for MacOS and iOS devices? After all, it is quite common to see an organization operate with a mix of Apple, Windows and Linux devices in their environment. The answer is Enterprise SSO for Apple devices. There a few requirements that are listed in the documentation so we’ll summarize that here.
 

An important item to note is if your primary MDM solution is not Microsoft Intune, you will need to deploy the SSO extension AND ensure your device is enrolled in Intune. It doesn’t have to be managed by Intune, but it must be enrolled so Azure can see the device.

Conclusion

Hopefully this article was able to provide useful insight on how to reduce the number of MFA prompts using secure best practices. Remember, the goal is to require strong authentication all the time, on every application. However, the trick is to use these methods listed above so MFA requirements are satisfied and you’re no longer being prompted.
 

I personally use Windows Hello for Business and I am prompted once every several months on my standard account because my MFA requirement is already satisfied by claim in the token.

The post Securely Reduce MFA Prompts in Azure AD appeared first on the Sysadmin Channel.

What is Authentication Strength?

Authentication strength is a Conditional Access control that enables administrators to specify what combination of authentication techniques can be used to access a cloud resource.
 

The Authentication methods policy, which allows administrators to specify the authentication methods to be used across Azure AD applications, forms the basis for authentication strength. Authentication strength enables further control over the application which can depend heavily on variables like access to sensitive resources, user risk, location, and more.
 

With this policy enabled, you can require access to high profile applications using ONLY MFA resistant methods like Windows Hello for Business or Fido 2. For all other applications or resources, you can set a policy to enable any one of the Passwordless methods available to you as an Azure AD user. With that said, let’s touch on the different authentication strength types and how they’ll be useful to your organization.

What types of Authentication Strengths are available?

When requiring MFA, it’s important to know that some methods are better than others. If your resource is located in Azure, there are several authentication strengths available to you with little configuration on your end. It’s all built-in to the product which is great.
 

Regarding the actual types, there are 3 main buckets

• Password + MFA (Good)
• Passwordless MFA (Better)
• Phishing Resistant MFA (Best)

Here is a table provided by Microsoft that outlines all of the possible types and what bucket they fall into.

Requirements

In order to enable authentication strengths, we need check a few boxes to make that happen. Let’s cover the requirements needed to ensure you’re on a road to success.
 

• Azure AD P1/P2 License
• Authentication Policy Administrator or Global Administrator
• Authentication Methods Policy configured
• Enable combined registration

Enable Authentication Strengths

By default Microsoft gives us 3 types of authentication strength policies right out of the box so we can hit the ground running.

Those built-in policies are:

• Multi-factor authentication
• Passwordless MFA
• Phishing-resistant MFA

It’s pretty neat that the 3 built in policies are exactly the same as the three buckets we mentioned above. That’s great but what if we wanted to create a custom authentication strength to only allow a specific requirement for a specific Azure resource? Let’s look at creating a custom authentication strength policy.
 

Within Azure AD:

• Navigate to Security → Authentication Methods → Authentication Strengths
• Direct Link: https://portal.azure.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AuthStrengths
• Click on New Authentication Strength
• Enter in Name and Description
• With the chevrons expanded, select the specific authentication strength you’re looking to add

• Follow the prompts to create the policy
• My custom policy will only allow Windows Hello or Fido 2 to be used

 
Once I hit create, we can see that my policy is created. However, you’ll notice that it is showing “Not configured in any policy yet” under the conditional access policies column.

 

Let’s move forward to see how we can configure the conditional access policy.

Configure the Conditional Access Policy

Now that we have our custom authentication strength created, let’s look at how to apply that for a specific set of users and/or applications. Conditional access policies can have a wide variety of controls you want to put in place, however, for this article we’ll apply it to a user on a specific app.
 

Within Azure AD:

• Navigate to Security → Conditional Access → Create a new policy
• Give the policy a relevant name
• Under Users: select the users/groups you want in scope of this policy
• Under Cloud apps: select the apps you want in scope of this policy
• Under Grant:
• Ensure the Grant access radio button is selected
• Select Require authentication strength checkbox
• Select the authentication strength you just created (Ours will be Fido 2 or Windows Hello)
• Select require all the selected controls
• Leave the policy in report only mode until you’re ready to enable it

User Experience

From a user’s perspective, there are 2 scenarios we need to keep in mind when enforcing an authentication strength through a conditional access policy.

• Scenario 1: The user does NOT have the authentication strength registered
• Scenario 2: The user does have the authentication method registered

Let’s drill down and cover both scenarios so you know exactly what to expect for each. The second scenario is the end goal so we’ll start with users who have not registered the required authentication strength first.
 

The user does NOT have the authentication strength registered

If a user is in scope of a policy that requires an authentication strength and they have not registered it, what does that look like?
 

My new authentication strength CA policy was only scoped to a single user going to Office 365. This user does not have Fido 2 or Windows Hello registered on their account so here’s what that looks like when I hit that endpoint.
 

First, I am prompted to authenticate using my normal method, then I get a notice saying the following.

Keep your account secure
Your organization requires you to set up the following methods of proving who you are.
To complete this sign-in, you need to use one of the methods listed below, but you cannot register those methods here. Please contact your administrator to register one or more of these methods and then try signing into this application again.

Authentication Methods:
Your Required Authentication

 

From here, the user will need to navigate to https://aka.ms/mysecurityinfo, follow the prompts and add the required method. You can reference this MS Doc to register a Fido 2 Security Key.

The user does have the authentication method registered

Moving on to the second scenario. If a user is already registered for their required auth strength, let’s take a peek of what that will look like from a user’s perspective.
 

If you’re signing in to a new session, you will need to successfully authenticate using the most recent authentication method used. Azure will then determine if the conditions of the policy apply and if it does, you’ll be prompted to verify the identity using the required auth strength. In my case, I’m required to use Fido 2.

Known Limitations

Before we go all gung ho and start enforcing everything using specific authentication strengths, it is important to know the limitations and how it can impact your users. If you’re running a predominantly Windows environment, there’s a much better chance you’ll have success because there are more things that are vertically integrated.
 

However, this is not the case for environments that have a mix of MacOS, Linux and Windows. Obviously since Windows Hello is a Windows feature, this will not work on other platforms so I guess that goes without saying. We also need to understand that Fido 2 doesn’t work with Safari so MacOS users will need to use Chrome if they need to Fido into any application. I’ve personally run into issues where some applications on MacOS just won’t work when requiring a security key because Apple hasn’t fully integrated this into their product yet.
 

Another thing to consider is that there are currently issues if you want to enforce Passwordless as a baseline policy. If you apply a policy enforcing Passwordless to a user who currently doesn’t have it enabled, they’ll get an infinite loop. Before you enforce this policy, be sure the users have this enabled so you can save yourself from trouble down the road.

Conclusion

At last we’re at the tail end of this article and hopefully you found it very informative knowing how to enable authentication strengths using Azure AD conditional access policies. This is something that can definitely improve your organizational security as well as add the convenience of Passwordless.
 

This feature is still in preview so there is still more work needed to iron out the rough edges but at the end of the day, this is still a win for admins who want a stronger security posture across their cloud environment.

The post How To Enable Authentication Strengths Using Azure AD Conditional Access Policy appeared first on the Sysadmin Channel.

What is Windows Hello for Business

So what exactly is Windows Hello for Business and why should we enable it as an organization? WH4B removes the need for traditional username and passwords (in most cases) and uses device based authentication with gestures. Biometric, fingerprint, facial recognition or PIN are all examples of useable gestures that are supported with this feature.
 

With Windows Hello enabled, your users can seamlessly authenticate to cloud resources AND satisfy any MFA requirements since this is a strong auth credential. This credential is tied to the device and uses a gesture to verify the identity. Once the identify has been verified, it creates what is known as a Primary Refresh Token (PRT) to seamlessly sign in to cloud resources.

How To Enable Windows Hello for Business Cloud Trust

In the past, there were some hurdles trying to get WH4B enabled for hybrid environments simply because it required a Public Key Infrastructure (PKI) to initially get the ball rolling.
 

Many organizations don’t have this setup in their environment so Microsoft released the latest evolution for this feature which is called Cloud Trust. Cloud Trust doesn’t require a PKI infrastructure and it doesn’t need any certificates deployed to machines or domain controllers. What does it need? Let’s touch on that right now.

Requirements

There are requirements for the infrastructure as well as the client. Both sets of requirements must be fulfilled to ensure this is working successfully.
 

Infrastructure Requirements:

• AzureADHybridAuthenticationManagement PowerShell Module
• Several fully patched Windows Server 2016 or later Domain Controllers
• A Domain Admin to create the Azure AD Kerberos Server object
• A Global Admin to authenticate to the Azure tenant

Client Requirements:

• Fully patched Windows 10 21H2 or later devices
• Devices are Hybrid Azure AD Joined
• Managed via Group Policy or Microsoft Intune (this article focuses on deploying via GPO)
• The user must be enrolled in MFA

Creating the Azure AD Kerberos Server

As part of the infrastructure requirements, we’ll need to install/use the AzureADHybridAuthenticationManagement PowerShell module. This module has the specific cmdlets needed to create the Azure AD Kerberos server for your on-premises domain.

#Install Powershell module
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber -Scope AllUsers

With the PowerShell module installed, we can now create the AAD Kerberos server using domain admin and global admin credentials. The domain admin credentials are needed to create the on-premises AD object and the global administrator is needed to confirm that you have proper access to the tenant.
 

$Domain = 'ad.thesysadminchannel.com'
$DomainCredential = Get-Credential -UserName 'ad\domainadmin' -Message 'Enter Password'

Set-AzureADKerberosServer -Domain $Domain -DomainCredential $DomainCredential `
  -UserPrincipalName paul@thesysadminchannel.com

Get-AzureADKerberosServer -Domain $Domain -DomainCredential $DomainCredential `
  -UserPrincipalName paul@thesysadminchannel.com

You will notice that a new computer object will be created in the Domain Controllers OU within AD.

Deploy Device Settings using Group Policy

With the Azure AD Kerberos server already created, all that’s left from an infrastructure perspective is to deploy the policy settings to the client devices. As I mentioned previously, this can be completed via Microsoft Intune, however this article is going to focus on deploying those configs via Group Policy.
 

With Group Policy Editor Open:

• Navigate to Computer Configuration → Administrative Templates → Windows Components → Windows Hello for Business
• set Use a hardware security device to Enabled
• set Use biometrics to Enabled
• set Use Windows Hello for Business to Enabled
• set Use cloud trust for on-premises authentication to Enabled
• Apply the policy to your computer objects

The policy should look like this in the settings page.

Next Generation Credential (Ngc) Client Prerequisite Check

Let’s head on over to the client machine to see what the current status of the device is and check if it will provision or not. This is not something the end user will be doing, however, it will provide troubleshooting tips if something is not working.
 

While on the client machine, open PowerShell and type: dsregcmd /status. Take a look at the device state and more importantly the Ngc Prerequisite Check (Image is edited for readability so you’ll need to scroll all the way down to see it).

 

This will give you details for the provisioning state of the device. If there are any issues like the device is not joined, the CloudTGT is unknown or the device is not eligible, a good place to start troubleshooting is to make sure the device is successfully Hybrid Azure AD Joined (not Azure AD Registered)

User Experience

We’ve now confirmed that the device is eligible and our status check says that it will provision. What now?
 

The next time the user logs in they should be prompted with the Windows Hello enrollment screen. If it’s not popping up, I’ve noticed logging out and logging back in again (instead of rebooting) usually does the trick.

 

The user will need to confirm their identity for completing an MFA request. If the user is not enrolled in MFA, they’ll most likely be prompted here to enroll. However, in our case, we have MFA enrolled so we’ll just complete the MFA number matching request.

Next we’ll be prompted to set up a PIN that can be used only for this device.

 

If there are no issues, you should now see an All set! screen.

 

Enabling Additional Gestures like Fingerprint, Face or Fido2

In the event you want to enable additional gestures like Fingerprint, Face or even a Fido2 security key you can do this manually without having to go through the wizard.
 

For example, I personally like using external USB keys like the TrustKey G320H because it supports Windows Hello Fingerprint and Fido2. Since I usually have my device with the lid closed and stowed away, this works great and it’s something I use literally everyday. If I get another key, I can enable it using these settings.
 

To enable additional gestures go to start → type: Sign-in options

Conclusion

Hopefully this article provided in-depth knowledge on how to enable Windows Hello for Business Cloud Trust. This implementation is honestly quite easy and doesn’t take a lot of effort to get the ball rolling. You will just need to make sure you test with a pilot group and communicate to your users what they’ll expect to see when this rolls out.

The post How To Enable Windows Hello for Business Cloud Trust appeared first on the Sysadmin Channel.

Well today, we’re going to do just that. I understand this is the legacy method for setting multi-factor authentication on user accounts, however, there’s a probable chance that you might have forgotten to disable it when you eventually moved on to setting MFA using conditional access policies. I say that because this was the case for me not too long ago.

Requirements

In order to get started with checking per-user MFA status, we’re going to need a few things in place to make sure we get a successful output. Let’s list them out here.
 

• MSOnline (MSOL) PowerShell Module
• Global Administrator Role

Get Per-User MFA Status using Office 365 Portal

Before we get into the Powershell method, I wanted to quickly go over the method using the legacy Office 365 Portal. In order to check this, you will need to be a Global Administrator.
 

In Azure AD:

• Navigate to Users -> Per-user MFA
• Using the drop down for Multi-Factor Auth status: Choose Enabled or Enforced

Using this method, you have the option to quickly see their status and if you’re up to it, you can disable them right there.

Get Per-User MFA Status using PowerShell

Now that we know how to check in the portal to view the per-user mfa status, let’s take look at how to do this within PowerShell. This requires you to be connected to the MSOnline using Connect-MSolService so let’s take a look now.

Function Get-PerUserMFAStatus {
<#
.SYNOPSIS
    Get Per-User MFA Status using MSOnline Powershell Module

.NOTES
    Name: Get-PerUserMFAStatus
    Author: theSysadminChannel
    Version: 1.0
    DateCreated: 2021-Feb-3

.LINK
    https://thesysadminchannel.com/get-per-user-mfa-status-using-powershell -
#>

    [CmdletBinding(DefaultParameterSetName='All')]
    param(
        [Parameter(
            Mandatory = $false,
            ParameterSetName = 'UPN',
            Position = 0
        )]
        [string[]]  $UserPrincipalName,


        [Parameter(
            Mandatory = $false,
            ParameterSetName = 'All'
        )]
        [switch]    $All

    )

    BEGIN {
        if (-not (Get-MsolDomain -ErrorAction SilentlyContinue)) {
            Write-Error "You must connect to the MSolService to continue" -ErrorAction Stop
        }
    }

    PROCESS {
        if ($PSBoundParameters.ContainsKey('UserPrincipalName')) {
            $MsolUserList = foreach ($MsolUser in $UserPrincipalName) {
                try {
                    Get-MsolUser -UserPrincipalName $MsolUser -ErrorAction Stop
                    
                } catch {
                    Write-Error $_.Exception.Message

                }
            }
        } else {
            $MsolUserList = Get-MsolUser -All -ErrorAction Stop | Where-Object {$_.UserType -ne 'Guest' -and $_.DisplayName -notmatch 'On-Premises Directory Synchronization'}
        }

        #Now that we have our UserList, lets check the per-user mfa status
        foreach ($User in $MsolUserList) {
            if ($User.StrongAuthenticationRequirements) {
                $PerUserMFAState = $User.StrongAuthenticationRequirements.State

              } else {
                $PerUserMFAState = 'Disabled'

            }

            $MethodType = $User.StrongAuthenticationMethods | Where-Object {$_.IsDefault -eq $true} | select -ExpandProperty MethodType
            
            if ($MethodType) {
                switch ($MethodType) {
                    'OneWaySMS'            {$DefaultMethodType = 'SMS Text Message'  }
                    'TwoWayVoiceMobile'    {$DefaultMethodType = 'Call to Phone'     }
                    'PhoneAppOTP'          {$DefaultMethodType = 'TOTP'              }
                    'PhoneAppNotification' {$DefaultMethodType = 'Authenticator App' }
                }
              } else {
                $DefaultMethodType = 'Not Enabled'
            }
    
            [PSCustomObject]@{
                UserPrincipalName    = $User.UserPrincipalName
                DisplayName          = $User.DisplayName
                PerUserMFAState      = $PerUserMFAState
                DefaultMethodType    = $DefaultMethodType

            }

            $MethodType        = $null
        }

    }

    END {}
}

Script Parameters

    -UserPrincipalName

DataType: string/array
Description: Specify the UserPrincipalName of the per-user MFA status you would like to see. Multiple UPNs separated by a comma are acceptable.
 

Example 1 – Specifying UserPrincipalNames separated by a comma

PS C:\> Get-PerUserMFAStatus -UserPrincipalName aaduser3@thesysadminchannel.com, aaduser4@thesysadminchannel.com, `
astark@thesysadminchannel.com, jsnow@thesysadminchannel.com

Example 2 – Getting all user’s status in the tenant

PS C:\> Get-PerUserMFAStatus -All

Conclusion

As mentioned, the per-user mfa is not the recommended way to enable MFA for your users. For that, we’ll want to either use conditional access (which require an Azure P1/P2 license). For those that don’t have this license in their tenant, you can use security defaults which enables MFA across the whole tenant.
 

Hopefully, you were able to find this script useful in finding which users still have the legacy MFA method enabled.

The post Get Per-User MFA Status using PowerShell appeared first on the Sysadmin Channel.

Requirements

In order to move forward with enabling multi-factor authentication for guest users there are a couple of requirements that are needed. Let’s list them out here so we have a clear understanding of what they are.

• Azure AD Premium license (P1 or P2)
• A valid external email account that you can add as B2B guest user

In my lab tenant, I have EMS-E5 licenses which is P2 so I’m good to use conditional access policies to get this all setup.

End User Experience and What to Expect

To give you some context on how I’m testing this in my lab tenant, I’ve granted the external user who is named “Guest User” access to a SharePoint site that I’ve created for this purpose.
 

The SPO site, Project Gladiator, has an “ExternalUser” folder that I’ve setup to mimic a real-world scenario. This folder is where people from other orgs will update their notes to use for collaboration.

At this point, I’ve sent an invitation to the guest user and they have accepted the invite. Next, I copied the link to that folder and sent over to the external user so they can access the resources that are setup at their convenience.
 

For now, we’ll take a moment to check in on the user experience before and after the policy is enabled.

What to Expect if the User has MFA Enabled

Let’s take a moment to clear the air first. If a user has MFA enabled on their own home tenant, this doesn’t mean that they’ll be prompted to confirm their identity with an MFA prompt on your resource tenant. There are now ways to trust the MFA claims from the home tenant using Cross Tenant Access Policies (xtap) but that’s a little outside the scope of the this article.
 

It will actually take some effort to enable MFA on a resource tenant if you’re not enforcing it so chances are they won’t do unless you make them.
 

However, if a user has enrolled in MFA in the resource tenant, then they’ll continue to be prompted for MFA as they previously have.

What to Expect if MFA is not enabled for the User

Since there aren’t any policies that are enforcing MFA for external (guest, B2B etc..) users, this user is able to get in with just a username and password. If someone potentially compromised the remote credentials, they now have access to your tenant. This is obviously a no-no and is the reason why enabling MFA is so vital to security.
 

We haven’t touched on how to enable the policy yet, however, what can we expect when we enable MFA for external users Office 365 / Azure AD?
 

Once you enable the policy, the user would be shown the typical prompt for when a user tries to enroll in MFA in the home tenant.

How To Enable MFA for External Users Office 365

Now that we know what it looks like, next up is to use a conditional access policy template in Azure AD to set it up. As mentioned, this would require you have a premium license so hopefully you have that setup in you tenant so you can follow along. Let’s review the steps needed to enable this policy.

In Azure AD:

• Navigate to Security -> Conditional access -> Policies
• Direct Link: https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies
• Click New Policy -> Create new policies from templates

• Under Customize your build: select Identities and click Next
• select Require multi-factor authentication for guest access and click Next

• Review the policy and confirm it is in Report-only
• Click Create Policy

Now let’s go back into the policy and under Assignments -> Exclude: Enter the breakglass account and an MFA exclusions group in your own tenant. Hopefully this won’t be needed, but if someone decides to modify the policy and applies it to people in your org, you’ll at least have some specific exclusions in place.
 

Finally, enable the policy and click save. External users will now need to enable MFA to access resources in your home tenant.

Conclusion

Hopefully this article showed you how to enable MFA for external users Office 365 and was easy to follow along. If you haven’t done so already, be sure to enable MFA for your regular users to ensure you’re covered across the board.

The post How To Enable MFA for External Users Office 365 appeared first on the Sysadmin Channel.

Today we’re going to cover exactly how to enable Passwordless authentication so you can answer the age old question of how to login to Microsoft Authenticator app. To give you a bit of context, when you enable Passwordless, you’re actually using your phone’s authenticator app in lieu of your password along with the biometric (or PIN) that’s set on your device. This allows you to verify your identity by approving the MFA challenge without ever having to enter in your password.

Requirements

In order to get passwordless authentication setup and configured in your environment, there are a couple of items that need to be setup beforehand. Don’t worry, we’ll walk through the entire process to ensure you’re at least beta testing this feature. Here’s an overview.

• The user must have Microsoft Authenticator installed on their device
• Microsoft Authenticator must be the default MFA method
• If a user has TOTP as their default method, passwordless authentication will not work
• A device can only be registered to 1 account
• To Confirm Device Registration: Open Authenticator → Settings → Device Registration
• The user will need to be scoped to the authentication method policy
• The app must be a cloud app. Applications hosted in ADFS may not work since it’s a different IdP

Microsoft Authenticator Registration and Management

As mentioned, one of the requirements above is to ensure that the user has MFA push notifications enabled on their account.
 

If you don’t have admin access to check these settings, they can check themselves by doing the following:

• Navigate to https://aka.ms/mysecurityinfo
• In the Security info blade…
• Ensure the default sign-in method is set to Microsoft Authenticator – notification
• If it’s set to TOTP, you might need to click Add method and register a push notification method

If you are an admin and you’re rolling this out to a larger set of people, it would be a good idea to get ahead of the curve and find out the user’s default strong authentication method. Luckily, we have the ability to check this using the MSOnline Powershell module.
 

As of today, we’re able to get Azure AD authentication methods using Microsoft Graph API, however Graph API does not have the capability to view the default method so we’ll need to rely on the MSOL module.

How To Enable Passwordless Authentication Azure AD

Now that we’ve met the requirements and confirmed that MFA push notifications is the user’s default method, we’re now read to move forward with setting up passwordless for your org.
 

Configure Administrative Settings for Passwordless Authentication

Let’s follow the steps below:

• Navigate to the Azure Active Directory -> Security -> Authentication Methods -> Microsoft Authenticator
• Set the policy to Enable
• Set the target to All Users or specify a pilot user/group

• As a bonus, enable location rich context For MFA Push Notifications and number matching for icing on the cake

Client Setup and User Experience

Assuming the user is in scope of the policy, let’s review the setup that’s needed as the end-user. It is relatively straight forward and setup is only needed once per device.

• On the user’s mobile device, click the entry for the account
• Click Enable phone sign-in

• Select continue on the next screen and you’ll be prompted to authenticate to approve MFA
• If successful, click back into your account and you should see Passwordless enabled

Now that we’ve enabled passwordless on the client device, let’s activate it.

• Open an incognito browser and enter in your user name
• On the prompt to enter your password, select Use an app instead (or other ways to sign-in if Fido2 is enabled)
• Enter the corresponding number

Conclusion

That’s it! Passwordless is now enabled on your account. Going forward, anytime you try to authenticate to a cloud resource you will be able to use passwordless authentication. One caveat to this is, if the application is hosted in your onprem ADFS, your mileage may vary.
 

All in all, I think this one of the great features that you should have rolled out to your organization. It is user friendly, adds security with MFA and is good practice to implement.

The post How To Enable Passwordless Authentication Azure AD appeared first on the Sysadmin Channel.

What is Additional Context

As mentioned, additional context allows the user to see what application triggered the MFA challenge and arguably more importantly, the location of the device that triggered it. So essentially, it will tell you what and where the MFA was triggered.
 

A lot of administrators have been requesting a feature like this to provide better security for their organization. Now, when users get MFA push notifications they can confirm that the location is not somewhere half way across the world.

What Are The Requirements To Enable This Feature

Before we get into the steps to enable this feature, let’s take a brief moment to discuss the requirements.

For starters:

• A Global Administrator -or Authentication Policy Administrator are required to set the policies
• MFA push notifications must be enabled and set as the default
• Note: If the default authentication method is TOTP additional context won’t work

How To Enable Location Rich Context For MFA Push Notifications

In order to move forward with MFA location rich context, let’s take you step by step to enable this policy for all or a subset of users in your organization. This can be enabled via Graph Explorer, but we’ll cover the method for setting this up in the Azure Portal graphical user interface.

In the Azure Portal:

• Navigate to Azure AD -> Security -> Authentication Methods
• Select Microsoft Authenticator

• Under Enable: Click Yes to enable the policy
• Under Target: Select your choice of All users -or Select users
• Next to Registration, click the 3 ellipsis -> Configure

• Authentication Method: set to Any
• Require Number Matching: I recommend setting to enable
• Show additional context in notifications: set to Enabled
• Click Done

This is using additional context and number matching for added security.

Conclusion

So there you have it. We’ve gone over the steps to enable location rich context for MFA push notifications in your organization and hopefully it’s something you’ll be able to implement fairly soon. It’s great step for security and personally I think it’s great for users as well.
 

If you enjoyed this and want to see more like it, be sure to check out our Azure posts for more useful content.

The post Enable Location Rich Context For MFA Push Notifications appeared first on the Sysadmin Channel.

What is Legacy Authentication And Why We Should Block It

I suppose before we go into detail on how to block it, we should probably address what it is. Legacy authentication is more or less self explanatory. By that I mean, it includes authentication methods that are superseded by todays modern authentication. In short, legacy authentication are authentication methods typically used by mail protocols such as IMAP, SMTP and POP3. Microsoft Office 2010 is an example client that uses legacy authentication.

 
The biggest take away here is that legacy authentication was highly active during a time where multi-factor authentication wasn’t really a thing. We’ve come a long way as far as security and auth methods go, but should still close those gaps because it can lead to open vulnerabilities in your environment.

 
To summarize, legacy authentication does not enforce multi-factor authentication (MFA) so it gives attackers a preferred attack vector to exploit. This is the biggest reason why we want to block legacy authentication. With that said, we can now get into the modern (and preferred) methods to blocking legacy authentication using conditional access policies.

How To See If Legacy Authentication Is Blocked in your Tenant

Now before you go through your testing it might be a good idea to check whether basic authentication is blocked in your tenant to begin with. Microsoft has already stated that if they don’t see any authentication requests using these older protocols, they’re going to disable it by default. In my tenant I wasn’t using so it was actually already turned off. To save you the headache, here are the steps to check if basic authentication is enabled in your tenant.

• Navigate to https://admin.microsoft.com/ to get to the Office 365 admin portal
• Next navigate to settings -> Org Settings -> Services -> Modern Authentication
• Direct Link: https://admin.microsoft.com/AdminPortal/Home#/Settings/Services/:/Settings/L1/ModernAuthentication

Use Conditional Access To Block Legacy Authentication In Office 365

Now that we understand the why, let’s get into the how portion of this article. We’re going to assume you have permissions to create conditional access policies.

• In Azure, navigate to Azure Active Directory -> Security -> Conditional Access -> Create a New Policy
• Direct Link: https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies

• We’ll name this policy, Common Policy – Block Legacy Authentication
• Under Users and groups:
• Under Include: We’ll select all users
• Under Exclude: We’ll want to exclude our exclusions group – e.g. break glass/service accounts

• Cloud apps or actions:
• Under Include: We’ll select all cloud apps
• Under Exclude: We’ll want to leave this blank

• Conditions -> Client apps:
• Select “Yes” to configure policy
• Unselect Browser and Mobile apps and desktop clients
• Leave Exchange ActiveSync clients checked
• Leave Other clients checked

• Grant:
• Select Block Access

For the final step, set the policy to Report-only so you can have some insights before enabling the policy. This will give you a heads up as to who is still using legacy authentication and at least give them some kind of notice to stop. Otherwise, if you’re brave, turn it off and apply the scream test which is also just as effective as finding out who is still using it.

Block Legacy Authentication Exchange Online

In addition to conditional access, we should also consider disabling the legacy auth methods in Exchange Online itself. There are several ways we can about it and we’ll cover those methods as well. However, here is a quick overview.

• Using an Authentication Policy
• Apply it as the default organization policy
• Apply it as a per user policy
• Disable IMAP/POP/Mapi/SMTPAuth protocols per mailbox

Create an Authentication Policy to Disable Basic Authentication

Being able to create an authentication policy would be able to help you not only identify who is using the policy, but set a standard for your setup. The command to create an auth policy is New-AuthenticationPolicy. Let’s cover two scenarios for enabling and disabling the required protocols.

#Create a Block Legacy Authentication Policy
New-AuthenticationPolicy -Name "Block Legacy Authentication"


#Create an Allow All Legacy Authentication Policy
New-AuthenticationPolicy -Name "Allow All Legacy Authentication" -AllowBasicAuthRpc -AllowBasicAuthPop -AllowBasicAuthSmtp -AllowBasicAuthMapi -AllowBasicAuthImap -AllowBasicAuthAutodiscover -AllowBasicAuthPowershell -AllowBasicAuthActiveSync -AllowBasicAuthOfflineAddressBook -AllowBasicAuthReportingWebServices -AllowBasicAuthOutlookService -AllowBasicAuthWebServices 

#Set the authentication policy as the default authentication policy for your organization
Set-OrganizationConfig -DefaultAuthenticationPolicy 'Block Legacy Authentication'

#Set the authentication policy on a per user basis
Set-User jsnow -AuthenticationPolicy 'Block Legacy Authentication'

#Have the policy take effect within the next 30 minutes.  By default it can take up to 24 hours.
Set-User -Identity jsnow -STSRefreshTokensValidFrom (Get-Date).ToUniversalTime()

Disable IMAP/POP/Mapi/SMTPAuth protocols per mailbox

Another alternative to the authentication method is to disable the protocols for each individual mailbox. This can be done using the Set-CASMailbox command for each of the mailboxes you’d want to disable.

PS C:\> Get-CASMailbox blightyear

Name       ActiveSyncEnabled OWAEnabled PopEnabled ImapEnabled MapiEnabled SmtpClientAuthenticationDisabled
----       ----------------- ---------- ---------- ----------- ----------- --------------------------------
blightyear True              True       True       True        True


PS C:\> Set-CASMailbox blightyear -ActiveSyncEnabled: $false -PopEnabled: $false -ImapEnabled: $false -MAPIEnabled: $false
PS C:\>
PS C:\> Get-CASMailbox blightyear

Name       ActiveSyncEnabled OWAEnabled PopEnabled ImapEnabled MapiEnabled SmtpClientAuthenticationDisabled
----       ----------------- ---------- ---------- ----------- ----------- --------------------------------
blightyear False             True       False      False       False

Conclusion

That’s it. Now we know how to block legacy authentication using conditional access policies in Azure Active Directory. For more posts on conditional access or Azure AD in general, be sure to check out our gallery of Azure Active Directory.

The post How To Block Legacy Authentication Office 365 appeared first on the Sysadmin Channel.

Setup DMARC in Office 365

We previously setup DKIM for Office 365 and as a measure to strengthen our security footprint, we’re going to setup DMARC in Office 365 as well.

• Login to your DNS provider. I’m using Cloudflare so i’ll get it setup there
• Create a new TXT record
• In the name field, type: _dmarc
• In the value field, type: v=DMARC1; p=none; rua=mailto:dmarcreports@domain.com
• Set TTL to 5 minutes to allow for a quick DNS propogation. Be sure to change to 1 hour afterwords

Here’s a quick break down of what the above values mean.

DMARC Explained – Quick breakdown

Name or Hostname value (Domains and subdomains)

• Hostnames will usually be _dmarc for top level domains. e.g. _dmarc.thesysadminchannel.com
• Subdomains should have _dmarc.subdomain. e.g. _dmarc.subdomain.thesysadminchannel.com

 
Value or Content

• There are two required value pairs that MUST be present on every DMARC record. They are “v” and “p”.
• The only tag-value pair for “v” is v=DMARC1
• The “p” tag pair “p=” can be paired with none, quarantine, or reject. e.g. p=none or p=quarantine or p=reject
• The “rua” & “ruf” tags support multiple email addresses with each separated by a comma e.g. rua=mailto:dmarcreports@domain.com
• It is recommended to start out with “p=none” so you can identify any issues with mail flow. After some time change it to quarantine or reject.

 
At the end of the day this is my DMARC record looks like in Cloudflare.

How To Confirm If DMARC Is Enabled and Working

Now that we have setup DMARC for our domain, we want to make sure everything is working as expected. So now the question is, how can we check to see if DMARC is enabled and working? Let’s head on over to https://mxtoolbox.com/dmarc.aspx so they can do the heavy lifting for us.

The post How To Setup DMARC in Office 365 appeared first on the Sysadmin Channel.