Posts in this series
- vCAC 6.0/6.1 build out to distributed model: Deploy the Identity Appliance
- VCAC 6.0 build-out to distributed model – Part 1: Certificates
- vCAC 6.0 build-out to distributed model – Part 2: vPostgres
- vCAC 6.0 build-out to distributed model – Part 3.1: Configure Load Balancing with vCNS
- vCAC 6.0 build-out to distributed model – Part 3.2: Configure load balancing with NSX
- vCAC 6.0 build-out to distributed model – Part 4: Deploying and clustering a secondary vCAC Appliance
SSO is a fundamental requirement when deploying vCAC, whether for a distributed or simple installation. This walk through goes through the deployment and configuration of the vCAC Identity Appliance, which provides a stand alone SSO instance for vCAC.
Some of the posts in this series are completed with vCAC 6.0.1, others will be with 6.1. Where there are differences I will aim to point them out!
Deploying the OVF
Deploying the OVF is very simple, just run through the wizard:
The appliance will perform a reverse lookup to get it's hostname - if you have pre-staged a DNS A and PTR record, and have a reservation set for the VM. If you statically assign an IP address, make sure you use the FQDN in the hostname field - not doing so will cause issues with the self-signed certificates and also when you join the Active Directory domain.
In my post yesterday (vexpert.me/hS) I talked about how to recover from an expired default SSO administrator password – this prompted a discussion on twitter with Anthony Spiteri (@anthonyspiteri) and Grant Orchard (@grantorchard) about the defaults for expiration and how to mitigate the risk.
The first solution is to modify the password expiration policy for SSO. I’m not advocating this necessarily – I think that expiring passwords ensure that you change them regularly and increase the overall security of your SSO solution. However, I can envisage situations (similar to mine) when the SSO administrator account is not used for a long time and expired – that causes headaches.
To modify the SSO password policy log onto the vSphere Web Client as the SSO admin (admin@system-domain for 5.1 or [email protected] 5.5) and select Administration, then Sign-On and Discovery > Configuration. Select the Policies tab – you should see the default config:
Click edit and set the password policy as required. This only applies to SSO users (i.e. those in the System-Domain or vSphere.local domains). To set the password to never expire in 5.1, set the Maximum Lifetime to 0 - for vSphere 5.5 you need to set to 9999 (Thanks to Hywel for his comments). IF you chose to do that, I’d beef up the complexity of your password policy to include upper, lower, numeric and special characters and increase the length from 8 to 13.
Similarly, you can edit the lockout policy which by default will lock you out if it has 3 failed attempts within 24 days. It will lock you out for 15 minutes. Setting the lockout time to 0 forces a manual unlock by an SSO admin.
The second option seems preferable to me (and Anthony and Grant) – that is to add some AD users or groups to the SSO administrators group. To do this, again log in as an SSO admin and select Administration, then Access > SSO Users and Groups, then the Groups tab. Select “__Administrators__” and click on the add principals button below. Select your AD domain from in the Identity Source field and search for your required user or group. Add them and click OK. Now those users, or group members have the ability to log on and reset or unlock the SSO admin account. AD accounts are obviously subject to your AD password policy, but can be reset independently of SSO and therefore don’t require you to use some command-line kung-fu to unlock.
Yesterday I attended my second ever #LonVMUG and did my first ever VMUG presentation! Generally it was a great day, with loads of really good sessions and some really cool community and vendor content.
As ever it was great day for socialising and networking with people who you interact with on twitter. For me one of the major benefits of the VMUG is learning from other people’s experience. Twitter was alive with the hastag #LonVMUG and it definitely adds something to the day to be active
The error thrown was:
User credentials are incorrect or empty. Provide correct credentials.
After a couple of hours online with VMware support I took a guess at the problem. On the existing Single Sign On Configuration I have added the Active Directory domain DefinIT and in order to enable integrated authentication from the vSphere Client I moved it to the top of the list - this meant that System-Domain is no longer the default authentication domain. The SSO admin account (admin@System-Domain) is a part of that domain and so my guess is that the installer tries to authenticate using [email protected] rather than System-Domain, which of course failed.
Moving System-Domain back to the top of the list allowed me to install correctly, and once finished I could drop it back down to allow integrated authentication again.