Chat now with support
Chat with Support

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

Configuring Windows Remote Management (WinRM)

Previous Next

Advanced system configuration and troubleshooting : 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.
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.
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.
Windows: %WINDIR%\krb5.ini which typically translates to C:\Windows\krb5.ini
/etc/krb5.conf
/etc/krb5/krb5.conf
%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.
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.
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:
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:
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
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
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.

About the cross-realm negotiate authentication behavior

Previous Next

Advanced system configuration and troubleshooting : 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.
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.
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.
Windows: %WINDIR%\krb5.ini which typically translates to C:\Windows\krb5.ini
/etc/krb5.conf
/etc/krb5/krb5.conf
%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.
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.
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:
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:
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
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
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.

About the cross-realm negotiate authentication behavior

Previous Next

Advanced system configuration and troubleshooting : Configuring Windows Remote Management (WinRM) : About the cross-realm negotiate authentication behavior : About the cross-realm negotiate authentication behavior

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.

About WinRM authentication and the Agent Manager

Previous Next


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 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.
Related Documents