Case
I want to work with Azure SQL Server, as noted in the best practices how to secure Azure SQL Server it is good to use AAD account for accessing your server/database instead of SQL Accounts.
I read several posts on the documentation site of Microsoft and blogs, but I cannot find that it is possible to disable/remove the Server Admin account, after you have the Azure SQL Server and an created AAD SQL Administrator and attached it to Azure SQL Server.
I know Server Admin Login and Password is mandatory, when you create the Azure SQL, but I hoped it was possible to delete after creation of server and AAD SQL Admin.
Why do I want this?
There are enough companies who have to rule (inherited from the on-prem) that accounts must be controlled by a centralized Identity Store, such as AAD.
Password rotation must be done, it is a lot easier when you have a centralized identity Store instead that you have to do it for a lot of Azure SQL Servers.
Question
Is it possible to disable the SQL Server Admin (sql account)?
I don't believe it is (or can be) possible to disable the SQL Server Admin.
The Azure Subscription Owner and the AAD SQL Admin identity have joint ownership of the Azure SQL Server. Either one needs to be able to re-acquire administrative access to the server.
And the mechanism that the Azure Subscription Owner uses to force their way into their own database is to reset the SQL Server Admin password from the Azure Portal.
This is roughly analogous to how a Windows Administrator can force sysadmin access to a SQL Server by starting the service in single-user mode.
I think the best you can do is to throw away the SQL Server Admin's password, so no one could log in using that account without first resetting the password in the portal. EG run:
declare #sql nvarchar(max) = concat(N'alter LOGIN [youradmin] WITH PASSWORD=N''',newid(), N'''')
exec (#sql)
Update 06/21:
Microsoft released Azure Active Directory only authentication for Azure SQL which effectively disables the possibility to use any SQL user for authentication.
Note the caveats
Azure AD-only auth is supported at the Azure SQL server level
This means that when this mode is enabled, all databases that belong to this server can only be accessed using Azure AD
authentication
Enabling Azure AD-only auth does not remove existing SQL logins or SQL users based on these logins. They continue being stored in SQL
metadata, but cannot be used for SQL authentication
Even though the Azure AD-only auth is enabled, with proper SQL permissions for Azure AD users, SQL logins and SQL users can be
created. However, the authentication process to connect to Azure SQL
using SQL logins/users will fail
Azure AD users with proper permissions can impersonate existing SQL users
Impersonation continues working between SQL authentication users even though the Azure AD-only auth feature is enabled. This is
consistent to the way impersonation works today, where even disabled
users can be impersonated.
Microsoft is working on allowing so called "AAD-only authentication" which will effectively disable the server admin login, as the complete SQL authentiction is disabled.
Related
App Service dev, staging and prod deployment slots and SQL DB all have system assigned managed identities.
Contributor roles have been assigned to managed identities at the subscription level.
SQL Server Contained users have been created and roles assigned for the App Service dev, staging and production slots:
SQL Server Contained Users
appsettings.json connectionStrings:
connectionStrings
AD DB Admin User created and added to SQLServer as a contained user.
Permissions added to AppService managed identity for dB1 and dB2 to SQL Server AppService Managed Identity Permissions
msi-validator returns success for token based connection from the web app to two different databases on the same sql server instance.
msi-validator success
Local and Azure deployment slot both return: SQLException Login failed for token-identified principal
Walked through https://social.technet.microsoft.com/wiki/contents/articles/53928.azure-ad-managed-identity-connecting-azure-web-app-and-slots-with-azure-sql-db-without-credentials.aspx and many other tutorials.
Still missing something...
Attempts to run the application using the managed identity connection string is consistently failing with the token-provider principal login failure error.
Confirmation of settings:
Confirmation of Settings
Please make sure the Azure Active Directory user is created on the Azure SQL Database. Please make you create the user in the Azure SQL Database following the steps mentioned here.
To create an Azure AD-based contained database user, connect to the database with an Azure AD identity, as a user with at least the ALTER ANY USER permission. Then use the following Transact-SQL syntax:
CREATE USER <Azure_AD_principal_name> FROM EXTERNAL PROVIDER;
CREATE USER [bob#contoso.com] FROM EXTERNAL PROVIDER;
CREATE USER [alice#fabrikam.onmicrosoft.com] FROM EXTERNAL PROVIDER;
Make sure you are connect to the Azure SQL database and not to the master database on the Azure SQL logical server.
As per my understanding you are facing an error stating login fails for token-identified principal when trying to connect your Azure ap service managed identity with your Azure SQL Database.
Could you please try the below in order to mitigate the issue.
Make sure System managed Identity status is showing on your app.
on your app service Verify that your connection string under application settings is set to "Server=tcp:.database.windows.net,1433;Database=;"
Allow Azure services and resources to access this server” should be set as Yes in Firewalls and virtual networks settings in your Azure SQL DB, in case it was not set earlier during Azure SQL setup.
Please do let me know if that help mitigate the issue. If not, we will keep working on the same to get you unblock.
I created SQL account for an application but how do I restrict or deny the same account not to connect the database using SSMS or Azure data studio by the developers since the developers can view the user information in web.config file.
Thanks,
Sandeep
You can use Azure Active Directory to authenticate your app, so that you don't need to write the username and password in config file.
With Azure AD authentication, you can centrally manage the identities of database users and other Microsoft services in one central location.
Benefits:
It provides an alternative to SQL Server authentication.
It helps stop the proliferation of user identities across servers.
It allows password rotation in a single place.
You can read more details from this document.
Basically the answer to your question is... You can't...
There is no way to identify the client of a certain connection in Azure SQL. What you can do, for example, is restrict access to a certain server using s firewall. But if your dev env is on the same machine as your SSMS that won't work because you're then blocking the dev env as well.
In that case, the best practice is to create a dev database to which all devs have access. In that case, it doesn't matter for you everyone knows the password because it's the dev database.
For production environments, you need to treat database credentials as secrets and thus make sure they are stored in a safe place. When you're using Azure, the KeyVault may be a good place to store the password. This KeyVault has a fine grained way of allowing access to secrets for individuals as well as IT systems.
We are trying to evaluate possibility of migrating our in-house SQL DB server to Azure SQL as a PaaS.
Our legacy windows application which is written in VB6 and now running on VB.NET Framework 4.5
Clarifications I need if I migrate only DB server to Azure:
We use both trusted / credential based SQL connection from our desktop application to connect to SQL DB. If we migrate to Azure SQL, will it support trusted connection which should authenticate current organizations NT user?
We have lot of cross DB queries, do we need to face any challenge to use the queries as it is?
Run time we take a DB backup / restore for some business cases. Does this work?
Are there any restrictions on number of admin users on Azure DB?
Probably yes if you sync your local AD with an AAD (See: Use Azure Active Directory Authentication for authentication with SQL Database, Managed Instance, or SQL Data Warehouse)
Azure SQL Database (PaaS) doesn't support cross DB queries by default - you have to setup / use Elastic Query for that.
Yes, you can take a DB backup at runtime and also restore it. There is also a point-in-time restore feature available. See: Learn about automatic SQL Database backups.
I think you can only specify one server administrator (at least within the portal) but I doubt you will reach any limit on db users.
Instead of using the single database SQL Server PaaS service you should also consider using Managed Instance (preview)
You will have to extend your active directory to Azure active directory to keep using trusted connections. You will learn how to do it on this documentation and this one.
On Azure SQL Database you have elastic queries that allow you to run cross database queries. Learn how to create elastic queries here.
You can create bacpacs (export your databases) to Azure Storage or to on-premises location very easy.
You can configure one Server Admin or one Azure Active Directory Admin (it can be a group) for your Azure SQL Server. However, at the database level you can add many database users to the dbmanager role. You can have more information about this topic here.
I've inherited a VB.Net Windows forms application that is used across several hundred remote sites. On the remote sites the application connects locally to a local SQL server instance using the currently logged in Windows user at the workstation - this all works fine.
The application however also needs to connect to a remote SQL server - currently this is done using a set of connection strings and sql authentication. The DBA wants to move away from using SQL server authentication and make everything Windows authentication.
Clearly, adding hundreds of users to the remote DB is not an option. Therefore I need to be able to use the currently logged in user if connecting locally to a local SQL server and a different Windows users (which will have permissions to the db server) if I am connecting remotely.
Does anyone have any suggestions of how this can be done or can suggest an approach.
Thanks
Since both servers are on the same domain, create Active Directory Groups for the application, put the users' Windows logins into the groups, and then give the 2, 3 or 10 or whatever app-specific AD groups permissions in the databases. If you're using stored procedures, create a database role for each AD group, grant the DB role execute permissions, and add the AD groups to the DB roles.
We currently use SQL 2008 with Windows Authentication disabled, we only allow SQL Mixed for accessing SQL.
We are wanting to switch our version control software to Team Foundation Server, which requires Windows Authentication.
Which ended up being a bit of a problem, I've talked to our DBA and Windows Authentication is not an option, nor is putting SQL on the server where TFS will reside.
Issue is, from what he is telling me, you are unable to just enable Windows Authentication just for a single user, its either on or off for all users.
Is this correct? What other options are there?
You need to have another talk with the DBA.
There are 2 options for authenticating to SQL Server:
Windows Authentication (only)
Both Windows Authentication and SQL Server Authentication
Yes it is true that if you turn on the latter option also known as Mixed Mode, and it applies to the server (which will now accept Windows Auth) - it does not mean that suddenly all valid Windows users will get access to SQL Server!
The Windows logins still have to be added as SQL users (SQL login != SQL user[principal]) and they can then belong to roles etc, so you would only need to add the users for TFS.
In fact, you cannot possibly disable Windows Auth - so I don't see why the DBA should be complaining about "turning on" Windows Auth.
This is probably what you need to do:
Add a new domain group "sqltfs"
Create a SQL user out of the Windows security Group "domain\sqltfs"
Grant all the access required to the new user (or indirectly through a role)
add all the TFS users into the domain group "sqltfs"
This way you can all continue to use SQL logins where it matter (existing code), while still gaining access via TFS -> SQL Server through the domain group membership
This probably belongs on superuser, but I'll take a stab at it. From my SQL 2008 R2 management console, the DB server can run in either pure Windows Auth mode, or mixed Windows auth + SQL auth. It can't run in SQL auth only.
Since you say you're in mixed mode, I can't see why he can't add another user to the DB that uses a windows domain account, rather than a local SQL server account. Mixed mode allows both.