This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
If you’ve moved your Identity service to Azure Active Directory, or if you’ve connected your Active Directory to Azure Active Directory, you might be interested in what additional security features Microsoft can provide. With Azure Active Directory (AAD), Microsoft has access to monitor user sign-in attempts and analyze them for risk, as they happen. Two services related to this are AAD Identity Protection and Conditional Access.
Azure Active Directory Identity Protection
AAD Identity Protection is solely focused on risks regarding user accounts, including sign-on attempts. These risks can be categorized as a ‘user risk’ such as credentials that are known to have been leaked or compromised, or as a ‘sign-in risk’’ related to the circumstances of the attempt to sign in, like the attempt coming from an anonymous IP address or a location that’s not usual for that account.
You can configure risk policies to automatically enforce remediation steps, or you can view reports of risk users and risky sign-in attempts, for manual remediation.
Risk policies & remediation
The user risk and sign-in risk policies are configured separately and can be applied to all users or selected users and groups. You can also exclude users, for example if they are a member of an included group.
In the policy, you select the Condition (which is the level of risk like Low or Medium). You don’t need to specify what exact scenario would count as a low, medium or high risk – Microsoft’s threat intelligence determines that automatically.
Then you choose a corresponding Control, or what will happen next. Options for Controls include allow access, block access, allow access but require multi factor authentication (MFA) or allow access but require a password change (depending on the policy type). Of course those last condition options would require that your users have been previously configured for multi factor authentication and self service password reset. There’s one additional policy you can use to turn on MFA for your users.
Want to see the impact of your risk policies? You can simulate a couple of different types of risk detections following the instructions here: Simulate risk detections in Identity Protection.
Risk reports and integrations
Want to see more detail or have manual control over any remediation steps? Check out the detailed reports for risky users, risky sign-ins and risk detections. These reports can be downloaded in .csv or .json format or accessed via the Microsoft Graph API for ingestion into other systems.
For more information on reports, visit How To: Investigate risks.
Licensing requirements
Azure Active Directory Identity Protection requires an Azure AD Premium P2 license, which is also included in the Enterprise Mobility and Security E5 plan. However you can get limited report information on the Azure AD Premium P1 plan and the Azure AD Basic/Free plan. For more information on licensing, visit License requirements.
Conditional Access
While Conditional Access also has policies with Conditions and Access Controls, it’s scope is broader than just Identity. It can use Identity sign-in risk as an input signal, especially in conjunction with other factors like device platform or location, and Conditional Access policies can also apply to all or selected Cloud applications.
Conditional Access Policies are also a great way of enforcing extra security restrictions that don’t wait for a risk to be detected, like enforcing that someone is prompted for MFA only if they are outside of the company network (via IP address range or country).
Conditions include sign-in risk (levels Low, Medium, High), Device platforms (like iOS or Windows), Locations (Any, all trusted or selected locations, that you have defined), Client Apps (browser, mobile, modern authentication and Exchange Active Sync), and Device State (to exclude hybrid Azure AD joined devices or devices marked as compliant with Microsoft Intune).
Access controls also have more options, like requiring the device to be marked as compliant or allowing a Cloud app session to be persistent evern after closing and re-opening a browser window (without re-prompting for sign in).
Finally, policies can be turned on in Report-only mode, to log the impact of the policy as if it were in place, for testing. You can then review the log to see which events and users would have been impacted.
Learn more about planning your Conditional Access deployment
Examples
- With Conditional Access, you could configure that a high sign-in risk event is immediately blocked, but not if it’s coming from an Intune compliant device.
- If a high sign-in risk event comes from an Intunre compliant device, you could grant access if the user passes an MFA challenge.
- Also, you could set that certain applications could only be accessed from Intune compliant devices. This is a strong security posture for access to sensitive information, where you can use Intune to enforce the security settings of the device itself (like anti-virus, PIN protection and auto lock times).
Licensing requirements
Conditional Access requires the Azure Premium P1 license.
Which one is right for you?
The answer is: It depends!
Want a greater level of access of when MFA is prompted for and when it isn’t? That’s Conditional Access. Want to ensure only company-managed devices can access some applications? That’s Conditional Access too.
Want a deeper level of detail about risky sign-on attempts from your users or possible identity-based attacks and integration with a Security Information & Event Management (SIEM) system? That’s Identity Protection.
Need both? Your Azure Active Directory Premium P2 license qualifies you for both capabilities.
To learn more:
Azure identity management security overview
Protect your identities with Azure AD Identity Protection
What is Azure Active Directory Identity Protection?
What is Conditional Access?