Malware Prevention Dynamic Analysis activation failure with use of identify provider other than the built-in vCenter Single Sign-On (SSO) domain

Products

• VMware vDefend Firewall
• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

MPS Dynamic Analysis activation fails with a "504 timeout" error in the UI

Environment

Security Services Platform (SSP) 5.2.0 with Static Analysis (Phase 1) of MPS installed

Cause

Dynamic Analysis requires creation of a vCenter Service account and this account is created using the built-in SSO domain "vsphere.local". If any other identity provider is used than "vsphere.local" then the activation fails in the UI with a "504 timeout" error.

The Dynamic Analysis activation phase uses the newly created service account to connect to the vCenter, but fails with a login error as seen in the malware-analysis-masapi pod logs:

2026-08-12 17:25:34,618 - amg_vmware_api_helper.utils - WARNING - Error vim.fault.InvalidLogin thrown when attempting to run _retry_establish_connection: (vim.fault.InvalidLogin) {
   dynamicType = <unset>,
   dynamicProperty = (vmodl.DynamicProperty) [],
   msg = 'Cannot complete login due to an incorrect user name or password.',
   faultCause = <unset>,
   faultMessage = (vmodl.LocalizableMessage) []
}. Attempt 0 of 2...
...
2026-08-12 17:25:48,936 - amg_vmware_api_helper.utils - WARNING - Error vim.fault.InvalidLogin thrown when attempting to run _retry_establish_connection: (vim.fault.InvalidLogin) {
dynamicType = <unset>,
dynamicProperty = (vmodl.DynamicProperty) [],
msg = 'Cannot complete login due to an incorrect user name or password.',
faultCause = <unset>,
faultMessage = (vmodl.LocalizableMessage) []
}. Attempt 1 of 2

Resolution

To resolve this run the attached script after the failure as per the steps below. The script does the following:

1. Obtains the vCenter SSO domain name
2. Patches the kubernetes secret that the malware-analysis-masapi pod uses
3. Patches the malware-analysis-masapi pod script's implicit assumption about built-in domain

Steps to be performed on the SSPI host:

• Copy or upload the attached script to SSPI
  
  
• Make the script executable

  chmod +x non_default_sso_domain_workaround.sh

• Run the script by providing the FQDN for the vCenter being used for malware detonation as input. 

./non_default_sso_domain_workaround.sh -h <vCenter FQDN>

#Example: ./non_default_sso_domain_workaround.sh -h vcenter.example.com

Passing SSO domain directly

In the event that there is no connectivity between SSPI and the vCenter host to allow for the domain to be looked up, the domain can be passed manually. If this route is chosen, be careful to specify the exact correct SSO domain. E.g. 

./non_default_sso_domain_workaround.sh -d correct.domain.local

• When you run the script it will open a prompt screen to select the SSP to edit. If you have multiple SSP instances, ensure you select the specific SSP instance that manages the vCenter where you are attempting to activate Malware Detonation.

Select the SSP instance when prompted :

• Once the script is successfully run, activate Malware Detonation again from the UI to deploy it successfully.

Note: The script should be run after successful Static Analysis activation and before Malware Detonation activation (you can do it before or after facing the above error).

Furthermore, in a Day 2 scenario, if the Malware Detonation Environment needs to be reset to use a different vCenter having a different SSO domain name, then this step needs to be performed before triggering the Reset operation.