This article will list the steps required to successfully load balance vCenter’s Single-Sign on using the vShield Edge Device.
To make things easier to understand, we will reference the topology previously described here

Note: vShield edge is only available as part of the VMware vCloud Suite.

Pre-requisites

  1. vShield Manager OVA Deployed
  2. Installed and Configured Microsoft Enterprise CA
  3. Open SSL version 0.9.8 Downloaded here: http://slproweb.com/products/Win32OpenSSL.html
  4. vCenter Certificate Automation Tool 5.5

 

Step 1: Configure the vShield Edge Device

  1. Once you have successfully deployed the OVA File; access the vShield Manager Web Interface using https://url_of_vShield Manager – You’ll need to set this up to connect to your vCenter initially. Once complete, you can access the configuration page via the vCenter UI – Home -> Inventory – > Datacenter Name -> Network Virtulization Tab
  2. Under Datacenters, click on your Datacenter name, then click on Network Virtualization. It’s time to deploy our edge device; Click on the default_plus 

    vshield_sso_config_ (1)

  3. Give your edge device a name and description also ensure your enable HA. This will ensure that there are 2 Edge devices deployed for redundancy and the appropriate DRS Rules will be created in vCenter to ensure they live on separate hosts.

    vshield_sso_config_ (2)

  4. Set your CLI Credentials to access the console if need be – SSH Access is always a good idea; though depends on your security policies

    vshield_sso_config_ (3)

  5. The next step is to set your Appliance Size. The size that you set will determine the resources (vCPU + Memory + vDisk) assigned to the Virtual Machine. Ref: KB2055673. Enable Auto Rule generation. You also need to specify where the edge devices will be deployed; (Cluster, Datastore, Host) Click on the default_plus to specify these details

    vshield_sso_config_ (4)

  6. Time to configure our interfaces – The vCNS Edge device can have up to 10 virtual interfacesThe first one we’ll create is attached to the VM Network – Click on the default_plus to setup the interface type (internal or uplink) and the port group that it’s attached to. The IP address set on the interface is what the edge device will use when we configure load balancing – Back to my topology 192.168.99.28 is my Virtual IP

     

    I’ve also create a secondary interface to separate my Edge HA Heartbeat\Stateful traffic from VM workloads

    vshield_sso_config_ (9)

  7. Depending on your setup, you’ll now need to configure the default Gateway – As vCNS Edge is a Router/Firewall/Load Balancer/VPN, you need to set the next hop + the Interface for connectivity
    vshield_sso_config_ (8)
  8. Configure your Firewall Default Policy – For the purpose of this demonstration, i’ve set the Default Traffic Policy to Accept. This will depend on whether you’re using the vCNS Edge device as a firewall, or if you’re using just using the load-balancing functionality in which case you probably don’t want to have the management overhead of managing another firewall.

    You’ll also need to set the interface that HA heartbeats between edges will traverse – In my previous example, this was interface_ha – I’ve also set IP addresses on the Management interfaces to assist with SSH Access.
    vshield_sso_config_ (7)

  9. After reviewing the Summary – Click Finish and you’ll see the Edge device commencing deployment – If you take a look at your vCenter Server; you’ll also notice the Edge Devices being deployed – Remember our HA Configuration

    vshield_sso_config_ (13)

    vshield_sso_config_ (14)

  10. Time to setup our load balancing now for vCenter Single Sign-On – Change your View to be Edges – This will list all the edges currently managed by vShield Manager.Click on your edge device then Actions -> Manage

    vshield_sso_config_ (15)

  11. Set the Load Balancer Service to Enabled then click on the default_plus to configure our Load Balancing Pool vshield_sso_config_ (16)
  12. Give your Single Sign On Service a friendly name and click Next 
    vshield_sso_config_ (17)
  13.  Configure the Services that we will be listening/load balancing on as well as the Balancing Method. vCenter Single Sign-On listens on 7444 so we’ll configure that service using the Balancing Method – Least_Conn eg. Balance on the least amount of connections. The other option would be to use Round_Robin which vCNS also supports.
    vshield_sso_config_ (18)
  14. Here we can set additional parameters to determine the health of the services and relevant time-out settings.
    There’s also a provision to check a specific URL (using a HTTP_GET)
    vshield_sso_config_ (19)
  15. Now onto the Members – Here is where we set our Single Sign-On Servers that are going to participate in the Load Balancing Group.

    Referring back to my example;
    SSO1.Skynet.local = 192.168.99.23
    SSO2.Skynet.local = 192.168.99.24

    If you have a “weighting” preference, you could also influence the Load Balancing Priority amongst the members
    vshield_sso_config_ (20)

  16. Once you’re happy with the configuration – Click Finish. Note: You’ll need to Publish the changes for them to take effect

    vshield_sso_config_ (21)

  17. We’re now onto the final stages of our Load Balancer Configuration: Setting up the Virtual Server.

    To do this, click on the Virtual Servers link.

    vshield_sso_config_ (23)

  18. Give your Virtual Server a friendly Name – As well as the IP Address it will be listening on – Remember this is the interface we configured earlier when deploying the Edge Device.

    Note: Existing Pool will be the Pool we configured earlier and your Services will entail TCP 7444 (vCenter’s Single Sign-On Communication port.Make sure you set the Virtual Server to Enabled, then click Add

    vshield_sso_config_ (31)

This concludes the Load Balancer Configuration – Next create the appropriate DNS Record in your DNS Zone to resolve to the IP Address you’re using for the Virtual IP – In my case loadbalancer.skynet.local  resolves to 192.168.99.28

Step 2: Setup Microsoft Enterprise Root CA

We now need to setup our Microsoft Enterprise Root CA to issue certificates that are compatible with vCenter’s Encryption Standards.
I assume that you’ve installed the Role using Server Manager, so let’s begin with setting up a custom template.

  1. Open up your Microsoft Certificate Authority (Click Start > Run, type certsrv.msc, and click OK)
  2. Right Click on Certificate Templates and select Manage
  3. Navigate to the pre-defined template “Web Server”; right-click and select “Duplicate Template” vcenter_sso_cert_ (1) 
  4. Select your Certificate Template compatibility level depending on your topology; for the basis of this blog, I’ve kept it to “Windows Server 2003 Enterprise” 
  5. Give your template a friendly name – This will be displayed when we request a certificate. Also set a Validity and Renewal period depending on your organizations policies.vcenter_sso_cert_ (2)
  6. Click the Extensions tab, then Select Key Usage and click Edit.
    vcenter_sso_cert_ (3)
  7. Select the Signature is proof of origin (nonrepudiation) option and Select the Allow encryption of user data option – Click OK.
    vcenter_sso_cert_ (4)
  8. Select Application Policies and click Edit
    vcenter_sso_cert_ (5)
  9. On the “Edit Application Polices” window, select Client Authentication then click Add.
    vcenter_sso_cert_ (7)
  10. Select Client Authentication.
    vcenter_sso_cert_ (6)
  11. Click OK.
  12. Click OK again.
  13. Click the Subject Name tab.
  14. Ensure that the Supply in the request option is selected.
    vcenter_sso_cert_ (8)
  15. Click OK to save the template.
  16. Next close the Certificates Templates Console, I assume that you still have the Certsrv.msc window still open; right-click on Certificate Templates, select New then Certificate Template to Issue
    vcenter_sso_cert_ (9)
  17. Now Select the template you previously created – In my case this is VMware Certificate
    vcenter_sso_cert_ (10)

This concludes the CA Authority configuration. Now let’s proceed with the Installation of vCenter’s Single Sign-on….As we have a greenfield site, we’ll first setup the Primary node – SSO1.skynet.local

Step 3: Installing vCenter’s Single Sign-On

Let’s begin the installation of vCenter’s Single Sign-On component.

  1. Run the vCenter Single Sign-on Setup wizard, proceed and accept the EULAvcenter_sso_install_ (1)
  2. Ensure that the information displayed in the prerequisites check is correct then proceedvcenter_sso_install_ (2)
  3. In the Single-Sign-On Deployment type; select “vCenter Single Sign-On for your first vCenter Server” and click nextvcenter_sso_install_ (3)
  4. In the “Site Name” field, give your site a name – This is what helps us identify which site\topology we’re working with when troubleshooting or adding additional service. If you’re a Microsoft admin, this is similar to your AD Sites and Servicesvcenter_sso_install_ (4)
  5. Leave the HTTPS port to the default 7444 and click “Next”vcenter_sso_install_ (5)
  6. Set the installation directory or leave the default and click nextvcenter_sso_install_ (6)
  7. Once you’re happy, click installAt this point our first Node is active (sso1.skynet.local); we can now proceed to installing the Secondary Single Sign-On Node (SSO2.Skynet.local)vcenter_sso_install_ (7)
  8. On the second node (in my case sso2.skynet.local) Run the vCenter Single Sign-on Setup wizard,
  9. Proceed and accept the EULA
  10. In the Single-Sign-On Deployment type; select “vCenter Single Sign-On for an additional vCenter Server in an Existing Site” and click next
    vcenter_sso_install_ (9)

     

  11. Enter the account credentials for the Primary SSO instance we installed earlier – in my case “sso1.skynet.local and click next
    vcenter_sso_install_ (10)

     

  12. Accept the partner certificate (We’ll change this after” and click continue 

    vcenter_sso_install_ (11)

  13. Here we select our Site Name – Click on the drop-down list and select the site that this Single Sign-On Server will be apart of and click next
    vcenter_sso_install_ (12)

     

  14. Leave the HTTPS port to the default 7444 and click “Next”
  15. Set the installation directory or leave the default and click next
  16. Once you’re happy, click install

vcenter_sso_install_ (14)

Now that we have our Node installed, the next part is to assign them Enterprise CA signed Certificates.

Step 4: Requesting SSL Certificates from the Enterprise Root CA

We’re now up to the stage where we request an SSL Certificate from our Enterprise Root CA and install it onto our SSO Nodes.

Take your time with this section as it is quite long – I’ve tried my best to simplify it as much as possible.

Let’s cover the pre-requisites first, In order for your CA signed certificate implementation to work, your Certificate must include   –

  1. The load balancers FQDN as the Common Name 
  2. Each servers hostname, FQDN, Load balancers FQDN and Virtual IP as the Subject Alternative Name

In my example, this would translate to;

Common name: loadbalancer.sjynet.local

Subject Alternative name: sso1, sso1.skynet.local, sso2, sso2.skynet.local, loadbalancer.skynet.local, 192.168.99.28

  1. RDP or open the Console to your first SSO Server (In my case; SSO1.skynet.local)
  2. Install Open SSL version 0.9.8 Downloaded here: http://slproweb.com/products/Win32OpenSSL.html – Note: Install the 32bit version!
  3. Install the VMware Certificate Automation tool 5.5 –
    Download it here: https://my.vmware.com/web/vmware/details?downloadGroup=SSLTOOL550&productId=353
  4. Create a certificate folder structure; in my case I will use C:\Certs
  5. We now have to create the SSL Configuration files; this is what SSL will interpret when creating the SSL Request.
    Refer to KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2044696Create a file in C:\Certs called sso.cfg then copy the following text into the configuration file:Items in bold will need to be changed to reflect your SSO Setup; however if you refer to my example, you will see that my Subject Alternate Name reflects the SSO nodes + Load Balancer.
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req
 
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:sso1, DNS:sso1.skynet.local, DNS:sso2, DNS:sso2.skynet.local, DNS:loadbalancer.skynet.local, IP:192.168.99.28
 
[ req_distinguished_name ]
countryName = AU
stateOrProvinceName = AU
localityName = Sydney 0.
organizationName = Skynet
organizationalUnitName = vCenterSSO
commonName = loadbalancer.skynet.local

 

vcenter_sso_cert_ (13) 

  1. Now Launch a command prompt and navigate to the OpenSSL directory. By default, this is C:\OpenSSL-Win32\bin.
    Run this command to create the vCenter SSO certificate request and export the private key:

    openssl req -new -nodes -out c:\certs\rui.csr -keyout c:\certs\rui-orig.key -config c:\certs\sso.cfg

vcenter_sso_cert_ (14)

  1. Convert the key to be in the proper RSA format in order for vCenter Server to recognize the Singe Sign-On Certificate:
openssl rsa -in c:\certs\rui-orig.key -out c:\certs\rui.key

vcenter_sso_cert_ (15) 

  1. Now time to send the key request off to your Enterprise Root CA; to do this, http to your enterprise root CA.
    This is usually HTTP://Enterprise_root_Server/Certsrv
  2.  Click Request a Certificate
    vcenter_sso_cert_ (16)
  3. Select Advanced Certificate Request
    vcenter_sso_cert_ (17)
  4. Select “Submit a Certificate request using a base-64-encoded…..”
    vcenter_sso_cert_ (19)
  5. Paste the contents of the RUI.CSR File (This was generated by the OPENSSL syntax we ran in step 6) and also remember to Set your Certificate Template to be that of the one we created earlier in Step 1 – Create a custom Certificate Template
    vcenter_sso_cert_ (20)
  6. Click Submit
  7. We now have a certificate! Set the encoded format to Base 64 encoded then click Download Certificate. Save the file in your C:\Cert folder and give it a friendly name. In my example, this is SSO_Key.cer
    vcenter_sso_cert_ (22)
  8. Now that we have a key, we also need to bind this key to the enterprise roots CA to form a chain – Go back into your Enterprsie Root CA Request page and select Download a CA Certificate, Certificate Chain or CRL

     

  9. Select your encoding method to be Base 64 and click Download Certificate chain
    vcenter_sso_cert_ (26)
  10. Save the file in your C:\Cert folder and give it a friendly name. In my example, this is Root_CA_Chain.p7b.
  11. Open the Root_CA_Chain.p7b File (Double-click in explorer)  – This should launch the Certificate Manager Console; Navigate to the Certificates  folder in the tree, then right-click on your Issuing Authority and select Export. Store this Certificate in your C:\Certs folder as Base64.cer

     

    Remember to set to Base-64 Encoded.
    vcenter_sso_cert_ (28)
    vcenter_sso_cert_ (29)

     

  12. Now time to marry them up the certificates! –
    Create a new file in C:\Certs called SSO_key.pem and paste the contents of the SSO Key: SSO_Key.cer first followed by Base64.Cer.

    The Contents should look similar to this (I’ve truncated the certificate for the purpose of this illustration)

    Note: It’s extremely important here that you don’t add any whitespaces otherwise the PEM File will fail!

vcenter_sso_cert_(33)

Step 5: Configure the Single Sign-On Services.

We now need to configure the Administrative, Secure Token and Group Check services to communicate via the Load Balancer and replace the certificates.

  1. In the command prompt of the first SSO node, run this command to get the service endpoints.
    This command is found at: C:\Program Files\VMware\Infrastructure\VMware\CIS\vmware-sso

    ssolscli.cmd listServices https://sso1.skynet.local:7444/lookupservice/sdk

    In my case; sso1.skynet.local is my first single sign-on instance.
    vcenter_sso_cert_(36)

  2. Using the output above, Create three files in your C:\Cert directory
    sts_id
    admin_id
    gc_id

    Note: these files do not have file extensions!

  3. Edit the files: sts_id, admin_id, and gc_id files to match the ServerId’s (description) from the output of the “ssolscli.cmd listServices” command we ran previously.

    When running the command, you will notice that the 3 Services listed are that responsible for the:

    Administrative Service
    Secure Token Service
    Group Check Service

    Based on my example, I’ve copied and pasted the “serviceId” from the services into the respective file. The file show not contain anything else.  
    vcenter_sso_cert_(37)

  4. We now  need to create three text files within the C:\certs directory in order to change the Single Sign-On’s load balancer configuration.
  5. Create the following 3 Text files in the C:\Cert directory

    admin.properties
    gc.properties
    sts.properties

 For the admin.properties file (Filename: C:\certs\admin.properties) copy\edit the following lines; replacing items in bold to reflect your setup

 

  1. [service]
  2. friendlyName=The administrative interface of the SSO server version=1.5
  3. ownerId=
  4. productId=product:sso
  5. type=urn:sso:admin
  6. description=The administrative interface of the SSO server
  7.  
  8. [endpoint0]
  9. uri=https://loadbalancer.skynet.local:7444/sso-adminserver/sdk/vsphere.local
  10. ssl=c:\cert\sso_key.pem
  11. protocol=vmomi

 

For the gc.properties file (Filename: C:\certs\gc.properties) copy\edit the following lines; replacing items in bold to reflect your setup

 

  1. [service]
  2. friendlyName=The group check interface of the SSO server version=1.5
  3. ownerId=
  4. productId=product:sso
  5. type=urn:sso:groupcheck
  6. description=The group check interface of the SSO server
  7.  
  8. [endpoint0]
  9. uri=https://loadbalancer.skynet.local:7444/sso-adminserver/sdk/vsphere.local
  10. ssl=c:\cert\sso_key.pem
  11. protocol=vmomi 

For the sts.properties file (Filename: C:\certs\sts.properties) copy\edit the following lines; replacing items in bold to reflect your setup

 

  1. [service]
  2. friendlyName=STS for Single Sign On
  3. version=1.5
  4. ownerId=
  5. productId=product:sso
  6. type=urn:sso:sts
  7. description=The Security Token Service of the Single Sign On server.
  8.  
  9. [endpoint0]
  10. uri=https://loadbalancer.skynet.local:7444/ims/STSService/vsphere.local
  11. ssl=c:\cert\sso_key.pem
  12. protocol=wsTrust 
  1. The next step is to update the Single Sign-On Service. Run the following commands in order.
    1. ssolscli updateService -d https://sso1.skynet.local:7444/lookupservice/sdk - u administrator@vsphere.local -p your_sso_password -si C:\cert\gc_id –ip C:\cert\gc.properties
    1. solscli updateService -d https://sso1.skynet.local:7444/lookupservice/sdk - u administrator@vsphere.local -p your_sso_password -si C:\cert\admin_id –ip C:\cert\admin.properties
    1. ssolscli updateService -d https://sso1.skynet.local:7444/lookupservice/sdk - u administrator@vsphere.local -p your_sso_password -si C:\cert\sts_id –ip C:\cert\sts.properties
  2. Once complete – Perform the same for the 2nd SSO Server; in my case that is sso2.skynet.local; So I will execute;
    1. ssolscli updateService -d https://sso2.skynet.local:7444/lookupservice/sdk - u administrator@vsphere.local -p your_sso_password -si C:\cert\gc_id –ip C:\cert\gc.properties
    1. ssolscli updateService -d https://sso2.skynet.local:7444/lookupservice/sdk - u administrator@vsphere.local -p your_sso_password -si C:\cert\admin_id –ip C:\cert\admin.properties
    1. ssolscli updateService -d https://sso2.skynet.local:7444/lookupservice/sdk - u administrator@vsphere.local -p your_sso_password -si C:\cert\sts_id –ip C:\cert\sts.properties

Step 6: Replace Single Sign-On Certificates

Now that we have configured Single Sign-On to use Certificate files, the last step is to replace the Self Signed Certificates with our CA Signed ones using the Certificate Automation Tool.

  1. Extract the VMware Certificate Automation Tool 5.5  files to a directory.
  2. Navigate to the install directory where you extracted the files and run SSL-Updater.bat
  3. Select Option 3: Update Single Sign-On
  4. Select Option 1: Update the Single Sign-On Certificate The wizard will ask you for the following inputs; 

Enter location to the new Single Sign-On SSL Chain:
Response is: C:\Cert\SSO_key.pem
Enter location to the new Single Sign-On Private Key:
Response is: C:\Cert\rui.key
Enter Single Sign-On Administrator User:
Response is: administrator@vsphere.local
Enter Single Sign-On Administrator Password
Response is: ****The Password you entered during installation****
Is the current machine hosting a primary Single Sign-On node?
Response is: Yes
Is the single Sign-On administrator service accessed via the load balancer?
Response is: Yes
Enter the Single Sign-On HA Load Balancer Certificate
Response is: *** Not required, Press ***
Enter the Single Sign-ON HA Load Balancer hostname
Response Is: *** Not required, Press ***

vcenter_sso_cert_(35)

  1. Now that we have update SSO1.Skynet.local (My Primary SSO Server; time to repeat the above for my Secondary SSO Server – SSO2.Skynet.local.
  2. Good news is that we already have a Certificate, so all we need to do is copy the C:\Cert folder to SSO2.Skynet.local as well as the Certificate Automation Tool Zip File.
    Execute the SSL-updater.bat file and repeat the above steps on your 2nd SSO Server, however when you get to the prompt:

    Is the current machine hosting a primary Single Sign-On node?
    Response is: No.
  3. Congratulations! – Our Certificates are now up to date on BOTH SSO Nodes – Test your configuration by installing the respective vCenter services (Web Client, Inventory, vCenter)
    Note: Some further considerations during the Installation of vCenter, Inventory Services and Web client:
    1. During the setup of vCenter, Web Client, Inventory Services, you’ll need to enter: https://fqdn_of_loadbalancer:7444/lookupservice/sdk as the “Lookup Service URL”. In my example, this will translate to: https://loadbalancer.skynet.local:7444/lookupservice/sdk
    2. Ensure that you also update the Certificates for vCenter, Inventory Services and Web Client; this can be achieved by using the vCenter Certificate Automation Tool 5.5