This article shares best practices for setting up account permissions with alternative credentials for the following products:
- GFI EndPointSecurity
- GFI EventsManager
- GFI LanGuard
GFI Software products often perform administrative level functions on remote computers. For example, agent installation, removal, maintenance, or information retrieval via SMB, RPC, or WMI. Therefore, it is necessary for the accounts used for the various processes to have administrative privileges on the remote computers.
This article describes common problems and shares best practices on setting up account permissions using alternative credentials.
The general requirement for most scenarios is that the server-side application process requires administrative privileges on the remote computer. This means that the account being used for the connection must be a local administrator on the remote computer.
About Alternative Credentials
Most GFI Software products can be configured to use an alternative user name and password. For this to work as intended, it is necessary to understand and set up the environment properly. An incorrect setup might result in errors like 'Access denied' although an account with sufficient permissions was specified. It is also necessary to be able to determine which process within an application is used when making the connection.
Microsoft Windows authentication is used when a server-side process accesses a remote computer. Microsoft Windows makes the first connection attempt via the account of the process itself. If this connection attempt fails, then Windows makes a second connection attempt using the Alternative Credentials.
However, the access fails if the first connection attempt to access the remote machine is successful, but the account does not have sufficient administrative permissions. Moreover, Windows returns an 'Access denied' message to the application. In this case, Windows does not attempt to use Alternative Credentials.
The server-side process can either be a Service or the User Interface. Depending on which action is being performed, the initial connection attempt is made by either of the following:
- The account under which the service is run.
- The user who logged into Windows and started the UI.
Single Domain Scenario
The user is using a service account that has administrative permissions on all remote computers and NOT using alternative credentials in a single domain environment.
In this setup, the application’s service is running under a domain account that has local administrative permissions on the server as well on all remote computers. In this scenario, you should avoid specifying any alternative credentials in the application at all.
Usually, a member of the Domain Administrators Active Directory group has these permissions. Alternatively, a specific account can be made a member of the local administrators' group of all computers via Group Policy.
Another alternative is to launch the application console executable using the Run as a different user option.
The user is using a local admin account and alternative credentials in a multi-domain, workgroup, or mixed environment.
When there is the need to use alternative credentials, one needs to ensure that the account of the service or the logged-in user is unable to authenticate with the first connection attempt. In this case, the authentication process can use alternative credentials to access the remote computer.
The best way to achieve this is to create a new service account on the remote machine and add this account to the local administrators' group of the GFI server. Ensure to give the user a name that does not exist on any other computer, like administrator, but use a name like 'GFIServiceAccount123'.
Use this account to run the server-side service and specify alternative credentials within the application. For example, in GFI Languard, it should be used for the scanning or remediation process.
The Microsoft Windows feature User Account Control (UAC) can interfere when using alternative credentials and needs to be disabled.