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 oftentimes due to permissions issues, some of these services do not get set.

Image RemovedImage Added

There are, however, some services that we do not typically assign the SSAdministrator privilege explicitly. Often times  Oftentimes services such as GA\GC GlobalAction/GlobalCapture are left to run as Local System as well as MongoDB.  From From a Windows perspective, these services will use the credentials of the user logged into the computera 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 square9webauthentication.dll – the referenced account is the account AdminAuthenticationSettings.xml in C:\GetSmart.  This account is set by Service Console – often times oftentimes the domain SSAdministrator. (This is why it’s often a good idea to run service console Service Console in the event that GAthat GlobalAction/GC GlobalCapture is running strangely. This will solidify the relationship of between the service account and the service itself.)

...

Service Console can be found in v4.1 and up and is located in the Getsmart GetSmart Directory

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.

...

...

...

...

...

...