Under certain circumstances, a user may be unable to sign in, and the following event is logged in syslog:
Access has been denied because the policy requirements could not be satisfied by the users’ current set of available authenticator enrollments.
- Multifactor authentication (MFA)
- Enrollment Policy
- Authentication Policy (ASOP)
If an Authentication Policy (ASOP) policy calls for an Authenticator that a user is not enrolled in and/or cannot enroll in per their enrollment policy, this error can occur.
This can happen when the authenticator does not meet other conditions of the ASOP or Enrollment Policy, such as authenticator constraints for Hardware Protection in the Authentication Policy, or Network Zone configuration within the Enrollment Policy, which removes them from connecting to their expected policy.
Review Authentication Policies and the Authenticator Enrollment Policy scoped to the user to ensure that the user can enroll in the necessary factors to satisfy the requirements of the Authentication Policy:
- The user must be enrolled and have access to the Authenticator that the Authentication Policies have defined.
- If the Authentication Policy defines that only Okta Verify or WebAuthn satisfy the authentication conditions, then at least one of these Authenticators must be available within the user's Enrollment Policy for them to be able to enroll and use the authenticator to satisfy the policy conditions.
- A conflict may occur with the Authentication Policies defined with certain constraints. One known example is the Hardware Protection constraint. If the user's hardware does not support Hardware protection (See "AND Possession factor restraints are" section in our Manual Chapter: Add an authentication policy rule for definitions), then even though the user is enrolled with the Authenticator, they may not use it for authentication, and the error message may display. In this instance, the user must enroll in an Authenticator.
- Ensure the user's Authenticator Enrollment Policy allows them to enroll and use the specified factor.
- Be sure to take into account if Network Zones are configured in the Authenticator Enrollment Policies. As Enrollment Policies are utilized within authentication evaluation and context, a change to the user's network may mean they fit into an unanticipated enrollment policy, which may remove the ability to leverage previously enrolled authenticators.
To expand on known condition #2 above - for example:
- A User named TestUser1 belongs to TestGroup1.
- TestGroup1's Enrollment Policy name is "EP1", and it allows enrollment of Okta Verify and SMS. EP1 also dictates they must be within the network zone named "Office"/
- The "Office" network zone is defined as 10.10.10.1/24
- When TestUser1 is in the "Office" Network Zone, they get an IP address of
10.10.10.20.
In this scenario, TestUser1 is able to enroll in Okta Verify and SMS Authenticators and use them in all Authentication Policies that require them.
If TestUser1 is not connecting within the "Office" Network Zone, they will not be assigned to the EP1 Enrollment Policy, and thus might not have access to use or enroll in Okta Verify or SMS depending on the Enrollment Policy or Authentication Policy they match with (usually falling to the default enrollment policies for authenticator availability).
NOTE: The Access Testing Tool can be used to verify whether the user is being assigned the expected policies.
