URL Authorization issues/problems

I have set up URL Authorization on virtual folders in a site that is being
used for webdav access. All works fine without URL Authorization, not only do
people get the folder list, they actually see only those folders they have
rights to because access-based enumeration is enabled. So far so good, but I
want to have the added 'control' of being able to restrict access by a group
as I don't necessarily want all my users to have remote access to all the
webdav virtual folders.

URL authorization works... sort of! This is where the problem lies...

If the AzImpersonationLevel in the IIS metabase for the virtual folder is
set to 1 (IIS worker process identity) you can log on successfully (assuming
you're in the appropriate group) but you seem to have administrative rights
so you can see and modify all files, even if you do not have access rights to
them yourself. Not very clever! The application pool is set to run with the
NETWORK SERVICE identity (if set to IWAM_... I get the same problem as given
below).

If the AzImpersonationLevel is set to 0 (authenticated client identity) you
cannot log on and get a 401.3 error (unauthorised due to ACL on resource). I
know the ACLs on the file system are OK because it was working fine without
URL Authorization. The URL Authorization store store has read/execute rights
for authorised users, as does (for good measure) the URLauth.dll file.

Can anyone throw any light on a) why I seem to get admin rights with the
worker process identity (bit dangerous that) and b) what resource it might be
complaining about with the client identity.

Many thanks

Ian

RE: URL Authorization issues/problems

After further investigation I'm now going to provide my own solution to the
problem here, it might be useful to others on the group.

It appears that the cause of the problem lies with 'Windows Integrated'
authentication on the web site itself. I'm not sure whether the behaviour I
described is part and parcel of this method or whether it is a real issue.
However, it's all beside the point (for me at any rate) because using 'Basic'
authentication (over SSL, of course) works, despite the instructions for URL
Authorization saying that it will only work with Windows Integrated. So for
anyone else interested in this, the instructions are at:

http://technet2.microsoft.com/WindowsServer/en/library/2f707 c21-f5e6-4649-8104-ef5e70bacbeb1033.mspx?mfr=true

but I would change 2 things:

1. Use Basic Authentication on the web site (which should be configured with
SSL)
2. Ensure that AzImpersonationLevel is set to 0

It works well, does exactly what I wanted of it, and I would heartily
recommend it to anyone.

Ian

"Ian Baldwin" wrote:

> I have set up URL Authorization on virtual folders in a site that is being
> used for webdav access. All works fine without URL Authorization, not only do
> people get the folder list, they actually see only those folders they have
> rights to because access-based enumeration is enabled. So far so good, but I
> want to have the added 'control' of being able to restrict access by a group
> as I don't necessarily want all my users to have remote access to all the
> webdav virtual folders.
>
> URL authorization works... sort of! This is where the problem lies...
>
> If the AzImpersonationLevel in the IIS metabase for the virtual folder is
> set to 1 (IIS worker process identity) you can log on successfully (assuming
> you're in the appropriate group) but you seem to have administrative rights
> so you can see and modify all files, even if you do not have access rights to
> them yourself. Not very clever! The application pool is set to run with the
> NETWORK SERVICE identity (if set to IWAM_... I get the same problem as given
> below).
>
> If the AzImpersonationLevel is set to 0 (authenticated client identity) you
> cannot log on and get a 401.3 error (unauthorised due to ACL on resource). I
> know the ACLs on the file system are OK because it was working fine without
> URL Authorization. The URL Authorization store store has read/execute rights
> for authorised users, as does (for good measure) the URLauth.dll file.
>
> Can anyone throw any light on a) why I seem to get admin rights with the
> worker process identity (bit dangerous that) and b) what resource it might be
> complaining about with the client identity.
>
> Many thanks
>
> Ian