Repository Profile No Longer Authenticating

asked on January 29 • Show version history

We have a Forms environment that has been using an Active Directory account to save forms into Laserfiche successfully for years. This server is publicly facing but has both the IIS site and routing service on the same server. The customer has blocked NTLM traffic between servers (both internal and external). This change stopped the Desktop Client and Windows Client from authenticating and we had to move both to LFDS authentication. While their Forms is not authenticating via LFDS, it is still allowing users to log in and submit/approve forms without issue. However their submitted Forms are suspending when they attempt to save to the repository.

When I attempt to update the profile used by the task, I receive a "Failed to verify the repository: The user account name or password is incorrect. [9010]" error.

Does Forms use NTLM when authenticating with the Laserfiche server when it is saving them into the repository via the service task?
If so, how can we set them up to use LFDS for authentication or is there a different method we should be using when saving documents into Laserfiche?
Has anyone ran into something similar and have a work-around or different idea of what may be causing this if NTLM is not the issue?

For now I have created a Laserfiche repository account and it is successfully saving using that but I do not want a local Laserfiche repository account as the long-term solution.

0 0

replied on February 2 • Show version history

Re: "If so, how can we set them up to use LFDS for authentication or is there a different method we should be using when saving documents into Laserfiche?"

I never use AD accounts for Save to Repository service task profiles. Instead, create a repository or Directory Server "Laserfiche" user to act as a Forms service account. I usually name the account "Forms", or sometimes a variant like "Forms-Dev" or "Forms-$RepoName" if relevant. This account doesn't need a named user license - Forms provides a special license-free connection for repository connections just like Workflow. Grant the account the minimum repository permissions it needs to create documents, write metadata, etc.

Set up a System-level Repository Profile for each repo with that account (or accounts) and migrate all processes to using them. See: Getting Started with Repository Profiles

Done. No Windows Authentication/Kerberos/NTLM complications.

Re: "but I do not want a local Laserfiche repository account as the long-term solution."

Why? Using a repository or Directory Server Laserfiche account is my preferred and default permanent setup.

2 0

replied on February 3

We can definitely use the local accounts. Back in the day when we had to use repository accounts, you had to have a license associated with the repository account for it to save to Laserfiche. I didn't know that whatever account is associated with the save to Laserfiche service task will get a "free" full license like Workflow. That solves that issue and removes the NTLM issue. Thanks!

2 0

replied on February 4

The same is also true of Import Agent, Email Archive, and Audit Trail repository connections. All provide an automatic license-free repository connection. My standard practice is to create a repository account for each of those applications (plus Forms and Workflow) and grant each the minimum required permissions for its role.

For Workflow, strongly prefer using repository account(s) over a Directory Server "Laserfiche" account. Workflow performs many more repository logins (orders of magnitude, typically) and repository account logins are much faster than Directory Server logins as Repository Server can quickly and directly handle them. Especially for small, frequent workflows, the additional authentication overhead from Directory Server logins can end up being a significant portion of overall instance runtime. Repository accounts avoid that. It's like 50ms vs 500ms, but that can really add up across tens of thousands of activities.

1 0

Question

Question

Repository Profile No Longer Authenticating

Replies

Sign in to reply to this post.