What's Best way to lock down but give access

[abaum]

All,

I need to give my security team access to VC so they can do an audit. They really have no idea on how to use VC and all they really want to do is look at the user accounts and permissions I've created. Is there any way to give them read only access to this info?

adam

[jasonboche]

VirtualCenter allows fairly granular controls as far as permission sets for users who are going to access VirtualCenter. You can take a look at some of the role templates that come pre-packaged with VC2.x, or you can create your own custom role assigning least privilege. Obviously what access you need to grant all depends on what access they need.

My personal policy on Auditors: Give them as little access/information as possible

Jason Boche

VMware Communities User Moderator

[BryanMcC]

Not sure why you would need to give auditors access to VC at all. If these Security auditors need access have them use whatever remote control tool you use such as RDP. I usually dont even tell people that the machines I am running are VMs and I have never had anyone ask me to walk them to the datacenter so they can use the console.

Help me help you by scoring points.

[abaum]

The auditors want to audit VC/ESX, not the guests. Our folks want to audit who has access to VC and ESX themselves. I've given them read only access for now. I need to do some testing to see if I can create a read only role that only has access to permissions. Don't want the auditors to be able to see everything.

adam

[jasonboche]

Auditors don't have friends. Even the auditors that sign up with "Linked In", nobody will connect with them. :smileydevil:

Jason Boche

VMware Communities User Moderator

[hicksj]

Read-Only permissions at the root are not sufficient for monitoring security permissions, when using the VI Client. FYI, there is a perl script included in that dumps the Role assignments. It doesn't list how the roles are defined however. I wonder if it can be tweaked to do so, and with a user that has RO permissions. (just because the VIC doesn't allow it, doesn't always mean the permissions don't allow it via the SDK)

A system generated report is normally sufficient in most such audits - auditors typically don't want to (or know how to) work within the system anyway.

Regards, J

Note: a straight cut & paste of said script from the pdf won't fly. I cleaned it up and the attached seems to work ok on perl 5.8. It could also use a bit more cleanup, following some newer standards set by the default scripts included in the viperltoolkit... but don't have the time at the moment. I anticipate needing something similar in the near future, so I may work on expanding this audit script myself.

[hicksj]

Took a 'quick' look at what I was initially thinking... wrote a quick "dumper" script and you can definitely dump all the roles, and what their enabled privileges are. If you want to see raw data on all the privileges, privilege groups, roleLists, etc, take a look at the attached script.

I'd like to eventually put something together thats actually readable, from an audit perspective. A combination of the previous script along with information in 'roleList' should provide all that's needed. Problem is creating something that is "readable!"

Message was edited by: hicksj

Another quick note: what's nice about the scripting is that it is valid when executed against either the host or virtual center.

[JesseR]

I ran your printperm script and it did report back the information, however, it errored out with error:

Can't call method "isa" on unblessed reference at C:/Program Files/VMware/VMware

VI Perl Toolkit/Perl/lib/VMware/VICommon.pm line 887.

It did give back some information but I do not know if it reported back ALL information before it errored out. What is causing the error?

[gzulauf]

I'm having the same problem. Any solutions?