LanGuard requires administrative privileges for most of its activities, including agent installation, scanning, remediation jobs, applying patches, deploying custom software, and gathering the information via SMB, RPC, or WMI. To avoid 'Access denied' or 'Network detection; The list of servers in this workgroup is currently unavailable' errors and login failures on monitored servers the accounts used for various services need administrative privileges on the remote computers in a single domain, multi-domain, workgroup, or mixed environments.
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' or 'Network detection; The list of servers in this workgroup is currently unavailable' 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 to use alternative credentials to access the remote computer.
The best way to achieve this is to create a new service account on the GFI LanGuard server and add this account to the local administrators' group. Ensure to give the user a unique name that does not exist on any other computer, like 'GFIServiceAccount123'.
Use this account to run the LanGuard services and specify alternative credentials for all the scanning and remediation operations.
Run a manual scan with or without alternative credentials (depending on the scenario above) and verify that it completes successfully.