8.3 UNIX security-related concepts

The next sections introduce some typical UNIX security-related concepts that will be referred to throughout this chapter. We will discuss PAM, UNIX naming services (NIS, NIS+ and the NSS), and Samba.

Thanks to PAM, UNIX system administrators can plug different authentication methods and protocols into the UNIX OS. This makes the different authentication methods and protocols available to the different UNIX system entry applications such as login, ftp, telnet, su, passwd, and rlogin. The following is a nonexhaustive list of authentication methods and protocols that PAM can make available to applications:

• UNIX file-based authentication (using the /etc/passwd or /etc/ shadow files)

• LDAP-based authentication

• NIS or NIS+-based authentication

• Kerberos-based authentication

• S/Key-based authentication

• SecurID-based authentication

• NTLM-based authentication

PAM can also enable single sign-on (SSO) on the UNIX platform; if the passwords used for different services are identical, PAM can be used to share the password transparently between the application’s possibly different authentication mechanisms.

8.3.1 PAM

Figure 8.1 shows the basic PAM architecture. A key element in the PAM architecture is the PAM configuration file. PAM authentication behavior can be configured differently for each individual PAM-enabled service. This can be done for all services together in the /etc/pam.conf file or for an individual service in its proper PAM configuration file—the latter is located in the /etc/pam.d directory.

Figure 8.1: The PAM architecture.

Among the configuration parameters specified in a PAM configuration file are the authentication modules that must be loaded for a particular system entry application’s authentication process to complete. PAM modules are stackable—this means that during the authentication process a service may be configured to call on different PAM modules. All this is illustrated in the following example showing the content of a PAM configuration file that holds the PAM authentication configuration for the login, ftp, and telnet services:

login auth required /lib/security/pam_unix_auth.so login session required /lib/security/pam_unix_session.so login account required /lib/security/pam_unix_account.so login password required /lib/security/pam_unix_passwd.so ftp auth required /lib/security/pam_skey_auth.so ftp session required /lib/security/pam_unix_session.so telnet session required /lib/security/ pam_unix_session.so

As you may have noticed in this sample configuration file, PAM provides more than just authentication services. It also provides the following services that are closely related to authentication: account, password, and session management services. PAM account management modules allow system entry applications to retrieve account-related information (such as logon hours, account expiry date, and so forth) from a local or central repository. Password management modules allow system entry applications to change users’ passwords. Session management modules allows for the setup and closing of a user’s session. It also allows for the logging of session information in a local or central repository.

The PAM architecture is supported on most Linux platforms (e.g., Redhat 7.2 and later) and on the HP-UX (from version 11.0 on), Solaris, and AIX platforms. In the context of this discussion on UNIX and Windows authentication integration, the following PAM modules are of particular interest:

• pam_unix: A PAM module supporting authentication, account, and password and session management. The pam_unix supports UNIX crypt(3) password hashing.

• pam_ldap: A PAM module used in conjunction with the pam_unix module for authentication and password management with an LDAP server.

• pam_kerberos: A PAM module that adds support for the Kerberos authentication protocol (as defined in RFC 1510).

Another PAM module that could be used in the context of a Windows- UNIX security integration project is pam_smb. The pam_smb supports the NT Lan Manager (NTLM) authentication protocols and can be used to authenticate UNIX hosts and users against a Windows server or domain controller (DC). I will not discuss the pam_smb in this chapter. It does not use any of the key protocols for Windows-UNIX security integration in an AD-centric world: LDAP and Kerberos. Also, the NTLM authentication protocols are based on proprietary standards and are considered less secure than the Kerberos authentication protocol. More information on pam_smb can be found at http://www.csn.ul.ie/~airlied/pam_smb. Note that I will discuss Samba; the latest Samba version (2.2.8) is still using NTLM authentication as well. Samba, however, will provide Kerberos authentication support in a future release.

The Windows equivalent of PAM is the Security Support Provider Interface (SSPI) and its Security Support Provider (SSP) modules. Here is an interesting side note: Back in the 1990s a team at the University of Michigan succeeded in developing a PAM-like architecture for NT (more information on this can be found at http://www.citi.umich.edu/u/itoi/ni_pam_usenix.pdf).

8.3.2 UNIX naming services

A general definition of a naming service is a repository that stores all kinds of information and that allows this information to be queried by clients (users and applications) in an easy way. This information typically includes host to IP address mappings, user account names, credential information (secured passwords), access permissions, access intermediaries (groups) and their membership, and printer definitions. Naming services not only allow users and applications to retrieve information, but they also allow them to update information and to perform name resolution (or to query for name mappings). In the context of this chapter, naming services are primarily used to enable different computers to share authentication- and authorization-related information by storing them in a central repository governed by a naming service.

Examples of typical Windows naming services are flat files (the hosts and lmhosts files), the Windows Internet Name Service (WINS), the Domain Name System (DNS), and the LDAP-based naming services. Also, the Windows security database (SAM or AD) that is governed by the local or domain security authority can be designated as a naming service: one that is specifically focusing on security-related information.

Over the years the UNIX OS has supported a wide range of naming services. As with Windows, these include flat files (stored in the /etc directory), DNS, and LDAP-based naming services. UNIX also supports two other UNIX-specific naming services: the Network Information System (NIS) and the Network Information System Plus (NIS+). The UNIX- specific naming services are discussed in more detail next.

Table 8.2 summarizes the characteristics of most common UNIX naming services. (This list is not exhaustive: less common naming services such as the Federated Naming Service [FNS] are not discussed.)

Table 8.2: Common UNIX Naming Services

UNIX Naming Service	DNS	LDAP	NIS	NIS+
Namespace	Hierarchical	Hierarchical	Flat	Hierarchical
Data Storage	Files/Resource records	Directories	Two column binary maps	Multicolumned tables
Server Types	Primary/Secondary	Master/Replica	Master/Slave	Root domain master/subdomain master/replica
Security	Public Key Extensions	SSL (LDAPs)	None	DES/public-private keybased authentication

8.3.3 NIS

In 1985 SUN Microsystems produced NIS: the Network Information Service, which is also referred to as the Yellow Pages (yp). NIS was one of the first UNIX-based distributed naming services. The primary focus of NIS was to make network management easier by providing a centralized naming service and repository.

An NIS repository centralizes information such as machine names and addresses, user names, network services, and so forth. This collection of information is referred to as the NIS namespace. The NIS namespace is stored in binary files that are known as NIS maps. A typical NIS service has maps such as passwd, group, automount, services, and rpc. Often there are two or more key fields in a map; the passwd map, for example, services lookups both by username and by UID.

The way that a UNIX client interacts with an NIS service is relatively simple. It is all based on the fact that the information stored in the NIS maps is augmenting or replacing information stored in local UNIX configuration files such as /etc/passwd, /etc/hosts. Let us illustrate this using the example of the /etc/passwd file, which stores account-password mappings and is used for local user authentication on a UNIX host. Thanks to NIS, a UNIX host can be redirected to a central NIS server when validating a user’s credentials. This happens if the user’s entry in the host’s local /etc/ passwd file is marked with a + sign. For example, the following entry in the /etc/passwd file will redirect the UNIX host to the passwd map on the NIS server to find out the credentials of user johndoe (in this entry the number 2003 is the UNIX UID of johndoe, 103 is the GID of johndoe).

+johndoe::2003:103:::

Like NT, NIS uses the notion of a domain to provide an administrative grouping of machines. A UNIX host’s NIS domain basically determines which NIS server the host will query. Within an NIS domain, NIS uses a single-master information replication model that is made up of a master and multiple slave NIS servers. Figure 8.2 shows the NIS architecture. Figure 8.2 also shows some of the typical NIS commands: “ypbind” to connect to a NIS server, “yppush” to push changes from NIS master to slave servers (also note that the yp in these commands stands for “yellow pages”).

Figure 8.2: The NIS Architecture.

One of the biggest deficiencies of NIS is its complete lack of security: NIS does not authenticate its users, NIS data are transmitted in the clear, NIS updates can be spoofed, and so forth. NIS also lacks an easy extensible data structure and an efficient information replication model.

8.3.4 NIS+

NIS+ was introduced by Sun as part of the Solaris 2 OS as an enhanced naming service for NIS. Like for NIS, the primary focus of NIS+ was to make network management easier by providing a centralized naming service and repository. The most important enhancements coming with NIS+ compared to NIS are support for a hierarchical namespace, client authentication (both users and hosts), secured data transmission, NIS+ object access control lists (ACLs), incremental updates between master and slave servers, and a better data storage model. Instead of using binary files, NIS+ stores its information in database-like tables.

NIS+ architecture can be made up of several hierarchical layers of master and replica NIS+ servers: At the top of the hierarchy sits a root master server, and underneath it can be one or more subdomain master servers. Each of the master servers can have one or more replica servers. Figure 8.3 shows the NIS+ architecture.

Figure 8.3: The NIS+ architecture.

Many NIS+ concepts are very similar to the concepts used by LDAP- rooted naming services. Because of these similarities and because of the adoption of LDAP as the default naming service in Solaris version 9, Sun considers NIS+ an end-of-feature (EOF) naming service.

8.3.5 NSS

Because many different naming services (DNS, NIS, NIS+, LDAP, and so forth) can be made available to UNIX clients and applications, Sun developed the concept of a universal naming service: the Naming Service Switch (NSS). Just like PAM, NSS is implemented using shared code libraries. The latter facilitates reconfiguration and makes it relatively easy to plug in a new naming service.

NSS is a client-side technology. Thanks to it, UNIX clients and applications do not have to be aware about which naming service stores which information. When the client or application wants to resolve a name, it simply calls on the NSS API. NSS then determines which naming services should be searched and in which order they should be searched. The NSS configuration is nailed down in the nsswitch.conf file. Figure 8.4 shows the NSS architecture. Notice that PAM modules can also call on NSS for naming services.

Figure 8.4: The NSS architecture.

Next is an example of the configuration data that can be found in the nsswitch.conf file. Note that unlike PAM, NSS does not allow configuration on a per service basis. As shown in the example NSS can, however, be configured on a per data type basis. For the different data types that may need to be resolved on a host, the nssswitch.conf file can specify different name resolution sources and the order in which these sources should be tried.

passwd: files nisplus nis shadow: files nisplus nis group: files nisplus nis hosts: files nisplus nis dn sservices: nisplus files

In order to speed up name resolution, most UNIX NSS clients also support a caching mechanism known as the name service caching daemon (nscd).

NSS is currently supported on Solaris, Linux, and HP-UX (from version11.0 onward). AIX has a similar concept called Information Retrieval System (IRS), which is rooted on Bind 8 code.

8.3.6 NIS futures and LDAP integration

Unlike NIS+, NIS is not considered an end-of-feature solution and until now Sun has not announced any plans to migrate it to LDAP. Because Windows AD is an LDAP-centric repository, some kind of NIS/LDAP integration will be needed in IT environments where integrated Windows and UNIX account management is needed and where NIS naming services are still required. Two common approaches are to store NIS data in an LDAP directory or to provide an NIS-to-LDAP gateway service. In the latter approach NIS queries must be translated into LDAP queries.

The first approach is described in RFC 2307 “An Approach for Using LDAP as a Network Information Service” (an IETF Internet draft) and RFC 2307bis (a revised version of RFC2307). Both RFCs describe an LDAP directory schema for storing NIS data in an LDAP directory. The RFCs provide mappings for all the common NIS maps: passwd, group, hosts, shadow, services, netgroup, protocol, ethers, and so forth. Both RFCs describe directory objectclasses and attributes, but none of them mandates the use of a particular LDAP tree structure.

The default Microsoft AD schema is not RFC 2307-compliant. The same remains true when adding the MS SFU 3.0 NIS schema extensions.

The AD schema can be made RFC 2307-compliant by adding the AD4Unix schema extensions—a set of freeware extensions that can be downloaded from http://www.css-solutions.ca/ad4unix. AD4Unix supports both RFC 2307- and SFU-compliant schema extensions. Figure 8.5 shows the AD4Unix configuration dialog box that is used to set the “schema style.” Note the naming differences between the SFU- and the RFC 2307- naming conventions.

Figure 8.5: AD4Unix AD schema style configuration.

Both NIS-LDAP integration solutions are discussed in greater detail later in this chapter.

8.3.7 Samba

Samba is a collection of software that provides the following two important services to the UNIX platform:

• Samba allows UNIX clients to access file and print services using the Server Message Block (SMB) and Common Internet File System (CIFS) network protocols.

• Samba allows the UNIX server to provide file and print services using the SMB and CIFS network protocols.

SMB is the default Microsoft file and print sharing protocol. CIFS is the name Microsoft uses to designate the SMB flavor that can run without requiring NetBIOS over TCP (NBT).

These two services make Samba the ideal gateway for sharing file and print services and integrated authentication between a Windows and a UNIX environment “the Microsoft way” (using the SMB protocol). Later this chapter also covers some solutions that can be used for file service sharing and integration authentication between Windows and UNIX “the UNIX way” (using the Network File System [NFS] protocol).

Samba runs on a variety of server platforms, many of which are UNIX flavors (AIX, Linux, and so forth) but also on VMS, Netware, and OS/2. Samba is freeware software that is available under the GNU public license (more information on this license is available at http://ftp.easynet.be/ samba/docs/GPL.html). Plenty of Samba-related information can be found on the Samba Web site at http://www.samba.org.

From a security point of view, Samba comes with the following features and functionality:

• Can act as the only Windows Primary Domain Controller (PDC) (only from Samba version 2 onward) in an NT 4.0-like (non AD- based) domain.

• Can be configured as a Backup Domain Controller (BDC) in a pure Samba environment. This can be done by replicating the smbpasswd file whenever changes are made to the SAM database.

• Can be a member server in a Windows NT 4.0, Windows 2000, or Windows Server 2003 domain.

• Can support NTLM authentication and Windows pass-through authentication.

• Can provide NetBIOS name resolution services. A Samba server can even act as a WINS server.

At the time of writing it was impossible for Samba (version 2.2.8) to operate as a domain controller in a Windows 2000 or later environment.

Also, Samba currently does not support Windows interdomain trust relationships. As pointed out in this list, Samba can be a member server in an NT4.0, Windows 2000, or Windows Server 2003 domain. For Windows 2000 this is independent of the domain mode (mixed or native). For Windows Server 2003 this is independent of the functionality level.

In a future release (the Samba TNG or Samba version 3.0 project), Samba may include LDAP and Kerberos support, enabling it to interact with AD as a true Windows 2000 or later server.

Later this chapter discusses two Samba-based solutions:

• One that is based on coexistence between a UNIX and a Windows infrastructure and that uses Samba for SMB-based file and print sharing between the two platforms.

• Another one that can provide true integrated Windows and UNIX account management and authentication integration for UNIX users of SMB resources. This solution is based on the Samba Win- bind service.