I'm unsure what I'm missing here, but I cannot connect from Logic App to Azure SQL. Any help is appreciated.
Steps performed:
1. Enabled System Assigned Managed Identity (SAMI) for the Logic App
2. Added the SAMI in a Contributor role for the SQL Server (its in another resource group)
3. Verified the SAMI role by clicking the Azure role assignments button
4. Added the SAMI in both the db_datareader and db_datawriter roles within the SQL Server itself using:
CREATE USER [SAMI Name] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [SAMI Name]
ALTER ROLE db_datawriter ADD MEMBER [SAMI Name]
5. Verified the internal roles were successful with:
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;
6. Add the Get Rows (V2) Azure SQL action in the Logic Apps Designer and create the connection
7. I can see that no server is found, so I enter the SQL server name as a custom value
8. After letting the Database Name load for a few mins, the action errors-out with:
Error text:
Could not retrieve values. Error code: 'Unauthorized', Message: 'Credentials are missing or not valid.
inner exception: The credentials provided for the SQL source are invalid. (Source at xxx.database.windows.net.)
clientRequestId: da158fe9-xxx'. More diagnostic information: x-ms-client-request-id is 'B1CBF136-xxx'.
I have allowed Azure Services on the SQL Server, so I don't get why this is happening
I'm not sure of the cause of this, but I found that if you also enter the database name as a custom value then the connection works.
I experienced exactly the same symptoms as you. After manually entering the database name, the list of table names populates automatically.
I also found that it's not necessary to add the SAMI as a contributor to the SQL Server (at least, not for this particular workaround).
Before entering custom database name:
After entering custom database name:
Related
I am the admin of my SQL server which I have created and I am testing on altering server level roles and for that I am trying below commands. The first one returns executed successfully and the second one returns 0, which means I dont have that spoecific server role. can anyone explain me why this is happening. What wrong am i doing here?
ALTER SERVER ROLE ##MS_ServerStateReader##
ADD MEMBER zzzsharepoint;
GO
select IS_SRVROLEMEMBER('##MS_ServerStateReader##', 'zzzsharepoint')
This is documented behaviour:
Return Types
int
Return value
Description
0
login is not a member of role. In Azure SQL Database, this statement always returns 0.
1
login is a member of role.
NULL
role or login is not valid, or you do not have permission to view the role membership.
For whatever reason, the documentation on Azure SQL Databases suggests otherwise. It also suggests using a query to check the permissions, however, that always returns no results as well. If the ALTER SERVER ROLE ran successfully, I would suggest that the role has had the role added.
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';
Trying to write an audit report for user permissions and access on a SQL Server 2012 database.
Using the following tables -
sys.database_role_members
sys.database_principals
sys.login_token
sys.database_permissions
sys.columns
sys.objects
Can get all the information required, except for the Login name associated with the database User.
Can anyone point me in the direction of where this information can be found?
Select ORIGINAL_LOGIN() as [Login]
The detailed info can be found here :
Microsoft ORIGINAL_LOGIN()
To add to your comment:
You can either restrict the user from accessing the database or not.
Same is applied to the server
SQL server does not provide you with the features to "Allow him/her to access the database, but if he/she does let me know"
In that case you would need to provide some custom functionality such as creating a job that executes the query :
select login_time,original_login_name,DB_NAME(database_id) from sys.dm_exec_sessions
where original_security_id <> 0x01
And depending on condition etc (User1 logged on DB1 at xx:xx:xx time) insert into table.
You should also take a look at Logon Triggers which could prevent users from logging under a certain conditions and then recording it Microsoft Logon Triggers if that is something you might want to consider
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 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