IIS Metabase GetObject call returning error 424 object required error

Question

We have an ASP Classic website running on Windows Server 2003 and IIS6 which is throwing intermittent runtime error 424 object required. We've tracked this down to the line which initialises the object reference to the metabase as shown below (second line):

MetaBasePath="IIS://" & ComputerName & "/" & StorageKey & "/" & DataAccessKey
Set ConfigKey=GetObject(MetaBasePath)
DataSource=ConfigKey.Get("ODBCDataSource")
UserName=ConfigKey.Get("ODBCUserName")
Password=ConfigKey.Get("ODBCPassword")

I've searched stackoverflow (and the web in general) for any signs of anyone else having this issue but have drawn a blank. Does anyone have any ideas what could be causing this? Are there any performance related settings which control the frequency of access to the Metabase? Are there any best practice measure we can employ to improve the efficiency of Metabase access? Are we correct in assuming that we are doing the right thing by hiding our database access details in the Metabase or is this overkill in terms of security?

This issue affects us on approximately 1% of page hits.

We are looking at a range of actions including checking the patch level of the server software components and potentially adding a loop around the above code to keep trying until the Metabase object is initialised correctly but this would at best be a short term fix in my opinion.

Advice most welcome! Thanks, Craig.

Additional info: Just discovered that IIS5.0 Isolation Mode is enabled. I'm trying to find out why this was enabled but could this be relevant?

Answer 1

IIS Metabases are NOT meant for security, but merely for convenience.

Its just a central repository for data shared by several virtual servers (IIS/ASP applications). So you if are using it just for security purposes, then Metabase is not needed at all.

Because:

• Who are you "hiding our database access details" from? The programmer? But he HAS access to it already. After assigning ConfigKey.Get("ODBCPassword") to Password, any response.write would reveal it. Even if that is done in global.asa, somewhere you will have to convert it to a connection string (or store it in an Application variable) so .asp pages can create the database connection objects. At some point between the Metabase and the object creation he WILL have access to the connection properties.

• Dont even think about preventing this by creating the connection object at global.asa and storing the object itself in an Application variable. (thus hiding the creation from programmer-accesible files). Not only this kills connection pooling, but its a huge negative performance hit.

If you are concerned about database security from ASP pages, here are some approaches i suggest:

• Create a different database user for website access, with very limited priviledges. Meaning SELECT, INSERT, UPDATE, DELETE and EXECUTE (stored procedures) only. No DROP, CREATE, ALTER, etc. This way, any "password leakage" or "programmer misuse" would not seriously compromise the database. The "admin" user password, with full priviledges, would never be accessible (or used) anywhere in the website.

• Create an ActiveX (or COM, DCOM) DLL to wrap the connection settings. It could be writen in C#, VB.NET or even classic VB6. It would read login and password from another (secure and web-innacessible) server file, create the connection object, and pass it to ASP directly.

So instead of using:

set objConn = Server.CreateObject("ADODB.Connection")

The ASP pages would use:

set objConn = Server.CreateObject("MYCLASS.Connection")

The config file itself could even be encrypted, as the decripit algorithm would be stored in the compiled code, NOT in a plain text ASP file.

That said, I dont mean the Metabase is useless. Its still a good, convenient place to store data, because:

• Data can be changed without changing any line of code

• Several websites can share data, even when each has it own isolated app

• Centralized data is always easier to mantain than keeping config and include files scattered all over the filesystem

• User/NTFS permititions can be set up in a way that only authorized people can change the data, but website users (and ASP developers) can only read it

That said, the "limited database user" + "COM class connection wrapper" is the approach used in most companies ive worked with. The ones concerned about security, of course. The others just use the "connection string hardcoded in global.asa then stored in application variable".