This section discusses the following topics. For additional planning topics, see the OES online documentation.
The OES Trustee and Linux (POSIX) security models are quite different, as presented in Table 19-1.
Table 19-1 POSIX vs. NSS/NCP File Security Models
Feature |
POSIX / Linux |
Trustee Model on OES |
---|---|---|
Administrative principles |
Permissions are individually controlled and managed for each file and subdirectory. Because of the nature of the POSIX security model, users usually have read rights to most of the system. To make directories and files private, permissions must be removed. For more information on making existing directories private, see Section 16.4.2, Providing a Private Work Directory. |
Trustee assignments are made to directories and files and flow down from directories to everything below unless specifically reassigned. |
Default accessibility |
Users have permissions to see most of the file system. The contents of a few directories, such as the /root home directory, can only be viewed by the root user. Some system configuration files can be read by everyone, but the most critical files, such as /etc/fstab, can only be read and modified by root. |
Users can see only the directories and files for which they are trustees (or members of a group that is a trustee). |
Home directories—an example of default accessibility |
By default, all users can see the names of directories and files in home directories. During LUM installation, you can specify that newly created home directories will be private. For more information on making existing home directories private, see Section 16.4.2, Providing a Private Work Directory. |
By default, only the system administrator and the home directory owner can see a home directory. Files in the directory are secure. If users want to share files with others, they can grant trustee assignments to the individual files, or they can create a shared subdirectory and assign trustees to it. |
Inheritance from parents |
Nothing is inherited. Granting permission to a directory or file affects only the directory or file. |
Rights are inherited in all child subdirectories and files unless specifically reassigned. A trustee assignment can potentially give a user rights to a large number of subdirectories and files. |
Privacy |
Because users have permissions to see most of the file system for reasons stated above, most directories and files are only private when you make them private. |
Directories and files are private by default. |
Subdirectory and file visibility |
Permissions granted to a file or directory apply to only the file or directory. Users can't see parent directories along the path up to the root unless permissions are granted (by setting the UID, GID, and mode bits) for each parent. After permissions are granted, users can see the entire contents (subdirectories and files) of each directory in the path. |
When users are given a trustee assignment to a file or directory, they can automatically see each parent directory along the path up to the root. However, users can’t see the contents of those directories, just the path to where they have rights. |
When an NCP volume is created on a Linux POSIX or NSS volume, some of the behavior described above is modified. For more information, see the OES 2018 SP3: NCP Server for Linux Administration Guide, particularly the NCP on Linux Security
section.
Seasoned NetWare administrators are accustomed to being able to set the following access restrictions on users:
Account balance restrictions
Address restrictions
Intruder lockout
Login restrictions
Password restrictions
Time restrictions
Many of the management interfaces that set these restrictions (iManager, for example), might seem to imply that these restrictions apply to users who are accessing an OES server through any protocol.
This is generally true, with two important exceptions:
Maximum number of concurrent connections in login restrictions
Address restrictions
These two specific restrictions are enforced only for users who are accessing the server through NCP. Connections through other access protocols (for example, HTTP or CIFS) have no concurrent connection or address restrictions imposed.
For this reason, you probably want to consider not enabling services such as SSH and FTP for LUM when setting up Linux User Management. For more information on SSH and LUM, see Section 9.4, SSH Services on OES.
For more information on Linux User Management, see Linux User Management: Access to Linux for eDirectory Users. For more information on the services that can be PAM-enabled, see Table 13-2.
The ports used by OES services are listed in Table 19-3.
Table 19-2 Open Enterprise Server Services and Ports
Service |
Default Ports |
---|---|
Domain Services for Windows |
|
NetIQ eDirectory |
|
iManager |
|
iPrint |
|
Novell Identity Translator |
|
OES AFP |
|
OES CIFS |
|
Cloud Integrated Storage (CIS) |
Infrastructure services:
CIS core services:
|
OES Cluster Service |
|
OES DHCP |
|
OES DNS |
|
OES FTP |
|
Novell Information Portal |
|
OES NetWare Core Protocol (NCP) |
|
OES Remote Manager |
|
NURM |
|
SFCB |
|
Secure Shell |
|
Storage Management Services (Backup) |
|
Time Synchronization |
|
OES on SLES provides modules configured to prevent the HTTP Denial of Service (DOS) attacks. As a best practice, if you are planning to have Apache based services such as iManager, NURM, iPrint, or UMC in OES, it is recommended to follow the Apache security tips.
For a list of configuration and administration topics, see the OES online documentation.