- [Instructor] Microsoft claims that 60% of all successful attacks rely on compromised credentials, so extra care needs to be taken to protect user identities in Active Directory and Microsoft's cloud-based directory services solution, Azure Active Directory. Like Azure AD Identity Protection, Microsoft Advanced Threat Analytics is a product for protecting user accounts from compromise. However, ATA targets on-premises AD, while Azure AD Identity Protection targets Azure AD identities.
While conceptually similar, they are separate engines, each with their own machine learning algorithms. Azure AD Identity Protection goes beyond simple monitoring and reporting by allowing organizations to set risk-based policies with or without conditional access in Azure AD that respond to issues when a specified risk level is reached. For example, a policy could block access, force a user to reset their password, or stipulate the use of multi-factor authentication.
Azure AD configuration issues are also flagged, such as alerts from privileged identity management and the presence of unmanaged cloud apps. There are six risk event types that Azure AD Identity Protection detects, and each is assigned a risk level of high, medium, or low. For example, users with leaked credentials, sign-ins from anonymous IP addresses, or impossible travel to atypical locations. Identity protection will also watch for sign-ins from infected devices, or sign-ins from IP addresses with suspicious activities, as well as sign-ins from simply unfamiliar locations.
Just like Microsoft ATA, Azure AD Identity Protection uses machine learning and behavioral analytics to detect malicious activity related to user identities. However, unlike ATA, Azure AD Identity Protection is leveraging the scale, the sample data, billions of data points collected daily of the Microsoft intelligent security graph. For each incident that's detected, a risk event is created. Some risk events can be detected in real time, while others are detected offline.
To mitigate risk events, actions defined in policy are activated when a certain risk level is reached. If you require multifactor authentication, remember that this policy only affects users who've actually been registered for multifactor authentication in Azure AD. As a best practice for users that have not yet registered for MFA, enable MFA registration policy for them and require them to register in a non-risk session, meaning from a familiar device in a familiar location.
Which policy is right for your organization? Choosing the high threshold option will minimize impact to your users. On the other hand, choosing the medium threshold option maximizes protection. Setting high on normal users but medium on sensitive or privileged users may be the right mix. It's important to understand when policy is applied. Policy will be applied to sign-ins using modern authentication, in all browser traffic.
Policy is not applied to applications using older security protocols by disabling the WS-Trust endpoint which provides extensions dealing with issuing, renewing, and validating of security tokens, amongst other things, at the federated identity protection level, such as with ADFS. When policy is applied, the new keep me signed in experience can minimize the prompts. However, there's intelligence behind that feature to ensure that users are prompted to remain signed in only when it's safe to do so.
At the end of the day, Azure AD Identity Protection adds an intelligent, automated, always improving layer of defense against identity compromise. If you were to ask anyone on the Microsoft Azure AD team who should implement Azure AD Identity Protection, they would simply answer, everyone. And in my opinion, they'd be correct.
- Configuring virtual-based security
- Securing email
- Implementing post-breach defense
- Protecting the cloud with Azure AD
- Using Windows Defender ATP
- Managing privileged access in Azure