Phone Lines icon GFI Support Home

Articles in this section

See more

Verifying Required Network Connectivity and Security Permissions for GFI LanGuard Operations

Author: Andriy Rybalchenko Updated

Overview

LanGuard operations require certain network settings and security permissions to be configured.

 

Connectivity check failures can result in the following commonly reported scenarios:

  • Access denied errors in scans, remediation jobs, and agent deployments.
  • Computers showing up as offline when they are actually connected and online.
  • Network path not found messages in remediation jobs.
  • Remediation jobs and agent deployments stuck in the pending state.
  • Agent scans or updates not initiating.

Diagnosis

The following tests should be performed using the same account which is running the GFI LanGuard 12 Attendant service, which is typically the domain admin account in single-domain environments. This account is also referred to as the “currently logged on user” in LanGuard. In single-domain environments, it is used to connect to all computers in LanGuard with administrative rights.

 

In multi-domain environments, in the last two tests, use the account used to make the connection with the test target depending on its location in the network. This is typically what you define in “alternative credentials” in the computer’s properties in LanGuard.

 

See Best Practices for Setting up Account Permissions with Alternative Credentials for more details. Once the account is validated, perform the following tests:

Solution

Please validate the following permissions:

Ping the computer

Confirm that you can successfully ping the computer via the hostname as well as the fully qualified domain name. Ensure that the correct IP address is being pinged. This is a hard requirement.

Resolve the computer using the hostname and IP address

NSLookup is a command prompt utility that finds Name Server information by querying the Domain Name System (DNS).

Use the NSLookup to:

  • Verify forward DNS lookup with the following command: 
    nslookup hostname.domain.local
    replacing hostname.domain.local with the fully qualified domain name of the test computer. This should return the fully qualified domain name and IP address of the target.
  • Verify reverse DNS lookup with the following command: 
    nslookup 192.1.1.10
    replacing 192.1.1.10 with the computer's IP address. This should also return the same fully qualified domain name and IP address as with the forward lookup test.

Sample output below:

C:\Windows\system32>nslookup win-rc7ij0vjjc8.my.testdomain.local
Server:  WIN-5N129UP46AT.Win10TestDomain.local
Address:  192.168.1.54
Name:    win-rc7ij0vjjc8.my.testdomain.local
Address:  192.168.1.83

C:\Windows\system32>nslookup 192.168.1.83
Server:  WIN-5N129UP46AT.Win10TestDomain.local
Address:  192.168.1.54
Name:    win-rc7ij0vjjc8.my.testdomain.local
Address:  192.168.1.83

Additional notes for this test

  • This test may not be valid when the target is a non-domain joined computer, also known as a WORKGROUP computer. You would typically not place such computers in the domain’s DNS server. However, you still need to successfully resolve the hostname in some way. One such solution is using the C:\Windows\System32\drivers\etc\hosts file on the LanGuard server to bind the hostnames and IP address of the target together. For more details, refer to Setting up a Workgroup Computer for LanGuard Operations
  • If reverse lookup does not work, the connectivity may still succeed. However, if the reverse lookup points to a wrong host, you must correct this discrepancy in the DNS server’s reverse lookup zone. It is strongly recommended to have consistent forward and reverse lookups configured in the DNS server for optimal operations.

top

Check for Remote Service Access

Run services.msc and attempt to connect to the target machine.

If you get an access denied error, try adding the credentials manually:

  • Open Credential Manager on the LanGuard server (Control Panel -> User Accounts -> Credential Manager).
  • Click on "Add a Windows credential".
  • Enter the network address (e.g., SERVER2012.MY.TESTDOMAIN.LOCAL), username, and password.
  • After adding the credentials, try accessing the Services management console again.

Before:

After:

Remember to switch back to Local computer after the test.

 

Using PowerShell on the LanGuard server, use the following command to enter the username used to connect to the machine in the DOMAIN\ACCOUNT format:

 $cred = get-Credential -credential DOMAIN\username

You will be prompted for the password; provide it.

Then check the services of the target using the hostname/IP using:

 Get-WMIObject Win32_Service -computer 192.168.1.83 -credential $cred

where you must replace 192.168.1.83 with the IP/hostname of the target you are checking the connectivity with. The screenshot below shows a case with Access denied as well as a success. In this case, the nonadmin account in the MY domain does not have the permissions to access the services and hence, cannot be used in LanGuard unless it is granted sufficient permissions. admind2 passes the check.

top

Connect via Remote Registry

Using the Remote Registry service, LanGuard can query the registry of a target computer remotely to pull important data such as the OS build and installed patches. Check if you can manually query the registry of a computer from the LanGuard server successfully:

  1. Ensure the Remote Registry service is started and set to Automatic startup on the target computer.
  2. Log on to GFI LanGuard server using an account with administrative access.
  3. Open the LanGuard server’s registry (regedit.exe).
  4. Go to File > Connect Network Registry.
  5. Enter the IP Address of the target machine and click on OK.
  6. Once connected, a new hive will appear for the target machine. Ensure you can browse to the following path: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog

top

Access the C$ Administrative Share

Administrative shares are the default network shares created by the Windows OS. LanGuard uses administrative shares such as C$ to obtain and store information on connected computers. Verify that LanGuard can access the C$ share and write to it:

  1. Ensure File and Print sharing is enabled on the target computer.
  2. Ensure that the default administrative C$ share has been created.
  3. Log on the LanGuard server using an account with administrative access.
  4. Go to Start > Run and type the following command: 
    \\hostname\C$
    Replace hostname with the target computer name.
  5. You may be prompted for credentials, especially if it is a computer in a different domain or a WORKGROUP computer. In this case, authenticate using the same account that you would specify in LanGuard.
  6. A File Explorer window should pop up, showing the contents of the C drive on the target computer.
  7. Browse to Windows > System32
  8. Create a text file called test.txt.
  9. After confirming that the file is created, you can delete it.

top

View the Event Log Remotely

Some monitoring checks in LanGuard retrieve information from the Windows event logs remotely from the target computer. The following test will ensure that the LanGuard server has access to this information:

  1. Log on the LanGuard server using an account with administrative access.
  2. Go to Start > Run and type the following command: eventvwr
  3. Click Action and select Connect to another computer.
  4. Enter the fully qualified domain name of the target computer (or simply the hostname if it is a WORKGROUP computer) in the Another Computer text box.
  5. Check the Connect as another user checkbox and click the Set user button on the right.
  6. In the window that pops up, specify the same credentials that LanGuard will use to authenticate with the target.
  7. Click OK.
  8. Ensure you can view each of the Windows event logs of the target computer.

top

Query via WMI (Windows Management Instrumentation)

LanGuard queries connected computers via WMI to obtain several key details, especially during scans. Below are two tests to verify that the LanGuard server can run WMI queries on the target computer:

Test 1

  1. Type the following in an elevated command prompt window: 
    wmic /node:192.1.1.10 /user:domain\user cpu get loadpercentage
    Be sure to replace 192.1.1.10 with the target computer’s IP address, domain with the NetBIOS domain name, and user with the account’s logon name. Use the same account that LanGuard will use to authenticate with the target.
  2. You will be prompted for the account’s password. This will be masked the moment you start typing it.
  3. If the query is successful, it returns the CPU usage on the target as logged by the WMI service.
    Example output below: 
    C:\Windows\system32>wmic /node:192.168.1.83 /user:my\admind2 cpu get loadpercentage
    Enter the password :************

    LoadPercentage
    1

Test 2

  1. Log in to the LanGuard server using the credentials you are attempting with the check/scan.
  2. Go to Start > Run and run mmc.
  3. Go to File > Add / Remove Snap-in and select WMI Control from the Available snap-ins
  4. Click Add.
  5. Choose Another Computer in the window that pops up and enter the IP Address of the target computer.
  6. Click Finish and close the Add/Remove Snap-in Dialogue box by clicking OK.
  7. Expand WMI Control node under Console Root.
  8. Right-click on the WMI Control node and go to Properties.
  9. You should see a window pop up that shows a message that says 
    Successfully Connected to : \\192.1.1.10
    in the General tab, where you will see the computer’s IP address instead of 192.1.1.10. This tab will also show you other details such as the Processor and OS.

top

Related Articles

Was this article helpful?
2 out of 4 found this helpful

Related articles