Configuring the Agent Connectivity Credential (ACC) and Implementation Best Practices
search cancel

Configuring the Agent Connectivity Credential (ACC) and Implementation Best Practices

book

Article ID: 194234

calendar_today

Updated On:

Products

IT Management Suite Client Management Suite Server Management Suite

Issue/Introduction

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.

Environment

ITMS 8.x.

Resolution

Step 1: Configure the ACC in the Console

  1. In the Symantec Management Console, navigate to Settings > Agents/Plug-ins > Global Settings.

  2. Select the Authentication tab.

  3. 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.

Step 2: Enable Automated Local Account Management

If you explicitly chose to use a Domain Account in Step 1, skip this step entirely.

  1. Navigate to Settings > Notification Server > Site Server Settings.

  2. Expand the tree and select Global Site Server Settings.

  3. 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.

Step 3: Propagate Configuration Changes

  1. 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.

  2. To accelerate this process, send an Update Agent Configuration task to all Site Servers and the SMP.

Step 4: Align Share & Folder Permissions (Crucial Dependency)

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

    • This can be any Shared folder.  To see where this folder lives, browse in the Console to Settings > All Settings > Software > Software Catalog and Software Library .. >  Software Library Configuration
  • NSCAP Share

    • ..:\Program Files\Altiris\Notification Server\NSCap
  • Patch Download Locations 

    • ..:\Program Files\Altiris\Patch Management\Packages

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.

Engineering Best Practices & Guidelines

  • 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.

Additional Information