How Do You Spell Relief?

Articles and Tips: article

Mike Latimer

Jeff Harris

01 Apr 2005

In a nutshell, Linux User Management (LUM) is a directory-enabled application which centralizes the storage and management of Linux user accounts. LUM uses eDirectory for the back-end repository of users and therefore benefits from the security, scalability and reliability that eDirectory users have come to expect.

The following excerpts are taken from the upcoming Novell Press book by Mike Latimer and Jeff Harris, "Novell Open Enterprise Server Administrator's Handbook, SUSE LINUX Edition" which will be available through any major book reseller after May 13, 2005 (ISBN: 067232747X).

LUM extends the capabilities of the Novell Account Management (NAM) software and is comprised of the following components:

NAM Pluggable Authentication Module (pam_nam): This module provides eDirectory authentication through LDAP for all PAMaware services. Once authenticated, users have the same privileges as when authenticating through NIS, NIS+ or local files.

Linux Administrators may equate this to the pam_ldap module. While the primary purpose of pam_nam is to provide LDAP authentication, and while similar to pam_ldap, pam_nam offers a closer integration with eDirectory with the following additional benefits:
- Unique UIDs and GIDs across the LDAP tree, or LUM domain.
- Advanced server access control based on LDAP access control lists (ACLs) in eDirectory.
- Refined LDAP searches offering a more effective integration with eDirectory.
NAM Name Service Switch (libnss_nam) redirector: This redirector enables user lookup through an LDAP connection to eDirectory. This is used to enforce permissions when accessing system resources.
NAM Cache Daemon (namcd): This daemon caches all user lookups performed by NAM. This cache is checked first when performing user lookups. If the requested resource is located with the cache, the LDAP lookup against eDirectory will not be performed, thus greatly increasing name resolution performance.
Command Line Utilities: Many different command line utilities exist to add Linux administrators. These utilities can be used in place of iManager for basic LUM administration. More information on these utilities will be available later in this section.

LUM-related Objects

In addition to the physical components of LUM, in order for LUM to integrate Linux authentication into eDirectory, the eDirectory schema must be extended. The extension takes place automatically during the LUM installation. LUM specific extensions create both classes and attributes required for authentication by the Linux services. These extensions are used in creating LUM-specific objects used to configure LUM, and when modifying user and group objects to convert them to valid Linux users and groups.

The following list describes each of these required LUM objects:

Linux (UNIX) Config: This object is used to store configuration information for a specific LUM domain. It contains such things as the next available GID and UID numbers and the context for Linux Workstations.
Linux (UNIX) Workstations: Every Linux server or workstation relying on LUM authentication must have a Linux Workstation object in the eDirectory tree. This object maintains a link to all LUM Groups which are allowed access to local services.
LUM User: Normal eDirectory users are extended with a Linuxspecific auxiliary class. This extension provides users with attributes required for Linux authentication. New attributes assigned to users include such things as the User ID (UID) number, primary Group ID (GID) number, default shell and home directory location.
LUM Group: eDirectory groups are also extended using a Linuxspecific auxiliary class. This extension adds such attributes as the Group ID (GID) number, and Linux Workstations and users assigned to the group.

Note: During the installation of LUM, a default Linux Config, Linux Workstation and LUM group are all configured automatically. However, LUM users must either be created manually during the creation of a new eDirectory user, or an existing eDirectory user must be converted to a LUM User prior to using LUM.

LUM Administration

LUM administration can effectively be divided into the following three categories:

LUM Configuration
User and Group Administration
Linux Service Administration

LUM CONFIGURATION

Although LUM is usable immediately after installation, it is a good idea to check the default LUM configuration prior to creating LUM users. Take the following steps to check the LUM configuration:

Launch iManager. In the Navigation frame, open the Linux User Management group and select Modify Linux/Unix Config Object. (See Figure 8.11.)
Locate the default UNIX Config object using the object selector. This object can be found in the same context as your server object. Click OK.
On the PosixConfigPage under the LinuxProfile tab, check the configured information and click OK. The default values are normally sufficient, but if necessary, the following fields may be changed:
- Linux Workstation Contexts: Enter the context or contexts where Linux Workstation objects should be located within the tree. When you use namconfig to add additional workstations to the tree, additional contexts will be automatically added.
- uam Posix GID/UID Number Start: Enter the first available number for Linux GID and UID numbers in these fields.
- uam Posix GID/UID Number End: Enter the last available Linux GID and UID numbers in these fields.
- uam Posix GID/UID Number Last Assigned: These fields contain the last GID and UID numbers assigned by LUM. Only change these fields if you intend to skip a number range.
- uam Posix GID/UID Number Reuse: Check these options if you would like to reuse GID and UID numbers which belong to deleted users and groups.
  
  WARNING Reusing GID and UID numbers which were previously assigned to deleted users allows the new user or group to assume the Linux file system rights assigned to the previous user or group. Only use this option if you are familiar with Linux permissions and understand this risk.
- uam Posix GID/UID Number Deleted Map: These fields track the GID and UID of deleted users and groups. These fields should not normally be modified manually.

Figure 8.11

In addition to iManager-based configuration, there are some configuration options that you may want to set on the Open Enterprise Server machine itself. One important option is regarding the configuration of the NAM Cache Daemon (namcd).

As explained earlier, the NAM Cache Daemon caches user and group lookups from eDirectory. By default this daemon uses a persistent cache which will be immediately available upon server restarts. For most implementations this is the desired behavior and will produce optimal performance. However, if you would like to use a non-persistent cache, or modify the cache refresh or size settings, the configuration of namcd must be manually modified.

The configuration file for NAM is /etc/nam.conf. Within this configuration file are settings which determine the behavior of namcd. The primary settings regarding the namcd cache are as follows (See the nam.conf man page for more information.):

enable-persistent-cache=YES: Determines whether the namcd cache is maintained on the local server and kept persistent across server reboots. Valid values are "yes" or "no."
persistent-cache-refresh-period=28800: Specifies the interval (in seconds) in which cached users and groups are refreshed from eDirectory. A longer interval reduces network traffic, but can produce stale data. Valid settings range from 1 to 2,147,483,647 seconds.
persistent-cache-refresh-flag=all: Determines whether all user and group data is refreshed during a cache refresh, or just accounts which have been accessed during the current session. Valid values are "all" or "accessed."

NOTE Do not confuse namcd (NAM Cache Daemon) with nscd (Name Service Cache Daemon). With LUM, namcd and nscd work together. The nscd daemon is used to cache host names and addresses. The namcd daemon specifically caches user and group names and IDs from eDirectory. Using namcd, performance of subsequent lookups of cached users and groups improves significantly.

User and Group Administration

eDirectory users do not automatically have the attributes required for LUM authentication. In order for the user to be a valid LUM user, these attributes must either be added during the initial user creation from within iManager, or added after the fact by converting the existing user to a LUM user. Assigning the LUM attributes to users during user creation has already been described in the User Object section at the beginning of this chapter. Take the following steps to convert an existing user to a valid LUM user:

Launch iManager. In the Navigation frame, open the Linux User Management group and select Enable User for LUM.
Locate the desired user object using the object selector or object history. Click OK.
To enable the user for LUM or Samba, you must complete the following fields:
- Primary Group: (Required) Enter the primary LUM group for the user. All Linux users must be associated with a Linux group. By default, a Linux group called lumgroup is created for this purpose.
- Enable Samba Authentication: If this user will also be accessing server resources via Samba, select the checkbox to enable Samba Authentication. The user's Samba password must also be manually entered into the appropriate fields.
  
  NOTE Enabling a user for LUM during initial user creation will automatically enter the user's password into the Samba password fields. Converting a user after creation may result in non-synchronized passwords if the Samba password entered does not match the eDirectory password.
Press OK to save the modifications.

NOTE Existing Linux implementations may wish to migrate users directly from local, NIS or NIS+ accounts. For information on this process, please see the main page for the unix2edir utility.

Linux requires every user to have a primary group associated with the user. LUM must also require a primary LUM group for users within eDirectory. As with user objects, eDirectory groups do not automatically have the attributes required for valid LUM groups. In order for the group to be a valid LUM group, these attributes must either be added during the initial group creation from within iManager, or added after the fact by converting the existing group to a LUM group. Assigning the LUM attributes to groups during user creation has already been described in the Group Object section at the beginning of this chapter. The following steps describe how to convert an existing group to a valid LUM group:

Launch iManager. In the Navigation frame, open the Linux User Management group and select Enable Group for LUM.
Locate the desired group object using the object selector or object history. Click OK.
To enable the group for LUM, you must complete one of the following options:
- Linux Config object: To associate the group with all defined Linux Workstations within the LUM domain, select this radial option and enter the Linux Config object in the corresponding field.
- Linux Workstation object(s): To associate the group with one or more specific Linux Workstations, select this radial option and enter the group or groups in the corresponding field.
- Press OK to save the modifications.

Table 8.4 PAM-Aware Services Available for Integration with LUM.

Service	Description
login	Local authentications via programs such as mingetty
ftp	File Transfer Protocol connections to programs such as vsftpd
sshd	Secure Shell connections made to sshd
su	Switched User authentications
rsh	Remote command execution sessions with rsh
rlogin	Remote shell sessions made with rlogin (not as secure as SSH)
passwd	Password changes made with the passwd command
xdm	Graphical authentication used with local and remote graphical sessions
openwbem	Authentication to openwbem providers on the local server. This is used for Health Monitoring within Open Enterprise Server.

Linux Service Administration

During the installation of LUM, you have the ability to determine which PAM-aware services you would like LUM-enabled. Services available for selection are listed in table 8.4.

If these services were not configured during installation, you can use the YaST module for LUM to LUM-enable these services later. The following steps document this process:

Launch YaST on the Open Enterprise Server machine.
Select the Users and Security category and then locate the Linux User Mgmt module. Click on this module to execute it.
NOTE You may receive a warning about LUM already being configured on the Open Enterprise Server machine. If you select "Yes," the LUM components will be reinstalled and configuration can continue.
Ensure the LDAP configuration for LUM is correct. Then enter the administrator's password in the appropriate field and click Next.
Ensure the Linux User Management contexts for the Linux Config object and Linux Workstations are correct. If an LDAP proxy is desired, enter the required information and then click Next.
Select the PAM-enabled services you would like integrated with LUM. Selected services will now attempt to authenticate users via LUM prior to authenticating against the local account files. Click Next to complete the installation.

LUM Command Line Utilities

The majority of LUM administration is performed through iManager. However, Linux administrators experienced with the command line interface may find the command line tools quicker than the browser-based interface of iManager.

Table 8.5 summarizes the command line tools available for LUM administration on the Open Enterprise Server machine:

Table 8.5 LUM Command Line Utilities

Use This Utility:	If You Want To:
namconfig	add or remove LUM for a specified eDirectory context. It can also be used to adjust LUM configuration parameters and import the SSL certificate necessary for secure LDAP connections to eDirectory.
namuseradd	create a LUM user in eDirectory. It can also convert non-LUM eDirectory users to LUM users.
namuserdel	delete a LUM user from eDirectory.
namuserlist	connect and list valid LUM users from specified eDirectory contexts.
namusermod	modify a LUM user's login information in eDirectory
namgroupadd	create a LUM group in eDirectory. It can also convert non-LUM eDirectory groups to LUM groups.
namgroupdel	delete a LUM group from eDirectory.
namgrouplist	list valid LUM groups from eDirectory.
namgroupmod	modify a LUM group's attributes in eDirectory.
unix2edir	migrate local, NIS or NIS+ accounts to eDirectory.

Use This Configuration File:	When You Want To:
namutils.inp	store default values for the various parameters of the nam utilities. This file is created in /var/nam when you run one of the nam utilities (except namuserlist and namgrouplist). Once created, you can modify this file to reduce the number of manually entered parameters required when using these utilities.
unix2edir.inp	store default values for the various parameters of the unix2edir utility. This file is created in /var/nam when you run unix2edir. Once created, you can modify this file to reduce the number of manually entered parameters required when using this utility.

More information on each of these utilities is available by accessing the man page for the respective utility.

Authentication with LUM

After LUM is configured with valid LUM users and groups and after Linux services are integrated into LUM, the authentication process a user experiences with LUM can finally be investigated.

LUM is specifically designed to take advantage of the Pluggable Authentication Module (PAM) infrastructure common with Linux servers. The primary benefit this offers is that all PAM-aware services have the potential to be integrated into eDirectory through LUM with relative ease. This section describes the integration steps and processes of authentication with a PAM-aware service.

Note: It is possible to enable LDAP-aware services to integrate directly with eDirectory, but this configuration is specific to the application being integrated and beyond the scope of this book.

Pam integration with LUM

As mentioned in the Login Process section of Chapter 3, PAM utilizes a configuration file for every PAM-aware service. These files exist in the /etc/pam.d directory and are named after the respective service. The contents of these files are used to determine what modules are involved with the authentication process to ensure the user is allowed access.

As shown in Figure 8.12, the pam_nam module is used for all authentication services. The control flag used with these services is normally set to "sufficient." This causes the authentication process to halt upon successfully retrieving auth, account and password information from the pam_nam module.

Figure 8.12

If pam_nam is unable to fulfill the request, the remainder of the configuration file is used. This allows local accounts to authenticate after checking for the requested account in eDirectory. Make sure the service configuration file allows for local authentication for root level access for administrators.

The pam_nam module relies on the /etc/nam.conf configuration file. This file contains information regarding the IP address of the eDirectory server, what credentials to use when authenticating to that server, and where in the eDirectory tree to search for LUM users and groups.

Note: For more information regarding the nam.conf configuration file, refer to the man page, or the online Novell documentation.

File System Permissions

With knowledge of the file system layout and the commands required to navigate that file system, only one thing could possibly stop you-permissions.

Permissions on files and directories in Linux can be viewed using a long file listing (ls -l). The output of this command will look similar to Figure 3.10.

Figure 3.10

Long file listings display the permissions on a file or directory on the far left side of each entry. This field is known as the "mode" of the file and consists of ten specific bits. The first bit is used to indicate the type of file being viewed. Possible file type values are listed in Table 3.14.

Table 3.14 Possible File Types

Type Designation	Description
-	Normal file
d	Directory
l	Symbolic link
c	Character device
b	Block device
p	Named pipe
s	Socket

The remaining nine bits represent the permissions on the specified file, as shown in Figure 3.11. These bits are logically divided into three groups of three bits each. The first set of three bits represents the permissions that the owner of the file has. (The owner is displayed as the third field in a long directory listing with ls.)

Figure 3.11

The second set of three bits represents the permissions assigned to the group owner of the specified file. (The group owner is displayed as the fourth field in a long directory listing with ls.) All members of the specified group receive the designated rights to the file.

The final set of three bits represents permissions that all other users receive to the specified file.

Note: Permissions on Linux are not cumulative. File owners receive just the permissions assigned to the owner-even if the owner is also a member of the group designated as the group owner. Likewise, members of the group owner receive only those rights-even if the "other" rights are more permissive.

Each of these sets of three bits all represent the same set of three rights-read, write and execute. These permissions behave differently based on whether they are set on a file or a directory. Table 3.15 describes the difference in these permissions.

Table 3.15 Permission Differences Between Files and Directories

Permission	Meaning on Files	Meaning on Directories
-	Normal file
Permission	Meaning on Files	Meaning on Directories
r (read)	The ability to read or view the specified file.	The ability to view contents within a directory. This ability requires the execute permission to be set as well.
w (write)	The ability to modify or write to the specified file.	The ability to create and delete files within a directory. This ability requires the execute permission to be set as well.
x (execute)	The ability to execute the file (required for script and binary program execution).	The ability to work within a specified directory.

Setting Permissions and Ownership

The chown utility can be used to change the owner and group owner of files and directories. When using chown, specify the new user and group owners followed by the file or directory. The user and group names are separated with a period. An example of this is as follows:

chown jdoe.users /tmp/tmpfile

Use the chmod utility to change permissions on a file or directory using two different methods. The first method is by use of symbolic representation of permission assignments. This requires identifying which set of permissions you are changing, what permissions you are assigning and an operator that determines whether rights are being added or subtracted. Table 3.16 lists possible values for these three fields.

Table 3.16 Common Symbolic Parameters for chmod

Category	Operator	Permissions
u (user)	+ (add permissions)	r (read)
g (group)	- (subtract permissions)	w (write)
o (other)	= (set permissions equal to designated values)	x (execute)
a (all)

Using the symbolic method, multiple permissions can be set by separating each setting with a comma. The following example demonstrates this:

chown u+a,o+r /tmp/tmpfile

You can change permissions another way with chmod by using an octal number representation of the desired permissions. This is important to understand because it's quite common.

In an octal interpretation of permissions, each right is assigned a number. The read permission is assigned a value of 4, write is assigned a value of 2 and execute is assigned a value of 1. These numeric assignments are used for all three sets of permissions as shown in Figure 3.12.

Figure 3.12

To assign permissions using the octal method, add up the value of each set permission bit in each category (user, group and other). Each category will range from 0 to 7. After each category has been calculated, use chmod as follows:

chmod 750 /tmp/testfs.sh

In the preceding example, all permissions (rwx) are assigned to the user category, read and execute (r-x) are assigned to the group, and no permissions (---) are assigned to the other category.

Note: Using octal notation, every category must be explicitly entered. Entered values are right justified with zeros substituted for missing values.

Special Permissions

In addition to the normal permissions, you might encounter three special permissions. These permissions are:

Set User ID (SUID)-The SUID bit is used on executables to modify the permissions allowed to the running process. When you run an executable with the SUID bit, the running process inherits the permissions of the owner of the executable rather than the permissions of the user who launched the program. This is useful when a running process should have more rights than a normal user is typically provided.
Set Group ID (SGID)-The SGID bit performs two functions: The first is similar to the SUID bit. An executable with the SGID bit set inherits the permissions of the group owner when running rather than the group permissions of the user who started the process. The second function the SGID bit performs is only valid on directories. With the SGID bit set on a directory, all newly created files within that directory automatically receive the same group owner as the group owner of the directory. This overrides the default assignment of each file receiving a group owner set to the individual user's primary group.
Sticky Bit-The Sticky Bit is only valid on directories. When the Sticky Bit is set on a directory, users are only allowed to delete files they own. Without this setting, users are allowed to delete files owned by other users as long as they have the write (w) permission on the directory. Special permissions are stored as part of the regular mode of the file, but there is no room for three more permission bits for these permissions. Because of this, special permissions are actually included within the execute (x) bit of user, group and other permissions. Figure 3.13 and Figure 3.14 demonstrate how these permissions are displayed when the corresponding execute bit is set and not set, respectively.

Figure 3.13

Figure 3.14

Even though special permissions are displayed as part of the normal mode of the file, setting special permissions is done through the use of one more permissions category with the octal mode of chmod. With this category, SUID is assigned a value of 4, SGID a value of 2 and the Sticky Bit a value of 1. You can set these permissions as follows:

chmod 3775 /data/sales

For more information on permissions and the chmod command, see man 1 chmod.

More Than One LUM? You Decide.

A LUM Domain is simply a term used to describe one Linux Config object and all users and workstations associated with that object. By default, one Linux Config object and therefore one LUM Domain, is created during the installation of LUM. Into this one LUM Domain, additional Linux servers and workstations can be added using the namconfig utility.

If your network spans multiple sites, or LUM services will be offered to a large number of users, additional Linux Config objects (and therefore additional LUM Domains) can be created.

The namconfig utility is the only tool that can create Linux Config objects in eDirectory. When creating multiple Linux Config objects, ensure all LUM domains exist in their own eDirectory partition. Also, because of the subtree LDAP search used with LUM, ensure no LUM domain exists beneath another LUM domain in the eDirectory tree.

* Originally published in Novell Connection Magazine

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.