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?
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.
Could somebody explain how you can have different databases/security when connecting in via Windows Authentication from when someone connects via SQL authentication?
I have a customer who had to put a computer onto their network. When they did this, the computer name changed. When connecting into SQL it now has a different server name.
The thing is if I connect using a SQL username and password, I get the databases that were installed before. However If I connect using windows authentication, I do not get the database.
I would like to know what needs to be changed in order for windows authentication to see the same as a user logging in via SQL authentication.
How can I go about changing the permissions of windows authentication?
Within SQL Server, there are Logins (at the server level) and Users (at the database level). Your SQL Server login obviously has permission to the database(s) you want to see. The logins can also be windows users and/or groups. So, if you add a named windows user as a server login, you can extend that login as users in different databases. You can do the same thing with a group. So, you could have a single login to your sql server that represents all authenticated users in your domain, etc...
So, I think you need to get into SSMS (SQL Server Management Studio) and see what logins and users are defined on your SQL Server.
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.
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 ;)
Is there any way to use SQL Server Auditing when the primary database interaction is from a website without impersonation?
All database actions come from a web application whose connection string uses a single logon / password. In the website, user authentication / creation comes from the membership provider, but is not passed through to the SQL Server. I would like to audit which website user performed which action on the SQL Server using the built-in audit mechanism.