As per my project requirement i need to lock a user in SQL Server(Which is created using Windows Authentication). Is there any way to do this?
For example: For a SQL login if you try to login using wrong Password more than 3 or 4 attempts, then that account gets locked out. User cannot login to SQL Server using this username. I want to check this using Users created under windows authenntication
Thanks for the help
Santhosh
You need to keep two things apart:
on a server-level, you have users that have a login - this gives them the ability to connect to that SQL Server at all. You can disable a login using:
ALTER LOGIN (name) DISABLE
Doing so prevents that user from logging into the database server alltogether - he (or she) cannot access anything on that database server anymore
on a per-database level, those logins might be granted access to the database - this is done by creating a user (based on that login) for that database, and assigning that user certain permissions. You can't really disable a user in a database - you just have to drop that user
USE (database)
DROP USER (name)
You can always re-create that user from his login in that database using
USE (database)
CREATE USER (name) WITH LOGIN = (login name)
Related
Disclosure: I am not an IT professional and I am certainly not a DBA.
That said, I can usually find my way around. I am following some instructions from a third party vendor to create a login, two databases, a user in each and ultimately a DSN to each.
Here are the steps:
Create a login (let's call it Test) with SQL Server Authentication and assign it a Public server role
Create two databases, both owned by the login we created (Test)
In each database, create a user with User Name and Login Name both set to Test and the default schema as dbo. Assign each user db_owner in Owned Schemas and Membership
Create a DSN to each database
If I follow these instructions, when I attempt to create the users I get an error: The login already has an account under a different user name. (Microsoft SQL Server, Error: 15063)
If I try creating a user with a different User Name (login name still Test), I get the same error.
If I try creating a user with a different Login Name, I get a different error: 'Test1' is not a valid login or you do not have permission. (Microsoft SQL Server, Error: 15007)
If I try skipping the users entirely and creating the DSN with the original Login, I get an error that login failed for user Test.
I have tried completely removing and re-installing SQL Server in case there was some duplicate name stored somewhere, but it didn't help.
So, I am not sure what else I can try. Clearly I am missing something, but I have no idea what.
If the Login owns the database, it's mapped to the user dbo (which stands for "database owner") so you can't create another user for that login.
Normal practice is to have the databases owned by SA or your Windows Login, then you can create the user for the SQL Login and assign whatever permissions you need.
Here on my company we have a SQL Database with several users. However everyone knows the password of 'sa' user.
Now, we have create a Intranet and it is necessary to limit the access to the Intranet database.
I have tryed to create a new owner and remove the permissions from 'sa' user to this database but with no success. What it is more recommended?
Continue this or create a new password for this specific database (is this possible)?
Thanks in advance
I would simply suggest reset the SA account's password. Very very few people should know this password ever. If you need to give specific people this access, then create accounts for them. Applications should almost never have this level of access.
Edit: In MS Sql Server you can have a user on the server level with no access, and then you make that user DBO in a specific database - this enables a user to "admin" a database without being able to mess with the server settings.. This is highly recommended imho.
Here is a detailled guide on how to do it:
First make a login:
http://msdn.microsoft.com/en-us/library/aa337562.aspx
Then give that user access to the DB:
http://msdn.microsoft.com/en-us/library/aa337545.aspx
Don't use SQL Server logins
Use windows logins. When the user should not have access, remove the windows login. You can't make people forget a password but you can revoke windows login access.
We have an application where user login is implemented using JavaEE5 Servlets, Filters, Spring3.0 and SQL Server database tables. When a user logs into the application, a record on User database table is added against the user. If any other user logs in whist the first user already logged in with same login credentials, we either avoid it or allow it depending on some conditions. This is made easy because of having single database table recording all user logins. I'm wondering if there is any way to avoid database and rely on application server. We are using JBoss5.1 currently.
Our WMS uses a database TSECURE to handle all logins from our WMS. I am thinking of creating my own new software for upload purposes only. In this tsecure we maintain / add different security user logins for different users. For example, I must create a WMS Access for Alex, I will create first a SQL Server login for alex, then add his [wms_user + wms_pass] to [TSECURE] with DB credentials under [sql_server_user_alex / pass].
My questions:
Is it necessary to use different security logins for different users?
Would it be OK to just use a single user for all of them? ex. userS: [alex1] / [joseph2] / [jdoe] / [aron] ... are all under [sa] security login? What would be the downside of this?
As marc_s noted.
The normal approach for this would be: (1) create a Windows group, (2) put your three users into that group, (3) create a SQL Server login for that group, and (4) give that group login the necessary permissions in your database. That way, you can add new members to that Windows group and they'll automatically have all the necessary permissions to access that database. Don't --EVER-- use the sa account in a production system! NO exceptions!
Windows Authentication is much more secure than SQL Authentication.
"Putting all users under SA" - do not do this under any context.
Please review the CIS SQL Server baseline for further guidance.
I have recently been running into many different areas of SQL Server that I normally don't mess with. One of them that has me confused is the area of Logins and Users. Seems like it should be a pretty simple topic...
It appears that each login can only have 1 user and each user can only have 1 login.
A login can be associated to multiple tables thus associating that user to many tables.
So my question is why even have a login and a user? they seem to be pretty much one in the same. What are the differences, or what is it that I seem to be missing?
A "Login" grants the principal entry into the SERVER.
A "User" grants a login entry into a single DATABASE.
One "Login" can be associated with many users (one per database).
Each of the above objects can have permissions granted to it at its own level. See the following articles for an explanation of each
Principals
Database Users
One reason to have both is so that authentication can be done by the database server, but authorization can be scoped to the database. That way, if you move your database to another server, you can always remap the user-login relationship on the database server, but your database doesn't have to change.
I think there is a really good MSDN blog post about this topic by Laurentiu Cristofor:
The first important thing that needs to be understood about SQL Server
security is that there are two security realms involved - the server
and the database. The server realm encompasses multiple database
realms. All work is done in the context of some database, but to get
to do the work, one needs to first have access to the server and then
to have access to the database.
Access to the server is granted via logins. There are two main
categories of logins: SQL Server authenticated logins and Windows
authenticated logins. I will usually refer to these using the shorter
names of SQL logins and Windows logins. Windows authenticated logins
can either be logins mapped to Windows users or logins mapped to
Windows groups. So, to be able to connect to the server, one must have
access via one of these types or logins - logins provide access to the
server realm.
But logins are not enough, because work is usually done in a database
and databases are separate realms. Access to databases is granted via
users.
Users are mapped to logins and the mapping is expressed by the SID
property of logins and users. A login maps to a user in a database if
their SID values are identical. Depending on the type of login, we can
therefore have a categorization of users that mimics the above
categorization for logins; so, we have SQL users and Windows users and
the latter category consists of users mapped to Windows user logins
and of users mapped to Windows group logins.
Let's take a step back for a quick overview: a login provides access
to the server and to further get access to a database, a user mapped
to the login must exist in the database.
that's the link to the full post.
In Short,
Logins will have the access of the server.
and
Users will have the access of the database.
I think this is a very useful question with good answer. Just to add my two cents from the MSDN Create a Login page:
A login is a security principal, or an entity that can be authenticated by a secure system. Users need a login to connect to SQL Server. You can create a login based on a Windows principal (such as a domain user or a Windows domain group) or you can create a login that is not based on a Windows principal (such as an SQL Server login).
Note:
To use SQL Server Authentication, the Database Engine must use mixed mode authentication. For more information, see Choose an Authentication Mode.
As a security principal, permissions can be granted to logins. The scope of a login is the whole Database Engine. To connect to a specific database on the instance of SQL Server, a login must be mapped to a database user. Permissions inside the database are granted and denied to the database user, not the login. Permissions that have the scope of the whole instance of SQL Server (for example, the CREATE ENDPOINT permission) can be granted to a login.
Graph on logins / users from MS sql-docs