Create vCenter user accounts
Configure users and roles for vCenter
To create service accounts for the Splunk for VMware solution, you first need to create vCenter users, create roles, and then assign the users to the roles. This topic shows you how you can do this for vCenter.
Create users
Obtain VMware vCenter Server account credentials for each vCenter Server system.
These credentials allow the Splunk Add-on for VMware read-only API access to the appropriate metrics on each vCenter Server system in the environment. the Splunk App for VMware uses the credentials when the DCN polls vCenter Server systems for performance, hierarchy, inventory, task, and event data. These credentials are required for DCN configuration. You can use existing vCenter Server account credentials, or create a new account for Splunk App for VMware to access the vCenter Server data.
You must have a user account to authenticate with vCenter. If you are using ActiveDirectory for authentication on your Windows OS (vCenter) machines and/or your ESX/i hosts, please skip to the "Make users in ActiveDirectory" section below.
If you add a new vCenter Server user as administrator, the user automatically gets an Administrator role in vSphere.
Create a local user on your Windows OS (vCenter) machine
Perform these steps to create a local user on each of your vCenter machines.
- Log into the Windows OS as an administrator.
- Go to Run
- Type "compmgmt.msc".
- Click OK to open Computer Management.
- Select Local user groups.
- Right click User.
- Select New user.
- Complete the requested fields.
- Deselect User must change password at next login.
- Select Create.
See Microsoft Windows documentation for further information.
Create users in ActiveDirectory
In a VMware environment, you can join your ESX/i hosts to an ActiveDirectory domain for authentication. Service accounts have to be created on all ESX/i hosts for the Splunk for VMware solution to work correctly. If any of your machines are not configured to use AD authentication, then you must create a "local" user on each one (see the relevant sections above for steps on how to do that).
For machines that are participating in an AD domain, you must create a service account in the given domain using the appropriate control panel in Windows Server. Most VMware environments use a single AD domain for authentication. However, if you are using multiple AD domains, then you must create a service account in each domain that your VMware environment is using.
How to create a service account within AD can vary depending upon your specific environment. Detailed steps are beyond the scope of this document. Contact your AD administrator to learn how to do this correctly for your environment. Here is an article that also may be helpful: http://technodrone.blogspot.com/2010/07/esxi-41-active-directory-integration.html.
After you have created the service account(s) in AD, you must create a role and map it to the service account you just created (in AD). The procedure is the same as that for creating local accounts. Follow the instructions in Create roles on each Esx/i host.
Create roles
You need to create roles on each vCenter machine.
Create a role on vCenter
To create a role on vCenter, see Create a Custom Role from VMware documentation.
vSphere requirements
The following are required permissions for vSphere.
Permissions to collect VC data using API calls
To collect vCenter performance metrics, the user account you provide on the DCS must have the following permissions:
- System.Anonymous
- System.Read
- System.View
The following permissions are required to update the configuration and use Syslog Service on Esxi hosts:
Permission |
---|
Global.Diagnostics |
Global.Licenses |
Global.Settings |
Host.Configuration.Change SNMP settings |
Host.Configuration.Hyperthreading |
Host.Configuration.Memory configuration |
Host.Configuration.Network configuration |
Host.Configuration.Power |
Host.Configuration.Security profile and firewall |
Host.Configuration.Storage partition configuration |
Sessions.View and stop sessions |
System.Anonymous* |
System.Read* |
System.View* |
Click OK and you should see your role in the list of roles. If so, then you're done!
Note: For user-defined roles, the system-defined privileges "System.Anonymous", "System.Read", and "System.View" are always present.
Permissions to use your own syslog server
Best practice dictates that use your own syslog server, and that you install a Splunk Enterprise forwarder on the server to forward syslog data. Use these permissions to collect data from the ESXi hosts using your own syslog server. These system-defined privileges are always present for user-defined roles.
Permission |
---|
System.Anonymous |
System.Read |
System.View |
Permissions to use an intermediate forwarder
Use these permissions if you configure your ESXi hosts to forward syslog data to one or more intermediate Splunk Enterprise forwarders. Use the vSphere client to enable the syslog firewall for the specific hosts.
Permission |
---|
System.Anonymous |
System.Read |
System.View |
Host.Configuration.AdvancedConfig |
Assign users to roles
- In the vSphere client and connect to the vCenter or ESX/i host that contains the user and role you created and now want to link together.
- On an ESX/i host or a vCenter, go to the Home > Inventory > Hosts and Clusters.
- Right-click on the root object in the tree on the left and click "Add Permission" from the context menu.
- On the left of the Assign Permissions window, under Users and Groups click Add... .
- Select the user you wish to assign a role to (e.g. splunksvc) from the list box and click Add then click OK.
- On the right of the Assign Permissions window, under Assigned Role select the role you wish to assign to the user from the pull down menu (e.g. splunkreader).
- Make sure the Propagate to Child Objects check box is ticked, without it your user will not have all of the necessary permissions.
- Click OK and verify that your user is listed on the permissions tab and has the role you assigned.
Verifying log in credentials
Now that you have have service accounts set up on each VC and ESX/i host in your environment, you can verify that you set up your user credentials correctly for each one. To test that your credentials work correctly on a target machine, you can point the vSphere client at the machine or you can use a web browser to access its Managed Object Browser (MOB).
To validate credentials for a target machine using the MOB, provide the initial URL of that machine (hostname) with /mob appended to the end:
https://<IP or DNS hostname of vCenter server or ESX/i host>/mob
You will be presented with a login dialog box, similar to the one shown here:
In some cases you may need to "add a security exception" in the browser to display the login dialog box. For the specific VC or ESX/i host that you are verifying, enter the corresponding username / password combination for that VC or ESX/i host.
Important: Do this validation step for each VC or ESX/i host that you created a service account for in the steps above. Creating a service account for a VC and validating that it works on the VC does not mean that it will also work on the ESX/i hosts in your environment. VC and ESX/i hosts have completely independent security subsystems. You must do the creation / mapping steps, as shown in this topic, for each VC and ESX/i host independently, and validate each one independently.
The service account credentials (username / password) you use to access the MOB are the same credentials used by the FA to get VMware data. You will use these credentials in your engine.conf and / or credentials.conf file(s) in a later installation step. If the credentials are not properly verified, the solution will not work properly. Although login problems are placed into the solution logs, they are nonetheless a pain to diagnose after the fact. It is much easier to make sure the service account credentials work properly beforehand.
If your login is not successful, then it will simply display the login box again with no further indication of failure. Try re-entering your username / password combination a few times to ensure that a typing error is not preventing you from accessing the MOB. If your login remains unsuccessful, retrace the steps you followed to create the service accounts. Multiple failures usually indicates that there was a problem setting up the credentials when you created the user account, role, or mapping the permissions. Re-trace your creation steps (above) for this particular machine to fix the issue.
If you are successful logging into the MOB, then a Web page similar to the following is displayed for each VC or ESX/i host:
Congratulations! Your service account is set up correctly! Now just remember to do this for each VC and ESX/i host that you will add to the Splunk for VMware Solution and you will be all set.
Note: You can also test that you created valid user credentials by logging into the VC machine or ESX/i host using the vSphere Client. If you can point the vSphere Client at each machine and log in successfully using the corresponding credentials, then you have correctly set up the service account. If is effectively the same as logging into the target machine's MOB.
About the Splunk App for VMware | Platform and hardware requirements |
This documentation applies to the following versions of Splunk® App for VMware (Legacy): 4.0.2
Feedback submitted, thanks!