This may be a problem with Azure databases, but I'm hoping there is a solution.
On creating an SQL Database in Azure, the server has a SQL Admin account, which is configured, in this case, manually via the Portal when provisioning. This can only be a SQL Authenticated user.
And of course, I have an AAD group/user configured as the AD Admin as well.
I have also set up an automated deployment using SSDT. The problem arises when I attempt to register the DACPAC as part of the deployment, but only after the first deployment if I'm using the AD account to deploy. It tries to update the registered data-tier application but gets an error stating that it already exists. If I deploy with the SQL Authenticated SQL Admin user instead, then it deploys successfully.
For a few reasons, I want to deploy using an AD account, not least of which to be able to create other contained AD users, which a SQL Authenticated user can't do.
Doing some poking about, I'm able to delete the registered dacpac in SSMS if I'm connected as the SQL user, but when I attempt to do so with the AD user I get:
The current user does not have sufficient permissions on the instance of SQL Server to delete the data-tier application. The user must be the database owner of the database associated with the data-tier application.
I know that the data-tier application info is stored in the virtual master database. e.g.
select * [master].[dbo].[sysdac_history_internal]
select * [master].[dbo].[sysdac_instances_internal]
It looks like you need to have db_owner on the master database in order to work with DACs in this way, but the only user that can be db_owner is the SQL authenticated SQL Admin.
So unless I can create a contained AD user that can do this, I don't think I can use dacpac registration, which is a real shame as drift detection is a real seller for the use SSDT.
If anyone knows how to manage this, I'd be very grateful to hear it.
Related
I am currently working on a project to help configure an application in GCP, been working mostly in Azure and I am a bit confused with users and rights in Cloud SQL for SQL Server. It seems that SA is not permitted and I can understand that but in their documentation it states:
You can create other SQL Server users or roles. All Users you create using Cloud SQL are granted the same database permissions as the sqlserver login. if you use a different method the user wont have the same permissions as the customer admin accounts.
My questions.
Create with cloud sql means i have to use the console to create those users and not thru TSQL inside say SQL Server Management Studio that connects to SQL Server?
If i create a login will I then be able to add that login as a user to the database?
thank you.
New to SQL Managed Instances. Currently I am testing our on-prem SQL databases in an Azure Managed Instance. There are some logging procedures in our application database which are gathering information to save in an audit trail. Some of these are referencing some of the DMVs such as sys.dm_exec_connections and sys.dm_exec_sql_text.
Accessing these using the MI administrator user works fine. However it is the AD service account which will be accessing the database. This service account does not appear to have access to those.
The service account has been added to the db_owner role within the database but I am not able to set at the server or database level the view server state and view all definitions permissions. I cannot see anything which could be the equivalent in a Managed Instance.
Does anyone know how and where to look in order to resolve this?
I have even tried with an account that is the AD Admin account of the instance.
Many thanks.
Please use sql logins instead of AAD login/users for this scenario.
In the current version of Managed Instance you can either create global AAD Admin that don't have full server admin privileges, or you can create contained AAD users as CREATE USER myusr FROM EXTERNAL_PROVIDER that cannot get server-level permissions because grant permission at server level can be given to server-level logins and not database-level users.
In the future we will have better AAD logins that are much similar to the existing Windows logins, but in the meantime, it might be painful if you try to setup this scenario with the existing AAD login/users.
I'm using the Telegraf input plugin for SQL Server (https://github.com/influxdata/telegraf/tree/master/plugins/inputs/sqlserver) to gather metrics and report to InfluxDB. It works well for SQL Server, but though it supports Azure SQL Database the documentation is a bit sparse.
The database user should be created like this:
CREATE LOGIN [telegraf] WITH PASSWORD = N'password';
GRANT VIEW SERVER STATE TO [telegraf];
GRANT VIEW ANY DEFINITION TO [telegraf];
That works on SQL Server, but in Azure it fails:
Securable class 'server' not supported in this version of SQL Server.
I wonder what I need to grant instead in order to solve this in the best possible way. We have a large number of databases running on the same server in an elastic pool, so if it is possible I would like to use a single user that logs in to the master and collects metrics for all the databases at once (the way it works with SQL Server). If that is impossible I can configure multiple logins and process one database at a time.
Perhaps I can grant VIEW DEFINITION at the database level, but VIEW SERVER STATE does not seem to be supported at all.
So, how should I configure the SQL Database login(s) for Telegraf with the SQL Server plugin to make it work?
EDIT:
Running as the super user for the server works without errors, but only produces metrics for master and tempdb. I need metrics for the many application databases and they are missing. Plus running as the super user is less than ideal.
Running as the super user for the server but connecting to a specific application database (add database in connection string) crashes with a nil pointer dereference and the log complains about VIEW DATABASE STATE permission denied in database master (the super user has access, but apparently not when connecting to a spefic database).
Granting VIEW DATABASE and VIEW DEFINITION to telegraf in an application database and connecting directly to that database as telegraf crashes with a nil pointer dereference and the log says the connection was closed.
EDIT 2:
Created bug report https://github.com/influxdata/telegraf/issues/4222.
EDIT 3:
As of the latest release the plugin works if the server admin account is used, so the issue has been solved. There is still no way to run with a less privileged account in Azure DB.
The answer:
GRANT VIEW SERVER STATE is not supported in Azure SQL Database.
On SQL Database Premium Tiers requires the VIEW DATABASE STATE
permission in the database. Permissions can not be granted in Master,
but the views can be queried in user databases. On SQL Database
Standard and Basic Tiers requires the SQL Database server admin
account due to security requirements following from multi tenancy of
those tiers.
Reason:
SQL Azure SQL is PaaS solution, therefore the most "server" specific features, DMVs, settings are blocked by purpose
References:
Grant View Server State - is it possible for a none SA user to have in Azure SQL?
SQL Azure VIEW DATABASE STATE permission denied in database 'master'
Possible workaround: (which is, anyway does not work in ewramner case)
CREATE LOGIN [telegraf] WITH PASSWORD = N'password';
USE [yourDB]
GRANT VIEW DEFINITION TO [telegraf];
GRANT VIEW DATABASE STATE TO [telegraf];
Therefore, (IMHO), there is no way to make such application working in SQL Azure without changing application code
II am migrating an existing SQL Server 2014 DB to Azure. Always failing so I ran Data Migration Assistant to Assess the DB compactibility and I get this result.
Cannot still figure out how to solved that.
User: [eAgricDBUser] has an unresolved reference to Login [eAgricDBUser].
The error occurs because it's referring to logins that existed in the source SQL Server instance but not in your target Azure SQL DB instance (logical master).
Suggest you think about how your users should access the database now that it is in Azure SQL DB. Contained users are helpful here as they can be moved around to any server and still function. AD users are even better but you'll need to have your on-premises AD integrated with Azure AD. Both save you lots of headaches with login migrations.
Alternatively, you can create the required logins in master before you run the database migration scripts which contain create user statements. Note that you will be creating them with a new password so you will need to provide that to the users plus you'll need some way for the users to change that to their own password.
I have a .NET application which connects to SQL Server 2008 for storing some data. I use SQL Server authenthication providing an sq username and a password to my end-user in app.config file. If something more needs to be changed I give to the end-user some other credentials.
How can I limit the sql user to only have permission to read/write data and executing existing stored procedures and everything else to be forbidden?
What is the best practice for setting permisions for a sql user that an application is using to connect to a database? Can I prevent somehow the user from logging in Management Studio and mess with my data?
I'm not searching for the perfect 100% reliable solution, but the best existing practice to do this. Thank you very much in advance.
Update: I work on a shared hosting SQL Server environment.
You'll need to create a new SQL user, something like 'LimitedUser'. To do this in SSMS, select the Security Folder of the server you are using, right-click, select New, select Login.
Select your authentication type (SQL server authentication is easily managed), and set the Default database to your database.
You'll need to set Server Roles so this new user only maps to your DB, and in the last page (Status), set Login to false so they cannot use these credentials to login to SSMS and 'mess with your data'.
Click OK, and you're done creating your limited user.
Assign it to your database, and then in SSMS, right-click on your db, select Properties, Permissions.
Select your user or role, and in the permission grid below, switch on only what need to be switched on.
As I see, your question is fully concerned with SQL server security.
You can limit user permissions on server, database or object scope, using GRANT statement, server or database roles. For example, you can assign db_datareader role for user, and then grant EXECUTE permission to this user for some stored procedures (or for entire database).
The current practice in my organization is to create the database roles (e.g. application admin, operator, and so on), adding the appropriate permissions to these roles and then assign these roles to database users.
I'm not completelly sure that you can prevent login into SQL Server Managent studio (SSMS), but SSMS wll not display information that must be invisible for user with user current permissions.
Shared SQL Server hosting where a single instance is shared among multiple customers is not compatible with with typical client-server applications. You are expected to perform all operations through a middle tier server such a WCF Data Service and maintain user accounts within your database in a table with Forms Authentication etc.
For your client-server application you need VPS hosting with your own instance of SQL server where you can create server-level logins. Without creating server-level logins there is no method to secure a client-server application. Any workarounds are just pseudo-security.