Excellent; good job.
Next steps:
- login to the web client with admin@system-domain
- Navigate to Home > Sign-On and Discovery
- Click the green "+" and add an identity source (see example below)
- Click ok, then go back in and edit to click the "test connection"
- Launch a new vSphere Client using domain credentials to test your success
Adding Identity Source for a domain named example.com:
After navigating to the above location, this is an example of all fields filled in for a domain named example.com...
| Identity Source | Active Directory (radio button selection) |
| Name: | example.com |
| Primary server URL: | ldaps://dc01.example.com:3269 |
| Secondary server URL: | ldaps://dc02.example.com:3269 |
| Base DN for Users: | DC=example,DC=com |
| Domain name: | example.com |
| Domain alaias: | EXAMPLE |
| Base DN for groups: | DC=example,DC=com |
| Authentication type: | Reuse Session (drop down selection) |
More details on this topic here.
Be aware that:
- If your domain controller certs expire, a perfectly good SSO will quietly fail. The result will be that all authenticated sessions will be ok (i.e. vSphere client was already running), but any new sessions will be denied. Don't let your DC certs expire (set them to auto-renew). If your DC certs expire you will get the error listed in KB 1015639. The KB hasn't been updated to reflect this scenario, but it should be soon (actually spoke to the nice folks at VMware today about this one).
- Always delete and recreate the desired identity source as editing them currently does not work
- Put your SSO password in a lockbox of some sort and send yourself a calendar invite to reset the pw (the admin@system-domain password expires by default in 365 days)
Convenience:
- Normally your users will need to log in to the web client using domain\username (unless using passthrough auth). If they just type in the user name, it's more support calls for you. Check this vid by the Wahl Network on youtube to tweak that setting.
Best of luck and have fun!