active directory

Building your own Virtual Appliances using OVF properties Part 3

03/19/2019 by William Lam 2 Comments

To conclude this three-part blog series, we are now going take a look at reference implementation for building your own Microsoft Windows Virtual Appliance (VA). Similar to the Linux VA build, the Windows OVA will also support the ability to customize basic networking configuration including the use of a static or DHCP option.

In addition, to demonstrate the endless possibilities for building your own VA, I have also included an option to automatically join a Microsoft Active Directory Domain as part of the OVA deployment, which is a fairly common operation after deploying a Windows-based system. In the example below, I am using Windows Server 2016 and PowerShell to perform all the required automation.

Step 1 - Create a new VM in vCenter Server and then install Window Server 2016 using the ISO. Once you have completed the OS installation, you may want to apply any patches or packages that you want included as part of your VA. Once that is done, go ahead and shut down the VM.

Step 2 - Select the VM in the vSphere Inventory and then click on Configure->vApp and then check the Enable vApp Options. Once enabled, select OVF environment for the IP allocation scheme. In the OVF Details tab, select VMware Tools for the OVF environment transport. (Optionally) You can specify some additional metadata including appliance name and URLs to help others who maybe consuming your VA once it has been exported to an OVF/OVA.

Step 3 - Next, add the following 9 OVF properties which will be used as input to configure networking within PhotonOS. Click Add and provide a Label, Key and optional Category.

Label	Key	Category
Hostname	guestinfo.hostname	Networking
IP Address	guestinfo.ipaddress	Networking
Netmask	guestinfo.netmask	Networking
Gateway	guestinfo.gateway	Networking
DNS Server	guestinfo.dns	Networking
DNS Domain	guestinfo.domain	Networking
AD Domain	guestinfo.ad_domain	Active Directory
AD Username	guestinfo.ad_username	Active Directory
AD Password	guestinfo.ad_password	Active Directory

Step 3 - Power back on the VM and once it is available on the network (assuming DHCP), download and copy the sample first boot script customize-guest.ps1 to C:\Users\Administrator\Desktop. This script is where all the magic happens and will process the OVF property input and then configure the network settings and if specified, it will also perform the Active Directory domain join. Right now it assumes the networking fields are optional, meaning if they are left blank, it will default the system to DHCP. If you provide all input properties, then it will go ahead and configure a static network address.

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.