Linux vs NetBSD NIS passwords

[KC9UDX]

Does anyone know how to get Linux (Debian, Manjaro, etc.) to cooperate with a NetBSD NIS server?

The only thing that doesn't work is user passwords.  Linux clients recognise NIS users but will not authenticate them.  I do not have this problem with NetBSD or Solaris clients.  Nobody else seems to run into this.

[Gribouille]

Does anyone know how to get Linux (Debian, Manjaro, etc.) to cooperate with a NetBSD NIS server?

The only thing that doesn't work is user passwords.  Linux clients recognise NIS users but will not authenticate them.  I do not have this problem with NetBSD or Solaris clients.  Nobody else seems to run into this.

Hello,

Have you check on the servers (primary and secondary) the security options  :

• 'securenets' to have the address of you subnetwork to serve ?
  
• 'Makefile' with 'MINUID' and 'MINGID' because you could have some users with UID or GID below this values that block the authentication ?
  
• in the 'Makefile', that the 'passwd' map is really exported (I'm suppose 'yes' ) ?
  

On the Linux client, check :

• '/etc/yp.conf' where the domain must be present and the NIS servers declared using the Ip address NO the 'hostname'. With the 'hostname', it could work, but it's very dependent of the network, the client's configuration, etc., believe me : use the Ip address;
  
• '/etc/ypserv.conf' that never I have modified;
  
• '/etc/ypserv.securenets'  that never I have modified;
  
• '/etc/idmapd.conf' that must contain something like 'Domain = <your domain's name>', without that there is no authentication.
  

After, try to use only the master NIS server and a Linux client, shutdown the secondary NIS server. Restart the service on the both systems. Look at the logs, 'dmesg' outputs. I've used Sun Solaris NIS server and SUN Solaris and Linux clients with success.

I hope that could help because, it's the most common troubles.

[KC9UDX]

Thank you for replying. I don't have an opportunity to verify everything at the moment. But I can add this:
The server has a GENERIC kernel, i386, 9.2.
There is only a primary server at the moment (for months). The only secondary server is being rebuilt and won't be done soon.
All UIDs for NIS users are in the range 1000..1099
The password map is really exported; I have had Solaris and NetBSD clients using it with no issue. Currently there is only 3 NetBSD clients and 8 Linux clients. The NetBSD clients work without a hitch. The Linux ones (OSMC, Debian, Raspbian, and Manjaro) work for hosts. I can verify that all maps work on NetBSD, but I'll have to see again exactly what ypcat reveals in Linux.
The Linux clients (none of the clients actually) have no LAN hostnames in /etc/hosts.
The Linux clients were configured in the minimum way as recommended in the Debian instructions. (Can't say exactly what that is at the moment).

I will have to double-check the Linux configuration again.

There are no indications of errors in dmesg or elsewhere, except maybe ypcat.

[KC9UDX]

Alright. I had a chance to try something.

ypcat passwd gives the exact same results on a Debian client as a NetBSD client.
id test gives the same results as well:
uid=1004(test) gid=100(users) groups=100(users)
But I cannot log in as 'test'. The password authentication fails.

By the way, the configuration on the Debian machine seems to be okay.

[Gribouille]

The main control is to check '/etc/nsswitch.conf', verify that you have something like : 'passwd:          files nis systemd'.

In this situation, all tests must be done in 'console' mode to debug, not with a window manager - you can stop the window manager.

About the 'homedir', local to the Linux (Debian) machine or NFS ? If it's NFS, verify the rights to the homedir.

What's happen if on the Linux machine you are logged as 'root' and make 'su - test' ? An other test, use an other local account, as 'root' and make 'su - <the other account>', and after 'su - test'. If you haven't restricted the root's rights, this a good way to check the password.
During this, in your a console (I use 'tmux' in this case), make some 'tail -F /var/log/< ...>' to find where the password could be rejected. 
Some files to observe in '/var/log' : auth.log, kern.log


Update : I suppose that your are working on the same domain name. If you have 'host_one' and 'host_two', the corresponding FQDN is 'host_one.your_domain' and 'host_two.your_domain'. I don't know how works the NIS service if the machines are not in the same domain name.

[KC9UDX]

1) I think it's "passwd: files nis" I might be missing systemd
2) Everything is done "remotely" over telnet or ssh for now.
3) It's NFS, which does work on all clients. If I have a local user "test" with UID 1004 in the Debian machine, it can access /home/test
4) I'll have to get back to you with this.
5) All machines are in the same domain, or should be. I'll have to check this, as I can only think how I have set domainname in rc.conf, which of course is not how it must be done in systemd.

[Gribouille]

1) I think it's "passwd: files nis" I might be missing systemd

It's enough. But take care if you have NetworkManager or a management of the network by 'Systemd'.

2) Everything is done "remotely" over telnet or ssh for now.

Sorry, you must try in local, physically on the system.

3) It's NFS, which does work on all clients.  If I have a local user "test" with UID 1004 in the Debian machine, it can access /home/test

I'm not sure to understand. Does the password is recognized in this case with an access by SSH ? or by 'root' with 'su - test' ?

4) I'll have to get back to you with this.

5) All machines are in the same domain, or should be.  I'll have to check this, as I can only think how I have set domainname in rc.conf, which of course is not how it must be done in systemd.

With Debian, '/etc/resolv.conf' (for a static configuration),  '/etc/idmapd.conf' or '/etc/hosts' are to check if you haven't done some unusual things.

[KC9UDX]

1) I do have NetworkManager, which I wish I didn't but don't want to stray too far from a standard installation, but all network settings are static. I'll have to see if systemd is in there or not.

2) Several of these machines don't have a physical console. On others I have used the console with the same results.

3) via NIS, the password is never accepted. What I have done is make a duplicate copy of the NIS user on the local machine, same UID/GID, same username and password. With that, the user can access his home directory (NFS).

5) I haven't done anything unusual. In fact, I reinstalled one of the Debian machines from scratch the other day and didn't do anything besides setting up NIS and NFS. But I'll have to make sure all the Linux clients have the correct domainname.

[Gribouille]

3) via NIS, the password is never accepted.  What I have done is make a duplicate copy of the NIS user on the local machine, same UID/GID, same username and password.  With that, the user can access his home directory (NFS).

Ok, it's a good bad result  Now, a NIS problem for the password NIS map and his usage is the most probable origin.

What contains your logfiles ?

[KC9UDX]

I checked the domainname and they all agree.

I tried 'su - test' on the client which *worked* to my surprise.

/var/log/auth.log on the client is such:
Jul 12 18:51:14 client login[12661]: FAILED LOGIN (1) on '/dev/pts/1' from 'localhost' FOR 'test', Authentication failure

/var/log/authlog on the server is such:
Jul 12 18:50:41 server rpcbind: connect from 192.168.0.38 to getport/addr(ypserv)

I find this very troubling; /var/log/messages on the client:
Jul 12 17:50:39 client NetworkManager[337]: <info> [1626130239.5545] dhcp4 (enp3s0): nameserver '192.168.0.25'
Jul 12 17:50:39 client NetworkManager[337]: <info> [1626130239.5545] dhcp4 (enp3s0): domain name 'test.net'
Jul 12 17:50:39 client NetworkManager[337]: <info> [1626130239.5545] dhcp4 (enp3s0): state changed bound -> bound

Where 'test.net' comes from and why domainname reports not 'test.net' but the correct domain name is a mystery at this point. The correct domain name is set in /etc/yp.conf

/var/log/kern.log on the client is very old and doesn't show anything related

---

I edited /etc/resolv.conf and changed test.net to the correct domain; NetworkManager apparently put this in there and probably will again; I'll have to investigate NetworkManager.

But since changing that, I restarted nis and rpcbind and now /var/log/auth.log gives more information:
Jul 12 19:15:44 client login[14820]: pam_unix(login:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/pts/1 ruser= rhost=localhost user=test
Jul 12 19:15:47 client login[14820]: FAILED LOGIN (1) on '/dev/pts/1' from 'localhost' FOR 'test', Authentication failure