Azure AD Identity Protection is one of the most sophisticated features in Azure Active Directory (Premium P2). Based on Microsoft’s Intelligent Security Graph it detects users and sign-ins at risk and responds at a level you select. If you have the required licenses it should be part of every cloud security baseline.
It features different levels of risk: low, medium, and high. In this post I’d like to talk about a particular high-risk event: sign-in from a completely unknown location.
Based on what you configure, Identity Protection will in this case proceed to require a password reset (including MFA) from the user to remediate the threat and make sure that it was either a false positive that was triggered by someone on vacation or on a business trip or to ensure that an attacker no longer has a valid password for the user.
If you just let Identity Protection do its magic, it’s all good. It will auto-remediate the alert and close it after password reset was successful.
Now comes the funky part:
Maneuvering into dead end
If you decide to interfere with the proceed e.g. by telling the user to reset the password on his Windows 10 machine in a hybrid scenario, Identity Protection will not behave as expected. If the user – for whatever reason – does not reset the password via any cloud portal the system will not accept the reset as remediation for the threat it sees.
That’s where the helpdesk fun begins:
- affected users can’t use cloud resources anymore as IP will still demand the “missing” password reset
- however, the user can’t reset or change the password again if you use any minimum password age above or equal to 1 day in your password policy
- a cloud administrator can’t reset the password for the user. Due to the minimum password age it will fail in both Azure AD as well as the “Reset password” console in Identity Protection
Fortunately, good ol’ Active Directory comes to the rescue. By resetting the user’s password and requiring them to change it at the next logon you’re good to go. The PwdLastSet attribute will be set to January 1st, 1601 which bypasses the minimum password age requirement.
But remember: unless you close the alert manually, Identity Protection still really wants that reset. 😉
Why does this even happen
The explanation is quite simple: the goal is to prevent an attacker that has access to a user’s device to change the password again and again on-premises which Identity Protection can’t control – at least not directly. So, in order to at least protect all cloud resources it won’t stop until the user proves their identity with a second factor.
The lesson
For most cases you should just let Identity Protection do its thing. However, in certain cases where you suspect a stolen or lost device is used, that could be abusing your corporate VPN client to access on-prem resources you might want to take additional action. This might include reseting the user’s password manually. In this case remember how Identity Protection still wants a cloud-based reset and the effects of the minimum password age.
Thanks for reading!
Chris