You are viewing limited content. For full access, please sign in.

Question

Question

Audit Trail - gMSA not working

asked on June 29, 2021

We've been testing out applying the group managed service accounts to the LF services in our customer's dev environment. They just tried it on the Audit Trail related services first. After changing each from the local account to the gMSA, they restarted each service. The two services indicated by the arrows produced the errors below. The other two started up just fine.

When trying to start Audit Trail Charts Component Engine:

When trying to start Audit Trail Importing Service:

 

Are we missing something here? I was under the impression that all they needed to do was install the products using the local accounts and change them to the gMSA afterwards.

0 0

Answer

SELECTED ANSWER
replied on June 29, 2021

Hi Jesse,

Those error messages in your screenshot should have corresponding Windows Event Log entries with additional details. Depending on where exactly they failed, the relevant log entries could be in the Windows Application, Windows System, or Laserfiche Audit Trail (names approximate) event channels. 

The most common reason for service start failures like what you're showing are port listener conflicts or permissions issues where the new service identity doesn't have rights to listen on the port it needs to. That's not a gMSA-specific issue and can happen with normal AD accounts as well. An easy way to sanity check that is to temporarily put the gMSA in the local Administrators group (which gives it all the port listening rights) and see if the services start. If they do, you know you have a permissions/URL ACL issue and need to pinpoint where. For a general example of how you fix that, see this Note in Laserfiche Forms Notification Setup documentation:

  1. Run the following commands in an administrator command prompt:

    netsh http add sslcert ipport=0.0.0.0:8181 certhash=#certhash appid={#appid}

    netsh http add urlacl url=https://*:8181/ user="LOCAL SERVICE" listen=yes

    Replace:

    • #appid with a random GUID.
    • LOCAL SERVICE with your local service account name.

    Note: You only need to run the second command if the service account for the Hub service is not Local System or a member of the local Administrators group on the machine.

 

With all that said, is there a particular reason you're running every service as the gMSA? We typically recommend changing the default identities of only those Laserfiche Services and IIS application pools that connect to SQL Server so you can leverage Windows Authentication (Kerberos). Changing the default identities of other services (to either a gMSA or normal AD account) is usually much more trouble than it's worth because you suddenly have to sort out all these little-but-blocking Windows permissions issues for things that Just Work with the defaults.

Do also note that if you run Workflow as a gMSA or normal AD account it must be a member of the local Administrators group on that server in order to create Scheduled Starting Rules.

Hope that helps.

Cheers,
Sam

0 0
replied on January 11, 2022 Show version history

Hi Sam,

Is it possible set up Workflow Connection Profiles using gMSAs? I've tried but had no luck. It works with Repository and LFDS accounts, of course, but the customer would like all accounts to use password managed in a password manager, or to be gMSAs. At the moment Workflow, Import Agent, Audit Trail, and Quick Fields (using Agent) are configured using LFDS (or Repo) accounts. IA, AT, and QFA (which utilise Service Accounts) for connection should work with gMSAs AOK. Workflow is my challenge!

 

-Ben 

Replies

You are not allowed to reply in this post.
You are not allowed to follow up in this post.

Sign in to reply to this post.