I am needing to update the password of one of the users in the database security folder in SQL Server 2012. Unfortunately, we do not have a DBA in-house and consequently needing some help. I've been told that I have sysadmin privileges on this SQL Server but I cannot find WHERE to update a user's password in the database. When I googled this, msdn show me how to update a login in the SQL Server 2012 box but this user is NOT listed under the Security\Logins folder in this server but this user is only under the database\Security\Users folder.
I had tried the ALTER LOGIN username WITH PASSWORD = 'password'; command but I only got this error:
Msg 15151, Level 16, State 1, Line 2
Cannot alter the login 'ATM', because it does not exist or you do not have permission.
Any help/direction would be appreciated. Thanks.
This is the difference between logins and users and how they relate to each other:
Logins - Instance level principals that allow an entity to connect to the SQL Server instance. They do not, by their nature, grant any access to databases on the instance. The exception to this is a login with sysadmin rights can use a database because they are sysadmin, but because of sysadmin level permissions.
Users - Database level principals that allow an entity to connect to a SQL Server database. Users are associated with logins via SIDs, creating a relationship between the two and allowing a login to connect to the instance and then use the associated user to connect to the database.
What commonly happens with SQL authenticated logins and database users on a restore is that the SIDS will be out of sync or a login will not exist for a user in the database, thus breaking the relationship. This relationship must be repaired before you can connect to the database using that login, because in the eyes of SQL Server those principals are no longer connected. If the login doesn't exist, you will have to first create it in order to associate it with the user:
--Windows login (Active Directory pass through)
CREATE LOGIN [DOMAIN\foo] FROM WINDOWS;
--SQL Authenticated
CREATE LOGIN [foo] WITH PASSWORD='5+r0ngP#55w0rd';
Once the login exists, associate it with the user:
ALTER USER [foo] WITH LOGIN=[foo]
You can use the following query in the context of your database to check for orphans:
select
dp.name [user_name]
,dp.type_desc [user_type]
,isnull(sp.name,'Orhphaned!') [login_name]
,sp.type_desc [login_type]
from
sys.database_principals dp
left join sys.server_principals sp on (dp.sid = sp.sid)
where
dp.type in ('S','U','G')
and dp.principal_id >4
order by sp.name
Related
I'll preface this with I've never been in charge of database security and this is all really new to me, so forgive the question if it's bad - I'll try to provide as much information as possible. I've searched around without much detail on my specific question.
I'm using a SQL Server 2008 R2 database and I am in need of the ability to restrict all domain users to be able to only execute certain stored procedures when explicitly defined. As in, DENY select/update/delete/etc on ALL database tables/views/stored procedures, except for SOME stored procedures where defined explicitly (grant execute on stored procedure to USER (domain users below)).
I thought this would be pretty easy with server roles but it appears custom server roles are only available in SQL Server 2012 and up and the public server role grants select access on all of my tables. I read that deny always takes precedent over grant so I setup a database role that has select access set to deny, but users are still able to query the tables.
Here is my current setup on 1 server that contains 2 databases:
Server Level:
Logins: [Domain Users] - AD group login so all users can CONNECT to the server. Has server role Public.
Database Level:
Users: [Domain Users] - AD group so all users can CONNECT to the database.
Database Roles: [SP_Reader] - [Domain Users] as a role member. Securables I have all tables set to deny access on select and my stored procedures that I want users to execute set to grant on execute.
The problem is users are still able to select from my tables as if the permissions don't exist. Any idea what I'm doing wrong here?
The problem turned out to be the 'db_datareader' role was assigned to the database user in addition to my custom database role (SP_Reader) which provides only execute on certain stored procedures.
The 'db_datareader' role went unnoticed as I was querying 'sys.database_permissions' which doesn't display permissions that are implicitly granted.
I ended up finding this Microsoft link which provides a query that returns the members of all database roles:
SELECT DP1.name AS DatabaseRoleName,
isnull (DP2.name, 'No members') AS DatabaseUserName
FROM sys.database_role_members AS DRM
RIGHT OUTER JOIN sys.database_principals AS DP1
ON DRM.role_principal_id = DP1.principal_id
LEFT OUTER JOIN sys.database_principals AS DP2
ON DRM.member_principal_id = DP2.principal_id
WHERE DP1.type = 'R'
ORDER BY DP1.name;
Alternatively this internal stored procedure returns results for whichever role you pass as a parameter:
EXEC sp_helprolemember 'db_datareader';
I try to map my other DB to a user by going to Security > Logins > right click someuser > Properties > User Mapping > Select DB > set as db_owner and then ok, but I keep on getting an error saying
User, group, or role 'someuser' already exists in the current database. (Microsoft SQL Server, Error: 15023)
What is causing the error, and how do I map that user to the database?
To fix the user and login mapping you need to open a query window in the SQL Server Management Studio. Enter the following two lines and replace myDB with the database name and myUser with the correct user name:
USE myDB
EXEC sp_change_users_login 'Auto_Fix', 'myUser'
If run successfully you should get an output like this one:
The row for user '****' will be fixed by updating its login link to a login already in existence.
The number of orphaned users fixed by updating users was 1.
The number of orphaned users fixed by adding new logins and then updating users was 0.**
Your user should now be mapped correctly.
Edit:
New way to Resolve/Fix an Orphaned User:
In the master database, use the CREATE LOGIN statement with the SID option to recreate a missing login, providing the SID of the database user.
CREATE LOGIN <login_name>
WITH PASSWORD = '<use_a_strong_password_here>',
SID = <SID>;
To map an orphaned user to a login which already exists in master, execute the ALTER USER statement in the user database, specifying the login name.
ALTER USER <user_name> WITH Login = <login_name>;
When you recreate a missing login, the user can access the database using the password provided. Then the user can alter the password of the login account by using the ALTER LOGIN statement.
ALTER LOGIN <login_name> WITH PASSWORD = '<enterStrongPasswordHere>';
if it is just one or two users, then easiest way is to drop the database user from the restored database, remap the database user to the server login using SSMS. If the server login does not exist then just create it, map the user.
Option 2: If you are migrating a large number of users, use sp_help_revlogin. sp_help_revlogin is a Microsoft supplied stored procedure that will help migrate logins from one server to another, including passwords and SIDs. Here is a good article about it SP_HELP_REVLOGIN : http://www.databasejournal.com/features/mssql/article.php/2228611/Migrating-Logins-from-One-SQL-Server-to-Another.htm
Code patches to help use it :
run following T-SQL Query in Query Analyzer. This will return all the existing users in database in result pan.
USE YourDB
GO
EXEC sp_change_users_login 'Report'
GO
Run following T-SQL Query in Query Analyzer to associate login with the username. ‘Auto_Fix’ attribute will create the user in SQL Server instance if it does not exist. In following example ‘ColdFusion’ is UserName, ‘cf’ is Password. Auto-Fix links a user entry in the sysusers table in the current database to a login of the same name in sysxlogins.
USE YourDB
GO
EXEC sp_change_users_login 'Auto_Fix', 'ColdFusion', NULL, 'cf'
GO
Run following T-SQL Query in Query Analyzer to associate login with the username. ‘Update_One’ links the specified user in the current database to login. login must already exist. user and login must be specified. password must be NULL or not specified
USE YourDB
GO
EXEC sp_change_users_login 'update_one', 'ColdFusion', 'ColdFusion'
GO
2) If login account has permission to drop other users, run following T-SQL in Query Analyzer. This will drop the user.
USE YourDB
GO
EXEC sp_dropuser 'ColdFusion'
GO
Create the same user again in the database without any error.
If you assign permissions to a database user without mapping it to the database first, it throws the error you mentioned.
You should be able to delete the user, map it to the database and then assign the user to the db_owner role.
First drop your user, then execute the script below:
USE [YOURDB]
GO
CREATE USER [USERNAME] FOR LOGIN [USERNAME]
GO
USE [YOURDB]
GO
ALTER USER [USERNAME] WITH DEFAULT_SCHEMA=[dbo]
GO
I had the problem when I was trying to copy a production database to a local test database. In SSMS, I made sure to disconnect from the production server before executing scripts on the local. However, even though I thought I had disconnected, someone pointed out that the title of the production database was still there, and I got errors that objects were already there. The solution was to totally exit from SSMS and start it again, only connecting to the local test database that time.
you can solve problem by expand database ->Security -> Users
and delete the user 'someuser' ,after that go to user mapping and assign.
this problem happen some times because the database user 'someuser' was deleted from 'Logins' in Security section in SSMS and the database still own this user
Create failed for User (Microsoft.SqlServer.Smo)
SQL Server Error User, group, or role already exists in the current database. (Microsoft SQL Server, Error: 15023)
To fix above error delete user under each database individually
I'm modifying an application that was designed to work with SQL Server databases to work with Azure SQL databases.
Most of the features and functions of the application appear to work well out of the box, or with minor tweaks but I've run into a snag with the following:
The application has an administration mode which allows a user to login using an account that has server admin rights and execute database updates when update patches are released. The application currently checks whether the user is in the sysadmin or serveradmin roles using the IS_SRVROLEMEMBER function.
However, on the SQL Azure instance, this method always returns 0, regardless of the user context I execute it under.
So the question is, how can I determine if the current login is an Azure server administrator? Or get a list of the Azure administrator logins (or logins and their roles on the server)?
I guess Azure database does not have server roles at all (it only has logins). Instead you should query master database for roles.
SELECT m.name as [Member]
, r.name as [Role]
FROM sys.database_role_members as drm
INNER JOIN sys.database_principals as m
on drm.member_principal_id = m.principal_id
INNER JOIN sys.database_principals as r
on drm.role_principal_id = r.principal_id
Make sure you execute it on master database. And remember you can not use "USE [dbname]" statement. "master" should be in your connection string.
more on logins in azure
server administrator permissions of Azure SQL Server and Azure SQL DW are not being reflected as database principals. instead, a logged-in admin user is the dbo user of the database.
so, in order to identify if the user is sysadmin or serveradmin all you have to do is to query SELECT current_user; and compare the result to dbo.
I have two databases.
Databases:
1. DB1
2. DB2
I have created two new logins.
Logins:
1. DB1_login
2. DB2_login
Next, I created user for each database mapped to the above logins.
create user DB1_login1_user1 for login DB1_login;
create user DB2_login2_user2 for login DB2_login;
So, DB1_login1_user1 user of DB1 database will be mapped to DB1_login1 login and DB2_login2_user2 user of DB2 database will be mapped to DB2_login2 login.
Granted database role permissions for both users is db_datareader and db_datawriter.
In DB2, I have a table named dbo.sample_table.
My requirement:
Let us consider that I have logged in as DB1_login1.
In this login, I have granted permissions for DB1_login1_user1 user to DB1 database.
Now from DB1, I have to select a table dbo.sample_table at DB2, which was mapped to another login DB2_login2.
Below is the query what am I trying to do is.
--CURRENTLY LOGGED IN AS DB1_LOGIN1
USE DB1;
EXECUTE as login='DB2_login2'
select * from DB2.dbo.sample_table
GO
I tried GRANT IMPERSONATE on LOGIN::DB2_login2 to DB1_login1, but it didn't work and also, I'm not aware about granting permissions across logins. I think granting permissions matters and I need help in doing that.
How can I execute the above query successfully?
Any help would be appreciable.
The users you created exist only in their respective databases, so what you're trying to do is not possible. Even if it were, or you allow acces (create users for login) in both databases and give then permissions and enable cross-database access, it would be too much of a security risk.
I'd suggest using stored procedures to acces data cross database. Stored procedure should be signed with a certificate, and the same certificate created in both databases. I've had it implemented on various occasions and it works flawlessly.
There is a great sample of this by Erland Sommarskog here.
I did granting permissions on login.
From administrator login "Sa", I executed the below query.
GRANT IMPERSONATE ON LOGIN::DB2_login to DB1_login;
And then from DB1_login, executed the below query for accessing DB across logins.
USE MASTER;
EXECUTE as login='DB2_login';
SELECT * FROM DB2.dbo.sample_table;
REVERT;
GO
Finally for my situation, I have solved the problem.
I am using SQL Server authentication with login name sa (default)
When I execute query
select session_user
I get dbo as a user. I want to change this, how can I do this using SQL query? Also what is a schema in SQL?
Sql server has 2 different notions
login: what you use to connect to the server
User: what you give rights to in a database
When your login is granted database access you are actually creating a database user mapped to the login. The sa is the system administrator account and mapped to the dbo (database owner user) on the system databases. When you are logged in with a user with the create database right and create a new database this login will be automatically mapped to the dbo user.
If you want to change this afterwards, you need to map the dbo user to a new login. Afterwards you can map the sa account to another database user.
use master
create login xxx with password = 'yyy', check_policy = off
use <yourdatabase>
exec sp_changedbowner 'xxx'
create user 'newuser' from login 'sa'
This way the sa login will be mapped to the newuser database user from now on.
A schema is a securable item which can be used to group database objects. Each database user has a "default schema" assigned.
Schema is a way of categorising the objects in a database. It can be useful if you have several applications share a single database and while there is some common set of data that all application accesses.
DBO is a DataBase Owner. You have created the database and you are a database owner.