14.1 Controlling Access to Services

IMPORTANT:With NSS-AD integration in OES 2015, OES CIFS supports Kerberos authentication for Active Directory users accessing NSS volumes. For more information, see the OES 2018 SP2: NSS AD Administration Guide.

OES supports a number of options for service access, including:

Web browsers.
File managers and applications on Linux, Macintosh, and Windows workstations.
Client for Open Enterprise Server software.
Personal digital assistants (PDAs) and other electronic devices that are enabled for Web access.

You control which of these options can be used through the services you offer and the ways you configure those services.

This section can help you understand access control at a high level so that you can plan, implement, and control access to services. More detail about the items discussed is contained in individual service guides.

The topics that follow are:

14.1.1 Overview of Access Control

The following sections present overview of methods for accessing Open Enterprise Server services.

Access to OES Services

Figure 14-1 illustrates the access methods supported by OES services. eDirectory provides authentication to each service.

Figure 14-1 Access Interfaces and the Services They Can Access

The interfaces available for each service are largely determined by the protocols supported by the service.

Browsers and personal digital assistants require support for the HTTP protocol.
Each workstation type has file access protocols associated with it. Linux uses NFS as its native protocol for file services access, Macintosh workstations communicate using AFP or CIFS, and Windows workstations use the CIFS protocol for file services.
Client for Open Enterprise Server uses the NetWare Core Protocol (NCP) to provide the file services.

Understanding the protocol support for OES services can help you begin to plan your OES implementation. For more information, see Matching Protocols and Services to Check Access Requirements.

Access Control Options in OES

Because OES offers both traditional OES access control and POSIX access control, you have a variety of approaches available to you, including combining the two models to serve various aspects of your network services.

Table 14-1 provides links to documentation that discusses OES access control features.

Table 14-1 General File System Access Control

Feature	To Understand	See
Access Control Lists (ACLs) on Linux	How ACLs are supported on the most commonly used Linux POSIX file systems, and how they let you assign file and directory permissions to users and groups who do not own the files or directories.	Access Control Lists in Linux in the SLES Security Guide
Aligning NCP and POSIX access rights	How to approximate the OES access control model on POSIX file systems.	Section 16.4, Aligning NCP and POSIX File Access Rights
Directory and file attributes	Directory and file attributes on NSS volumes.	Understanding Directory and File Attributes for NSS Volumes in the OES 2018: File Systems Management Guide
File system trustee rights	File system trustee rights on NetWare (NSS and traditional volumes), including how file system trustee rights work.	Understanding the OES Trustee Model for File System Access in the OES 2018: File Systems Management Guide
OES trustee rights and directory and file attributes	How to control who can see which files and what they can do with them.	Understanding File System Access Control Using Trustees in the OES 2018: File Systems Management Guide
POSIX file system rights and attributes on Linux	How to configure file system attributes on OES servers.	Access Control Lists in Linux in the SLES Security Guide
Security Equivalence in eDirectory	The concept of Security Equivalence in eDirectory.	Security Equivalence in the OES 2018: File Systems Management Guide

The Traditional Novell Access Control Model

NetWare is known for its rich access control. OES makes these controls available on Linux through NSS volume support. In addition, some of the controls are available on Linux POSIX file systems through NCP volume creation. NCP volume access controls are not equivalent to NSS because they are constrained by Linux POSIX access controls, which offer only a subset of the directory and file attributes that NSS offers.

In the OES access control model, eDirectory objects, such as users and groups, are assigned File System Trustee Rights to directories and files on NSS and NCP volumes. These trustee rights determine what the user or group can do with a directory or file, provided that the directory or file attributes allow the action.

This is illustrated in Figure 14-2.

Figure 14-2 Directory and File Access under the NetWare Access Control Model

Table 14-2 explains the effective access rights illustrated in Figure 14-2.

Table 14-2 Access Rights Explanation

eDirectory or Active Directory Users and Groups	File System Trustee Rights	Directory and File Attributes	Directories and Files
eDirectory and AD users and groups gain access to the file system through their respective authentication mechanisms.	File system trustee rights govern access and usage for the directory or file to which the rights are granted. Trustee rights are overridden by directory and file attributes. For example, even though Nancy has the Supervisor (all) trustee right at the directory (and, therefore, to the files it contains), she cannot delete File2 because it has the Read Only attribute set. Of course, because she has the Supervisor right, Nancy could modify the file attributes so that File2 could then be deleted.	Each directory and file has attributes associated with it. These attributes apply universally to all trustees regardless of the trustee rights an object might have. For example, a file that has the Read Only attribute is Read Only for all users. Attributes can be set by any trustee that has the Modify trustee right to the directory or file.	The possible actions by the users and group shown in this example are as follows: Nancy has the Supervisor trustee right at the directory level, meaning that she can perform any action not blocked by a directory or file attribute. The Di (Delete Inhibit) and Ri (Rename Inhibit) Attributes on Directory A prevent Nancy from deleting or renaming the directory unless she modifies the attributes first. The same principle applies to her ability to modify File2. Because Joe is a member of the Reporters group, he can view file and directory names inside DirectoryA and also see the directory structure up to the root directory. Joe also has rights to open and read any files in DirectoryA and to execute any applications in DirectoryA. Because Bert is a member of the Reporters group, he can view file and directory names inside DirectoryA and also see the directory structure up to the root directory. Bert also has rights to open and read File1 and to execute it if it's an application. And Bert has rights to grant any eDirectory user access to File1. Because all three users are members of the Reporters group, they can grant any eDirectory user access to File2. Of course, for Nancy this is redundant because she has the Supervisor right at the directory level.

eDirectory or Active Directory Users and Groups

File System Trustee Rights

Directory and File Attributes

Directories and Files

eDirectory and AD users and groups gain access to the file system through their respective authentication mechanisms.

File system trustee rights govern access and usage for the directory or file to which the rights are granted.

Trustee rights are overridden by directory and file attributes.

For example, even though Nancy has the Supervisor (all) trustee right at the directory (and, therefore, to the files it contains), she cannot delete File2 because it has the Read Only attribute set.

Of course, because she has the Supervisor right, Nancy could modify the file attributes so that File2 could then be deleted.

Each directory and file has attributes associated with it. These attributes apply universally to all trustees regardless of the trustee rights an object might have.

For example, a file that has the Read Only attribute is Read Only for all users.

Attributes can be set by any trustee that has the Modify trustee right to the directory or file.

The possible actions by the users and group shown in this example are as follows:

Nancy has the Supervisor trustee right at the directory level, meaning that she can perform any action not blocked by a directory or file attribute.

The Di (Delete Inhibit) and Ri (Rename Inhibit) Attributes on Directory A prevent Nancy from deleting or renaming the directory unless she modifies the attributes first. The same principle applies to her ability to modify File2.
Because Joe is a member of the Reporters group, he can view file and directory names inside DirectoryA and also see the directory structure up to the root directory.

Joe also has rights to open and read any files in DirectoryA and to execute any applications in DirectoryA.
Because Bert is a member of the Reporters group, he can view file and directory names inside DirectoryA and also see the directory structure up to the root directory.

Bert also has rights to open and read File1 and to execute it if it's an application.

And Bert has rights to grant any eDirectory user access to File1.
Because all three users are members of the Reporters group, they can grant any eDirectory user access to File2.

Of course, for Nancy this is redundant because she has the Supervisor right at the directory level.

NSS Access Control on OES

Table 14-3 provides links to documentation that discusses the various NSS-specific access control features.

Table 14-3 Summary of NSS Access Control Documentation Links

Feature	To Understand	See
Independent Mode vs. NetWare Mode This applies only to OES servers, not NetWare.	The difference between Independent Mode access and NetWare Mode access.	Access Control for NSS on Linux in the OES 2018: File Systems Management Guide
POSIX directory and file attributes on NSS volumes on OES This describes what is displayed. POSIX permissions are not actually used for access control to NSS volumes.	How NSS file attributes are reflected in Linux directory and file permissions viewable through POSIX.	Viewing Key NSS Directory and File Attributes as Linux POSIX Permissions in the OES 2018: File Systems Management Guide

Feature

To Understand

See

Independent Mode vs. NetWare Mode

This applies only to OES servers, not NetWare.

The difference between Independent Mode access and NetWare Mode access.

Access Control for NSS on Linux in the OES 2018: File Systems Management Guide

POSIX directory and file attributes on NSS volumes on OES

This describes what is displayed. POSIX permissions are not actually used for access control to NSS volumes.

How NSS file attributes are reflected in Linux directory and file permissions viewable through POSIX.

Viewing Key NSS Directory and File Attributes as Linux POSIX Permissions in the OES 2018: File Systems Management Guide

Client for Open Enterprise Server (NCP File Services) Access

If you have not already determined whether to use the Client for Open Enterprise Server on your network, we recommend that you consider the following information:

About the Client for Open Enterprise Server

The Client for Open Enterprise Server extends the capabilities of Windows desktops with access to OES servers.

After installing Client for Open Enterprise Server software, users can enjoy the full range of OES services, such as

Authentication via NetIQ eDirectory
Network browsing and service resolution
Secure and reliable file system access
Support for industry-standard protocols

The Client for Open Enterprise Server supports the traditional OES protocols (NDAP, NCP, and RSA) and interoperates with open protocols (LDAP, CIFS, and NFS).

Is the Client for Open Enterprise Server Right for Your Network?

Although OES offers services that don’t require Client for Open Enterprise Server, (such as NetStorage and iPrint), many network administrators prefer that their network users access the network through the client for the following reasons:

They prefer eDirectory authentication to LDAP authentication because they believe it is more secure.
They prefer the NetWare Core Protocol (NCP) over the Microsoft CIFS protocol because they believe that CIFS is more vulnerable to the propagation of viruses on the network.

Conversely, other network administrators are equally adamant that their users function better without the added overhead of running an NCP client on each workstation.

We can’t determine what is best for you or your network, but we do provide you with viable choices.

eDirectory User Access to OES Servers

eDirectory users have access to services on OES servers just like they do on NetWare, with one additional consideration—to access some of the services, users must have Linux user credentials, such as a user ID (UID) and primary group ID (GID).

Because eDirectory users don’t have Linux user credentials by default, OES provides the Linux User Management (LUM) technology. Users and groups who need access to the affected services, must be enabled for eDirectory LDAP authentication to the local server. For more information, see Linux User Management: Access to Linux for eDirectory Users.

Beginning with OES 2015, the Novell Identity Translator (NIT) is supported. For more information, see NIT (Novell Identity Translator) in the OES 2018 SP2: NSS AD Administration Guide.

Active Directory User Access to OES Servers

Active Directory users can be granted access to CIFS shares on NSS volumes. The NSS AD integration service must be installed and the Novell Identity Translator must be configured to provide user IDs (UIDs) for AD users. For more information, see the OES 2018 SP2: NSS AD Administration Guide.

14.1.2 Planning for Service Access

After you understand the access options available to your network users, you can decide which will work best on your network.

Planning tips for network services are contained in the following sections:

Planning File Service Access

As you plan which file services to provide, be aware of the file service/volume and feature support limitations outlined in the following sections.

Service Access to Volume Type Limitations

Supported combinations are outlined in Table 14-4.

Table 14-4 Service Access to Volume Types

File Service	Linux POSIX Volumes	NSS Volumes on Linux
AFP	No	Yes-OES AFP
CIFS	No	Yes-OES CIFS
NetStorage	Yes	Yes
NetWare Core Protocol (NCP)	Yes	Yes
NFS	Yes	Yes-NFSv3

Details about the file systems supported by each file service are explained in the documentation for the service.

Be aware that file services support different sets of access protocols. A summary of the protocols available for access to the various OES file services is presented in Matching Protocols and Services to Check Access Requirements.

Feature Support

Table 14-5 Features Supported on Each Volume Type

Feature	Linux POSIX Volumes	NSS Volumes on Linux
Directory quotas	No	Yes
Login scripts	Yes (if also defined as an NCP volume)	Yes
Mapped drives	Yes (if configured as an NCP volume)	Yes
Novell directory and file attributes	No	Yes
Purge/Salvage	No	Yes
Trustee rights	Yes (if configured as an NCP volume)	Yes
User space quotas	No	Yes

Planning Print Service Access

OES iPrint has access control features that let you specify the access for each eDirectory User, Group, or container object to your printing resources.

You can also use iPrint to set up print services that don’t require authentication.

NOTE:Access control for printers is supported only on the Windows iPrint Client.

For more information on access control and iPrint, see Setting Access Control for Your Print System in the OES 2018 SP2: iPrint Administration Guide

Matching Protocols and Services to Check Access Requirements

Figure 14-3 illustrates the access interfaces available to users in OES and the services that each interface can connect to. It also shows the protocols that connect access interfaces with network services.

To use this for planning:

Review the different access interfaces in the left column.
In the middle column, review the protocols each interface supports.
In the right column, view the services available to the interfaces via the protocols.

Figure 14-3 Access Interfaces and Services, and the Protocols That Connect Them

14.1.3 Coexistence and Migration of Access Services

Because NetWare Core Protocol (NCP) is available in OES, your Client for Open Enterprise Server users can attach to OES servers as easily as they have been able to attach to NetWare servers. In fact, they probably won’t notice any changes.

NCP Server for Linux enables support for login scripts, mapping drives to OES servers, and other services commonly associated with Client for Open Enterprise Server access. This means that Windows users with the Client for Open Enterprise Server installed can now be seamlessly transitioned to file services on OES.

For more information, see the OES 2018 SP2: NCP Server for Linux Administration Guide.

14.1.4 Access Implementation Suggestions

After you plan and install OES services, be sure to provide clear access instructions to your network users. For a summary of access methods, see Section D.0, Quick Reference to OES User Services.

14.1.5 Configuring and Administering Access to Services

The following sections discuss administering access to services.

Password Management

Many network administrators let users administer their own passwords. For more information on password self management, see Password Self-Service in the NetIQ eDirectory Administration Guide.

Linux (POSIX) File System Access Rights

Access control to Linux POSIX file systems is controlled through POSIX file system access rights or attributes associated with directories and files. In general, the directories and files can be accessed by three POSIX entities:

The user who owns the directory or file
The group who owns the directory or file
All other users defined on the system

These users and the affected group are each assigned (or not assigned) a combination of three attributes for each directory and file:

Table 14-6 Linux Access Rights

Attribute	Effect on Directory when Assigned	Effect on File when Assigned
Read	Lets the user or group view the directory's contents.	Lets the user or group open and read the file.
Write	Lets the user or group create or delete files and subdirectories in the directory.	Lets the user or group modify the file.
Execute	Lets the user or group access the directory by using the cd command.	Lets the user or group run the file as a program.

For more information, see Configuring Trustees and File System Attributes in the OES 2018: File Systems Management Guide.

NSS File and Directory Trustee Management

The OES 2018: File Systems Management Guide contains a thorough discussion of file and directory trustee management in its Configuring Trustees and File System Attributes section.

The following sections present brief information about managing trustees on NSS volumes.

Using NetStorage to Change File and Directory Attributes and Trustees

You can use the NetStorage Web browser interface to change attributes and trustees for directories and files on NSS volumes, but you can’t change them by using a WebDAV connection to NetStorage.

Using iManager to Change File and Directory Attributes and Trustee Rights

You can use the iManager Files and Folders plug-in to manage directories and files on NCP and NSS volumes. For more information, see the plug-in help.

Using the Linux Command Prompt to Change File Attributes

Use the attrib command to change file and directory attributes on an NSS volume.

The attrib command is also documented in Using the Attrib Utility to Set NSS File System Attributes in the OES 2018: File Systems Management Guide.

You can also enter the following command at the command prompt:

attrib --help

Using the Linux Command Prompt to Change Trustee Rights

To grant NSS trustee rights to an NSS volume, enter the following command:

rights -f /full/directory/path -r rights_mask trustee full.object.context

where /full/directory/path is the path to the target directory on the NSS volume, rights_mask is the list of NSS rights, and full.object.context is the object (User or Group) in its full eDirectory context including the tree name.

For example, you might enter the following:

rights -f /data/groupstuff -r rwfc trustee mygroup.testing.example_tree

For a complete list of command options, enter rights at the command prompt.

The rights command is also documented in Using the Rights Utility to Set Trustee Rights for the NSS File System in the OES 2018: File Systems Management Guide.

Using rights and NFARM to Manage AD Trustee Assignments on NSS Volumes

For information on rights utility and NFARM, see the OES 2018 SP2: NSS AD Administration Guide.