Sten has asked for the wisdom of the Perl Monks concerning the following question:

Hi,
I create a cgi script (perl) that does some maintenance jobs, deleting old files, backup files, and other tasks. All maintenancejobs started manually from my cgi script, using popupmenus and submit knobs.

This is no problem to do, as long as I'm maintaining the IIS servers local disks, but when trying to access/maintain "everyone-full-control-shares" on a cople of other servers, I get access denied. (Servers are in workgroups, not in domains)
access Denied is good for securityreasons, but not good for what I want to achieve with my script, just now.

There is probably a possibility to set up the remote shares I want to maintain as zero-session-share, but I would prefer to pass on a login and a password, and get access that way, or at least in one way or another (pretend to) have som security. Anyone who can give me some directions/ideas?

The maintainroutine in my script, can be called from dos prompt, with some arguments, that works fine, and mapped shares are accessed/maintaned without any problem. So the access-denied-problem is due to the 'cgi/web' enviroment restrictions.

Regards
Sten

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

Replies are listed 'Best First'.
Re: W32: How can cgi scripts access shares on other w32 servers
by Jenda (Abbot) on May 06, 2003 at 20:39 UTC

    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

[reply]

      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).

[reply]
Re: W32: How can cgi scripts access shares on other w32 servers
by meredith (Friar) on May 07, 2003 at 01:27 UTC
    You'll want to look in the docs for Win32::NetResource. You can use RESOURCETYPE_ANY to avoid mapping a drive (just authenticate and hold connection) or, if you prefer the non-stored-password approach, you can make calls to "NET USE /user:foobar \\SERVER\IPC$". Don't forget to close connections when you're done! Oh, just a caveat: if you run this script on a 9x machine, you must have a matched up user and password, it won't let you use a different username.

    ----mhoward----
[reply]

Back to Seekers of Perl Wisdom