@Nipa 

Thank you . This is working.

@Mohit Chordia , if you open a support case, share it here and I’ll split your query into its own thread.

TFA email can be disabled using this Additional settings. If set at commcell level, it will disable for all the users that belongs to the commcell. 

Name: DisableTFAEmail

Category: CommServDB.Console

Type: Boolean

value: true

@dude :

Already did few months back they don't have any way apart from modifying the email template .

What I would do in this case, would talk to support in hopes that there is a qcommand / qscript that can disable the MFA Email notification and only allow the Apps. I would not be surprised if they have a way to do that.

Np, workaround is present to modify the email template but going through the thread i thought that something new is introduced in 11.25 release.

Ohh sorry I misundertood you before. Looking at the docs, I am not quite sure it is documentated or if it is possible. I would recommened opening a case with that request and if that is not possible today, I`m sure they would provide options to get around that.

@dude 

I understand that PIN generating apps can be used  but is there any option to disable PIN over email feature in 11.25 . I want to ensure that if a user is not using PIN generating app should not receive the PIN over email.

Any new capabilities added in 11.25 for MFA ?

Regards, Mohit

@Mohit Chordia you do not need to use PIN over email. You have additional options such as Google Authenticator App, Microsoft Authenticar App, Commvault Token Desktop.

Refer to : https://documentation.commvault.com/11.24/expert/7935_pin_generating_tools.html

@Mike Struening :

@dude 

@Anand 

Do we have the the option in FR25 now to disable PIN over email feature ? If yes , please share the documentation.

Anytime, man!

Thanks

@dude , this is coming inFR25.

Hey @Anand , do you have any ETA on release for @dude ?

@Anand I`m not sure I understand. It is currently not supported but it is coming in future release? do you  know when?

@dude , let me know if @Anand ‘s reply satisfied your question 

@dude  In other words, yubikey option doesn’t get invoke, when we do SSO.  In case of ADFS, yubikey support need to be added in AD. When token comes back to us, user is already marked authenticated. Internally we have tried yubikey with Azure AD setup and it worked fine. Currently we are adding feature to allow local or direct AD user authentication with yubikey.

Editing in FR25 to mark this as the best (and complete) answer.

@Mike Struening just wondering if you would be able to look my question above about ADFS/Yubikey and check internally? Thanks

@Anand any way to get ADFS and allow Yubikeys?

Second factor is asked only when CV does the password authentication. When password is validated thru SSO or IDP, we act as relying party. 

I understand that you want end user to amend the email but admin may not like it. They would like to keep the user email same as AD email to avoid defragmentation, data leak or security issues. We are targeting to update the email only when it’s empty. Ex- service account, SAML account etc. 

We also just discovered disabling SSO has forced the java client to prompt for 2 factor auth. For wider community as I presume you know this.

Great stuff. Maybe the AD/LDAP email address should stay for the purpose of scheduled reports etc, but a 2nd e-mail field used exclusively for recovery purposes. Users should be flagged that their recovery email address is empty if MFA is enabled, and periodically prompted (6 months) to check their details are still correct. I also think any manual amending of the e-mail address be limited to the user, therefore a administrator can create\disable an account but not amend it.

This is being worked on. 

1. Option to block the pin to be sent in email.
2. Option to set the email for the AD/LDAP account if user has rights.

we are checking this internally with

 @Divya Trivedi@Tharun Pathepuram  @Anand 

we will get back on this.