• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 216
  • Last Modified:

use one sql server authentication for many users?

I am using mixed mode for SQL Server. Most of our users will use mixed mode so I created one account for all users. I connect to the server but I always connect and disconnect the record set in other words there are no record set connection left open duration of the program.

I have a table that consists of users and each user has different rights to different parts of the program. i.e. one user may not have the rights to use accounting section of the program. When they launch the program, it asks the user for user name and password but that is just to authenticate the user and to setup the application layout. When the user connects to the database, it uses a different user name and password to authenticate the sql server account.

Example
SQL Server Authentication
User id: General_user
Password: zeus

Table
Lists of all users with password and varies fields that have the users’ rights value.

Is this a typical practice or what?






0
lunchbyte
Asked:
lunchbyte
2 Solutions
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
>Most of our users will use mixed mode
this is "nonsense". let me explain.

In SQL Server, you have 2 types of LOGINS:
* SQL Server logins:
  -> SQL Server stored the name and password for the login
* Windows Authenticated logins
  -> SQL Server only stores the name of the windows NT User OR NT Group

SQL Server can run in 2 modes:
* Windows Authentication mode
  -> only Windows Authentication logins will be allowed to login; SQL Server logins will be blocked
* Mixed mode
  -> both types of logins are allowed

NOTE:
 when a user connects with a USERNAME/PASSWORD, he is using SQL Authentication, the USERNAME actually being the LOGIN name.
 to use Windows Authentication, the application has to specify a special connection string that indicates to use Windows Authentication.
 
SQL Server does not allow any windows account by default, you have to create those nt-based logins in sql server for those NT accounts that you want to grant the relevant permissions



0
 
derobyCommented:
I think what he meant was that the application has a login/pwd hardcoded into the client-program that is able to connect to the server. (SQL-security)
Additionally, the client application will ask for 'another set' of login/pwd and will verify that against the information stored in some user-tables in the database. (application security)

I don't think it is uncommon, but I would not recommend it either. If someone ever managed to find the hardocoded values (amazing things can be done using a hex-editor, or even notepad), he would most likely have full access to the database.

The way we do it here is by
* giving each user a specific login (either by allowing there windows-account to connect, or by giving them a unique login/pwd)
* configure the security on the database so the users have only got access to a limited number of procedures (or views) and each of those (procedures or views) have a check built in that will verify if given login has sufficient access based on the data in the security related user-tables mentioned above.

If ever a user needs to be able to execute some dynamic sql or stuff on objects he normally would not have access too, our appliction will load an encrypted appliction role and password from a configuration table, decrypt it, create a new connection, activate the application role, do whatever is needed and drop the connection again.

Works fine for us and we haven't found anyone 'breaking the system' yet.


0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now