3.3 Administering

This section discusses various ways to administer the NetWare FTP Server:

3.3.1 Supporting Extended Characters in a User Password

Users are unable to log in if a password containing extended characters is set from a Windows workstation, such as from iManager. This is because of code page differences between the server and the client.

To ensure that the user login is successful, you need to set a password with extended characters from the server console.

3.3.2 Initializing Multiple Instances

Multiple instances of the NetWare FTP Server can run on a single machine with different IP addresses, or port numbers.

You can initialize multiple instances of the NetWare FTP Server, if each instance of the NetWare FTP Server has a unique IP address and port number combination. Each NetWare FTP Server instance can have its own configuration file and access restrictions file.

The NetWare FTP Server uses the IP address of the host (HOST_IP_ADDR) and the port number (FTP_PORT) as defined in the configuration file to bind to and listen for FTP client connection requests. You can specify the configuration file while starting the NetWare FTP Server. If these parameters are not defined in the configuration file, the NetWare FTP Server listens to the standard FTP port number on all of the NetWare Server’s IP addresses.

If multiple instances of NetWare FTP Server (NWFTPD) are running and if you need to set the FORCE_PASSIVE_ADDR parameter (non-default), then any instance where this is set must have a unique value.

If one instance of NetWare FTP Server is listening on multiple addresses and the configured passive address is not reachable from clients on some networks, then the administrator can configure separate instances of FTP for each network address. Each instance can then have its own FORCE_PASSIVE_ADDR setting.

For more details, see Table 2-1.

3.3.3 Unloading Specific Instances

You can unload specific instances of NetWare FTP Server that correspond to the specified configuration file by using the following syntax:

nwftpd -u [volname: [/dirname/...]] myconfig.cfg

Default directory = sys:/etc. Default volume = sys:

3.3.4 Managing Intruder Detection

You can enable either host detection or user intruder detection at a time, but not both at the same time.

For example, INTRUDER_HOST_ATTEMPTS can be disabled (set to 0) while INTRUDER_USER_ATTEMPTS is enabled (set to 1 or higher).

If a successful login takes place before the maximum specified number of unsuccessful login attempts, the login failures count is reset to 0.

If the invalid login attempts of the users and hosts are fewer than maximum attempts allowed, and they are not detected as an intruder, they are removed from the corresponding list after refresh time of 72 hours.

The intruder host list and the intruder user list are refreshed every 72 hours.

Host Intruder Detection

A host or a client machine is considered an intruder when the number of consecutive login failures for any user from that host is more than the configured limit set by the INTRUDER_HOST_ATTEMPTS parameter.

What Happens When the Host Is Identified As an Intruder

  • The Server closes the session.

  • The host machine's access to the NetWare FTP Server is denied the time interval specified by the HOST_RESET_TIME parameter in the configuration file.

User Intruder Detection

A user is considered an intruder when the number of unsuccessful login attempts is more than those specified by the INTRUDER_USER_ATTEMPTS parameter in the configuration file.

All failed attempts from a user from different hosts are considered for intruder detection as the same user. When the accumulated attempts for the same user from different hosts exceed the maximum number of allowed attempts, then that user is detected as intruder.

What Happens When the User Is Identified As an Intruder

  • The user account is locked out for an interval of time specified by the USER_RESET_TIME parameter in the configuration file.

  • The user cannot log in from a different host until the reset time is over.

3.3.5 Specifying Access Restrictions

The FTP service lets you specify access restrictions for a user, a client host, and the IP address of a client host. The access restrictions are specified in the RESTRICT_FILE restrictions file, which can be configured. You can specify the access restrictions at various levels, and multiple access rights are allowed.

By default, changes to the RESTRICT_FILE take effect dynamically. But when the objects restricted in ftprest.txt file are renamed in eDirectory, these objects should be synchronized manually in the ftprest.txt restriction file.

Restriction Levels

The following table describes the supported levels of access restrictions.

Table 3-4 NetWare FTP Access Restrictions and Support Levels

Restriction Level

Description

Container

Restriction can be specified for any eDirectory container. This controls all the users in that container and its sub-OUs.

*.container name

The asterisk (*) indicates the container level restriction. The container should be a fully distinguished name.

To apply restrictions if the container names have aliases, add the alias of the container names in the restrictions file.

User

Restriction can be specified for a particular user.

.user name

The period (.) indicates user level restriction. The username should be a fully distinguished name.

To apply restrictions if the user names have aliases, add the alias of the user names in the restrictions file.

Domain

Restriction can be specified at the domain level. This controls all the hosts in that domain and its subdomains. The following is the RESTRICT file format:

DOMAIN= domain name

The DOMAIN= key word indicates the domain level restriction.

The domain restrictions do not work if the NetWare server is not configured to query a valid DNS server, or if the restricted domain's DNS database does not contain a pointer record (address to name resolution) for the FTP client address.

Address Range

Restriction can be specified based on the IP address or range.

Restricts any node that has the IP address within the specified IP address range. The range is specified by two IP addresses separated by a space. The range = 0.0.0.0 to 255.255.255.254. The value 255.255.255.255 is invalid since 255.255.255.255 is a broadcast address and not supported for ADDRESS_RANGE.

Host

Restriction can be specified for a particular host machine.

ADDRESS= host name/IP address

The ADDRESS= key word indicates the host level restriction. The host name or IP address of the host can be specified.

The DNS configuration should be appropriate for address and domain name restrictions.

Access Rights

The following table describes the permitted access rights.

Table 3-5 NetWare FTP Access Rights list

Access Right

Description

DENY

Denies access to the NetWare FTP Server for that client.

READONLY

Gives read-only access to the client.

NOREMOTE

During login, the NetWare FTP Server determines the user’s home server and home directory. The user is unable to navigate outside the home server.

NOTE:The home server can be different from the server where NetWare FTP Server is running.

GUEST

During login, the NetWare FTP Server determines the user’s home server and home directory. The user is unable to navigate outside of the home directory.

NOTE:The home server can be different from the NetWare FTP Server.

ALLOW

Gives normal FTP access without restriction.

Keywords

The following table describes the possible keywords.

Table 3-6 NetWare FTP Access Restriction Keywords

Keyword

Description

ADDRESS=

Restricts a particular node. The IP address or machine name can be used.

DOMAIN=

Restricts a particular domain.

The asterisk (*) should be used for container-level restrictions.

ADDRESS_RANGE=

Restricts a range of nodes based on the IP address. It applies the restriction to any node that has the IP address within the specified IP address range.

ACCESS=

Mandatory for each line. It should be followed by access rights.

Restriction File

The format and organization of the RESTRICT_FILE restriction file is as follows:

  • Each line should have one entity name and corresponding access rights.

  • The rights of the entities are assigned according to the order of the restriction file. If different rights apply to the same entity, the latest entities that appear in the restriction file are used.

  • All rights specified in the same line are applied to that entity.

  • If the restriction file does not exist or is empty, the ALLOW access is given to all users. Users have no restrictions other than those imposed by their own effective trustee rights to the file system.

Example 1 

*.novell                           ACCESS=ALLOW

*.testou.novell                    ACCESS=DENY

.user1.testou.novell               ACCESS=READONLY

User1 at testou is granted read-only rights. The other users at testou.novell are denied the right to log in. However, all other OUs at .novell are allowed.

Example 2 

*.testou.novell                    ACCESS=DENY

*.novell                           ACCESS=ALLOW

All OUs at .novell are allowed because both rights apply to testou and the second one would be used.

Example 3

ADDRESS=Clientmachine1.testou.novell.com ACCESS=NOREMOTE

.user1.novell ACCESS=READONLY

User1 logging from clientmachine1 will have read-only rights and no remote access.

For more details, see Table 2-2

3.3.6 Monitoring FTP Log Files

The NetWare FTP Server has four log files for recording different activity information. All the log files are created in the FTP_LOG_DIR directory specified in the configuration file.

The LOG_LEVEL parameter defined in the configuration file controls the number and type of information logged.

All the log files now support comma-delimited format for log messages.

Specifying Log Levels

The log levels indicate bits for which you can give any combination.

  • 1 = ERROR

  • 2 = WARNING

  • 4 = INFO

Table 3-7 NetWare FTP Server Log Levels

Log Level

Combination Logged

LOG_LEVEL = 3

Error messages and warning messages.

LOG_LEVEL = 4

Error messages and warning messages.

LOG_LEVEL = 7 (Default)

All messages are logged

The MAX_LOG_SIZE parameter specifies the maximum size of the log files (in KB), up to which messages can be logged. After exceeding this limit, the existing contents of log files are copied to the corresponding backup (*.bak) files.

Statistics Log File

The statistics log file contains details of all active sessions in the log file. The default path is sys:/etc/ftpstat.log.

The statistics log file maintains the following three record types. Every record type is separated by a comma.

  • TRANSFER: Contains information related to the data transfer.

  • USER: Contains information related to user s logged in or logged out.

  • FAILURE: Contains information about the number of failures during data transfer.

Intruder Log File

The intruder log file contains information about unsuccessful login attempts. The default path is sys:/etc/ftpintr.log.

The following information is recorded in the file:

  • Address of the machine where the login originated

  • Time of the attempted access

  • Login name of the user

The general intruder log format is:

ErrorLevel, Date Time, Client IPaddress, UserName, message

System Log File

The system log file contains all the internal system-related information encountered by the NetWare FTP Server.

The general system log file format is:

Error, Thread ID, Date Time, Message

For more details, see Table 2-4.

3.3.7 Viewing Active Sessions

To load the Active Sessions display utility, click the Monitor Active Session link in iManager.

Figure 3-2 Active Session Display

Figure 3-3 Session-based Details

You can view session-based details such as bytes sent, bytes received, session duration, files sent, files received, and current Novell® eDirectory 8.7.3 context. These details are not tied to individual user logins.

These statistics-related pages time out after every 20 minutes. Users can reload by clicking the Monitor Active Session link again.

3.3.8 Setting Modification Time

NetWare FTP Server now supports extended functionality for the mdtm modification time command. This command, now allows you to set the last modified date and time for both files and directories.

Previously, the mdtm command functionality was limited to retrieving the last modified date and time of a file only.

The command syntax is as follows:

mdtm [timestamp] pathname

  • The format for the optional timestamp is YYYYMMDDHHMMSS.

  • The timestamp is required only when setting the modified date and time of the target.

  • FTP Server considers the timestamps set or retrieved to be in server local time.

  • The pathname can be any existing file or directory on the server. You can use relative and absolute paths.

  • FTP Server supports and accepts pathnames that either begin with spaces or include spaces.

    However, use the spaces in file and directory names with caution because the handling of spaces in these names varies with each FTP client. Certain FTP clients do not handle spaces well when they parse the user’s command prior to sending it to the server, and some clients might handle this better if the pathname is enclosed in double quotes.

    For example,

    " pathname"

FTP Client Response

If the FTP client does not recognize the mdtm command, then the client software might reject the command that the user enters and might not forward it to the server.

To ensure that the client forwards the mdtm command to the server, enter a customized quote command in the following format:

quote MDTM [timestamp] pathname

Most FTP clients view the quote command as a signal that they should send the rest of the line to the FTP Server even if the client software does not recognize it.

However, some clients might change spaces and quotation marks within the quote command, so successful execution on paths or names containing spaces might not be possible from some FTP clients.

3.3.9 Subtree Search Support

FTP Server now supports subtree searching while looking for user objects under specified contexts.

To enable subtree search, add the delimiter :s to the end of the context in the SEARCH_LIST parameter in ftpserv.cfg file. The FTP server then searches the context and all sub containers. If :s is not added to a context, the search is done only within the specified context.

The contexts in the list should be specified in the preferred search order.

For example:

SEARCH_LIST=.accounting.boston.novell:s,.development.boston.novell:s,.boston.novell

Here the search begins for user objects in .accounting.boston.novell and in the subtree below. If the user is not found under this subtree, the search continues under .development.boston.novell and in the subtree. If the user is not found, .boston.novell is searched again, without searching any further sub containers.

The subtree search is performed by ndsilib.nlm. This module accesses the tree through the nfauuser user object. This user is normally created during the NetWare 6.5 install, for use by Native File Access for UNIX (NFS), but can also be created by loading schinst -n at the server console.

The load sequence in the autoexec.ncf file should be changed to load ftpstart.ncf first. Alternatively, if nfsstart.ncf is remarked out because NFS is not being used, load ndsilib.nlm before ftpstart.ncf.

For more information on this utility please refer to online documentation on Native File Access for UNIX.Any duplicate contexts in the SEARCH_LIST will be eliminated and the modified list is noted in the ftpd.log file.Context duplication is checked according to the order specified in SEARCH_LIST. That is, if a parent context has subtree search enabled, all the subsequent child contexts specified in the SEARCH_LIST is eliminated irrespective of whether they are specified for subtree search or one-level search.

For example:

SEARCH_LIST=.boston.novell:s,.accounting.boston.novell:s,.development.boston.novell

In the above case both the contexts, .accounting.boston.novell and development.boston.novell could be eliminated from the list because .boston.novell is the parent and is specified for subtree search.However, a parent context that is specified after a child context is not eliminated. This allows searches to resolve more quickly by specifying smaller areas with frequently used user populations before a larger subtree search is done.

For example: SEARCH_LIST=.development.boston.novell:s,.accounting.boston.novell,.boston.novell:s

In this case, none of the contexts is eliminated. The development subtree is searched, then if no match is found, the accounting container is searched. If a match is not found, an entire subtree search of boston.novell is done.If a problem prevents the use of ndsilib for subtree searching, the FTP server treats each context in the SEARCH_LIST as a plain, single-level search context.

NOTE:The current SEARCH_LIST in use is always be noted in the ftpd.log file. In troubleshooting, it might be useful to compare the intended SEARCH_LIST in ftpserv.cfg with the effective result in ftpd.log.

When the process of locating a user object depends upon a subtree search, the user should submit only the username upon login. Submitting a relative or partial context with the username is not successful in a subtree search. Submitting a full context, beginning with a leading dot (.) is recommended because this does not rely on a subtree search.

For example:

.user1.boston.novell

If a context name contains the delimiter itself (:s), it should be separated with a backslash, irrespective of whether it is specified for subtree search or for context-level search.

For example:

SEARCH_LIST=.north\:south

where the eDirectory container object name is .north:south.

When a user is found, the FTP session's context is set to the context where the user was found.