How can Audit Trail show a 9010 error from Workflow without it being logged as an activity error?

asked on March 11, 2021 • Show version history

9010 means invalid username or password.

Workflow Current Error Logs are clean, which would show a login failure from an activity normally.

Yet Audit Trail shows many 9010 errors happening all day long for the user configured for Workflow Repository connections from User agent Laserfiche Workflow LFRA.

Laserfiche Workflow LFRA is the Laserfiche Workflow Service right? That service would only ever attempt a login to the repository if it was running a repository based activity (IE: Find Entry). If that activity could not login, it would fail and post to the log files.

No activity errors since 3/8

Constant Logs showing failures from LFRA

0 0

replied on March 11, 2021

We pull that date from Windows and it's not always accurate. The better way to check if the Subscriber is happy is the repository tab in the Subscriber Trace. If the Subscriber can't currently connect to the repository, there should be a yellow warning sign in the top section of the repository tab with the error message.

0 0

View 3 previous replies

replied on March 11, 2021

Oh the subscriber is good. These events are from a workflow repository connection, configured in the workflows. The user account is a specific account used by that connection.

0 0

replied on March 12, 2021

Oh, sorry, I don't know why I read that as a Subscriber problem.

Yes, "Laserfiche Workflow" is the server. Did you open the logs or are you only going by the modified date?

The stack trace for the error in log should have the name of the workflow rule.

0 0

replied on March 12, 2021

I opened the logs and I am looking at the workflow search history. Given that they do not even have workflows which run every second of every day and there is a failed login attempt every second of every day, how is this possible? Why is Audit Trail showing so many failed login attempts by the Workflow engine that we have never configured?

It seems to me, the only time workflow should be logging into the repository with this custom user account they created, is when they specified it should do so.

There is no real logic in any of this. The login attempts started immediately after updating the server to version 11 and before we even finished upgrade WF to version 11.

0 0

replied on March 12, 2021

What do you mean " the Workflow engine that we have never configured"?

Workflow makes connections as needed and there's more than just starting workflows. So it is possible that it can attempt connections in the currently running instances.

That said, an upgrade makes no changes to the passwords. So something else changed the password and made the connection profile invalid.

Is this your only Workflow Server? Were there any errors in the logs?

It's probably best that you open a support case so we can take a closer look at both WF logs and audit logs.

0 0

replied on March 12, 2021

I just mean that they do not have it configured to be running activities every second of every day, yet there are failed login attempts from the service that often.

There are no errors in Workflow showing it could not connect to the repository.

I don't think audit trail is showing accurate data. If there was a failed login, it would be logged.

0 0

replied on March 12, 2021

It's not impossible though. It would depend on your workflow design. You could have a For Each Entry that iterates over a large entry set and calls Find Entry on each one. If you put it in a Try Catch, it might not report the error at all, but still fail at every iteration.

But again, an upgrade wouldn't break the password. If it started while Workflow was still on the previous version, then it is more indication that somebody actually changed the password.

0 0

Question

Question

How can Audit Trail show a 9010 error from Workflow without it being logged as an activity error?

Replies

Sign in to reply to this post.