Admin account getting locked very frequently in Altiris / Asset management Suite causing unable to use Admin account & tool

[Shiv Choudhary]

Altiris application's admin account is getting locked repetitively due to which we are unable to use Altiris asset management application. 

Earlier the account which we were using i.e., Altrisadmin, through which we were doing all the work related to the Asset management tool was getting locked frequently. So, as per the article shared earlier ( https://knowledge.broadcom.com/external/article/156852/changing-the-application-identity-accoun.html ) we have created separate AssetAdmin account in addition to the one created earlier. Now to solve the problem of account lockout , the new account Assetadmin that we have created is also getting locked.


Firstly we were using Altrisadmin account as an admin account , later once requested by support to create a separate account, created Assetadmin account to resolve the issue of admin account lockout but even after that admin account is getting locked .

We have tried all the steps suggested in the KB article https://knowledge.broadcom.com/external/article/156852/change-the-application-identity-accoun.html and also performed the last 7th step as suggested still account getting locked very frequently. 

If anyone have any idea about this plz let us know as we are unable to use Altiris application in our Environment due to the frequent account lockout .



1. Account lockout is started since we changed the password of Altrisadmin account and then created an additional account named Assetadmin but that new account is also getting locked repetitively and finally we are unable to use the tools/server because the account is getting locked frequently.

2. 8.5 version of SMP / Asset Management Solution we are using it in our environment

3. We have checked in other places that the new username and password is already updated in the hierarchy but let me know if we have to make any changes on the child server as well because we have 1 parent and 5 child servers in the hierarchy.

4. No stand-alone replication rules we are using in our Environment

5. Can you please help me check which tasks have specified custom credentials and review them for the affected domain account.


I have also checked connection profiles for different protocols and in WMI I found the earlier account i.e. had Altrisadmin credentials. I have checked it on Parent server. Do I have to check this as well and change the credentials to AssetAdmin on 5 child servers other than the parent server?

Yes, when my domain account password was changed in AD, I have opened a Symantec installation manager and specified a new password there and also configured it by following all the steps you suggested in the screenshot.

Currently the biggest problem we are facing is while taking RDP of the server, the administrator account is getting locked due to which we are unable to use the tool in our environment & getting below attached error .

IP: Actually there can be other things, that someone cached old password and tries to logon to SMP Console, reaching count of retries and causes account lock. Just my assumption.

SC: We have investigated the source of the account lock on AD and found that it is randomly coming from the field system which we are monitoring in the Asset management tool. We are observing multiple failed logins attempts from user Assetadmin. For past 24 hours we observed more that 1000+ different source hosts for failed logins. We have changed the password for the AssetAdmin account as suggested by the security team because the AssetAdmin account is getting locked too frequently and due to this we were unable to use the Asset management tool.

After changing the password it worked fine for a day or two but after that it is locking again.

Please let me know that when we change password from NS side, do we also need to update new password on all field machines because i think all field systems is trying to authenticate with old password and so we are getting multiple failed login attempts.

------------------------------
Shiv Choudhary
India
------------------------------

[Igor Perevozchikov]

Hi Shiv Choudhary!

1. When this account locking started? Was there recently password change in AD for this Domain account?
https://knowledge.broadcom.com/external/article/237958/authentication-connectivity-credential-a.html
https://knowledge.broadcom.com/external/article/157377/application-identity-account-lockout.html

2. What version of SMP/Asset Management solution you have?

3. If current NS AppIdentity account (domain account) recently changed password in AD, then need to check other place in SMP Console to make sure that this account wasn't manually specified with previous old password (if yes, need to type there a new password and save changes)

- If You have Hierarchy, right click on NS > edit and update password if there are used manual credentials

- Also if there are stand-alone replication rules with manual credentials specified, need to review them and update password if there is affected Account is used.

- Possible that there are some tasks which has domain account specified to "run as" and there is an old password used which causes account lock

   Here is a KB where you can check which tasks have a custom credentials specified and review them for affected domain account
    https://knowledge.broadcom.com/external/article?articleId=170069

- If you are using "CEM Gateway" and there is NS AppIdentity account is specified to send report data to your Notification Server, then need to open "Gateway Manager UI" on Gateway server and specify there new Domain Account password.

- Check AD Import rules, if they have manually specified this domain account there

- Check "Connection Profiles" for different protocols which are used for Network Discovery tasks, Agentless Monitoring, Virtual Machine Management solution.

- When your Domain Account password was changed in AD, did you open a Symantec Installation Manager and specified there a new password and configured it?

Best regards,
IP.

------------------------------
[JobTitle]
[CompanyName]
[State]
------------------------------

[Shiv Choudhary]

Hi Igor ,
Our client machines are constantly trying to connect to the NS child server and do not have an updated password. So they are continuously trying to contact NS with wrong password which is causing account locking again and again.
The Altiris account password NS clients (field systems) are using to connect back to the NS (Altiris child servers) contains incorrect password information.
Also plz tell me how can we update new password for all client machines in one go so that all machine connect with updated password whenever they connect to notification server.Let me know if we use the option Use these credentials & update here the new password then client machines will try contacting with the new password or not . Also how can we enter the username : username or Domain\username .

Also let us know the resolution of error that we are getting in the attached screenshot . 

------------------------------
Shiv Choudhary
India
------------------------------

[Igor Perevozchikov]

Hi Shiv Choudhary!

1. You mean that after 6 months, now agents start to lock account on that Child NS server again?
How you identified that this is exactly caused by Symantec Management agent?
There is a lot of other soft and places and actions which can cause account lock...

2. About "Global Agent Settings" page - Authentication tab

Agent Connectivity Credential

Lets you specify a username and a password that the Symantec Management Agent uses to connect to a secured resource. Use application credentials Use the application identity credentials that you specified on the  Processing  tab of the  Server Settings  page. Notification Server processing settings Use these credentials Specify the appropriate ACC user name and password. This account usually has a lower level of rights than the Application Identity account, and is a dedicated account created for use on package servers. The credentials that you specify must be a known account on Notification Server and every package server.

Specify there domain\username

3. To avoid error message in UI when you tried to save changes, need to change this core setting value.
Example:
Or change it from this place on NS:
C:\ProgramData\Symantec\SMP\Settings\CoreSettings.config
<customSetting key="ScheduleManagerInterop" type="local" value="1" upgradeIf="ne" />

4. In cases when Domain account always locked by someone, better to create a new domain account and use it as NS AppIdentity... Open Symantec Installation Manager and proceed with steps shown in previous comments above to apply new AppIdentity account.

Or reinstall agents on client computers as suggested in this KB https://knowledge.broadcom.com/external/article/157377/application-identity-account-lockout.html

Best regards,
IP.

------------------------------
[JobTitle]
[CompanyName]
[State]
------------------------------

[Shiv Choudhary]

Hi Igor , 

1) I have gone through all suggested points & after doing the changes(<customSetting key="ScheduleManagerInterop" type="local" value="1" upgradeIf="ne" />) in Coresetting.config file we are still getting the same error .

2) When we say this account usually has a lower level of rights than the Application Identity account , what does that exactly mean by lower level of rights ? 

3) IP- You mean that after 6 months, now agents start to lock account on that Child NS server again?
How you identified that this is exactly caused by Symantec Management agent?
Shiv -  As you can see in the below screenshot that there are still some systems which had Altiris agent installed and are authenticating with old user credentials which was Altrisadmin, currently we are using Assetadmin.

So, please let me know how we can update these systems with new user credentials that is Assetadmin?
Account lockout problem is never resolved in our environment and it has become a never ending thing for us , so kindly help us with it.

Also, I have noted one thing that as soon as office hours are over i.e., after 6-7 pm the admin account is not locked out whereas during office hours it gets locked within minutes or even faster.

It means that the source of account lockout is only from field machines and not from local server, because if some credentials are not updated at server end, then account lockout behavior should not behave like this & the account lockout incident would have uniform throughout the day & night .

I mean to say that as soon as the client machines are starting up in business hours (10 AM to 6 PM )  agent tries to authenticate with the Notification server continuously & account lockout start and it locks up so quickly that we are unable to use the tool during office hours.

------------------------------
Shiv Choudhary
India
------------------------------

[Igor Perevozchikov]

Hi Shiv Choudhary!

Since you have SMP 8.5 version (I thought that it is 8.5 RU4), so is there latest 8.5 POST RU4 cumulative point fix installed on all available SMP Servers?
You can check what Point fixes are installed on each SMP server from registry.
Do you have the same like on example below?

Here is a common KB https://knowledge.broadcom.com/external/article?articleId=232242 describing known problem that Agents weren't able to register with Task Server(s) due to error "The logon attempt failed (0x8009030C)"

If this issue is reproducible on your environment, then you need to download latest available point fix "SMA_SMP_8_5_POST_RU4_v11_23Feb_1658753544895.zip" from https://knowledge.broadcom.com/external/article/198337/cumulative-post-itms-85-ru4-point-fixes.html 
and install it on each SMP Server (This installed point fix will required to upgrade SMA on every managed client computer and Task Server on every Site Server.

Best regards,
IP.

------------------------------
[JobTitle]
[CompanyName]
[State]
------------------------------

[Shiv Choudhary]

Hi @Igor Perevozchikov ,

No such pointfix exists in the registry at our end. PFB screenshot.

------------------------------
Shiv Choudhary
India
------------------------------