Create database user using stored procedure MS SQL [closed] - sql

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 months ago.
Improve this question
I have an idea to create database user (account with username and password that can access MS SQL database with those credentials) in a SQL stored procedure, and use those credentials in my web application, when user logs in with that account, to connect and interact with database.
This way I will be able to set permissions for each account and then it won't matter if that user manages to somehow get in touch with my database without my web app, as he will not be able to make changes that he couldn't do through my web app.
In short -> security is directly in my database, not in my web app.
As you can probably tell, I'm not well versed in this type of stuff, I bet that this is already a standard way of doing security, or there's a better way.
My question is:
Can I create a DB user in MS SQL using one of it's stored procedures?
If possible, how would I go about for example changing it's password?
Or if I want to add some more information other than just username and password, I would create a table with those new colums (for example first and last name, nickname, phone number, etc), how would I go about connecting a DB user with my table?
(I imagine it would be something like 'usernames for DB users are unique, so just save the username').
As you can see I have a broad idea, and it's still a bit messy in my head, and was wondering if someone could point me in the right direction with my train of thought.

You can create a Login / User using
USE MyDatabase
CREATE LOGIN MyLogin WITH PASSWORD = 'MyStrongPassword'
CREATE USER MyUser FOR LOGIN MyLogin
To change a password
ALTER LOGIN MyLogin WITH PASSWORD = 'MyNewStrongerPassword'
To grant the user access to a table within the database:
GRANT SELECT ON MyTable TO MyUser
You can indeed do this directly within a stored procedure, though I'm not sure why you'd want to - surely this would be a one off operation by a database administrator, rather than something that would require the re-usability a stored procedure gives?

Related

How To Manage User Authorization and User Access in Access? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I wanna create a feedback database and have three types of users (teacher, student, and admin) how can I do that by using ms access 2016 ?
You'll want to run some VBA code on opening the Access db. If you do not need to secure your db from meddling and just want a way to obtain different functionality I suggest you avoid Access's security, it's tricky and problematic.
If you still want that protection you can find a lot of descriptions out in Googleland, I'll describe a simple identification scheme that avoids the built-in Access id security scheme. It does not provide any real security.
Establish/authenticate the user. Easiest way is to take advantage of unique PC userids and execute Environ$("Username") to return the ID used by the PC operator to log in with. If you cannot rely on it being unique, you may have to choose to create an initial form dialogue to set a name string.
Create an Access user table with all the userids/name strings plus their role (teacher, student, admin). Look up the result of step 1 in this table. If you don't find it put out a message about who to contact and then exit the application. If you do find it, remember the role.
In your VBA code declare a userid variable and a role variable in the global context (outside all subroutine and function definitions) and make them PUBLIC. Make sure the variable names are completely unique and do not use the same name as the module name. Store the results of step one and step two there.
Now you can code VBA code and SQL that references both global, public variables and you do not constantly have to join a role table into everything you do. To use the role variable in SQL, enclose the variable names in square brackets.

Need to find username/password that program uses to write to firebird DB [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have a program that accesses a local firebird database. It has write access to this database, and we need to be able to write to this database, but do not know the username/password.
Obviously, somewhere in the PC is a connection string/username/password to be able to connect to that database. What methods could I use to find this?
I've tried process monitor to see if it accesses any registry keys but can't see any.
I've checked the installation directories for configuration files.
I've decompiled some of the DAL DLL's but can't see any hardcoding anywhere!
The vendor is no longer, so we can't go to them.
Any advice appreciated!
If with "local" you mean embedded then you actually don't need to know the password - the embedded version doesn't check password. Quote from the "README_embedded.txt" file, chapter "2.3. Authentication and security":
The security database (namely security2.fdb) is not used in the embedded server and hence is not required. Any user is able to attach to any database. Since both the server and the client run in the same address space, the security becomes just an agreement between both sides which can be easily compromised.
So you actually need only the username, and for that you can use SYSDBA - the Firebird's superuser. Note that the username is still checked, even with embedded, to assign user SQL privileges.
In addition to the answer by ain regarding use of embedded, authentication in Firebird is handled by the server and its associated security database. This means that if you copy (or better: backup and restore) a Firebird database to a different server where you know the SYSDBA password, then you can simply access the database.
However if you want continuous write access from a different process to a database that is used by a Firebird server embedded in an user application: you can't. The embedded server (at least on Windows), does not allows external connections.

SQLServer difference between new login and new database user [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Difference between a User and a Login in SQL Server
Is it enough to create a database login with permission to desired database? Or do I need to create a database user for this login?
A login is a login account for the entire SQL Server instance - an instance can contain numerous databases.
A user is defined at the database level, and is associated with a login to provide interactive access (privileges providing)
Logins are a server side (instance level) objects. Their correct name is 'server principals' (see sys.server_principals). Server wide privileges are granted to logins, like create database or view server state permissions.
Users are a database objects, correctly referred to as 'database principals' (see sys.database_principals). They are the recipients of database permissions, like create table or select.
Ordinarily a login is mapped 1-to-1 to a user in each database, via a matching SID, but there are some exception, like all members of the sysadmin fixed server role are always mapped to dbo.
Users without login are a specific construct for Service Broker remote identities (see Remote Service Bindings) and for code signing. You should never have to create one in any other context, and if you do, you're likely doing it wrong. Users without login are never meant to be impersonated.

SQL Server database security [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have SQL Server 2008 installed on Windows 2008 Server.
I've disabled built-in administrator password and created sa with sysadmin privileges.
Question is: Is there any way to access to database, or back it up. or methods to reset (and / or) get password for sa?
I want to secure my database.
Thanks.
I've disabled built-in administrator password...I want to secure my database.
If you think you can disable access to built-in administrators your are chasing a phantasm. Built-in administrators will always be able to access your database, the steps to gain access are clearly documented in Connect to SQL Server When System Administrators Are Locked Out. Your database must be deployed on a system on which you completely trust the system administrators, there is no work around for this basic requirement.
Most often this question is asked as some misguided attempt to protect the perceived IP in the database. The answer to that question is that what you want is called DRM and SQL Server does not offer DRM. If you are afraid of distributing the database to your users then use a service like SQL Azure.
Users who have to have access to the SQLCmd prompt would be be able to run perform such commands. You could access the database and reset passwords the console and do something like this:
ALTER LOGIN sa WITH PASSWORD = ‘newpassword’ UNLOCK

from a trigger, how to find out who modified data on table X while that user is logged from a generic dbuser but got the right from a user-table

I'm not sure how to formulate that question but:
you have a webpage
the webpage got a specific user/pass in the web.config for the connection string
on a webpage you ask for a user/pass that is connected to a table (id, name, pass)
the user is recognized with a valid user/pass and now you know the id from the table above
the user change some data in a table and that table got a trigger
from that trigger, how to retrieve the user id from step 4
Let's say the user is logged using the asp.net membership table
Use SET CONTEXT_INFO and CONTEXT_INFO() to pass out-of-band parameters. Your Web layer must ensure it sets this correctly on each connection it uses prior to calling into the database, which means one extra additional round-trip to the database.
In step 4, when you say that YOU know it, what you really mean is that your application knows what user id is logged in. Your application's authentication is completely separate from your database authentication (excepting maybe using windows authentication with SQL server, but I don't think that's what you're doing).
As KM mentions, you would need to pass the application user id to the trigger by means of a "LastUpdatedUserID" column or some such thing on the table being updated.
#KM, or move your users into AD and use integrated auth. No other option here.
you need to have a LastChgID column (or similar) on the table they are changing based on the web page user/password, then INSERTED.LastChgID will tell you. otherwise, you are out of luck.
EDIT
When you save the change, store the web apps user ID into the table's LastChgID column, this may require passing it into the stored procedure, or just SET that column in the UPDATE statement. When the trigger fires, INSERTED.LastChgID will have the web apps user ID.
Since the username is just data it is tough to capture via a trigger.
Option #1 is similar to what KM said and your developer would have to pass the username via a query and update an audit column in the database. and the trigger would grab that column vlue on updates and do what ever you want with it.
Option #2 would be to programatically create the user in SQL server or your windows domain structure, give it access to the application and then impersonate that user upon entry for subsequent logins. This would be an administrative maintenance issue, but the application users would then access the database using their unique ID instead of the one configured in web.config and all updates to the database are as that user instead of the generic one supplied in web.config.
Hope this helps.
As has already been suggested (by Remus Rusanu) using the SET CONTEXT_INFO for this means you don't have to add parameters on all your stored procs to do this. A similar question from myself can be found here:
SQL Server: Modifying the "Application Name" property for auditing purposes