Went to Lowe's today to get
replacement sand for my three year old's sandbox. I knew that I needed 15 bags, each
weighing 50 lbs. What I did not figure on is the antiquated trolley-thing whose
steering wheels are in the back that I had to use to get all of those bags to my
vehicle. But my son had a blast riding on top of it while his Dad was
trying to maneuver the infernal thing down aisle ways that seem to be blocked by
stacks of stuff, and people who could not seem to understand that
something that heavy does not stop on a dime!
Finally got the thing to my
van and started putting the bags in. My son kept asking
me why I was making all those noises when I was putting the bags in. Don't think
he got the "darn things are heavy and they leak" part. It also had not clicked
for him why I was getting these bags. So finally we got home and unloaded
everything.
Then I told to him that the
sand was for his sandbox.
Ahh... These are the moments
that you live for and cherish as a parent! I LOVE being a
Dad!
7:14:40 PM 
Comment
There have recently been
discussions in many places about running and developing as non-Admin. I figured
that I would add my $0.02 to it.
There is an excellent document
[1] by Lars Bergstrom (Visual Studio Core Team) on MSDN that outlines how
to develop as non-Admin when using VS.NET. I've followed the procedure
documented in it and have had no issues in developing and debugging ASP.NET
applications as a Local User.
Recently, I installed VS.NET 2003
on my primary DEV machine and decided to follow the same instructions and ended
up running into a couple of issues. Hopefully my solutions and work-arounds will
help others who are trying to do the same thing. I am not going to repeat the
existing docs but am just going to document the deltas.
NOTE: My dev machine is Windows
XP Pro.
ProcessModel
By default, my restricted user
login cannot debug Web applications. The web server started up ASP.NET as the
NETWORK_SERVICE account and my user account, which is running the debugger,
does not have the rights to debug other users' programs
(SeDebugPrivelege). The work around for this is to either grant my account
this right or edit machine.config file to run the ASP.NET process under my user
id. The document recommends the latter approach for IIS 5 (Windows XP)
which is what I chose to do.
This is done by changing the
<processModel> from the default of:
<processModel
userName="machine" password="AutoGenerate" ......
/>
to
<processModel userName="YourUserName" password="YourPassword"
...... />
Security Note:
If you do not set a restrictive ACL on the machine.config file, putting your
userid and password in cleartext allows anyone to see your password. Even if you set a restrictive ACL, all users in the Administrators group will still be able to see it.
My resolution to the
above Security Note was the following. Use the aspnet_setreg.exe utility [2] to
put an Encrypted version of my account userid and password in the registry by
using the following command:
aspnet_setreg.exe -k:SOFTWARE\MY_SECURE_APP\processModel -u:"YourUserName"
-p:"YourPassword"
Then modify the
processModel as follows to point it to the
registry:
<processModel
userName="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,password"
...... />
Registry
Permissions
By default the DACL on the
"HKLM\SOFTWARE\MY_SECURE_APP" hive grants Full Control to only System,
Administrators and Creator Owner. Since ASP.NET is running under my userid,
the caveat here is to make sure that I gave my userid (ex. "YourUserName")
Read access to this registry hive where the userid and password are now
stored.
This way, even if someone
peeks into both machine.config and/or the registry they cannot see a cleartext
version of my userid and password.
File system
Permissions
VS.NET 2003 installs version 1.1
version of the .NET Framework. Majority of the file ACL's needed are
the same as documented in [1] except for that the %INSTALLROOT% changes to
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322". So you need to give the
following rights to your account:
- %INSTALLROOT% - Read
-
%INSTALLROOT%Temporary ASP.NET Files - Read and Write
Once I made the above
changes, I've have had no issues developing and debugging Web Applications using
VS.NET 2003.
[1] Developing Software in Visual Studio .NET with Non-Administrative
Privileges
[2] Use the ASP.NET Utility to
Encrypt Credentials and Session State Connection Strings
2:18:01 PM
Comment
