Merge pull request #34369 from WilliamDAssafMSFT/20250610-freshness

20250610 freshness pass

Author: AnnaMHuff

azure-sql/database/active-directory-interactive-connect-azure-sql-db.md

@@ -1,10 +1,10 @@
 ---
-title: Connect .NET with Microsoft Entra multifactor authentication
+title: "Connect .NET with Microsoft Entra Multifactor Authentication"
 description: "C# Code example, with explanations, for connecting to Azure SQL Database by using SqlAuthenticationMethod.ActiveDirectoryInteractive mode."
 author: VanMSFT
 ms.author: vanto
 ms.reviewer: wiassaf, vanto, mathoma
-ms.date: 09/27/2023
+ms.date: 06/10/2025
 ms.service: azure-sql-database
 ms.subservice: security
 ms.topic: how-to
@@ -16,6 +16,7 @@ ms.custom:
 monikerRange: "=azuresql || =azuresql-db || =fabricsql"
 ---
 # Connect to Azure SQL Database with Microsoft Entra multifactor authentication
+
 [!INCLUDE [appliesto-sqldb-fabricsqldb](../includes/appliesto-sqldb-fabricsqldb.md)]
 
 This article provides a C# program that connects to Azure SQL Database. The program uses interactive mode authentication, which supports [multifactor authentication](/azure/active-directory/authentication/concept-mfa-howitworks) using Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)).
@@ -24,21 +25,21 @@ For more information about multifactor authentication support for SQL tools, see
 
 [!INCLUDE [entra-id](../includes/entra-id.md)]
 
-<a name='multi-factor-authentication-for-azure-sql-database'></a>
+<a id="multi-factor-authentication-for-azure-sql-database"></a>
 
 ## Multifactor authentication for Azure SQL Database
 
 `Active Directory Interactive` authentication supports multifactor authentication using [Microsoft.Data.SqlClient](/sql/connect/ado-net/introduction-microsoft-data-sqlclient-namespace) to connect to Azure SQL data sources. In a client C# program, the enum value directs the system to use the Microsoft Entra interactive mode that supports multifactor authentication to connect to Azure SQL Database. The user who runs the program sees the following dialog boxes:
 
-* A dialog box that displays a Microsoft Entra user name and asks for the user's password.
+- A dialog box that displays a Microsoft Entra user name and asks for the user's password.
 
    If the user's domain is federated with Microsoft Entra ID, the dialog box doesn't appear, because no password is needed.
 
    If the Microsoft Entra policy imposes multifactor authentication on the user, a dialog box to sign in to your account will display.
 
-* The first time a user goes through multifactor authentication, the system displays a dialog box that asks for a mobile phone number to send text messages to. Each message provides the *verification code* that the user must enter in the next dialog box.
+- The first time a user goes through multifactor authentication, the system displays a dialog box that asks for a mobile phone number to send text messages to. Each message provides the *verification code* that the user must enter in the next dialog box.
 
-* A dialog box that asks for a multifactor authentication verification code, which the system has sent to a mobile phone.
+- A dialog box that asks for a multifactor authentication verification code, which the system has sent to a mobile phone.
 
 For information about how to configure Microsoft Entra ID to require multifactor authentication, see [Getting started with Microsoft Entra multifactor authentication in the cloud](/azure/active-directory/authentication/howto-mfa-getstarted).
 
@@ -49,11 +50,11 @@ For screenshots of these dialog boxes, see [Using Microsoft Entra multifactor au
 >
 > You can also search directly with the [optional ?term=&lt;search value&gt; parameter](/dotnet/api/?term=SqlAuthenticationMethod).
 
-## Prerequisite
+## Prerequisites
 
 Before you begin, you should have a [logical SQL server](logical-servers.md) created and available.
 
-<a name='set-an-azure-ad-admin-for-your-server'></a>
+<a id="set-an-azure-ad-admin-for-your-server"></a>
 
 ### Set a Microsoft Entra admin for your server
 
@@ -78,7 +79,7 @@ Before you run the C# example, it's a good idea to check that your setup and con
 
 Run SSMS from the same computer, in the same building, where you plan to run the C# example. For this test, any **Authentication** mode is OK. If there's any indication that the server isn't accepting your IP address, see [server-level and database-level firewall rules](firewall-configure.md) for help.
 
-<a name='verify-azure-active-directory-multi-factor-authentication'></a>
+<a id="verify-azure-active-directory-multi-factor-authentication"></a>
 
 ### Verify Microsoft Entra multifactor authentication
 
@@ -99,7 +100,6 @@ For more information, see [Using Microsoft Entra multifactor authentication](./a
 This is an example of C# source code.
 
 ```csharp
-
 using System;
 using Microsoft.Data.SqlClient;
 
@@ -111,7 +111,6 @@ public class Program
         // Connection string - user ID is not provided and is asked interactively.
         string ConnectionString = @"Server=<your server>.database.windows.net; Authentication=Active Directory Interactive; Database=<your database>";
 
-
         using (SqlConnection conn = new SqlConnection(ConnectionString))
 
         {
@@ -129,21 +128,20 @@ public class Program
 
     }
 }
-
 ```
 
 &nbsp;
 
 This is an example of the C# test output.
 
-```C#
+```console
 ConnectionString2 succeeded.
 select @@version
 Microsoft SQL Azure (RTM) - 12.0.2000.8
    ...
 ```
 
-## Next steps
+## Related content
 
 - [Microsoft Entra server principals](authentication-azure-ad-logins.md)
 - [Microsoft Entra-only authentication with Azure SQL](authentication-azure-ad-only-authentication.md)

azure-sql/database/active-geo-replication-security-configure.md

@@ -1,51 +1,51 @@
 ---
-title: Configure security for disaster recovery
+title: Configure Security for Disaster Recovery
 description: Learn the security considerations for configuring and managing security after a database restore or a failover to a secondary server.
 author: rajeshsetlem
 ms.author: rsetlem
 ms.reviewer: wiassaf, mathoma, vanto
-ms.date: 12/18/2018
+ms.date: 06/10/2025
 ms.service: azure-sql-database
 ms.subservice: high-availability
 ms.topic: how-to
-ms.custom: sqldbrb=1
+ms.custom:
+  - sqldbrb=1
 ---
 # Configure and manage Azure SQL Database security for geo-restore or failover
+
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
-This article describes the authentication requirements to configure and control [active geo-replication](active-geo-replication-overview.md) and [failover groups](failover-group-sql-db.md). It also provides the steps required to set up user access to the secondary database. Finally, it also describes how to enable access to the recovered database after using [geo-restore](recovery-using-backups.md#geo-restore). For more information on recovery options, see [Business Continuity Overview](business-continuity-high-availability-disaster-recover-hadr-overview.md).
+This article describes the authentication requirements to configure and control [active geo-replication](active-geo-replication-overview.md) and [failover groups](failover-group-sql-db.md). It also provides the steps required to set up user access to the secondary database. Finally, it also describes how to enable access to the recovered database after using [geo-restore](recovery-using-backups.md#geo-restore). For more information on recovery options, see [Business continuity in Azure SQL Database](business-continuity-high-availability-disaster-recover-hadr-overview.md).
 
 ## Disaster recovery with contained users
 
 Unlike traditional users, which must be mapped to logins in the `master` database, a contained user is managed completely by the database itself. This has two benefits. In the disaster recovery scenario, the users can continue to connect to the new primary database or the database recovered using geo-restore without any additional configuration, because the database manages the users. There are also potential scalability and performance benefits from this configuration from a login perspective. For more information, see [Contained Database Users - Making Your Database Portable](/sql/relational-databases/security/contained-database-users-making-your-database-portable).
 
-The main trade-off is that managing the disaster recovery process at scale is more challenging. When you have multiple databases that use the same login, maintaining the credentials using contained users in multiple databases may negate the benefits of contained users. For example, the password rotation policy requires that changes be made consistently in multiple databases rather than changing the password for the login once in the `master` database. For this reason, if you have multiple databases that use the same user name and password, using contained users is not recommended.
+The main trade-off is that managing the disaster recovery process at scale is more challenging. When you have multiple databases that use the same login, maintaining the credentials using contained users in multiple databases might negate the benefits of contained users. For example, the password rotation policy requires that changes be made consistently in multiple databases rather than changing the password for the login once in the `master` database. For this reason, if you have multiple databases that use the same user name and password, using contained users is not recommended.
 
 ## How to configure logins and users
 
 If you are using logins and users (rather than contained users), you must take extra steps to ensure that the same logins exist in the `master` database. The following sections outline the steps involved and additional considerations.
 
   >[!NOTE]
-  > It's also possible to use logins created from Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)) to manage your databases. For more information, see [Azure SQL logins and users](./logins-create-manage.md).
+  > It's also possible to use logins created from Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)) to manage your databases. For more information, see [Authorize database access](logins-create-manage.md).
 
 ### Set up user access to a secondary or recovered database
 
 In order for the secondary database to be usable as a read-only secondary database, and to ensure proper access to the new primary database or the database recovered using geo-restore, the `master` database of the target server must have the appropriate security configuration in place before the recovery.
 
-The specific permissions for each step are described later in this topic.
-
-Preparing user access to a geo-replication secondary should be performed as part configuring geo-replication. Preparing user access to the geo-restored databases should be performed at any time when the original server is online (e.g. as part of the DR drill).
+Preparing user access to a geo-replication secondary should be performed as part configuring geo-replication. Preparing user access to the geo-restored databases should be performed at any time when the original server is online (as part of the disaster recovery test).
 
 > [!NOTE]
 > If you fail over or geo-restore to a server that does not have properly configured logins, access to it will be limited to the server admin account.
 
-Setting up logins on the target server involves three steps outlined below:
+Setting up logins on the target server involves three steps:
 
 #### 1. Determine logins with access to the primary database
 
 The first step of the process is to determine which logins must be duplicated on the target server. This is accomplished with a pair of SELECT statements, one in the logical `master` database on the source server and one in the primary database itself.
 
-Only the server admin or a member of the **LoginManager** server role can determine the logins on the source server with the following SELECT statement.
+Only the server admin or a member of the **LoginManager** server role can determine the logins on the source server with the following `SELECT` statement.
 
 ```sql
 SELECT [name], [sid]
@@ -74,7 +74,7 @@ WHERE [type_desc] = 'SQL_USER'
 ```
 
 > [!NOTE]
-> The **INFORMATION_SCHEMA** and **sys** users have *NULL* SIDs, and the **guest** SID is **0x00**. The **dbo** SID may start with *0x01060000000001648000000000048454*, if the database creator was the server admin instead of a member of **DbManager**.
+> The `INFORMATION_SCHEMA` and `sys` users have `NULL` SIDs, and the `guest` SID is `0x00`. The `dbo` SID might start with `0x01060000000001648000000000048454` if the database creator was the server admin instead of a member of **DbManager**.
 
 #### 3. Create the logins on the target server
 
@@ -97,10 +97,10 @@ On the target server, do not create a new login with the server admin SID from t
 >
 > DISABLE doesn't change the password, so you can always enable it if needed.
 
-## Next steps
+## Related content
 
-* For more information on managing database access and logins, see [SQL Database security: Manage database access and login security](logins-create-manage.md).
-* For more information on contained database users, see [Contained Database Users - Making Your Database Portable](/sql/relational-databases/security/contained-database-users-making-your-database-portable).
-* To learn about active geo-replication, see [Active geo-replication](active-geo-replication-overview.md).
-* To learn about failover groups, see [Failover groups](failover-group-sql-db.md).
-* For information about using geo-restore, see [geo-restore](recovery-using-backups.md#geo-restore)
+- [Authorize database access to SQL Database, SQL Managed Instance, and Azure Synapse Analytics](logins-create-manage.md)
+- [Contained Database Users - Making Your Database Portable](/sql/relational-databases/security/contained-database-users-making-your-database-portable)
+- [Active geo-replication](active-geo-replication-overview.md)
+- [Failover groups overview & best practices (Azure SQL Database)](failover-group-sql-db.md)
+- [Geo-restore](recovery-using-backups.md#geo-restore)

azure-sql/database/always-encrypted-enclaves-configure-attestation.md

@@ -1,14 +1,15 @@
 ---
-title: "Configure attestation for Always Encrypted using Azure Attestation"
+title: "Configure Attestation for Always Encrypted Using Azure Attestation"
 description: Configure Azure Attestation for Always Encrypted with secure enclaves in Azure SQL Database.
 author: Pietervanhove
 ms.author: pivanho
 ms.reviewer: vanto, mathoma
-ms.date: 11/14/2023
+ms.date: 06/10/2025
 ms.service: azure-sql-database
 ms.subservice: security
-ms.custom: ignite-2023
 ms.topic: how-to
+ms.custom:
+  - ignite-2023
 keywords:
   - "encrypt data"
   - "sql encryption"
@@ -30,7 +31,7 @@ To use Azure Attestation for attesting Intel SGX enclaves used for [Always Encry
 
 1. Create an [attestation provider](/azure/attestation/basic-concepts#attestation-provider) and configure it with the recommended attestation policy.
 
-2. Determine the attestation URL and share it with application administrators.
+1. Determine the attestation URL and share it with application administrators.
 
 > [!IMPORTANT]
 >With Intel SGX enclaves in Azure SQL Database, attestation is mandatory and it requires Microsoft Azure Attestation.
@@ -71,23 +72,23 @@ authorizationrules
 The policy verifies:
 
 - The enclave inside Azure SQL Database doesn't support debugging.
-  
+
   Enclaves can be loaded with debugging disabled or enabled. Debugging support is designed to allow developers to troubleshoot the code running in an enclave. In a production system, debugging could enable an administrator to examine the content of the enclave, which would reduce the level of protection the enclave provides. The recommended policy disables debugging to ensure that if a malicious admin tries to turn on debugging support by taking over the enclave machine, attestation will fail.
 
 - The product ID of the enclave matches the product ID assigned to Always Encrypted with secure enclaves.
-  
+
   Each enclave has a unique product ID that differentiates the enclave from other enclaves. The product ID assigned to the Always Encrypted enclave is 4639.
 
 - The security version number (SVN) of the library is greater than or equal to 2.
-  
+
   The SVN allows Microsoft to respond to potential security bugs identified in the enclave code. In case a security issue is discovered and fixed, Microsoft will deploy a new version of the enclave with a new (incremented) SVN. The recommended policy is updated to reflect the new SVN. By updating your policy to match the recommended policy, you can ensure that if a malicious administrator tries to load an older and insecure enclave, attestation will fail.
 
 - The library in the enclave has been signed using the Microsoft signing key (the value of the x-ms-sgx-mrsigner claim is the hash of the signing key).
-  
+
   One of the main goals of attestation is to convince clients that the binary running in the enclave is the binary that is supposed to run. Attestation policies provide two mechanisms for this purpose. One is the **mrenclave** claim, which is the hash of the binary that is supposed to run in an enclave. The problem with the **mrenclave** is that the binary hash changes even with trivial changes to the code, which makes it hard to rev the code running in the enclave. Hence, we recommend the use of the **mrsigner**, which is a hash of a key that is used to sign the enclave binary. When Microsoft revs the enclave, the **mrsigner** stays the same as long as the signing key doesn't change. In this way, it becomes feasible to deploy updated binaries without breaking customers' applications.
 
 > [!IMPORTANT]
-> Microsoft may need to rotate the key used to sign the Always Encrypted enclave binary, which is expected to be a rare event. Before a new version of the enclave binary, signed with a new key, is deployed to Azure SQL Database, this article will be updated to provide a new recommended attestation policy and instructions on how you should update the policy in your attestation providers to ensure your applications continue to work uninterrupted.
+> Microsoft might need to rotate the key used to sign the Always Encrypted enclave binary, which is expected to be a rare event. Before a new version of the enclave binary, signed with a new key, is deployed to Azure SQL Database, this article will be updated to provide a new recommended attestation policy and instructions on how you should update the policy in your attestation providers to ensure your applications continue to work uninterrupted.
 
 For instructions for how to create an attestation provider and configure with an attestation policy using:
 
@@ -119,10 +120,11 @@ Get-AzAttestation -Name $attestationProviderName -ResourceGroupName $attestation
 
 For more information, see [Create and manage an attestation provider](/azure/attestation/quickstart-powershell#create-and-manage-an-attestation-provider).
 
-## Next steps
+## Next step
 
-- [Manage keys for Always Encrypted with secure enclaves](/sql/relational-databases/security/encryption/always-encrypted-enclaves-manage-keys)
+> [!div class="nextstepaction"]
+> [Manage keys for Always Encrypted with secure enclaves](/sql/relational-databases/security/encryption/always-encrypted-enclaves-manage-keys)
 
-## See also
+## Related content
 
 - [Getting started using Always Encrypted with secure enclaves](always-encrypted-enclaves-getting-started.md)