Server for NIS using too many Ephemeral ports

  • Article

The Server for NIS initiates recursive LDAP queries on AD and in some environments, where the ports do not close quickly enough, it can create problems like TCP port Exhaustion .

When a client initiates a TCP/IP socket connection to a server, the client typically connects to a specific port on the server and requests that the server responds to the client over an ephemeral, or short lived, TCP or UDP port. On Windows Server 2003 and Windows XP the default range of ephemeral ports used by client applications is from 1025 through 5000. Under certain conditions it is possible that the available ports in the default range will be exhausted

Why is NIS sending LDAP requests?

The server for NIS (or nissvc) stores user names, accounts, “UNIX attributes” etc in AD. However, any requests made to this service are handling via an image of the AD data, a cache, called the ‘Mapcache’ (located in the %windir%\idmu\nis folder). Thus, if a client issues an ypcat request, then NIS simply reads this information from the cache and sends it, without touching AD.

The NIS server should only be generating LDAP traffic under the following two circumstances:

a. When the server starts and the local Mapcache is being generated.

b. When changes to AD causes NIS to update the Mapcache.

Based on my experiences the following changes take care of the scenario. We are trying to make sufficient number of ports available through these.

· Locate the MaxUserPort value under the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Change the value of MaxUserPort value to 65534

· Locate the TcpTimedWaitDelay value under the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Change value of TcpTimedWaitDelay to 60

BTW, The default setting for the TcpTimedWaitDelay value is 240 (Decimal), which equals four minutes. The TcpTimedWaitDelay value determines the length of time that a connection stays in the TIME_WAIT state before it is closed.