Forum Discussion
FEATURE REQUEST: Account Exclusion functionality for SSPR / Self Service Password Reset
Azure configuration for SSPR currently appears to only allow three options for inclusion: None, Selected or All. There is no exclusion configuration option - and that's a problem for non-interactive service accounts and similar:
The workaround is awkward and potentially very time consuming, as described by this person's issue: https://social.msdn.microsoft.com/Forums/en-US/51affd2c-a2c8-4faa-bbd8-bd1773c985d4/how-to-exclude-a-subset-of-users-from-requiring-authentication-info-when-first-signing-in?forum=WindowsAzureAD&prof=required
This is an ongoing issue where non-user accounts aren't able to login because they cannot register an alternative method of login. For example, my ticketing system uses accounts linked to exchange mailboxes to login. It would be far easier to exclude a group with these accounts in from the self-service password reset mechanism than any alternative.
- No option to use dynamic groups?
Late to the party; thought I would drop this here for others:
Dynamic Groups would work if you had an attribute that would denote which users should or should not have permission.
".memberof" was just added to Dynamic Groups about 6 months ago, however the '-notin' operator is not supported (you cannot enable Password Reset for all users, not a member of group 'X').
You would instead need to use some user level attribute to exclude users from the dynamic group.
Very sloppy. The actual solution is to allow for an exclusion group within the Password Reset control - similar to conditional access policies etc.
One possible solution would be to use Conditional Access Policies to prevent a group of users from "Register security information" under User actions. This may prevent self-service password reset as registration is required. Conditional Access Policies correctly allow for groups to be either included or excluded.
The more I think about it, the more I suspect this is another ploy to push customers to E5.
Upvoting this feature. While there is possibly a situation where a dynamic group is valid, exclude would be administrator friendly
