Conditional Access Tips From the Trenches

I want to drop some lines about my experience deploying several projects of Azure Conditional Access

• Always exclude your emergency accounts from the conditional access policies (remember if you don’t have an Emergency Account, you’re late), this is something that I always tell to my customers and I will never give up
• Don’t enable new policies without communicate properly to the organization, and also to foresee the impact in the users (you will save a lot of tickets from the customer service)
• Don’t enable policies that requires compliant or hybridAzureAdJoin devices without verifying the state of the devices in the Azure Portal (same as before, you will save tickets and system interruption from the end users)
• Careful with including in the policies the application “all apps”, is it possible to have a disgusting surprise (in my case, it happened to me in Azure, I put some exclusions, but it seems that sometimes the portal calls randomly to other APIs that cannot be controlled (and do not exist in AAD), so the user received a block in the portal even if the policy makes sense for you)
•  If you go ahead with the policy with “All Cloud Apps” for the policies bases on devices, be sure to exclude in the policy the app “Intune Enrollment” or you won’t be able to enrol new devices in the portal
• It is very easy to include multiple cases in one policy, but if you want to troubleshoot of what is happening, is it easier to segment the policy in multiple policies. Eat the elephant bite by bite, we have to put in the balance having and managing several policies or be able to troubleshoot correctly.
• Is it recommended to include a naming convention in your policies, in a bird’s eye, you will be able to know what is the use for each policy (user, device, administrator, guest)

So, this is all, probably you’re following most of these recommendations, but if not, don be a fool 😉

Till next time!

Advertisement

Why you should block legacy authentication

Currently, we could say that Legacy Authentication is one of the most compromising sign-in, luckily for us, older protocols have been replacing with modern authentication services, taking the advantage that MA supports MFA, while Legacy Authentication refers to all protocols that use Basic Authentication, and only requires one method of authentication.

So, it is important thar for security reasons we need to disable legacy authentication in our environments, why? Because enabling MFA isn’t effective if legacy protocols are not blocked. For example, the following options are considered legacy authentication protocols:

• Authenticated SMTP – Used by POP and IMAP clients to send email messages.
• Autodiscover – Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.
• Exchange ActiveSync (EAS) – Used to connect to mailboxes in Exchange Online.
• Exchange Online PowerShell – Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect.
• Exchange Web Services (EWS) – A programming interface that’s used by Outlook, Outlook for Mac, and third-party apps.
• IMAP4 – Used by IMAP email clients.
• MAPI over HTTP (MAPI/HTTP) – Used by Outlook 2010 and later.
• Offline Address Book (OAB) – A copy of address list collections that are downloaded and used by Outlook.
• Outlook Anywhere (RPC over HTTP) – Used by Outlook 2016 and earlier.
• Outlook Service – Used by the Mail and Calendar app for Windows 10.
• POP3 – Used by POP email clients.
• Reporting Web Services – Used to retrieve report data in Exchange Online.
• Other clients – Other protocols identified as utilizing legacy authentication

How can we monitor the usage of legacy authentication in Azure AD?

Thanks to Log Analytics, Insights and workbooks, we are able to monitor the use of those protocols, for instance:

And check the non-interactive sign-ins (be careful with ADConnect sync accounts):

What we can do to avoid this?

The best way to block or report legacy authentication for users is use Conditional Access policies (Does my organization need Azure AD Conditional Access? – Albandrod’s Memory (albandrodsmemory.com) & Enabling zero trust security in your environment – Albandrod’s Memory (albandrodsmemory.com)

But the best way is creating a CA policy:

My final advice

Legacy authentication must be disabled to protect our environments, but first, start small and analyse the impact in your organization.

Till next time!

Conditional Access extension for Chrome

If you’re implementing conditional access in your company and you’re struggling with Windows 10 devices and Chrome support, probably you will need to visit that Docs link: https://docs.microsoft.com/es-es/azure/active-directory/conditional-access/concept-conditional-access-conditions#chrome-support

But in this post, I want to talk about something related to it, in one of my projects, I have a CA policy that required one of the following selected controls: Require MFA or Require Hybrid AAD joined device

My device was Hybrid, so I was fullfilling one of the requirements, for example, when I was accessing with IE or Edge, the device info gets passed properly and MFA is bypassed for hybrid AAD machines.

But with Chrome, even having the Windows 10 Account extension pushed via GPO, I was able to see in the azure sign-in logs that device info is blank except for Browser and OS, so the AAD join status is not passed and MFA triggers. So it was very weird and it was causing me some problems…

So finally, after hours of troubleshooting, i finally figured out what was wrong. When you automatically install the extension, it doesn’t clear some cookies which Chrome will then try to use the old way of logging in. So in this case what you will need to do is access to chrome://settings/content/all and delete the cookies for login.microsoftonline.com

After doing that, everything was working perfectly, keep aware of that!!

Office 365 and new Conditional Access policies

Good news from Microsoft! Now we have a new feature that has been requested by many of my customers, which is to control access to portal.office.com.

You probably now that office portal is controlled by Conditional Access, but acessing to the portal itself you can gain a lot of information from this portal itself…

With this new feature, we can target multiple apps at once. Another major benefit is that when Microsoft adds another app to the Office 365 suite, it is automatically controlled by Conditional Access which is unfortunately currently not the case.

Currently the following Office 365 applications are included in the Office 365 (preview) client;

• Microsoft Exchange Online Protection
• Microsoft Flow
• Microsoft Forms
• Microsoft Office 365 Portal (including admin.microsoft.com)
• Microsoft Teams
• Microsoft Teams Services
• Microsoft To-Do WebApp
• Office 365 Exchange Online
• Office 365 Search Service
• Office 365 SharePoint Online
• Office 365 Yammer
• Office Delve
• Office Hive
• Office Online
• OneDrive
• OneNote
• PowerApps
• Skype for Business Online
• Sway
• Workplace Analytics

So, the advantages that we can find are:

• Less Conditional Access rules needed to control access Office 365 services.
• New Office 365 services are automatically controlled by Conditional Access
• Portal access controlled: A scenario to test this could be to only allow access to the Office 365 apps from compliant devices. We will see that access to the Office Portal, where a lot of meta data is show is not allowed anymore from a non-managed or non-complaint device.
• But also adding an Office 365 account an Office 365 ProPlus installation on a non-managed device can be blocked.

It’s great!!

My experience about registering Hybrid Azure AD joined devices

Implementing a Conditional Access scenario in Azure, involves that device Context claims are necessary for ADFS / Azure AD to determine if a device is recognized, managed, compliant, etc. We have to take into account that are used to recognize if its a known device or not.

During my experience registring Hybrid Azure AD Joined devices, I found that in Windows 7, a Workplace Joined machine is per user based and receives a device authentication certificate that is stored in the “Current User” certificate store.

In Windows 10, I found that Azure AD device registration is per machine, so we have detected blank fields in AzureAD (which is normal), I raised a support ticket and they confirm this behavior. In this case, the machine receives a device authentication certificate that is stored in the “Local Machine” certificate store.

During authentication, IE and Edge successfully use this certificate to complete device authentication. Chrome will not touch any certificates in the “Local Machine” certificate store. If using Chrome the device is not recognized, MFA fails, and the user is prompted for a secondary form of authentication.

This appears to be a known issue with alternative browsers without a suitable answer. Without device authentication occurring, a device can not be recognized for the purposes of bypassing MFA with conditional access policies.

Microsoft has provided a plug-in for Google Chrome, that allows it to perform device authentication when using MFA. However, there are a couple caveats to be aware of:

• The plug-in only works for Chrome and only works with Windows 10 Creators Updates (1703) or newer.
• The plugin only works for Azure AD conditional access policies.
• ADFS device based conditional access policies will not work.
• Relying party trusts in ADFS other than Office 365 will not be able to utilize the plugin due to the previous limitation.

Long story short, Windows 7 device authentication seems to work fine and recognized devices will support device based conditional access policies if you use Chrome. Windows 10 devices using Chrome have limited ability to support device based conditional access policies.