"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:ecQYtAzWDHA.1492@TK2MSFTNGP12.phx.gbl...
> If you reset ACLs to allow anonymous access and everything works (even for
> the "Authenticated") case, then I question whether you are actually
> authenticating.
>
> I can note that the default web directories that IIS sets up serves as an
> illustration of what would work. I could not reproduce your claims using
> ACLs from those default web directories. You should see whether it works
> for you as well before touching ACLs.
>
> The basics of ACLs come down to this:
> 1. The Resource (like the script itself) and the ScriptMap Engine (and
> associated resources) must be accessible to the remote authenticated user
> 2. The remote authenticated user is the configured Anonymous User (default
> is IUSR) for anonymous and the logged in user for any other authentication
> protocol.
> 3. IIS_WPG should have list ACL on the resource to be able to cache it.
On
> a DC, where IIS_WPG is not allowed, the resource must be list ACL'd to
> individual members of the IIS_WPG group.
>
> In the end, you just match the ACLs on the resources with the remote
> authenticated users that need access.. You should see at least the above
> basics if you look at \inetpub\wwwroot.
>
> --
> //David
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message
> news:uyIayTuWDHA.2444@tk2msftngp13.phx.gbl...
> I have reset the ACL to allow anonymous access and everything works. What
> next?
>
> "David Wang [Msft]" <someone@online.microsoft.com> wrote in message
> news:%23OGnXIKWDHA.2056@TK2MSFTNGP11.phx.gbl...
> > If you make requests of the form
> > http://cvstest/viewcvs/viewcvs.cgi/modulename , does that work?
> >
> > Namely, does this CGI depend on PATH_INFO or not? I am suspecting it
> does.
> >
> > I tried to duplicate it by doing the following:
> > 1. I set a Scriptmap of .cgi to C:\Inetpub\wwwroot\MyCGI.EXE
(avoiding
> > any ACL issues)
> > 2. I set DefaultDoc on / to be test.cgi
> > 3. I created a file test.cgi so that DefaultDoc works
> >
> > I made a request to http://localhost/ and http:/localhost/test.cgi
under
> > anonymous, basic, and NTLM, and all passed (they invoked MyCGI.EXE to
> return
> > content).
> >
> > I am using default ACLs, default AppPoolId of Network Service.
> >
> > I do not immediately know what is wrong in your scenario, but if you can
> get
> > it working in the default case, we can work on lockdown.
> >
> > I believe the Authentication issue with NTLM is separate from the "Bad
> > Headers" issue, so let's take it one at a time. Let's get the files
> working
> > to not return "Bad Headers" first. NTLM is a connection-based protocol,
> so
> > I want to ask you whether the CGI works with keep-alive correctly or
not.
> >
> > --
> > //David
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > //
> > "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message
> > news:uMxwr4DWDHA.2316@TK2MSFTNGP09.phx.gbl...
> > I have used Basic and Windows Integrated Authentication. They behave
> > differently. They both behave the same for the originally described
> problem.
> > After using the http://cvstest/viewcvs/ URL and successfully
> > authenticating, there are links in the format
> > http://cvstest/viewcvs/viewcvs.cgi/modulename. If I've authenticated
with
> > Basic, these links work, with Integrated they do not.
> >
> > By the way, viewcvs is a virtual directory on the same machine.
> >
> > App Pool Identity is Network Service. I've tried local system as well.
> >
> > ACL is Local Administrators Group, CVS Users Group and SYSTEM all have
> full
> > control.
> >
> > Do know the answer to "How is cgi scriptmapped?"
> >
> > viewcvs.cgi is the only default document.
> >
> > > I am therefore thinking of what would cause the IIS resolution and
> > > re-execution to fail, and I'm looking at the request up to the
> > ScriptEngine.
> >
> > The redirect case is the one that works, it's the explicit URL
> > http://cvstest/viewcvs/viewcvs.cgi that does not.
> >
> > Thanks...
> >
> > Mark
> >
> >
> > "David Wang [Msft]" <someone@online.microsoft.com> wrote in message
> > news:es3GNOBWDHA.212@TK2MSFTNGP12.phx.gbl...
> > > How did you configure authenticated access (what sort of
> authentication).
> > >
> > > Are you running with a custom AppPoolIdentity.
> > >
> > > What are the ACLs on the accessed resources.
> > >
> > > How is .cgi scriptmapped (does it have ScriptEngine/File not Found
> > options).
> > >
> > > If you configure viewcvs.cgi as a DefaultDoc (is it the only one?),
both
> > > URLs are the same. The first one will cause IIS to send a courtesy
> > redirect
> > > to http://cvstest/viewcvs/ back to the client, and when the client
> > requests
> > > this URL behind-the-scenes, IIS would resolve / to /viewcvs.cgi and
> > execute
> > > http://cvstest/viewcvs/viewcvs.cgi using the ScriptEngine configured
for
> > the
> > > .cgi Scriptmap -- the same as if you made a direct request to it.
> > >
> > > I am therefore thinking of what would cause the IIS resolution and
> > > re-execution to fail, and I'm looking at the request up to the
> > ScriptEngine.
> > >
> > > --
> > > //David
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > //
> > > "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message
> > > news:en4FMI$VDHA.2248@TK2MSFTNGP10.phx.gbl...
> > > I am trying to execute a python script on IIS 6 as follows:
> > >
> > > Anonymous access
> > > http://cvstest/viewcvs and http://cvstest/viewcvs/viewcvs.cgi
> > > Both of the above work. I have made viewcvs.cgi a default page for the
> > > directory.
> > >
> > > Authenticated access:
> > > Removed anonymous access, added ACL for user group. viewcvs.cgi
remains
> a
> > > default page for the directory.
> > > http://cvstest/viewcvs presents authentication dialog and works.
> > > http://cvstest/viewcvs/viewcvs.cgi does not present authentication
> dialog.
> > > Returns:
> > >
> > > ********************************
> > > CGI Error
> > > The specified CGI application misbehaved by not returning a complete
set
> > of
> > > HTTP headers.
> > >
> > > *********************************
> > >
> > > The script is unchanged in all cases. Only the NTFS permissions are
> > changed
> > >
> > > -- Thanks in advance....
> > > ------------------------------------------
> > > Mark Hildreth
> > > IT Response, Inc.
> > > 205 Rustic Place
> > > San Ramon, CA 94583
> > > mark@ITResponse.com
> > > (925) 828-7650
> > > (925) 699-6800 (cell)
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>

"Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message
news:%23f4R6h3WDHA.652@tk2msftngp13.phx.gbl...

"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:ecQYtAzWDHA.1492@TK2MSFTNGP12.phx.gbl...
> If you reset ACLs to allow anonymous access and everything works (even for
> the "Authenticated") case, then I question whether you are actually
> authenticating.
>
> I can note that the default web directories that IIS sets up serves as an
> illustration of what would work. I could not reproduce your claims using
> ACLs from those default web directories. You should see whether it works
> for you as well before touching ACLs.
>
> The basics of ACLs come down to this:
> 1. The Resource (like the script itself) and the ScriptMap Engine (and
> associated resources) must be accessible to the remote authenticated user
> 2. The remote authenticated user is the configured Anonymous User (default
> is IUSR) for anonymous and the logged in user for any other authentication
> protocol.
> 3. IIS_WPG should have list ACL on the resource to be able to cache it.
On
> a DC, where IIS_WPG is not allowed, the resource must be list ACL'd to
> individual members of the IIS_WPG group.
>
> In the end, you just match the ACLs on the resources with the remote
> authenticated users that need access.. You should see at least the above
> basics if you look at \inetpub\wwwroot.
>
> --
> //David
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message
> news:uyIayTuWDHA.2444@tk2msftngp13.phx.gbl...
> I have reset the ACL to allow anonymous access and everything works. What
> next?
>
> "David Wang [Msft]" <someone@online.microsoft.com> wrote in message
> news:%23OGnXIKWDHA.2056@TK2MSFTNGP11.phx.gbl...
> > If you make requests of the form
> > http://cvstest/viewcvs/viewcvs.cgi/modulename , does that work?
> >
> > Namely, does this CGI depend on PATH_INFO or not? I am suspecting it
> does.
> >
> > I tried to duplicate it by doing the following:
> > 1. I set a Scriptmap of .cgi to C:\Inetpub\wwwroot\MyCGI.EXE
(avoiding
> > any ACL issues)
> > 2. I set DefaultDoc on / to be test.cgi
> > 3. I created a file test.cgi so that DefaultDoc works
> >
> > I made a request to http://localhost/ and http:/localhost/test.cgi
under
> > anonymous, basic, and NTLM, and all passed (they invoked MyCGI.EXE to
> return
> > content).
> >
> > I am using default ACLs, default AppPoolId of Network Service.
> >
> > I do not immediately know what is wrong in your scenario, but if you can
> get
> > it working in the default case, we can work on lockdown.
> >
> > I believe the Authentication issue with NTLM is separate from the "Bad
> > Headers" issue, so let's take it one at a time. Let's get the files
> working
> > to not return "Bad Headers" first. NTLM is a connection-based protocol,
> so
> > I want to ask you whether the CGI works with keep-alive correctly or
not.
> >
> > --
> > //David
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > //
> > "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message
> > news:uMxwr4DWDHA.2316@TK2MSFTNGP09.phx.gbl...
> > I have used Basic and Windows Integrated Authentication. They behave
> > differently. They both behave the same for the originally described
> problem.
> > After using the http://cvstest/viewcvs/ URL and successfully
> > authenticating, there are links in the format
> > http://cvstest/viewcvs/viewcvs.cgi/modulename. If I've authenticated
with
> > Basic, these links work, with Integrated they do not.
> >
> > By the way, viewcvs is a virtual directory on the same machine.
> >
> > App Pool Identity is Network Service. I've tried local system as well.
> >
> > ACL is Local Administrators Group, CVS Users Group and SYSTEM all have
> full
> > control.
> >
> > Do know the answer to "How is cgi scriptmapped?"
> >
> > viewcvs.cgi is the only default document.
> >
> > > I am therefore thinking of what would cause the IIS resolution and
> > > re-execution to fail, and I'm looking at the request up to the
> > ScriptEngine.
> >
> > The redirect case is the one that works, it's the explicit URL
> > http://cvstest/viewcvs/viewcvs.cgi that does not.
> >
> > Thanks...
> >
> > Mark
> >
> >
> > "David Wang [Msft]" <someone@online.microsoft.com> wrote in message
> > news:es3GNOBWDHA.212@TK2MSFTNGP12.phx.gbl...
> > > How did you configure authenticated access (what sort of
> authentication).
> > >
> > > Are you running with a custom AppPoolIdentity.
> > >
> > > What are the ACLs on the accessed resources.
> > >
> > > How is .cgi scriptmapped (does it have ScriptEngine/File not Found
> > options).
> > >
> > > If you configure viewcvs.cgi as a DefaultDoc (is it the only one?),
both
> > > URLs are the same. The first one will cause IIS to send a courtesy
> > redirect
> > > to http://cvstest/viewcvs/ back to the client, and when the client
> > requests
> > > this URL behind-the-scenes, IIS would resolve / to /viewcvs.cgi and
> > execute
> > > http://cvstest/viewcvs/viewcvs.cgi using the ScriptEngine configured
for
> > the
> > > .cgi Scriptmap -- the same as if you made a direct request to it.
> > >
> > > I am therefore thinking of what would cause the IIS resolution and
> > > re-execution to fail, and I'm looking at the request up to the
> > ScriptEngine.
> > >
> > > --
> > > //David
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > //
> > > "Mark Hildreth" <mhildreth@sbcglobal.net> wrote in message
> > > news:en4FMI$VDHA.2248@TK2MSFTNGP10.phx.gbl...