使用被包含的数据库用户在数据库级别对 SQL Server 和 SQL 数据库连接进行身份验证。 所谓的独立数据库，是指与其他数据库以及承载它的 SQL Server/SQL 数据库实例（包括 master 数据库）隔离的数据库。 SQL Server 支持包含的数据库用户进行 Windows 和 SQL Server 身份验证。 使用 SQL 数据库时，将包含的数据库用户与数据库级防火墙规则组合在一起。 本主题回顾了与传统登录/用户模型和 Windows 或服务器级防火墙规则相比，使用包含的数据库模型的差异和优势。 特定方案、可管理性或应用程序业务逻辑仍可能需要使用传统的登录/用户模型和服务器级防火墙规则。
注释
随着 Microsoft sql 数据库服务的发展，并朝着更高的保证 SLA 的方向发展，可能需要切换到包含的数据库用户模型和数据库范围的防火墙规则，以获得更高的可用性 SLA 和给定数据库的最大登录率。 Microsoft鼓励你今天考虑此类更改。
传统登录名和用户模型
在传统的连接模型中，Windows 用户或 Windows 组的成员通过提供由 Windows 身份验证的用户或组凭据连接到数据库引擎。 或者连接提供名称和密码，并使用 SQL Server 身份验证进行连接（这是连接到 SQL 数据库时的唯一选项）。 在这两种情况下，master 数据库必须具有与连接凭据匹配的登录名。 在数据库引擎确认 Windows 身份验证凭据或对 SQL Server 身份验证凭据进行身份验证后，连接通常会尝试连接到用户数据库。 若要连接到用户数据库，登录名必须能够映射到用户数据库中的数据库用户（即关联）。 连接字符串还可以指定连接到特定数据库，该数据库在 SQL Server 中是可选的，但在 SQL 数据库中是必需的。
重要的原则是登录名（在 master 数据库中）和用户（在用户数据库中）必须同时存在并且相互关联。 这意味着与用户数据库的连接依赖于 master 数据库中的登录名，这限制了将数据库移动到其他托管 SQL Server 或 Azure SQL 数据库服务器的能力。 如果出于任何原因，与主数据库的连接不可用（例如，正在进行故障转移），则总连接时间将增加，或者可能会导致连接超时。因此，这可能会降低连接的扩展性。
包含的数据库用户模型
在封闭的数据库用户模型中，主数据库中没有登录信息。 相反，身份验证过程发生在用户数据库中，并且用户数据库中的数据库用户在 master 数据库中没有关联的登录名。 包含的数据库用户模型支持 Windows 身份验证（在 SQL Server 中）和 SQL Server 身份验证（在 SQL Server 和 SQL 数据库中）。 若要作为包含的数据库用户进行连接，连接字符串必须始终包含用户数据库的参数，以便数据库引擎知道哪个数据库负责管理身份验证过程。 包含的数据库用户的活动仅限于身份验证数据库，因此当作为包含的数据库用户进行连接时，必须在用户需要的每个数据库中独立创建数据库用户帐户。 若要更改数据库，SQL 数据库用户必须创建新的连接。 如果同一个用户存在于另一个数据库中，SQL Server 中的包含的数据库用户可以更改数据库。
对于 SQL 数据库，从传统模型切换到包含的数据库用户模型时，不需要对连接字符串进行更改。 对于 SQL Server 连接，必须将数据库的名称添加到连接字符串（如果尚不存在）。
重要
使用传统模型时，服务器级角色和服务器级别权限可以限制对所有数据库的访问。 使用包含的数据库模型时，具有 ALTER ANY USER 权限的数据库所有者和数据库用户可以授予对数据库的访问权限。 这可减少对高特权服务器登录名的访问控制，并扩展访问控制以包括高特权数据库用户。
防火墙
SQL Server
Windows 防火墙规则适用于所有连接，对登录名（传统模型连接）和独立数据库用户具有相同的影响。 有关 Windows 防火墙的详细信息，请参阅 为数据库引擎访问配置 Windows 防火墙。
SQL 数据库防火墙
SQL 数据库允许针对服务器级别连接（登录名）和数据库级连接（包含的数据库用户）使用单独的防火墙规则。 连接到用户数据库时，会检查第一个数据库防火墙规则。 如果没有允许访问数据库的规则，则会检查服务器级防火墙规则，这需要访问逻辑服务器主数据库。 数据库级防火墙规则与包含的数据库用户相结合，在连接期间无需访问服务器的 master 数据库，从而提高连接可伸缩性。
有关 SQL 数据库防火墙规则的详细信息，请参阅以下主题：
语法差异
| 传统模型 | 包含的数据库用户模型 |
|---|---|
连接到 master 数据库时：CREATE LOGIN login_name WITH PASSWORD = 'strong_password';然后，连接到用户数据库时： CREATE USER 'user_name' FOR LOGIN 'login_name'; |
连接到用户数据库时：CREATE USER user_name WITH PASSWORD = 'strong_password'; |
| 传统模型 | 包含的数据库用户模型 |
|---|---|
若要更改密码，于主数据库环境中：ALTER LOGIN login_name WITH PASSWORD = 'strong_password'; |
若要在用户数据库上下文中更改密码：ALTER USER user_name WITH PASSWORD = 'strong_password'; |
注解
在 SQL Server 中，必须为 SQL Server 实例启用包含的数据库用户。 有关详细信息，请参阅 包含的数据库身份验证服务器配置选项。
应用程序中可以共存具有非重叠名称的数据库用户和登录名。
如果 master 数据库中存在名为 name1 的登录名，并且你创建了一个名为 name1 的包含数据库用户，那么在连接字符串中提供数据库名称时，连接到数据库时将优先选用数据库用户的上下文，而不是登录名上下文。 换句话说，数据库中包含的用户将优先于具有相同名称的登录名。
在 SQL 数据库中，包含的数据库用户的名称不能与服务器管理员帐户的名称相同。
SQL 数据库服务器管理员帐户永远不能是独立数据库用户。 服务器管理员有足够的权限来创建和管理包含的数据库用户。 服务器管理员可以授予包含在用户数据库中的数据库用户权限。
由于包含的数据库用户是数据库级主体，因此需要在将使用它们的每个数据库中创建包含的数据库用户。 该标识仅限于数据库，并且与同一服务器中另一个数据库中具有相同名称和相同密码的用户的所有方面都是独立的。
使用通常用于登录名的相同强度密码。