Issues with Server for NIS

Recently, we faced couple of issues with Server for NIS. The environment looks like:

2 Windows 2008 R2 as DC and HP UNIX as NIS client. The issue which the customer was facing was as below:

· First issue: Users were unable to login from Unix clients using AD credentials

· Second issue: Windows DC were appearing as Unix under the NIS servers (IDMU console)

For the first issue, we configured one of the HP Unix as a NIS client so that it binds to Windows DC (NIS master). The configured the password Sync properties.

· Check whether Password sync is installed on all the windows 2008 R2 DC's. Password Sync is a component of IDMU

· Click on Password Sync - Properties -settings and change the default encryption key for password sync on the windows box DC.

· Also checked whether the option “Windows to UNIX” is checked or not

· Also check the port Number. It should be 6677

· Click on Password Sync - Properties - Configuration tab and checked the option“ Enable “

· Also check "Enable extensive login"

· Restarted Server for NIS

This resolved the first issue. We created a new user and reset his password. From the HP UNIX client we were able to login using the AD credentials.

For the second issue, an attribute "Gecos: NIS Server" of 2nd NIS server was not set automatically.

IDMU snap-in checks this attribute to include the name of the domain controller in the list of Windows NIS servers in the snap-in. As it cannot find the desired value in the attribute, the name of the domain controller does not appear in the IDMU snap-in.

The reason for this as below:

“The gecos attribute is set by “niscnfg.exe” (located in %windir%\idmu\setup), which is called by the NIS service (nissvc) at startup. But niscnfg is called only if nissvc thinks that the “configuration” is not already set up. In case of peer DCs, when NIS is installed on the first machine, this AD container “ypserv30” is populated and copied to the other Peer DCs, because it is a common object across the domain. Thus, when NIS is installed on the second machine, the container ypserv30 is already updated, and therefore niscnfg will not run.

Niscnfg.exe cannot be called every single time ‘Server for NIS’ is started, because that would be unnecessarily cumbersome. Also, because of the code design, it is not possible to set the gecos value directly from nissvc.

We populated the gecos entry for the DC, did a schema update and restarted “Server for NIS” service. There is a support document also which talks about a similar situatation.

https://support.microsoft.com/kb/971900 

This resolved the second issue and we were able to see the 2nd Windows DC in IDMU snap in.