Chat now with support
Chat mit Support

Foglight Agent Manager 5.8.1 - Guide

Configuring the Embedded Agent Manager Installing External Agent Managers
Understanding How the Agent Manager Communicates with the Management Server Deploying the Agent Manager Cartridge Downloading the Agent Manager Installer Installing the Agent Manager Starting or Stopping the Agent Manager Process Frequently Asked Questions
Configuring the Agent Manager Advanced System Configuration and Troubleshooting
Configuring Windows Management Instrumentation (WMI) Configuring Windows Remote Management (WinRM) UNIX- and Linux-Specific Configuration
Monitoring the Agent Manager Performance Deploying the Agent Manager to Large-Scale Environments

Configuring the Target (Monitored) System

Recent versions of Windows® OS include WinRM, but it is disabled by default. There are two ways to configure HTTP or HTTPS: manually or using Group Policy Objects.
Manually Configuring WinRM HTTP Access
To manually configure the target machine for WinRM authentication:
1
Open a command prompt window on the target machine.
2
Type the following:
winrm quickconfig
This enables the default WinRM configuration and disables payload-level encryption.
 
* 
IMPORTANT: Payload-level encryption encrypts only the contents of the messages that are exchanged between the Agent Manager and the monitored system. It does not affect the security of any credentials passed between the target system and the Agent Manager. If you require full encryption, configure the WinRM server to use HTTPS. HTTPS safely and securely encrypts all data transmitted between the Agent Manager and the monitored system.
The default WinRM settings allow only negotiate authentication.
To enable Basic authentication:
1
Open a command prompt window on the target machine.
2
Type the following:
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Negotiate="false"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
Manually configuring WinRM HTTPS access
If additional security is required, for example if data is transferred across untrusted networks, you can configure WinRM to use HTTPS. A valid server authentication certificate must be installed on the target machine in order to enable HTTPS.
 
* 
NOTE: You cannot use self-signed certificates.
The certificate must be granted by a recognized certificate-granting authority (CA) in order for the Agent Manager to authenticate it. Otherwise you must install the root CA certificate in the Agent Manager’s trusted keystore, as described in Installing HTTPS certificates.
 
* 
TIP: Install the certificates in the following location:Certificates (Local computer)/Personal/Certificates
To enable HTTPS access:
1
Open a command prompt window on the target machine.
2
Issue the following commands:
winrm quickconfig -transport:https
Using Group Policy Objects to configure WinRM
You can use Windows Group Policy Objects to automatically configure HTTP or HTTPS listeners in WinRM. Enable or disable the appropriate default group policies that are pre-installed with Windows, or use the defaults as a template to develop new policies.
To view the default policies:
1
On the target machine, click Start.
2
Type run and press Enter.
3
In the Run dialog box that appears, type mmc and click OK.
4
The Console Root window appears.
5
In the Console Root window, choose File > Add/Remove Snap-In.
6
In the Add or Remove Snap-ins dialog box that appears, in the Available snap-ins area, select Group Policy Object, and click Add.
7
In the Select Group Policy Object dialog box that appears, click Finish to close it.
8
Click OK to close the Add or Remove Snap-ins dialog box.
9
In the Console Root window, in the navigation tree on the left, choose Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service.
10
Review the settings on the right. Double-click a setting to edit its state.
11
After you have edited the settings as necessary for your environment, close the Console Root window.
Installing HTTPS certificates
In environments where an in-house certificate granting authority (CA) is in use, the CA’s certificate must be added to the Agent Manager’s trust keystore. The Agent Manager then assumes that the authority, and any signed certificates it issues, are trusted.
To add a certificate to the keystore:
1
Ensure that the Agent Manager is running.
2
Launch a command shell on the Agent Manager machine, and navigate to the <fglam_home>/bin directory.
3
Issue the following command:
fglam --add-certificate alias=/path/to/saved.ca.certificate
If the import succeeds, the Agent Manager automatically recognizes and uses the certificate.

Configuring the Agent Manager (Monitoring) System

The Agent Manager automatically attempts to perform the necessary configuration on the monitoring host machine. If for any reason the changes cannot be made, you have to manually update the following settings.
Configuring Kerberos
The WinRM negotiate authentication scheme uses Kerberos. By default, the Agent Manager searches the following files for information about the location of the Key Distribution Center (KDC):
•
%WINDIR%/krb5.ini
•
/etc/krb5.conf
•
/etc/krb5/krb5.conf
If the Agent Manager fails to find a configuration file, it attempts to automatically detect the required settings and writes them to $FGLAM/state/default/config/krb5.conf.
 
* 
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 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.
Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen