立即与支持人员聊天
与支持团队交流

Foglight Agent Manager 5.8.5.2 - 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

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.
To allow the agent to connect locally on Windows®:
1
Enable the Remote Registry Service.
Once the agent has successfully connected and the Agent Manager connection services have made the required changes, the Remote Registry Service can be disabled.
2
Ensure that the Server service is running.
 
* 
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.
To release a locked MySQL process:
•
Stop the wmiprvse.exe process.
 
* 
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.

Generating a Configuration File Required for WinRM Negotiate Authentication

WinRM connections using the default Negotiate authentication require a copy of the krb5.config file. On Windows®, the Agent Manager attempts to auto-generate this file and places it under <fglam_home>f/state/default/config/krb5.config. Under some circumstances, the Agent Manager is unable to auto-generate the file on Windows, in which case the file needs to be created. On UNIX® systems, the file is never auto-generated and must always be provided.
If the file needs to be created, the format of the krb5.config file for the WinRM Negotiate authentication is as follows:
[libdefaults]
default_realm = <dns_suffix_upper_case>
[realms]
<dns_suffix_upper_case> = {
kdc = <DNS_Server_for_dns_suffix_upper_case>
}
[domain_realm]
.<dns_suffix_lower_case> = <dns_suffix_upper_case>
Where:
The values dns_suffix_upper_case, dns_suffix_lower_case, and DNS_Server_for_dns_suffix_upper_case must be replaced with their actual values.
The [domain_realm] section in the file maps the domain of the host being connected to, to a realm.
The [realm] section provides the relevant kdc (key distribution center) server with a specific realm to use for kerberos authentication. This is generally the DNS server for the relevant domain.
The default_realm value in the libdefaults section is the realm mapping to use when the domain of the host cannot be matched to a realm.
For example, for connecting to hosts on the sample.domain.com domain with the dnsserver.sample.domain.com DNS Server, the contents of the krb5.config file should be as follows:
[libdefaults]
default_realm = SAMPLE.DOMAIN.COM
[realms]
SAMPLE.DOMAIN.COM = {
kdc = DNSSERVER.SAMPLE.DOMAIN.COM
}
[domain_realm]
.sample.domain.com = SAMPLE.DOMAIN.COM
When connecting to a host1.sample.domain.com, the host1’s domain is mapped to the SAMPLE.DOMAIN.COM realm, which maps to the DNSSERVER.SAMPLE.DOMAIN.COM kdc to use for kerberos authentication.
After creating the krb5.config file is created the absolute path to the generated krb5.config file should be provided in the <config:krb5-config-file> tag value of the <fglam_home>/state/default/config/fglam-config.xml file, so that it can be accessed by the Agent Manager. Any changes to the fglam-config.xml file require the Agent Manager to be restarted in order for those changes to take effect. Therefore, if the Agent Manager is running while you are making these changes, you must restart it.

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:
•
Negotiate authentication is based on Kerberos authentication, involving tickets/keys obtained from a Key Distribution Center (KDC).
•
Basic authentication uses standard HTTP headers to communicate directly with the remote machine.
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 Available WinRM Connection Schemes when the Agent Manager Runs on AIX.
Understanding Negotiate/Kerberos Authentication
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:
1
Initial Authentication for a Kerberos Session (Kerberos step 1)
a
A client begins a Kerberos session by requesting a ticket-granting-ticket (TGT) from the KDC based on the domain user name. This is done automatically on Windows login, but can be repeated when a different KDC is needed for a service on a different realm.
b
The KDC creates a TGT and sends it back to the client, in encrypted form, based on the client's password. The client decrypts the TGT using the client's password.
c
In possession of a valid TGT, the client can request tickets for various services.
2
Subsequent Kerberos Authentications (Kerberos step 2)
a
When the client requires access to a service using Kerberos authentication, the client requests a ticket for the particular service, from the KDC by sending the TGT as proof of identity.
b
The KDC sends the ticket for the specific service to the client.
c
The client can then send this ticket to the remote server to establish a session with the server's service.
Finding the Kerberos Authentication File
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.
Observing the Contents of the Kerberos Configuration File
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:
•
Windows: %WINDIR%\krb5.ini which typically translates to C:\Windows\krb5.ini
•
UNIX:
•
/etc/krb5.conf
Or:
•
/etc/krb5/krb5.conf
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, so on Unix, the file is not generated. On Unix platforms, you need to create your own Kerberos configuration files to establish WinRM connections using Negotiate authentication.
To detect the settings on Windows, the following environment variables are checked:
•
%LOGONSERVER%: Provides the name of the domain controller that authenticated the client's logon to the machine. This value is just the simple name of the KDC, but the fully qualified name must be used in the configuration file.
•
%USERDNSDOMAIN%: Provides the fully qualified DNS domain that the currently logged on user's account belongs to.
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 file is not 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:
[libdefaults]
default_realm = <REALM_NAME_IN_CAPS>
 
[realms]
<REALM_NAME_IN_CAPS> = {
kdc = <fully_qualified_kdc_name>
}
[domain_realm]
.<domain_in_lower_case> = <REALM_NAME_IN_CAPS>
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:
<config:krb5-config-file>C:\Quest_Software\fms_6_2_0_206\state\fglam\state\default\.\config\krb5.config</config:krb5-config-file>
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.
About the Kerberos Configuration File Format
The Kerberos configuration file typically looks like:
# Copyright 2015 Dell Inc.
# ALL RIGHTS RESERVED.
[libdefaults]
default_realm = EXAMPLE.COM
 
[realms]
EXAMPLE.COM = {
kdc = HOST1.EXAMPLE.COM
}
 
[domain_realm]
.example.com = EXAMPLE.COM
•
Any line that begins with a number sign '#' is considered a comment, and is ignored.
•
The default_realm value is used to determine what KDC should be used, if the realm cannot be determined from the domain.
•
The [realms] section is used to provide the KDC for the specified realm
•
The [domain_realm] section is used to map the domain to the realm to use.
So for example, if connecting to a host A with user credential example.com\UserX, the kerberos file is used as follows:
1
The domain is determined from the user credential, so in this case the domain name is example.com.
2
The domain example.com maps to the realm EXAMPLE.COM in the domain_realm section.
3
The realm EXAMPLE.COM is then found, and its KDC value is used to determine the KDC to use for authentication.
4
The KDC, HOST1.EXAMPLE.COM, is then communicated with for authentication.
In another example, if connecting to a host B with user credential other.domain\UserY, the same Kerberos file is used as follows:
1
The domain is determined from the user credential, so in this case the domain name is other.domain.
2
The domain other.domain does not map to any realm in the domain_realm section, so the KDC is attempted to be resolved from the DNS.
3
Typically, the DNS does not find the KDC for the different domain, and so the default_realm value, EXAMPLE.COM is used instead.
4
The realm EXAMPLE.COM is then found, and its KDC value is used to determine the KDC to use for authentication.
5
The KDC, HOST1.EXAMPLE.COM, is then communicated with for authentication of the user credential.
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
# Copyright 2015 Dell Inc.
# ALL RIGHTS RESERVED.
[libdefaults]
default_realm = EXAMPLE.COM
 
[realms]
PROD.QUEST.CORP = {
kdc = HOST1.EXAMPLE.COM
}
OTHER.DOMAIN = {
kdc = MYKDC.OTHER.DOMAIN
}
 
[domain_realm]
.example.com = EXAMPLE.COM
.other.domain = OTHER.DOMAIN
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 document was helpful.

选择评级

I easily found the information I needed.

选择评级