active directory

Can I assign my Active Directory users a non-CloudAdmin vCenter Server role in VMC?

10/08/2018 by William Lam Leave a Comment

In VMware Cloud on AWS (VMC), when a user is logged into vCenter Server, they are not running as the Administrator role like you might in an on-prem vSphere environment but rather a restrictive vCenter role called CloudAdmin. The reason for this is that VMware is responsible for managing the infrastructure, including the management software and we want to make sure customers do not accidentally make changes that could affect those operations. More importantly, with VMC being a service, customers can now focus their attention on the consumption of resources in VMC and leave the maintenance of the infrastructure for VMware to manage.

Note: For those interested, you can find the complete list of vCenter privileges for the CloudAdmin role here.

The ability to create and consume custom vCenter roles has been an extremely powerful capability of vCenter Server and although this is currently not possible in VMC, it is something that is actively being worked on. With that said, many of the requests that I have seen in regards to this topic has actually been about consuming some of the default vCenter roles. This is especially true for the "Read Only" role which is useful for auditing and monitoring purposes. As a CloudAdmin user, you can assign default vCenter roles that either have equal or lesser privileges than the CloudAdmin role which also includes the default "Read Only" vCenter role.

Configuring Active Directory integration with VMware PKS Ops Manager using VMware Identity Manager (vIDM)

04/27/2018 by William Lam Leave a Comment

When configuring Ops Manager for VMware Pivotal Container Service (PKS) from an Authentication standpoint, you can either chose local authentication or use an external identity provider. The former means you are managing local users that reside within the User Account and Authentication (UAA) component of Ops Manager, which may be okay for a lab or proof of concept environment. However, for a Production deployment, most customers prefer to use their enterprise directory services which is typically Microsoft Active Directory.

Ops Manager can integrate with a number of external identity providers as long as it can speak SAML. For VMware customers, the preferred identity provider solution is VMware Identity Manager (vIDM) which not only supports Active Directory, but can also support a number of other directory service integrations like Active Directory Federation Services (ADFS) as example. Since vIDM supports SAML-based authentication, we can configure Ops Manager to use vIDM which also means we benefit from all of the enterprise Single Sign-On capabilities that vIDM delivers, including things like multi-factor authentication which can provide an additional layer of security when connecting to your PKS infrastructure.

Since there is currently no documentation on how to set this up, with the help of my colleague Blair Fritz and Assaf from the vIDM Engineering team, we have documented the process below which outline the required steps to integrate Ops Manager with vIDM.

Changing “Password will expire in X days” notification for Active Directory users in vSphere Web/H5 Client

11/17/2017 by William Lam Leave a Comment

When logging into the vCenter Server using either the vSphere Web (Flex) or H5 Client, one of the validation checks that is automatically performed by the server is to check the current users password expiry. If you account expiry is less than the current password expiry configuration, then you will see the yellow notification pop up at the top stating:

Password will expire in X days

This is definitely a helpful feature to have automatically built into the vSphere UI and the default expiry actually depends on the type of user logging into the system. This last part is sometimes confusing as folks mix up the default Single Sign-On User Expiry with the Active Directory user expiry which is completely different.

Single Sign-On Users

For SSO Domain (vsphere.local by default) users, the password expiry AND notification by default is 90 days. This can be configured in the vSphere Web Client under Administration->Single Sign-On->Configuration->Password Policy as shown in the screenshot below. For those wanting to automate this configuration, there is currently not an SSO Admin API, but there are some options, have a look at this blog post here.

Active Directory Users

If you are logging in as an Active Directory user, the password expiry notification by default is 30 days but the actual password expiry will obviously depend on your Active Directory system. If you want to change the expiry notification in case your expiry is not 30 days or you wish to notify sooner or later, this is actually controlled by the vSphere Web and H5 Client.

Enabling shell access for Active Directory users via SSH to vCenter Server Appliance (VCSA)

10/09/2017 by William Lam 4 Comments

I had a question the other day on whether it was possible to enable shell access for Active Directory users when logging into the vCenter Server Appliance (VCSA) via SSH? The answer is yes and though this is documented here, it is not very clear whether this is only applicable to SSO-based users only. In any case, the process to enable this is pretty straight forward and simply requires two steps which I have outlined below.

Step 0 - Ensure that your VCSA and/or PSC is joined to Active Directory before proceeding to the next step. If not, take a look at the documentation here for more details.

Step 1 - Login to vSphere Web Client and under Administration->System Configuration->Nodes->Manage->Settings->Access, go ahead and enable boh SSH and bash shell options. The first setting turns on SSH to the VCSA and the second setting allows users (local, SSO and AD) to access the shell on the VCSA.

Step 2 - In the vSphere Web Client and under Administration->Single Sign-On->Users and Groups->Groups, select the SystemConfiguration.BaseShellAdministrators group and add either an AD User and/or Group that you wish to allow to access the shell.

Once you have completed the steps above, you can now SSH to your VCSA/PSC using the AD user (UPN format) that you had authorized earlier. In the example below, I am logging into one of my VCSA using user primp@primp-industries.com and as you can see, I am placed into the appliance shell by default.

At this point I can access all the appliancesh commands just like I normally would if I had logged as a root or administrator@vsphere.local.

If we wish to change to bash shell, we simply just type "shell" which will enable shell access, assuming you had performed Step 2.

One thing that I noticed is that the default home directory for the AD user is /var/lib/nobody and apparently that does not exists by default, so users end up in / directory by default after enabling shell access. I am not sure if this is also related, but the username shows up as nobody as you can see from the prompt. This is something I will share with Engineering to see if we can improve upon as I am sure most of you would rather see the user that is actually logged in.

The good news from an auditing and logging standpoint is that for operations that are logged, it does properly show the username even though the prompt is showing up as nobody.

All replicated Platform Services Controller should be joined to Active Directory

06/16/2015 by William Lam 4 Comments

Last week a colleague of mines was setting up a new vSphere 6.0 environment which contained a vCenter Server with an external Platform Services Controller (PSC) for our Management vSphere Cluster and another vCenter Server also with an external PSC for our Compute vSphere Cluster. The PSC's were configured to replicate with each other which meant they were part of the same SSO Domain providing us with the new Enhanced Linked Mode (ELM) feature that was introduced in vSphere 6.0.

With ELM, you can now easily view all of your vCenter Servers by logging into either of the vSphere Web Client Servers provided by any of the vCenter Servers that are connected to the replicated PSCs. In addition to providing a single view into your vSphere environment, data such as Licensing, Tags, VM Storage Policies, Roles/Permissions & Affinity/Anti-Affinity Rules to name a few are also replicated and made available to all the other vCenter Servers.

As part of the initial setup, my colleague had joined the first PSC (psc-01) to our Active Directory domain after completing the deployment of the VCSA, as the vSphere Web Client was required to make further changes to the PSC. The question that my colleague had was whether or not additional PSC nodes were required to be joined to the same Active Directory domain or would it automatically be handled by the PSC replication?

This was actually a great question and in fact something that could easily be overlooked or at least until you try to login using an Active Directory account and can not. What you will notice when going to the SSO Admin Configuration screen is that the Active Directory Identity Source has been added, so I can see why one would assume this would automatically be handled. If we take a closer look at my home lab environment and the Active Directory configuration within each of the PSC, we will see why this not the case.

If we take a look at the Active Directory configuration for psc-01, we can see that it is part of our AD Domain and the "Join" option is grayed out.

If we now take a look at psc-02, you will see that the Active Directory configuration is empty and the option to "Join" is still available.

To resolve this problem, you just need to add the additional PSC nodes to Active Directory and then reboot for the changes to go into affect. The PSC's also support different Active Directory domains as long as a trust relationship exists between the two, for more details take a look at this VMware KB 2064250. It should also be noted that this should not be an issue for those deploying a Windows based vCenter Server since it is usually a best practice to joined the Windows system to an AD Domain prior to installing additional software on top.

Easily automate ESXi 6.0 Active Directory join using domainjoin-cli

04/06/2015 by William Lam 8 Comments

A nice little enhancement that I recently came across in ESXi 6.0 is the inclusion of the Likewise utility called domainjoin-cli which allows you to join a system to an Active Directory Domain. Previously, if you wanted to automate the process of joining an ESXi host to an Active Directory Domain, you had to either manually configure it using the vSphere Web/Client, using Host Profiles or creating an external script using the vSphere APIs.

All of these options were mostly executed during the post-provisioning process and if you wanted to include Active Directory configuration as part of the provisioning process, you may have had to resort to something like calling into the vSphere MOB within a Kickstart script as I had shown back in 2011 in this article here. The solution I came up with was not ideal but it worked for those that did not want to have additional steps after initial provisioning.

With the domainjoin-cli utility now included in the ESXi Shell of ESXi 6.0, you easily automate the joining an Active Directory Domain with just a couple of lines added to your Kickstart or provisioning scripts. Before you can use the command-line utility, you will need to ensure the Likewise Service Manager Daemon is running by running the following two commands which will start the service and also ensure the service automatically starts up:

/etc/init.d/lwsmd start
chkconfig lwsmd on

Next, to join to your Active Directory Domain, you will need to specify the following 3 parameters:

join - Specifying the operation is a join versus a leave
AD Domain Name - Active Directory Domain to join
AD Username - Active Directory username to join to the domain
AD Password - Active Directory password to join to the domain (optional as you will be prompted if it is not specified)

Here is an example of what the command looks like joining my Active Directory Domain in my lab:

/usr/lib/vmware/likewise/bin/domainjoin-cli join primp-industries.com administrator [PASSWORD]

You should see a success message if the ESXi host was successfully joined to the Active Directory Domain and you will want to reboot your ESXi host for the changes to take full effect. This is definitely a simpler method to include into an ESXi Kickstart script to automate the joining of an Active Directory Domain and hopefully you will find this handy when using ESXi 6.0.