Script user rights

By Michiel van Otegem
28 May 2001

When a user requests a page on your server, that user (or actually the script in the page) can do certain things. What... that depends on the situation, or actually the identity used with the execution of tasks.

Script rights

The webserver normally works under a special user account, the IUSR_machinename account. This account is automatically created when you install IIS (or PWS). This means that all the files that are on your website, can be read when that user has rights to read that file. This is the case when that specific user has those rights OR when the usergroup Everyone does(!). Otherwise a log-in screen appears and you have to log-in as a user that does have rights to open the file. All the files outsite the website of course can't be requested just like that. The script can however open these files using the Scripting.FileSystemObject.

Through the IUSR account you can't request files through the network. Then a log-in screen will also appear in the browser. This is because the IUSR account is tied to the server, it's not a domain account, but a local server account. To make this possible the IUSR has to be replaced by a domain account. However, this isn't recommendable, because a hack on the server will also give access to the rest of the network.

You can change the user that IIS works under with the Internet Service Manager. This also has consequences for what IIS can and cannot do. Make sure that this user does have the required rights on components needed to run ASP. Otherwise all you get back is a blanc page, without an error message (thus difficult to trace...).

Component rights

When a script calls a component, the user under which the component is executed may change identity. Everything that's done from the component, is done by that new identity. What identity this is, depends on the kind of component.

An in-process component
A so called in-process component works in the same proces-space as the script, in fact they're the same program. This is why Single Threaded Appartment (STA) components, as made with Visual Basic 5.0 and higher, have the same identity. With other types of components all operations invoked in component from the script occur through a so called proxy, that serves a bit like a translator. These components get the identity of the System account. This means it has access to ALL resources on the server, but none on the rest of the network, since this is a local server account. It's clear that the rights of this account sometimes can be too great, but also sometimes to little. You can solve this by using Windows Component Services (formerly Microsoft Transaction Server). You can give a component that runs under WCS an identity explicitely. This can be a local account, but also an account that's part of your network domain. The first one is handy when you don't want to give acces to everything, the last one is handy when you have to get something over the network.

An out-of-process component
A so called out-of-process component works in its own proces-space. The advantage of this is that when the component fails, the webserver just goes on (normally the server would also crash). The disadvantage however is that it demands a lot of the server, this is why ASP 2.0 didn't allow the usage of out-of-process components by default (ASP 3.0 does). To be able to do this, you have to change the registry and put the HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/W3SVC/ASP/Parameters/AllowOutOfProcCmpnts key on 1.

An out-of-process component works under the IWAM_machinename account by default. The same rules apply as for the IUSR_machinename account. An out-of-process component can't work under WCS, so if you want to change the identity of such a component, you'll have to do it in another way. You can do it with the DCOM Configuration tool dcomcnfg.exe.