A user had an issue with a login to an application. The error is "The Update permission was denied on the object '{tablename}', database '{databasename}, schema 'dbo'.
The user already has permissions based on a role that already allowed other users to properly login, making the necessary entry into the "log" table.
When checking the user with this code,
EXECUTE AS LOGIN = N'[AD UserName]';
SELECT
permission_name AS [Permission]
FROM fn_my_permissions(N'[ServerName]', N'DATABASE')
ORDER BY permission_name;
REVERT;
the results were:
CONNECT
EXECUTE
SELECT
VIEW ANY COLUMN ENCRYPTION KEY DEFINITION
VIEW ANY COLUMN MASTER KEY DEFINITION
I expected this:
CONNECT
DELETE
EXECUTE
INSERT
SELECT
UPDATE
VIEW ANY COLUMN ENCRYPTION KEY DEFINITION
VIEW ANY COLUMN MASTER KEY DEFINITION
I granted Insert, Update, Delete and Execute directly to the user for the database. The permissions were still not showing Insert, Execute or Delete and still the user can not log in.
I applied permissions directly to the table. Again the user could not access the application due to the error when inserting into the table.
Additionally the user has access to other DB's on the server but I am not able to find why on this database the user's granted permissions are not correctly applied.
Where can I find if permissions are being altered due to server level permissions or other ideas i am not able to think of.
Thank you in advance
The issue was the user was part of a group that had db_denywriter checked on the same database.
The question still remains what is the best way to determine the permissions of a user, even if it's through a group permission, are denied or granted.
The lack of something should not equate to true, or false.
Thanks!
Related
I have a huge problem with rights of new users of my SQL Server database. The new user cannot see any tables but is still able to drop them or create new tables.
Code to create the user:
--Code Start
--This is how I instantiate the new user:
CREATE LOGIN userName WITH PASSWORD 'password';
CREATE USER userName FOR LOGIN userName;
--Furthermore, the user get some roles. So that the user can do at least something:
CREATE ROLE roleExample;
GRANT DELETE, INSERT, SELECT, UPDATE ON dbo.exampleTable TO roleExample;
SP_ADDROLEMEMBER roleExample, userName;
--Code End
In my opinion, the new User should only be able to operate on the exampleTable now. But as I said, the user is also able to create and drop tables.
That's why, I added some constraints to the role, the new user gets:
DENY CREATE TABLE TO roleExample AS dbo;
This did not help either. The User is still able to create tables in dbo.
This problem is btw. not related to a specific schema. The new user can create and drop tables in any schema.
I guess that new users are allowed to create or drop tables by default. Sadly, I do not know how to change it.
I hope you guys can help me.
Attached is an example, where you can see that the user does not know the schema, where a new table should be created. Nevertheless, the schema exists and after executing this statement, the table is created. The error-message just says that this table is already created, because I executed this statement twice. Still, the user is not able to see its own created table in SQL Server Management Studio.
User does not know schema, but still can create tables in it
OK, so there's several things that it might be, but by far the most likely is that someone has granted some database permission(s) to the public role or to some AD group that your users are all in. (Also possible, but less likely is that something similar has been done to the server permissions).
To check for database permissions open SSMS (SQL Server Management Studio), right-click on your database in the Object Explorer pane and select "Properties". Then in the Database Properties window click the "Permissions" page from the list on the upper-left.
If there are any database permissions granted to any Users or Roles, they should appear in the upper listbox. If Public is in there click it to see if has been granted any database-wide permissions. All users have the Public role, so anything granted here is automatically granted to all users.
If that isn't it, then check any other roles listed in the upper listbox. Also check any users that look like they might be AD Groups because these work like DB roles except that SQL Server cannot administer them, nor tell who's in a specific group from these interfaces.
If you don't find anything here, then repeat this for the Server Permissions also.
I have a user created in sqlserver -> security -> Logins
I would like to provide the db owner role to the existing user to a database.
When i try change the user properties in SSMS, i get the following error:
The user already exists. I only want to update the owner property.
Can anyone help me with this?
Thanks
Because the user already exists in individual db, update the db owner can't be done until the user is dropped.
so i dropped the user by droppping the owned schema first and then dropped the user
https://dba.stackexchange.com/questions/19456/the-database-principal-owns-a-schema-in-the-database-and-cannot-be-dropped-mess/19458
I want to update a table in databse B, from a trigger in database A. The trigger in database A is fired via different user accounts, which may or may not have permission on Database B. It works fine with the users which have permission on database B.
However, when trigger is fired under a user account, it throws exception because user does not have permission on the object referred by the Synonym. Is there a way to check permission on the object referred by Synonym so that I can avoid the exception when user does not have permission?
Finally, I found it in documentation. Below query did the trick.
IF (SELECT HAS_PERMS_BY_NAME('ams.syn_bkgsvcattribute', 'OBJECT', 'INSERT'))>0
print 'yes'
else
print 'no'
I've just migrated from SQL2000 to SQL2008 and I have started getting an execute permission issue on a stored proc which uses sp_OACreate.
The rest of the system works fine with the db login which has been setup and added to the database.
I've tried:
USE master
GO
GRANT EXEC ON sp_OACreate TO [dbuser]
GO
But this fails with the following error:
Msg 15151, Level 16, State 1, Line 1
Cannot find the user 'dbuser', because
it does not exist or you do not have
permission.
I'm logged into the server as sa with full permissions. I can execute a similar sql statement and apply the permissions to a server role, however not a login/user.
How do I apply the changes to the specific user/login?
I can apply the permissions to the public role and it resolves my issue; however this seems to be a security issue to me which I don't really want to apply to the live server.
Leading on from John's answer I checked the user listings on the Master database and my user wasn't there. Whether it had been deleted or lost some how I don't know. Something may have gone crazy with the migration of the dbs to the new server instance.
Anyway; re-creating the user and associating it to the specific login enabled me to run the following statements on the master database to allow for the execution of the stored procs.
USE MASTER
GO
GRANT EXECUTE ON [sys].[sp_OADestroy] TO [dbuser]
GO
GRANT EXECUTE ON [sys].[sp_OACreate] TO [dbuser]
GO
GRANT EXECUTE ON [sys].[sp_OAMethod] TO [dbuser]
GO
GRANT EXECUTE ON [sys].[sp_OASetProperty] TO [dbuser]
GO
Thanks for all the help and pointers. Hope this helps other people in the future.
The error suggests that the User "dbuser" does not exist in the master database.
I assume the user exists within the master database?
You can check by using the following T-SQL
USE MASTER;
GO
SELECT *
FROM sys.sysusers
WHERE name = 'dbuser'
If the user turns out not to exist, simply use the CREATE USER statement and create a user called "dbuser". The user will automatically be mapped to a Login of the same name, provided one exists.
Your problem could be related to orphaned users.
Try
USE MASTER
GO
EXEC sp_change_users_login 'Report'
This will return one row per orphaned user name. Then,
EXEC sp_change_users_login 'Update_One', 'dbuser', 'dbuser'
Here is some code I'm using the verify that (current user) has EXECUTE permission on sp_OACreate etc:
use master;
select state_desc,name from
sys.database_permissions a
left join
sys.all_objects b
on a.major_id = b.object_id
where name like 'sp_OA%';
As pointed out by #John Sansom and #WestDiscGolf the user has to exist in the Master database and the execution rights must granted in the Master database, hence use Master is required. The query above will return records if the user has execute permissions and empty set if they do not. (Execution in the user database will also return empty set.)
I couldn't figure out a way check these permissions using fn_my_permissions, which is supposedly the right tool for jobs like this.
Check if your user has permissions for the database you use. You can do this by Security -> Logins -> Select User and open the properties window. Then select "User Mapping" from the right menu. Now check the databases that you want the given user to have access to. After that select from the bottom part of the window "Database role membership" and check "db_owner". Now the user will be the owner of the database and will be able to execute queries, store procedures and so on.
UPDATE:
Add user for the database by selecting your database -> security -> users -> right click "New User"
Or you can use this query
CREATE LOGIN AbolrousHazem
WITH PASSWORD = '340$Uuxwp7Mcxo7Khy';
USE AdventureWorks2008R2;
CREATE USER AbolrousHazem FOR LOGIN AbolrousHazem;
GO
Here are more details http://msdn.microsoft.com/en-us/library/ms173463.aspx
Using SQL Server 2008.
I created a new database, created a new user and mapped the user to the same login name.
Gave the user all the roles available including db_owner.
The user created a new table but when the user tried to select from the table, an error "The SELECT permission was denied on the object ...." showed up.
Why doesn't the user have select permission if the user is member of the db_owner and db_datareader roles?
I recall this used to work before.
MOst likely the user isn't actually the DBO. Check the table name is [dbo].[tablename] and that the user actually is the dbo.
Actually - More information about the error would be nice. Cause you usually have select access to tables you have created.
Are there any deny permissions set?