VMware Cloud Community
jddias
VMware Employee
VMware Employee
Jump to solution

vCM created accounts - can they be modified?

A security scan turned up two user accounts created by vCM install -

CSI_COMM_PROXY_USR

ECMSRSUser

We are being requested to have these accounts comply with password policy but my concern is that this would break vCM.  Can anyone confirm this?

Visit my blog for vCloud Management tips and tricks - http://www.storagegumbo.com
Reply
0 Kudos
1 Solution

Accepted Solutions
kmenze
Contributor
Contributor
Jump to solution

jddias,

You can delete the CSI_COMM_PROXY_USR account.  I have replaced it successfully with a domain account.  Here are the steps I go through to make my domain account work.  Note, this is for a stand-alone Agent Proxy machine, you'll need to adjust accordingly if you are doing this on your collector:

  1. I do make it member of the local administrators group (may not be required, haven't tested it without doing this)
  2. I add the domain account to the local CSI_COMM_PROXY_SVC group.
  3. Grant full control permissions to where the VCM agent is located.  In my case, I have stand-alone agent proxy machines (I don't use the collector).  You'll see the CSI_COMM_PROXY_USR already had full control permissions here.  Revoke the permissions for the CSI_COMM_PROXY_USR account and grant full control to the domain account.
  4. Grant full control permission to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Configuresoft (assuming you are on an x64 operating system, if not, then HKEY_LOCAL_MACHINE\SOFTWARE\Configuresoft).  Again, you'll see CSI_COMM_PROXY_USR already had permissions, revoke that and grant the full control to your domain account.
  5. Change the service account on the CM Communication Proxy service to use your domain account and cycle the service.
    1. If the Service won't stay running, double check the permissions from steps 3 & 4 above
    2. If the service stays running, I delete the CSI_COMM_PROXY_USR account at this point.
  6. Restart the server
  7. Log on to the server with your domain account.
  8. Follow the steps to create new AgentProxy keys
  9. Import the new AgentProxy keys into the collector
  10. Update the SSH key on the ESX hosts, you can just append the key from the servername_ssh_public_key.txt ino the authorized keys file in /home/csi_acct/.ssh on each ESX host collected from this Agent Proxy.
    1. Note, you can add multiple ssh keys to this file.  In our case, we have like 15 agent proxies.  We have all the keys in this file that we put on each ESX host. 
  11. Repeat the above for each agent proxy server you have.
  12. On my collectors, I disable the CM Communication Proxy service, remove the CSI_COMM_PROXY_USR account and change it to local system then stop the service.

This will take care of your CSI_COMM_PROXY_USR account.

The ECMSRSUser account is a different story.  This account is hard coded in VCM.  I found this documented in the release notes for both 5.3 & 5.4.  Here's the link for the 5.3 release notes:  http://www.vmware.com/support/vcm/doc/vcm_53_release_notes.html.  Just search for ECMSRSUser on that page.  This hard coded account is still used in 5.4.1, but, it's not in the release notes any longer.

In our case, we have a security policy against local accounts on servers, so, this causes us an issue.  I worked with support on this when this account was first added to VCM.  While it's not supported, you can delete this account.  You just need to make sure to add appropriate permissions into SSRS on your collector into the ECM Reports folder.  You can use a domain group, authenticated users, or domain accounts, whichever works for your environment.  You'll need to grant content manager permissions.  This solution "works" for us.  Note, you will get security events anytime a SRS page is access from within VCM, as VCM will still try to use the ECMSRSUser account, but, as long as the SSRS permissions are in place, everything still works.   I have not fully validated this continues to work with 5.4.1, so, make sure to test this.  I did find the ECMSRSUser account must exist if if you want to use the Import/Export gui tool to export reports (the command line ecmie.exe tool doesn't have this dependency).

I have submitted an enhancement request to resolve this.  It can only help if others do the same  Smiley Wink.  We should be given the option to specify domain accounts for both of these at install times.  At the very minimum, the password for the ECMSRSUser account should not be hard coded.

I hope this this helps.

View solution in original post

Reply
0 Kudos
2 Replies
kmenze
Contributor
Contributor
Jump to solution

jddias,

You can delete the CSI_COMM_PROXY_USR account.  I have replaced it successfully with a domain account.  Here are the steps I go through to make my domain account work.  Note, this is for a stand-alone Agent Proxy machine, you'll need to adjust accordingly if you are doing this on your collector:

  1. I do make it member of the local administrators group (may not be required, haven't tested it without doing this)
  2. I add the domain account to the local CSI_COMM_PROXY_SVC group.
  3. Grant full control permissions to where the VCM agent is located.  In my case, I have stand-alone agent proxy machines (I don't use the collector).  You'll see the CSI_COMM_PROXY_USR already had full control permissions here.  Revoke the permissions for the CSI_COMM_PROXY_USR account and grant full control to the domain account.
  4. Grant full control permission to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Configuresoft (assuming you are on an x64 operating system, if not, then HKEY_LOCAL_MACHINE\SOFTWARE\Configuresoft).  Again, you'll see CSI_COMM_PROXY_USR already had permissions, revoke that and grant the full control to your domain account.
  5. Change the service account on the CM Communication Proxy service to use your domain account and cycle the service.
    1. If the Service won't stay running, double check the permissions from steps 3 & 4 above
    2. If the service stays running, I delete the CSI_COMM_PROXY_USR account at this point.
  6. Restart the server
  7. Log on to the server with your domain account.
  8. Follow the steps to create new AgentProxy keys
  9. Import the new AgentProxy keys into the collector
  10. Update the SSH key on the ESX hosts, you can just append the key from the servername_ssh_public_key.txt ino the authorized keys file in /home/csi_acct/.ssh on each ESX host collected from this Agent Proxy.
    1. Note, you can add multiple ssh keys to this file.  In our case, we have like 15 agent proxies.  We have all the keys in this file that we put on each ESX host. 
  11. Repeat the above for each agent proxy server you have.
  12. On my collectors, I disable the CM Communication Proxy service, remove the CSI_COMM_PROXY_USR account and change it to local system then stop the service.

This will take care of your CSI_COMM_PROXY_USR account.

The ECMSRSUser account is a different story.  This account is hard coded in VCM.  I found this documented in the release notes for both 5.3 & 5.4.  Here's the link for the 5.3 release notes:  http://www.vmware.com/support/vcm/doc/vcm_53_release_notes.html.  Just search for ECMSRSUser on that page.  This hard coded account is still used in 5.4.1, but, it's not in the release notes any longer.

In our case, we have a security policy against local accounts on servers, so, this causes us an issue.  I worked with support on this when this account was first added to VCM.  While it's not supported, you can delete this account.  You just need to make sure to add appropriate permissions into SSRS on your collector into the ECM Reports folder.  You can use a domain group, authenticated users, or domain accounts, whichever works for your environment.  You'll need to grant content manager permissions.  This solution "works" for us.  Note, you will get security events anytime a SRS page is access from within VCM, as VCM will still try to use the ECMSRSUser account, but, as long as the SSRS permissions are in place, everything still works.   I have not fully validated this continues to work with 5.4.1, so, make sure to test this.  I did find the ECMSRSUser account must exist if if you want to use the Import/Export gui tool to export reports (the command line ecmie.exe tool doesn't have this dependency).

I have submitted an enhancement request to resolve this.  It can only help if others do the same  Smiley Wink.  We should be given the option to specify domain accounts for both of these at install times.  At the very minimum, the password for the ECMSRSUser account should not be hard coded.

I hope this this helps.

Reply
0 Kudos
abbie11
Enthusiast
Enthusiast
Jump to solution

HI Jddis ,


Welcome to vmware fourm.,


yes you can modify for that please follow below steps if need more please get back to us


1) Stop the agent (on Windows open cmd prompt "net stop emxagent", on Unix <agent_home>/<version>/bin/emx_agentd.sh stop)
2) Remove <agent_home>/<version>/config/emx.properties and emx.properties.alt files (if present)
3) Open <agent_home>/<version>/config/bootstrap.properties file
4) Edit the baseURL line and replace the existing VCM Server name/IP with the new VCM Server's name/IP and remove all other non-commented lines
5) Save the modified bootstrap.properties file
6) Start the agent (on Windows open cmd prompt "net start emxagent", on Unix <agent_home>/<version>/bin/emx_agentd.sh start)
7) You will now see the agent on the Activations page on the new VCM Server

😎 Activate the agent from the UI

Yours, Abbie



Winning!