Security model (deployment) for MS Access application with SQL Server Backend

We have an application, consisting of an MS Access frontend (2007, mdb format), a few .net libraries and an SQL Server (2008) backend. I am working on an installer, which automatically installs the MS Access Runtime, our application, our libraries, SQL Server Express and configures everything.

Clearly, the MS Access application and the libraries (running in a normal, non-admin user context) need access to the SQL Server database. What is the best way to grant access to the application?

This is what I came up with. Unfortunately, all of these seem to have drawbacks:

• SQL Server Compact Edition: Does not support views.

• Application Roles: This seems to be best practice. However, it requires executing a stored procedure before accessing the database (I cannot pass the app credentials in the connection string). Thus, I cannot use this to attach the SQL Server tables as a linked tables in the Access MDB, which is a requirement of our Access application.

• SQL Server User Instance: To quote from MSDN: "This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work..."

• SQL Authentication: Microsoft says: "When possible, use Windows Authentication."

• Using Windows authentication and granting BUILTIN\USERS full access: This is by far the easiest solution, but somehow it "seems wrong" to do that...

The application is targeted at a non-technical audience, so asking the user to configure permissions is not an option.

EDIT: Some clarification: It's a "local" application, i.e., the SQL开发者_如何学Go Server is located on the same machine as the application; SQL Server access from the network is neither necessary nor desired. The software (a regular business application for managing stocks, invoices, etc.) will be available to download for free, so it should run in a variety of environments (domain/non-domain, different operating systems, etc.), and IT knowledge should not be required to install it -- apart from the usual "click on setup.exe, confirm UAC prompt, acknowledge the installation directory, etc.". I expect the most common scenarios to be "Windows XP, local admin user" and "Windows Vista/7, local admin user with UAC enabled". Since we want to follow good practices, running the application should not require "Run as Administrator" in the latter case.

@Heinzi write:

Using Windows authentication and granting BUILTIN\USERS full access: This is by far the easiest solution, but somehow it "seems wrong" to do that...

The usual approach here is to add a custom user group (e.g., "db-users") and put the users in that group. That way you can control exactly who is allowed access.

How about:

• Use an Access ADP project, pre-configured to connect to the locally installed SQL Server instance.
• Connect using BuiltIn\Users group (or SQL authentication) but grant only the bare minimum credentials. Enough to logon and ...
• Call sp_setappprole to "elevate" the client connection to your defined application role's identity.

If sound like you have only got the tie of the iceberg. When it comes to selling and deploying access SQL applications.

I have take a different route. I have virtual computers as standalone workstation and domain server and workstation all virtual.

I have write a scripts they are a combination of VBA and VBScript. Ask Is the DB and App to run on single computer or different computers. If different computer what is the name of the computer the DB is located on. Is the DB and App to in a workgroup, homegroup or domain environment Is the DB computer already have SQL Express or above Is the App computer already have Access or Access Runtime installed.
If yes which version. Will all or only limited users have access.
If limited what is the user group name of user to be have access to the data. Does this group already exist If No List the Name of the Users that Should Be Added to the Group Also questions about the Admin Users and Group

The script start the virtual machines and goes through a series of steps to rep the MDB and SQL DB for deployment. Then creates an MSI for the Server Install with include a custom script that sets up the environment. Finally packages MDB in a nice MSI.

I have since enhanced the process to allow some questions to be answered at the beginning of the server installation. This means the user groups and users can be selected from the lists in the workstation or domain depending on prior questions asked.

If user the app user is a member of the Admin Group of the Workstation or Domain. They get extra menu options. That allow them to add or remove members from the DB user group for the workstation or domain. This I find is helpful.

I am now moving to the next stage and looking at hosting my assess app as an SasS (Software as a Service) (Rental). So the app can be use in any HTML5 Browser, Windows or Mac as Virtual Desktop or Android and Apple device. Having said that Access is a bit ugly on mobile devices.

When I am up and running I will make the platform available to others.