Giving up on my 1st environment for now with the install errors, I moved on to my 2nd environment. The 1st is completely isolated, but the 2nd is a nonprod environment that is similar to my prod config. I also decided to add this SSO server to my prod domain, and see what would happen when I had multiple domains in my infrastructure, and how easily I could configure things to work correctly. So, I spun up a new virtual machine, and decided to start clean and install SSO standalone from vCenter. The install failed initially when I changed install path to D:, which was again infuriating, but leaving the default path allowed successful completion of the SSO installer. So, at this point, at least I can move forward.
I will add that it’s a little disappointing that there isn’t an easy way to verify/test that the install went well, and the service is up and running as expected. I can open a browser to the SSO port, but it’s garbage in-garbage out, and you get an error. Doesn’t give that warm and fuzzy that I was looking for, so I had to take it on faith that it installed correctly, and decided to move on.
Next part would be to upgrade vCenter Inventory Service on the existing vCenter vm, and that went just fine, and connected back to the SSO server without a problem. Next up was vCenter, and that went cleanly as well. I will say that the installer did warn that the permissions on the vCenter server would be modified, and I did have to recreate permissions in a few cases.
Once vCenter was installed, I went back to my SSO server, and decided to install my WebClient server on the same VM. The installer went fine, and was able to connect to SSO. Since this VM was not hosting vCenter, I also changed the default WebClient ports from 9443 to 80 and 443, so I didn’t have to force people to remember that when they tried to connect using this method, and to wean them off the fat client.
Once installed, I logged into the web client, using the admin@system-domain, since that’s all there was setup right now, and I was able to get into the GUI. Now, even though I had vCenter connected to SSO, I could not see any of the vCenter objects. I went back and checked all my configurations, and could see in all of the logs that I was connected to vCenter and SSO respectively. So, at this point, it appears to be a permissions issue, and not a configuration problem or install failure per se.
Now, since SSO is in one domain, and the vCenter is in another, I wanted to make sure this wasn’t the cause for my lack of vCenter objects. I logged into the web client, and went into the administration section, and clicked on the Sign-on and Discovery configuration. As expected, my default prod domain, which SSO vm is a part of, was visible as an identity source, as was the default system-domain, and nothing else.
Adding the domain where my nonprod vCenter exists was easy enough,
- Click the little plus sign in Identity Sources
- Select active directory as the type
- Provide a name
- In the Primary and Secondary URLs, use ‘ldap://’ as the source type before the server name and then the port
- The port could be 389 or 3268 for active directory using ldap
- The port could be 636 or 3269 for active directory using ldaps
- Base DN by default is your domain name components prepended by ‘dc’
- Domain name is self-explanatory
- Alias should also be pretty intuitive, what do you want to call your source?
- DN for groups is the same as your base DN by default
- Authentication type will need to be ‘Password’
- Unless the new domain will authenticate using the account you have already logged in with, you will need to use password, Password authentication allows you to provide an account in the remote domain that has access authenticate users. Without this in place, the connection to the non SSO domain will fail
- Username and Password for the remote domain
Now that the identity source has been added, we will need to provide roles and/or permissions. Go back to your web client, administration section, ‘SSO Users and Groups’, and click over to the ‘Groups’ tab. Here is where we will add our domain users into the proper groups. I only have need to add the Administrators right now, so I’ll click over to the __Administrators__ group, and click the ‘Add principals’ button at the top. Select the appropriate domain, and search for the user or group you wish to add to the administrators section. Once you’ve found the correct user/group, make sure you select it and click the add button. This should put the selected user/group into the bottom window.
You can now log off as admin@system-domain, and log back in as user@domain that you added.
This let me back in as an administrator, but I still did not see any connected vCenters and/or vms and hosts. I finally logged into my vCenter directly with the fat client I installed previously, and checked my permissions. Remember earlier when I mentioned getting a warning about permissions? Well, modified they were. I had to recreate permissions from my domain, but when I did go to add a permission, I did notice that I had options to add permissions from the vCenter server itself, from the system-domain from SSO, the domain SSO was a part of, as well as the new domain I added from above. Very cool.
Once I added permissions, ahem, again, I could see the connected vCenter and all of its members. I went back in an added permissions from my prod domain, and I could now log into to the WebClient once, and be granted permissions over all of the environments I wished to manage. Indeed making administration, after the initial setup, much easier.
Hope that helps.