Clarifying FTP restrictions strategies in FTPREST.TXT.

There has been confusion about usage of the SYS:ETC\FTPREST.TXT file for FTP restrictions, with the FTP Server (NWFTPD.NLM) on NetWare 5.1, 6.0, and 6.5. Some of the confusion arose because the current FTP server has different or additional implementations than the NetWare 4.x / 5.0 FTP server used. Some of the confusion is because of vague or incomplete documentation. This document attempts to explain and clarify the proper usage of the FTPREST.TXT file.

The FTPREST.TXT file has 5 Levels of access that can be assigned, and 4 Types of restrictions that can make use of those access levels.

 

The 5 Levels are:

Allow; Deny; Readonly; Guest; and Noremote

 

The 4 Types are:

NDS User Account; Address; Address Range; and DNS Domain.

 

Without a firm understanding of how these types and levels interact, they can be very confusing and yield seemingly unpredictable results.

The main goal of this document is to talk about the Types, but for that to make sense, some explanation of the Levels will first be needed. Explanation of Levels:

 

DENY and READONLY are self-explanatory.

ALLOW means the user has both read and write access (as long as his file system trustee rights provide that).

The details of GUEST and NOREMOTE are not necessary to understand the rest of this document. But a detailed explanation of those 2 levels and how they interact with home directory settings, see Solution NOVL62274, also known as KB 10065724.

 

Some levels can be combined without any logical conflict. GUEST, READONLY, and NOREMOTE have no conceptual contradictions with each other. Other combinations would seem to conflict when combined. If the combination of 2 levels would represent a intuitive conflict, the more restrictive level will take effect. For example, when ALLOW and DENY are combined, the result is DENY. When ALLOW and READONLY are combined, the result is READONLY. When GUEST and DENY are combined, the result is DENY.

Explanation of Types: The types (by themselves) are self-explanatory. But combining them gets complicated. The general explanation, stated as simply as possible, consists of 2 concepts:

The above explanation is accurate but may still be confusing to some. So here are some examples:

Example 1: Multiple rules of ONE TYPE, based on User account (according the rules above, this is a "last one wins" scenario):

*.O=NOVELL ACCESS= READONLY

.CN=USER1.O=NOVELL ACCESS= ALLOW

If .USER1.NOVELL logs in, he will get in with both read and write access, because the ALLOW rule is the last rule that applies to him. Any other users (*) within .O=NOVELL (even in sub-containers) will be limited to READONLY because that rule is the last that applies to them. If you reverse these 2 rules, then even USER1 will get READONLY access, because the READONLY rule would become the last one in the list that applies to him.

 

Example 2: Multiple rules of ONE TYPE, based on Address Range (this is a "last one wins" scenario):

ADDRESS_RANGE= 10.65.1.1 10.65.1.255 ACCESS=DENY

ADDRESS_RANGE= 10.65.1.10 10.65.1.20 ACCESS=ALLOW

If someone from an address within the .10 - .20 range attempts to log in, he will be allowed. Everyone else within the larger range will be denied. If you reverse these rules, then even .10 - .20 will be denied.

Example 3: Multiple rules of TWO TYPES, based on DNS Domain and User account (this is a "combined access" scenario):

DOMAIN= novell.com ACCESS=READONLY

.USER1.NOVELL ACCESS=GUEST

If USER1 logs in from a IP address within the novell.com domain, the system will give him READONLY access, and will restrict him to his home directory (which is what GUEST access means). Changing the order will make no difference.

Example 4: Multiple rules of TWO TYPES, based on DNS Domain and User account (this is a "combined access" scenario):

DOMAIN= novell.com ACCESS=READONLY

.USER1.NOVELL ACCESS=ALLOW

If USER1 logs in from a IP address within the novell.com domain, the system will attempt to combine ALLOW and READONLY access. The result will be READONLY access. Changing the order of the rules will not make a difference.

Example 5: Multiple rules of TWO TYPES, based on an Address Range and an Address (this is a "combine" scenario):

ADDRESS_RANGE= 10.65.1.1 10.65.1.255 ACCESS=DENY

ADDRESS= 10.65.1.10 ACCESS=ALLOW

This is not a very functional setup. The second rule may as well not exist. The system will attempt to combine these rules. When DENY and ALLOW are combined, the result is DENY. Changing the order will not make a difference.

Example 6: Multiple rules of TWO TYPES, based on a DNS Domain and an Address (this is a "last one wins" scenario):

DOMAIN= novell.com ACCESS= DENY

ADDRESS= 10.65.1.10 ACCESS= ALLOW

If a user logs in from IP address 10.65.1.10, which (hypothetically) is part of novell.com, the user is ALLOWED even though it is part of the novell.com domain. Reversing the rules would result in the user at 10.65.1.10 being DENIED.

FINAL NOTE: If three or more types are combined, the same rules used above should still apply, but the analysis can become extremely complex. Novell recommends that administrators stick to as simple an approach as possible. For easiest planning, design the restrictions using only one or two types..