I have a customer who wants to run all their reporting in Access but they need data from my SQL Server database and I need to be able to filter what data they see by a few parameters. The data needs to be updated frequently, what is the best way to handle this.
You could create a login with read permissions on your prod db, or a login with read permission on "publication db" where you would copy the visible info nightly.
Your question needs to be more precise in terms of timing (real time info or not) and granularity (all details or summarized data), at least.
My suggestion would be to create Views that do any permanent filtering (that is, that filter what you allow the Access user to see). Then create a login with Read on those Views.
From the Access end, link to the Views with Get External Data (by whichever method applies to the Access version), for an ODBC Connection, which contains the login credentials if you're not using Integrated Security on the SQL Server. The Views show up as tables & the user can report to their heart's content.
Related
I'm making an Access database which will be used by multiple people, but I want to make it so that only certain people can edit,add,delete certain tables or fields so data isn't accidentally changed wrongly, and so the data is read-only to the people who don't have permission to edit. Is there any way to do this? Could I even just have access to certain tables or forms password protected?
Access used to have its own security model using an MDW file, but that went away sometime ago. So the short answer is "no". If you are able to introduce SQL Server into the equation, you could store the tables in SQL (or the free version SQL Express). SQL Server offers the security model you need, and you would then link the tables from SQL Server (ODBC) to Access. In this model, SQL Server is managing your data, and Access is your "front end". Once linked, access forms, reports, etc. really don't distinguish between local or attached tables, so all of your same Access skills apply. You can export the tables from Access to SQL using the export feature within Access, and choose ODBC. I'm not sure if you're comfortable doing this, but it's really not all that difficult.
If you do use SQL Server (or Express) you would configure the users and permissions on the tables themselves, using SQL Sever Management Studio. If a user that did not have update permissions, for example, tried to update a row from an Access form, Access would fire the statement at SQL Server which would return a permission error. You could also use SQL Security to implement Windows Authentication, and assign permission to network users. When the statements were fired at SQL Server, they would be authorized based on the users login (when they logged into the network). There would be no need for them to login again.
If you decide to go this way, let me know and I can guide you through it.
I am creating an application that will track hours for employees. Ideally, HR has asked that certain tables not be modified once data is commited. This is done easily enough from the front-end and stored procedures. However, it would be great to be able to prevent it from the server itself through constraints so that folks that have access to the back-end data can't change any values in the selected tables (unless they are sneaky enough to know how to disable the constraints).
If you trust your SQL Server admins then it’s possible. Have your admin to create users that don’t have datawriter permissions for those tables or schema.
So, application would write the data into database and users who have access to those tables would only be able to read the data.
If you don’t want admins to have the ability to modify data that’s not possible. There is no way to prevent it but there is a way to detect it if it happens. Check out this article for details on details how to this is done in third party application and see if it helps.
Use Server Side security roles to give only the HR Group data-write privileges.
Apologies in advance for the long post, I am trying to be as clear as possible. Is there a way to disable a user / Windows AD group accessing a database via SQL Server Management Studio (SSMS)?
I have an desktop application that uses a SQL Server 2005 database. The application runs as the user logged onto the machine (unfortunately we can't change that otherwise this would be simple). The database is permissioned with groups (but it would apply to users as well) to give access to the appropriate schemas and objects that the user requires. The users have (and need) the ability to select, insert, update and delete data to complete their process.
The application carries out a series of validation and auditing steps on the user input to ensure they are entering decent data (and for some additional business processing). A user could open SSMS and make these changes through the query editor avoiding the application completely which is what we are trying to avoid. What I am looking for is a way to stop the users updating the database through any tool other than the application provided.
I have found a couple of similar posts (including How to disable SQL Server Management Studio for a user) but these don't quite cover this issue as they work on restricting user access or using different logins.
The only solution I can think of at the moment is to have a set of tables where the user data goes initially and then another process picks this up, runs the application processes on and then puts the data into the master / source tables. Then I could restrict user access to the master tables.
This appears to be a good scenario for an application role.
I'm building a Windows application that will go against a SQL 2008 database. Some of the table data is very sensitive but some of our users will still need at least read if not read/write access to those tables. We're going to use Windows Security to control their access to the database.
I want to know if those same users can access the data in those tables through something like Excel or MS Access? It's about blocking a bad apple from trying to steal the data inside and walking off with it. If they have read access to the data, though, is there any real way to stop them?
Sorry if this is a SQL Server 101 question, but I'm not finding good answers to the question.
Thanks for the help!
If they have to have read access, then you should pretty much assume they can do what they want with the data. If you render data on the screen, you have to assume someone can write down what they see with a paper and pencil.
With that said, I'd create a service account that has permissions to access SQL Server from your application. Control the access in your app via roles. Do not grant any users access to your database directly - they have to go through your app.
If you try to open Access or Excel and point it to your SQL Server database, they won't have permission to do anything.
A good way to do this might be to author stored procedures that fulfill all of your needs and grant all the users execute only privileges.
If you grant full read access to your users, then yes its going to be difficult to prevent them from what your talking about.
As mentioned by others, you can create a SQL account for your application. This will disallow any outside access from anything other than your application itself. Of course, this would mean that access to your application itself would have to be restricted. This is also easily accomplished by limiting read access to the executable to an active directory group which contains users whom get access. Further to that, you application may also use active directory hooks to determine whether to allow write access for those users who need it.
That all being said though.... your biggest problem will be the physical security. If just one user in the authenticated group is untrustworthy, then a certain acceptable usage policy, HR employee screening, and user environment checks and balances must be in place. A proper workstation deployment policy will also be good here, allowing you to restrict removable drive usage, logging all access, connectivity details etc etc.
It's more about the operational environment at this point if you can't trust the user.
Users could access SQL tables using linked table in Access or external data query in Excel, however the permissions are controlled by the SQL server, which means the users have read-access, they will be able to access data in read-only mode.
We have some corporate intranet users using a WinForms app to work on a system with SQL server behind. Integrated Security is setup, allowing all users update and delete permissions, where application security limits how and where table updates take place.
However, some users are power users with SQL query tools at their disposal, and access the DB directly for building reports. However, with integrated security, they have default update rights on tables where they should not have, as the application apply rules to the updates.
Is this an example of where it's more appropriate providing the app with a central SQL authenticated login, whilst users get read only rights for integrated security?
As Jon mentioned stored procedures would give you the protection over direct table modifications. There are other options too. You can use SQL Server's "Application Role" (via sp_setapprole proc). This enables you to continue to use a separate ID for everyone but only at application connection time (through the front-end) are the user's rights elevated.
A major downside to using a shared ID is you lose track of who is submitting SQL to the server though if they're all internal you can get to the machine name.
Something else is concerning though. It sounds as if your users can connect to the database and run queries at will. You run a major risk of downtime in the application due to user behavior in the directly connected SQL sessions. If you can pull it off you may want to try to have a reporting database created that is updated at intervals that your business can tolerate, i.e., daily. HTH
I presume from the way that you've worded your question that your app executes sql statements directly. If you could refactor it so that it executes stored procedures, you could grant exec rights on the procedures and deny direct updating of the tables. This might not be possible though, depending on what your app does.
sql authentication is one option. Stored procedures are another. However, building more granular roles for assigning just the appropriate permissions to just the appropriate user types is where you should really be looking.
Additionally, I would really avoid giving these users direct access to the DB at all. Security reasons aside, it doesn't take much for a user who isn't proficient in SQL to accidentally execute a query that will swamp your database server and create an effective denial of service. Even pros can do this accidentally from time to time.
Instead, give them access to a reporting services or analysis services type solution, or use replication to give them access to a clone of the data. This way your production system is protected.
Personally I would do all application data access through stored procedures. I would set Integrated security to only allow users to run the SP's and not manipulate the data directly.
Advanced access can be given to DB admins to manipulate the data directly when needed.
Group based permissions will provide you with much more flexibility for access rights, and less administrative burden when controlling these with integrated security.