Tag Archives: sso

Enable EqualLogic Active Directory Authentication

If you’re using a DELL EqualLogic SAN you have the ability to turn on Active Directory authentication.  The benefit once setup is that you can control access to the SAN via AD groups rather than giving out the Group Admin account or maintaining local accounts on the EqualLogic group.

The process to turn on Active Directory authentication is quite simple.  Whether AD authentication is on or off you can still use Local authentication and locally created accounts.  So if you do lose connectivity to AD you will still be able to local on with the default grpadmin account or any other local accounts that you have made.

To begin, login to the EqualLogic Group Admin webpage with local Group Administrator permissions.  On the left select Group Configuration then navigate to the Administration Tab.  It should look similar to below with ‘Local Only’ set as the authentication type.


Select the Active Directory radio button.  A new window will appear similar to below.


Click Add and type in at least one IP address of an AD Server.  If you have more than one (which you should) you can click Add again and input multiple servers.  The EqualLogic san will connected against the first AD server in the list and if unable to connect will work its way down the list.

On the right you can leave the Secure protocol as none and Use Default Port.  If you’ve successfully put in the correct AD server IP addresses you should be able to click on Get Default and the Base DN should be automatically populated with you the root DN of your AD domain name.

For the User you will need an AD account.  Open up Active Directory Users and Computers.  Create a basic user with no special rights.  Set the account not to expire.  Make sure it has read access into AD (by default all user accounts will have this).  Back in the EqualLogic Group Administrator use this new account created.  Use the full domainusername format.


Click the Test AD Settings.  A new window will appear and make a connection to each AD Server you added and perform a test search using the User you just created.

Hopefully all green ticks will be returned and you can click Ok and return to the AD Settings window.  If you receive a red cross and a fail double check the IPs of the AD servers.


Click OK and one final window will open asking to join the EqualLogic group to the Windows domain.  You can choose to Cancel this step if you don’t wish to use Single Sign On.  If you proceed, for the username enter in an Administrator account that would have permissions to add workstations to the domain and click ok.


If successful you will see the Group name added as a computer in AD Users and Computers under the Computers OU.

The Administration tab should now look similar to below.  You will have a new Active Directory Status section with a couple green ticks indicating that you have successfully added in an AD server and the Group was successfully created as a computer object in AD for SSO.


That’s all there is to it.  You can now click on Add to add a new users or group from AD.  A window will appear giving the option to create a standard local user account but now the radio buttons to create an AD user or group are available.

The process is the same for a user or group.  Select the Add a new Active Directory user radio button.  Under General settings type in the username of the AD User omitting the domain name.  You can click on Check name which will verify with a green tick that the user does indeed exist in AD.


Click next and specify the permissions you want the account to have.


Click next again, verify the details and permissions you have set for the account then click finish.


If you choose to use an AD group.  I recommend first creating a Domain Local group first in AD.  Populate this group with the users you want to have access.  Then run through the steps above but select Add a new Active Directory group.

Installing vSphere 5.1 – vCenter Inventory Service

To install vCenter Server the vCenter Inventory Service is a prerequisite.  I was going to gloss over the fact that I know nothing about the Inventory Service, current or previous version, but still thought it best to raise that fact.  There is just so little information out there on it.  Having recently done my VCP there was no mention of this function.  VMware’s website has excellent technical documents but they fall short on explaining anything to do with the Inventory Service.  For a component that is so predominant in the installation process it’s surprising.

The only explanation I have on it is what’s on the installation screen 🙂  Make of it what you will.

“vCenter Inventory Service stores vCenter Server application and inventory data, enabling you to search and access inventory objects across linked vCenter Servers.”

To begin the installation mount the vSphere media and run the installer.  Select the option to install VMware vCenter Inventory Service.

Fight your way through the license and patent agreement screens as usual.  Then click next to start the Installation wizard.

In my case I am upgrading my previous vSphere 5 version but a clean install is virtually identical with the exception of the below screen which prompts to either do not override or replace the database.  I’ve chosen to not override.

Enter in your FQDN of the local system.  In most, bar large installations, this will be the same system as your SSO and vCenter host.  If you’ve read my previous post on SSO and FQDN (http://wp.me/p1BmCN) you’ll know that DNS records are extremely important for a proper working SSO and vCenter implementation.

Accept all the default ports.  Unless you have security concerns or you’re traversing firewalls there’s little reason to change them.

Select the best size of your ESX environment.  Try to foresee what your future requirements will be and match that.  In my case I’ve selected medium.

This next screen relates to the new Single Sign On feature of vSphere 5.1.  Leave the default administrator user and enter in your master password you set during the installation of Single Sign On.  For the Lookup Service URL enter in your SSO server.  This will most likely be the same host.  Use the FQDN and the port.  By default the localhost is filled in so hopefully no change will be needed.

Next you’ll be presented with a Self-Signed certificate.  To proceed click Install certificate.

That’s all.  A little simpler than Single Sign On DB creation and installation.  Next you can finally install the vCenter Server with the prerequisites out the way.

vSphere 5.1 SSO and the FQDN issue

During the installation of the vSphere 5.1 Single Sign On component you will be prompted for the Fully Qualified Domain Name or IP of the server you are installing on.  If the server you are installing to does not have a DNS record the installation will fail and rollback.

More often than not you’ll have a forward lookup record for your host.  The SSO installation, however, will also perform a reverse lookup query on your IP.  If you don’t have a reserve record you will be prompted that the installation could not fully resolve the host and the installation may fail (I can tell you it WILL fail).

It’s important to check that the host you are using has both a forward and reverse record.

The vSphere SSO installation seems to take it one step further and query every interface on the server.  If you have multiple interfaces to different networks the installation will query the forward and reserve on all interfaces.  If records don’t exist for all these interfaces the installation will fail.  For the life of my I can’t figure out why this is import for all interfaces.

In my situation I had numerous interfaces on my blade server.  Particularly two iSCSI interfaces with no DNS records.  The installation would not let me proceed with a successful installation till they were fully resolvable or disabled.  It’s also worth noting that if you have link local addresses (i.e. 169.254.x.x) that they will be queried too and fail the installation.

You can confirm if the installation of SSO is failing by looking at the vm_ssoreg.log logfile under your user profile folder.

{system drive}users{username}AppDataLocalTempvm_ssoreg.log

Installing vSphere 5.1 – SSO

New in vSphere 5.1 is Single Sign On.  Whether you are installing vSphere vCenter 5.1 on a fresh system or upgrading from a previous version.  You will have to install SSO.  By using SSO, VMware components communicate with each other through a secure token rather than each component authenticating with an external source like Active Directory.

To install SSO, as with vCenter, you are required to create a DB to complete the installation.  In my case I used the same SQL server that has my vCenter DB taht I plan on upgrading.  You can make this DB prior to the start of the SSO installation or as I did create it sequentially during the installation process when prompted for a local SQL instance install.

Using your vSphere 5.1 media, mount and run and installation.  The product installation menu will appear as below.  Select vCenter Single Sign On and click the Install button.  Select a language and then click through the obligatory Welcome screen, patents and license acceptance.

The SSO installation will then start.  Again, whether an upgrade or a fresh install, if it’s your first 5.1 installation you’ll be selecting ‘Create the primary node…’

On the previous screen we selected our deployment type.  On this next screen we are selecting our Node Type.  in this case a basic node will do the job.

SSO uses an admin account to run.  This can’t be changed through the installation process.  The account is [email protected]  You are asked for a password for this account.  Record and remember this password as you will use it during other SSO deployments in your environment and additional vSphere product installations.

We are now prompted for a SQL Database type.  Unless you have a small environment or a test lab we probably won’t be using Express.  While there’s nothing wrong with MS SQL Express but if we have the opportunity to use or install a full copy of MS SQL Server (or heaven forbid Oracle) we will gain better growth and manageability over time.  As such I have choosen to use an existing SQL Server.

Now before we processed any further we have to create the DB.  SSO want a particular tablespace name and without the correct name the installation will fail.  Below I used SQL Server Management Studio and a SQL Query to create my DB with the required tablespace names.  As most of you aren’t DBAs i’ve attached the script I have used.


With the DB now created we can proceed with the remainder of the installation.  Enter in the DB name used and the hostname of the DB Server.

Enter in the Full name of the server including its domain that you are installing the SSO Server on.  Important-- Make sure that your server has both a forward and reverse lookup records.

Here we either use the Windows built-in Network Service account or we can create a domain account.  I tend to favor creating low privilege domain accounts that i can easily centrally control.

Depending on what your installation policy is like either leave the default location or choose to install to a different path.

Leave the default port and click next.

…and finally the install will now start and hopefully complete without error.