Novell Certified Linux Engineer (Novell CLE) Study Guide (Novell Press)

Working with Linux User Management

Test Objective Covered:

2. Access a Linux Server with Linux User Management (LUM).

The LUM component of NNLS serves as the link between the local Linux system and eDirectory. LUM represents a huge leap forward in eDirectory technology.

eDirectory was actually ported over to Linux in 1998. I remember when the first version became available for beta testing. I went to a training session in a room packed with Linux administrators. All of us were waiting with baited breath to see eDirectory on our favorite platform.

We all proceeded through the install portion of the class without incident. Shortly after that, things started to go wrong. The product itself worked fine ”it was the way it worked that caused consternation.

As you probably know, Linux administrators tend to have an inquisitive nature. In accordance, after the install portion of the class, most of the students were off experimenting and tinkering with the eDirectory service instead of listening to the instructor (he wasn't terribly interesting to listen to anyway).

As a result of this tinkering, all of us realized in a moment of group collective consciousness that the eDirectory and Linux authentication systems weren't connected to each other in any way. Because of our past experience with NetWare, we were fully expecting to be able to use eDirectory to authenticate Linux users. Instead, we found that Linux users were still being managed with the passwd, shadow, and group files. eDirectory and Linux were in no way connected.

To authenticate to eDirectory, you had to log in using the Novell Client from a Windows or DOS workstation. To log in to the Linux server, you had to authenticate from the login prompt at the server console. Essentially, eDirectory used Linux as a platform to run on and wasn't used to actually manage the server itself.

Needless to say, all the students in the class were very disappointed and called the instructor's attention to this issue. He looked at us in a funny way and said something to the effect of, "Well, of course it doesn't," as if we were expecting the impossible . Thankfully, Novell realized this fact and included LUM in NNLS.

Note

Novell actually started working on this problem prior to NNLS. LUM descends from Novell's Account Management product line. Having used both, LUM is considerably easier to use and works much more reliably.

LUM makes eDirectory do exactly what we were expecting it to do back in 1998: tt redirects authentication to the Linux system through eDirectory. Linux users can authenticate to the system without an entry being required in the passwd file.

This alone makes eDirectory worth its while on the Linux platform. Recall in Chapter 4, "Introduction to Novell Nterprise Linux Services (NNLS)," that we discussed the administrative challenge presented by synchronizing Linux user and group accounts on multiple servers. Previously, you had two options for this problem:

• You could synchronize accounts manually. In a very large network, this could be a daunting task.

• You could implement NIS+. NIS+ is an Open Source service that synchronizes accounts between Linux systems.

Either way, it wasn't an easy task.

Using eDirectory to manage your Linux user accounts makes life much easier for the administrator. Instead of trying to synchronize accounts among multiple systems, eDirectory serves as a central repository for all network information.

Tip

It's important that you understand that eDirectory doesn't synchronize user accounts.

With eDirectory, you only need a single user account for every user in your organization. You assign rights to the single user account to control what resources the user can and cannot use.

Recall when we installed NNLS in the previous chapter. We configured NNLS to redirect authentication for PAM-enabled services. PAM stands for Pluggable Authentication Modules . PAM uses a series of shared library files to create a modular authentication system. It allows the administrator to customize the authentication mechanism a particular service, such as login or ftp, uses.

Linux services such as ftp, login, and so on have been redirected to use eDirectory user accounts instead of the user accounts in the passwd file. This is particularly useful when implementing Samba. We'll discuss this topic in more depth in a later chapter.

How LUM Works with eDirectory

When LUM is installed, it extends the eDirectory schema (if you're new to eDirectory, you may not know what this means). Recall in Chapter 5, "NNLS Installation and Administration," that I said the eDirectory schema defines objects that are allowed in the tree, defines the attributes they have, and specifies containment rules.

The base schema installed when you implemented NNLS isn't static. You can add, delete, or modify object classes and attributes in your tree. LUM does exactly this when it is installed. It extends the schema and adds LUM-specific attributes to the default user, group, and template object classes. As you can see in Figure 6.11, the user object receives a new property page called Linux Profile .

The following attributes are added to the user object:

• User ID

• Primary Group ID

• Primary Group Name

• Login Shell

• Home Directory

• Comments

In Figure 6.12, you can see that the group object class also has a new property page named Linux Profile.

Group objects have the following attributes added:

• Group ID

• uamPosixWorkstationList

• Description

• memberUid

LUM also extends the schema to add two new types of objects to the tree, as listed in Table 6.1.

Table 6.1. LUM eDirectory Objects

Installing LUM also adds the components listed in Table 6.2 to your system.

Table 6.2. LUM Components

These new objects and modules play a critical role in LUM. One of the issues encountered when redirecting to eDirectory is that of context. Recall that eDirectory uses a hierarchical database structure. Objects are referenced by their username and their context (for example, DCoughanour.SLC.CLE).

The Linux passwd file, on the other hand, is a flat file. User accounts are not arranged into a hierarchy.

This brings up a new problem: How do you deal with the issue of context in a system that previously had no notion of the concept? To fix this problem, LUM provides Linux users with an authentication process called contextless login , which is just what it sounds like. Users can log in to the Linux system using a typical Linux username.

The LUM nss_nam.so module resolves the contextless user name provided by the user during login to the particular system's workstation object in the eDirectory tree. This object is shown in Figure 6.13.

The workstation object contains a list of all the groups that have been given access to the Linux system. This is shown in Figure 6.14.

Only users who are members of these groups are allowed to authenticate to the Linux system. In Figure 6.14, only users who are members of the IFEmployees.IF.CLE group or the SLCEmployees.SLC.CLE group are allowed to authenticate to the CLE1 Linux system.

The username supplied by the user is compared with the usernames in the associated LUM groups. If a match is found, the user is authenticated and his or her Linux profile is used to configure the system environment.

Let's look at this redirection process in greater detail.

How LUM Redirection Works

LUM redirection is based on the Name Service Switch (NSS) component integrated into Linux. NSS allows you to configure how you want authentication to occur in the system. The NSS configuration is controlled by the /etc/nsswitch.conf file.

When you install LUM, the NNLS installation script modifies the nsswitch.conf file. This modified file is shown in Figure 6.15.

Notice that the parameters for passwd, shadow, and group have been modified with the addition of the string nam . With the system configured in the way shown in Figure 6.15, it will first look in the passwd file for the user during login. This is configured by the files directive.

If not found there, it will next use eDirectory for authentication. This is configured by the nam directive. This system is configured to use NIS+ after eDirectory (if we actually had it installed on the system). This is configured by the nisplus directive.

The installation script also modifies the PAM files in the /etc/pam.d directory for services such as login, ftp, and ssh to use eDirectory for authentication. The modified file for the login service is shown in Figure 6.16.

Notice in Figure 6.16 that login has been configured to use the LUM pam_nam.so module. This module redirects authentication requests to the nss_name.so module.

When the nss_nam.so module receives a request, it contacts the LUM daemon, namcd . This service retrieves and caches information from your eDirectory tree. If the username of the user authenticating is already in the daemon's cache, it will return the distinguished name (which is the object name and its context) of the associated user object. Otherwise, it queries eDirectory for the information, returns the distinguished name, and stores the information in its cache.

The namcd daemon can be configured using the /etc/nam.conf configuration file or by running the namconfig utility. A typical nam.conf file is shown in Figure 6.17.

The parameters in this file are explained in Table 6.3.

Table 6.3. The namcd Configuration Parameters

As you can see from Figure 6.17, the NNLS installation script automatically configures your system, and usually very little additional configuration is needed ” assuming you entered the correct information.

Let's now look at how you enable LUM functionality on your system.

Setting Up LUM

LUM is a highly flexible product, allowing you to configure your system in a variety of different ways. For the CLE certification, you only need to know how to perform a basic configuration, and that is what we will focus on here.

To perform a basic configuration of LUM on your system, you would do the following steps:

Note

This is a set of generic steps. We'll go through a detailed set of steps in the upcoming lab exercise.

1. In a web browser, navigate to https :// your_server's_IP_address /nps/iManager.html.

2. Authenticate to iManager as the admin user.

3. Create groups for LUM access. You can create one single group or multiple groups. To do so, complete the following steps:

   1. In iManager, scroll down to the eDirectory Administration role and select Create Object .

   2. In the Available Object Classes field, select Group and then click OK .

   3. In the Group Name field, enter a name for your group.

   4. In the Context field, enter the context where you want the group to reside and then click OK .

   5. When prompted that the group has been created, click OK .

   6. When prompted to convert the group to a LUM group, click Cancel . You'll convert the group at a later point.

4. Populate the new group with the users you want to be able to authenticate to the Linux system using eDirectory by completing the following steps:

   1. In iManager, select Modify Object .

   2. In the Object Name field, enter the name of your group.

   3. In the drop-down list, select Members .

   4. In the Members field, browse to and select each user object you want in the group.

   5. Click OK .

5. Convert the group to a LUM group by completing the following steps:

   1. In the left frame, scroll down to the Linux User Management role and select Convert eDirectory Group to LUM Group .

   2. In the Select Group field, browse to and select your group and then click OK .

   3. When prompted to select the workstations you want the group added to, select Linux Workstations .

   4. In the Linux Workstations field, browse to and select your UNIX Workstation object and then click OK .

   5. When prompted that the LUM group was created, click OK .

6. Convert each user in the group to a LUM user by completing the following steps:

   1. Under the Linux User Management role, select Convert eDirectory User to LUM User .

   2. In the Select User field, browse to and select the first user in your group and then click OK .

   3. When prompted to specify the primary group for the user, browse to and select your group.

   4. Deselect the option to convert the user to a Samba user object; then click OK .

   5. Select Repeat Task .

   6. Repeat these steps for each user in the group.

Test the configuration by completing the following steps:

1. Switch to a shell prompt by pressing Ctrl+Alt+F2 if you are running in a graphical environment. If you are working from the text-based shell prompt without the X Window System, press Alt+F2 .

2. At the login prompt, enter the username of a user object in the converted group. Don't include the context of the object. For example, if you wanted to authenticate as DCoughanour.SLC.CLE, you would simply enter DCoughanour .

3. Supply the user's password at the password prompt. You should see a message indicating that a new home directory is being created in /home for the user.

That's all there is to it! In Lab Exercise 6.2, you can configure LUM on your server.