Understanding Authentication in vRealize Operations
// This is a guest post by Jeremy (@nakedhitman)
vRealize Operations offers a number of options for user authentication and permission management, but does not do a great job describing the differences between them and why you should care. Most of the options are fairly easy to understand, but the vCenter authentication source is special and can easily cause confusion. Let's break them down and run through the differences:
The vCenter authentication source is enabled automatically when vCenters are registered and is one of the options for authentication on the vRealize Operations login screen. This causes a great deal of confusion for many users that are using their domain credentials and can log in without issues, yet cannot perform various tasks despite being an "administrator" in the vCenter and/or domain.
Even in situations where "real" authentication sources are configured properly, the vCenter authentication source may still cause confusion since it can present itself as the default, allowing domain users to log in with partial permissions if they are not paying close enough attention. Unfortunately, there is no way to disable the vCenter authentication source, nor to change the default, so you must make an effort to educate your users about the differences and to use the appropriate source when logging in.
Hopefully, this clarifies the differences between the authentication sources and allows you to choose the one that best suits your needs. If any of the above is unclear, please drop me a line in the comments. Thanks for stopping by!
vRealize Operations offers a number of options for user authentication and permission management, but does not do a great job describing the differences between them and why you should care. Most of the options are fairly easy to understand, but the vCenter authentication source is special and can easily cause confusion. Let's break them down and run through the differences:
- Local Shell Users
- Example: root
- These user accounts can not log in or be imported into the application UI.
- They can log in to the shell of the system via SSH or VM console.
- Local Application Users
- Example: admin, maintenanceAdmin, automationAdmin
- They can not log in to the shell of the system via SSH or VM console.
- The full range of permissions can be granted to local users.
- Active Directory / LDAP
- Example: youruser@yourdomain.tld, yourdomain\otheruser
- They can not log in to the shell of the system via SSH or VM console.
- Technically, AD and LDAP are the same technology, but with different presets. These sources allow users and groups to be imported from a domain so that they can log in with their common credentials.
- The full range of vRealize Operations permissions can be granted to imported AD/LDAP users and groups.
- SSO SAML
- Example: administrator@vsphere.local, youruser@yourdomain.tld, yourdomain\otheruser
- They can not log in to the shell of the system via SSH or VM console.
- Similarly to the AD/LDAP source, importing users from SSO allows you to assign vRealize Operations roles to domain users and groups. The advantage of using the SSO source is that if you have a complex domain configuration, you can use the existing configuration from SSO without having to re-implement your domain delegation and bindings in vRealize Operations.
- The full range of vRealize Operations permissions can be granted to imported SSO users and groups.
- vCenter
- Example: administrator@vsphere.local, youruser@yourdomain.tld, yourdomain\otheruser
- They can not log in to the shell of the system via SSH or VM console.
- Users from this source are not imported in the traditional sense and vRealize Operations simply trusts the vCenter when it says that a user has permission to log in and see objects.
- Because vCenter is responsible for assigning permissions, and because vCenter can only ever be aware of objects in its own inventory, it cannot grant permission to view or modify objects that are internal to vRealize Operations, nor to data that comes in to vROps from other sources.
- The vRealize Operations roles cannot be modified or expanded for users that come from the vCenter source from the vRealize Operations side.
- vCenter users are unable to create and schedule reports in vROps.
The vCenter authentication source is enabled automatically when vCenters are registered and is one of the options for authentication on the vRealize Operations login screen. This causes a great deal of confusion for many users that are using their domain credentials and can log in without issues, yet cannot perform various tasks despite being an "administrator" in the vCenter and/or domain.
Even in situations where "real" authentication sources are configured properly, the vCenter authentication source may still cause confusion since it can present itself as the default, allowing domain users to log in with partial permissions if they are not paying close enough attention. Unfortunately, there is no way to disable the vCenter authentication source, nor to change the default, so you must make an effort to educate your users about the differences and to use the appropriate source when logging in.
Hopefully, this clarifies the differences between the authentication sources and allows you to choose the one that best suits your needs. If any of the above is unclear, please drop me a line in the comments. Thanks for stopping by!