I have created contained database roles in an Azure SQL database, granted permissions to the roles, and created database users mapped to Azure Active Directory, and added the database users to the applicable roles. However, the users don't appear to be automatically inheriting the permissions of the roles (I've confirmed they were successfully added). Am I missing a step?
CREATE USER [User.Name#Company.com] FROM EXTERNAL PROVIDER
ALTER ROLE [DATABASE-ROLE] ADD MEMBER [User.Name#Company.com]
Note: The roles have Select and View Definition permissions, but the users are only showing Connect permissions.
I have the same issue. I run ran the command as below to create a role which has select permission and assign the role to a Azure AD user.
CREATE ROLE testrole AUTHORIZATION [dbo]
GO
-- Grant access rights to a specific schema in the database
GRANT
SELECT,
VIEW DEFINITION
ON SCHEMA:: [dbo]
TO testrole
GO
create user [jim#hanxia.onmicrosoft.com] from EXTERNAL PROVIDER
GO
ALTER ROLE testrole ADD MEMBER [jim#hanxia.onmicrosoft.com]
GO
Then I run the command :
SELECT p.NAME
,m.NAME
FROM sys.database_role_members rm
JOIN sys.database_principals p
ON rm.role_principal_id = p.principal_id
JOIN sys.database_principals m
ON rm.member_principal_id = m.principal_id
GO
SELECT DISTINCT pr.principal_id, pr.name, pr.type_desc,
pr.authentication_type_desc, pe.state_desc, pe.permission_name
FROM sys.database_principals AS pr
JOIN sys.database_permissions AS pe
ON pe.grantee_principal_id = pr.principal_id;
It shows that I have assigned the role to the user ans the use only has connect permission.
But I run the command:
EXECUTE AS user = 'jim#hanxia.onmicrosoft.com'
select * from student
It shows that the user has select permission.
So I think Transact-SQL support Azure AD user in Azure SQL database is not perfect. Is that right? Can someone explain it?
Related
I have a Azure SQL DB. I need to give a Azure group permissions to do select statements to get data out of this DB, but it's important they can't do anything to mess it up with delete/update etc.
I created a SQL user from a 365 group with
CREATE USER [GroupName] FROM EXTERNAL PROVIDER
, but now these group members have permission to do update/delete commands etc. I only want these group members to be able to do select statements. However...
EXEC sp_addrolemember 'db_datareader', 'GroupName'
ALTER ROLE db_datareader ADD MEMBER [GroupName]
gives the error:
Cannot alter the role 'db_datareader', because it does not exist or you do not have permission.
Why is this? I would assume I need to revoke the current permissions anyway?
I'm assuming you are grating permission to Azure Active Directory Group.
Use the below statements and it should work fine.
EXEC sp_addrolemember 'db_datareader', 'Azure Active Directory Group'
GRANT SELECT ON SCHEMA::<schema_name> TO [Azure Active Directory Group]
Note: Make sure you have required permission on the schema level to grant the required permission. Please see the permissions here.
I wasn't able to figure it out so I just deleted the user and created from scratch.
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'm trying to drop all the logins from SQL server except the default built-in SQL server logins but I'm unable to drop the <domain>\administrator account. It gives me following error:
Server principal '<domain>\administrator' has granted one or more
permission(s). Revoke the permission(s) before dropping the server
principal.
I tried checking the permission assigned to this user using this query :
Select *
from sys.server_permissions
where grantor_principal_id =
(Select principal_id
from sys.server_principals
where name = N'<domain>\administrator')
This query returns only one record corresponding to an end-point as below:
class class_desc major_id minor_id grantee_principal_id grantor_principal_id type permission_name state state_desc
105 ENDPOINT 65536 0 269 259 CO CONNECT G GRANT
But when I try to check the rights assigned to this user on all of the existing end-points, I find none have any kind of permissions for the user I'm trying to delete.
I'm not sure what is happening and where to look for to drop this user.
I was able to solve this issue. There were following issues which were not allowing me to drop the <Domain>\administrator login from SQL server:
Owner of ReportServer and ReportServerDB databases was <Domain>\administrator user
Owner of ConfigMgrEndPoint end-point was also <Domain>\administrator user.
I changed the ownership of all the above mentioned SQL objects. I made sa user as their new owner. Then I was successfully able to drop the <Domain>\administrator user. I also got following expert comment from one of my colleagues who was helping me with this issue :
Keeping [sa] as a default owner for most sql objects is a standard
practice. Making a domain user as owner of SQL objects can affect the
working later on if that user no longer exists or is disabled in the Active Directory at any point of time
to find out what are the permissions that are preventing the dropping of the login
I am using this script:
SELECT ##SERVERNAME,##SERVICENAME
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
DECLARE #GrantorName nvarchar(4000)
SET #GrantorName = 'xxx\the_login' /* Login in Question */
SELECT b.name as Grantor
, c.name as Grantee
, a.state_desc as PermissionState
, a.class_desc as PermissionClass
, a.type as PermissionType
, a.permission_name as PermissionName
, a.major_id as SecurableID
FROM sys.server_permissions a
JOIN sys.server_principals b
ON a.grantor_principal_id = b.principal_id
JOIN sys.server_principals c
ON a.grantee_principal_id = c.principal_id
WHERE grantor_principal_id =
(
SELECT principal_id
FROM sys.server_principals
WHERE name = #GrantorName
)
and sometimes this one:
--Check to see if they own the endpoint itself:
SELECT SUSER_NAME(principal_id) AS endpoint_owner ,name AS endpoint_name
FROM sys.database_mirroring_endpoints;
--If so, you'll need to change the endpoint owner. Say the endpoint is called Mirroring, and you want to change the owner to SA:
--ALTER AUTHORIZATION ON ENDPOINT::Mirroring TO sa;
or following these instrustions:
--1) Check to see if this logon only has server level permissions and check to see
--if this login has granted permissions to another server principal.
--Use this query to identify the permissions granted.
Select perm.* from sys.server_permissions perm
INNER JOIN sys.server_principals prin ON perm.grantor_principal_id = prin.principal_id
where prin.name = 'xxx\the_login' /* Login in Question */
--2) The permissions granted will need to be revoked , to allow the DROP LOGIN to complete.
--The permissions can be granted again by a suitable LOGIN.
there is also a very nice article related to this:
Drop Login issues for logins tied to SQL Server Availability Groups
You'll have to check for "server permissions" and "explicit permissions".
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
I am having trouble granting permissions to users of my database. For instance, I cannot seem to get my user SELECT privileges no matter how many securables and memberships I give it. I started by giving the user select permission database>security>Users>Properties>securables
and giving it db_datareader membership. After this did not work I added the user to all of the memberships and granted him all permissions available in the securables section. After that failed, I gave the user all permissions available in the security>login>properties, I added the login to all server roles accept sysadmin and gave the user ownership of all schemas in the database I want him to access. Still I get this same error below:
The SELECT permission was denied on object 'Patient_Information', database 'Clinical_Data', schema 'dbo'
When I add the login to the role sysadmin, the user that it is mapped to has no problem doing selects, inserts and basically anything else. The weird thing is that when I look into database>properties>Permissions the user does not have any of the permissions that I have granted him in the securables section. Here is the code I use to grant:
USE Clinical_Data; GRANT Select on schema::DBO to lab31
Thanks in advance for any help you can provide.
I usually create a database role and assign the user to the role. Assign the schema privileges to the database roles. A quick example of this using code for a fictitious database is below.
--
-- 1 - GRANTING CORRECT USER ACCESS BY SCHEMA
--
--create test user login
CREATE LOGIN [User1] WITH PASSWORD=N'p#55w0rd'
GO
-- Make sure we are in autos
USE [AUTOS]
GO
--create user in test database
CREATE USER [User1] FOR LOGIN [User1] WITH DEFAULT_SCHEMA=[ACTIVE]
GO
--create role
CREATE ROLE [Auto_User] AUTHORIZATION [dbo]
GO
--apply permissions to schemas
GRANT ALTER ON SCHEMA::[ACTIVE] TO [Auto_User]
GO
GRANT CONTROL ON SCHEMA::[ACTIVE] TO [Auto_User]
GO
GRANT SELECT ON SCHEMA::[ACTIVE] TO [Auto_User]
GO
--ensure role membership is correct
EXEC sp_addrolemember N'Auto_User', N'User1'
GO
If you are more comfortable with SQL Server Management Studio, here is a go. All actions might not be exact but I did check them with SS 2012.
Lets say your login is [bilbo] and the database they want to access is [middle earth].
Is the default database for the server login = [bilbo] the database they are trying to query, [middle earth]?
[SMSS object explorer path]: Server -> security -> logins -> right click + properties
Is the server login mapped to a database user named [bilbo] in the [middle earth] database?
[SMSS object explorer path]: Database name -> security -> users
Make sure the user [bilbo] is not in any deny database roles (db_denydatareader, db_denydatawriter). Any deny actions over ride any grants.
[SMSS object explorer path]: Database name -> security -> roles -> database roles -> select + right click + properties
{You would add your custom database role here.}
Make sure the user [bilbo] has permissions to the schema.
[SMSS object explorer path]: Database name -> security -> schemas -> select + right click + properties
This should give you the layout of the land.
Find the offending revoke or lack of permission and assign it.
Please do not give out all server roles or all database roles! You are just asking for a head ache when the user does something stupid like drop table.