Multi-factor authentication in Identity Hub
Note
This feature is at the Preview stage.
In Yandex Identity Hub, you can configure multi-factor authentication
MFA enhances protection of user accounts by requiring an additional authentication factor aside from the password. This may be either a one-time code (TOTP
MFA policies
MFA policies specify the multi-factor authentication requirements enforced on users, which include:
-
Requirements for the allowed MFA factor types.
-
Requirements for the time period in which the user must add a second authentication factor after registration.
If the user does not add a second factor within the specified period, they will not be able to authenticate in Yandex Cloud on their own.
To enable a user who missed the deadline for adding a second factor to authenticate, the organization administrator must reset the user verification date, restarting the period set in the Creation deadline field of the MFA policy.
To reset a user account verification date, you need the
organization-manager.federations.userAdminrole or higher (for federated accounts) or theorganization-manager.userpools.userAdminrole or higher (for local accounts).Note
You can look up the date of a user's last verification with the MFA factor on the Overview tab of the user information page in the Cloud Center Identity Hub interface.
-
Requirements for the frequency of repeated verification of the additional authentication factor.
Upon expiry of the specified timeout, the user will need to authenticate with the additional factor again.
You can create an MFA policy in the Identity Hub
For an MFA policy to apply to specific user accounts, you need to explicitly add those users or the groups to which they belong to the policy's target groups.
Note
You can add any type of user accounts to the MFA policy target groups, but the policy will only apply to federated and local user accounts.
If a group added to an MFA policy includes users with different account types, the policy will only apply to users with federated and local accounts.
An MFA policy can be either Active or Inactive.
You can temporarily deactivate an active policy; as a result, its status will change to Inactive, and users whose accounts belong to the policy's target groups will no longer be required to use an additional authentication factor. You can reactivate an inactive policy, and its requirements will again apply to the relevant user accounts.
If a user belongs to target groups of multiple MFA policies at once, their account will be subject to the most stringent policy requirements, both in terms of authentication factors and the period and frequency of additional factor verification.
MFA policies can be managed by users with the organization-manager.editor role or higher.
MFA factors
When getting authenticated in Yandex Cloud for the first time, federated and local users belonging to the MFA policy target groups must set up additional account protection by verifying their identity with a second authentication method (factor). Authentication factors available to the user depend on their device capabilities and the factor strength settings dictated by the MFA policy:
-
Any. This option allows users to select one of the following additional authentication factor standards:-
WebAuthn
(FIDO2 ). The acceptable additional authentication factors may include hardware keys such as Rutoken or YubiKey , Passkeys authenticators, platform authenticators such as Windows Hello , etc.Warning
Browser extensions with password input control may cause errors when entering additional factors. We recommend disabling such extensions in case of errors.
-
TOTP
. This standard enables using one-time codes generated by dedicated authenticator apps as an additional authentication factor.
-
-
Phishing-resistant. This option enforces the WebAuthn authentication factors as the most secure ones.
Users must repeat the verification with the selected additional authentication factor as often as is specified in the Lifetime field of the MFA policy settings.
The organization administrator may remove an existing user authentication factor. For example, this may be necessary if the user is unable to access the authenticator app or lost their hardware key used for identity verification.