This section provides more information about configuring access rules, how to build access control lists, and presents several examples. It contains the following subsections:
Novell BorderManager 3.7 allows you to configure each access rule as either an Allow rule or a Deny rule. Allow rules allow a request to be fulfilled; Deny rules deny the request. You can take two different approaches when you set up your Novell BorderManager 3.7 access control scheme, as follows:
As stated previously, Novell BorderManager 3.7 adds together all the individual access rule lists defined at all the different levels of the NDS or eDirectory tree in your network, starting from the Server object, continuing through the container holding the Server object, and concluding at the root of the eDirectory tree.
Within this consolidated list, rule lists defined at the Server object are placed at the beginning; rule lists defined at the root are placed at the end. In other words, rules defined closer to the user are placed closer to the top of the server's access control list. This combined list is the access control list for the Novell BorderManager 3.7 server; and it is applied to every access request received by the server.
Novell BorderManager 3.7 uses the sequence of access rules in the access control list to determine which rule takes precedence. A rule closer to the top of the list always takes precedence over any rule that follows it in the list. The first rule that matches the access request is the rule that is applied to the access request. If you mix conflicting Allow and Deny rules in an access control list, then you must ensure that the sequence of rules in the list produces the desired effect.
Each time a user makes an access request, such as when a Novell IP Gateway, Proxy Services, or VPN user initiates a request to access a particular service or destination, Novell BorderManager 3.7 checks the server's access control list. It searches the list until it finds the first access rule that applies to the requesting object, then it acts immediately on the rule to allow or deny the request. Intelligent sequencing is essential when you create access control rules because Novell BorderManager 3.7 searches for the first applicable rule in the server's access control list. It does not search for any potentially applicable rules after that.
In this example, your company president wants a rule that keeps company employees from accessing the World Wide Web (WWW) during work hours. You can accomplish this blanket policy with one general access rule at the root of the tree that contains your Novell BorderManager 3.7 server.
If the vice president of Marketing insists that his people must have access to the Web to perform their jobs effectively, you can satisfy his request with a second rule that you create for the Marketing user group or for specific users within that group.
This approach is one way to implement access rules on your Novell BorderManager 3.7 server. You use general rules placed higher in the eDirectory tree for far-reaching policies that you want to effect, such as keeping employees from accessing the Web during work hours. You use specific rules placed lower in the NDS or eDirectory tree for more specific cases or exceptions, such as allowing the Marketing group to have access to the Web during business hours.
When two rules conflict with each other (Deny everyone Web access during business hours and Allow members of the Marketing department to access the Web during business hours), the rule closer to the beginning of the server's access control list takes precedence. When no rule is found, the request is denied because the server's default action in the absence of a specific rule to the contrary is always Deny.
In this example, the administrator for XCom Communications creates the following rules on the XCom Novell BorderManager 3.7 server.
An analysis of the preceding access rules raises the question of whether the administrator really needs to configure the three Deny rules. Novell BorderManager 3.7 will automatically deny the user's access request when it reaches the end of the access control list if the request does not match any rule in the list. The answer is it depends on what the administrator wants to accomplish.
An examination of rule 4, which denies any users in the xcom.com group access to www.yadda.com, and rule 8, which allows any user in xcom.com to access any destination, reveals that rule 4 (deny) is necessary.
Rule 7 denies user access to any Web pages inside the innerweb.xcom.com/prv directory after rules 5 and 6 allow the Finance group and Human Resources group to access their own Web directories.
However, rule 2 allows any user in xcom.com to access innerweb.xcom.com, which allows access to the pages inside the innerweb.xcom.com/prv directory. Rule 3 allows any user in the exec.xcom.com group to access any destination, which also allows access to pages inside the innerweb.xcom.com/prv directory.
If the administrator does not want users in the xcom.com group to access the innerweb.xcom.com/prv area, then rule 2 should be moved after rule 7 (deny). However, if the administrator wants users in the exec.xcom.com group to have access to the innerweb.xcom.com/prv directory, then rule 7 is not needed.
On examination, rule 8 allows any user in xcom.com to access any destination, which also allows any user to access the host, innerweb.xcom.com. This makes rule 2 unnecessary. The administrator can also delete rule 9 because, by default, Novell BorderManager 3.7 automatically denies user access requests at the end of the access control list when the request does not match any specific rule in the list.
The final access control list looks like the following:
An analysis of the preceding access control list reveals that any user in xcom.com can access any destination (rule 7), except the www.yadda.com and innerweb.xcom.com/prv directories (rule 3 and rule 6).
Now consider the following requests:
If Amy made this request, the access rules would work as follows:
The answer is No, Amy cannot access www.yadda.com.
The access rules would work as follows:
Jose can access the site but not he cannot use FTP to copy the files.
The access rules would work as follows:
P.V. can use FTP to copy files from www.yadda.com.
Roger cannot see any location under innerweb.xcom.com/prv.
You can also specify periods of the day and days of the week when an access rule is to be in effect, and you can specify that you want all requests against an access rule to be logged.