Foglight Agent Manager 5.8.5.2


	NOTE: The fglam.config.xml file specifies the location of the krb5.conf file in the <kerberos‑config‑file> element. If the element is empty or omitted, no configuration file is used.

You can manually override the location of krb5.conf with the following command-line parameter:

-Djava.security.krb5.conf=</path/to/file>

Configuring Kerberos on a Windows Host

Additional registry keys may be required when you deploy an Agent Manager on a Windows host. The Agent Manager installer attempts to make the changes automatically. If the Agent Manager is unable to establish a WinRM connection, check that the following changes were made correctly.

•

In Windows Vista and later versions, User Account Control (UAC) affects access to the WinRM service. When the Negotiate authentication scheme is used in a workgroup only, the built-in Administrator account can access the service.

To allow all accounts in the Administrators group to access the service, set the value of the following registry key to one ‘1’:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

•

By default, Windows does not allow JavaTM to access certain required session keys when JavaTM attempts to authenticate with Kerberos. The following registry keys should be added to ensure that the required sessions keys are available. The Agent Manager attempts to detect and update these registry keys automatically the first time a WinRM connection is attempted.

Windows 2003, Windows Vista, and later:

•

Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

•

Value Name: allowtgtsessionkey

•

Value Type: REG_DWORD

•

Value: 0x01

Windows XP and Windows 2000:

•

Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos

•

Value Name: allowtgtsessionkey

•

Value Type: REG_DWORD

•

Value: 0x01

Configuring Kerberos During Runtime

The KerberosConfigurationService API provides the ability for agents to modify or create a Kerberos configuration file during runtime.

The Agent Manager uses the Kerberos configuration file to establish WinRM Negotiate connections to hosts. In most cases, the Agent Manager can create the Kerberos configuration for the current domain to which the machine running the Agent Manager belongs. However, the Kerberos configuration typically needs to be modified when cross-domain WinRM connections are required. This can be done by modifying the Kerberos configuration file manually, to add the new domain properties, and restarting the Agent Manager. If no instance of the previous Kerberos configuration file is found, the fglam.config.xml file needs to be updated to instruct the Agent Manger which Kerberos configuration file to use for WinRM connections.

All of these actions can also be performed during runtime, without requiring any manual changes, or an Agent Manager restart. The KerberosConfigurationService allows agents to make these changes during runtime and have the changes take effect immediately. If a new configuration file is created, fglam.config.xml file is updated automatically.

For complete information about this service, see the Foglight Agent Manager Devkit and Javadoc documentation.

Configuring the Command-Shell Connection Settings

WinRM relies on a set of configuration parameters that establish the level of system resources the WinRM service needs to address incoming requests. In certain cases, some parameter values do not provide sufficient configuration levels which can lead to run-time errors.

Depending on how WinRM is used, some parameter values may not provide sufficient configuration levels which can lead to connection issues. The Agent Manager makes an attempt to diagnose some of these situations and communicate appropriate recommendations using Warning messages. The configuration levels that the Agent Manager attempts to diagnose are:

•

MaxConcurrentOperationsPerUser: This parameter specifies the maximum number of concurrent Enumeration operations allowed by an individual user. The value must be in the range of 1 to 4294967295.

This parameter is only available for WinRM version 2.0 and later. In version 1.1, the MaxConcurrentOperations parameter is used instead.

To increase the value assigned to this parameter, issue the following command:

winrm set winrm/config/service @{MaxConcurrentOperationsPerUser="<number>"}


	TIP: WinRM parameters can also be edited using the Group Policy Object Editor. To start the editor, type gpedit.msc at the command line, and then navigate to Local Computer Policy > Computer Configuration > Administrative templates > Windows Components > Windows Remote Management (WinRM) and Windows Remote Shell.

Figure 3. Windows Components in the Local Group Policy Editor

•

MaxConcurrentOperations: This parameter specifies the maximum number of concurrent shells any user can remotely open on the same system. Any number from 1 to 4294967295 can be used. For more information about this parameter, you can visit the following Web page: http://msdn.microsoft.com/en-us/library/cc251426.aspx.

This parameter is only available for WinRM version 1.1. It is deprecated for version 2.0 and later, and MaxConcurrentOperationsPerUser is used instead.

To increase the value assigned to this parameter, issue the following command:

winrm set winrm/config/service @{MaxConcurrentOperations="<number>"}

•

MaxShellsPerUser: This parameter specifies the maximum number of concurrent shells any user can remotely open on the same system. Any number from 0 to 2147483647 can be used, where 0 means unlimited number of shells. If this policy setting is enabled, the user cannot to open new remote shells if the count exceeds the specified limit.

To increase the value assigned to this parameter, issue the following command:

winrm set winrm/config/winrs @{MaxShellsPerUser="<number>"}

•

AllowRemoteShellAccess: This parameter controls access to the remote shell. It must be set to true.

To set this parameter to true, issue the following command:

winrm set winrm/config/winrs @{AllowRemoteShellAccess="true"}

For additional information, visit the following Web page:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384372%28v=vs.85%29.aspx

Available WinRM Connection Schemes when the Agent Manager Runs on AIX

When the Agent Manager monitoring a Windows® machine runs on an AIX® system, WinRM connections only work for the Basic authentication scheme. Attempting to use the Negotiate scheme does not result in a WinRM connection being established.

About WinRM Connection Ports

WinRM uses a set of default ports for communication. Depending on the WinRM version, the following port numbers are used:

•

WinRM 1.1 and earlier: The default HTTP port is 80, and the default HTTPS port is 443.

•

WinRM 2.0 and later: The default HTTP port is 5985, and the default HTTPS port is 5986.

After issuing the winrm quickconfig command, the listener port number can be determined using the winrm enum winrm/config/listener command. For example:

> winrm enum winrm/config/listener

Listener

Address = *

Transport = <HTTP|HTTPS>

CertificateThumbprint

ListeningOn = <ip_addresses>