VMware Log Insight 4.0 and a slow login with the domain user credentials

Recently I was spinning up one more instance of VMware Log Insight 4.0 appliance in a branch office.

After enabling authentication against Active Directory, I have noticed it was relatively slow to log on to the Log Insight web interface. Moreover, when I pointed the Authentication Configuration to the local domain controllers the connection test was always failing.


I did not have enough time to troubleshoot this issue. So I decided to continue with this task later on.

Few days after the situation became even worth: domain users could not successfully log on to the appliance with the rolling wheel appears when pressing the login button.


Fortunately, I am not the first customer who came across of this issue. VMware has published an article “Unable to Log In Using Active Directory Credentials” which helps to locate the cause of this behaviour.

As suggested by the vendor, I looked through the records in the /storage/var/loginsight/runtime.log file and have found the following:

[com.vmware.loginsight.aaa.krb5.KrbAuthenticator] [Attempting Kerberos login: [[ user=XXXXX ], [ domain=XXXXX ]]]

[com.vmware.loginsight.aaa.krb5.KrbAuthenticator] [Kerberos login in 270817ms]

jsonResult: {“result”:”Cannot reach kerberos servers through TCP.“}

suggestion Please verify that your firewall settings allow TCP ports for active directory and kerberos.

Here I need to say that Active Directory has the hub-and-spoke topology with the domain controllers in the local and central sites being available to the clients.

By default, Log Insight could be pointed to the specific domain controllers, but not Kerberos servers. As a result, the Kerberos client uses auto-discovery as a mechanism to contact any server listed in the _ldap._tcp.dc._msdcs.[domain_name] namespace and delays with reaching ones that are available. To illustrate this, you can execute the following command from the Log Insight CLI:

~# netstat -A inet –program | egrep -i “kerberos”

It should show you all active UDP sessions which were initiated by the Kerberos client.

The next step is to find the way to narrow down a list of the domain controllers to those which are available to the client. VMware helps us with this task providing “advanced options for Active Directory integration in Log Insight beyond what is available in the administrative user interface.

The problem can be resolved with the following steps:

  1. Open https://loginsight_hostname_or_ipaddress/internal/config web-page.
  2. Add krb-domain-servers option with the appropriate values for the available domain controllers to the advanced configuration and save those changes.
  3. Restart Log Insight server.

After all those changes completed, you should be able to log on quickly to Log Insight with the domain account:

[com.vmware.loginsight.aaa.krb5.KrbAuthenticator] [Attempting Kerberos login: [[ user=XXXXX ], [ domain=XXXXX ]]]

[com.vmware.loginsight.aaa.krb5.KrbAuthenticator] [Kerberos login in 22ms]

03/03/2017 – Update 1: With the release of vRealize Log Insigh 4.3 the issue has been resolved. Please see the release notes for more details.


vCenter Support Assistant 6.5: This type of network adapter is not supported by {0}Other Linux (64-bit)

VMware has just released a new version of vCenter Support Assistant 6.5 which officially supports vSphere 6.5 and has a few noticeable improvements comparing to the previous release.

In this appliance, SUSE Linux has been replaced with Photon OS. The shift looks quite logical, as VMware pushes their own Linux flavour to more and more new products. Not only is it help to maintain a holistic approach when distributing virtual appliances, but it also promises an improved performance of the operating system, as VMware heavily invested into making it lightweight and fast.

However, when I completed provisioning vSA 6.5 in my environment and checked the virtual machine settings; to my surprise, it was a warning message shown in the screenshot below.


It is not problematic to understand a root cause of this issue and eliminate it completely.To keep backwards compatibility with previous versions of vCenter Server, the VM hardware was set to version 8 (ESXi 5.0 and later).

To keep backwards compatibility with earlier versions of vCenter Server, the VM hardware was set to version 8 (ESXi 5.0 and later).


This choice of the OS is entirely unexpected, as ‘Other Linux (64-bit)‘ was classified as a Legacy operating system by the vendor.


It is until the VM hardware version 10 when it is possible to change the guest operating system to ‘Other 3.x or later Linux (64-bit)‘ to resolve the problem. So the workaround would be upgrading the VM to at least hardware version 10, and then chose the compatible OS type.

My suggestion to VMware would be to introduce a new Guest OS version called ‘Linux / Photon OS’ with the compatible hardware profile to prevent similar warnings in the future.