How can I implement security accounts in an Employee Database in Microsoft Access 2010 which allows for different users to login with different permission sets. e.g:-
I have a database which has Managers, Supervisors, and clerks or assistants, and only 1 full administrator.
I have already set a table: tblAccount, tblEmployee
**EmployeeIDP**
Name
Surname
StartedOn
FinishedOn
EmployeedType - Look up:- Admin/Manager/Supervisor/Clerk/Temporary
**AccountIDP**
Username
Password
**EmployeeIDF**
LastLogin
Permissions - look up:- Full Access/Manage accounts/Read accounts only/No access
Without trying to give you the whole specification of the database how can I prevent certain users from accessing the accounts table or form?
I have already implemented a login form and each user is logged using VBA but this was easier than trying to implement permissions to tables/fields etc...
I want to prevent clerks from seeing other accounts, and prevent supervisors from adding/deleting, Managers can add new users an do anything other than delete tables or change the structure of the database.
Obviously the administrator can do anything.
Is this even possibly without advanced VBA.
Depends on the access you give the users. You said you already have a login form that tracks access.
Are all your forms controlled from a startup dashboard page?
Are the users viewing only authorized buttons/links on the dashboard based on their log in?
You could hide all objects (queries, tables forms, reports), give access only through the dashboard, create a .mde or a accde front end where you distribute an encrypted frontend to users. You can then control who can open which data sets, through the forms. This won’t stop a determined programmer but for your usual users, it will work as you get a more robust system.
I have a hidden form that opens after user logs on. The form has field that can be referenced by any process.
DoCmd.OpenForm "frm_global_variables", acNormal, "", "", , acHidden
I answered this in past how to implement user level security in MS Access 2007
There was once workgroup security feature from Microsoft, but it is no more there, was discontinued. But now we will have build our logic & coding for the roles & security feature.
I created a privilege table along with log-in table. Each screen in the database will have Read-only or Read-write privilege to each user. I inserted all the screen names into privilege table. Another table UserPrivilege will have users and their privileges. Assigning privilege to an user will be done only by Admin user.
A function at start of each form check swhether a specified user is allowed to view or edit form. If he/she is given read-only, we will lock all controls looping thr' controls on the form. Else, nothing to do. OR keep all the controls read-only at design them and unlock them thr' code for write privilege.
The database window is kept hidden when a version to end user is delivered. This prevents usual , simple view to tables in the database, opening forms , reports object in database window. After making mde/accde few more tweaks can be done so that user is not easily able to view tables directly. by-passing startup, special keys etc.
Related
I have created an SSRS report which I am using in Asp.net website. Reports accepts server, database,user and password to create connection string dynamically. Dynamic connection string is required because user can select a database at the time of log-in and that database need to be used for SSRS.
One requirement is such that user should be able to create SSRS report himself. For the purpose I provided guideline that how to create parameters that are require data-source's dynamic connection string.
One possible problem I thought is if user do not make parameters as hidden, he will have database credential in clear text.
I thought of adding encryption at asp.net website and decryption in SSRS report but decryption function/code will be easily accessible at the time of designing.
Any idea how to overcome the situation?
I suggested that the OP should read the following documentation:
Specify Credential and Connection Information for Report Data Sources
This were the remarks made by the OP:
Prompt the user for credentials :Not possible because some users can view report with provided website user/password. He will have no idea about DB.
Store credentials: Not possible because user will see data in website as well as in report by database selected at the time of log-in. Database selection option is given at the time of log-in in website because there would be more than one database. so one report will show different data based on selected DB by the user.
Use Windows integrated security : Not possible because most of our client are not allowing use to use integrated security for database access. we need to use their provided credentials for all database access.
Use no credentials : we need to use client provided credentials for all database access. Correct me if i missed something from that article
This is my response and answer to the presented problem:
You require a user to login to your website, as soon as the user is logged in you should be able to know who this user is. This also means that you can give a user specific rights/access to your application.
So you can use the Stored Credentials and more specifically use the Integrated Security.
Type | Context for network connection | Data Source
-------------------- | -------------------------------- | -----------------
Integrated security | Impersonate the current user | For all data source types, connect using the current user account
I believe the following documentation might be exactly what you're looking for.
How to: Secure Connection Strings When Using Data Source Controls
I would strongly recommend creating a new table containing data that specifies the different access levels to then have a junction table with the user table. This will make it easy to determine which user has access to which report and allow for an easy implementatuon of the Integraded Security.
First, I'm not a MS Access developer. However I've got a new job and have to do some MS Access development. I'll be working with another developer who has experience at this; at least more than I have.
One thing he showed me is that users will get into this MS Access application, which goes into the forms, do whatever it is they do there and then bang out of the forms application to get direct access to the tables of the database. (The Access application is a front end to a SQL Server 2005 database.) Since the end users have direct access to the SQL tables, well you can just imagine what sort of mischief they can get into. (The Access application was written by a contractor who left with the application unfinished.)
So my question is this: how can we prevent end users from getting out of the Access application to directly interact with the SQL tables? I would think this is possible, but like I said I'm not an Office developer so I've no idea how it would be done, nor even what sort of things I'd look for.
The Access application is written in MS Access 2007.
#rod
Generally the level of security MS Access is providing is not very impressive. But it gives you some sort of security preventing novice users accessing unwanted information.
look for:
Compiling the database to ACCDE, MDE
provide custom ribbon with your own buttons
Disable the "Navigation" pane : http://www.access-programmers.co.uk/forums/showthread.php?t=187697
Disable the settings via right click.
Use AutoExe function to check if NavigationPAne is deactivated, and reboot database if necessary
Disable the "bypass startup option" key: http://www.access-programmers.co.uk/forums/showthread.php?t=91984
prevent database to load if the DB is not in .accde or .mde format. Again this is within the AutoEXE function to check.
Some useful research/investment would be.
Custom ribbon creator for MS access which will help you to provide your own buttons/ribbons (I used ribboncreator)
Providing membership/user account. since you already have dedicated SQL server you can save user credentials in the back-end tables hiding from front-end. Check user has access by writing stored procedures/functions.
Write function to gather errors, activities and uploads to a LOG table and monitor activities. use web-services + MSXML2.XMLHTTP + async for this task.}
Create a UI for the users to navigate your application. The most basic thing is just a form that has buttons to open all other forms the users need to access in your application.
Then use the ribbon to navigate to "File" -> "Options" -> "Current Database".
Select the form from the step above as "Display form" for the application and then uncheck all the following options "Use Access Special Keys", "Display Navigation Pane", "Allow Full Menus", "Allow Default Shortcut Menus".
This will start you Access application and show the selected form without any of the standard UI for working with tables or the design of other objects in your application.
But please be aware that this is just protection against normal users making accidental mistakes by changing stuff they are not supposed to change. This will not deter a malicious and knowledgeable attacker.
If you want open your application for development, hold down the SHIFT-Key while opening the file.
Another option outside of Access is to deny an AD group with read/write access to your SQL tables the DELETE permission. I was able to do this successfully using Access 2013 and Microsoft SQL Server Management Studio 2012. This post discusses the command.
DENY DELETE ON tablename to [DOMAIN\groupname];
Users in the AD group are able to modify and delete data through the UI we have created, but unable to open the table, select a line, and hit the delete key. They receive the following error: "ODBC--delete on a linked table 'tablename' failed....The DELETE permission was denied on the object ...."
Is there a way to provide generic permissions for users to run reports stored in the Report Manager? I can see how to provide access on an individual user basis via Manage -> Security -> New Role Assignment, by adding the User's Windows login name and assigning them to the Browser role for the report. (Report Manager already knows the domain name).
However, we don't want to be continually having to manage this for each new user. I want anyone under that domain name to have access without needing to configure it. I had hoped that just adding the domain name as a 'user' to the Browser role for that report would do it, but to no avail.
You can add any domain group that has been set up, not just individual users, or you can simply add all domain users, i.e. MYDOMAIN\Domain Users to the Browser role, which seems to be what you're after.
However, I would recommend creating a generic user group like MYDOMAIN\SSRSReportUsers or something like that and adding this group to the browser role instead of MYDOMAIN\Domain Users, as adding all users to the Report Server seems like it doesn't give you many options to manage this in any sort of granular way.
I have a SQL Server instance using SQL Authentication only. I will have only two users and one database on this instance. The SA has a user name of XX. I have another user and lets say that user is X. And, in my create scripts, I am adding X as a user on the server and then on the one database that is there.
If XX is the SA (created when installing SQL Server) there is no need for me to explicitly map XX to any database, correct?
I am a little confused over the CREATE USER WITHOUT LOGIN. If the above is true would I ever need to script the addition of X to the one database WITHOUT LOGIN? What is the significance of WITHOUT LOGIN? Under what conditions would anyone what to do that?
Thank you.
Users without login were added to replace application roles.
Loginless users are usefull for impersonation, in order to gain necessary permissions. They allow users to authenticate to the instance with their own credentials, therefore making SQL Server able to audit activity to their login, while impersonating the loginless user on the database context.
Simple impersonation example:
SELECT SUSER_NAME(), USER_NAME();
GO
CREATE USER loginless_user_4test
WITHOUT LOGIN
GO
EXECUTE AS USER = 'loginless_user_4test'
GO
SELECT SUSER_NAME(), USER_NAME();
GO
REVERT --as long as you haven't issued "EXECUTE AS ... WITH NO REVERT", you can go back to previous context
GO
I have a SQL 2008r2 report server where, despite having the appropriate ROLE permissions assigned within the RS, you can not view a report/folders Properties, unless you are also a member of the administrator group on the server. You can view the report itself, but not the Properites tab. When viewing the Properties tab, an rsAccessDenied error is shown with the message "The permissions granted to user 'XXX\XXX' are insufficient for performing this operation."
My understanding is that just being a member of the Browser role should be sufficient to view a reports properties, and the account actually is member of all roles (Content Manager, Publisher, Broweser, etc), so that isn't the issue, so why would you also need to be a member of the administrator group on the server?
Given that everything is being done from a browser on a remote computer, I'm at a bit of a loss as to what the Properties tab is doing that requires the extra permissions.
Anyone know what's going on and what needs to be changed so that the user doens't need any permissions on the server itself?
I had a similar problem where I didn't have access to the Properties-tab or the Data Sources-tab but adding my user to Administrators did not solve the issue. However all my role assignments were on a subfolder and when I was added to root/home with role "Browser" it suddenly started working. Even without me being an admin on the RS Server.
According to Microsoft documentation, you need higher privileges to achieve that :
http://technet.microsoft.com/en-us/library/ms157363(v=sql.105)
Browser role only enables you to navigate through folder structure and view/subscribe to reports. You need the "Content Manager Role" to achieve what you want.