13.2 Linux User Management: Access to Linux for eDirectory Users

NOTE:Beginning with OES 2015, a new service named the Novell Identity Translator (NIT) is introduced, which is associated with the Linux User Management.

NIT represents a new approach to the service that LUM provides and works seamlessly with LUM to provide access to CIFS.

For more information about NIT, see NIT (Novell Identity Translator) in the OES 2023: NSS AD Administration Guide.

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, OES 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 OES LUM and cover the following topics:

13.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 2023: Linux User Management Administration Guide.

A Graphical Preview of Linux User Management

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

Figure 13-1 LUM Provides POSIX Access for eDirectory Users

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

Table 13-1 Linux User Management

Valid POSIX Users	Authentication	eDirectory Authenticated Services
Some services on OES 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 OES Remote Manager as either local or eDirectory users. By default, only the sfcb command (required for server management) is enabled for eDirectory access.

Valid POSIX Users

Authentication

eDirectory Authenticated Services

Some services on OES 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 OES Remote Manager as either local or eDirectory users.

By default, only the sfcb 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 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.
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 user management tools prevent you from creating an eDirectory user named root, thus replacing the root user on an OES 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 OES Remote Manager and perform other system management tasks as the root user.

About Service Access on OES

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

In other words, LUM lets eDirectory users function as local (POSIX) users on an OES 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 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.

OES Services That Require LUM-Enabled Access

Some services on an OES server require that eDirectory users be LUM-enabled to use them:

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 or services.

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

The core utilities available for PAM-enablement are summarized in Table 13-2.

Table 13-2 PAM-enabled Services Controlled by LUM

Command	Where Executed	Task
ftp	Another host	Transfer files to and from the OES server which, in this case, is a remote host.
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.
login	OES server SSH session with OES server	Log in to the OES server, either directly or in an SSH session with the server.
sfcb	Local host	Required for iPrint, NSS, SMS, OES Remote Manager, and iManager.
sshd	Another host	Establish a secure encrypted connection with the OES server which, in this case, is a remote host.
su	OES server SSH session with OES 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 server through a PAM-enabled service for the first time causes the creation of a home directory in /home on the server.

Novell Remote Manager on Linux: You can access OES 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 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, who has rights to see everything on the Linux server, including NSS volumes.
- A local Linux user with access governed by POSIX access rights. (Having local users in addition to root is not recommended on OES servers.)
- A LUM-enabled eDirectory user, such as the Admin user created during the install.

OES 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:

NSS: eDirectory users that access NSS volumes directly through NCP (the Client for Open Enterprise Server) are not required to be LUM-enabled.

OES Services That Do Not Require LUM-enabled Access

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

iPrint
NCP Client to an NCP Volume
NCP Client to an NSS Volume
CIFS

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

As you plan to LUM-enable users for access to the services that require it, keep in mind that each OES 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 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 each server must be formed by using iManager. This can be accomplished for multiple servers by using the process described in Enabling eDirectory Groups and Users for Linux Access.

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

LUM-Enabling Required for Full Administrative Access

The current LUM architecture requires that administrators, administrator equivalents, partition administrators, and RBS-enabled managers be LUM-enabled to have full management capabilities.

13.2.2 LUM Changes

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

13.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 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 servers that require LUM-enabled users.

This can be easily determined by doing the following:

Review the information in OES Services That Require LUM-Enabled Access.
Identify the servers that will run the services mentioned.
Note the users and groups that need access and then configure their objects and the target servers/services for that 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 J.0, System User and Group Management in OES.

13.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 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 also lets you associate the group with one or more OES servers or Linux workstations.

nambulkadd: If you have eDirectory users and groups that need to be enabled for Linux access, you can use the nambulkadd command to modify multiple objects simultaneously. For more information, see the OES 2023: Linux User Management Administration Guide.

UNIX Workstation and Linux Workstation Are the Same Thing

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

When OES servers are created, a UNIX Workstation - server_name object is created in eDirectory, where server_name is the DNS name of the OES 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 eDirectory Groups and Users for Linux Access

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 servers by associating the LUM-enabled groups to which the users belong with the UNIX Workstation objects you want users to have access to.

There are four methods for enabling eDirectory groups and users for Linux access:

Using iManager to Enable Groups and any Users Assigned to Them

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

Log in to iManager as the eDirectory Admin user or equivalent.
Click Linux User Management > Enable Groups for Linux.
Browse to and select one or more Group objects, then click OK.
If you want all users assigned to the groups to be enabled for Linux, make sure the Linux-Enable All Users in These Groups option is selected.
Click Next.
If the groups contain users, click Next to confirm that you want them enabled.
Browse to and select a UNIX Workstation (OES server) object, then click OK.
Browse to and select the Unix Config Object for the workstation, then click OK.
Click Next, click Finish, then click OK.

Using iManager to Bulk-Enable Users in a LUM Group

The following steps assume that the eDirectory LUM-enabled Group objects already exist and that they have assigned non-LUM-enabled User objects that you want to enable for Linux access.

Log in to iManager as the eDirectory Admin user or equivalent.
Click Linux User Management > Bulk-Enable Users in a LUM Group.
Browse to and select one or more LUM-enabled Group objects, then click OK.
Browse to and select the Unix Config Object, then click OK.
Click Next.
Click Finish to confirm that you want the listed users enabled for Linux.
Click OK.

Using iManager to Bulk-Enable Users in a Container

The following steps assume that eDirectory non-LUM-enabled User objects exist inside an eDirectory container (OU object) and that you want to enable these User objects for Linux access.

Log in to iManager as the eDirectory Admin user or equivalent.
Click Linux User Management > Bulk-Enable Users in a Container.
Browse to and select the Container (OU) object, then click OK.
Browse to and select the Unix Config Object, then click OK.
Browse to and select the LUM-enabled group that you want the users associated with for Linux access.
Click Next.
Observe that all user objects in the container are listed for assignment to the group you have selected as the primary group. If you don’t want already enabled user objects that are currently assigned to a different primary group to have that assignment changed, you must deselect them at this point.
Click Finish to confirm that you want the selected users enabled for Linux (if not already) and assigned to the select group.
Click OK.

Using LUM Utilities at the Command Prompt

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

The nambulkadd utility lets you use a text editor to create a list of groups you want enabled for Linux access. For more information, see nambulkadd in the OES 2023: Linux User Management Administration Guide.

IMPORTANT:Be sure to include a blank line at the end of each text file. Otherwise, the last line of the file won’t be processed properly.
The namgroupadd utility lets you create a new LUM-enabled group or enable an existing eDirectory group for Linux access. For more information, see namgroupadd in the OES 2023: Linux User Management Administration Guide.