ESXi lwsmd Service Crashes with Error: "Cloning Thread During Cross Forest Trust Lookups"
search cancel

ESXi lwsmd Service Crashes with Error: "Cloning Thread During Cross Forest Trust Lookups"

book

Article ID: 448138

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

  • ESXi hosts experience severe outbound network flooding, high-volume DNS query storms, and Connectionless LDAP (CLDAP) connection timeouts immediately following a domain join or cluster rejoin sequence to the primary Domain Controller (DC) domain path.
  • The embedded Likewise Open identity agent daemon (lwsmd) exhausts its allocated thread pool infrastructure, generating critical failures inside the system logging stack.

/var/run/log/syslog.log:

<Time_Stamp> Er(27) lwsmd[####189]: [netlogon] Timed out after waiting for 5 seconds while performing CLDAP pings
<Time_Stamp> Er(27) lwsmd[####189]: [netlogon] CLDAP timed out: <DC_HOSTNAME.trusted forest tree domain 1>
<Time_Stamp> Er(27) lwsmd[####189]: [netlogon] CLDAP timed out: <DC_HOSTNAME.trusted forest tree domain 2>
<Time_Stamp> Er(27) lwsmd[####189]: [netlogon] Timed out after waiting for 5 seconds while performing CLDAP pings
lwsmd: Error cloning thread: -12 (bad0014)

  • Inter-process socket communication path breakdown occurs during thread starvation conditions, preventing the invocation of administrative actions via the terminal:

[root@<HOSTNAME>:~] /usr/lib/vmware/likewise/bin/lwregshell
lwregshell (error = 40700 - LWREG_ERROR_NO_SUCH_KEY_OR_VALUE)
No such key or value

Environment

VMware vSphere ESXi

Cause

This is an expected behavior of identity agent in adherence to universal cross-platform industry and IETF standards. 

The identity agent initializes automatic background topology sweeps to find, index, and evaluate alternative authentication paths across all trusted forest trees learned from the root domain. 

When perimeter firewalls drop this outbound UDP port 389 discovery traffic rather than explicitly rejecting it, the agent enters an aggressive sub-second background retry loop. 

Because the directory provider cache type operates within volatile process memory, unfulfilled connection paths quickly pool inside the process heap, leading to total thread exhaustion and subsequent daemon collapse.

Resolution

To resolve the issue follow one of the below options.

Option 1:

Open Perimeter Security Firewalls (Recommended):

  • Configure network access controls to permit unidirectional outbound traffic from the ESXi host management interfaces to all external domain controllers across the following mandatory ports:
  • If the management layer is frozen or the utility returns error 40700, clear the unmapped process sockets from the ESXi shell prior to configuration:

kill -9 $(pgrep lwregd)
kill -9 $(pgrep lsassd)

Note: The above commands might report no process to kill, if the "lwregd" and "lsassd" services are already crashed. Hence, the below command can be directly run to restart the service.

/etc/init.d/lwsmd start

  • The below ports need to be opened:
    • Port 88 (TCP/UDP)
    • Port 123 (UDP)
    • Port 135 (TCP)
    • Port 137 (UDP)
    • Port 139 (TCP)
    • Port 389 (TCP/UDP)
    • Port 445 (TCP)
    • Port 464 (TCP/UDP)
    • Port 3268 (TCP)

Option 2:

Host Isolation and Trust Exclusion (Local Workaround):

  • Modify the active Likewise directory services database registry keys to bypass cross-forest trust evaluation structures entirely:
  • Access the interactive database engine:
    • /usr/lib/vmware/likewise/bin/lwregshell
  • Navigate to the directory provider node and disable global trust enumeration:

cd HKEY_THIS_MACHINE\Services\lsass\Parameters\Providers\ActiveDirectory
set_value "DomainManagerIgnoreAllTrusts" 1
quit

Note: To explicitly filter specific unroutable domains instead of a global block, utilize the multi-string variable array option: set_value "DomainManagerExcludeTrustsList" "trusted forest tree domain 1" "trusted forest tree domain 2"

  • Push the schema adjustments to the active runtime and cycle the subsystem daemon to flush volatile memory caches:

/usr/lib/vmware/likewise/bin/lwsm refresh lsass
/etc/init.d/lwsmd restart

Additional Information

For more information on the issue, refer the below articles: