VMware Authentication Proxy in a DoD Hardened Environment

If you work in IT in the DoD in any capacity, then you know your systems can be a pain to work with if you followed a Security Technical Implementation Guide (STIG). This can be even more of a pain when following a commercial vendor’s installation or configuration documentation, since they write in the general sense and can’t possibly know every quirk in our environment.

From the Windows Server 2016 STIG, (Finding ID: V-73691) the LAN Manager authentication level must be set to send NTLMv2 response only and to refuse LM and NTLM.

From the VMware vSphere 6.5 ESXi STIG, (Finding ID: V-94023) the ESXi host must use the vSphere Authentication Proxy to protect passwords when adding ESXi hosts to Active Directory.

So even though the current STIG is only referencing vSphere 6.5, this can still be used for newer versions. During the configuration of a vCenter Server 7.0 Authentication Proxy, I found that the proxy kept not authenticating. After reviewing the logs on the Domain Controller, it was found that Likewise was sending the authentication to the Domain Controller with an NTLM response and not NTLMv2.

Reconfigure the Likewise service to send NTLMv2 and try to configure the Authentication Proxy again. This time, the configuration should be successful. You can further test by adding an ESXi host to vCenter and ensure it properly joins the domain.

Before configuring NTLMv2 on Likewise

ref: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-DFA95E13-EC95-4951-B94F-6D08CCFAC188.html

  1. Click the ENABLE link.
  2. Click the EDIT link.

Fill in the Domain, Domain User, and Domain Password settings. Click the SAVE button.

Notice the Operation failed! message.

You can also view the log located at /var/log/vmware/vmcam/vmcam-sca.log. Below is an excerpt, notice the Enter password for Service.vSphereAuth line. That indicates that it was not sending the correct password because we know that we typed it into the window.

I ended up tailing the log with the following so I could see in real-time what was occurring.

tail -f /var/log/vmware/vmcam/vmcam-sca.log

Configuring Likewise to Send NTLMv2

Run the following bold commands, the rest is for context.

/opt/likewise/bin/lwregshell
\> cd HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM
HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM> list_values
    "SendNTLMv2" REG_DWORD 0x00000000 (0)
    "Support128bit" REG_DWORD 0x00000001 (1)
    "Support56bit" REG_DWORD 0x00000001 (1)
    "SupportKeyExchange" REG_DWORD 0x00000001 (1)
    "SupportNTLM2SessionSecurity" REG_DWORD 0x00000001 (1)
    "SupportUnicode" REG_DWORD 0x00000001 (1)
HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM> set_value SendNTLMv2 1
HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM> list_values
+   "SendNTLMv2" REG_DWORD 0x00000001 (1)
    "Support128bit" REG_DWORD 0x00000001 (1)
    "Support56bit" REG_DWORD 0x00000001 (1)
    "SupportKeyExchange" REG_DWORD 0x00000001 (1)
    "SupportNTLM2SessionSecurity" REG_DWORD 0x00000001 (1)
    "SupportUnicode" REG_DWORD 0x00000001 (1)
HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM> quit
/opt/likewise/bin/lwsm restart lwio
Stopping service reverse dependency: lsass
Stopping service reverse dependency: rdr
Stopping service: lwio
Starting service: lwio
Starting service reverse dependency: rdr
Starting service reverse dependency: lsass

Go back to vSphere Client and configure the Authentication Proxy again. You may have to disable and enable the service again if you didn’t restart the service while connected through SSH. This time, it should work without an error. If you are tailing the log, then you should see Active Directory domain added successfully at the bottom.

From here you can Import the vSphere Authentication Proxy Certificate to ESXi Host.

Change the Canonical Name (CN) of an Active Directory User

One of the most annoying things for me (and I assume many other Systems Administrators) is going into an organization and querying users to find all variations of name formats. Some are ‘first name last name’, ‘last name, first name’, or some other variation. It’s almost like an archeological dig where you can see periods of time that there was one format and then later on another format came along.

What’s frustrating is knowing how easy it is to change the format and that it doesn’t happen. It’s fine if the organization wants to change the format, but if that’s the case, then be sure to change the information already contained to match. There is nothing wrong with periodically running a “cleanup” script over Active Directory to make everything uniform. The great thing about Active Directory is that it is a database, it already contains the information. The DisplayName property and the cn are display properties, they can be changed whenever without affecting the user object. Also, running a script like the one below can clean up and make Active Directory uniform in a matter of seconds, if not less.

	# Where the users are located that you want to change
	$exerciseUsersOU = 'OU=USERS,OU=TEMPORARY,DC=aaronrombaut,DC=com'
	# An array of the users (adjust Properties as needed)
	$exerciseUsers = Get-ADUser -Filter * -SearchBase $exerciseUsersOU -Properties Title, GivenName, Surname
	
	# Loop through all the users
	foreach ($exerciseUser in $exerciseUsers)
	{
		$title = $exerciseUser.Title
		$firstName = $exerciseUser.GivenName
		$lastName = $exerciseUser.Surname
		
		# The following line will adjust the DisplayName
		Set-ADUser -Identity $exerciseUser -DisplayName "$lastName, $firstName, $title"
		
		# The following line will adjust the cn
		Rename-ADObject -Identity $exerciseUser -NewName "$lastName, $firstName"
	}

The following images show a before and after but are only a representation of what you can rename from and to. Your organization may use different naming standards. Either way, when standards change, be sure to adjust the objects already present. This will be much more professional and organized.

Before renaming the User
After renaming the User

PowerShell New-ADUser

Many Systems Administrators can attest that creating user objects can be fun…the first time. Then you begin to realize how daunting navigating through the ‘New User’ dialogs can be. Plus, once you are finished creating a user, you still have to add that user to the appropriate security groups. Sure, there are tricks and shortcuts like creating a disabled user template, but what if your organization has an abundance of security groups? Is it really worth all the effort to create a disabled user template for each potential group? Absolutely not!

PowerShell to the rescue, of course! Create a generic function that takes the common information needed anyways and use it to create the user object, then add that user object to the general security group. This can happen in seconds and will create user objects in the OU that will be in the same format all the way through. It will save on typing and decrease the chance of spelling errors as well because you are only typing the user’s actual first and last names once.

Below is an example of a script dedicated for Department of Defense (DoD) use but can easily be adapted for industry. The bones of the function are reusable no matter the organization.

# Set these accordingly
$exerciseUsersOU = 'OU=USERS,OU=TEMPORARY,DC=aaronrombaut,DC=com'
$exerciseGroupsOU = 'OU=GROUPS,OU=TEMPORARY,DC=aaronrombaut,DC=com'
$exerciseDescription = 'Exercise Description'
$exerciseDomain = 'aaronrombaut.com'
$exerciseDefaultPassword = ConvertTo-SecureString -String '1$Pass%0' -AsPlainText -Force
$exerciseDefaultUsersGroup = 'GLS_DEFAULT_USERS_GROUP'

# Function to make standard user objects
function New-ExerciseADUser
{
    $firstName = Read-Host -Prompt 'First name'
    $lastName = Read-Host -Prompt 'Last name'
    $objectName = "$firstName.$lastName"
    $displayName = "$lastName, $firstName"
    $eDIPI = (Read-Host -Prompt 'EDIPI').ToUpper()
    $cellName = Read-Host -Prompt 'Cell name'
    # $password = Read-Host -Prompt 'Password' -AsSecureString

    # Create a new user object and place it in the correct OU
    New-ADUser -Name $objectName `
        -AccountPassword $exerciseDefaultPassword `
        -CannotChangePassword $false `
        -ChangePasswordAtLogon $true `
        -Description $exerciseDescription `
        -DisplayName $displayName `
        -EmployeeID $eDIPI `
        -Enabled $true `
        -GivenName $firstName `
        -PasswordNeverExpires $false `
        -PasswordNotRequired $false `
        -Path $exerciseUsersOU `
        -SamAccountName $objectName.ToLower() `
        -SmartcardLogonRequired $true `
        -Surname $lastName `
        -UserPrincipalName "$eDIPI@$exerciseDomain"

    # Add exercise user to the default users group for the exercise
    Add-ADGroupMember -Identity $exerciseDefaultUsersGroup -Members $objectName

    # Add exercise user to the cell group they belong to for the exercise
    $exerciseGroups = Get-ADGroup -Filter * -SearchBase $exerciseGroupsOU
    foreach ($exerciseGroup in $exerciseGroups)
    {
        $exerciseGroupName = $exerciseGroup.Name
        if($exerciseGroupName -match $cellName)
        {
            Add-ADGroupMember -Identity $exerciseGroupName -Members $objectName
        }
    }
}

New-ExerciseADUser

As you can see above, the administrator had to navigate through three dialog boxes to create a single user. If you look at the ADUC screenshot, you will see the user was created but is in ‘First name Last name‘ format where as the rest of the users are in ‘Last name, First name‘ format. This could be the resolved either at creation time or fixed after the user object is created. Either way, it is time consuming, error prone, and may not be consistent in environments with more than a single administrator. On top of that, the administrator still needs to apply the user to a security group.

Now look at the above screenshot of running the PowerShell script. It asks six questions and then creates the user and adds that user to a generic security group. A few things to note, the script can be tweaked so that the display name is in any format you would like at creation time. The script right now is set to ‘first name last name‘ as you can see in the image for the user, Arthur Dent. Also, the user does not have to be added to a security group, it’s just a common practice to add a user to a generic security group during on-boarding. See the link below for another PowerShell script that can be run on Active Directory to change all the users in an OU to a common format if desired after user creation.

https://www.aaronrombaut.com/change-the-canonical-name-cn-of-an-active-directory-user/

If your organization requires more or less information, just add or remove as needed. All of the Account options are programmable, such as forcing the user to change the password at next logon, password expiration, account expiration, or smart card usage. It’s just a matter of how much information you need or want from a user at account creation time and your organization’s policies.