Garland Smith I suspect what you are encountering is the change made in the Agent between DES and AES security in the 10.0 release of the Agent.
See the following enhancement in the Patrol Agent 10.0 Documentation . I believe the Agent is supposed to be backward compatible by reading the older DES encrypted string and then re-encrypting it using AES but I have seen where this does not work for some of the KM's installed that also perform a password encryption to store a hashed password for use by the KM.
You might be able to use the default account scripts and see if that re-encrypts the correct password hash to make the 10.7 agent functional.
If you are upgrading the Agent to 10.7 why are you not using the 11.3 Agents that are available? See the following Patrol Agent Matrix for supported TSIM versions.
My questions were aimed at understanding forward and backward compatibility between 9.x and 10.x PATROL Agents regarding encrypted passwords, I wasn’t able to find much about that in the product documentation (if there is anything that documents that, maybe you can share the URL). There are a number of combinations and permutations to consider. What happens when a 10.x PATROL Agent receives a DES-encrypted password? What happens if a 9.x PATROL Agent receives an AES-encrypted password. Etc…
We have a fairly significant number of 9.6.xx PATROL Agents. Upgrading from 9.6.00 to 10.7.00 (or 11.3) will take a significant amount of time. It isn’t something where you can wave a magic wand and have all PATROL Agents in the enterprise upgraded in one fell swoop.
Other than being at the latest GA version, it’s not clear to me how it matters for this conversation whether we’re going to 10.7 or 11.3 since (I believe) both employ AES encryption. Let me know if there’s something that I’m missing here.
No. The issue was that for some reason, the PATROL Agent defaultAccount got lost from the secure configuration store. It’s only happened a couple of times. So far, I haven’t been able to determine why it happened. To fix the problem, we had to remove the PATROL Agent configuration entirely, restart the PATROL Agent, and then apply previous configurations. Fortunately, we have the required configurations in PCM.
I wasn’t able to find anything in the documentation that talks about this. If there is documentation for this, can you provide the URL?
I had comparable errors and I solved them by reapplying the /AgentSetup/defaultAccount variable from PCM with the old DES-encrypted password. The Patrol agent will convert the password to AES.
>> It’s only happened a couple of times. So far, I haven’t been able to determine why it happened
Correct me if I'm wrong but as far as I know PCM uses pconfig to fetch and update Patrol configuration settings. On our PCM server pconfig.exe version 9.6 is installed and that version does not yet support AES-encryption. We sometimes have the same errors as you have and we are going to upgrade the Patrol Agent on our PCM server to version 11 so that all the utilities support AES-encryption. Hopefully that will solve these errors.
I had a similar issue a few weeks back. I learned that this error means that the PATROL defaultAccount encrypted password somehow got lost from the secure store configuration file. Since, by default, the PATROL Agent defaultAccount is stored in $PATROL_HOME/lib/config.default, we were able to address the issue by removing all of the config files (including the secure store) from $PATROL_HOME/config and then restart the PATROL Agent and apply any applicable configurations.
In your case, reapplying the configuration using pconfig created a configuration override, which (apparently) corrected the problem (presumably) by storing the encrypted password in the secure store file.