Impossible to onboard new users after enforcing MFA TOTP on LDAP logins

[nivedita-p]

Describe the bug Once TOTP MFA is enforced on LDAP logins, it becomes almost impossible to onboard new users. When a new user tries to login, they are prompted to enter TOTP, for which they need a QR code scanned into any MFA authenticator app, which the user could have been able to generate only before TOTP was enforced. This leaves vault admin to generate QR code for the user using /identity/mfa/method/totp/admin-generate command which expects $ENTITY_ID which is only generated once user has attempted login. Not only is this process very difficult to automate. This makes the whole user onboarding experience to vault very clunky.

To Reproduce Steps to reproduce the behavior:

1. Enforce TOTP using vault write /identity/mfa/login-enforcement/adtotp mfa_method_ids="$TOTP_METHOD_ID" auth_method_accessors=$LDAP_ACCESSOR
2. As vault admin, try to generate QR code for new user using command vault write -field=barcode /identity/mfa/method/totp/admin_generate method_id=$TOTP_METHOD_ID entity_id=$ENTITY_ID
3. $ENTITY_ID won't exist in vault until user has already attempted login

Expected behavior When an LDAP user is trying to login for the first time to a vault that has TOTP enforcement, once user is successfully authenticated against LDAP, provide the user an option to generate their own QR code from UI or CLI.

Environment:

• Vault Server Version : 1.10.3
• Vault CLI Version : 1.7.2
• Server Operating System/Architecture: Flatcar-stable-2765.2.6-hvm

[hghaf099]

@nivedita-p Thanks for filing this ticket. Our product and engineering team are aware of the issue with on-boarding into login MFA for TOTP method and addressing this issue is in our roadmap. Considering that, we do have a proposal on how the Login MFA on-boarding workflow should look like at this point. Here is a orderly listed way of the flow: 1- Configure the TOTP login MFA method and get the method ID 2- Create a policy to grant write access to /identity/mfa/method/totp/generate path and attach that policy to the users 3- Have the users log in, and generate a QR code by sending a POST request to /identity/mfa/method/totp/generate with the MFA method ID. 4- After step 3, enforce the login MFA by creating a login enforcement config.

The above flow would work only before the enforcement rule is configured. However, there are very much cases where users are needed to be on-boarded after login enforcement is setup. Then, in this case, an admin would need to generate the QR code for them using /identity/mfa/method/totp/admin-generate endpoint, passing the MFA method ID and their Entity-ID. This means that the admin would need to create an entity-ID using identity/entity endpoint and entity alias using identity/entity-alias endpoint for them as well.

[oyvsi]

I don't think the proposed process will scale that well. When you onboard 20 new users every week self-service is the name of the game. I think the user should be prompted with Step 3 after logging in with password the first time they log in even when login enforcement is in place.

[jeverett1522]

I agree with @oyvsi ... New users should be prompted to set up MFA on first login if the entity-id is new (meaning it's a new user or method used). After generating a QR code and having them enable it, Vault would then log them out and they can log in with the new TOTP code and correct policies. The policies before MFA should only allow basic generation of the QR code to allow on-boarding to be smooth.

There really is no reason why this workflow was not thought through before releasing, it seems it should have been included in the MVP of the feature...

Hopefully this can take a little higher priority in an application that prides itself in security while trying to avoid complexity. Thanks.

[ipaqmaster]

Running into the same behaviour. MFA is enforced but newly provisioned users (Or in our case an entire organisation of 1500+ users) are immediately asked for and expected to produce a TOTP passcode at first login.

This puts a show-shopping pin in things having to now write some script to generate and securely transmit token's to everyone in our company.

The lack of MFA self-onboarding should be prioritised. The browser of users who have successfully authed over LDAP for the first time should reach out to write /identity/mfa/method/totp/generate and return a QR for them to scan - Appropriately erroring if the Vault browser UI runs into any permission issues along the way for administrators to fix if need be. In the meantime I'll have to think of something else.

[Smithx10]

Obviously... the question is.... how does the Enterprise Version of MFA handle this?

[con-f-use]

Enterprise or not, a secret management system without convenient MFA throughout the whole workflow and all uses is pretty dangerous and reckless in this day and age. I opened the first issue requesting MFA in the OSS version. Thanks and credits to Hashicorp for listening :heart:. In that issue, I argued:

A strong and healthy business behind Vault keeps it growing and financed, which is good for open-source users, too. However, in a world of constant security breaches and increasing compute power to break passwords, I think the benefit of protecting the FOSS community's sensitive data outweighs the revenue caused by TOPT as an enterprise feature.

And that sentiment is true for this issue, too. There being no good onboarding when MFA is already enforced, makes vault actually dangerous. So @hsimon-hashicorp @hghaf099 , maybe you could argue for more exigent circumstance?

[heatherezell]

Enterprise or not, a secret management system without convenient MFA throughout the whole workflow and all uses is pretty dangerous and reckless in this day and age. I opened the first issue requesting MFA in the OSS version. Thanks and credits to Hashicorp for listening ❤️. In that issue, I argued:

A strong and healthy business behind Vault keeps it growing and financed, which is good for open-source users, too. However, in a world of constant security breaches and increasing compute power to break passwords, I think the benefit of protecting the FOSS community's sensitive data outweighs the revenue caused by TOPT as an enterprise feature.

And that sentiment is true for this issue, too. There being no good onboarding when MFA is already enforced, makes vault actually dangerous. So @hsimon-hashicorp @hghaf099 , maybe you could argue for more exigent circumstance?

Thank you for this feedback! I can take this back to our product folks and see if we can make the experience better for everyone. One of my favorite things about our community is meaningful feedback, and how much everyone cares about the product.

While I can't make any guarantees, please know that I hear you and I will bring this to the team. Thank you again!

[ston1th]

Hi @hsimon-hashicorp just checking in for an update on this issue since it is a much awaited feature for me and many others.

[gee456]

I want to ask , is there any way to change vault so users could access the /ui/vault/mfa-setup URL but not the rest of vault even when MFA is enabled? This provides a nice self service way of users setting up their own QR code and MFA.