yes, tid10018610
Ah, so the trick is to only allow by NDS container/group, which will
require a login, but also an allow rule for the server's IP, which will
bypass the login.
Be careful with your access rules. If you have a rule at the bottom of
your list (after a bunch of deny rules for users, groups or containers)
that allows Any, you would end up allowing everyone to everything without
authenticating.
Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on
BorderManager, go to http://www.craigjconsulting.com ***
>Be careful with your access rules. If you have a rule at the bottom of your list (after a bunch of deny rules for users, groups or containers) that allows Any, you would end up allowing everyone to everything without authenticating.
>
>
Sadly this doesn't seem to be working. Although I've turned off Enforce
Access Rules, and I've added a rule that allows my IP address to access
any URL, I still get a 403 Forbidden alert from BorderManager. Summary
of rules:
1. Deny Any URL <Specified URL list>
2. Allow <My IP> URL <Any URL>
3. Allow <Group1> URL <Any URL>
4. Allow <Group2> URL <Specified URL list>
If I am logged in, it will be as a member of Group1, so if I start
clntrust.exe I can then get access, but this of course defeats the
object as the server is not normally logged on.
If so, try restarting proxy. (It may not have picked up your change when
you made it, and restarting should definitely pick up a change by now).
Authenticate Only When.... tells BorderManager to authenticate only
under certain conditions. The easiest way to think about it is if you
think of the server making up to two passes through the access rules.
The first pass will simply skip rules set for user, group or container.
If it sees an allow rule for Any or an IP address/subnet, it will stop
at that rule and allow the traffic. If it does not see a match on the
first pass, or it sees a Deny rule, it will then make a second pass
through the rules and try to authenticate the user (CLNTRUST or SSL).
>In article <tcZ5n.5728$q93....@kovat.provo.novell.com>, Neil wrote:
>
>
>>Sadly this doesn't seem to be working. Although I've turned off Enforce Access Rules, and I've added a rule that allows my IP address to access any URL, I still get a 403 Forbidden alert from BorderManager.
>>
>And you have checked 'authenticate only when user attempts to access a restricted page'?
>
>In article <tyB7n.463$qb7...@kovat.provo.novell.com>, Neil wrote:
>
>
>>I had to trawl through the dialogs looking for it, but I eventually found it! Please could you remind me what the difference between this and Enforce Access Rules is?
>>
>Enforce Rules tells BorderManager to use the Access Rules list or not.
>
>Authenticate Only When.... tells BorderManager to authenticate only under certain conditions.
>
Ah, so you have to consider the two in parallel.
With both off, it's open season.
With only authenticate on, it's like having an allow rule for [Root] to
access anything.
With only enforce on, only allow rules work on NDS objects, but this
allows you to have allow rules that bypass authentication.
With both on, since you have to authenticate, this lets you use deny
rules with NDS objects.
With enforce rules off, it's open season. With authentication off, you
still have access rules that can apply to Any, subnets or IP addresses.
(Usually you end up just applying Deny to Any, and allow to subnets).
>
> With only authenticate on, it's like having an allow rule for [Root] to
> access anything.
With authenticate on, you have the possibility to discriminate between
users, groups or containers and IP addresses, and you can do things like
all the Tree, forcing anyone who wants to use the proxy to at least be in
your tree (and force them to authenticate as well).
>
> With only enforce on, only allow rules work on NDS objects, but this
> allows you to have allow rules that bypass authentication.
1. Hmm...enforce on means the proxy looks at rules.
2. Authenticate on means the proxy makes a link between browser IP address
and a user ID, and then a rule can make use of user, group or container.
3. Authenticate Only When... Means #2 sometimes happens, sometimes not.
But it definitely makes you have to understand your rules closely to
achieve what you want.
The usual method is authenticate, having some specific allow rules (for
admins and the like) at the top of the list so they can bypass some Deny
rules.
Then you tend to have a few Allow URL rules to allow specific sites that
might otherwise get blocked, or for which everyone should have access.
Then you often see A Deny Any rule for SurfControl or LinkWall that denies
categories of sites for anyone not already allowed by the above rules.
Following that, you have an Allow rule for either Any or for an Internet
Users Group to allow people to go where ever they want that is not already
blocked.
Finally you have a Deny Any rule. This prevents people from browsing that
are not in the tree/authenticated. (This is generally the default rule at
the bottom of the list).
Sometimes you have multiple Allow-by-group rules, especially for specific
sites. Sometimes you have multiple Deny rules for SurfControl/Linkwall
aimed at different groups, with different categories selected. (One set
for teachers/staff, another more restrictive set of categories for
students, for instance).
If you add in Authenticate Only When.... It's usually to allow a subnet or
specific IP addresses (I do this for Windows and Linux servers a lot) to
use proxy without authenticating. Very useful for servers that need to do
unattended updates of patches or virus patterns. I also sometimes just
open filter exceptions for those servers instead.
There is a good set of example rules in my BMgr book.
>In article <kxF7n.546$qb7...@kovat.provo.novell.com>, Neil wrote:
>
>
>>With both off, it's open season.
>>
>>
>With enforce rules off, it's open season.
>
No, I still needed to authenticate before I could browse.
>I also sometimes just open filter exceptions for those servers instead.
>
Unfortunately we also use the transparent proxy.