Novell is now a part of Micro Focus

Enhancements in BorderManager 3.6 Support Pack 1a

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 30 Nov 2001

Version: BorderManager 3.6

For more info, and to download the file, see TID 2960410

This file contains all updates for all services contained in the BorderManager 3.6 product along with added support for NetWare 6 installations. The purpose of the Support Pack is to provide a bundle of fixes that can be tested together and can be installed on NetWare 6. It is not recommended to install individual files from the Support Pack.

*** It is not necessary to install this patch if BorderManager 3.6 is running on a NetWare 4.X or NetWare 5.X server and BM36SP1.EXE has already been installed.

Prior to installing this Support Pack or any other major update to your server you should ensure that you have a reliable backup.

System Requirements

Here are the minimum system requirements:

  • Novell BorderManager Enterprise Edition 3.6
  • Support Pack 9 or later for NetWare 4.x servers
  • Support Pack 6a or later for NetWare 5 servers
  • Support Pack 2 or later for NetWare 5.1 servers
  • NetWare 6 with the latest support pack as available
  • Current TCPIP.NLM patch file (applicable export or domestic version)

The support packs and patch files are available at

Important: BorderManager 3.5 is not supported on Netware 6. Therefore, you must install BorderManager 3.6 and this support pack to run on a NetWare 6 server. This support pack is mandatory because it restores essential NetWare 6 files that are downgraded during the BMEE 3.6 installation.


This suppport pack contains the following enhancements:

Authenticating to a Non-BorderManager Parent Proxy Server Using HTTP

The proxy module can be configured to send a proxy- authorization header when forwarding a request to a CERN parent by adding the following section to the ETC/PROXY/PROXY.CFG file:

  • [Proxy-Authorization]
  • UserName=<user_defined_on_cern_parent>
  • Password=<password
  • ProxyReAuthorization=1

The username and password must use basic authentication (NTLM is not supported). Because basic authentication credentials cannot be extracted from an encrypted packet, users connecting to an SSL site are prompted for a valid user name and password on the CERN parent. If all users must authenticate individually to the CERN parent, leave the User Name and Password fields blank.

To disable this feature, add only the following to the ETC/PROXY/PROXY.CFG file:

  • [Proxy-Authorization]
  • AlwaysSendAuthorizationToCERNParent=0

Using Cookie-based Authentication with a Forward Proxy

BorderManager can associate a unique cookie with each user so that requests can be tracked. This is accomplished as follows:

  1. A user makes a GET HTTP request via the browser to the BorderManager forward proxy.
  2. BorderManager authenticates the user using SSL authentication.
  3. If the authentication is successful, it generates a cookie, stores it in an internal table, and also issues a set cookie command to the browser for both the proxy domain and the target domain using triple redirects. This ensures that the browser sends the cookie in the HTTP header in all subsequent requests.
  4. Because BorderManager expects a cookie in every request from an authenticated user, the product extracts the cookie from the received request and checks for an authentication entry against that cookie. If an authentication entry is found, the user is considered authenticated and the request is processed. If the cookie header is missing, BorderManager goes through the entire authentication process again and creates a new cookie.

BorderManager sets "session cookies" on the browsers. These cookies don't live beyond the particular session of the browser. When the browser is unloaded and reloaded, the user must re-authenticate to the proxy. Previously, the only user identity information present in an HTTP request was the source IP address. However, using cookie-based authentication, each user can have a unique session identity that is established with each login. Even if many users share the same IP address (for example, when going through a Network Address Translator (NAT), proxy, circuit- level gateway, and so on), the cookie identifies each user uniquely.

Cookie-based authentication can be turned on or off by using the following flag:


in the SYS:ETC\PROXY.CFG file. If the flag is turned off or if there is not an entry for BM_Forward_Cookie in the PROXY.CFG file, authentication reverts back to IP-based authentication.

The following entry is required in the SYS:ETC\PROXY.CFG file to enable cookie-based authentication:

[BM Cookie]
BM_Forward_Cookie=1 ; cookie based authentication is enabled. 1= enabled, 0= disabled (default).


  • Cookie-based Authentication Does Not Work with SSL
    Browsing to HTTP sites using SSL does not work properly when using cookie-based authentication (forward proxy or reverse proxy). Web browsers must be enabled to accept cookies.
  • The BorderManager server may abend if cookie-based authentication is enabled and reverse proxy and client requests are forwarded to HTTP sites using SSL.

    To disable authentication for reverse proxy on your BorderManager server from NetWare Administrator, do the following:
    1. Click BorderManager Setup > Acceleration > Details.
    2. Double-click an entry in the HTTP Accelerator List.
    3. Uncheck Enable Authentication For This Particular Accelerator.

    You can check to ensure that authentication is disabled for forward proxy by the checking the value set for BM_Forward_Cookie in the [BM Cookie] section of the SYS:ETC\PROXY\PROXY.CFG file.

  • Single Sign On (CLNTRUST.EXE) does not work correctly when cookie-based authentication is enabled.
  • The transparent proxy does not work correctly when forward cookie-based authentication is enabled.

New Mail Proxy Parameters

If you use the BorderManager Mail Proxy, the following keywords must now be added to the [BM Mail Proxy] section of the SYS:\ETC\PROXY\PROXY.CFG with the corresponding values:

BM_Domain: Primary domain of the BorderManager proxy; for example, if your primary registered domain name is, this value should be set to This keyword is used for the proxy to check incoming mail for spam relay. For example, if the domain name in the TO: field of the message does not match the primary domain of the proxy, the proxy will reject the message.

NOTE: If "Primary Domain Name" is not specified through NetWare Administrator, this keyword and a value are required in the SYS:ETC\PROXY.CFG file or outbound e-mail will not be sent. If "Primary Domain Name" *is* specified, the BM_Domain field it is not necessary.

BM_Proxy_Domain: Fully qualified DNS name of the BorderManager proxy. This field is used by the proxy to advertise its correct host name when sending the HELO command to an SMTP server. This is useful in cases in which the target SMTP server is performing a DNS lookup on the hostname advertised in order to avoid spam relay. Though this keyword is optional, if this keyword is not specified, outbound e-mail from the mail proxy may be rejected by the destination SMTP servers. This is because some SMTP servers do reverse DNS lookups on the SMTP origin during SMTP session establishment as an anti-spam measure. The recommendation is to specify this keyword with a value.

BM_Incoming_Relay: Whether the mail proxy will relay messages containing a % sign. This field can be set to integer values of 0 and 1. If set to 1, the mail proxy will relay e-mail containing a % sign. For example, if the proxy receives a message with a TO ADDRESS:, it will relay the message to If set to 0, the proxy will reject all incoming relay requests. By default, it is set to 0 to avoid a spam relay attack.


  • [BM Mail Proxy]
  • BM_Incoming_Relay=0


  1. These keywords must be added to the PROXY.CFG file or the mail proxy will not forward mail.
  2. If the mail proxy is enabled and an e-mail/attachment larger than the currently configured spool directory or maximum message size is passed through, the server may hang or abend. To avoid this issue, use NWADMIN to change the maximum message size to 2000MB and the spool size to 4000MB (even if there is not that much space available).
  3. If multiple MX record resolution is required, PROXY.NLM must be loaded with the -M switch (for example, LOAD PROXY -M).

Runtime Switches For ACLCHECK.NLM

To improve the ability to manage Access Control Rules, the following runtime switches have been added. These switches should be specified on the "LOAD ACLCHECK" command in the NCF file where you start BorderManager (for example, you might add "LOAD ACLCHECK" after the "LOAD BRDSRV" line in the AUTOEXEC.NCF file).

/A - enables ACL rules to recognize aliases when using SSL authentication.

/Bxxx - enables you to define how often ACLCHECK tests for changes in user group membership. (User groups can be used in creating BorderManager Access Control Rules.) By default, ACLCHECK user groups every hour and will re-read the rules if a change is detected. You may only want ACLCHECK to do this every few hours to reduce the number of times per day that the rules are re-read. When using this switch, replace the xxx with an integer starting with 0. This is the number of hours ACLCHECK will wait before testing for group membership changes. For example, using "/B0" disables ACLCHECK's regular testing for group membership changes and "/B24" will cause it to test group membership and reread the rules only once per day (every 24 hours).

/G - enables smart group change detection. This switch requires Directory Services DS.NLM version 7.44 or later on all servers that host replicas of the user partitions. By default, to check for changes to group membership, ACLCHECK reads all group memberships from every group mentioned in an ACL rule. Therefore, ACLCHECK must walk the tree to find the group and then reread each one of the members from the list for each group. This action alone requires a great deal of DS processing. If a group membership change is detected, ACL check must re-read the rules and walk the tree again. With the latest version of DS and the /G switch, ACLCHECK can now check a timestamp on the group object to know whether it has changed.

/I - prevents resolution of IP addresses in rules. Warning: With this switch, two rules are required to completely block or allow a URL: one for the DNS name and one for the IP address.

/P nnnn - enables you to specify a preferred server for ACLCHECK DS requests. Replace "nnnn" with the name of the preferred server.

/Q - forces ACLCHECK to go into "quiet" mode when certain types of messages are being spuriously broadcast to attached users.

/S - suppresses the display console messages for IP addresses that can't be resolved. This helps those who prefer not to have messages displayed on the console stating that an address could not be resolved by ACLCHECK.

/Z1 - enables ACLCHECK to display group information as it is read.

/Z2 - enables ACLCHECK to display GetNDSRevision() info as it is called.

Example load line:


Runtime Switch For AUTHCHK.NLM

Currently, the reverse proxy checks for the browser IP address as well as the cookie ID. Unfortunately, checking for the IP address causes some ISPs to function improperly. To fix this issue, there is now a switch that enables the reverse proxy to check for the Browser cookie ID only. This switch should be specified on the "LOAD AUTHCHK" command in the NCF file where you start BorderManager (for example, you might add "LOAD AUTHCHK" before the "LOAD BRDSRV" line in the AUTOEXEC.NCF file).

/n - check for cookie ID only; do not check for IP address.

Software Defect Fixes

In addition to these enhancements, this Support Pack contains software changes that fix a number of issues. Please see TID 2960410 for a complete list of defects that are fixed in this Support Pack.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates