16.2 Linux User Management: Access to Linux for eDirectory Users

Users and groups on NetWare servers are created in and managed through eDirectory; users and groups on Linux servers are usually created locally and managed according to the POSIX (Portable Operating System Interface) standard.

Because Open Enterprise Server provides services running on both Linux and NetWare, Novell has developed a technology that lets eDirectory users also function as “local” POSIX users on Linux servers. This technology is called Linux User Management or LUM.

The following sections outline the basic principles involved in Novell LUM and cover the following topics:

16.2.1 Overview

The topics in this section are designed to help you understand when LUM-enabled access is required so that your network services are accessible and work as expected. For more information about Linux User Management, see Overview in the OES 2 SP3: Novell Linux User Management Administration Guide.

A Graphical Preview of Linux User Management

Figure 16-1 illustrates how Linux User Management controls access to the OES 2 server.

Figure 16-1 LUM Provides POSIX Access for eDirectory Users

The following table explains the information presented in Figure 16-1.

Table 16-1 Linux User Management

Valid POSIX Users

Authentication

eDirectory Authenticated Services

Some services on OES 2 servers must be accessed by POSIX users.

eDirectory users can function as POSIX users if they are enabled for Linux access (LUM).

When the system receives an action request, it can authenticate both local POSIX users and users who have been enabled for Linux access.

Users can potentially access PAM-enabled services, Samba shares, and Novell Remote Manager as either local or eDirectory users.

By default, only the openwbem command (required for server management) is enabled for eDirectory access.

Linux Requires POSIX Users

Linux requires that all users be defined by standard POSIX attributes, such as username, user ID (UID), primary group ID (GID), password, and other similar attributes.

Linux Users Can Be Local or Remote

Users that access a Linux server can be created in two ways:

  • Locally (on the server): Local users are managed at a command prompt (using commands such as useradd) or in YaST. (See the useradd(8) man page and the YaST online help for more information.) These local users are stored in the /etc/passwd file. (See the passwd(5) man page for more information.)

    IMPORTANT:As a general rule on OES 2 servers, the only local user account that should exist is root. All other user accounts should be created in eDirectory and then be enabled for Linux access (LUM). You should never create duplicate local and eDirectory user accounts.

    For more information, see Section 7.2, Avoiding POSIX and eDirectory Duplications.

  • Remotely (off the server): Remote users can be managed by other systems, such as LDAP-compliant directory services. Remote user access is enabled through the Pluggable Authentication Module (PAM) architecture on Linux.

The Linux POSIX-compliant interfaces can authenticate both kinds of users, independent of where they are stored and how they are managed.

The root User Is Never LUM-Enabled

The OES 2 user management tools prevent you from creating an eDirectory user named root, thus replacing the root user on an OES 2 server. If root were to be a LUM user and eDirectory became unavailable for some reason, there would be no root access to the system.

Even if eDirectory is not available, you can still log into the server through Novell Remote Manager and perform other system management tasks as the root user.

About Service Access on OES 2

Novell Linux User Management (LUM) lets you use eDirectory to centrally manage remote users for access to one or more OES 2 servers.

In other words, LUM lets eDirectory users function as local (POSIX) users on an OES 2 server. Access is enabled by leveraging the Linux Pluggable Authentication Module (PAM) architecture. PAM makes it possible for eDirectory users to authenticate with the OES 2 server through LDAP.

In OES, the terms LUM-enabling and Linux-enabling are both used to describe the process that adds standard Linux (POSIX) attributes and values to eDirectory users and groups, thus enabling them to function as POSIX users and groups on the server.

You can use iManager to enable eDirectory users for Linux. For instructions, see About Enabling eDirectory Users for Linux Access.

Services in OES 2 That Require LUM-Enabled Access

Some services on an OES 2 server require that eDirectory users be LUM-enabled:

  • Novell Samba (CIFS) Shares on the Server: Windows workgroup users who need access to Samba shares defined on the server must be LUM-enabled eDirectory users who are configured to access the server. This is because Samba requires POSIX identification for access.

    By extension, NetStorage users who need access to Samba (CIFS) Storage Location objects that point to the server must also be LUM-enabled eDirectory users with access to the server.

    NOTE:Although Samba users must be enabled for LUM, Samba is not a PAM-enabled service. Logging in to the OES 2 server through Samba does not create a home directory.

  • Core Linux Utilities Enabled for LUM: These are the core utilities and other shell commands that you can specify during the OES install to be enabled for authentication through eDirectory LDAP. In Linux, these are known as PAM-enabled utilities.

    IMPORTANT:Before you accept the default PAM-enabled service settings, be sure you understand the security implications explained in Section 22.2.2, User Restrictions: Some OES 2 Limitations.

    The core utilities available for LUM-enablement are summarized in Table 16-2.

    Table 16-2 PAM-enabled Services Controlled by LUM

    Command

    Where Executed

    Task

    ftp

    Another host

    Transfer files to and from the OES 2 server which, in this case, is a remote host.

    login

    • OES 2 server

    • SSH session with OES 2 server

    Log in to the OES 2 server, either directly or in an SSH session with the server.

    openwbem

    Local host

    Required for iPrint, NSS, SMS, Novell Remote Manager, and iManager.

    gdm

    • Local host

    • Remote host

    Run and manage the X servers using XDMCP.

    gnomesu-pam

    Local host

    Required for GNOME applications that need superuser access.

    sshd

    Another host

    Establish a secure encrypted connection with the OES 2 server which, in this case, is a remote host.

    su

    • OES 2 server

    • SSH session with OES 2 server

    Temporarily become another user.

    This is most often used to temporarily become the root user, who is not a LUM user and is, therefore, not affected by LUM.

    NOTE:Logging in to the OES 2 server through a PAM-enabled service for the first time causes the creation of a home directory on the server.

  • Novell Remote Manager on Linux: You can access Novell Remote Manager as the following:

    • The root user with rights to see everything on the Linux server.

    • A local Linux user with access governed by POSIX access rights. (Having local users in addition to root is not recommended on OES 2 servers.)

    • A LUM-enabled eDirectory user, such as the Admin user created during the install.

  • Novell Storage Management Services (SMS) on Linux: You can access SMS utilities as

    • The root user with rights to see everything on the Linux server.

    • A local Linux user with access governed by POSIX access rights. (Having local users in addition to root is not recommended on OES 2 servers.)

    • A LUM-enabled eDirectory user, such as the Admin user created during the install.

Services That Do Not Require LUM-Enabled Access But Have Some LUM Requirements

Some services do not require eDirectory users to be LUM-enabled for service access:

  • NetStorage: NetStorage users don’t generally need to be LUM-enabled. However, salvaging and purging files through NetStorage on an NSS volume can only be done by users who are enabled for Linux.

    IMPORTANT:Files that are uploaded by non-LUM users via NetStorage are owned, from a POSIX perspective, by the root user. The assumption is that such users are accessing their data on NSS or NCP volumes by using an NCP storage location object. In both cases, the Novell Trustee Model applies and POSIX ownership is irrelevant.

    If non-LUM NetStorage users are later enabled for Samba access (which includes LUM-enabling) and begin using Samba as a file service, their NetStorage uploaded files are not accessible through Samba until you change POSIX file ownership. Although the Novell implementation of Samba leverages eDirectory for authentication, Samba file and directory access is always controlled by POSIX. The Novell Trustee Model doesn’t apply to Samba.

    Both Novell trustee assignments and POSIX file ownership are tracked correctly after users are LUM-enabled.

    Although NetStorage doesn’t require LUM-enabled access, the service itself runs as a POSIX-compliant system User (initially a local user on the OES 2 server) who functions on behalf of the end users that are accessing the service.

    If NetStorage must access NSS volumes, this local system user must be moved to eDirectory and LUM-enabled because only eDirectory users can access NSS volumes. The OES 2 installation program configures this correctly by default.

    For more information, see Section I.0, System User and Group Management in OES 2 SP3.

  • NSS: eDirectory users that access NSS volumes directly through NCP (the Novell Client) are not required to be LUM-enabled.

    However, because Novell Samba accesses NSS through the virtual file system layer that makes NSS appear to be a POSIX-compliant file system, Samba users must be LUM–enabled to access an NSS volume.

Services That Do Not Require LUM-enabled Access

The following end user services do not require LUM-enabled access:

  • iFolder 3.8

  • iPrint

  • NCP Client to an NCP Volume

  • NCP Client to an NSS Volume

  • Novell AFP

  • Novell CIFS

  • QuickFinder

LUM-Enabling Does Not Provide Global Access to ALL OES 2 Servers

As you plan to LUM-enable users for access to the services that require it, keep in mind that each OES 2 server being accessed must be associated with a LUM-enabled group that the accessing users belong to.

In other words, it is not sufficient to LUM-enable users for access to a single OES 2 server if they need access to multiple servers. An association between the LUM-enabled groups that the users belong to and the eDirectory UNIX Workstation object associated with the server must be formed by using iManager for each server the users need access to. This can be accomplished for multiple servers by using the process described in Enabling Users to Access Multiple OES 2 Servers.

For more information on LUM, see the OES 2 SP3: Novell Linux User Management Administration Guide.

16.2.2 LUM Changes in SP3

In reponse to customer requests for improved LDAP performance, persistent searching for new Linux-enabled users and groups has been disabled in OES 2 SP3.

For more information, see Section 7.11, LUM Cache Refresh No Longer Persistent and What’s New in the OES 2 SP3: Novell Linux User Management Administration Guide.

16.2.3 Planning

The following sections summarize LUM planning considerations.

eDirectory Admin User Is Automatically Enabled for Linux Access

When you install Linux User Management on an OES 2 server, the Admin User object that installs LUM is automatically enabled for eDirectory LDAP authentication to the server.

Planning Which Users to Enable for Access

You need to identify the eDirectory users (and groups) who need access to services on OES 2 servers that require LUM-enabled users.

This can be easily determined by doing the following:

  1. Review the information in Services in OES 2 That Require LUM-Enabled Access.

  2. Identify the servers that will run the services mentioned.

  3. On your planning sheets, note the users and groups that you need to enable and the servers you need to enable them to access.

Be Aware of System-Created Users and Groups

You should also be aware of the system-created users and groups that are LUM-enabled when NSS is installed. For more information, see Section I.0, System User and Group Management in OES 2 SP3.

16.2.4 LUM Implementation Suggestions

The following sections summarize LUM implementation considerations.

About Enabling eDirectory Users for Linux Access

You can enable eDirectory users for Linux User Management by using either iManager 2.7 or the nambulkadd command.

  • iManager: You can enable existing eDirectory users for Linux access by using the Linux User Management tasks in iManager.

    You can enable multiple users in the same operation as long as they can be assigned to the same primary LUM-enabled group. The enabling process lets you associate the group with one or more OES 2 servers or Linux workstations. For more information, see Enabling Users to Access Multiple OES 2 Servers.

    Samba users are also enabled for Linux access as part of the Samba-enabling process.

UNIX Workstation and Linux Workstation Are the Same Thing

When you use iManager to manage OES 2 access, you might notice some inconsistencies in naming.

When OES 2 servers are created, a UNIX Workstation - server_name object is created in eDirectory, where server_name is the DNS name of the OES 2 server. In some places the iManager help refers to these server objects as Linux Workstation objects.

Both UNIX Workstation and Linux Workstation refer to the same eDirectory objects.

Enabling Users to Access Multiple OES 2 Servers

IMPORTANT:Users gain server access through their LUM-enabled group assignment rather than through a direct assignment to the UNIX Workstation objects themselves.

You can enable users for access to multiple OES 2 servers by associating the LUM-enabled groups to which the users belong with the UNIX Workstation objects you want users to have access to.

Enabling eDirectory Groups for Linux Access

There are two methods for enabling eDirectory groups for Linux access:

Using iManager

The following steps assume that the eDirectory Group objects already exist and that any User objects you want to enable for Linux also exist and have been assigned to the groups.

  1. Log in to iManager as the eDirectory Admin user or equivalent.

  2. Click Linux User Management > Enable Groups for Linux.

  3. Browse to and select one or more Group objects, then click OK.

  4. If you want all users assigned to the group to be enabled for Linux, make sure the Linux-Enable All Users in These Groups option is selected.

  5. Click Next twice.

  6. Browse to and select one or more UNIX Workstation (OES 2 server) objects, then click OK.

  7. Click Next, click Finish, then click OK.

Using LUM Utilities at the Command Prompt

Novell Linux User Management includes utilities for creating new LUM-enabled groups, and for enabling existing eDirectory groups for Linux access.

Enabling eDirectory Users for Linux Access

There are two methods for enabling eDirectory users for Linux access:

Using iManager

The following steps assume that the eDirectory User objects already exist.

  1. Log in to iManager as the eDirectory Admin user or equivalent.

  2. Click Linux User Management > Enable Users for Linux.

  3. Browse to and select one or more User objects, then click OK.

  4. Click Next.

  5. As indicated, you can do the following:

    • Select and enable an existing eDirectory group for Linux.

    • Select an eDirectory group that is already enabled for Linux.

    • Specify the name and context of a new eDirectory group to create and enable for Linux.

    Select the option that matches your requirements.

  6. Click Next.

  7. Browse to and select one or more UNIX Workstation (OES 2 server) objects, then click OK.

  8. Click Next, click Finish, then click OK.

Using LUM Utilities at the Command Prompt

Novell Linux User Management includes utilities for creating new LUM-enabled users, and for enabling existing eDirectory users for Linux access.