Wednesday, February 20, 2013

Adding Active Directory as an Identity Source for Single Sign On

When you first deploy the vCenter Server Appliance (vCSA), Single Sign On (SSO) does not use Active Directory as an Identity Source.  The SSO service and the vSphere Web Client are configured and integrated as part of the deployment of the vCSA but the default Identity Source is the local OS accounts.

You can update the Identity Source to point to your Active Directory for authentication.  You will first need to login to the vSphere Web Client using the vCSA root account which is an SSO administrator by default.  To login follow these steps:

Login to the vCSA using the Web client and the root or administrative credentials. The vSphere Web Client URL is https://[vCenter Server Appliance]:9443

Navigate to the Administration Tab. Click “Sign-On and Discovery and Configuration as shown in figure 1.01.

imagefigure 1.01 

Under the Identity Sources tab on the right click the “+” to add a new Identity Source. 

As shown in figure 1.02: Select the Identity source type “Active Directory

Type a Name i.e. virtualguru.org

Provide the URL for you AD server i.e. ldap://demoad001.virtualguru.org:3268

Provide the Distinguished Name (Base DN for users) in the format DC=virtualguru, DC=org

In Authentication Type you can select “Reuse Session".  Reuse Session is supported for Active Directory Identity Sources and essentially takes the credentials used to logon to SSO and passes them to the AD Server. 

image figure 1.02

(Note: although in the example we are using the root of the domain you should use a Group within the Active Directory that includes all of your vCenter Administrators and then provide the fully Distinguished Name (DN) of the group. This reduces the amount of time required to lookup  the accounts and provides better security by being more specific. If you are unsure of what the DN is then simply create the group and use a LDAP Browser to browse to the group and read the DN Name as shown in figure 1.03. A great utility is the Softerra LDAP Browser which can be downloaded here.)

image

figure 1.03

Wednesday, February 6, 2013

Upgrading vCloud 1.5 and Storage Profile Considerations

I have seen some information out there that touches upon what you need to be aware off but wanted to investigate a little further. The confusion centers around what happens to existing datastores not using Storage Profiles when you upgrade from vCloud 1.5 to 5.1? 

To review, Storage Profiles are a feature that is enabled using vCenter and accessible to customers who have vSphere Enterprise Plus licensing.  vSphere Enterprise Plus licensing is included in the vCloud Suite 5.1 bundle.

Storage Profiles allow you to categorize your datastores using user-defined or system-defined attributes.  User defined are created by you whereas system-defined are provided by the storage vendor through their support of the VMware vStorage APIs for Storage Awareness (VASA).

Upon Completion of the vCloud Upgrade from 1.5 to 5.1 a default Storage Profile is created called ‘Any’ as shown in the figure 1.01.

image

figure 1.01

Any includes all storage pools that the vSphere environment has access to.  In my case it picked up two local storage pools as well as shown in figure 1.02.

image

figure 1.02

The default ‘Any’ Storage Profile is retroactively applied against all my existing Organizational virtual datacenters (vDCs) as shown in figure 1.03.  If I was not aware of this behavior I  may have VMs being created on a mix of local and shared storage pools.  Clearly this is something we will want to clean up.

image

figure 1.03

(Note: I personally believe that in certain Dev situations local storage may be an acceptable storage pool.  If you were considering this you would categorize local storage pools in separate storage profiles however.  The problem here is really the default mixing of both shared and local storage).

Removing the Any Storage Profiles

In my testing I had not enabled Storage Profiles so to remove ‘Any’ I will need to Enable Storage Profiles in vSphere, create Storage Profiles without local datastores and then replace the ‘Any’ Storage Profiles with my newly created Storage Profiles.

This is easy in a small environment but requires some planning in a large one (Providers take note).  To Enable and create Storage Profiles follow these steps:

Create User-defined Storage Capabilities

  • From vSphere browse to Home, Inventory, Datastores and Datastore Clusters
  • Right-click the datastore you wish to use and select Assign User-Defined Storage Capability
  • Click New and set a Name and Description
  • Repeat for all datastores that should be included

Create Storage Profiles

  • From vSphere browse to Home and under Management select VM Storage Profiles
  • Select Enable VM Storage Profile and then the Enable button (This is hard to see) and then click Close
  • Click Create VM Storage Profile
  • Name and assign the Storage Capabilities from the user-defined list you created

From vCloud Director Refresh and adjust the Storage Profiles

  • From the Home page select the Manage & Monitor tab and select vCenters under the vSphere Resources Heading
  • Select your vCenter on the right and right-click  and select Refresh Storage Profiles

Adjust you Provider vDCs

  • From the Manage & Monitor page under Provider VDCs DOUBLE-CLICK your provider VDC.
  • Under the Storage Providers Tab click the Plus to add your new storage profile
  • Select the ‘Any’ Storage Profile and right-click and select Disable
  • Select the ‘Any’ Storage Profile and right-click and Remove as shown in figure 1.04

add_remove

figure 1.04

Monday, February 4, 2013

Just what is Single Sign On?; vSphere 5.1

Technorati Tags: ,,

Single Sign On or SSO was introduced as a requirement for deploying vCenter 5.1.  SSO is based on identity management technology built by RSA but designed for VMware environments.  It provides a higher level authentication mechanism than Active Directory to enable Federation.  Federation in this sense allows you to authenticate once but access many vSphere environments such as multiple vCenter servers that may not have common Active Directories (ADs). 

SSO treats AD as an identity source; it also supports OpenLDAP, local accounts on the vCenter server and accounts created within SSO.  When you login to vCenter 5.1 you are passing the authentication to SSO which forwards it to an identity source for authentication.  Once authenticated you use a token vs. a username and password.  This token allows you to access multiple environments without re-authenticating.

SSO requires its own database.  Multiple SSO servers can be deployed and connected to the same database.  When multiple SSO servers are deployed one is designated Primary while the rest are slaves.  To make this configuration Highly Available you must add a Load Balancing (LB)Solution in front of the SSO servers.  The final step is to re-point the vCenter server to the new Load Balanced IP as covered in this VMware Knowledge Base article.

The easiest way to install SSO is to use the vCenter Server Appliance (vCSA) as it is integrated.  For additional details on installing vCSA please see my post.  Once installed the  default SSO account is: admin@System-Domain.  The password for this account is set during installation on a Windows server or randomly when you configure SSO on the vCSA.  

Install the VMware vSphere Web Client
  • Launch autorun.exe from the vCenter Server media
  • Select VMware vSphere Web Client and click Install.
  • Follow the prompts to choose the language and agree to the end user patent and license
  • Accept the default port settings.
  • Enter the information to register the vSphere Web Client with vCenter Single Sign On.

The default administrator user name is admin@System-Domain (Note: You will need to set this password first if you used the vCSA) and the Lookup Service URL is:

https://[SSOServer]:7444/lookupservice/sdk

  • Click Install.
Reset the random password for the admin@System-Domain account (vCSA Only)

Note: As mentioned, if you installed the integrated SSO on the vCSA then you will need to login using the root account and set the password for the admin@System-Domain account first.

  • Login to the vCSA using the Web client and the root or administrative credentials.  The vSphere Web Client is included as a part of the vCSA so the URL is https://[vCenter Server Appliance]:9443
  • Navigate to the Administration Tab. Click “SSO User and Groups
  • Right Click on the admin account and select Edit User. Specify the new password and click OK.

You should add your Active Directory vCenter Administrators Group to the SSO Administrators group as part of the configuration to enable their primary login to administer SSO (Note: this assumes you have already added your AD as an Identity Source.  If you have not yet have a look at this post).  To do this you will need to install the VMware vSphere Client first.

Adding your vCenter Administrators to the SSO Administrators Group
  • Login to your SSO server using the VMware vSphere Web client and the admin@System-Domain account.
  • Browse to Administration and under Access select SSO Users and Groups
  • Select the _Administrators_ under the Principal name column

01fig123

  • Select the Add Principals button from the menu
  • Under Identity source change from System-Domain to your Active Directory

01fig124

  • Search for the the right group and click Add and OK