Category Archives: Compliance and Security

Configuring vRA 7 for 2 Factor Authentication

 

One of the most exciting new features in vRealize Automation 7 is the addition of the VMware Identity Manager (or vIDM) to act as the identity provider. This brings a whole host of new capabilities, but one of the key among them is the addition of simple and flexible multi-factor authentication. This  guide will walk you through the process of configuring vRA 7 for 2 factor authentication, using Google Authenticator as our example token.

In this example scenario, a vRA 7 environment is already set up and fully functional using traditional username and password authentication. The guide also assumes you have a basic CentOS server set up and available for configuration. Both of these steps are outside the scope of the instructions below.

Part 1: Configuring the Linux Host

First, ensure that you have proper DNS resolution set up for the CentOS host. This host will act as your authentication intermediary, processing both the Active Directory username and passwords as well as the Google Authenticator token. Since AD is involved, DNS and time configuration will be critical.

Create_DNS_Record

Next, SSH to your Linux host. You’ll need to be a privileged user (i.e. root) for these operations, so that’s what I’ve logged in as here. Your configuration may require you to log in as a standard user and then su to root, or use sudo.

Log_In_Host_SSH

Next, you must edit the SELinux configuration.

vi /etc/selinux/config

SELINUX=disabled

Ensure that the SELinux policy is set to either permissive or disabled as shown below. While it is definitely possible (and probably advisable) to keep SELinux enabled for this configuration, the additional steps to do so are outside the scope of this guide.

Edit_SELinux_Configuration

Now, remember what I said about DNS and time being critical when integrating with Active Directory? You’ll need to set up NTP services on your host to ensure that there’s no time drift for authentication to work properly.

yum install ntp -y
ntpdate <your_ntp_server_here>

This will install the ntpdate package on your host, as well as set the time source. Ensure that you set this NTP server to the same one that provides time to your Domain Controllers – this will prevent time related authentication failures.

Install_Configure_NTP

Now would also be a great time to confirm your DNS configuration is correct. Check the /etc/hosts file and ensure that your hostname is mapped to the correct IP address. Also check your /etc/resolv.conf file to ensure that your host is pointing at a DNS server which can properly resolve your Active Directory. In the example shown, the DNS server is set directly to our Domain Controller.

Confirm_DNS_Config

Next, ensure that the wget package is installed. Your host may already have this installed.

yum install wget -y

Install_wget

Great. The basic system is now set up and ready to start loading the software that will do the heavy lifting.

First up will be the PowerBroker Identity Suite, or PBIS. These utilities will enable the simple addition of AD authentication to your Linux host. The commands below will add the PBIS RPM repository so that yum can download and install the packages.

rpm --import http://repo.pbis.beyondtrust.com/yum/RPM-GPG-KEY-pbis
wget -O /etc/yum.repos.d/pbiso.repo http://repo.pbis.beyondtrust.com/yum/pbiso.repo
sed -i "s/mirrorlist=https/mirrorlist=http/" /etc/yum.repos.d/epel.repo
yum clean all
yum install pbis-open -y

Install_PBIS

Now that PBIS is installed, you can join your Linux host to your AD domain.

domainjoin-cli join corp.local <your_domain_username>

This command will actually join the host to the domain, creating a computer object and all the required Linux PAM configuration. Ensure you use a username with the rights to add machines to the domain – in the example here, we used the default Administrator account.

/opt/pbis/bin/config AssumeDefaultDomain true

Next, this command will ensure that the domain you joined is always assumed to be the default. This saves you entering DOMAIN\username notation for everything you do.

Join_AD_Domain

Now open up your Active Directory Users and Computers snap-in. By browsing to the default Computers container, you can validate that your Linux host is now added to the Active Directory. In this example, it is named util-01a and is listed as a CentOS 6.3 host running PBIS Open 8.3.

Validate_Domain_Membership

And while you’re in the ADUC view, create a domain group called RADIUS_Logon_Disabled in the Users container. You don’t need to add any users to it now – this will be used only if you want to deny any users the ability to authenticate against RADIUS without completely disabling their account. We’ll come back to this group later.

Create_Denied_Logon_Group

Now, reboot your Linux host. This ensures that all of the PBIS configuration is in full effect.

Once the host is fully restarted, log in as the same privileged account you were using before. We’re not done yet!

wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
rpm -Uvh rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

This will enable another external repository, so that you can obtain the QR code generator that will be used with Google Authenticator…

Prepare_RPMforge_Repo

yum install qrencode qrencode-devel git pam-devel gcc -y

…and this will grab and install all the packages and dependencies needed to build the Google Authenticator components.

Install_Build_Tools

Since the Google Authenticator utilities aren’t delivered as an RPM package, they’ll need to be built from source. To do that, you’ll download the source files from a Git repository and compile them directly on the Linux host. Don’t worry, this sounds a lot harder than it is.

cd /root
git clone https://code.google.com/p/google-authenticator
cd /root/google-authenticator/libpam
make && make install

This checks out the latest version of the Google Authenticator code, downloads it to your local system, compiles it and installs it. Easy, right?

Download_Compile_Google_Authenticator

This is the last package installation, honest. Download and install the FreeRADIUS server, using:

yum install freeradius -y

Install_FreeRADIUS

Now that all the packages are installed, there’s some configuration to be done. This part requires some config file editing, so be sure you’ve got your editor of choice handy and read the steps carefully – small mistakes can have big impact here!

First, the user which FreeRADIUS runs as must be changed. By default, the server executes as the radiusd user, but because we will need to read Google Authenticator tokens from every user’s home directory, it is far easier to run the service as root instead. There are of course other ways to make this possible without running as root, but they are outside the scope of this guide. In a production environment, you should definitely explore doing so.

vi /etc/raddb/radius.conf

Change:
user = radiusd
group = radiusd

To:
user = root
group = root

Change_FreeRADIUS_User_Group

Next, edit the radiusd.conf file to deny access to members of the AD group you created earlier. This is accomplished by adding the text shown here, in the “Deny access for a group of users” section of the file.

vi /etc/raddb/users

Add:
DEFAULT Group == "RADIUS_Login_Disabled", Auth-Type := Reject
 Reply-Message = "Your account has been disabled."

DEFAULT Auth-Type := PAM

Configure_Denied_RADIUS_Users

Now, FreeRADIUS must be configured to accept PAM-based authentication. PAM is the Linux Pluggable Authentication Module framework, and is what makes all of this fancy authentication possible.

vi /etc/raddb/sites-enabled/default

Uncomment the line shown so it just reads "pam"

Enable_RADIUS_PAM

Once the FreeRADIUS server is configured to accept PAM authentication, PAM itself must be configured to use the correct mechanisms, in this case combining Active Directory authentication with Google Authenticator tokens. To do this, edit the /etc/pam.d/radiusd file and comment out all of the existing lines, then add the configuration below

vi /etc/pam.d/radiusd

Comment all existing lines by prefixing with #

Add:
auth requisite pam_google_authenticator.so forward_pass
account required pam_lsass.so use_first_pass

Configure_PAM_Modules

Finally, the RADIUS server must be configured to authenticate the vRealize Automation server itself. This is done by pairing a shared secret with the hostname of the system. Edit the /etc/raddb/clients.conf file and add the text specified in the section shown. Be sure not to add this new client definition inside the default definition. In the example shown, the client is vra-01a.corp.local, the secret is VMware1!, and the shortname is vra-01a. Fill in your specific details instead.

vi /etc/raddb/clients.conf

Add:
client <your-full-vRA-VA-hostname> {
 secret = <your-shared-secret>
 shortname = <your-vRA-VA-friendly-name>
}

Add_RADIUS_Site

Now, start the FreeRADIUS server.

service radiusd restart

Restart_radiusd

Part 2: Configuring vRealize Automation

Now that the Linux host is configured to process the authentication requests, you’ll need to configure vRealize Automation’s VMware Identity Manager instance to leverage it.

Log in to vRealize Automation as a Tenant Administrator.

Click on the Administration tab, then the Directories Management button on the left. Select the Connectors button and you’ll see the screen pictured. This is where you’ll configure the vIDM Directory connection. Click on first.connector as shown.

Configure_vRA_Directory_Connector

You’ll be presented with the screen below. Click on the Auth Adapters button. Notice that the RadiusAuthAdapter is Disabled. Let’s change that – click on RadiusAuthAdapter.

Configure_Auth_Adapters

Here you’ll see the configuration for the vIDM RADIUS adapter. Fill in the fields as shown, substituting  the correct Radius server hostname/addressShared Secret (remember you entered this in an earlier step – in this  example it was VMware1!) and Realm prefix. The Realm prefix is your domain name, with the trailing slash character. Also, note the Login page passphrase hint has been customized – this reminder will display on the login page to help guide users to enter the correct data.

Do not enable the Secondary Server at this time – leave all the rest of the fields as-is.

Click the Save button at the bottom of the screen, then switch back to the vRealize Automation tab in your browser.

Configure_RADIUS_Adapter

Now, click on the Network Ranges button and select Add Network Range. This will allow you to specify groups of IP addresses which will use a particular authentication config. It’s a good idea to configure just one or two IPs for testing purposes initially, so that you don’t accidentally lock yourself out of the environment.

vRA_Network_Ranges

The Network Range configuration is pretty straightforward. Just enter a name, description and IP range. Make the starting and ending IP addresses the same to specify only a single host. In this example, we are limiting this range to the local desktop. Click Save.

Add_Network_Range

Click on Policies  to the left and then edit the default_access_policy_set. Remember that you can create multiple policies for multiple scenarios.

vRA_Access_Policies

Click on the Green + sign to add a new policy rule.

Edit_Default_Policy

Configure the policy rule as shown:

  • If a user’s network range is: <your new network range here>
  • And the user is trying to access content from: All device types
  • Then the user must authenticate using: Radius Only

Click Save.

Add_Policy_Rule

Now, grab the icon highlighted in red with your mouse and drag the new rule to the top of the list. Click Save.

Reorder_Policy_Rules

vRealize Automation is now configured to use RADIUS authentication, combining both Active Directory credentials with a Google Authenticator token.

Part 3: Enabling Users for Google Authenticator

Now that the Linux host has been built and configured and vRA has been set up to take advantage of it, you need to create tokens for your users.

Re-connect to your Linux host from Part 1 using SSH, or if you still have an active session simply switch back to it. You should be authenticated as root at this point, as you will be assuming the identity of your AD users to create their tokens.

In the pictured example, we are becoming a user named mary. Mary is an AD user who has never before logged in to this Linux host – yet we were able to assume her identity by authenticating against Active Directory. Pretty cool! You can also check that you are indeed logged in as Mary by running whoami.

su mary
whoami

Su_to_AD_User

Now, you’ll create the Google Authenticator token. This can be done by running the following command:

google-authenticator -tdf -r 3 -R 30 -w 17 -Q UTF8

Notice that the command creates a huge QR code, a Secret Key, and 5 emergency scratch codes. These codes can be used in the event that you don’t have your smart device handy, but each can only be used once. Keep those in a safe place. The QR code is a graphical representation of the alphanumeric secret key printed directly beneath it.

Create_Google_Authenticator_Token

Here’s the fun part. Pick up your nearest handy smart device. It could be a smartphone, a tablet, etc. I use an iPhone, so the following images were captured there.

Search for the Google Authenticator app in the App Store, or Google Play, etc. Download it – it’s free.  Open the app.

Google_Authenticator_App_Store

Tap the “Scan Barcode” option and grant the application access to your camera. You can also select Manual Entry and type in the alphanumeric secret key – but where’s the fun in that?

Set_Up_Google_Authenticator

Point your phone at the QR code generated on the screen and the app will do the rest!

Scan_QR_Code

You can see that the Authenticator app has automatically generated a token for Mary, showing her name and the server which she’s authorized for. The little Pac-Man thing to the right is a timer – these tokens are only good for a single use, and only valid for 30 seconds.

View_User_Token

Part 4: Testing Your Work

To recap, you’ve just:

  • Built a Linux host to handle the task of authenticating against Active Directory and Google Authenticator
  • Configured vRealize Automation to leverage that host as an authentication source
  • Created a time-based token for one of your Active Directory users

Now it’s time to put it all together and test the configuration.

Open a new browser window. I find that an ‘Incognito’ or ‘Private Browsing’ window works best, since you probably have another window logged in as your Tenant Administrator already. Notice that you are now prompted for the username and AD Password + Google Auth Code – that was the free text you entered a few steps back to help guide your users.

Login_vRA

Log in using the new token on your smartphone. Assuming the following parameters:

  • Username = Mary
  • Password (AD) = VMware1!
  • Google Authenticator Code (from smart device) = 098765

You would log in with a username of “mary” and a passcode of “VMware1!098765

Login_Successful

Voila!

This post was brought to you by Breakside Brewery’s Salted Caramel Stout, which was genuinely instrumental in getting me through developing this configuration. Notes of chocolate play on the nose while sea salt and fresh caramel round out the palate in one of the smoothest, most pleasant stouts I’ve ever tried.

Breakside_Salted_Caramel

Happy automating!

Special thanks to Ed Kaczmarek for contributing to this guide – follow him at @edkaczmarek!

Important – vRealize Automation VAMI authentication issue when upgrading to 6.2.1

For those of you who will be upgrading your vRealize Automation appliance to 6.2.1 now that the new version is available, please be aware of an issue that you may encounter.

After upgrading your appliance to 6.2.1 via the VAMI and rebooting, you may find that you are unable to authenticate to the VAMI as ‘root’.

This can be fixed by logging in to the vRA Appliance from the console (as root – this account is unaffected) and running the following command:

chage -M 99999 root

This will reset the expired root password account and allow you to authenticate to the appliance VAMI interface again.

Alternatively, you could change the root password to reset the expiration.

Sorry, no wine content on this one – it’s WAY too early. This message pairs nicely with a cup of coffee.

Happy automating!

 

Creating DISA STIG Scorecards with vCM

In my previous life as an InfoSec guy, I was responsible for assessing, enforcing, and ensuring continuous compliance with all the various baselines for which my organization was responsible. At the forefront of this list were a long list of DISA STIGs (Defense Information Systems Agency Security Technical Implementation Guides) – a daunting task in any size environment with any size staff. Of course, this particular environment was fairly large, and the information assurance technical staff consisted basically of… me…  so  automating these processes became something of a necessity.

This is where one of VMware’s most versatile products comes in – the vRealize Configuration Manager (vCM.) This gem of a tool provides unified, cross-platform configuration and compliance management and enforcement of over 80,000 distinct controls from a single interface, complete with fully customizable reports, dashboards, and a whole host of other fun features.

Anyway, enough sales. On to the how-to.

This tutorial assumes you already have vCM installed and configured and able to communicate with at least one managed system. For this example we will be creating a Windows 2008 R2 scorecard.

To start, we will need to download the STIG content and the viewer tool straight from DISA.  The content is what’s known as a “Benchmark” and can be obtained from http://iase.disa.mil/stigs/Pages/a-z.aspx. The one we will want for this example is the “Windows 2008 R2 MS STIG Benchmark – Version 1, Release 15

Benchmarks

A few notes here.

  1. These benchmarks will update quarterly, on a fixed schedule found here.
  2. You will notice that there are “MS” and “DC” STIG bundles for Windows operating systems. MS refers to Member Servers, and DC to Domain Controllers. This is because there are additional and special requirements depending on which role the server fills. Make sure you select the appropriate bundle for your target system.
  3. You will also notice that there are “Benchmark” and “STIG” bundles. The STIG bundle contains much more information as well as a whole host of manual (non-automated) checks which are out of scope for this guide.
  4. Any time you see the *PKI designation next  to a link, this means that a DoD issued PKI certificate (smart card) is required to access this content. If you have one, great! If not, you simply won’t have access to this particular information.

Next, you will need to download the STIG Viewer. This is a Java based JAR application which will allow you to view, interact with and update your STIG scorecards. This can be obtained from http://iase.disa.mil/stigs/Pages/stig-viewing-guidance.aspx. Click the link for “STIG Viewer Version 1.2.0” in this example.

STIGViewer

Note that you will need to have a functioning JRE installed on your vCM server to use this tool.

Once you have the STIG Viewer and the appropriate benchmark for your guest operating system downloaded to the vCM server, we need to place the benchmark in vCM’s SCAP import folder. In a default install of vCM, this folder is found at C:\Program Files (x86)\vmware\vcm\WebConsole\L1033\Files\SCAP\import

SCAPImport

Tip: SCAP is the Security Content Automation Protocol, a standard designed to provide a framework for vulnerability management by the National Vulnerability Database.

Once the file is copied to the import location, it’s time to fire up the vCM console.

  1. Log in as a user with the Admin role or a custom role with access to the Compliance tools.
  2. Click on the Compliance slider on the left
  3. Expand the SCAP Compliance spinner
  4. Click on Benchmarks
  5. Click Import on the right hand panel to bring up the list of available SCAP benchmarks
  6. Using the arrow controls in the middle of the dialog, move the benchmarks you wish to import to the right hand side and click Next, followed by Finish on the next dialogBenchmarkImport

You will now see the new benchmarks listed in the Compliance slider on the left. If you expand them, you will notice that they are broken down into MAC (Mission Assurance Category) and CL (Confidentiality Level) categories. Be sure you know the MAC and CL for the systems you plan to audit –  the affects the stringency of certain technical controls.

MACandCL

Now it’s time to run a collection against the systems you want to audit. There are many ways to accomplish this, and I’m going to assume you have your own preferred method – but here’s a quick one just in case.

  1. Select Collect from the main toolbar at the top of the vCM interface
  2. Select Machine Data and select OK
  3. Choose the machine(s) you wish to audit – either from the list on the left, or use the filter, or machine groups, etc.
  4. Select Select a Collection Filter Set to apply to these machines and click NextCollection1
  5. Select the Regulatory Baseline Filters – Windows (for this example) filter set and click NextCollection2
  6. Click Finish

Now you need to monitor the collection job until it completes successfully. Wait until the job disappears completely from the Jobs list before continuing to the next step. This ensures that the data is fully merged into the vCM database.

JobsView

Now we can return to the Compliance slider.

  1. Expand the SCAP Compliance spinner, followed by the Benchmarks and the appropriate benchmark for the OS you are going to audit
  2. Select the appropriate MAC and CL for the system in question. For this example, we will use MAC-2_Sensitive
  3. Click Run Assessment in the right hand panel
  4. Select the machines you wish to audit from the upper list and move them to the lower list using the arrow controls
    RunSCAP
  5. Click Next
  6. Select if you wish to run the action now or later. For this example we will select Run Action Now and click Next
  7. Click Finish

A Windows SCAP Assessment job will be submitted to the Jobs list. Monitor this until it completes, then select the appropriate MAC and CL from the Benchmarks list again to refresh the view.

You should see a list of your assessed servers that looks like this:

ResultOptions

Now you have quite a few options. You can choose from the pre-configured result types that vCM provides for you – the OVAL HTML result is a nicely formatted human-readable report that’s suitable for a build book, hard copy, etc:

OVALResults

But, to generate content that will work with the DISA STIG Viewer, you need to export an XCCDF-formatted XML file. To do this:

  1. Click Export from the toolbar
  2. Select the machines you wish to export data for. Each machine will generate its own XML file
  3. Click Next
  4. Select XCCDF Results – XML
  5. Click Finish

You will receive a dialog that looks like this when the export is complete.

ExportResults

Navigate to this folder: in a default vCM install it is C:\Program Files (x86)\vmware\vcm\WebConsole\L1033\Files\SCAP\export

Here you will see a list of the exported results files for the servers you selected in the last step.ExportedFiles

We’re almost there. Take a deep breath and another drink of your favorite adult beverage. Today I am personally drinking a truly excellent 2010 Miner Cab from the much-coveted Stagecoach vineyard. This vineyard in the eastern hills of the Napa Valley produces fruit for some of the biggest name wines around, and with good reason.MinerStagecoach

Refreshed? Good – back to the STIGs. Now you’re going to want to fire up that DISA STIG Viewer we downloaded at the beginning. Provided you have a properly installed JRE, you should just be able to double-click the JAR file.

You’ll then be greeted with this friendly government-issue GUI. Never fear.STIGViewerGUI

  1. Select File and Import STIG from ZIP from the menu bar
  2. If this is your first time importing a STIG bundle, you will be prompted to create a savepoint. Select Yes
  3. Navigate to the folder where you stored the STIG Benchmarks we downloaded at the beginning of this guide. Be sure to select the one(s) which apply to the compliance results you exported earlier.
  4. You’ll see the viewer is now populated with STIG controls.STIGControls
  5. Now we must create a checklist from this raw data. Select Checklist and Create Checklist – Current STIG from the menu bar
  6. You will now have a STIG Checklist which you can enter your own data into. Notice that the Host Target Data in the lower left corner is not populated, and all of the vulnerability statuses are set to Not ReviewedChecklistView
  7. This is it: the last step. Select Import from the menu bar, followed by Import XCCDF Results. Navigate to the XML file you exported from vCM earlier. Remember, by default it was located in C:\Program Files (x86)\vmware\vcm\WebConsole\L1033\Files\SCAP\export
  8. Voila! You will see that the checklist has been filled out for you. You can now review the checklist, mark it up, make manual severity/status overrides, etc. If you save it as a .CKL file, it will be an acceptable artifact to most DoD certified auditors for the purposes of DIACAP/RMF. CompletedChecklist

Of course, you must be sure to be aware that every audit is different and you should check with your DOIM or local IA department to confirm these documents will be acceptable/sufficient for your purposes.

Tip: Much of what we just did can be scheduled inside of vCM. This removes a LOT of the manual work.

I hope this  guide has been useful to you.