GFI LanGuard has to perform administrative level functions on remote computers for many of its activities, including agent deployment, scanning, remediation jobs, applying patches, and gathering the information via SMB, RPC, or WMI, etc. In order to avoid 'Access denied' errors is necessary for the accounts used for various services 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 LanGuard 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.
In order to achieve this GFI LanGuard can be configured to use an alternative user name and password. For this to work as intended, it is necessary to understand the environment properly and configure everything accordingly. 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 service/process is used when making the connection.
When a server-side process accesses a remote computer Microsoft Windows authentication is used. 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.
Note: However, everything 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 and 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.
Below are the solutions for the Single Domain and Multi-Domain/Mixed Scenarios.
Single Domain Scenario
In a single domain environment, the recommended setup is using a service account that has administrative permissions on all remote computers and NOT using alternative credentials. In this setup, LanGuard services are running under a domain account that has local administrative permissions on the server as well on all remote computers.
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.
Note: Follow the above guidelines and avoid specifying any alternative credentials at all.
In a multi-domain, workgroup, or mixed environment the recommended setup is using a local admin account and alternative credentials.
When using alternative credentials, 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 will be able use alternative credentials to access the remote computer.
The best way to achieve this is to create a new service account on the remote machines and add this account to the local administrators' group of the GFI LanGuard server. Ensure to give the user a name that does not exist on any other computer, like 'GFIServiceAccount123'.
Use this account to run the LanGuard services and specify alternative credentials for scanning and remediations.
Note: The Microsoft Windows feature User Account Control (UAC) can interfere when using alternative credentials and needs to be disabled.
Run a manual scan with or without alternative credentials (depending on the scenario above) and verify that it completes successfully.