Foglight Agent Manager 5.9.8 - Foglight Agent Manager Guide

Enabling agents to connect locally on Windows

When a WMI agent connects to the same machine it is running on (that is, localhost) using credentials that explicitly specify a user other than the currently logged on user, you must make certain registry changes to allow the required COM services to run.

IMPORTANT: Normally, the Server service starts automatically. If it is stopped, or fails to start, it must be manually restarted before the Agent Manager can connect locally using credentials for a user other than the currently logged on user.

Releasing a locked MySQL process

The Agent Manager uses the wmiprvse.exe process to make use of WMI for remote Windows® monitoring. However, in some situations, this process can lock the MySQL process, mysqld.exe, preventing it from being uninstalled, deleted, moved, or updated.

IMPORTANT: Stopping the wmiprvse.exe process does not affect the running state of the WMI service. The process starts again automatically when an application requires WMI.

Configuring Windows Remote Management (WinRM)

Windows Remote Management is the Microsoft® implementation of the Web Services Management Protocol (WSMAN) which is a Simple Object Access Protocol (SOAP) based protocol over HTTP/HTTPS and is used for system management. For more information, visit https://msdn.microsoft.com/en-us/library/aa384470%28v=vs.85%29.aspx.

WinRM has two authentication mechanisms that are used by the Agent Manager to establish connections:

When the Agent Manager is installed on AIX, Negotiate authentication is not currently supported. In such cases, only Basic authentication can be used. For more information, see About WinRM connection ports.This section provides solutions for the following issues:

WinRM IPv6 connection support

Starting with the Foglight Agent Manager version 5.9.1, the WinRM connection with unique local IPv6 Address and link-local IPv6 Address is supported on the Agent Manager running on Windows, Linux, and Solaris.

Kerberos is a network security protocol that involves three elements: the KDC, the client user, and the server with the desired service to access. The KDC is installed as part of the Domain Controller and acts as the authentication service and the ticket-granting service.

Each administrative domain has its own KDC, which contains information about the users and services for that particular domain. This administrative domain is a Kerberos realm.

The steps involved in Kerberos authentication involve the following actions:

Foglight Agent Manager always generates an auth.login.config file that is used for Kerberos. It is generated by the Agent Manager on both UNIX® and Windows®, and is used to configure the Kerberos module that the Agent Manager uses for authentication. This file is located in the <fglam_dir>/state/default/config directory, and must never be modified.

The Kerberos configuration file specifies the KDC from which tickets are obtained. Operating systems sometimes have their own Kerberos configuration files. If present, the Agent Manager uses them by default. They can be found in the following locations:

If none of these files are found, the Agent Manager attempts to create its own kerberos configuration file, based on the detected settings. The detection can only be done on Windows, and on Unix, the empty file is generated.

To detect the settings on Windows, the following environment variables are checked:

These two environment variables are only present when the user credential used to login to the machine, is a domain credential, for example, when the user account belongs to the domain. If a local user account is used, these environment variables are not present, and an attempt to generate the Kerberos configuration file is made using the network information. If not found, the empty file is generated.

If you are running the Agent Manager on a UNIX machine, to determine the values to use in the Kerberos configuration file for the remote machine, simply log in to the remote machine using a domain user credential and check the values. The format of the file is as follows:

If the Kerberos configuration file is generated by the Agent Manager, it is placed in the <fglam_dir>/state/default/config/krb5.config file, and an entry is added to the <fglam_dir>/state/default/config/fglam.config.xml file so that the Agent Manager is aware of the file location. An example of this entry on Windows is as follows:

If the file is not generated, you can generate your own file, add a value for the krb5-config-file entry in the fglam.config.xml file, and restart the Agent Manager.

NOTE: If current OS user have permission to modify krb5.config file, FglAM will automatically specify domain name as the kdc in the file if the kdc entry is not found when making Kerberos authentication.

The Kerberos configuration file typically looks like:

So for example, if connecting to a host A with user credential example.com\UserX, the kerberos file is used as follows:

In another example, if connecting to a host B with user credential other.domain\UserY, the same Kerberos file is used as follows:

To specify a non-default realm to use for the other.domain value is the second example, the Kerberos configuration file can be modified as follows

Now, if a domain of other.domain is encountered, the realm used will be OTHER.DOMAIN instead of the default_realm value since there is a domain mapping entry. This can be repeated for other domains and realms.

This is the reason that fully qualified domain names be used for the domain value of the credential. Also, to prevent any possible DNS issues with the KDC, the fully qualified name of the host should be used, such as A.example.com or B.other.domain.

There are other sections and properties that can be used in the Kerberos configuration file, but for the Agent Manager purposes, the ones described above are sufficient.

The Kerberos configuration file supports specifying multiple KDC entries in one realm, which enables the WinRM connections to try to obtain the tickets from one of these KDCs, in order to prevent the single point of failure. The multiple KDC entries configuration typically looks like:

Each KDC listed in the same realm will be tried up to <max_retries> times and each time will wait for up to <kdc_timeout> milliseconds until one succeeds.

To fix this issue, follow the instructions to achieve that total timeout number for KDC listed in the same realm does not exceed the timeout limit set by WinRM connection: