In Visual Studio 2017, I have a SQL Server Project with a simple database using SQL Authentication.
I am trying to publish a new table. The publish script, however, is trying to drop and recreate the user I am using to publish the database.
GO
PRINT N'Dropping [adf]...';
GO
DROP USER [adf];
GO
PRINT N'Creating [adf]...';
GO
CREATE USER [adf] WITHOUT LOGIN;
GO
REVOKE CONNECT TO [adf];
GO
PRINT N'Creating <unnamed>...';
GO
EXECUTE sp_addrolemember #rolename = N'db_owner', #membername = N'adf';
CREATE TABLE ....
I read the View Preview:
** Highlights
Tables that will be rebuilt
None
Clustered indexes that will be dropped
None
Clustered indexes that will be created
None
Possible data issues
None
** User actions
Drop
[adf] (User)
Create
[adf] (User)
[staging].[square_transactions] (Table)
** Supporting actions
Create
Role Membership: <unnamed> (Role Membership)
Your permissions to see all objects in the server or database could not be verified. The original error was:
The SELECT permission has not been granted on 'sys.sql_logins' for the 'master' database. You must be a member of the 'loginmanager' role to access this system view.
Reverse Engineer will continue the import process, and logins will not be imported.
The reverse engineering operation will attempt to continue anyway, but the resulting model might be incomplete, malformed, or incorrect.
I added the loginmanager role to the login [adf] wondering if this would fix the dropping and creating of the [adf] user. It did not.
Finally, I published using the server admin account. It still drops and creates the user, but was at least able to run.
How can I resolve this issue? I was thinking I should not use the server level admin account to do database development in SSDT/VS.
You need to add Adf as login to master database also. You just need to create that login on master once. Please try the following:
---- On server level
CREATE LOGIN adf
WITH PASSWORD = 'ThisIsAStrongPassword!'
GO
---- Create user on Master database Level
CREATE USER adf
FOR LOGIN adf
WITH DEFAULT_SCHEMA = dbo
GO
exec sp_addRoleMember 'dbmanager', 'adf';
exec sp_addRoleMember 'loginmanager', 'adf'
---- Create user on your user database
CREATE USER adf
FOR LOGIN adf
WITH DEFAULT_SCHEMA = dbo
GO
exec sp_addRoleMember 'db_owner', 'adf';
Related
I hope you can help me with this.
We have an application that we need to restrict access to. The application will be using login TestApp.
I've been testing this using SQL Server Management Studio v 17.9.1 and we are using SQL Server 2016.
This Login will have access to all tables, stored procedures, views, functions and triggers within its own schema Test in the tatabase: Testing, and only to certain tables from dbo schema that we specify in the permissions of the TestAPP user.
I've used the following script to achieve that.
The problem we are having is that the Login can access all system views and stored procedures and we don't want this level of access (attached pictures enter image description here) enter image description here
This login shouldn't be able to do those under schema TEST.
Create, drop, alter tables from Test schema
Create, alter, drop views from Test schema
Create, alter, drop stored procedures from Test schema
We are trying to use Roles so that we don't have to specify each and every sys object that we want to deny access to.
I've created the Role [db_TestExecutor] and attached the role to the user. and then gave specific permissions for the dbo tables but still they can see all sys objects.
Used SQL code below:
USE [Testing]
GO
CREATE SCHEMA [Test] AUTHORIZATION [dbo]
GO
CREATE ROLE [db_TestExecutor]
GO
GRANT EXECUTE ON SCHEMA::Test TO [db_TestExecutor]
GO
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::Test TO [db_TestExecutor]
USE [mASTER]
GO
IF NOT EXISTS (SELECT 1 FROM sys.server_principals WHERE [name] = 'TestApp')
BEGIN
CREATE LOGIN TestApp WITH PASSWORD=N'Password123', DEFAULT_DATABASE=[tempdb], DEFAULT_LANGUAGE=[British], CHECK_EXPIRATION=OFF, CHECK_POLICY=ON
END
USE [Testing]
GO
CREATE USER [TestApp] FOR LOGIN [TestApp]
GO
ALTER ROLE [db_TestExecutor] ADD MEMBER [TestApp]
GO
GRANT INSERT ON [dbo].[tblOrders] TO [TestApp]
GO
GRANT SELECT ON [dbo].[tblOrders] TO [TestApp]
GO
GRANT UPDATE ON [dbo].[tblOrders] TO [TestApp]
GO
GRANT SELECT ON [dbo].[test] TO [TestApp]
I expect the TestApp login to be able to see only objects from Test schema and only certain dbo tables.
Please see below the desired result:
Thank you very much for your help!
I created a new login and a new user in Azure SQL server database.
What I want to do is providing a read only permission to this role for a single table in the database.
While doing this I ran the below script:
EXEC sp_addrolemember N'db_datareader', N'new_user'
GO
But with this permission the new user can view all the tables in the database.
So I tried running the below script with 'public' role.
EXEC sp_addrolemember N'public', N'new_user'
GO
But its giving me this error:
"Membership of the public role cannot be changed."
How to provide only a single table read permission to the new user?
Execute the following statement on master database to create your new user login (mydb_user)
CREATE LOGIN mydb_user
WITH PASSWORD = 'p#ssw0rd'
GO
Run below statements on the user database
CREATE USER mydb_user FROM LOGIN mydb_user ;
GO
GRANT SELECT ON dbo.Events TO mydb_user;
I tested this on my side. It should work on your side.
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 creating a website which has access to 2 SQL Server 2014 databases.
I'm a bit of a noob - I've only ever granted access to a single database before and I use this script:
USE [master]
GO
IF EXISTS(SELECT * FROM sys.syslogins WHERE name = N'MyUser')
DROP LOGIN [MyUser];
GO
CREATE LOGIN [MyUser]
WITH
PASSWORD=N'******',
DEFAULT_DATABASE=[MyDatabase],
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
-- Drop & recreate db-user
USE [MyDatabase]
GO
IF EXISTS (SELECT * FROM sys.database_principals WHERE name = N'MyUser')
DROP USER [MyUser];
GO
CREATE USER [MyUser] FOR LOGIN [MyUser]
GO
EXEC sp_addrolemember N'db_owner', N'MyUser'
GO
However, when I run the script on the second database, I lose access to the first database. I have access to both if I create 2 different users.
So, a question - what do I need to do to this script so that I can retain acces over multiple databases?
The first chunk of code in your script drops the login from the server, if it's already present. So if you're running the entire script two times, it will create the login, create the database user (and associate it to the login), then drop/re-create the login at the start of the second iteration.
If you need to add this login as a user within a second database, all you need to do is execute the second half of the script for any additional database. (Although as alluded to in the comments, using SQL Server Management Studio to do this in the UI is much easier.)
I am creating a new read/write user on SQL Azure as follows:
-- Connected to master
create login [fred] with password = 'xxx';
-- Connected to my DB
create user [fred] from login fred;
EXEC sp_addrolemember 'db_datareader', 'fred';
EXEC sp_addrolemember 'db_datawriter', 'fred';
When I login using SSMS I get an error saying Cannot open database "master" requested by the login. The login failed.
What am I doing wrong or missing?
By default, SSMS tries to connect to master, but your new account does not have access to master; only the user database I presume.
On the login screen of SSMS, you need to specify the database name as well; just click on the Options >> icon, which opens up the Connection Properties tab. In there, specify the database name you are trying to connect to.
After creating the database user in the specific database Database1,
again select 'master' and create database user.
Execute below statement twice - one for Database1 and another for 'master'
CREATE USER appuser1 FROM LOGIN appuser1;
Unfortunately, this is not documented in Azure help
https://learn.microsoft.com/en-gb/azure/azure-sql/database/logins-create-manage
--> Open new query window for master database and execute this commands
CREATE LOGIN AppLogin WITH password='XXXXXX'
GO
CREATE USER [AppUser] FOR LOGIN [AppLogin] WITH DEFAULT_SCHEMA=[dbo]
GO
--> Open new query window for YOUR Database
CREATE USER [AppUser] FOR LOGIN [AppLogin] WITH DEFAULT_SCHEMA=[dbo]
GO
EXEC sp_addrolemember 'db_owner', 'AppUser';
GO
Source: How to create custom user login for Azure SQL Database
As Karol commented in Herve Roggero's response, I had the same problem even after selecting the database.
In our case the problem was that the users we created in our databases were disabled.
After we run the following script in the database we wanted to connect for each user:
GRANT CONNECT TO [ourDbUser]
We refreshed the database's users and now they were enabled, and then we were able to connect to the database successfully.
For me, the issue was that the person who created the user on the database did so without specifying FROM LOGIN, therefore the user was available in the Security->Users tab, but login was still not possible. I had to recreate the user and linking it to the login with the same name on the database:
DROP USER [myuser]
GO
CREATE USER [myuser] FROM LOGIN [myuser] WITH DEFAULT_SCHEMA=[dbo]
GO
and then granting the correct permissions on the database, in my case:
ALTER ROLE db_datareader ADD MEMBER [myuser]
ALTER ROLE db_datawriter ADD MEMBER [myuser]
Two other reasons that can trip you up:
The Server Login and the Database User must be the same. You cannot have APILogin link to APIUser, Azure just doesn't like it
Hyphens aren't allowed in usernames on Azure, so you can't have API-User