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
description: Become familiar with server security settings in SQL Server. Learn about options that control server authentication, proxy accounts, and other features.
4
4
author: rwestMSFT
5
5
ms.author: randolphwest
6
-
ms.date: 08/26/2025
6
+
ms.date: 02/23/2026
7
7
ms.service: sql
8
8
ms.subservice: configuration
9
9
ms.topic: concept-article
@@ -29,9 +29,59 @@ Uses Windows Authentication to validate attempted connections. If the `sa` passw
29
29
30
30
Uses mixed mode authentication to verify attempted connections, for backward compatibility with earlier versions of [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)]. If the `sa` password is blank when the security mode is being changed, the user is prompted to enter an `sa` password.
31
31
32
-
> [!NOTE]
32
+
> [!NOTE]
33
33
> Changing the security configuration requires a restart of the service. When changing the Server Authentication to SQL Server and Windows Authentication mode the SA account isn't automatically enabled. To use the SA account, execute [ALTER LOGIN](../../t-sql/statements/alter-login-transact-sql.md) with the `ENABLE` option.
34
34
35
+
## Authentication modes explained
36
+
37
+
Choosing the right authentication mode affects the security, manageability, and application compatibility of your [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] instance.
38
+
39
+
### Windows Authentication
40
+
41
+
Windows Authentication uses the security credentials of the Windows operating system to validate user connections. [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] doesn't store or manage passwords directly — it relies on the Windows domain controller (Active Directory or local accounts) for credential validation.
42
+
43
+
Key characteristics:
44
+
45
+
- Uses Kerberos or NTLM protocols for credential validation.
46
+
- Supports centralized password policies including complexity requirements, expiration, and account lockout through Active Directory Group Policy.
47
+
- Enables single sign-on (SSO) — users don't need to enter separate SQL Server credentials.
48
+
- Provides built-in auditing through the Windows Security Event Log.
49
+
- Supports Windows group-based access, which simplifies permission management for large numbers of users.
50
+
51
+
### SQL Server Authentication
52
+
53
+
SQL Server Authentication uses login accounts stored in the `master` database. Each login has its own username and password that [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] manages independently from Windows credentials.
54
+
55
+
Key characteristics:
56
+
57
+
- Credentials are stored directly in [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)], separate from the Windows domain.
58
+
- Requires users to provide a username and password in every connection string.
59
+
- Doesn't support Kerberos delegation or centralized domain password policies by default.
60
+
- Useful when clients aren't part of a Windows domain, such as internet-facing applications or cross-platform environments.
61
+
62
+
### Comparison of authentication modes
63
+
64
+
| Feature | Windows Authentication | SQL Server and Windows Authentication (mixed mode) |
65
+
|---|---|---|
66
+
|**Protocol**| Kerberos or NTLM | Kerberos, NTLM, or SQL password |
67
+
|**Password management**| Managed by Active Directory | SQL logins managed by SQL Server; Windows logins managed by Active Directory |
68
+
|**Single sign-on**| Yes | Only for Windows logins |
69
+
|**Centralized password policy**| Yes (Active Directory Group Policy) | SQL Server enforces its own password policy for SQL logins |
70
+
|**Supports non-domain clients**| No | Yes |
71
+
|**Best suited for**| Enterprise and intranet environments | Internet-facing applications, cross-platform environments, or mixed scenarios |
72
+
73
+
### Choose the right authentication mode
74
+
75
+
Use the following guidelines when you select an authentication mode:
76
+
77
+
-**Use Windows Authentication mode** when all clients are domain-joined Windows machines, you want centralized credential management through Active Directory, and you don't need to support non-Windows clients.
78
+
-**Use SQL Server and Windows Authentication mode** when you need to support applications that can't use Windows Authentication, clients that run on non-Windows operating systems, or legacy applications that require SQL Server logins.
79
+
80
+
> [!IMPORTANT]
81
+
> Even when you use mixed mode, prefer Windows Authentication logins for administrative accounts and internal applications. Reserve SQL Server Authentication for scenarios where Windows Authentication isn't possible.
82
+
83
+
For more information, see [Choose an authentication mode](../../relational-databases/security/choose-an-authentication-mode.md).
84
+
35
85
## Login auditing
36
86
37
87
#### None
@@ -82,4 +132,6 @@ Select to allow the database to be the source or target of a cross-database owne
82
132
83
133
## Related content
84
134
135
+
-[Choose an authentication mode](../../relational-databases/security/choose-an-authentication-mode.md)
description: Orphaned users occur when a database user login no longer exists in the `master` database. This article discusses how to identify and resolve orphaned users.
[!INCLUDE [SQL Server Azure SQL Database Synapse Analytics PDW](../../includes/applies-to-version/sql-asdb-asdbmi-asa-pdw.md)]
23
23
24
-
Users are orphaned in [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] when a database user is based on a login in the `master` database but the login no longer exists in `master`. This can occur when the login is deleted or when the database is moved to another server on which the login doesn't exist. This article describes how to find orphaned users and remap them to logins.
24
+
Users are orphaned in [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] when a database user is based on a login in the `master` database but the login no longer exists in `master`. This can occur when the login is deleted or when the database is moved to another server on which the login doesn't exist. This article describes how to find orphaned users and remap them to logins.
25
25
26
-
> [!NOTE]
26
+
> [!NOTE]
27
27
> Reduce the possibility of orphaned users by using contained database users for databases that might be moved. For more information, see [Make your database portable by using contained databases](../../relational-databases/security/contained-database-users-making-your-database-portable.md).
28
28
29
+
> [!IMPORTANT]
30
+
> The `sp_change_users_login` stored procedure was previously used to fix orphaned users but is now deprecated. Use `ALTER USER ... WITH LOGIN` instead, as described in the [Resolve an orphaned user](#resolve-an-orphaned-user) section. For more information, see [sp_change_users_login (Transact-SQL)](../../relational-databases/system-stored-procedures/sp-change-users-login-transact-sql.md).
31
+
29
32
## Background
30
33
31
34
For connections to a database on an instance of [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] that use a security principal (database user identity) based on a login, the principal must have a valid login in the `master` database. This login is used in the authentication process that verifies the principal's identity and determines whether the principal is allowed to connect to the instance of [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)]. The [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] logins on a server instance are visible in the [sys.server_principals](../../relational-databases/system-catalog-views/sys-server-principals-transact-sql.md) catalog view and the [sys.sql_logins](../../relational-databases/system-catalog-views/sys-sql-logins-transact-sql.md) compatibility view.
32
35
33
-
[!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] logins access individual databases as a "database user" that's mapped to the [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] login. There are three exceptions to this rule:
36
+
[!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] logins access individual databases as a "database user" that's mapped to the [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] login. There are three exceptions to this rule:
34
37
35
38
- Contained database users
36
39
@@ -46,7 +49,7 @@ Users are orphaned in [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)]
46
49
47
50
Information about the mapping of a [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] login to a database user is stored in the database. It includes the name of the database user and the security identifier (`SID`) of the corresponding [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] login. The permissions of this database user are applied for authorization in the database.
48
51
49
-
A database user (based on a login) for which the corresponding [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] login is undefined or is incorrectly defined on a server instance can't sign in to the instance. Such a user is said to be an *orphaned user* of the database on that server instance. Orphaning can happen if the database user is mapped to a login `SID` that's not present in the `master` database. A database user can become orphaned after a database is restored or attached to a different instance of [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] where the login was never created. A database user can also become orphaned if the corresponding [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] login is dropped. Even if the login is re-created, it will have a different `SID`, so the database user will still be orphaned.
52
+
A database user (based on a login) for which the corresponding [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] login is undefined or is incorrectly defined on a server instance can't sign in to the instance. Such a user is an *orphaned user* of the database on that server instance. Orphaning can happen if the database user is mapped to a login `SID` that's not present in the `master` database. A database user can become orphaned after a database is restored or attached to a different instance of [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] where the login was never created. A database user can also become orphaned if the corresponding [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] login is dropped. Even if the login is re-created, it has a different `SID`, so the database user is still orphaned.
50
53
51
54
## Detect orphaned users
52
55
@@ -67,7 +70,7 @@ WHERE sp.sid IS NULL
67
70
68
71
**For Azure SQL Database and Azure Synapse Analytics**
69
72
70
-
The [sys.server_principals](../../relational-databases/system-catalog-views/sys-server-principals-transact-sql.md) table isn't available in SQL Database or Azure Synapse Analytics. Identify orphaned users in those environments by completing these steps:
73
+
The [sys.server_principals](../../relational-databases/system-catalog-views/sys-server-principals-transact-sql.md) table isn't available in SQL Database or Azure Synapse Analytics. To identify orphaned users in those environments, complete these steps:
71
74
72
75
1. Connect to the `master` database and select the SIDs for the logins by using the following query:
73
76
@@ -111,20 +114,30 @@ ALTER USER <user_name> WITH Login = <login_name>;
111
114
ALTER LOGIN <login_name> WITH PASSWORD = '<enterStrongPasswordHere>';
112
115
```
113
116
114
-
> [!IMPORTANT]
117
+
> [!IMPORTANT]
115
118
> Any login can change its own password. Only logins with the `ALTER ANY LOGIN` permission can change the password of another user's login. However, only members of the **sysadmin** role can modify passwords of **sysadmin** role members.
116
119
120
+
## Deprecated methods
121
+
122
+
In earlier versions of [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)], the `sp_change_users_login` stored procedure was used to resolve orphaned users. This procedure is deprecated and might be removed in a future version. Use `ALTER USER` instead.
123
+
124
+
The following table shows the equivalent modern syntax for common `sp_change_users_login` operations:
125
+
126
+
| Deprecated syntax | Recommended replacement |
127
+
|---|---|
128
+
| `EXEC sp_change_users_login 'Report'` | `SELECT dp.name FROM sys.database_principals dp LEFT JOIN sys.server_principals sp ON dp.sid = sp.sid WHERE sp.sid IS NULL AND dp.authentication_type_desc = 'INSTANCE'` |
129
+
| `EXEC sp_change_users_login 'Auto_Fix', '<user>'` | `ALTER USER <user> WITH LOGIN = <user>` |
130
+
| `EXEC sp_change_users_login 'Update_One', '<user>', '<login>'` | `ALTER USER <user> WITH LOGIN = <login>` |
131
+
132
+
For more information, see [sp_change_users_login (Transact-SQL)](../../relational-databases/system-stored-procedures/sp-change-users-login-transact-sql.md).
- [Make your database portable by using contained databases](../../relational-databases/security/contained-database-users-making-your-database-portable.md)
0 commit comments