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:

• 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!

Read More

VMware Identity Manager (vIDM) Web App Integrations

Our vIDM (FKA Workspace Portal) developers are hard at work delivering SAML-based SSO integration documentation for Web apps and other 3rd party identity provider integrations. Since previous versions of Workspace had a "This functionality exists.. so good luck!" mentality, I'm really excited to share a new landing page for these support resources:
https://www.vmware.com/support/pubs/vidm_webapp_sso.html 

At the time of this post, white papers are available for

• AirWatch Applications


• Office365


• Salesforce


• ServiceNow


• Webex


• vIDM and ADFS 2.0

Read More

Workspace Portal, Access Policies, and Kerberos authentication

You've decided it's time to expand your Workspace Portal deployment from internal-only, to also allow external access. You've setup your Load Balancer, gotten your certificates in place, and now you're tasked with configuring internal and external authentication methods.

This post covers the configuration needed for Kerberos on internal connections, while allowing username/password authentication from external connections.

Access Policies

First, let's setup your access policies. Access Policies allow you to specify criteria that users must meet in order to access Workspace Portal. We're going to configure the Default Access Policy Set to include two policies: internal and external

For our internal connections, we're going to utilize Kerberos. Configuring Kerberos isn't covered in this post, so ensure you have it working first. Here are some helpful posts for setting it up:

Configuring Kerberos for Workspace
Kerberos SSO in Workspace 1.8 (basic config flow still applies to Workspace Portal 2.1)

For our external connections, we'll let our users utilize their Active Directory synced username and passwords for authentication. Ensure your Directory Sync rules from the Connector Service Admin page include all desired AD groups and that they're synced regularly.

First: ensure you've created both an internal and an external Network Range:

1. Log into the Workspace Admin Portal > Settings > Network Ranges


2. Click + Network Range to add our internal range. Configure this to the appropriate subnets used in your LAN.


3. We'll use the default ALL RANGES entry for our external connections

Then, from the Policies tab, we'll edit the default_access_policy_set to correspond to these network ranges.

1. Click + Access Policy and name it internal. Set it to use a Minimum Authentication Score of 1. 


2. Then select the default 'web policy' which corresponds to our external network range. We'll set this to a Minimum Authentication Score of 2 as seen below:

NOTE: Be sure to re-arrange the policies so that internal is on top, and 'web policy' is on bottom and click Save.

Authentication method

Now, head to Settings > Authentiation Methods and order the options as seen here. Be sure to click each entry to edit the Authentication Score to match the below screenshot. Once again, order is important.

Notice that Kerberos is on top, with an authentication score of 1.

Set Kerberos as the Default Method

Password will be set to an authentication score of 2.

At this point, you should be able to verify that your user portal loads from both internal and external locations, as well as verify that your internal users aren't prompted for their credentials.

Troubleshooting

Scenario 1:

When launching Workspace Portal externally, the page times out and doesn't load, but internally it launches.

Scenario 2:

When launching Workspace Portal externally, the page loads, but internally, users are prompted for username and password (Kerberos fails to login the user)

   - In either case, verify the order of your Access Policies have Kerberos on top, password on bottom. Also verify that the scores are set appropriately, per the screenshots

Read More