VMware Cloud Community
Windspirit
Hot Shot
Hot Shot
Jump to solution

Multi-node pug-in dosnt work with SSO

Hi all,

Problem:

Using the multi-node plugin with 5.5.2.1 I get an error when trying to add another Orchestrator. Error message:

Unable to convert object, 'com.vmware.o11n.plugin.vcoconn.model.RemoteServer@56aeb048' plugin exception reason : convertToResult() --> Finder 'VCO:RemoteServer' : unexpected error 'ch.dunes.model.sdk.SDKFinderException: convertToResult() --> Finder 'VCO:RemoteServer' : unable to invoke read method : 'name''

It works fine just using a NON-SSO configuration (out of the box with vcoadmin). As soon as I configure it for SSO it dosnt work anymore.

Even more wired: SSO configured, in the Add a vCO server dialog, choose SSO enabled:No, Shared:YES. Will add the Orchestrator but will report it as offline. You will have to delete its Config out of the resources to get rid of it as you cant even dlete it.


System:

Both Orchestrator Appliances are 5.5.2.1 and are configured to the same SSO (5.5U2).

Reply
0 Kudos
1 Solution

Accepted Solutions
popove
VMware Employee
VMware Employee
Jump to solution

Hi Windspirit,

A workaround to this is to set the settings "SSO enabled" to false and "Shared" to true and then to provide the shared account in the "Add a vCO server" workflow.

There is a KB article dealing with that issue - Using Single Sign-On authentication on a remote Orchestrator server might cause problems with the Multi-Node plug-in (2095701)

View solution in original post

Reply
0 Kudos
7 Replies
popove
VMware Employee
VMware Employee
Jump to solution

Hi Windspirit,

A workaround to this is to set the settings "SSO enabled" to false and "Shared" to true and then to provide the shared account in the "Add a vCO server" workflow.

There is a KB article dealing with that issue - Using Single Sign-On authentication on a remote Orchestrator server might cause problems with the Multi-Node plug-in (2095701)

Reply
0 Kudos
Windspirit
Hot Shot
Hot Shot
Jump to solution

Thats what I tried, and thats the wired stuff I mentioned, just wrote Shared:NO and thats wrong I meant YES. So no that dosnt work.

Reply
0 Kudos
popove
VMware Employee
VMware Employee
Jump to solution

Can you retry the proposed setup.

I have tested this locally and by providing the shared credentials it is working fine.

Reply
0 Kudos
Windspirit
Hot Shot
Hot Shot
Jump to solution

Just retested it. Installed fresh vROs 5.5.1.2 and made sure vCenter (SSO) is latest.

NoGo.

See screenshots:

Reply
0 Kudos
popove
VMware Employee
VMware Employee
Jump to solution

This behavior is observed when you have improper configurations saved in the database. When you open the inventory the plugin tries to construct objects from these configurations and failes.

So make sure you do not have improper configurations. They are located in the Resources->Library->VCO->Configuration (Design View) and to be sure better delete all of the configs listed there

and then add a new remote vRO as the prescribed way.

I have tested this locally and it fails when you have improper configurations in the resources but when they are removed averything connects and works fine.

I have also deployed two vROs 5.5.2.1 with SSO 5.5.2.

Reply
0 Kudos
Windspirit
Hot Shot
Hot Shot
Jump to solution

Pls check your private messages in the forum. Thanks

Reply
0 Kudos
Windspirit
Hot Shot
Hot Shot
Jump to solution

OK...I could replicate that now.

However, one think I found is that this also happens if you added the SSL cert with IP instead of FDQN.

Anyway...CASE CLOSED.

THANKS

Reply
0 Kudos