Hello,
My VC 2 server is not behind a firewall and is on one of my server segments. I'm starting to get concerned about having internal folks download and install the VIC without permission. I've poked around and put in a hack that limits access the the c:\docs & settings\All users\App data\VMware\VMware VirtualCenter\docroot\client\vmware-viclient.exe to only domain admins. I'm worried that the hack may cause issues with future upgrades. Is there an easier way to limit access to the Tomcat home page?
TIA,
Gary
Hi,
then your users still could download the VIC directly from the ESX Server.
Not exactly what you're looking for, but you could remove the download link from the Tomcat home page.
http://communities.vmware.com/click.jspa?searchID=2095362&objectType=2&objectID=608613
Well since the upgrades are only updated at the same time as the VC, I would simply turn the web access service off. The move the viclient install to some other protected folder.
Thx. I still want to allow app admins to get the their consoles via the mangled url as I can control inventory and tab presentation. With that said, disabling the web access won't work for me. However, pulling the executable off the docroot is better than what I have today.
Hi,
then your users still could download the VIC directly from the ESX Server.
Not exactly what you're looking for, but you could remove the download link from the Tomcat home page.
http://communities.vmware.com/click.jspa?searchID=2095362&objectType=2&objectID=608613
Does it really matter if someone downloads the VIC? Without proper permissions within VC, they probably can't even log in.
I think the basis behind your concern for people downloading the client, really isn't relevent in my opinion. Just control access to VC with security.
Troy, everything you said is understood. As Ghost mentioned above, it's more of a matter to keep folks away from the Tomcat start page. One misconfig with VC roles and permissions can lead to exposure. Since role reporting is only available via perl scripts, it makes audit and compliance a bit dicey.
PS - I forgot to cover Ghost's comments about getting the VIC from the hosts. The hosts are behind physical firewalls. 80 and 443 are locked down to specific destinations.
Message was edited by: gary1012
Gary,
Me again... I guess your threads on security capture my interest
Earlier we discussed reporting on roles, specifically dumping a report of their current state. Here, it seems you're interested in protecting against misconfigurations. I just tested a perm change and VC definitely logs the event. Therefore, to complete your compliance monitoring initiative, how about we generate reports whenever permissions change?
I just checked a dump of what VC logs, and the following "interesting" events are defined:
PermissionRemovedEvent, PermissionUpdatedEvent, PermissionEvent, PermissionAddedEvent, along with RoleUpdatedEvent, RoleRemovedEvent, RoleEvent, RoleAddedEvent
skearney posted a vmeventmgr.pl script that when fed the above list, should dump those events for a particular time period. It could be scheduled to query VC every five minutes and spool the results to an email list. I've not yet tried the script as I don't have some of the perl modules loaded that are referenced in that script, but I will shortly. Maybe this will help fill in some of the gaps?
Regards, J
Nice find Hicksj. You're single-handedly making me brush off the dust on my Perl books. I will certainly give this a try. Thx again!
Thanks. Just tested it and it appears to work just fine.
A quick tip... I'm running all my mgmt scripts off a RHEL5 box. The DateTime & DateTime::Format::ISO8601 modules are not included by default. Its been a while since I added modules... forgot about the handy "cpan" utility. Compiled/installed most of the dependencies by hand, which was a royal PITA. Then I remembered cpan - it detects and resolves deps quite quickly. SO much better
Sample output:
PermissionAddedEvent:
Permission created for vctest on VM1, role is Virtual Machine Power User, propagation is enabled
PermissionEvent:
PermissionRemovedEvent:
PermissionUpdatedEvent:
RoleAddedEvent:
RoleEvent:
RoleRemovedEvent:
RoleUpdatedEvent: