In Azure SQL I can query what temp tables currently exist by using the query -
select * from tempdb.sys.tables;
However, I am not able to find who created these. Surely there must be a simple way to find out who created these temp tables! There are links which suggest things, but all of that works on SQL Server, not Azure SQL.
Permissions
Any user can create temporary objects in tempdb. Users can
access only their own objects, unless they receive additional
permissions. It's possible to revoke the connect permission to tempdb
to prevent a user from using tempdb. We don't recommend it because
some routine operations require the use of tempdb.
The tempdb system database is a global resource that's available to all users connected to the instance of SQL Server or connected to Azure SQL Database.
By default, server admin, database owner or a user with required permission can access the tables of tempdb.
This official article on tempdb database is related to Azure SQL Database. Please go thorugh for more details and better understanding.
Related
We are testing the process for azure data share and have set up source shares from SQL db on our primary azure domain and shared them to accounts on our secondary azure domain.
We can accept the share invite and successfully map the source SQL data to blob storage but when we attempt to map the same share to a target SQL db we get the error:
Mapping failed. Please check Troubleshoot Azure Data Share for help
and try again.
Data Share account's Managed identity is missing required permissions
on database. For more details, please refer to
https://learn.microsoft.com/en-us/azure/data-share/subscribe-to-data-share
We have followed all the troubelshooting tips and can confirm the Data Share external user has the 3 roles on the target db (db_datareader, db_datawriter, db_ddladmin).
We have also made the Data Share identity a SQL Db Contributor on the target SQL server.
Is there anything else we need to update or checks we can run to find out why the data share is not mapping to SQL target. We really need to prove this process before we offer it to our clients so any help that can be provided would be gratefully received.
Thanks
There are several permissions are needed or conditions to access Database from Azure DataShare resource's managed identity:
First Set Azure Active Directory Admin to yourself in SQL server. After becoming admin Connect through Azure Active Directory authentication to the Azure SQL Database using SSMS and then grant db_datareader permission to the Data Share Resource-Managed Identity while granting this permission, make sure you're connected to the database by Azure Active Directory authentication not SQL authentication.
I have setup a Synapse environment and filled my storage account with some sample Parquet files. I have then created a serverless SQL database and created some external tables over the Parquet files. All this works fine and I can query these tables fine from the Synapse UI and SSMS using AD Authentication.
The problem is I want to connect an app to the serverless SQL database which doesn't support AD authentication. Therefore I want to connect it using a standard SQL account. I have setup a SQL account (username and password) and I'm able to connect through SSMS, but not query any tables due to this error...
External table 'TableName' is not accessible because content of directory cannot be listed.
I assume this is a double-hop authentication problem because the SQL user doesn't have access to the storage account? I can't seem to find any guides on how to do this. Does anyone know?
I've written a blog-post where this issue is tackled, as I've encountered this problem as well a few days ago. You can read it here.
Basically, it comes down to the fact that you have to:
create a SQL login for your user
create a credential in SQL that has the same name as the URL that points to the container in your datalake that contains the files you want to query
grant reference rights on that credential to your SQL login
create a user on your database for that login
Next to that, you also need to create some specific role-assignments.
This article says that an Azure subscription owner has access to all the resources in the subscription. However to get access to an Azure database, one must either be a user in the database, or be part of the Azure Admin AD group.
Can a subscription owner access the database regardless of the SQL security? If so, how?
The article you refer to gives a very high-level overview on RBAC roles provided in Azure.
It is important to understand these built-in roles that give access to the resources (the management plane) vs those that give access to the resource data (the data plane).
For example, many built-in roles give users access to data, for example: Storage and KeyVault.
As for databases, it all depends on the type of database engine your refer to. Each have specific particularities in terms of roles and permissions.
SQL Database is managed right in the SQL server. This link provides additional details on how this is done. SQL Database
Other modern database engines, such as Cosmos DB, come with different Azure Built-in roles (just like Key Vault or Storage). See this link in order to give you a better idea on the roles and permissions assigned for each roles. Role-based access control in Azure Cosmos DB
As the Azure Account owner, I have universal access, and can make copies of my databases in the Portal.
However, my team members, who are members of Active Directory groups cannot. because their Target Server list is empty.
I have granted the AD groups access (via the Access Control menu option) to both our database severs (and the owning resource group). So they are able to access the database server, but still they are unable to see it in their list of Target Servers when they try to make a copy.
Does anyone know what permissions are required to populate the Target Server list when copying databases?
Thanks,
Max.
Please reference this document Copy database within Azure:
When you copy a database to a different SQL Database server, the security principal on the new server becomes the database owner on the new database. If you use contained database users for data access, ensure that both the primary and secondary databases always have the same user credentials, so that after the copy is complete you can immediately access it with the same credentials.
If you want to see target SQL Server, the AD group members also should have the permission to access other resources in your subscriptions.
Make sure they are in the same subscription or add the role(I tried reader, owner and contributor and works well) to the member from Subscription IAM,:
Hope this help.
I copied many times an sqlDatabase but i can only access with my user.
As read in the documentation, the principal became the user who started the operation.
So i tried using the sql statement to copy the database logged as the sql server administrator, but invain.
I can't access to copied database with the original sql server principal.
I need to keep this super user on all the server databases.
There is no problem. I can connect to all the databases copied.
There is only a visible difference in Sql Server Management Studio.
It is a connection option:
if I connect with Connect to Database: default, I can see all the databases on my server.
if i choose a single one, i can see only it.