I don't envision this working at all.
You are logging in to Main Site using SSO.... Session per user is sending Main Site SSO token through plug-in to remote site that is not using same SSO source = no authentication since remote site doesn't use the same SSO source..
You need to use Share a unique session when defining your remote servers in the Mult-Site plug-in.
OK thanks for the info. Question though:
If I use share a unique session, the session I use would be based on a service account from AD. (I'm using SSO authentication, and SSO is in turn using AD as an identity source, and that service account lives in AD).
So I this case also, I would have the same problem - I'm using SSO at the main site as the basis for that shared unique session.
So if the fact that I'm using different SSO servers and different vCenters and different AD servers at each site means that I can't use "session per user" authentication, why would I be able to use "share a unique session"?
If I switch to "share a unique session", that won't change the fact that I'm using different SSO servers at each site, it will only change the user name that the session at the main site is based upon from being a user account to a service account, but not change any other aspect of the authentication process.
With this in mind, how would using "share a unique session" be different?
It is different because it should let you specify a username and password for each remote vRO host which in turn should authenticate on their respective SSO.
ok great thanks
As you are using the vRO Multi-site for several years now, how do you feel about the vRO multi-site feature robustness for an Enterprise size environment? I work for big insurance company and want to implement this solution to cover over a dozen of sites and more than fifty vROs as slaves. Initially we run on a need basis to kickoff remote workflows from Master but later bases on the results we may expand the usage.
Any one using this feature is welcome to respond to this question.