VSphere iSCSI initiator authentication changes enhance system uptime, security

VSphere 4.0 hosts now support multiple iSCSI targets and mutual Challenge-Handshake Authentication Protocol, which can minimize system downtime.

This Content Component encountered an error

When you have the opportunity to enhance security without limiting functionality or manageability, it's a very good thing. VMware has enabled this with certain iSCSI initiator authentication changes in vSphere 4.0.

The first major change is that a VMware ESX or ESXi host can now use different iSCSI hosts simultaneously, even if the iSCSI hosts are managed by different groups or have different authentication capabilities. Second, VMware ESX 4.0 enhances the iSCSI authentication process over VMware Infrastructure 3 (VI3) with the addition of four different security levels, mutual Challenge-Handshake Authentication Protocol (CHAP) security and the ability to independently configure authentication for multiple targets.

Anonymous and authenticated access
At the authentication level, ESX 3.5 supports two types of access to iSCSI targets: anonymous and authenticated. When authenticating access in ESX 3.5, you use the Challenge-Handshake Authentication Protocol (CHAP). The implementation of access is somewhat limited because only a single local name and secret set of credentials can be used, which can be somewhat problematic in environments that have many potential iSCSI targets. In an environment where these multiple targets have different authentications, only those that have the same values can be used, which means that in essence, CHAP authentication in ESX 3.5 usage is all or nothing.

With the introduction of ESX 4.0, however, VMware has provided additional flexibility to the iSCSI authentication scheme. CHAP authentication can be configured at the root level of the iSCSI initiator and at the target level. Credentials can be configured at the root level and, if desired, inherited at the target level. ESX 4.0 also adds mutual CHAP authentication, which brings an additional level of security between the host and the iSCSI storage system.

For example, let's say an organization has many different storage technologies in the enterprise: one for this project; one for another project, etc. Let's also say that these technologies will be used for a VMware project, but the iSCSI targets were not configured identically. To use VMware with both storage solutions, changes must be made to the storage technologies for ESX 3.5 to use both of them, whereas with vSphere and ESX or ESXi 4.0, you would not have to make these changes – which means less system downtime and less impact on the other projects from the iSCSI authentication change.

Configuring mutual CHAP in ESX 4.0
To investigate how to configure mutual CHAP in ESX 4.0, I used StarWind Software Inc. iSCSI storage area network (SAN) software as my iSCSI storage. The StarWind iSCSI SAN solution is an iSCSI SAN that runs on top of a Windows installation and is very simple to configure. I chose the Enterprise version for my purposes primarily because it can thin-provision storage.

I started by downloading the StarWind iSCSI SAN and installing it on my Windows system. I chose a full installation and launched the management screen to get started with my storage configuration upon completion. After logging into the iSCSI connection, I added storage to my installation by adding a device to the connection. I chose "Snapshot and CDP device" because my test environment does not have a significant amount of space, and I wanted to use a thin-provisioned iSCSI target. I made sure to allow multiple iSCSI connections as I use this for my other test ESX hosts as well.

Enabling mutual CHAP authentication
To enable mutual CHAP authentication, I modified the permissions of the connection to include CHAP authentication for the StarWind iSCSI SAN and added the CHAP authentication for the ESX host. Because multiple ESX hosts will use this authentication, I added the CHAP authentication for the additional hosts as well.

To gain access to the presented iSCSI targets at the host level, I modified the iSCSI Software Initiator on my ESX 4.0 host. This is configured through the Storage Adapters pane in the Configuration tab of ESX 4.0. In ESX 3.5, there is a CHAP configuration tab, which can accept only the iSCSI target's CHAP authentication credentials. ESX 4.0 moves the CHAP configuration to a button that adds not only mutual CHAP authentication but also rules regarding which security level CHAP uses. The CHAP security settings are as follows:

CHAP security level Behavior Supported initiators
Do not use CHAP CHAP authentication is not used. This disables authentication. Software
Hardware
Do not use CHAP unless required by target The host prefers to not use CHAP, but will CHAP authentication as an alternative. Software
Use CHAP unless prohibited by the target The host prefers CHAP authentication, but will use connections that do not have CHAP enabled. Software
Hardware
Use CHAP CHAP authentication is required. There will be no successful connections without CHAP authentication. Software

It is important to remember that hardware iSCSI initiators do not support mutual CHAP.

To configure the authentication between my host and the StarWind iSCSI SAN, I first entered the local name/secret combination of the iSCSI target in the CHAP fields, followed by the local name/secret combination of my host in the mutual CHAP fields. After clicking OK, I was asked to rescan my software iSCSI initiator. Voìla! I created a secure two-way connection from my ESX 4.0 host and my iSCSI targets.

In addition to supporting mutual CHAP, ESX 4.0 allows different targets to support various CHAP authentication levels as well as different CHAP credentials. In a less complex environment, these settings can be configured at the initiator level, and each target can inherit the settings.

When you need to do more with less, as many do in today's economy, you pretty much have to make do with what you have. If you can leverage what you have in place without disrupting the services that these resources currently provide, the end result is more flexible, as well as cost efficient – which is part of what vSphere 4 provides with the changes I've reviewed here.

Jase McCarty (VCP) has worked in IT for 20 years, with experience in academic, military, insurance and financial sectors. He has been using VMware's products since 1999 and has vast experience with Windows, Linux and Unix systems. He currently operates his own blog at www.jasemccarty.com, owns a private consultancy and has co-authored two VMware books. He is a 20-year veteran of the Air National Guard, and currently works for a Fortune 500 company.


This was first published in July 2009

Dig deeper on Selecting storage and hardware for VMware environments

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchVirtualDesktop

SearchDataCenter

SearchCloudComputing

Close