There are several sources of non-local accounts on Linux systems. You have probably heard of two: an NIS server and an LDAP server. Both are topics in the follow-on course on Networking Administration. In addition to NIS and LDAP other sources of authentication information are sssd, winbind, kerberos, and idm. Although we are concerned only with client configuration in this course, some mechanism must exist to decide how to search these sources of information and the various tools that perform authentication must be consistently configured.

If  you have a non-local account there usually is a non-local source for the home directory as well. This is often provided via NFS. As we will see later in the course, these home directories are usually mounted on-demand using the automounter.

In discussing non-local accounts we should take a step back and discuss the two views of authentication as a means of explaining how the information is distributed on a Linux system. The first view is from the local system's point of view - "Someone is logging in - where do I look to authenticate them?" Information for this view is kept in the nsswitch - the name service switch, configured in /etc/nsswitch.conf. The second view is from a program who needs to have an authentication task performed - "How can I call a function to authenticate and have it work no matter where the authentication information is coming from?" This second view is very important because we want authentication to work correctly when the mix of authentication sources changes without having to install new programs. To accomplish this, most Linux utilities that perform authentication use PAM - the Pluggable Authentication Modules. PAM's configuration is kept in files in /etc/pam.d named for the service for which they provide authentication. (PAM handles much more than how to lookup credentials for logins - it handles the entire login process and is highly configurable. We will discuss PAM briefly later in the course.)

These two views of authentication follow different pathways in the system, and they must be configured in a consistent manner. This consistent configuration is provided by the authconfig program, which sets parameters for the system in the nsswitch and for programs in the PAM files. We will examine these changes in one of the exercises when we change the source of authentication for a virtual machine.

NIS and LDAP are two sources of non-local authentication information that are configured using the  authconfig program either through its control panel or at the command-line. We will discuss these and their configuration files after a brief introduction to each service. Parameters set by authconfig can be found in the file /etc/sysconfig/authconfig. The results can also be seen in the nsswitch and in the PAM configuration files.

nsswitch.conf

The name service switch configures how various types of data are distributed on a Linux system and the order in which the sources should be searched. It organizes the data in databases, which may be the standard local text files (like the passwd and group files) or non-local queries, such as LDAP or NIS.

There are multiple databases configured by nsswitch. We will discuss the use of three: passwd, group, and shadow. Each of these is configured on a single line in /etc/nsswitch.conf: the database name is followed by a colon, then a space-separated list of services that can provide entries in that database. The services that are available (installed) on a machine are implemented as libraries in /lib64/nss_x.so, where x is the service name. The most basic services that are important here are

files - use the local files such as /etc/passwd and /etc/group to find the information

nis - query nis for the information

ldap - query ldap for the information

The order in which the services are listed on the database line determines the order they are queried. Thus

passwd: files ldap

indicates that the local files should be searched for passwd entries first, then LDAP, whereas

passwd: ldap files

indicates the opposite order.

NIS

NIS, which stands for Network Information Service, is an old non-local authentication system that has fallen into less use of late due to security concerns. Although it is possible to deal with the worst of these security issues using careful configuration, it only recommended for use on local networks. It should never be used for authentication from (or exposure to) the Internet. At the time of this writing, our local linux network uses NIS for authentication. NIS' old name was yellow pages, hence most NIS tools' names start with the prefix yp.

NIS is pretty simple. Essentially the NIS server shares account and group information starting at particular uid/gid numbers with the clients on the network. These types of information are shared via maps, which can be queried by the clients. The most commonly-used maps are passwd and group, which share the passwd and group information, respectively, from the server.

To authenticate against an NIS server is simple - all you need is the NIS domain name (set by the server), and the server's FQDN or IP address. First you need two packages - the yp-tools and ypbind package. ypbind performs the actual communication with the NIS server.

When you are logged in via NIS, of course, you are using an account on the NIS server. All requests to change or query account information must be sent to the server. This is the purpose of the yp-tools package. yp-tools includes user tools for querying the server, changing your password and changing other account information on the server. The only exception here is yppasswd, which has been deprecated (the standard passwd program now knows how to change the NIS password.) Here is a short list of the interesting yp tools:

• ypcat - cat the yp database, given a map name. For example, ypcat passwd will show the /etc/passwd lines (from the NIS server) of all NIS accounts.
• domainname - display the current NIS domain
• ypwhich [domain] - display the current server of the NIS domain
• ypchfn, ypchsh  - change the user's finger information or shell. These programs are deprecated. Their functionality has been moved into the yppasswd program. yppasswd -l is used to change the user shell and yppasswd -f is used to change the finger information, but these functions do not work well if the NIS server is running with SELinux enabled, as ours is.
  
• yppasswd - change the user's password. This is deprecated. This functionality is in the passwd program itself.
  

NIS security issues

When authentication is performed against an NIS server, the server sends the encrypted password to the client so that it can be used for authentication. This is the major glaring security issue of NIS. It can be resolved by using Kerberos passwords with NIS, or by switching to LDAP.

The second security issue with NIS is its tendency to want to use random ports. Although it is possible to tie down static ports for the crucial NIS services, the yppasswdd protocol (which is used for ypchsh and ypchfn, but not needed to change passwords) does not allow the use of a static port. You may find on our systems that these programs do not function correctly, hence the user no longer has control of their shell nor finger information. This tendancy of NIS to want random ports makes firewall configuration difficult.

The last security issue with NIS is that it allows the local root user to co-opt network accounts. For obvious reasons we will not show how this is done, but suffice it to say that any breakin of root on a local (client) machine compromises all NIS accounts on the network.

NIS is discussed more completely in this course's follow-on course - cs260b.

LDAP

The Lightweight Directory Access Protocol is a general-purpose client/server system for a central repository of user parameters. As I understand it, the use of LDAP for Linux authentication mimicks the information that NIS provides - that from the passwd, group and shadow files. All communication between the client and the LDAP server is, however, encrypted, which circumvents the biggest issues with NIS. LDAP is discussed at length in this course's follow-on course, cs260b. It will also be discussed briefly in class.

Authenticating against an NIS server

Authenticating using NIS can be configured with the authentication control panel. Simply select NIS, enter the domain and server, and apply. This requires the installation at least of the ypbind package.

This is equivalent to running the authconfig program like this

# authconfig --enablenis --nisserver=192.168.122.251 -nisdomain=nis-bs --update

Both of these methods will

• update /etc/yp.conf to indicate the server
• configure ypbind to start at boot
• start ypbind now
• update the /etc/nsswitch.conf file to indicate that nis is now used for authentication as well as the passwd and group files
• update the PAM configuration for changing passwords to allow changing NIS passwords.
  

Mixing of authentication sources can cause difficulty when configuring a group of systems, especially when they are heterogeneous. In the current versions of RedHat Linux, especially in version 7, a new "super-service" has been provided called the Identity Management Service, or idm. The idea behind idm is to centralize all the authetication on one external server with a user-friendly interface. Rather than configure each client separately to use a mix of authentication sources, then,  each client is configured to use the idm server and the single idm server (and possibly one or more idm slave servers) are configured for the various authentication sources - NIS, LDAP, active directory, Kerberos, etc. The idm server also can centralize NFS mounts, sudo configuration and DNS.