Good morning folks,
Today we have the second edition of our new blog series The Inside Scoop. In this installment we will be focusing on the topic: Troubleshooting tips for common issues with vCenter Server Single Sign-On (SSO).
With the release of vSphere 5.1 the virtualization world was introduced to vCenter Server Single Sign-On. Along with the incredible new features and abilities that Single Sign-On offered, there was also some confusion around the installation and configuration of SSO amongst our user communities.
We met up with some of our front line Technical Support Engineers at our support center in Cork, Ireland and quizzed their brains for a little while in regards to Single Sign-On, and in order to get an insight into the common configuration issues that they see on a weekly basis, and also get some of their recommendations on how to troubleshoot common issues.
The primary area of expertise of these Engineers is our vSphere product family, more specifically, our vCenter Server product. They spend a large portion of their time helping customers troubleshoot the issues that they are encountering in their environments. Well, here is what they had to say…
Check your Identity Sources
One of the most frequent questions we receive from new users of Single Sign-On is:
Why am I unable to see the expected identity sources in my identity sources list?
The answer is actually quite a straight forward one. Identity sources will only be automatically discovered during the SSO installation if the user running the installation was a Domain Administrator. If a Local User ran the installation, then automatic discovery would not occur.
Another issue which pops up from time to time is when identity sources have been manually added by a user but the Domain Alias was never specified.
Ensure that you specify the Domain Alias when manually adding an identity source as without it the “Use Windows Session Credentials” option will not work. Also, it is worth noting that you cannot modify the Domain Alias after an identity source has been created. You will need to delete the existing identity source and re-create in order to add the Domain Alias.
Some users have also reported issues where they are experiencing longer than expected wait times upon logging into the vCenter Server system. In most cases, this can be easily resolved by adding the identity source to the list of Default Domains and moving it to the top of the list. This will speed up the authentication times as the first in the list will be the identity source that is queried first upon login. Good tip!
Note: Be sure to click the Save icon in order to save the changes to the Default Domains.
Don’t forget the Database Scripts!
When installing vCenter Single Sign-On you are presented with two options concerning which type of database you want to use for the Single Sign-On installation. These options are:
- Install a local Microsoft SQL Server 2008 R2 Express instance
- Use an existing supported database
Quite often we see Single Sign-On installations where this step is overlooked. If you choose to use the an existing support database option, you must run two SQL scripts prior to being able to install Single Sign-On. The install wizard will prompt you to perform this action. The two scripts are located on the vCenter Server 5.1 Installation Media in the \Single Sign On\DBScripts\SSOServer\schema\<DB>\ directory.
The two scripts are:
- rsaIMSLite<DBName>SetupTablespaces.sql
- rsaIMSLite<DBName>SetupUsers.sql
Clicking “Next” and progressing to the next section in the installation wizard without first having run the above mentioned database scripts, would result in an error message such as the one shown below because the installer will not be able to communicate with the database due to the fact that the database is not even there!
The log file quoted in the above error dialog box will contain an error message similar to the following:
ERROR 1217[main] – com.vmware.vim.installer.core.logging.CoreLoggerImpl.error(?:?) – Failed to established connection :com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user ‘RSA_DBA’
In order to ensure that your vSphere 5.1 environment gets off to the best start possible, whether performing an fresh install or upgrading from an existing vSphere 5.0.x version, it would be best to familiarize yourself with the various best practices and methods of installation and upgrading. The following VMware Knowledge Base articles would be a great place to start:
- Overview of upgrading from vCenter Server 5.0 to vCenter Server 5.1 (2032283)
- Installing vCenter Server 5.1 best practices (2021202)
- Upgrading to vCenter Server 5.1 best practices (2021193)
- Methods for installing vCenter Server 5.1 (2032885)
- Methods of upgrading to vCenter Server 5.1 (2021188)
Avoid unnecessary changes
Whenever we receive support requests from our user community complaining of symptoms such as “vCenter Server failed to start after restarting the Single Sign-On server”, one of the first areas we consider looking at is whether or not something has changed on the system where the Single Sign-On server is installed. If the system where the Single Sign-On server is installed is changed, this will cause the SSO server to fail to start and in turn will cause the vCenter Server from starting.
What kind of changes are we talking about?
For example:
- When updates are applied to the operating system
- The machine name changes
- The machine is added or removed from an Active Directory domain
- If you clone or change the parameters of a virtual machine where SSO is installed (such as the amount of RAM, the number of CPUs, the MAC address)
When it comes to the machine where the Single Sign-On installation is situated, it would be best advised to avoid making system changes on that machine whether it be a physical or virtual machine.
For additional information relating to this issue, check out VMware Knowledge Base article: After making a change or restarting Single Sign On server system, vCenter Server 5.1.x fails to start (2036170).
Single Sign-On Passwords
Sometimes we receive support requests from users looking for assistance relating to failed login attempts. The users report that they are no longer able to login with their Single Sign-On administrator credentials into their vCenter Server systems using the vSphere Web Client. Users who report this problem usually also see the following error message.
User account is locked. Please contact your administrator
Being unable to login using your SSO administrator credentials can occur for several reasons but we find that most common causes are either:
- Too many failed login attempts
- The password for the admin@system-domain user has been changed
- The Single Sign-On passwords have expired
For security purposes, the administrator account is automatically locked out if there are too many failed login attempts. By default, vCenter SSO allows for three failed login attempts before an account is locked out. These policies can be modified and the instructions for doing so are found in VMware Knowledge Base article Configuring and troubleshooting vCenter Single Sign On password and lockout policies for accounts (2033823).
At the time of installation the password for the admin@system-domain user is defined. This also defines the password for the “Master” password. It is worth noting that changing the password for the user admin@system-domain does not change the Master password. The Master password continues to remain the same as the original password that was defined at installation time and for this reason it is recommended that you always keep a note of this password as you may need it in an emergency. If your SSO administrator password needs to be unlocked or reset, see VMware Knowledge Base article Unlocking and resetting the vCenter Single Sign On (SSO) administrator password (2034608) for details.
Single Sign On account passwords expire after 365 days, including the password for admin@system-domain user. To reset SSO user account passwords, refer to VMware Knowledge Base article Resetting an expired password in VMware Single Sign On (SSO) (2035864).
Watch out for Non-ASCII characters
In the initial releases of vCenter Server 5.1, Single Sign-On installations may have failed due to SSO administrator passwords containing non-ASCII characters. This issue has since been resolved with the release of VMware vCenter Server 5.1.0a, but if you are running on an older release and are seeing errors such as “Error 29133 Administrator login error” or “Error 29158 Node package creation error“, then we would recommend that you update your system to either of the more recent 5.1.0a or 5.1.0b releases as soon as you can. Additional information concerning this issue is available in KB article: vSphere 5.1 Single Sign On (SSO) installation fails with error: Error 29133. Administrator login error (2035820).
Well, that concludes our Inside Scoop edition for this week. We hope this will be of some help to you in keeping your vCenter Server Single Sign-On environments running as smoothly as possible. Be sure to check back with us again in the coming weeks for the next edition of The Inside Scoop!