How to setup Agent Connectivity Credential (ACC) and Best Practices

Products

• IT Management Suite
• Client Management Suite
• Server Management Suite

Issue/Introduction

This article will show how to setup the Agent Connectivity Credential (ACC) and also include Best Practices.  When the Application ID (App ID) is used to register with Task Servers and download packages, it can be locked out.  When the App ID is locked out it can create issues getting to the NS Console.  Creating an Agent Connectivity Credential can remediate this issue by providing another account for Task Server registration and package downloads to use. 

Environment

ITMS 8.x.

Resolution

To setup the Agent Connectivity Credential do the following:

Note: please refer to our online documentation as well: Global Agent Settings Page Link

1. In the console go to “Settings > Agents/Plug-ins > Global Settings” and select the “Authentication” tab.

2. Click the Radio button for “Use these credentials” and enter an account and password of your choice. Best Practice: this should not be a domain account. The agent will create this Local Account on the Site Server when the Agent does its next Update Configuration. It will ONLY be created on site servers. Sample Local Account: ACC_user.  Sample Domain account: Domain\User

Note: The UI is picky about password complexity. Use upper and lower case characters, numbers and symbols.

3. In the console go to “Settings > Notification Server > Site Server Settings”  then go under the “Site Server Settings” and select “Global Site Server Settings”

4. Enable the top two boxes:

• Create the Agent Connectivity Credential on Site Servers (provided the ACC is not a domain account)
• Re-enable the created local account if it has been locked out
  • For more details about "Re-enable the created local account if it has been locked out" and how it works, please see this KB: 150951

5. Update the agent configuration on all site servers including the SMP server. This will create the Account.  You could send an “Update agent configuration” Task.

6. See Best Practice Note #2 for the Folders where the ACC needs to have READ permission added.  HINT: Software Library, NSCAP share, and Patch Download location.

When the Agent on the Site Servers checks in, they will receive instructions to create a local account with the specified name and password. When the managed agents check in they will start authenticating to site servers using the local account that was created on each of the site servers.

As mentioned, creating the ACC will isolate the App ID service account from being used during registration for task servers and package downloads.  It also eliminates App ID service account lockouts because Agents are no longer using that account.

Best Practices:

1. Use a Local Account for the ACC, not a Domain Account.  This allows the Agent to create, monitor and manage the account.
2. If the SMP server is operating as a Task Server then it will create the local account. The new local account is used during package refresh cycles to update package codebases. Therefore the new local account must be granted at least READ permissions to the locations where the package files are located such as the Software Library, NSCAP share, and Patch Download location.  If these are all on the same Drive, then READ access can be added at the Drive level for simplicity.
3. When the ACC password is changed, the Site Servers and Agents must be updated before an agent can use the new password for Task Server registration and also Package Download.  If not the ACC account will lock out like other Windows accounts would do.  Therefore the Best Practice as recommended by Dev is to NEVER change the ACC password.  Instead - change the ACC to a new user account, and then update the Task Servers. As this is a new account, it is usually impossible to lock it out by having the wrong password. When the ACC user is changed we must also make sure it has READ rights on the SMP as mentioned in the previous paragraph.
4. If the ACC account does lock out after changing the User name, an investigation is needed into finding the system that locked it out and why.  Since the account should be Local, the Lock is reported in the Site Server's Event Logs where the account is locked.  Search the Event Logs for Event ID: 4740.
5. DO NOT enter the Application ID account information into the "Use these Credentials" option.  That is not necessary and breaks things.  If you want to use the App ID account for the ACC, please check the box "Use Application Credentials".
6. For more details about the option "Re-enable the created local account if it has been locked out" and how it can work better in your environment please see this KB: 150951

 

Additional Information

181466 Restricting Package Access Credentials