25 Sep 2018 by Chris Cahill
Microsoft Ignite 2018: What Happened on Day 1?
Here’s a brief round-up of what went down on day one of Microsoft Ignite 2018.
Azure AD Conditional access has long been one of the coolest features in the EMS suite, allowing you to configure policies governing the authentication process for all your cloud applications, Office 365 included. With a wide range of conditions and controls, its flexibility is comparable to and even surpassing the Claims rules and Access Control Policies you can configure with AD FS in federated scenarios. Over the last few weeks, some recent additions made Conditional Access even better, so let’s go over them.
One of the biggest downsides of Conditional Access was the fact that any policies you configure only applied to clients using Modern authentication. Any login attempts coming from clients using legacy authentication methods were simply ignored, leaving a huge gap in your policy implementation. Now, Conditional Access finally supports legacy authentication, albeit with a single action: Block. Even though no other actions are supported, blocking legacy authentication is the number one concern for many enterprises, so this is a great addition to the service.
To configure a Conditional Access policy that blocks legacy authentication, first navigate to the Azure AD Blade in your Azure portal. After clicking on the Conditional access node, you need to create a new policy or edit an existing one. Go to the Conditions menu, then the Client Apps entry and finally select the Other clients checkbox. You can configure any additional conditions as necessary, including scoping the policy to specific Cloud apps or Users and Groups. Regardless of which action you configure under the Access controls section, however, the end result will be that any login attempt falling under the scope of this policy will be blocked. The reason behind this is that none of the other controls are supported for applications using legacy authentication, for example none of these applications can surface the necessary controls to perform Multi-factor authentication.
A sample policy created to block legacy authentication when logging in from an unknown location is shown on the screenshot below. As you can see, several types of conditions are configured on the policy. All users and groups are included to it, with a single exception added for the service account used by the Cogmotive reporting application. All cloud apps fall under the scope of the policy, as well as login attempts coming from all device platforms. For the list of locations, a single exclusion is configured, so that any login attempt coming from a “trusted IP” is not a subject to the policy. Lastly, the “Other clients” condition is configured to scope the policy to just cover legacy authentication attempts. The action for the policy is set to Block access and the Enable policy control is set to ON, meaning that any login attempt matching the conditions listed above will be blocked.
Once the policy is configured, it can take up to 24 hours before it becomes active, as noted in the official documentation. In my experience, however, the changes were applied almost instantaneously, and I was quickly able to confirm that the newly created policy blocks IMAP and POP logins, Autodiscover and EWS requests, remote PowerShell connectivity to Exchange Online and so on. As expected, any login attempts will also be captured in the Office 365 Audit logs, falling under the UserLoginFailed operation and with LogonError value of BlockedByConditionalAccess. Similarly, the Azure AD Sign-in logs will register an event with a Failure Sign-In Status, Sign-In Error Code of 53003 and Failure reason of Access has been blocked due to conditional access policies.
Since most of the applications using such legacy protocols have no way of displaying a server-side message, it’s important to properly communicate changes you have made to the policy in order to avoid confusion and unnecessary ticket volume for your service desk. Even though Modern authentication has been around for years now and every first-party (Microsoft) application supports it, there might still be some users trying to log in with third-party applications that do not support Modern authentication or are using outdated versions of the Microsoft apps. As usual, communicating with your user base and educating them can save you a lot of trouble.
Another recent and very important update to the service is the preview release of the Baseline protection policy feature that enforces Multi-factor authentication for the most-sensitive admin roles in Office 365. The current list of roles covered by the Baseline policy includes:
but as the feature evolves and based upon customer feedback, additional ones might be added. Unlike any other Conditional Access policies, which require any user under the scope of the policy to be licensed for Azure AD Premium, baseline policies are made available for free, with any edition of Azure AD.
Once the feature is released in general availability, it will be enabled by default for all roles listed above. For the preview, however, the baseline policy is created but not enabled, so it’s up to you to decide whether you want to use it. To test it, navigate to the Azure AD blade in the Azure portal, expand the Conditional Access node or browse directly to https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies.
The policy should be listed on top and will be named “Baseline policy: Require MFA for admins (Preview)”. Clicking on it reveals the controls to enable or disable the policy, as well as to schedule automatic enablement later on, once Microsoft has decided that the feature is production-ready. In addition, you can configure a set of users and/or groups to exclude from the policy, just like with any other CA policy. Here’s how the settings look like:
No additional settings are exposed or configurable for this feature, if you need such granularity you will have to use the standard CA policies (which of course require Azure AD Premium licensing). It is important to understand that the Baseline policy enforces MFA on each admin login, meaning that the “bypass MFA on trusted locations” feature will not work. The policy will also apply to any login attempts coming from clients using legacy authentication, so in effect any such attempt will be blocked.
Additional information about the feature can be found in the official documentation.
In addition to the great new features described above, few smaller improvements also deserve mention. One such example is the new conditions found under the Users and Groups node, namely the “All guest users” condition. As the name suggests, selecting this condition will ensure that the policy applies to all Guest accounts in the directory. Alternatively, you can use the same as an exception to your rules.
Similar to the “All guest users” condition, a new condition has been introduced to allow easy inclusion (or exclusion) of users that have been assigned any privileged role in Azure AD. This is the “Directory roles” condition, showcased on the below screenshot:
As you can see from the above, every admin role that is currently available in Azure AD/Office 365 is listed and can be selected as part of this condition. As new roles are added (such as the recently announced Application administrator and Application developer roles), you can expect the list to expand. However, there is no condition that will include “any admin role”, including newly released ones, so you will have to keep updating any rules using this condition.
Lastly, under the Conditions node, a new “Device state” condition has been made available. The two values available are “Device Hybrid Azure AD joined” and “Device marked as compliant” and can be found under the Exclude tab. Using these conditions (exceptions) is most relevant to scenarios where you want to exclude login attempts coming from managed devices.
If you’d like to take full advantage of the Azure platform, Quadrotech offers a range of bespoke migration services for large organizations.