This article applies to 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 that can arise when the connect cannot be completed and best practices how to setup accounts, permissions and how to use 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.
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 setup 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, if the first connection attempt to access the remote machine is successful but the account of the process does not have sufficient administrative permissions to perform its tasks, the access fails and Windows returns an 'Access denied' message to the application and Windows does not attempt to use the 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 the account under which the service is run or the user who logged into Windows and started the UI.
- Single Domain Environment.
- Using a service account that has administrative permissions on all remote computers and NOT using alternative credentials.
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.
- Multi-domain, work group, or mixed environment.
- Using a local admin account and alternative credentials.
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 the 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 also interfere with the use of alternative credentials. It can be disabled from the registry as follows:
- Go to Start > Run > Regedit.
- Browse to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
- Create a new DWORD 32bit: LocalAccountTokenFilterPolicy and set its value to 1.