Trust Issues

[Steven Laux]

Hello,
I installed a new SIM 5.0 server. I'm having trouble with the trust relationship. I followed the steps in the SIM help titled "Setting up Trust Relationships". I created a new certificate, exported it, imported it on the SIM server an it worked fine. When I import it from the System Management Homepage on other servers, it imports. I then try a software status poll. The poll completes but when I look at the server status, it's still a blue (I). Any ideas?

[jim goodman]

I am assuming that this is under the sw column. Have you configured SNMP on the managed systems and also configured the VCA to trust the VCRM? and actually seen the VCA change to reflect the referenced support pack? The trust being spoken of there is the VCA to VCRM not the SSO.

- Jim

[Steven Laux]

We have multiple VCRMs that trusted our old 4.2 SP2 SIM. I'm trying to get the VCRMs to trust the new 5.0 CMS. I also tried to get a VCA from a non-VCRM to trust the CMS...no dice.

[Rich Purvis]

From what you have said it is not clear if you have configured your VCA's with login credentials to access the VCRM's - I think that may have been what Jim was getting at.

-Rich

[Steven Laux]

The VCAs are set up to access the VCRMs using an administrator service account.

[Rich Purvis]

Ok Steve, if you are using the actual ID "Administrator" that could be part of the problem. When the new System Management Homepage started using OS-based authentication the Version Control software was changed to start encouraging people not to use the Administrator ID. The new SMH will currently not allow version control to sign-in with the OS based ID "Administrator". If it is an upgraded VCRM that used to use the old Administrator/Operator/User ID's then it has a backwards compatibility that will allow it to work in this upgrade scenario. But the OS "Admiinistrator" will not work because of possible misconfiguration or other issues that might cause a huge number of failed logins on the Administrator ID and the fear that it might cause an lockout on the ID. You can use an administrator ID if you want - just not "Administrator". This should be discussed in this document here:
http://h200001.www2.hp.com/bc/docs/support/SupportManual/c00293375/c00293375.pdf

mostly in chapter 2.
If you are not using the "Administrator" id then you might want to look over the doc anyway just to make sure there is nothing else that may be causing you an issue.

-Rich

[Michael E. Matthews]

Just for the record, the Administrator ID cannot be locked out even if you have renamed it. There must have been some other concern?

[Rich Purvis]

Nope, you are correct about the Administrator ID, however that was part of the reasoning, even though it was faulty as it appears to be the only ID that does not lockout. There were numerous possible issues around the way Version Control operates that could arise in the transition from the old authorization model to the OS based login model that had to be addressed. Hence, it was decided that it was best to encourage people not use the Administrator ID or in fact any ID with OS administrator rights. As explained in chapter 2 of the doc it is best to create an ID that has basically no real rights within the OS, like VCAdmin. And then place it within a group with no specific rights like SMHAdmins. And then give the group SMHAdmins the equivalent "admin" authority within the SMH. This way you can use an ID that has "admin" rights within the apps for SMH but have no real rights within the OS, making it somewhat safer model of usage.

-Rich

[Steven Laux]

Thanks for the response, everyone. Rich, I am using a domain account with administrator privileges to log into the VCRM from the VCAs. I believe this issue has something to do with the certificates but I cannot figure out what the problem is. The VCAs are logging into the VCRMs without a problem.