Ypbind successful, but cannot login with NIS

Hi All,

I’m trying to use NIS on Rocky Linux 8.4. I’ve successfully ypbind, but I still cannot login my account with NIS unless I add these two things:

  1. Add this line in /etc/passwd
    ====
    <my_account>:x:1736:1501:<my_account_name>:/home/<my_account>:/bin/bash
    ====
  2. Add this line in /etc/shadow
    ====
    <my_account>:<my_pwd>::0:99999:7:::
    ====
    <my_pwd> is the encrypted password string getting from yptest | grep <my_account>

Once I have changed my passwd, I will have to modify these two things. It is not convenient.

Has anyone encountered this problem before?

Thanks

Have you checked the “passwd”, “group”, and “shadow” entries in the /etc/nsswitch.conf to make sure that ‘nis’ is one of the methods to be used ? (backup the original file before modifying)

The ‘original’ file that ‘I’ see, have ‘these’ entries:

# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:     files sss
shadow:     files sss
group:      files sss

You will probably want each entry to have the following ‘methods’ in ‘this’ order:
: files nis sss

The ‘manual’ method you used, worked since ‘files’ is one of the methods (and the primary method to be used)

OH, and and odd behavior with NIS, may require that the ‘compat’ method be used in the “group” entry and possibly the others (do a ‘man nsswitch.conf’ for more info)

Hi,

Yes, I did change the “passwd”, “group”, and “shadow” entries to “files nis sss” or “nis files sss”. But neither of them will work. Forgot to mention that I run my Rocky Linux on a vmplayer to test. Not sure if it may be the vmplayer’s problem.

Thanks

Or, the old ‘port’ issue, being ‘blocked’ by either local host firewall rules, or that of the hosting ‘iron’…

Hi, I’ve turned off the firewall but still not working. I doubt it’s the passwd encrypting method that cause this issue, maybe our nis server and the rocky linux have different passwd encrypting settings. Do you know where can I find the rocky linux’s passwd encrypting settings?

If you run the command ypcat passwd do you see the NIS password map? If not then you don’t have the NIS layer working. This is a low level test to show that ypbind is talking to a NIS master and getting results back.

If you run the command getent passwd do you see all the local entries and then the NIS entries? How about getent passwd a_nis_user (where you need to pick a user in the NIS map that is not in the local password file). If that doesn’t work then you have your nss layer misconfigured.

If all these work then the problem is likely to be at the PAM stack or elsewhere.

How are you trying to login? On a text console? Via ssh? From a GUI login? One normal “gotcha” with GUI logins is if the home directory doesn’t exist or has the wrong owner/permissions.

Hi @sweh,

  1. If you run the command ypcat passwd do you see the NIS password map? Yes.
  2. If you run the command getent passwd do you see all the local entries and then the NIS entries? Yes.
  3. I getent passwd a_nis_user and I can see the user in the NIS map that is not in the local password file

I’ve tried to login with

  1. Via ssh using the terminal on my computer to my Rocky Linux on a virtualbox and
  2. Directly using the GUI login on the Rocky Linux on a virtualbox
    but neither of them will work.

I ypwhich and it did show my nis server’s IP, and I can successfully ping from my Rocky Linux to this IP.

And my user directory setting under my home directory is the same as the user folder on my other computer which can successfully login with nis.

Hi, I authselect select nis and it worked

So all the tests (eg ypcat) demonstrated that NIS was working, and a minimal level of nsswitch was good.

Now since authselect primarily rewrites nsswitch.conf and /etc/pam.d/ files this highlights that’s where the problem was; either with one of the nsswitch entries or with PAM. If you have a copy of before/after then you might be able to see what the important change was.

2 Likes