in reply to W32: How can cgi scripts access shares on other w32 servers

Wouldn't it be better to use the Task Scheduler to schedule a script that does the maintenance? And sends you a report by email or whatever.

Anyway ... is your CGI script running under the default IUSR_... account or under your account? In this case you should allow "Integrated Windows Authentication" and change the permissions to the script so that IUSR_ cannot read it. When you access the script then you either get a login dialog or get authentified automaticaly (if you are on the same computer or in the same domain). And since the script now runs under whatever your account it should have access to the network shares.

I say should because I've always worked with a domain, not a workgroup.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature

  • Comment on Re: W32: How can cgi scripts access shares on other w32 servers

Replies are listed 'Best First'.
Re: Re: W32: How can cgi scripts access shares on other w32 servers
by grantm (Parson) on May 06, 2003 at 22:05 UTC

    The "Integrated Windows Authentication" is great for working with file permissions on the web server's local drives, but it can't be used for accessing remote shares. To access remote shares, you'll need to enable basic authentication. My (somewhat sketchy) understanding of why this is the case is as follows:

    If the browser authenticates transparently with the server using NTLM (aka Integrated Windows Authentication) then the CGI script has a security token of type 'network'.

    If basic authentication is used, the security token is the same as if the user logged on to the console of the server (in fact at least until IIS4.0, IUSR_machine_name required "Log on locally" rights).

    Under the NT domain security model, a 'local' security token can be used to access networked resources but a 'network' security token can only be used to access local resources. Or to put it another way, a process running with a local token can delegate that authority across the network. Network tokens cannot be delegated.

    For more info, see this article on MSDN.

    Note: This is the same reason why integrated database security can only be used to propogate users' credentials from IIS to SQLServer if the database is running on the same server as IIS.

    Update: Here's another article on the subject. Apparently the correct terminology for the types of token is "Primary Token" (can be delegated) and "Impersonation Token" (cannot be delegated).