Chatta subito con l'assistenza
Chat con il supporto

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

About the cross-realm negotiate authentication behavior

Cross-realm or cross-domain is the mechanism of using WinRM Negotiate authentication to establish a connection to a machine in a different domain. There are also some differences here between behavior when the Agent Manager uses Java 6 and Java 7.

Enable DNS reverse lookup

DNS reverse lookup is the querying technique of the Domain Name System (DNS) to determine the domain name associated with an IP address – the reverse of the usual “forward” DNS lookup of an IP address from a domain name. The process of reverse resolving of an IP address uses PTR records.

The Enable DNS Reverse Lookup switch is under Dashboards > Administration > Agents > Agent Properties > FglAM > FglAMadapter.

The Basic authentication mechanism simply provides HTTP headers to the remote machine, to provide the credentials that should be used for authentication. There is no use of a configuration file or a KDC. The mechanism provides no protection for the transmitted credentials, since they are simply encoded in base64 and not encrypted or hashed. To address any security concerns, it is recommended that Basic authentication attempts are made over an HTTPS and not HTTP connection. Since the KDC is not involved in the authentication process, the credentials used for Basic authentication must be local user credentials, such as local user credentials for the remote machine, and not domain user credentials.

When the remote machine is contacted, the remote machine responds indicating that Basic authentication needs to be used by the client. The client side then base64-encodes the user name and password and sends an HTTP request with an HTTP header containing the base64-encoded result to the remote machine, which then validates the provided credential.

Since local user credentials are used, and a KDC is not needed, the domain the host is on is irrelevant for Basic authentication.

About WinRM authentication and the Agent Manager

The Agent Manager supports Basic and Negotiate WinRM authentication schemes with Windows credentials. The Negotiate authentication scheme is enabled by default in WinRM and is the recommended way to authenticate in most environments.

In order to establish connections over Windows® Remote Management (WinRM), you must provide a Windows credential. For more information, see Configuring credentials.

The Negotiate authentication scheme requires fully-qualified domain accounts. For example, instead of using the NetBIOS domain, the Windows credential should be configured with the fully qualified domain.

The Basic authentication scheme requires local Administrator accounts; you cannot use domain accounts. For more information, see Promoting remote users to administrators on local machines through the Domain Controller. Basic authentication is insecure because it transmits user names and passwords in an easily decoded string, and therefore it should not be used on an untrusted network. If Basic authentication is required, and security is a concern, configure the target system to accept only HTTPS traffic. For more information, see Manually configuring WinRM HTTPS access. If Basic authentication is not acceptable in your environment because of some specific security concerns, it can always be disabled.

Basic and Negotiate authentication schemes are not mutually exclusive when it comes to their configuration. The remote system can be enabled to use both authentication schemes, given a specific order of preference. For example, a remote machine can be configured to first attempt the Negotiate authentication, and it fails, to subsequently try the Basic authentication. Therefore, if you enable Basic authentication, there is no need to disable Negotiate authentication requests, and the other way around. However, you can disable either scheme, as required.

In general, if Basic authentication is not suitable, it should be disabled. If both Negotiate and Basic authentication are enabled, and Negotiate fails, Basic authentication is still attempted, and the credentials are transmitted in an easily decoded string. Because of different credential requirements for Negotiate (a domain user credential) and Basic (a local administrator credential), a credential only applies to one authentication type. Therefore a general recommendation is that if Basic authentication is required, Negotiate authentication does not have to be disabled. But if Negotiate authentication is needed, best practice is to disable Basic authentication requests.

You can also use Windows Group Policy Objects to automatically configure HTTP or HTTPS listeners in WinRM. For more information, see Using Group Policy Objects to configure WinRM.

You can also use the Enable WinRM authentication based on only Basic or Negotiate type switch in the FglAMAdapter Properties view to decide which WinRM authentication scheme will be used.

False: Negotiate authentication scheme will be attempted at first. If Negotiate fails, then Basic authentication will be attempted.
True: Either Negotiate or Basic scheme will be attempted, depending on the type of user credentials:

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.

The default WinRM settings allow only Negotiate authentication.

3
Optional. If Negotiate authentication is enabled, and you want to disable it, type the following:

winrm set winrm/config/service/auth @{<Basic|Negotiate>="<true|false>"}

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.

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.

@{Hostname="<host>";CertificateThumbrint="<thumbprint>"}
host is a fully qualified host name, as it appears in the certificate.
thumbprint is the certificate thumbprint, with spaces removed.

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.

2
Type run and press Enter.
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.

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.

fglam --add-certificate alias=/path/to/saved.ca.certificate
Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione