what permissions does the VCA logon id need?

[Mark Butler_3]

I've got a repository and baseline set up. The servers can see the repository and everything works ok.

The problem is that the login id that I have to give managed server Version control agent doesn't seem to work unless it is an administrator of the Repository server.

I've tried using an id with "Power User" rights and it won't connect, as soon as I add the id to the admins group it works fine so its a permissions problem.

What permissions does the agent need to be able to do its function? Is it change-rights to a folder structure, is it "log on as a service" rights, etc. I can't find any info about it in the docs.

[jim goodman]

I believe you have to have local administrator rights to use the VCRM. The guide recommends creating a local user vcadmin. When I do installs I create an admin account specifically for VCA to VCRM access.

- Jim

[Mark Butler_3]

I don't think I made myself very clear. One the managed servers, when I configure the agent to point back to the central console server (the one with the repository) I have to give them a login id.

I created a local ID on the central console server and used the id when configuring all of the managed servers. Unfortunately the agent won't connect back to the central server unless the id is added to the administrators group of the central server.


Rereading it, I still don't think its clear - lets try some real names......
SIMSERVER = name of server running the Insight Manager service and containing the repository.

VCA-ID = local id created on SIMSERVER to allow the agents access to the repository.

SERVER1,2,3,4 = servers being managed.

When I update the VCA agent on SERVER3 I tell it to use SIMSERVER and VCA-ID.

The problem is that unless I add VCA-ID to the administrators group on SIMSERVER, the VCA agent won't connect. Putting VCA-ID in the Power-Users group on SIMSERVER won't work.

It seems insecure to require every single server in the enterprise to use an id that has administrative rights over the entire central console.. but thats the only way i could get it to work. I was hoping there was another answer.

[jim goodman]

So the server 1,2 and 4 work fine?

In all instances of the latest VCA I have used it requires a username that is not 'administrator' and the id I would create needed to be added to the administrators group otherwise I could not access the VCRM from the selected VCA.

The idea of using a unique user id is so the administrator account one might use wouldn't get locked out.

It might not be clear in the manual. All I could find was: HP recommends that you create an account with administrator privileges to be used specifically
by the Version Control Agent.

If anything requiring admin rights is definitely infered.

- Jim

[Mark Butler_3]

Thanks for the info...

My opinion is that requiring an id to have administrative privledges on the entire server when all its doing is *reading* a folder full of files is preposterous.

It looks like we will not be able to use the version control agent in the production network, that will never fly with the security folks.

[jim goodman]

I understand your point, unfortunately I don't know enough about it's workings to answer the question that you pose.

I highly recommend you give that feedback to Hp. In your console go to Help --> About Hp Systems Insight Manager. Scroll Down and click the Tell Us About Hp Systems Insight Manager. That will bring up a 12 question survey and after the first 8 of general stuff you will be able to provide your input and satisfaction.

Hp does look at this as much of the product has been developed based upon customer feedback.

- Jim

[Rich Purvis]

Whoa - you do not need OS "administrator" priviledges for the VCA to login to the VCRM. It just has to have "administrator" or "operator" System Management Homepage priviledges - it is not the same thing. You can createa an ID called VCAdmin or as described in the doc VCOperator. Take that ID and put it into a user group called SMHAdmins (or whatever you want). You then configure the SMH that has the VCRM on it to give SMHAdmins group either SMH "administrator" or "operator" level authority within SMH - *not* the OS. VCAdmin userid and the SMHAdmins group do not need any special priviledges in the OS - hence you basically have non-priviledged ID's that you can use to run Version Control. They have the appropriate level of authority for SMH but they have none for the OS if that is how you want to set it up.

-Rich

[jim goodman]

Hey Rich thanks for jumping in - I said I couldn't say definitely, but I can say this: one of the last customers I worked with said he could not get the VCA to talk to the VCRM until we used a userid with administrator rights on the box.

Let me get this clear, because obviously its not.... it is based upon the SMH assigned group for administrator access to the SMH. So if the customer leaves the default SMH Group (local administrator) then the VCA needs to have an authentication via that group. If they would have done group SMHadmin for administrator access to the SMH then the VCA would need to authenticate thru that group... is that correct? Because the VCA manual sure doesn't spell that out unless I totally missed it. And support totally took my customer down a road of misunderstanding.

- Jim

[jim goodman]

Rich it is as you say - I tested it. I always thought that is how it did work because I set up groups in earlier engagments and it worked and I guess I let what this customer told me he got from support alter my understanding - I thought that is how it is now.

My apologies for the bum info.... that is why I like these forums here, the learning (and reproof)never stops.

- Jim

[Rich Purvis]

No apologies necessary Jim :). I may have to review the docs again, there are several things with SMH 2.0 and Version Control that appear confusing and may need further clarification. Thanks,

-Rich