I am trying to synchronise databases in two different subscriptions using Azure datasync on the new portal
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-get-started-sql-data-sync
On the portal, I do not get the ability to choose subscription or connection string to connect to a Azure database on a different subscription (this is not on premise)
The options presented are either
a) Database from existing subscription + database server
b) on-premise database- with a sync agent to be downloaded
Can linking to another database via connection string be implemented via API's or is there any restriction or feature limitation around this?
Based on your comment, your issue is due to you having different logins for each subscription. In order to achieve what you want to do, you will need to cross add the various users to the subscriptions.
First, log into your Azure portal. Navigate to the subscription you are the admin for. Click on Access control (IAM) to manage the permissions for it.
Click the Add button which will bring up a dialog to add permissions. Simply select the role you wish to grant (I believe you will need contributor for this) and enter the email address of the user that you want to grant permissions to.
Related
I am attempting to share an SQL view via Azure Data Share. I have set up the data share, created a share to send, and am attempting to add a dataset. I am logged into Azure Portal as me#example.com. I am also connected to the database (an Azure SQL DB) in SSMS as me#example.com. I do the following:
Select "Add datasets"
Select "Azure SQL Database"
Select the resource group
Select the SQL server
I got the the message about setting up permissions (the create user and exec sp_addrolemember db_datareader query), which I did successfully in SSMS. So, next I select the data, which was found successfully, and select "Next". This is where the problem starts.
I am given the options for Tables and Views. However, neither is populated. I can see all the tables and views in SSMS, including the view I created. However, when I select, say, "View" from the 2 options, it finds nothing and says, "No results to show".
This is mystifying. I clearly have access and permissions, yet it won't even populate the list of views. Any suggestions what might be causing this? This is my first Azure Data Share, and I could easily have missed something, but it seems like it should have everything that it needs for this operation.
Here are my assumptions:
It is using my Azure Portal login credentials to authorize access to populate the list.
The fact that I can see the tables and views in the SSMS Object Explorer implies sufficient permission to see the same in Azure Portal.
Since this data share and the database are in the same resource group, no firewall configuration is needed.
I am trying to provide DBAdmin privilege for a user on multiple databases.
I know how to do from on premises SQL database, I can directly map the user to required databases.
Can anyone let me know how to do it in Azure managed instance. Since the added user is external user, can,t see it in the Logins to map the user.
I have like 100 databases on which the user should have db admin right. Is there a easiest way to do that?
You can use an Azure Active Directory Login
eg
CREATE LOGIN [someuser#somecompany.onmicrosoft.com] FROM EXTERNAL PROVIDER
then create users mapped to this login in the appropriate databases, or make this login a sysadmin. Not sure if this shows up in SSMS, as it was added relatively recently. So you may have to create the users and grant them permissions in the target databases in TSQL, as per: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-aad-security-tutorial
I'm using CouchDB 2.1.0 and for my use case I would like non-admin users to be able to create their own databases that they will then have write/read access to, and the ability to add other users with write/read access.
Note that this is not one database per user, which seems to be the common use case, but many user-created databases per user.
Users are being created right now by POSTing to the _users database. Authentication is being handled by CouchDB's built-in authentication.
I could create a backend service that has admin credentials that would create these databases, but I would like to avoid doing so. Reading through docs it seems like by default CouchDB only allows admins to create databases; is there a way to change this?
Honestly, I think the only real answer here is that you'll have to make a backend service that has admin credentials that can create new databases. Kind of a bummer since one of my goals for this project was "no backend other than CouchDB".
My backend service ended up just taking a list of users that should have access to the created database, creating the database with a unique ID, and returning that ID. I then have a document in each user's DB that lists all of the DBs they have created.
Can someone tell me how can I add Azure Active Directory groups into the azure sql server, I am using server manager tool to do this but cant find any way to figure this out, I can add simple Azure Active Directory user though..What about groups?
I will assume that you are wanting to provide access for end-users to connect, not Database Administrators. For my example below, let's say that the end-users are in a group called "AZ-Users", and that your Database Administrators (including you) are in a group called "AZ-DBAs".
For Azure SQL Databases, there are key things that must be in place to get this to work:
There must be an "Active Directory admin" configured for your server. This can be any AAD user or an AAD group. You can check if this has been set or not by going to the Azure portal page for your server. Be careful that you are looking at the Overview page for the server, not the individual database, they are not the same thing. Detailed instructions here. In our example, we would configure this to be the AAD group called "AZ-DBAs".
When you are ready to create the AAD login for "AZ-Users" on your Azure SQL Database, you must yourself be logged in using AAD... meaning a member of the "AZ-DBAs" group from my example above. You can use SSMS or any other similar tool for executing TSQL commands. Note that if you try a SQL auth connection instead, it won't work for step 4 below - you'll get this error:
Msg 33159, Level 16, State 1, Line 1
Principal 'AZ-Users' could not be created. Only connections established with Active Directory accounts can create other Active Directory users.
Change the context to the database you want to provide access to for your end users.
Execute this statement:
CREATE USER [AZ-Users] FROM EXTERNAL PROVIDER
Note that this will create a "contained database user", as detailed here. That's it. This process works for AAD groups and AAD users.
You will probably also want to grant some level of permissions as well, such as:
EXEC sp_addrolemember 'db_datareader', 'AZ-Users'
All you need to know about how to configure and manage Azure Active Directory Authentication you can find it in this article.
Then to connect to SQL Azure using Azure Active Directory authentication please read here.
Connect to the server via SSMS as your Azure AD admin. Create a new query with the db you want to affect. Run this:
ALTER ROLE db_datareader ADD MEMBER [AzureADGroupName];
GO
To modify permissions, do something like this:
ALTER ROLE db_datareader ADD MEMBER [AzureADGroupName];
GO
I have recently been running into many different areas of SQL Server that I normally don't mess with. One of them that has me confused is the area of Logins and Users. Seems like it should be a pretty simple topic...
It appears that each login can only have 1 user and each user can only have 1 login.
A login can be associated to multiple tables thus associating that user to many tables.
So my question is why even have a login and a user? they seem to be pretty much one in the same. What are the differences, or what is it that I seem to be missing?
A "Login" grants the principal entry into the SERVER.
A "User" grants a login entry into a single DATABASE.
One "Login" can be associated with many users (one per database).
Each of the above objects can have permissions granted to it at its own level. See the following articles for an explanation of each
Principals
Database Users
One reason to have both is so that authentication can be done by the database server, but authorization can be scoped to the database. That way, if you move your database to another server, you can always remap the user-login relationship on the database server, but your database doesn't have to change.
I think there is a really good MSDN blog post about this topic by Laurentiu Cristofor:
The first important thing that needs to be understood about SQL Server
security is that there are two security realms involved - the server
and the database. The server realm encompasses multiple database
realms. All work is done in the context of some database, but to get
to do the work, one needs to first have access to the server and then
to have access to the database.
Access to the server is granted via logins. There are two main
categories of logins: SQL Server authenticated logins and Windows
authenticated logins. I will usually refer to these using the shorter
names of SQL logins and Windows logins. Windows authenticated logins
can either be logins mapped to Windows users or logins mapped to
Windows groups. So, to be able to connect to the server, one must have
access via one of these types or logins - logins provide access to the
server realm.
But logins are not enough, because work is usually done in a database
and databases are separate realms. Access to databases is granted via
users.
Users are mapped to logins and the mapping is expressed by the SID
property of logins and users. A login maps to a user in a database if
their SID values are identical. Depending on the type of login, we can
therefore have a categorization of users that mimics the above
categorization for logins; so, we have SQL users and Windows users and
the latter category consists of users mapped to Windows user logins
and of users mapped to Windows group logins.
Let's take a step back for a quick overview: a login provides access
to the server and to further get access to a database, a user mapped
to the login must exist in the database.
that's the link to the full post.
In Short,
Logins will have the access of the server.
and
Users will have the access of the database.
I think this is a very useful question with good answer. Just to add my two cents from the MSDN Create a Login page:
A login is a security principal, or an entity that can be authenticated by a secure system. Users need a login to connect to SQL Server. You can create a login based on a Windows principal (such as a domain user or a Windows domain group) or you can create a login that is not based on a Windows principal (such as an SQL Server login).
Note:
To use SQL Server Authentication, the Database Engine must use mixed mode authentication. For more information, see Choose an Authentication Mode.
As a security principal, permissions can be granted to logins. The scope of a login is the whole Database Engine. To connect to a specific database on the instance of SQL Server, a login must be mapped to a database user. Permissions inside the database are granted and denied to the database user, not the login. Permissions that have the scope of the whole instance of SQL Server (for example, the CREATE ENDPOINT permission) can be granted to a login.
Graph on logins / users from MS sql-docs