I have a Windows account that is used for running services (i.e. it’s not intended that any person should log in as that account). Turns out one of the services needs to access a remote network share that’s on a machine in a different Windows domain, and so needs to supply remote credentials to get to that share.
Now if it was me needing to access the remote share, I would simply open Credential Manager, and save the required credentials. But it’s not me, and my understanding of credential manager is it only saves credentials to be used by the logged in user.
I can of course solve this problem. I temporarily elevate the privileges of the service account to allow interactive logins, then I login as that user and use credential manager to store the correct remote credentials. Then I remove the interactive login privileges. But that feels very hacky and not the kind of thing I ought to be doing.
The work around is to log in with your normal user account and then run following in an elevated command prompt;
Login to SQL Server as an admin account. Run following query by impersonating the user;
execute as user = 'SomeUserName' -- Set this to the user name you wish to check
select * from fn_my_permissions(null, 'DATABASE') -- Leave these arguments, don't change to MyDatabaseName
order by subentity_name, permission_name
This will list all effective permission for this user;
I have a web application. This application connect to MS SQL SERVER 2017 for data manipulation (SELECT, UPDATE, DELETE, INSERT) and execute stored procedures. The application also run SQL Agent jobs. I need to create a user in the database to allows application to connect and execute queries, stored procedures and run SQL Agent jobs.
Open SSMS (sql server management studio) login through sysaddmin acount e.g. sa
Make sure “user1” has connect permission to yourDB.
Execute this query
use yourDB go
GRANT EXECUTE TO user1 GRANT SELECT TO user1 GRANT INSERT TO user1 GRANT UPDATE TO user1 GRANT DELETE TO user1
and also execute this
GRANT ALTER ON SCHEMA::dbo TO user1
where user1 is your user
If we want to allow this user to run sql agent jobs, we need to add it to “SQLAgentOperatorRole”. This role will allow the user to run any job on the server.
Now to SQL Agent permissions;
CREATE USER [user1] FOR LOGIN [user1]
ALTER ROLE [SQLAgentOperatorRole] ADD MEMBER [user1]
Make sure user has these permissions in MSDB database;
This is a good article on setting up jobs and an idea to integrate those jobs in UI.
for troubleshooting, assign user to “sysadmin” Server Role. Make sure to revoke this permission afterwards.
I am not able to drop a SQL user and keep getting this error message;
Msg 15138, Level 16, State 1, Line 5
The database principal owns a schema in the database, and cannot be dropped.
There is an orphan user who owns a schema or role and can not be dropped until user is detached from schema/role.
First see if there is any role associated and remove it;
-- Query to get the orphan users
EXEC sys.sp_change_users_login 'REPORT'
-- Query to get the user associated Database Role
DBPrincipal_2.name as [Role], DBPrincipal_1.name as [OWNER]
FROM sys.database_principals as DBPrincipal_1
INNER JOIN sys.database_principals as DBPrincipal_2
ON DBPrincipal_1.principal_id = DBPrincipal_2.owning_principal_id
WHERE DBPrincipal_1.name = 'ADDUSER'
--Query to fix the role
ALTER AUTHORIZATION ON ROLE::[db_owner] TO [dbo]
SSMS STEPS: Object Explorer->Target Server->Target Database->Security->roles->Right click on database role. Change user name to your selected name or “dbo” and click OK.
Now fix the issue where we will transfer the ownership of the database role/schema to dbo.
----*** Query to get the user associated schema
select * from information_schema.schemata
where schema_owner = MyUser'
--Query to fix the error Msg 15138 on database schema
ALTER AUTHORIZATION ON SCHEMA::[MyDatabaseSchema] TO [dbo]
--Query to drop the user
DROP USER [MyUser]
SSMS STEPS: Object Explorer->Target Server->Target Database -> Security->Schemas->Right Click on schema->Change user name to your selected name or “dbo”.
Schema and/or database role has been transferred to “dbo”. You are safe to drop the user.