Pre-requisites for Monitoring Components in an Agentless Manner

When deploying a remote agent, it is essential to ensure that the remote agent can communicate using multiple agentless mechanisms (see Figure 1) with the target environment (appropriate firewall rules must be configured for this purpose).

The sub-sections below describe the pre-requisites that need to be fulfilled to enable agentless monitoring of different types of applications. 

General Pre-requisites

  1. At least one remote agent should be available for performing agentless monitoring. By default, the eG agent on the eG manager host serves as both a remote agent and external agent for the environment. If required, you can configure more remote agents. For this purpose, you can follow the procedure detailed in Section 7.8.3 of this document.
  2. If you intend to use SNMP for monitoring a component in an agentless manner, then make sure that the SNMP port 161 is opened on the target component.

Pre-requisites for Monitoring a Windows System/Application in an Agentless Manner

For monitoring a Microsoft Windows environment in an agentless manner, the following requirements should be fulfilled:

  1. The udp ports 137 and 138 and the tcp ports 139 and 445 should be opened on the target Windows sytem to enable the remote agent to communicate with that system.

  2. Ideally, the remote agent should be installed and running with the permissions of a domain administrator. To ensure this, do the following before starting a remote agent:

    • Open the Component Serviceswindow (using the menu sequence, Settings -> Control Panel -> Administrative Tools -> Component Services) of the remote agent host. Right-click on the eGurkhaAgentservice listed therein, and select Propertiesfrom the shortcut menu.

      agentlogonas1

      Figure 1 : Selecting properties from the eGurkhaAgent service’s shortcut menu

    • Select the LogOn tab from the Properties dialog box that appears. Then, choose the This account option from the Log on as section of, and provide the Domainname\Username of the domain administrator in the adjacent text box. Provide the Password of the domain administrator, and confirm the password by retyping it in the Confirm Password text box.

      agentlogonas

      Figure 2 : Changing the Log On account

    • Finally, click the Apply button in and then the ok button to register the changes.
    • Hence, typically, at least one remote agent is necessary for each independent domain being monitored.

    In high security environments, administrators may not prefer to have the eGurkhaAgent service run with domain administrator privileges. In such environments, administrators can configure the eGurkhaAgent service to run using the credentials of a user who has rights to login to every Windows system in the domain or at least to those systems that are to be monitored. Note that in this case the user account should be Allowed to logon locally. To enable a user to logon locally, follow the steps below:

    • Login to the Domain Controller.
    • Double-click on the domain to which a user should be allowed to logon locally, in the Domains forest.
    • Right-click on the Default Domain Controllers Policy, and then select Edit from the right-click menu.
    • In the console tree, expand Computer Configuration, Policies, Windows Settings, Security Settings, and Local Policies, and then click User Rights Assignment.

    Note:

    The above-mentioned steps are applicable only if the remote agent and the target Windows host are in the same domain. However, if the remote agent is within a domain, but the target host operates out of the domain or within a workgroup, then perform the following broad steps to ensure that the remote agent monitors the host:

    • Create a new user on the target host and assign local administrator privileges to that user.
    • Create a new user on the remote agent’s host with the same credentials as the user created on the monitored host; assign local administrator privileges to this user also.
    • Ensure that the remote agent runs with the permissions of this new user.

    The detailed steps in this regard are available in Chapter 7 of this document - i.e., the chapter on Troubleshooting.

  3. Ensure that the target Windows system consists of the default share named admin$. If this share does not exist on a target, then the remote agent will not be able to connect to that system or collect metrics from it. To check whether admin$ pre-exists, do the following:

    • Login to the target system and go to the command prompt.
    • Type the command net share; this command will list all the default and user-configured shares on the system
    • If admin$ is not listed, it is a definite indicator that the system does not consist of the admin$ share.

    The way forward is to manually configure the admin$ share on the target system. To do so, issue the command net share admin$ from the command prompt of the system. This will create the admin$ share. For more information on net share, check out the URL:

    http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/net_share.mspx?mfr=true

  4. Also, the remote agent connects to the Windows host to be monitored using NetBIOS - a protocol that allows applications on different computers to communicate within a local area network. If NetBIOS is not enabled on a Windows host, then eG Enterprise cannot monitor that host in an agentless manner.

    To enable NetBIOS on a Windows 2000 host, follow the steps given below:

    • Follow the menu sequence: Start -> Programs -> Accessories -> Communications -> Network and Dial-up Connections

    • Figure 3 will then appear. Right-click on the Local Area Connection and then select Properties from the shortcut menu.

      netbios3-final

      Figure 3 : Selecting the Properties option of the Local Area Connection option

    • Figure 4 that appears next displays the properties of the Local Area Connection. Double-click on the Internet Protocol (TCP/IP) option indicated by Figure 4 to view its properties.

      netbios4-final

      Figure 4 : The General tab of the Properties dialog box

    • Click on the Advanced button within the General tab of the Properties dialog that appears next.

      netbios5-final

      Figure 5 : Properties of the Internet Protocol (TCP/IP)

    • Click on the wins tab of the Advanced TCP/IP Settings dialog box, and select the Enable NetBIOS over TCP/IP option within. Finally, click the ok button therein to register the changes.

      netbios6-final

      Figure 6 : Enabling NetBIOS

    To enable NetBIOS on a Windows 2003 host, follow the steps given below:

    • Follow the menu sequence: Start -> Programs -> Accessories -> Communications -> Network Connections
    • Right-click on the Local Area Connection option and select Properties.
    • Then, double-click on the Internet Protocol (TCP/IP) under the "This connection uses the following items:" list box.
    • Click on the Advanced button within the General tab of the Properties dialog box that appears next.
    • Click on the wins tab of the Advanced TCP/IP Settings dialog box, and select the Enable NetBIOS over TCP/IP option within. Finally, click the ok button therein to register the changes.

    To enable NetBIOS on a Windows XP host, follow the steps given below:

    • Follow the menu sequence: Start -> All Programs -> Accessories -> Communications -> Network Connections
    • Right-click on the Local Area Connection option and select Properties.
    • Then, double-click on the Internet Protocol (TCP/IP) under the "This connection uses the following items:" list box.
    • Click on the Advanced button within the General tab of the Properties dialog box that appears next.
    • Click on the wins tab of the Advanced TCP/IP Settings dialog box, and select the Enable NetBIOS over TCP/IP option within. Finally, click the ok button therein to register the changes.

    To enable NetBIOS on a Windows 7 system, follow the steps given below:

    • Click Start and then click Network.
    • Click on the Network and Sharing Center.
    • Click Manage Network Connections.
    • Right-click on the Local Area Connection and select Properties.
    • Select Internet Protocol version 4 (TCP/IPv4).
    • Click the Advanced button under the General tab page.
    • Click the wins tab page.
    • Click Enable NetBIOS over TCP/IP.
    • Click ok and Exit the settings.
  5. Additionally, to remotely monitor a Windows 7 host in particular, you need to start the Remote registry service.

  6. By default, remote Windows systems/applications are monitored using Perfmon. To ensure that the remote agent is able to collect metrics from the target Windows systems using Perfmon, the following pre-erquisites should be additionally fulfilled:

    • PerfMon should have at least READ access to the Perflib\LanguageID subkey on the remote computer (which allows external access to PerfMon). The Perflib\LanguageID subkey is located in the following Registry path: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Perflib\LanguageID. The LanguageID is a numeric code for the spoken language of the installed operating system. A computer with a LanguageID of 009 (the English LanguageID) has the following Perflib\Language subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Perflib\009
    • The Disk Performance Statistics Driver (diskperf) should exist on the target computer; allow READ access explicitly to the user account for the following registry key and all subkeys: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Diskperf

    • The monitored computer should be able to connect to IPC$. The following registry entry enables connecting to IPC$:

      • Hive: HKEY_LOCAL_MACHINE\SYSTEM
      • Key: CurrentControlSet\Services\LanmanServer\Parameters
      • Name: AutoShareWks
      • Type: REG_DWORD
      • Value: 1
    • At least READ access should be granted to the following registry subkey (allowing it to remotely connect to the Windows registry): HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg. This permission determines who can remotely connect to a registry. If this subkey does not exist, all users can remotely connect to the registry. To remotely connect to a registry, a user must have at least READ access to the winreg subkey on the target computer.

    • At least READ access should be granted to the following registry keys on the remote computer:

      • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg
      • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Perflib

    • To monitor Windows 2000 and Windows XP, the user name must have access granted by the following group policies:

      • Profile single process
      • Profile system performance

      Both group policies are security settings that you can set from the Local Policies => User Rights option in the Administrative Tools of the Control Panel.

    • To monitor Windows XP, if the system root is on an NTFS partition, the user name must have at least READ access to the following two files:

      • %SystemRoot%\System32\Perfc009.dat
      • %SystemRoot%\System32\Perfh009.dat

Pre-requisites for Monitoring a Unix System/Application in an Agentless Manner

For monitoring Unix systems/applications in an agentless manner, ensure that the pre-requisites outlined below are fulfilled:

  1. By default, the remote agent communicates with a target Unix system via Rexec. In this case, make sure that port 512 is opened on the target to enable this communication. If SSH is the mode of communication between the remote agent and target system, then make sure that port 22 is opened on the target.
  2. If you want the remote agent to connect to a target host via Rexec, then make sure that the rexecd daemon on the target host is started. This daemon provides the server function for the rexec command. To check the status of this daemon, open the /etc/inetd.conf file on the target host and look for the rexecd line in it. If this line is uncommented, it indicates that the daemon has been started. If the line is commented, then it indicates that the daemon has not been started. In this case, uncomment the line, save the inetd.conf file, and then run the refresh -s inetd command or the kill -1 InetdPID command to inform the inetd daemon of the changes to its configuration.

  3. If you want the remote agent to communicate with a target host via SSH, then you should also pick an encryption type/mode for the SSH connection. The options here are: Password authentication and Key-based authentication.

    If you want the SSH connection to use the Password Authentication mode, then, first make sure that Password Authentication is enabled on the target host. For this, follow the steps below:

    • Login to the Unix host to be monitored.
    • Edit the sshd_config file in the /etc/ssh directory.
    • Check whether the Password Authentication flag in the sshd_config file is set to no. If so, set it to yes.
    • Then, save the file and restart/signal the SSH daemon (eg., using kill -1 <sshd pid>)

    If you want the SSH connection to use the Key-based Authentication mode instead, then first make sure that Key-based authentication is enabled on the target host. For this purpose, you will require a public/private key pair. A public/private key pair is available in the /opt/egurkha/agent/sshkeys/ directory of the eG agent. While the private key is available in the file named id_rsa, the public key is contained within the file authorized_keys. The pass phrase associated with the default private key is eginnovations. You now have the option to proceed with the default keys or generate a different key pair.

    If you decide to go with the keys bundled with the eG agent, do the following:

    • To enable key-based authentication, the private key should remain in the /opt/egurkha/agent/sshkeys/ directory of the eG agent, and the public key should be copied to the remote Unix host to be monitored. To achieve this, first login to the Unix host to be monitored as the eG user.
    • Create a directory named .ssh in the <USER_HOME_DIR> on the host using the command: mkdir ~/.ssh.
    • Next, copy the authorized_keys file from the /opt/egurkha/agent/sshkeys/ directory on the eG agent host to the <USER_HOME_DIR>/.ssh directory on the Unix host. Make sure that the permission of the .ssh directory and the authorized_keys file is 700.

    On the other hand, if you want to generate a new key pair, then do the following:

    • Login to the Unix host to be monitored as an eG user.

    • From the <USER_HOME_DIR>, execute the command: ssh-keygen -t rsa. Upon executing the command, you will be requested to specify the full path to the file to which the key is to be saved. By default, a directory named .ssh will be created in the <USER_HOME_DIR>, to which the key pair will be saved. To go with the default location, simply press Enter.

      Generating public/private rsa key pair.
      Enter file in which to save the key (/home/egurkha/.ssh/id_rsa):

    • Next, you will be prompted to provide a pass phrase. Provide any pass phrase of your choice.

      Enter passphrase (empty for no passphrase): eginnovations
      Enter same passphrase again: eginnovations

    • If the key pair is created successfully, then the following messages will appear:

      Your identification has been saved in /home/egurkha/.ssh/id_rsa.
      Your public key has been saved in /home/egurkha/.ssh/id_rsa.pub.
      The key fingerprint is:
      09:f4:02:3f:7d:00:4a:b4:6d:b9:2f:c1:cb:cf:0e:e1 dclements@sde4.freshwater.com

    • The messages indicate that the private key has been saved to a file named id_rsa in the <USER_HOME_DIR>/.ssh, and the public key has been saved to a file named id_rsa.pub in the same directory. Now, rename the id_rsa.pub file as authorized_keys.
    • Then, to enable key-based authentication, login to the eG agent host.
    • Copy the id_rsa file from the <USER_HOME_DIR>/.ssh directory of the target Unix host to the <EG_INSTALL_DIR>\agent\sshkeys directory on the eG agent host.

    • Finally, log into target Unix host once again (as the eG user) and lock the file permissions down to prevent other users from being able to read the key pair data, using the following commands:

      chmod go-w ~/

      chmod 700 ~/.ssh

      chmod go-rwx ~/.ssh/*