I have a server (2008R2) that has little Access (2010) databases relevant to departments and their needs. I have a new EHR server (2008R2) running SQL (2008R2) servers and am able to establish an ODBC connection between the two. I created the ODBC using the SA / SA password to the SQL Server.
As an administrator, I can log in to the Access database and run queries and reports based off of tables linked back to the SQL DB. No one else can. I did save the password when I created the External table link in Access. My Sys Admin - also Administrator, cannot run queries or reports logged into the Access database server for this DB.
On this particular SQL Server, I am not an admin under my login. I have to use the SA account to login to the backend or through the Management Console.
I need to have the EHR managers run their own reports. Does anyone have any experience with why the ODBC would not be allowing a connection for anyone but me when the connection is server based?
What Gord Thompson said is important. Access is not a database server and its engine runs on the client machine which will need copies of whatever DSNs are used.
But the problem of getting Access to 'remember' credentials is something I recall struggling with in Access 2000. My solution was to create a dummy pass-through query (anything that will run quickly) that stores the credentials. When a new client session starts, first call the dummy query and for the duration of their connection, they'll have access to the DSN in question.
Related
I am trying to set-up/test SQL Server row-level security for my database. I want to use row-level security for SSRS reports and Power BI. The database is set up on my test PC using SQL Server Express with SSMS.
On my test PC I have set up a separate account -- separate from the user under which I established the SQL Server and database. I believe I have set-up the SQL Server level permissions and database level permissions appropriately(?) for the separate user.
I go into the separate user account and continually get the
Server principal **** is not able to access under current permissions
message in SSMS and cannot access the data in the SSRS localhost website.
Is the separate user, established on the same PC, not considered to be in the same domain as the PC user who established the database? Is that what is causing the problem? If so, how can that be overcome? If not, any ideas what my problem might be? Is there some constraint in SQL Server Express that I need to establish the database using a SQL Server Developer edition?
I prefer not to wait until the database is established on the system test server to determine how this will work. Many thanks for any thoughts or suggestions.
I need to lock down access to a linked server object in MSSQL server.
I am building views on a host database, from which, I query to populate a staging table on my warehouse server. I am using Data Tools/SSIS to extract the view data. To simplify the SSIS package, I am using the OPENQUERYsyntax to query the linked server object that exists on my warehouse server, and connects to other SQL servers, Oracle servers, etc., through linked server objects.
To provide access to the linked servers, I have set up a local SQL login on the host db that has read access, then I use 'Be made using this security context:' and pass the local SQL login. That works just fine.
I realize now that I have a problem: any user with warehouse access can query the linked server object because of that stashed security context! I don't want that! I do need folks who should have access to be able to query (so I can write my SSIS packages), as well as the SQL Server Agent service account to have access so when the SQL Server Agent job runs as that user that it can successfully query the linked server.
I believe that the key to locking down query access to the linked server object is somewhere in the 'Local server login to remote server login mappings', but I'm having a hard time figuring that out. When I try to add for instance NT SERVICE\SQLAgent mapped to the local login with access, then save, I hit 'Login failed for 'NT AUTHORITY\ANONYMOUS LOGON' when saving.
Any ideas on how I can allow a security groups that have access, and SQL Server Agent service account to query the linked server, but not the rest of people with warehouse access?
This is known as the 'double hop' problem
(https://blogs.technet.microsoft.com/askds/2008/06/13/understanding-kerberos-double-hop/)
and to get rid of the Anonymous login error you would have to properly set up Kerberos pass-through authentication;
https://blogs.msdn.microsoft.com/farukcelik/2008/01/02/how-to-set-up-a-kerberos-authentication-scenario-with-sql-server-linked-servers/
https://www.databasejournal.com/features/mssql/article.php/3696506/Setting-Up-Delegation-for-Linked-Servers.htm
However this is quite involved - you mention that to 'simplify' the SSIS package you use a linked server, however SSIS solves exactly this problem... Why don't you just use SSIS to copy the data from the other server to avoid using a linked server?
I have a SQL Server database for many users. All users connect to the same database using the same connection string (ie. via the same user ID/pwd which is hard coded into the client side application software).
From a processing perspective on the server, will it make any difference connecting to the database with each user having its own USER name configured on the database where the access rights to the database will be the same for all?
I'm trying to run a VBScript which calls a stored procedure (SQL Server 2012) that Inserts records into a Linked Server Table.
The script returns the following error:
The Microsoft Access database engine cannot open or write to the file '\999999999\99999999\9999999\9999999.accdb'. It is already opened exclusively by another user, or you need permission to view and write its data.".
Nobody else is using the table.
However, when I execute the stored procedure from Management Studio it works fine. I believe the problem is related to permissions. How do I grant a user explicit rights to Linked Servers?
I apologize for not providing more detail to my question earlier, I made the mistake in thinking that there was a simple solution, with that said here are some more details:
The key to this problem is: When I login as Windows Authenticated User on SSMS I'm able to run my Stored Procedure (Which connects to the Linked Server) without a problem. Couple of more technical points to add as I do more research (and finding this is not a simple problem):
The SQL Server is on Subnet ...5.X
The Access Database is on Subnet ...2.X
VBScript runs from a Job Processing Server on Subnet ...5.X
The Windows Authenticated Account on SQL Server has the Linked Server setup and can connect using the IP address and shared folder \192.168.2.X\Blah Blah Blah\thedatabase.accdb
If I login to SQL Server using SQL Server Authenticated User they cannot access the Linked Server (See error in original post)
If I attempt to run the VBScript from the Job Processing computer as the SQL Server Authenticated User or with a Trusted Connection I'm unable to access the Linked Server.
I've tried mapping a drive on the SQL Server computer for the SQL User (didnt work)
I've tried various combination of Login configurations on the Linked Server: Made without using security context, made using the login's current security context, made using the security context (admin username and password on other machince, SQL server admin username and password)
I've added the SQL User to the domain user group (But I only made them a standard user, need to research this one before making to many modifications)
I've added the SQL User as an Admin on the Access Database computer.
The key to my problem is: Why can the Windows Authenticated user connect to the MS Database via Linked Server and the SQL User cannot
Again apologies for not supplying this much detail upfront but I made the mistake of thinking this was a simple security problem.
I understand that the reason mixed mode allows login with Windows authentication is for security purposes. My boss asked me to create a setup.exe that installs:
our medical software
SQL Server 2008 R2
SQL Server Management Studio
The install is fully automated with limited user input. SQL Server and the SSMS are implemented with a config file. sa and serviceRXuser (strong passwords) are SQL Server authentication logins.
I don't want my clients to have access to our database, because editing drug data could be potentially life threatening. And yes, we have had clients alter things in our database... causing application errors that required re-installation.
Is there any way to, at least, limit access to keep end-users from editing the data? Preferably a T-SQL command so I can keep automation. If not, is there any way to hide the database?
first of all, don't share SA password (on any strong user password) with your clients :)
Your app is running on client machines and coonnect to SQL via ODBC?
hmmm.... it is hard, because the users can use Your ODBC connection from ACCESS and EXCEL too. Can you change Your app to don't use ODBC?
If You grant ONLY exec rights on stored procedures to serviceRXuser (don't need DB_DATAREADER or any other rights), then clients can't do anything, only what You can handle in SP-s. You can send an encoded parameter to every SP, and decode is wrong, raise any random error SQL ;) Users can't create this encoding from excel/access ;)