Enhancements in BorderManager 3.6 Support Pack 1a

Novell Cool Solutions: Feature

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.

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.

Enhancements

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:

A user makes a GET HTTP request via the browser to the
BorderManager forward proxy.

BorderManager authenticates the user using SSL
authentication.

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.

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:

-"BM_Forward_Cookie"

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:

KNOWN ISSUES

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:

Click BorderManager Setup > Acceleration > Details.

Double-click an entry in the HTTP Accelerator List.

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 xyz.com,
this value should be set to xyz.com. 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:
johndoe%abc.com@xyz.com, it will relay the message to
johndoe@abc.com. 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.

Example:

[BM Mail Proxy]

BM_Domain=xyz.com

BM_Incoming_Relay=0

BM_Proxy_Domain=mail-proxy.acctg.xyz.com

KNOWN ISSUES

These keywords must be added to the PROXY.CFG file or
the mail proxy will not forward mail.

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).

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).

/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:

LOAD ACLCHECK /G /B12 /S

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.