vCAC 6.0/6.1 build out to distributed model: Deploy the Identity 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. (more…)
Avoid SSO Admin lockout – a.k.a. your first task after installing vSphere SSO
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 firstname.lastname@example.org 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.
London VMUG – July 2013
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 (more…)
VMware vCenter Linked Mode not supported through firewalls
This article originally started off life as a record of how I managed to get this working, as a lot of my posts do, but this time it appears I am foiled.
Last week, I had 3 vCenter Servers that appeared to be happily talking to each other in Linked Mode sharing a singe Multi-site SSO domain without any real issues. I had a single-pane-of-glass view of all 3 and I could manage them all from the one client. The reason for the 3 vCenter servers was segregation of LAN and DMZ networks: vCenter001 was in the LAN, vCenter002 sat in DMZ1 and vCenter003 sat in DMZ2.
vCenter 5.1 Single Sign On Multi-Site error: User credentials are incorrect or empty
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@example.com 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.
Installing VMware vSphere Single Sign On (SSO) in Multi-site Mode
VMware vSphere Single Sign On (SSO) can be installed in Multi-site mode to support local sign-on to vCenters that you want to be part of the same single sign on domain – for example, if you want to install Linked-Mode and have the advantage of a single pane of glass view, but can’t risk using a single SSO instance across the WAN. In other words, from VMware’s blog post:
Multisite deployments are where a local replica is maintained at remote sites of the primary vCenter Single Sign-On instance. vCenter Servers are reconfigured to use the local vCenter Single Sign-On service and reduce authentication requests across the WAN. Multisite deployments do drop the support of single pane of glass views unless Linked Mode is utilized and multisite deployments are actually required to maintain Linked Mode configurations where roles, permissions and licenses are replicated between linked vCenter servers. Linked mode will re-enable single pane of glass views across multisite instances. (more…)