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.
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.
• |
Stop the wmiprvse.exe process. |
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 About WinRM connection ports.This section provides solutions for the following issues:
The steps involved in Kerberos authentication involve the following actions:
1 |
Initial Authentication for a Kerberos Session (Kerberos step 1) |
2 |
Subsequent Kerberos Authentications (Kerberos step 2) |
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.
• |
• |
UNIX: |
• |
/etc/krb5.conf |
• |
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. |
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.
NOTE: If current OS user have permission to modify krb5.config file, FglAM will automatically specify domain name as the kdc in the file if the kdc entry is not found when making Kerberos authentication. |
The Kerberos configuration file typically looks like:
• |
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 |
2 |
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 |
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
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.
• |
kdc_timeout: This parameter sets the maximum number of milliseconds to wait for a reply from a KDC, the default value is 30000 milliseconds. |
• |
max_retries: This parameter sets the maximum number of times each KDC will be tried, the default value is 3. |
• |
Decrease the parameter values of max_retries and kdc_timeout in krb5 file. For example, max_retries=1 and kdc_timeout=10000. |
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center