Re: ISAPI - Knowing if rule accepted or deny the request on POLICY_CHECK_COMPLETED

Hi Phillip,

Can you demonstrate that?

You can just test it.

In such a case the connection would be past down the list until it hit the
Default Rule where it would then be denied.

Nope.

Watch your Monitoring log to see what rule actually is associated with
the resulting "deny".

It is allowing rule in this case.

If you put a second identical rule under that one and include the
"missing" user, then it would catch the traffic after the first rule
ignored it and the user would be allowed.

Absolutely no.

I'm willing to be wrong,...but what you describe doesn't fit with what I
know about the rule behavor. An allow can only allow and not anything
else, and a deny rule can only deny and nothing else.

I afraid you are wrong. There is a good article about this. Here, just
found: http://www.isaserver.org/articles/ISA2004_AccessRules.html
Quote:
"When you configure access rules that apply to users and the user can not
authenticate themselves for any reason, then the request will be denied by
the rule requiring authentication, even if it is an allow rule."

Evgeny

"Phillip Windell" <philwindell@xxxxxxxxxxx> wrote in message
news:ujhVLNnbIHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
"Evgeny" <anonymous@xxxxxxxxxxxxx> wrote in message
news:uWhTgEnbIHA.5900@xxxxxxxxxxxxxxxxxxxxxxx

An Allow based Rule cannot "deny",...it can either allow or ignore.

Actually this is not right. Allowing rule can deny connections. For
example if connection conforms to allowing rule in all except user
identity (rule allows access to authenticated users, but connection is
anonymous), then connection will be denied. Other rules are not even
checked in this case.

Can you demonstrate that? In such a case the connection would be past
down the list until it hit the Default Rule where it would then be denied.
Watch your Monitoring log to see what rule actually is associated with the
resulting "deny".

If you put a second identical rule under that one and include the
"missing" user, then it would catch the traffic after the first rule
ignored it and the user would be allowed.

I'm willing to be wrong,...but what you describe doesn't fit with what I
know about the rule behavor. An allow can only allow and not anything
else, and a deny rule can only deny and nothing else.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or
Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1/8/918ed2d3-71d0-40ed-8e6d-fd6eeb6cfa07/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesecurity/partners/hardwarepartners.mspx
-----------------------------------------------------



.

Relevant Pages

  • understanding chkrootkit: sshd section
    ... Rhosts Authentication disabled, originating port will not be trusted. ... Secure connection to %.100s on port %hu refused%.100s. ... Warning: Remote host refused compression. ... Received RSA challenge from server. ...
    (comp.os.linux.security)
  • understanding chkrootkit: sshd section
    ... Rhosts Authentication disabled, originating port will not be trusted. ... Secure connection to %.100s on port %hu refused%.100s. ... Warning: Remote host refused compression. ... Received RSA challenge from server. ...
    (comp.security.unix)
  • (fwd) FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn (fwd)
    ... susceptible to attack than other unencrypted sessions. ... > incoming connection is being established, ... > All versions of FreeBSD 3.x and 4.x prior to the correction date ... > requiring other authentication of the originator are vulnerable to ...
    (FreeBSD-Security)
  • Re: understanding chkrootkit: sshd section
    ... Connection will not be encrypted. ... > Rhosts Authentication disabled, originating port will not be trusted. ... > Could not request local forwarding. ... Remote host failed or refused to allocate a pseudo tty. ...
    (comp.os.linux.security)
  • Re: understanding chkrootkit: sshd section
    ... Connection will not be encrypted. ... > Rhosts Authentication disabled, originating port will not be trusted. ... > Could not request local forwarding. ... Remote host failed or refused to allocate a pseudo tty. ...
    (comp.security.unix)