I have legacy web-page-script that needs to add, modify, and delete records in an Microsoft Access-database-file via an ODBC "System" data-source.
Web applications, running in IIS6, cannot perform these tasks without proper NTFS permissions being set on the Access Database file itself.
To set the proper NTFS permissions, I must select the proper IIS built-in user account, and then give that account the minimum permissions necessary for allowing this script to add, modify and delete records.
I've been reading about these built-in IIS accounts here:
Yet, I'm still not clear on which built-in account (and permissions) would be best to use for granting web-applications the ability to modify this Access database.
So far, I've succeeded by giving the "Network Service" account full permissions on the Access database file (this works), but I'm not sure that I've chosen the most optimal built-in account and permissions.
The goal is that I choose the built-in IIS account (and NTFS permissions for that account) (on this Access Database file) that would permit the SQL modifications (the script needs to do), but nothing more than that.
The database file itself, should not be accessible from the web, and IIS should only be able to succeed on the SQL modifications (prescribed by the script).
What would be the best practice in the scenario?
Access is based on the files services of Windows, therefore there is no real distinction between editing the records (insert, update, delete) and modify the database file itself. If IIS is capable of editing the records, then it is also capable of doing anything else. Using the Network Service looks fine to me.
If you really need something more secure, then you should replace Access with something like SQL-Server. By its own design, Access is very unsecure and should never be used for storing any sensitive information.