VMware Cloud Community
XModem
Enthusiast
Enthusiast

LdapAuthenticationException: Cannot login user

When ever I'm trying to run a task, it fails and tells me:

ch.dunes.login.ldap.LdapAuthenticationException: Cannot login user : CN=vCO Admin,OU=Users,OU=LocalDomain,DC=localdomain,DC=grp (reason : [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 ])

This entry is found only when looking in the server.log, there is no specific error to be seen in GUI.

Googling for the error showed me that it's basically about "invalid credentials". But I triple and quad checked (re-typed) the password for that user cited above and it works when I use it to login to vCO.

Could there be a bug, which I just happened to stumble upon?

- Jonas

Reply
0 Kudos
11 Replies
XModem
Enthusiast
Enthusiast

Small update:

The task above was generated by another workflow (as a result thereof). This seems to cause the problem with the user failing to authorize against vCO itself. It looks like I cannot correct this issue later on by manual intervention. The task is and remains invalid.

EDIT: Also with a manually created task, after it had run once (and with a problem), the credentials are discarded and can't be refreshed by editing the task and re-entering the password.

Reply
0 Kudos
ivand
VMware Employee
VMware Employee

We will look at the problem and will try to reproduce it.

I will post result later today

Thanks

Ivan

Reply
0 Kudos
XModem
Enthusiast
Enthusiast

Thanks for looking into this. I must add that this vCO 5.1 instance was configured solely to use LDAP SSL, not vCenter SSO, because SSO always gave me an undistinct "vCenter SSO server error" when trying to login with the vCO Client. Funny enough, in vCO Configuration the authorized users would authenticate successfully in the testing mask. SSO showed successful authentication if the password was correct and failure when I typed something else instead, but the vCO Client always showed authentication failure regardless.

Hence all LDAP - with that everything works fine fortunately, except now for those edited/reactivated tasks.

Reply
0 Kudos
ivand
VMware Employee
VMware Employee

I tried to reproduce the problem but I couldn't.

I scheduled manually a workflow with user that has only execute and view rights on the workflow and it works as expected.

Can you please, describe in details what exactly you are doing?

What are permissions of the user used for scheduled workflow? What LDAP provider you are using? Anything else that could help me reproduce the issue

Regards

Ivan

Reply
0 Kudos
XModem
Enthusiast
Enthusiast

The important thing is, in my case, that I did not select any execution date (NULL attribute) within the workflow generating the task, so the task is on "standby" waiting for a date and time somewhat in the future in order to execute. If you go ahead then, edit the task and select a future time, it will fail with said error.

But you should be able to repro the issue too, by simply generating a manual task and then try to re-run it, after it completed (or failed).

Another missing feature is the possibility to simply "Run" a task (e.g. scheduled in the past).

The idea is, that you can use a task in order to prepare the parameters for a workflow to reverse a procedure, e.g. to delete a certain VM again, without the need to browse and select the name within the vCenter tree. So the initial workflow creates a VM and generates the task to destroy the VM again and passes the name of the created VM, but the task - in my case - is not scheduled, so the operator simply should be able to either schedule it himself or to run it, when the VM is no longer needed.

Reply
0 Kudos
ivand
VMware Employee
VMware Employee

I tried by doing manual task and after it completes I rescheduled it. I had no issues to do that.

So i will try to schedule a task without an execution date and then to reschedule it

I am using appliance with embedded user groups

Regards

Ivan

Reply
0 Kudos
XModem
Enthusiast
Enthusiast

According to my exhaustive descriptions above, you'll have to use LDAP (SSL) authentication in order to replicate my problem. Using a different auth mechanism, might not trigger the issue.

Reply
0 Kudos
ivand
VMware Employee
VMware Employee

When I try to schedule a workflow using 'Schedule workflow' element with workflowScheduleDate 'NULL' workflow fails with :

ReferenceError: "workflowScheduleDate" is not defined.

Can you, please, post tha script that you are using to schedule a workflow?

Regards

Ivan

Reply
0 Kudos
ivand
VMware Employee
VMware Employee

Sorry I miised your last response.

I will try with LDAP SSL.

Thanks

Ivan

Reply
0 Kudos
ivand
VMware Employee
VMware Employee

I was not able to reproduce issue even with LDAP SSL.

Can you, please, attach <vco-install-folder>/app-server/server/vmo/conf/ldap.properties?

But first, please, remove any confidential information as real names of users and user groups, password and LDAP host.

Also can you attached the workflow that schedules the task?

Regards

Ivan

Reply
0 Kudos
XModem
Enthusiast
Enthusiast

Hi Ivan

Please find enclosed the requested files. I only removed the password hash from the ldap config, it’s a pure test environment, so don’t worry about names.

Note that the workflows in question use the AD Plugin, plus, the Create computer workflow creates a Task for the Destroy a computer workflow.

Greetings, Jonas

Reply
0 Kudos