Views:

Summary



Account information is correct in the node configuration, but browsing the node fails to show local file system resources.

Symptoms



The fbl log file indicates failure to connect to the TSA, showing error:

fffdffdd from NWSMTConnectToTargetService



Resolution



The symptom described here is related to OES Linux using two different authentication mechanisms. If the user account is local to the node, in other words a user account was locally created, then the account will be automatically added to both authentication mechanisms. If the user account is maintained remotely in eDirectory, the two authentication mechanisms are enabled independently for the account and are not automatically kept in sync. The two authentication mechanisms cover the normal Netware oriented objects such as NSS and eDirDB resources in one case, and the Linux oriented (POSIX) objects such as the root file system for the other case.

Although the user account may have proper permissions for accessing a Netware node, an OES Linux node requires the user account to be "Linux Enabled" in order to provide access to POSIX authentication. Local user accounts on the machine automatically have POSIX access, but remote user accounts being managed from eDirectory will not have access by default. A typical scenario would be the addition of OES Linux nodes to an existing enterprise which already has a populated eDirectory containing user accounts that are not "Linux Enabled".

You can follow this link to Novell's description of this:

www.novell.com/documentation/oes/index.html?page=/documentation/oes/implgde/data/lum-overview.html

Here is an excerpt from the referenced page summarizing the key points:

 

Overview

The topics in this section are designed to help you understand when Linux-enabled access is required so that your network services are accessible and work as expected.

Linux Requires POSIX Users

Linux requires that all users be defined using 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

  • Locally (on the server): Local users are managed at a shell 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.)
  • 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.

About Service Access on OES Linux

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

Said another way, LUM lets eDirectory users function as local (POSIX) users on an OES Linux 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 Linux 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.

Linux Access Is Not Global Access to OES Linux Servers

As you plan to Linux enable users for access to these services, keep in mind that each OES Linux server that Linux-enabled users need to access must be associated with a Linux-enabled group that the users belong to.

In other words, it is not sufficient to Linux-enable users for access to a single OES Linux server if they need access to multiple servers. An association between the Linux-enabled group that the users belong to and the eDirectory UNIX* Workstation object associated with the server must be formed using iManager for each server the users need access to.

For more information on LUM, see the Novell Linux User Management Technology Guide.