You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/connect/ado-net/sql/azure-active-directory-authentication.md
+10-1Lines changed: 10 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Describes how to use supported Microsoft Entra authentication modes
4
4
author: David-Engel
5
5
ms.author: davidengel
6
6
ms.reviewer: davidengel
7
-
ms.date: 09/13/2024
7
+
ms.date: 05/01/2025
8
8
ms.service: sql
9
9
ms.subservice: connectivity
10
10
ms.topic: conceptual
@@ -363,6 +363,12 @@ The following example shows how to set an application client ID through a config
363
363
364
364
Available in version 5.2 onwards, there's a new [AccessTokenCallback](/dotnet/api/microsoft.data.sqlclient.sqlconnection.accesstokencallback) property on [SqlConnection](/dotnet/api/microsoft.data.sqlclient.sqlconnection). Use the `AccessTokenCallback` property to define a custom function that returns an access token given the incoming parameters. Using the callback is better than using the [AccessToken](/dotnet/api/microsoft.data.sqlclient.sqlconnection.accesstoken) property because it allows the access token to be refreshed within a connection pool. When using the `AccessToken` property, the token can't be updated after opening the connection. There's also no associated expiration date provided through the property. Once the token expires, new connection requests fail with a server authentication error and pools using it must be manually cleared.
365
365
366
+
> [!IMPORTANT]
367
+
> An `AccessTokenCallback` must return access tokens of the same security context for the same input parameters. If the security context is different, a pooled connection with the wrong security context may be returned for a connection request.
368
+
369
+
> [!NOTE]
370
+
> `AccessTokenCallback` is part of the key used to identify connection pools. Avoid creating a new function callback for every creation of a SqlConnection since that results in a new pool every time. Reference the same instance of a function for connections you want to be considered for pooling. The connection pool key includes parameters passed to the callback to partition connection pools appropriately.
371
+
366
372
The following code snippet is an example of using the `AccessTokenCallback` property in **Microsoft.Data.SqlClient v5.2 onwards**.
@@ -371,6 +377,9 @@ The following code snippet is an example of using the `AccessTokenCallback` prop
371
377
372
378
Given more flexibility, the client application can also use its own provider for Microsoft Entra authentication instead of using the `ActiveDirectoryAuthenticationProvider` class. The custom authentication provider needs to be a subclass of `SqlAuthenticationProvider` with overridden methods. It then must register the custom provider, overriding one or more of the existing `Active Directory*` authentication methods.
373
379
380
+
> [!IMPORTANT]
381
+
> An authentication provider must return access tokens of the same security context for the same input parameters. If the security context is different, a pooled connection with the wrong security context may be returned for a connection request.
382
+
374
383
The following example shows how to use a new authentication provider for `Active Directory Device Code Flow` authentication.
[!INCLUDE [SQL Server Azure SQL Database Synapse Analytics PDW FabricSQLDB](../../includes/applies-to-version/sql-asdb-asdbmi-asa-pdw-fabricsqldb.md)]
22
-
Use the **Permissions** page or the **Securables** page to view or set the permissions for securables. This page can be opened from many locations. The contents of the page can change slightly, depending on how the page is opened and what it contains. The top grid of the page might be populated when the page opens, or it might be empty. To add items to the upper grid, click **Search**. In the upper grid, select an item, and then set the appropriate permissions on the **Explicit** tab. To view aggregated permissions, use the **Effective** tab.
23
-
24
-
To understand the possible combinations of securables and principals, see the securable-specific syntax links in the topic [GRANT (Transact-SQL)](../../t-sql/statements/grant-transact-sql.md). For more information, see [Securables](../../relational-databases/security/securables.md).
25
-
26
-
## Page Header
27
-
The header of the **Permissions** or **Securables** page varies depending on the securable or principal. It displays information relevant to the item, such as its name.
28
-
29
-
## Upper Grid
30
-
The upper grid contains one or more items for which permissions can be set. This dialog box provides the **Search** button for selecting objects or principals to add to the upper grid. The name of the grid might display **Securables** or one or more types of securables or principals. The columns that are displayed in the upper grid vary depending on the principal or securable.
31
-
32
-
**Name**
33
-
The name of each principal or securable that is added to the grid.
34
-
35
-
**Type**
36
-
Describes the type of each item.
37
-
38
-
## Explicit Tab
39
-
The **Explicit** tab lists the possible permissions for the securable that are selected in the upper grid. To configure the permissions, select or clear the **Grant** (or **Allow**), **With Grant**, and **Deny** check boxes. All options are not available for all explicit permissions.
40
-
41
-
**Permissions**
42
-
The name of the permission.
43
-
44
-
**Grantor**
45
-
The principal that granted the permission.
46
-
47
-
**Grant**
48
-
Select to grant this permission to the login. Clear to revoke this permission.
49
-
50
-
**With Grant**
51
-
Reflects the state of the WITH GRANT option for the listed permission. This box is read-only. To apply this permission, use the [GRANT](../../t-sql/statements/grant-transact-sql.md) statement.
52
-
53
-
**Deny**
54
-
Select to deny this permission to the login. Clear to revoke this permission.
55
-
56
-
**Column Permissions**
57
-
For objects that contain columns (such as tables, views, or table-valued functions), the **Column Permissions** button opens the **Column Permissions** dialog box. In this dialog box, you can set **Grant**, **Allow**, or **Deny** permissions on individual columns of a table or view. This option is not available for all object types or permissions.
58
-
59
-
## Effective Tab
60
-
The permissions that a principal has related to a securable may come from permissions that are set for several different principals. For example, a login might be granted permissions individually and also as a member of a group. The **Effective** tab shows the result of combining explicit permissions and the permissions that are received from group or role memberships. Grant permissions are aggregated. A deny permission overrides all grant permissions.
61
-
62
-
**Permissions**
63
-
The name of the permission.
64
-
65
-
**Column**
66
-
The names of columns that are affected by the permission.
[Security Center for SQL Server Database Engine and Azure SQL Database](../../relational-databases/security/security-center-for-sql-server-database-engine-and-azure-sql-database.md)
71
-
72
-
23
+
24
+
Use the **Permissions** page or the **Securables** page to view or set the permissions for securables. This page can be opened from many locations. The contents of the page can change slightly, depending on how the page is opened and what it contains. The top grid of the page might be populated when the page opens, or it might be empty. To add items to the upper grid, select **Search**. In the upper grid, select an item, and then set the appropriate permissions on the **Explicit** tab. To view aggregated permissions, use the **Effective** tab.
25
+
26
+
To understand the possible combinations of securables and principals, see the securable-specific syntax links in the article [GRANT](../../t-sql/statements/grant-transact-sql.md). For more information, see [Securables](securables.md).
27
+
28
+
## Page Header
29
+
30
+
The header of the **Permissions** or **Securables** page varies depending on the securable or principal. It displays information relevant to the item, such as its name.
31
+
32
+
## Upper Grid
33
+
34
+
The upper grid contains one or more items for which permissions can be set. This dialog box provides the **Search** button for selecting objects or principals to add to the upper grid. The name of the grid might display **Securables** or one or more types of securables or principals. The columns that are displayed in the upper grid vary depending on the principal or securable.
35
+
36
+
**Name**
37
+
The name of each principal or securable that is added to the grid.
38
+
39
+
**Type**
40
+
Describes the type of each item.
41
+
42
+
## Explicit Tab
43
+
44
+
The **Explicit** tab lists the possible permissions for the securable that are selected in the upper grid. To configure the permissions, select or clear the **Grant** (or **Allow**), **With Grant**, and **Deny** check boxes. All options aren't available for all explicit permissions.
45
+
46
+
**Permissions**
47
+
The name of the permission.
48
+
49
+
**Grantor**
50
+
The principal that granted the permission.
51
+
52
+
**Grant**
53
+
Select to grant this permission to the login. Clear to revoke this permission.
54
+
55
+
**With Grant**
56
+
Reflects the state of the WITH GRANT option for the listed permission. This box is read-only. To apply this permission, use the [GRANT](../../t-sql/statements/grant-transact-sql.md) statement.
57
+
58
+
**Deny**
59
+
Select to deny this permission to the login. Clear to revoke this permission.
60
+
61
+
**Column Permissions**
62
+
For objects that contain columns (such as tables, views, or table-valued functions), the **Column Permissions** button opens the **Column Permissions** dialog box. In this dialog box, you can set **Grant**, **Allow**, or **Deny** permissions on individual columns of a table or view. This option isn't available for all object types or permissions.
63
+
64
+
## Effective Tab
65
+
66
+
The permissions that a principal has related to a securable might come from permissions that are set for several different principals. For example, a login might be granted permissions individually and also as a member of a group. The **Effective** tab shows the result of combining explicit permissions and the permissions that are received from group or role memberships. Grant permissions are aggregated. A deny permission overrides all grant permissions.
67
+
68
+
**Permissions**
69
+
The name of the permission.
70
+
71
+
**Column**
72
+
The names of columns that are affected by the permission.
0 commit comments