Upgrading vCenter Server to 5.5 U1 Broke vCO AD Plugin

[pwmiller]

Hey guys,

I recently upgraded vCenter Server (in Windows) to 5.5 U1, and thus vCO was upgraded to the most recent version as well. It looks like the AD plugin was upgraded to 1.0.4-763, and now cannot be correctly configured. The logs from vCO give the following:

2014-05-12 12:11:14.141-0400 [WorkflowExecutorPool-Thread-1] ERROR {Administrator@VSPHERE.LOCAL:Configure Active Directory server:8a6abc61-9f1e-4b75-84e3-5f7ed902af57:1d74889645f12cdf0145f133c1e20009} [MSPluginFactory] Provided credentials are corrupted.

java.lang.RuntimeException: org.bouncycastle.crypto.InvalidCipherTextException: pad block corrupted

at ch.dunes.util.PasswordEncryptor.decrypt(PasswordEncryptor.java:76)

at ch.dunes.util.EncryptHelper.newDecrypt(EncryptHelper.java:61)

Furthermore, when I attempt to configure an AD server using the plug-in, I get the following issue, showing me that one of the configuration objects is null - "ConfigurationManager".

2014-05-12 12:11:14.251-0400 [WorkflowExecutorPool-Thread-1] WARN  {Administrator@VSPHERE.LOCAL:Configure Active Directory server:8a6abc61-9f1e-4b75-84e3-5f7ed902af57:1d74889645f12cdf0145f133c1e20009} [WorkflowItemTaskRunner] Script execution error on workflow : Configure Active Directory server / 'Update Configuration'(item1) : ReferenceError: "ConfigurationManager" is not defined. (Workflow:Configure Active Directory server / Update Configuration (item1)#10)

2014-05-12 12:11:14.351-0400 [WorkflowExecutorPool-Thread-1] ERROR {Administrator@VSPHERE.LOCAL:Configure Active Directory server:8a6abc61-9f1e-4b75-84e3-5f7ed902af57:1d74889645f12cdf0145f133c1e20009} [SCRIPTING_LOG] [Configure Active Directory server (5/12/14 12:11:12)] ReferenceError: "ConfigurationManager" is not defined. (Workflow:Configure Active Directory server / Update Configuration (item1)#10) - null

We are not using LDAPS, just standard LDAP, so I can't see why we'd be getting a crypto exception, and the configuration object "ConfigurationManager" being null is interesting.

Is there any way to reset the plugin configuration, reestablish a connection, and try again? I'd prefer not to reinstall this vCO, as we have done a lot of configuration.

Uninstalling and reinstalling the 1.0.4 plugin doesn't seem to resolve the issue. Can or should I revert to 1.0.3?

Thanks for all of your help.

[pwmiller]

Reinstalling the 1.0.3 plugin also doesn't seem to work. Does anybody have any ideas? We're seeing 'pad block corrupted' errors:

type Exception report

message java.lang.RuntimeException: org.bouncycastle.crypto.InvalidCipherTextException: pad block corrupted

description The server encountered an internal error that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: java.lang.RuntimeException: org.bouncycastle.crypto.InvalidCipherTextException: pad block corrupted  org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:515)  org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:422)  

root cause

java.lang.RuntimeException: org.bouncycastle.crypto.InvalidCipherTextException: pad block corrupted  ch.dunes.util.PasswordEncryptor.decrypt(PasswordEncryptor.java:76)  ch.dunes.util.EncryptHelper.newDecrypt(EncryptHelper.java:61)  ch.dunes.util.EncryptHelper.decrypt(EncryptHelper.java:45)  ch.dunes.util.EncryptHelper.decrypt(EncryptHelper.java:28)  ch.dunes.common.plugin.config.MSConfigurationAdaptor.validateConfiguration(MSConfigurationAdaptor.java:381)  com.vmware.vmo.plugin.ms.config.web.actions.ConfigureAction.execute(ConfigureAction.java:63)  sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)  sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)  java.lang.reflect.Method.invoke(Unknown Source)  com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:404)  com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:267)  com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:229)  com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:221)  com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)  com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)  com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:222)  com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)  com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)  com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:150)  org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:48)  com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)  com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)

[cdecanini_]

If you did not do so already try to use the workflow to add a host that is in Library / Microsoft and not the one in ASD endpoint configuration.

[pwmiller · Accepted solution]

Thanks Christophe, that complained about the "ConfigurationManager" object being missing (as per the first post in this thread). That said...

Renaming/removing the

C:\Program Files\VMware\Infrastructure\Orchestrator\app-server\conf\plugins\AD.xml and

C:\Program Files\VMware\Infrastructure\Orchestrator\app-server\server\vmo\conf\plugins\AD.xml

and re-configuring the AD plugin (1.0.3 in this case), seems to have allowed the AD connection to be re-established. At that point, we were seeing errors in the vCO client related to plug-in configuration (it looks like all of the old cruft from 1.0.4 wasn't fully cleaned up), so I upgraded the plugin from 1.0.3 to 1.0.4.

I can now browse the AD structure in vCO as expected. What a terrifying, plugin-breaking upgrade!

[igaydajiev]

The issue is fixed and will be available in next vCAC release .

More details what is causing the issue can be found in following thread vCAC 6.0.1 ASD Active Directory Endpoint