Page Comparison

In Support, and in ProServProfessional Services, best practice is to manually set most of our services to use the SSAdministrator account so that permissions are directly assigned without passing through a medium. Most of these services should be set properly to the SSAdministrator user during installation, but often times due to permissions issues, some of these services do not get set.

...

There are, however, some services that we do not typically assign the SSAdministrator privilege explicitly. Often times services such as GAGlobalAction\GC GlobalCapture are left to run as Local System as well as MongoDB.  From a Windows perspective, these services will use restricted local account with some system privileges. These are listed in the services.msc console as “Local System”.

However, when the API is being called by said service, the account called to run that account is referenced through the AdminAuthenticationSettings.xml in C:\GetSmart.  This account is set by Service Console – often times the domain SSAdministrator. (This is why it’s often a good idea to run service console in the event that GA/GC that GlobalAction\GlobalCapture is running strangely. This will solidify the relationship of the service account and the service itself.)

...

This is crucial to the proper functioning of services like Global Action. If, for example, a user is secured and can create and modify GA initiator services BUT the service account referenced in the square9webauth.dll cannot see said search (IE – is not secured) that service will not function correctly.

Things to be aware of:

GA GlobalAction and GC GlobalCapture can both run comfortably as Local System and as a secured user – we typically run this service in whatever way is most stable

If GlobalCapture is using UNC paths to 'hot folder', the service cannot run as LocalSystem. The GlobalCapture service needs to run as a user with permission to access those folders. 

You can tell if Service Console has set the credentials correctly by checking the last-modified date of the AdminAuthenticationSettings.xml in your Getsmart directory

Services will require a restart for new authentication credentials to take effect

...

...