Tag Archives: vidm

It seems like the more time I spend with the new VMware Identity Manager (vIDM) in vRealize Automation 7, the more great new capabilities I discover. Today’s post comes directly from a customer request, and discusses how to use vIDM Attribute Mapping in vRA 7.

Due to complexities in this customer’s Active Directory environment, they have the “email” attribute in their user accounts populated – but it does not contain the user’s actual email address. This means that vRA is unable to send them notifications, as it automatically inherits this field and uses the information therein.

Have no fear, vIDM is here.

Here you can see my account with the default configuration. My email address is set to jon@corp.local, but that just isn’t where I receive my email.

Looking at my account inside of Active Directory, we can see that this address is set in the ‘E-mail’ field, which maps to the ‘mail‘ attribute in LDAP.

But, if we look at the Attribute Editor, we can see that the LDAP ‘otherMailbox‘ attribute contains my preferred email address of ‘jon@vaficionado.com‘

So, how can I change my vRA configuration to utilize that otherMailbox attribute instead? It’s very easy. Start by clicking on the Administration tab in vRA. Then select the Directories button on the left hand side and edit your Active Directory shown to the right.

Next, you’ll be presented with the Active Directory settings page. Click on the Sync Settings button.

Here you’ll see a whole host of advanced synchronization options that you can change. Click on the Mapped Attributes button at the top, then select the dropdown next to email. Select Enter Custom Input… from the menu.

Now, enter the new Active Directory attribute name that you want to retrieve the email address from. In this example, the new attribute is named otherMailbox. Click Save & Sync to save your settings and update the user accounts.

You’ll now be given the opportunity to review the proposed changes once the sync is completed. You can see in this example, there are 4 AD accounts that will have their attribute mappings updated. Click Sync Directory.

Once the sync is completed (this may take some time, depending on how many objects were being updated and the size of your AD, etc) go back to the Administration > Directory Users and Groups view and find your user account again. You’ll notice that the email address has now been updated to reflect the contents of the preferred attribute.

Pretty cool, huh?

This post was brought to you by Terrapin Beer Co’s Poivre Potion, a very unique dry-hopped pink peppercorn Saison. I love the way the spicy and sweet notes of the peppercorns play off the bitterness of the hops and the farmhouse funk of the Saison yeast strains. Delicious and easy to drink.

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.

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.

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.

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.

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.

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

yum install wget -y

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.

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.

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.

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.

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!

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

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.

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.

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

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

yum install freeradius -y

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.

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.

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"

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

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.

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.

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.

Here you’ll see the configuration for the vIDM RADIUS adapter. Fill in the fields as shown, substituting the correct Radius server hostname/address, Shared 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.

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.

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.

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

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

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.

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

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

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.

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.

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?

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

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.

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.

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”

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.

Happy automating!

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