Modify registry keys under HKEY_CURRENT_USER or HKEY_USERS\<SID> from a component inside the IIS

[brd]

Modify registry keys under HKEY_CURRENT_USER or HKEY_USERS\<SID> from a
component inside the IIS



I have to create and modify keys and values from the registry under
HKEY_CURRENT_USER from the thread where the component is running. If the
component was invoked from visual basic script everything works fine. If the
component was invoked from asp I got the error 'access denied'. With a
registry monitor I saw that all my operations in the registry are mapped to
HKEY_USERS\.DEFAULT instead of HKEY_CURRENT_USER. If I create a process
(like cmd.exe) for the same user while the IIS is working the component
works fine. So I think if there is any process or thread interactive on the
same machine the component invoked from the IIS works fine. So I tried to
access the registry with the user SID HKEY_USERS\<SID> but this didn't work
too. I got the error 'parameter incorrect'. If I create a process (like
cmd.exe) for the same user again, it works fine. So what do I have to do to
modify the registry inside the IIS?



System:W2003 Server



Thanks

Andreas

[Patrick Philippot]

Hi Andreas,

Post by brd
Modify registry keys under HKEY_CURRENT_USER or HKEY_USERS\<SID> from
a component inside the IIS

First, you should think twice about the idea of "current user" when
executing the code of an ASP page on a IIS server. Normally, you don't
have any user logged on at this time. So the idea itself doesn't really
make sense :-) .

Second, assuming there's a logged on user on the IIS server when the
code of your ASP page executes, this code (fortunately) doesn't execute
under the "current user" 's account (imagine the consequences if the
system admin is logged on). The thread executing this code impersonates
either the anonymous IIS user or another user if you are using Windows
authentication for this site.

Let's assume you are using anonymous access. In that case, IIS
impersonates the IUSR_<machine_name> user and the system applies to the
page code the permissions granted to this user, which are fairly
limited, of course.

So whatever you want to do, trying to write to the HKCU registry key
from the code of an ASP page is certainly a *very* bad idea.

Tell us what kind of information you want to store, and maybe we'll be
able to suggest a solution.

[brd]

Hi Patrick



Ok - the history is very long but I will try to explain it very shortly. The
component wasn't designed to run only inside the IIS there are also other
programs that use the component. The first system on which the component
runs was NT4 and the registry modifications were done under HKLM. The data
which should be stored are different, but most of them are configuration
data which are stored on other servers (configuration or resource servers).
The reason to store the data in the registry was to stabilize the component
and reduce the dependencies to the other components. I want that this
component was able to run if there was no access to the configuration
servers or no running resource component. I want to get the possibility to
check the configuration data very easily on the machine where the component
was running, because many times it was the wrong configuration server with
different data. I want to change the configuration data (for test) on the
machine where the one component was running without accessing the
configuration server because this impacts all components in the network. The
registry has the best API for my requirements and it performs very well. So
I hope you can understand my decision using the registry. With W2k, XP and
W2003 the ACL of the registry has changed very heavy, so I tried to use
HKEY_CURRENT_USER instead of HKLM with the described result.



And you are right we are using anonymous access.



Andreas

Post by Patrick Philippot
Hi Andreas,

Post by brd
Modify registry keys under HKEY_CURRENT_USER or HKEY_USERS\<SID> from
a component inside the IIS

First, you should think twice about the idea of "current user" when
executing the code of an ASP page on a IIS server. Normally, you don't
have any user logged on at this time. So the idea itself doesn't really
make sense :-) .
Second, assuming there's a logged on user on the IIS server when the code
of your ASP page executes, this code (fortunately) doesn't execute under
the "current user" 's account (imagine the consequences if the system
admin is logged on). The thread executing this code impersonates either
the anonymous IIS user or another user if you are using Windows
authentication for this site.
Let's assume you are using anonymous access. In that case, IIS
impersonates the IUSR_<machine_name> user and the system applies to the
page code the permissions granted to this user, which are fairly limited,
of course.
So whatever you want to do, trying to write to the HKCU registry key from
the code of an ASP page is certainly a *very* bad idea.
Tell us what kind of information you want to store, and maybe we'll be
able to suggest a solution.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

[Patrick Philippot]

Andreas,

I understand your reasons for storing data to the registry (although I'm
not convinced that this mechanism is the fastest available). Since your
code is running under the IUSR_<machine_name> account, you'll be able to
write to whatever key of the registry you want, provided you set the
registry permissions accordingly.

Giving access to the whole HKCU or HKLM tree would obviously be a
serious mistake. But nothing prevents you from granting IUSR_xxxxx write
access only to the specific key your component is using. I would not use
HKCU anyway because if you change the security policy of your IIS
application later, this will break the whole mechanism.

Of course, this assumes that you master the administration of the IIS
server where your application is running. If the application is to be
sold to other companies as a package, you'll have a hard time convincing
their admins that they should give extended rights to IUSR_xxxx.

IMHO, I would chose another way of storing your configuration data:

- Since they are buffered in memory, INI files are not that slow :-)

- I guess you do have a database handy on your server. Retrieving these
data from SQL Server or Oracle locally might not be that slow too when
compared to the registry (which is merely another database).

- You can design your own storing mechanism, specifically tuned for your
needs

- You could use the Shared Property Manager (SPM) although it has a
serious drawback: it is very fast but all data are lost when the server
shuts down. So you should imagine a serialization mechanism in order to
enable data restoration when IIS shuts down or crashes for any reason.

These articles could help:

http://msdn.microsoft.com/msdnmag/issues/1100/instincts/
http://www.topxml.com/conference/wrox/2000_vegas/text/jimmy_cache.pdf

[brd]

Patrick,



The first implementation was using INI files, but maybe you can remember the
msdn articles which force the programmers to use the registry instead?

A database on the server doesn't exist and it is not possible for me to
require this environment on an IIS Server.

The component runs also on server without an IIS.



I thank you for your suggestions.



Regards

Andreas

Post by Patrick Philippot
Andreas,
I understand your reasons for storing data to the registry (although I'm
not convinced that this mechanism is the fastest available). Since your
code is running under the IUSR_<machine_name> account, you'll be able to
write to whatever key of the registry you want, provided you set the
registry permissions accordingly.
Giving access to the whole HKCU or HKLM tree would obviously be a serious
mistake. But nothing prevents you from granting IUSR_xxxxx write access
only to the specific key your component is using. I would not use HKCU
anyway because if you change the security policy of your IIS application
later, this will break the whole mechanism.
Of course, this assumes that you master the administration of the IIS
server where your application is running. If the application is to be sold
to other companies as a package, you'll have a hard time convincing their
admins that they should give extended rights to IUSR_xxxx.
- Since they are buffered in memory, INI files are not that slow :-)
- I guess you do have a database handy on your server. Retrieving these
data from SQL Server or Oracle locally might not be that slow too when
compared to the registry (which is merely another database).
- You can design your own storing mechanism, specifically tuned for your
needs
- You could use the Shared Property Manager (SPM) although it has a
serious drawback: it is very fast but all data are lost when the server
shuts down. So you should imagine a serialization mechanism in order to
enable data restoration when IIS shuts down or crashes for any reason.
http://msdn.microsoft.com/msdnmag/issues/1100/instincts/
http://www.topxml.com/conference/wrox/2000_vegas/text/jimmy_cache.pdf
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

[Patrick Philippot]

Post by brd
The first implementation was using INI files, but maybe you can
remember the msdn articles which force the programmers to use the
registry instead?

Yes, but it seems that Microsoft have changed their mind about this. And
so did I. The problem is that the registry has grown too big on many
systems. Despîte the enhancements on XP and 2003, this directly affects
performance (the bigger the registry, the slower the system). So INI
files are no longer "evil".

For standard applications, this is why C:\Documents and
Settings\<username> is there. Applications are encouraged to store user
data in this folder, not in the registry. They can use whatever format
they want. Win32 apps use INI files, .Net apps use XML files,... For
data not related to a particular user, use C:\Documents and Settings\All
Users\<company_name>\<app_name> . Use SHGetFolderPath to get the actual
folder.

[Patrick Philippot]

Hi Andreas,

Post by brd
Modify registry keys under HKEY_CURRENT_USER or HKEY_USERS\<SID> from
a component inside the IIS

First, you should think twice about the idea of "current user" when
executing the code of an ASP page on a IIS server. Normally, you don't
have any user logged on at this time. So the idea itself doesn't really
make sense :-) .

Second, assuming there's a logged on user on the IIS server when the
code of your ASP page executes, this code (fortunately) doesn't execute
under the "current user" 's account (imagine the consequences if the
system admin is logged on). The thread executing this code impersonates
either the anonymous IIS user or another user if you are using Windows
authentication for this site.

Let's assume you are using anonymous access. In that case, IIS
impersonates the IUSR_<machine_name> user and the system applies to the
page code the permissions granted to this user, which are fairly
limited, of course.

So whatever you want to do, trying to write to the HKCU registry key
from the code of an ASP page is certainly a *very* bad idea.

Tell us what kind of information you want to store, and maybe we'll be
able to suggest a solution.