- How to use VMware vSAN ReadyNode Configurator - Fri, Dec 17 2021
- VMware Tanzu Kubernetes Toolkit version 1.3 new features - Fri, Dec 10 2021
- Disaster recovery strategies for vCenter Server appliance VM - Fri, Nov 26 2021
You can also configure vCenter Server 7 to authenticate the connection via your Microsoft Active Directory (AD), so any users that you'll grant access to part of your vSphere infrastructure will not need to remember new login/password combination, but will use the Windows session credentials.
Single Sign-On allows different vSphere components to communicate with each other via a secure token mechanism (SAML).
The SSO domain that you create when you first install vCenter Server is the default identity source of the vSphere environment. You can set the Microsoft AD integration afterwards. VMware SSO allows not only Active Directory authentication, but also any other Security Assertion Markup Language (SAML) 2.0–based authentication source.
New in vSphere 7.0, vCenter Server supports federated authentication to sign in to vCenter Server.
Single Sign-on uses several services
- Authentication of userss—Users are authenticated through either an external identity provider federation or the vCenter Server built-in identity provider. The built-in identity provider supports local accounts, Active Directory or OpenLDAP, integrated Windows authentication (IWA), and other authentication systems such as smart card, RSA SecurID, and Windows session authentication.
- Authentication of solution users through certificates.
- Security Token Service (STS)—This service issues the SAM tokens representing a user's identity.
- SSL for secure traffic.
SSO Configuration: Identity providers and sources
Open your vSphere web client and connect to your vCenter Server 7, then go to Shortcuts > Administration.
Access VMware SSO via Administration
Click the Single Sign-On section and Configuration. On the Identity provider tab, click Active Directory Domain > Join AD.
Join Microsoft AD
Enter your Microsoft domain and OU (optional). After entering your Microsoft AD credential, you'll need to reboot.
I thought that VMware is better than Microsoft, but both vendors' products need a reboot when changing Microsoft AD specifications, changing domain, going from workgroup to domain, etc.
Join Microsoft AD and reboot the appliance
If you do not join the VCSA to Microsoft AD, you'll get the following message when you want to change the identity source:
You can't continue because the vCenter Single Sign-On server is not currently joined to any domain.
Change identity source type
After a reboot, go back to the identity sources. You should now be able to pick the Microsoft AD.
I found it quite convenient when working on a Windows workstation attached to a Microsoft domain to simply tick the check box "use Windows session authentication" when connecting to vCenter Server.
If the checkbox is grayed out, you'll need to install the Enhanced Authentication Plug-in.
Use Windows session authentication is grayed out
The Enhanced Authentication Plug-in enables:
- Accessing the VM console
- Deploying OVF or OVA templates
- Transferring files with the datastore browser
- Using Windows session authentication
Note: If you configure vCenter Server to use federated authentication with Active Directory Federation Services, the Enhanced Authentication Plug-in only applies to configurations where vCenter Server is the identity provider (Active Directory over LDAP, integrated Windows authentication, and OpenLDAP configurations).
Back to our SSO identity provider configuration, where you can see how I'm adding the Microsoft AD as the identity source type.
Add Microsoft AD as the identity source type
Users and groups
Users and groups is also found in the same section. We can have a look at the Local Accounts tab. On the Local Accounts tab, you'll see different options where you can change the password policy or password expiration lifetime.
By default, users are locked out after five consecutive failed attempts in three minutes, and a locked account is unlocked automatically after five minutes. You can change these defaults using the vCenter Single Sign-On lockout policy.
You should know that many of these groups are internal to vsphere.local domain or give users high-level administrative privileges. You should only consider adding users to those groups after cautious consideration of the risks.
You should never delete any predefined user or group.
Possibility to change local password policy
vCenter Server object hierarchy
All objects in the vCenter Server hierarchy can carry permissions that are assigned by you. You can pair a user and a role with the object. For example, you can select a resource pool and give a group of users read privileges to that resource pool object by assigning them a specific role.
However, for some services that are not managed by vCenter Server directly, you'll need to be a member of certain SSO groups that determine the privilege. For example, a user who is a member of the Administrators group can manage vCenter Single Sign-On. A user who is a member of the CAAdmins group can manage the VMware Certificate Authority, etc.
Example of CAAdmins group
Final thoughts
vCenter Server 7 has very complete management of identity sources and providers. We have also looked at some basics of SSO groups and users. However, I'd strongly recommend reading other lessons from our free study guide and also getting the complete VMware documentation set for vSphere 7.
The study guide will help you to pass VMware Certification VCP-DCV 2020 based on vSphere 7. The whole study guide, available here, helps you master all the topics to become VMware Certified.
