HOWTO: Solaris NIS Server and (Red Hat 9) Linux NIS Client

Today (errr.. yesterday) I found myself needing to set up a Red Hat 9 based server that would use a Solaris NIS+ server as its source of account information on a “temporary” basis. It is possible for Linux to use NIS+ as an authentication source but I found the idea highly undesirable considering the distribution of choice does not ship with the needed tools and documentation seemed to be quite nonexistant. There was also the risk that because the maintainers of the distribution (hence the operating system itself so to speak) did not use or test with NIS+ there may have been bugs and problems introduced into the system libc that would complicate its use.

I remembered that NIS+ on Solaris has a “NIS compatibility mode”. NIS is supported “out of the box” in pretty much every version of Red Hat since the dawn of time so this seemed the best option. Turning on this “compatibility” feature of rpc.nisd on the Solaris server would cause rpc.nisd to respond to both NIS+ and NIS requests. The Linux system could then authenticate users using NIS. Turning on this compatibilty mode is trivial (simply start rpc.nisd with the -Y flag) and is documented in the rpc.nisd man page. You will need to edit the /etc/inet/rpc script and make sure EMULYP="Y" is either uncommented or make sure rpc.nisd is started with the needed -Y flag.

The NIS+ service daemon should now respond to NIS requests. By default the passwd table in NIS+ is configured with permission settings preventing users and machines which are ‘unauthenticated’ (I really don’t want to cover NIS+ credentials here) from viewing the actual field in the table that contains the hashed password string. All “requests” that come into rpc.nisd through NIS seem to use the “nobody” permission set.

By default passwd.org_dir in NIS+ allows “nobody” to access every field in the passwd table except for the actual password string itself. This manifests itself as all password fields appearing to be set to *NP* or similar while attempting to use ypcat passwd or getent passwd on a client machine. The fix for this is to simply grant the read permission to “nobody” using “nischmod n+r passwd.org_dir“. The password field should now be viewable using the aforementioned commands on client machines.

WARNING: The password field of the passwd database is now visible to any machine able to request it. While this is not that big of a deal on systems that are legitimate clients (getent passwd by default on a NIS+ client machine allows non-root users to see the string) it can be a big deal if the machine hosting the NIS+/NIS service is not properly firewalled. If the portmap RPC service and other RPC services are exposed to the outside world it is quite possible someone could extract your passwd database from your server. If you are unfamiliar with NIS security please do some research before deploying. (Of course if you are exposing any Solaris RPC service you will most likely get hacked eventually… depressing but true).

With that warning out of the way it is now time to configure the Linux client. Red Hat 8 and later both have a text (authconfig) and GUI tool (authconfig-gtk) to allow you to configure which means of obtaining user information and authentication you wish for the system to use. Simply start one of the tools. I will use the GUI program (authconfig-gtk) for this example.

On the User Information page make sure Cache User Information and Enable NIS Support are checked. Click on the Configure NIS… button and enter the NIS Domain and IP address of the NIS server you wish to use. Click OK on the NIS Settings window and you should now be returned to the main window. Click OK on the main window. There may be a long pause before the program quits completely.

Now you will need to make sure the needed services are running. portmap, ypbind and nscd should be running. Check /var/log/messages to make sure ypbind is happy and has found the NIS server. Check /etc/nsswitch.conf and make sure you are happy with the settings the tool set up for you. (The defaults were fine for my use). To test if nsswitch and friends are working, simply use the command “getent passwd“. You should see the local passwd file scroll by followed by the contents of the passwd table in NIS/NIS+. If you see this then nsswitch.conf and friends are happy. Be Happy.

Unfortunately the PAM configuration that authconfig sets up for you in /etc/pam.d/system-auth does not seem to work when a Solaris NIS+/NIS server is the server in use. (UPDATE: You may not need to tweak the pam files at all for it to work… My problem might have been nscd caching negative responses during earlier testing.) The following is the PAM file that seems to work for me:

auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix_auth.so shadow nullok
auth        required      /lib/security/$ISA/pam_deny.so                                                                                                    account     required      /lib/security/$ISA/pam_unix_acct.so                                                                                                    password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix_passwd.so shadow nullok
password    required      /lib/security/$ISA/pam_deny.so
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix_session.so

The file seems to work fine for openssh’s pam.d config file and should work fine as system-auth. The only thing that will not work is the changing of passwords. Which for my use is not a problem (and actually desirable) but it may be for you. Unfortunately from my (meager) understanding this would require you to add more privileges to “nobody” on the passwd.org_dir NIS+ table and in my mind that is highly undesirable. If you find yourself needing to change passwords from NIS clients you’ll need some very careful firewalling to have any hope of keeping your account database secret.

The real solution is to use LDAP. The problem is Solaris only seems to support LDAP in a useable “out of the box” form in Solaris 9. I have been told the padl PAM modules work well on Solaris so if you find yourself needing to use Linux clients mixed in with Solaris servers and clients, it may be time to seriously consider moving to LDAP instead of playing with NIS. At most NIS should be used as a temporary emergency measure in my mind.

If I have said anything in this post that is technically wrong please feel free to let me know. Unfortunately, if the above does not work for you I’m afraid I do not have the means or time to help you diagnose the issue. At least I hope I have faced you in the right direction.