I’ve been playing around with SSO for a couple of weeks now, and I think the overall premise is good. “One ring to rule them all”, so to speak. And in that, I can get behind it. It will really come in handy when your environment gets large enough. To the point where a single entry point makes a lot of sense, and creates a large efficiency. With that said, there is at least one thing that will need to be updated before a large enterprise can rely on SSO as intended.
The identity sources will have to be modified, so there are more than just primary and secondary. A primary and secondary alone does not necessarily work for an organization that hosts dozens of domain controllers. Also, an installer that automatically adds in the local domain, and chooses a primary and secondary makes it difficult to authenticate when those two domain controllers go down. I know this first hand, because that is exactly what happened to me. Just my luck that the two servers chosen happen to both be down at the same time, but I would have hoped that in that scenario, there would be way to still authenticate against the other 15-20 servers that are still available. That is not what I discovered. I was effectively locked out of SSO. Thankfully, I could log back in through the vSphere client, and make sure my system-domain users had permissions added, but my user db of record was no longer active directory as intended.
So, I could work around the issue by going back to the identity source configuration section and modifying the auto inserted entry to include the domain name that is load balanced through DNS. However, if the modification has to be authenticated for some odd reason before it will save the provided information, the task will fail. The only choice left is to remove the source completely, and re-add. When I re-added, I was able to provide the DNS name as the primary, and left the secondary blank. This allowed me to save the identity source.
This should be the end, but since I had to remove the previous entry, I now also have to go back to the SSO Users and Groups section in Administration and re-add my domain group to the __Administrators__ group.
My access is once-again restored, albeit as a workaround.