So, What Do We Currently Have?
At this point we have a functioning vCenter server containing a datacenter construct and a cluster with some ESXi servers. These are all authenticating using the built in SSO (Single Sign On) server and all networking is done via VMware Standard Switches (VSS). These should all be configured exactly the same for basic networking across all hosts.
We could go and start deploying VMs now and creating additional vmKernel ports to enable vMotion etc. BUT VSS configs are a pain to manage and scale out (as everything has to manually be configured identically) and dont provide anyof the advanced features or centeralised management that virtual Distributed Switches do (vDS). Also, you’d be hard pressed to find a real world deployment using just standard switches.
What We’re Going To Do Next?
This post is going to deal with one of two things that you should do right now as it’s far, far easier to configure these features before going forward than it is to try and change later when VMs are running and using all the vSphere features.
- Configure vSphere (ESXi and vCenter) to use domain authentication for added, more flexible, more real world security).
- Configure vSphere with a custom group to allow users to be given very specific roles and permissions.
We will configure advance networking in the next part of this series.
Why Are We Doing It?
Simple, because this is one of two changes to the basic config that are typical of what you’ll find in real world deployments and enable more features and flexibility in your lab whilst being easier to manage.
Stage 0: Stop the VCSA root Password From Expiring and Configure NTP
In this blog post we are going to configure the vSphere environment to use AD Authentication vs the inbuild SSO authentication. But what if something goes wrong and both authentication sources require remediation. Simple, you log in as root to your appliance and you can fix stuff. True, but…. By default the root password in VCSA will expire after a year which can leave you high and dry. It’s simple to fix so, before going any further, lets configure it to never expire.
Navigate to your VCSA’s admin web interface. This is a specialconfiguration interface with basic appliance settings. it’s avaialble at https://<VCSA-Appliance>:5480
Log on to the appliance’s web configuration interface using the root user and the password defined in the setup script from Part 2 of this blog series.
Navigate to Adminsitration and ensure that No is selected under Password Expiry Settings > Root Password Expires. Click Submit.
Now we can quickly configure the time service to the same values as we did for the ESXi hosts. Select Time from the menu and then the Edit button.
NOTE: For vSphere 6.7 you won’t need to do this as NTP is configured at deployment via the JSON parameter file.
Click on the dropdown for Mode and select NTP from the list of options.
Now enter uk.pool.ntp.org (Assuming this is the server you entered into the ESXi NTP configuration earlier) under the Time Servers area and click OK.
The VCSA is now configured to use NTP as it’s time source.
Stage 1: Configuring For Active Directory Authentication
What You’ll Need
In order to connect the VCSA to an Active Directory for authentication you’ll need to have an account in the Active Directory set up to allow vCenter to be joind to the lab domain. For this example I recomend creating a service account to perform this function.
I have created and will be using the following in this example: email@example.com
NOTE: It does not need to be an admin user as a standard AD account can join 10 computers to a domain. This is only going to join 1.
Join The VCSA To The Domain
Open a browser to https://<vCSA_Address>/vsphere-client/
Log on to the appliance using the firstname.lastname@example.org account and the password set up when you deployed the appliance.
From the Navigator pane select Administration to open the admin sub menu.
Select Deployment > System Configuration
This will open System Configuration. Select Nodes then hilight the VCSA from the list (of one). Now Select the Manage tab and click the Join button.
This will bring up the Join Active Directory window. Enter the information required to join the domain. In the example below:
- Domain: lab.local [The full name of the domain you wish to join]
- Organization Unit: <optional> [The DN path of the AD area you’d like the VCSA to be placed.
- User Name: email@example.com [the service account created earlier]
- Password: <password> [The password]
Unless there is an error noting obvious will happen. You will have to reboot the appliance to see the changes applied. Once it has rebooted, navigate back to the same place and notice that the domain is now listed as joined.
Now we should configure Active Directory as an Identity Source within vCenter. This will allow us to use domain credentials to logon to vCenter and control access via domain group membership. To do this navigate to Single Sign-on > Configuration and open the Identity Sources tab.
Click green plus to start the process to add an identity source.
the simplest method to use is the one listed below. So, in the Add identity source window, select Active Directory (Integrated Windows Authentication) option. Ensure the domain name is correct (i.e. the same as the domain we just joined inthe steps above). and select the Use machine account option. Clock OK. toadd the identity source.
NOTE: this will only work if the VCSA is joined to a domain already. This is what we achieved in the previous step so it will work for us.
We can now use Active Directory as an authentication source but, right now, we still need to configure vCenter to give permissions to users/groups to allow this to happen. Firstly off it makes sense to give a domain account administrative access to vCenter so we can stop using the firstname.lastname@example.org account.
Navigate to Single Sign-On > Users and Groups and select the Groups tab.
This window allows tyou to create a new group for use in vSphere or add users / groups in to an existing group. Scroll down and select the Administrators group (this is the default group vSphere has for high level access to vSphere). You’ll see that the only member of this at the moment is the accoiunt you’re logged in with right now.
Click the Add Member (under the Group Members heading). From the Domain drop down ensure you select the Active Directory domain you want (In our example lab.local). You can now select the user or group from the domain to add to the group. I’ve added both (shown below). If you’re following best practice you should probably create a group in Active Directory, add users to that group and add this group at this step.
Now, when we look at the group, we should see our new entries listed.
To test this worked log out of the web client and try logging back in as a domain user (as shown below. You have to use the format <user>@<domain>.<whatever> in VMware products
If Successful you’ll be back in the main Web Client window and you should be able to see and do whatever you want. You’ll also have your domain username shown in the top right
Stage 2: Creating Groups With Custom Permissions
Being able to add users and groups from SSO and a Windows domain to the built in vSphere groups is great and all that but, what if you want to offer more granular permissions or restrict a user / group to a single task in Virtual Center. This is where Roles/Global Permissions can come in handy.
What’s The Process Then?
Simply it’s this:
- Create a new group.
- Add Users and Groups to this group.
- Create a new role with custom permissions
- Assign the created group the new custom role
Create a New Group, Assign Users
As in stage 1 navigate to Users and Groups and the Groups tab. Now Create a new group by clicking on the green plus sign. In this example I’ve named it as below. This gives a good explination of the purpose of this demo.
Once the group is created add in a user from Active Directory that will eventually have the rights we’re about to define. In this example I have pre-created a domain account called No Access. It’s just a basic domain user account I’m going to use for this process.
Create a New Role In vCenter
Now Navigate to the Access Controls > Roles section of vCenters Administration settings. From here we will create a new role which simply has permissions to Create a Datacenter.
The Roles screen is displayed. Click the green plus to create a new role.
Name the role and assign the permissions you want granted to users of this role. In this example I’m Createing a role called Create Data Center and assigning only one permission, that of Create Datacenter. Click ok to create the role.
Assign Users This Permission
Now we need to assign this permission to users or groups. In this example we will assign the role to the previously created vSphere group (above). Navigate to Administration > Global Permissions.
Select the Manage tab and click the green plus to add the new permission. Note that this screen lists all the currently active permissions.
Now Add the previously created group from the vSphere.local domain (notice that this vsphere.local group contains lab.local users) and click OK.
Finally select the created Create DataCenter role from the dropdown on the right and click OK. You have now created a permissions group, added domain users to it, created and new role and finally assigned this role to the new group.
You can see the effect of this immediatly by simply logging out of the vSphere Web Client and logging back on again with the user assigned to the group. So, in this example, I would log back on with the NoAccess@lab.local user and I should find that I can log on but all actions on all objects within vCenter are now greyed out except for the ability to create a datacenter.
NOTE: In vSphere permissions are additive. So, if you add a user to the above Create DataCenter group but they are also a member of an admin group they will get all the administrative permissions as well as any specific others. Its worth remembering this.
next up we’re goingt o configure the advanced networking features of vSphere by configuring Virtual Distributed Switches and migrating our lab networking off the standatd switches.