By default, the Symantec Management Agent uses the Symantec Management Platform (SMP) Application Identity (App ID) service account to register with Task Servers and download packages. In large or highly active environments, a sudden influx of agent requests or stale credentials can easily lock out this domain-level App ID.
Because an App ID lockout completely paralyzes the NS Console and halts core platform services, establishing an Agent Connectivity Credential (ACC) is a critical best practice. The ACC offloads agent-to-server authentication to an isolated credential, shielding your core infrastructure from lockout loops.
ITMS 8.x.
In the Symantec Management Console, navigate to Settings > Agents/Plug-ins > Global Settings.
Select the Authentication tab.
Click the radio button for Use these credentials and enter a username and password.
Best Practice: Use a Local Account format (e.g., ACC_User) rather than a domain account (Domain\User).
Note on Password Complexity: The console UI is notoriously strict regarding password complexity. Ensure your password contains uppercase letters, lowercase letters, numbers, and symbols to avoid validation errors.
If you explicitly chose to use a Domain Account in Step 1, skip this step entirely.
Navigate to Settings > Notification Server > Site Server Settings.
Expand the tree and select Global Site Server Settings.
Enable the top two checkboxes:
Create the Agent Connectivity Credential on Site Servers – This instructs the Symantec Management Agent to automatically provision this local user account on your Site Servers.
Re-enable the created local account if it has been locked out – This automatically auto-remediates local lockouts directly on the Site Servers.
For these changes to take effect, the Site Servers (and the SMP server, if it acts as a Task/Package server) must pull down their new policies.
To accelerate this process, send an Update Agent Configuration task to all Site Servers and the SMP.
If your SMP server doubles as a Task Server or Package Server, it will use this new ACC local account during package refresh cycles to update codebases. If permissions are missing, you will encounter Access Denied or UNC does not allow read/write access errors (see KB 157265).
You must grant Full Control to the ACC account at both the NTFS (Security) level and the SMB (Share) level for the following repositories:
Software Library
NSCAP Share
Patch Download Locations
Pro Tip: If these repositories live on the same logical drive, you can apply these permissions once at the drive root level to simplify management.
Never Enter Your App ID Credentials Manually: Do not manually type your primary App ID username and password into the "Use these credentials" field. If your architecture requires using the App ID for agent connections, simply check the native box labeled "Use Application Credentials". Manual entry alters credential parsing and breaks core functionality.
How to Rotate ACC Credentials: * Do not simply change the password on an existing ACC account. Legacy or offline agents attempting to connect with the old password will instantly lock the account out company-wide.
Instead: When it is time to rotate credentials, change the configuration to an entirely new username (e.g., from ACC_User_v1 to ACC_User_v2) along with the new password. Ensure this new user has been granted Full Control permissions on your package shares before saving. Because it is a completely unique account string, old agents cannot lock it out.
Isolating Lockouts (Event ID 4740): Because the ACC should be configured as a local account, lockouts will not hit your Active Directory domain controllers. Instead, look directly at the Windows Security Event Logs of the specific Site Server experiencing the issue. Filter for Event ID 4740 to pinpoint the exact machine name or IP address triggering the bad authentication attempts.