Azure Active Directory only authentication for Azure SQL
We’re announcing a new feature called Azure Active Directory only authentication for Azure SQL (hereafter referred to as “Azure AD-only auth”). This feature is in public preview and is supported for Azure SQL Database (SQL DB) and Azure SQL Managed Instance (MI). Following the SQL Server on-premises feature that allows the disabling of SQL authentication and enabling only Windows authentication, Azure SQL now allows only Azure AD authentication, and disables SQL authentication in the Azure SQL environment. Feature details When “Azure AD-only auth” is active (enabled), SQL authentication is disabled, including for SQL server admin, as well as SQL logins and users. The feature allows only Azure AD authentication for the Azure SQL server and MI. SQL authentication is disabled at the server level (including all databases) and prevents any authentication (connection to the Azure SQL server and MI) based on any SQL credentials. Although SQL authentication is disabled, the creation of new SQL logins and users are not blocked. However, pre-existing and newly created SQL accounts will not be allowed to connect to the server. In addition, enabling the Azure AD-only auth feature does not remove existing SQL login and user accounts, but it denies these accounts from connecting to Azure SQL server and any database created for this server. Tooling-support We support PowerShell, CLI commands, Rest APIs, ARM templates, as well as the Azure portal for SQL Database to enable or disable the Azure AD-only auth feature. The Azure portal for MI is currently not supported. For more on details on this feature and available interfaces, see AAD-only-authentication. Permissions required to enable/disable Azure AD-only auth To enable or disable the Azure AD-only auth feature special permissions are required available to the high privileged built-in roles such as subscription owner, contributor, or co-administrator. The required permissions can also be customized by creating custom roles. For more information on Azure built-in roles, see https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles. To allow Azure AD users with lower privileges to enable/disable the Azure AD-only auth feature, the existing built-in role SQL Security Manager was modified to allow these operations for SQL DB and MI. The two Azure SQL built-in roles, SQL Server Contributor (used for SQL DB) and SQL Managed Instance Contributor (used for MI), do not have the permission to enable or disable Azure AD-only auth. This role-separation helps in implementing separation of duties, where users who can create an Azure SQL server or create an Azure AD admin, such as SQL Server contributor or SQL Managed Instance Contributor, cannot enable nor disable security features such as Azure AD-only auth. Enabling/disabling the Azure AD-only auth feature using the Azure portal After assigning an Azure AD user a role discussed above, such as SQL Security Manager, the Azure AD-only auth feature can be enabled using the Azure portal by checking the feature box and saving its action (see below). The Azure AD-only auth feature using the Azure portal is currently supported only for SQL DB, and not for MI. Note that the Azure AD admin must be set for this server to check the feature box. Once the feature is enabled, any attempt to login to this server using SQL authentication fails with an error message indicating the cause of the failure (see below). Similarly, the feature box can be unchecked allowing both Azure AD and SQL authentication. In this case, repeating the SQL login using the SSMS example above will succeed. Limitations 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. New update As an extension to this feature we have also released a new functionality that is now part the public preview for the Aure AD-only auth allowing to provision an Azure SQL server with Azure AD-only enabled during a server creation. In addition a server admin and a server password can be set by the system (set password to random) during a server provisioning. For more information see Create server with Azure Active Directory only authentication enabled in Azure SQL - Azure SQL Database | Microsoft Docs.Announcing Azure SQL Database ledger
Bringing tamper-evidence capabilities to your database, the ledger feature for Azure SQL Database provides cryptographic that your data has not been maliciously altered. This article explains Azure SQL Database ledger and how it can help digitize trusting your data.What’s new in Azure SQL Managed Instance at Ignite 2020
Since its inception, Azure SQL Managed Instance (SQL MI) has been continuously improved based on customer feedback, aiming to meet critical requirements of organizations that migrate and modernize their applications in Azure. In that spirit we are excited to announce several important capabilities coming to preview or general availability during Ignite 2020, which will bring significant improvements across multiple product aspects: performance, security and compliance, management experience, programmability surface area and application compatibility.🔐 Public Preview: Backup Immutability for Azure SQL Database LTR Backups
The Ransomware Threat Landscape Ransomware attacks have become one of the most disruptive cybersecurity threats in recent years. These attacks typically follow a destructive pattern: Attackers gain unauthorized access to systems. They encrypt or delete critical data. They demand ransom in exchange for restoring access. Organizations without secure, tamper-proof backups are often left with no choice but to pay the ransom or suffer significant data loss. This is where immutable backups play a critical role in defense. 🛡️ What Is Backup Immutability? Backup immutability ensures that once a backup is created, it cannot be modified or deleted for a specified period. This guarantees: Protection against accidental or malicious deletion. Assurance that backups remain intact and trustworthy. Compliance with regulatory requirements for data retention and integrity. 🚀 Azure SQL Database LTR Backup Immutability (Public Preview) Microsoft has introduced backup immutability for Long-Term Retention (LTR) backups in Azure SQL Database, now available in public preview. This feature allows organizations to apply Write Once, Read Many (WORM) policies to LTR backups stored in Azure Blob Storage. Key Features: Time-based immutability: Locks backups for a defined duration (e.g., 30 days). Legal hold immutability: Retains backups indefinitely until a legal hold is explicitly removed. Tamper-proof storage: Backups cannot be deleted or altered, even by administrators. This ensures that LTR backups remain secure and recoverable, even in the event of a ransomware attack. 📜 Regulatory Requirements for Backup Immutability Many global regulations mandate immutable storage to ensure data integrity and auditability. Here are some key examples: Region Regulation Requirement USA SEC Rule 17a-4(f) Requires broker-dealers to store records in WORM-compliant systems. FINRA Mandates financial records be preserved in a non-rewriteable, non-erasable format. HIPAA Requires healthcare organizations to ensure the integrity and availability of electronic health records. EU GDPR Emphasizes data integrity and the ability to demonstrate compliance through audit trails. Global ISO 27001, PCI-DSS Require secure, tamper-proof data retention for audit and compliance purposes. Azure’s immutable storage capabilities help organizations meet these requirements by ensuring that backup data remains unchanged and verifiable. 🕒 Time-Based vs. Legal Hold Immutability ⏱️ Time-Based Immutability Locks data for a predefined period (e.g., 30 days). Ideal for routine compliance and operational recovery. Automatically expires after the retention period. 📌 Legal Hold Immutability Retains data indefinitely until the hold is explicitly removed. Used in legal investigations, audits, or regulatory inquiries. Overrides time-based policies to ensure data preservation. Both types can be applied to Azure SQL LTR backups, offering flexibility and compliance across different scenarios. 🧩 How Immutability Protects Against Ransomware Immutable backups are a critical component of a layered defense strategy: Tamper-proof: Even if attackers gain access, they cannot delete or encrypt immutable backups. Reliable recovery: Organizations can restore clean data from immutable backups without paying ransom. Compliance-ready: Meets regulatory requirements for data retention and integrity. By enabling immutability for Azure SQL LTR backups, organizations can significantly reduce the risk of data loss and ensure business continuity. ✅ Final Thoughts The public preview of backup immutability for Azure SQL Database LTR backups is a major step forward in ransomware resilience and regulatory compliance. With support for both time-based and legal hold immutability, Azure empowers organizations to: Protect critical data from tampering or deletion. Meet global compliance standards. Recover quickly and confidently from cyberattacks. Immutability is not just a feature—it’s a foundational pillar of modern data protection. Documentation is available at - Backup Immutability for Long-Term Retention Backups - Azure SQL Database | Microsoft Learn
