ASPState Select Permission Denied

I've been scouring the 'Net and I'm surprised to not find any info on this. Apparently I've screwed up something that nobody else has managed to screw up.

Using Win03EE and SQL2005.

I created the ASPState database using "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Aspnet_regsql.exe" using "-sstype p" to put the data in ASPState instead of tempdb.

During the creation I used an admin SQL login (let's call it "MyAdmin") that has full admin permissions. (MyAdmin is a SQL login, not a domain account.) I then created an "ASPState" SQL login (not domain) and gave it full permissions within the ASPState database.

I should probably note that the Win03EE server is also a domain controller even though the SQL logins I'm using are non-domain. This is because, currently, the development workstations are not part of the server's domain. Since the entire environment is strictly for research and development, optimum security is not the first concern at this point.

When I run the ASP.NET 2.0 web application with the connection string set to use the MyAdmin account, everything works fine. I can even poke around in ASPState with SSMS and see the session entries being inserted in the tables.

When I run the application with the connection string set to use the "ASPState" login, I get "SELECT permission denied on object 'sysobjects', database 'mssqlsystemresource', schema 'sys'".

If I give ASPState sysadmin priviledges, it works. Of course, I don't want to give ASPState sysadmin priviledges.

I have seen non-ASPState issues posted on the 'Net involving permission denied and mssqlsystemresource. From those I've come to understand that this likely has to do with the changes made to SQL2005 that are probably not anticipated by the current version of aspnet_reqsql.

So... can anyone help me save what's left of my hair from being pulled out any further? I've been clicking various permission settings on and off all day long with no results. The lack of correlation between mssqlsystemresource and what permission setting is needed where is pretty frustrating.

In addition to the solution to this problem, I'd really appreciate any info anyone has on a great place to go read about security setting adjustment considerations in light of the changes made in SQL2005. In particular, what changes from SQL2000 to SQL2005 impact the operation of existing SQL2000 code and what an admin should know about adjusting security settings.

Thanks!

I was about to explain the reason with a resolution by referring a KBA, but found this interesting page http://idunno.org/dotNet/sessionState.aspx on web in this regard.