Herb,

I think what you are experiencing is do to how Windows works.
AFAIK IIS only relies on the underlying Windows security.

Group memberships of an account are determined when the account
first logs in. If an account is added to new, removed from prior groups,
these changes will not be seen until the account has logged off and
then back logged back in.

Roger

[quoted text, click to view]

How does IIS deal with Inprocess DLLs and their permissions?

Is this why IIS seems to 'cache permission' settings? -- i.e., changes
to file permissions which should be reflected the next time the file
is OPENED by a user are not necessarily reflected until IIS is restarted.

Why one might say, "of course", there is a weirdness here, if the user
in question never visits the visits the IIS until after the permission
change,
e.g., this sequence:

IIS started -- NTFS permission change -- new user attempts access
through that DLL that REQUIRES that permission change to be in
effect.

Does IIS somehow cache the permission themselves and run it's OWN
security manager internally?

If so, this would explain how my "not authorized" problem might result
while NO AUDIT failures appear in the security log.

Admission: I don't use permissions refencing the IUSR_machinename
and IWAM_machinename DIRECTLY but instead use groups (best
practice right <grin>) largely so that I can easily distinguish MY changes
from those made by tools like IISLockdown, updates to software, etc.

How about the Metabase? Could a tightening of something in there by
the lockdown tool have hosed my access by anonymous users to the
email submission EVEN THOUGH there are no audit failures on the
FP2002 extension DLL nor on the output File?

[quoted text, click to view]

What does this have to do with changes to object permissions?

There was no mention of changes to groups -- just the object permissions.

Of course, groups and RIGHTS (not permissions) are calculated when
the User logs on and not recalculated until that re-occurs. (Exception is
are the "special groups" which really should be called DYNAMIC groups
because the OS calculates the TYPE of access to determine membership
each time a resource is opened.)

File (and other object) permissions are much more dynamic, requiring
no logon by the affected user(s) since the users are really "given the
permission" but rather the OBJECT is assigned an access control entries
that REFERENCE the users/groups and allow or deny access.

The only built-in issue with timing the effect of PERMISSIONS (not rights)
is that the permissions are checked when the OBJECT (e.g., file) is
OPENED, so if an object were already open and the permissions were
changed then the change would not be reflected until the re-open.

We see that IUSR_machine account authenticates when the service starts
(auditing enabled) and doesn't (usually) re-authenticate until the next
startup.

This COULD explain the permissions on ISAPI DLLs seeming sticky until
restart for IUSR_machinename IF this were the only account that EVER
referenced the DLL -- file is opened on first use and then kept open,
but....

Some users authenticate BESIDES IUSR and IWAM machine name so how
does IIS keep these separate? Today, a separate process is possible and
sometimes used for running ISAPI DLLs bu this behavior has been around
since ISAPI DLLs in IIS 3.0 without the separate process and if their is
only
the ONE separate process we still have the issue of distinguishing
JoeAdmin's
access through Cool.DLL from IUSR_machine anonymous users.

I am pretty much having to think through ALL assumptions since I have an
access problem that is not being discovered by normal auditing -- nor the
IIS or URLScan logs.

Hi Herb,

Have a look at this article, it may address the behavior you are seeing.


Changing the Default Interval for User Tokens in IIS:
http://support.microsoft.com/default.aspx?scid=kb;en-us;152526


Thanks,

Michael Laing
Microsoft Developer Support
Internet Information Server

***********************
[quoted text, click to view]
account name for newsgroup participation only.<<

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
© 2003 Microsoft Corporation. All rights reserved.
***********************
--------------------
| From: "Herb Martin" <news@LearnQuick.com>
| Subject: NTFS permission for Inprocess DLLs
| Date: Mon, 14 Jul 2003 00:25:44 -0500
| Lines: 34
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <#63MFicSDHA.1252@TK2MSFTNGP10.phx.gbl>
| Newsgroups: microsoft.public.inetserver.iis.security
| NNTP-Posting-Host: cs666835-45.austin.rr.com 66.68.35.45
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.inetserver.iis.security:2220
| X-Tomcat-NG: microsoft.public.inetserver.iis.security
|
| How does IIS deal with Inprocess DLLs and their permissions?
|
| Is this why IIS seems to 'cache permission' settings? -- i.e., changes
| to file permissions which should be reflected the next time the file
| is OPENED by a user are not necessarily reflected until IIS is restarted.
|
| Why one might say, "of course", there is a weirdness here, if the user
| in question never visits the visits the IIS until after the permission
| change,
| e.g., this sequence:
|
| IIS started -- NTFS permission change -- new user attempts access
| through that DLL that REQUIRES that permission change to be in
| effect.
|
| Does IIS somehow cache the permission themselves and run it's OWN
| security manager internally?
|
| If so, this would explain how my "not authorized" problem might result
| while NO AUDIT failures appear in the security log.
|
| Admission: I don't use permissions refencing the IUSR_machinename
| and IWAM_machinename DIRECTLY but instead use groups (best
| practice right <grin>) largely so that I can easily distinguish MY changes
| from those made by tools like IISLockdown, updates to software, etc.
|
| How about the Metabase? Could a tightening of something in there by
| the lockdown tool have hosed my access by anonymous users to the
| email submission EVEN THOUGH there are no audit failures on the
| FP2002 extension DLL nor on the output File?
|
|
|
|
|

[quoted text, click to view]

You said you do permissioning with groups
[quoted text, click to view]

You were not clear as to the exact context of the error but long on
analysis of possible underlying causes.
It was not even clear that this issue exists for prior or only new webs.
Reread what you had posted. Basically it seems to indicate that you
are having an issue after a permissions change, and later you say you
use groups for permissioning.

That is what it has to do with the changes you were discussing

Yes, permission changes; not group membership changes.

Hello,

Your basic premise is fundamentally flawed. IIS relies totally on the
underlying OS security mechanisms and doesn't 'cache permission
settings' at all.

This is actually very simple to test. How ? Create a test file, access
it, change its NTFS permissions, try to access it again.

If done correctly you will notice the change immediately. And IIS
won't have been re-started.

Not Authorized means just that, you're not authorized. No bug, no
weirdness, you're just missing something obvious.

Regards,

Paul Lynch
MCSE

[quoted text, click to view]