企业官网建设流程全解析

1. 两种登录方式不是“选哪个”，而是“为什么必须都懂”

刚接手一个老系统迁移项目时，我遇到个典型场景：开发同事本地用 SQL Server Management Studio（SSMS）连数据库一切正常，但部署到测试服务器后，同一套连接字符串死活报错——提示“用户登录失败”。排查两小时，最后发现他写死的连接字符串里用的是 SQL Server 身份认证，而测试环境数据库只启用了 Windows 身份认证。这不是配置错误，是认知断层：很多人把“SQL 登录”和“Windows 登录”当成两个可互换的选项，就像选微信还是QQ登录一样简单。实际上，它们是两套完全独立、底层机制截然不同、权限模型不可混用的身份验证体系。你用哪种方式登录，直接决定了 SQL Server 启动哪一套安全子系统来校验你、授权你、审计你。更关键的是，Windows 身份认证不走密码传输，SQL Server 身份认证必须明文或加密传输密码——这直接关系到网络中间人攻击的风险等级。我见过太多团队在生产环境误配 SQL 登录账号，结果被扫描工具批量爆破出 sa 密码；也见过因域控策略变更导致所有 Windows 认证连接集体失效，却没人知道该去改哪里。所以这篇实操记录不讲“怎么点按钮”，而是从协议栈开始，一层层剥开两种登录背后的握手流程、令牌生成逻辑、权限继承路径，以及——最要命的——那些文档里不会写的、但你上线前必须亲手验证的 7 个临界点。关键词SQL Server 身份认证和Windows 身份认证不是并列名词，它们是两条平行的安全轨道，踩错一条，整个访问链就脱轨。

2. Windows 身份认证：不是“免密”，而是“借权”

2.1 核心原理：Kerberos 与 NTLM 的双轨制

Windows 身份认证的本质，是让 SQL Server 信任 Windows 操作系统已经完成的身份核验结果。它不自己验密码，而是向 Windows 索要一个“已认证”的凭证。这个过程依赖 Windows 域环境下的安全协议，主要有两种实现路径：

• Kerberos（默认首选）：当客户端和 SQL Server 都在同一个 Active Directory 域内，且服务主体名称（SPN）正确注册时，Windows 会自动使用 Kerberos 协议。它的优势在于：密码永不离开客户端机器，全程通过票据（Ticket）交换完成身份确认。SQL Server 收到的是一个由域控（KDC）签发的、加密的 Service Ticket，里面包含客户端身份和会话密钥。整个过程没有密码明文或哈希值在网络上传输。

• NTLM（降级备选）：当 Kerberos 条件不满足（比如跨域、SPN 缺失、DNS 解析失败），系统会自动回退到 NTLM 协议。此时客户端会向 SQL Server 发送一个 NTLM Challenge-Response 流程：SQL Server 发起挑战（Challenge），客户端用本地存储的密码哈希计算响应（Response）并返回。注意：这里传输的是密码哈希的运算结果，而非密码本身，但哈希值一旦被截获，仍可被离线暴力破解。NTLM 是一种“有状态”的协议，每次连接都需要完整握手，性能略低于 Kerberos。

提示：判断当前连接走的是哪种协议，最直接的方法是在 SSMS 中执行SELECT auth_scheme FROM sys.dm_exec_sessions WHERE session_id = @@SPID;。返回KERBEROS或NTLM即可确认。不要依赖“没输密码”就认为是 Kerberos——NTLM 同样免输密码。

2.2 SPN：Kerberos 的“身份证号”，90% 的故障根源

SPN（Service Principal Name）是 Kerberos 正常工作的绝对前提。它相当于给 SQL Server 实例在域控中注册的一个唯一“身份证号”，格式为MSSQLSvc/<FQDN>:<port>或MSSQLSvc/<FQDN>。例如，一台名为sql-prod.contoso.com的服务器，实例监听在默认端口 1433，则其 SPN 应为MSSQLSvc/sql-prod.contoso.com:1433。

为什么 SPN 如此关键？因为 Kerberos 客户端在发起请求前，必须先向域控查询“我要连的这个服务，它的身份证号是多少？”。如果查不到，或者查到多个，Kerberos 就会失败，系统自动降级到 NTLM。而现实中，SPN 错误几乎占了 Windows 认证连接失败案例的 90%。常见错误包括：

• SPN 未注册：全新安装的 SQL Server 实例，默认不会自动注册 SPN，必须由域管理员手动执行setspn -S MSSQLSvc/sql-prod.contoso.com:1433 DOMAIN\sqlservice命令。
• SPN 冲突：同一 SPN 被注册在两个不同的域账户下（比如旧服务器重装后未清理 SPN），Kerberos 无法确定该信任谁。
• SPN 格式错误：使用了短主机名（如sql-prod）而非完全限定域名（FQDN），或端口号遗漏/错误。
• SPN 所属账户错误：SPN 必须注册在运行 SQL Server 服务的 Windows 账户名下，而不是NT AUTHORITY\NETWORK SERVICE这类内置账户（除非明确配置）。

我曾在一个金融客户现场，花三天时间定位一个“间歇性连接失败”问题。最终发现是 DNS 轮询导致客户端有时解析到 A 记录，有时解析到 B 记录，而只有 A 记录对应的服务器注册了正确的 SPN。解决方案不是修 DNS，而是为 B 记录也注册上 SPN，并确保两个 SPN 指向同一个服务账户。

2.3 权限继承：从域用户到数据库角色的三级跳

Windows 身份认证的权限不是凭空而来，它遵循严格的继承链条：

1. 域/本地用户组成员身份：这是起点。你的 Windows 账户属于哪些域组（如DOMAIN\SQL-DBA-Team）或本地组（如BUILTIN\Administrators），决定了你能获得的基础 Windows 级别权限。
2. SQL Server 登录映射：在 SQL Server 中，必须将 Windows 用户或组显式创建为一个“登录名”（Login）。例如，执行CREATE LOGIN [DOMAIN\john.doe] FROM WINDOWS;。这一步建立了 Windows 身份与 SQL Server 实例的关联。注意：创建 Login 本身不赋予任何数据库权限，它只是“准入证”。
3. 数据库用户与角色分配：在具体数据库中，需将该 Login 映射为“用户”（User），并加入数据库角色。例如：

   USE [AdventureWorks]; CREATE USER [john.doe] FOR LOGIN [DOMAIN\john.doe]; ALTER ROLE [db_datareader] ADD MEMBER [john.doe];

   这里db_datareader是固定数据库角色，赋予 SELECT 权限。你也可以创建自定义数据库角色，分配更精细的权限。

关键经验：永远不要直接将域用户添加为 Login，而应使用域组。比如创建DOMAIN\SQL-App-Readers组，将所有应用服务账户加入其中，然后在 SQL Server 中只创建一个CREATE LOGIN [DOMAIN\SQL-App-Readers] FROM WINDOWS;。这样，增减服务账户只需在 AD 中操作，无需触碰数据库，符合最小权限原则和运维规范。

3. SQL Server 身份认证：密码在哪里“活”着？

3.1 密码存储机制：SQL Server 的“保险柜”与“明文陷阱”

SQL Server 身份认证的核心是用户名/密码对，但它如何存储密码，直接决定了系统的安全性边界。

• 密码哈希存储：SQL Server 从 2005 版本起，绝不存储明文密码。它使用 SHA-2（SHA-256）算法对密码进行哈希，并将哈希值连同一个随机盐值（Salt）一起存储在sys.sql_logins视图的password_hash列中。当你输入密码时，SQL Server 会用同样的盐值对输入密码进行哈希，再与存储的哈希值比对。这个过程完全在 SQL Server 内部完成，密码明文从未进入内存或日志。

• “明文密码”的真实含义：所谓“明文传输”，是指在客户端与 SQL Server 建立连接时，密码字符串需要通过网络发送。虽然 SQL Server 本身不存明文，但网络传输中的密码，如果未启用加密（如 SSL/TLS），就可能被嗅探工具捕获。这就是为什么Encrypt=True在连接字符串中不是可选项，而是强制要求。

• 密码策略集成：SQL Server 可以强制执行 Windows 密码策略（如复杂度、过期、历史记录）。启用方式是在创建 Login 时指定CHECK_POLICY = ON：

  CREATE LOGIN [appuser] WITH PASSWORD = 'P@ssw0rd123!', CHECK_POLICY = ON, CHECK_EXPIRATION = ON;

  这意味着appuser的密码必须符合域策略，且过期后无法登录。但要注意：CHECK_POLICY 对 SQL 登录有效，对 Windows 登录无效——后者完全由 Windows 自身策略控制。

3.2 连接字符串的“生死线”：Encrypt 与 TrustServerCertificate

一个看似简单的连接字符串，往往藏着致命陷阱。以最常见的 ADO.NET 连接字符串为例：

Server=sql-prod.contoso.com;Database=AdventureWorks;User ID=appuser;Password=P@ssw0rd123!;Encrypt=True;TrustServerCertificate=False;

• Encrypt=True：这是开启 TLS 加密的开关。它告诉客户端驱动程序：“请与服务器协商一个 SSL/TLS 会话，之后所有通信（包括密码）都必须加密。” 如果设为False，密码将以明文形式在网络上传输，无论服务器是否配置了证书。

• TrustServerCertificate=False：这是证书验证的开关。当为False时，客户端会严格验证 SQL Server 提供的 TLS 证书：

  1. 证书是否由客户端信任的根证书颁发机构（CA）签发；
  2. 证书中的Subject Alternative Name (SAN)是否包含服务器的 FQDN（如sql-prod.contoso.com）；
  3. 证书是否在有效期内，且未被吊销。

  如果任一条件不满足，连接将被拒绝，并抛出著名的错误：[08001] [Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: The certificate chain was issued by an authority that is not trusted.

• TrustServerCertificate=True：这是一个危险的“绕过验证”开关。它告诉客户端：“即使证书不受信任，也接受它。” 这在开发测试环境可以临时使用，但在生产环境等同于关闭了 TLS 的核心安全能力——你获得了加密通道，却无法确认你连接的真的是目标服务器，而非一个中间人伪造的服务器。生产环境严禁设置为 True。

注意：Encrypt=True和TrustServerCertificate=False必须成对出现，才能构成真正安全的连接。单独设置Encrypt=True而不验证证书，风险极高。

3.3 密码生命周期管理：从创建到轮换的实战清单

SQL 登录的密码管理，远不止“设个强密码”那么简单。以下是我在多个大型项目中沉淀下来的、必须落地的 5 项操作：

1. 初始密码强度：创建 Login 时，密码必须满足CHECK_POLICY = ON，且长度至少 12 位，包含大小写字母、数字、特殊字符。避免使用字典词、用户名、日期等可预测模式。

2. 密码轮换自动化：绝不能依赖人工定期修改。应使用 SQL Agent 作业或外部调度工具（如 Windows Task Scheduler 调用 PowerShell），在密码到期前 7 天自动发送邮件提醒，并在到期日当天执行ALTER LOGIN [appuser] WITH PASSWORD = 'NewP@ssw0rd456!'。关键：新密码必须立即同步到所有使用该账号的应用配置中，否则服务中断。

3. 连接池的“缓存”陷阱：.NET 的 SqlConnectionPool 会缓存连接。当你修改了 SQL Login 的密码，已建立的连接池中的连接并不会立即失效，它们会继续使用旧密码工作，直到连接被回收或超时。这意味着密码轮换后，应用可能在数分钟甚至数小时内仍能用旧密码连接成功，造成“轮换未生效”的假象。解决方案：轮换密码后，必须调用SqlConnection.ClearAllPools()强制清空连接池。

4. 审计日志留存：启用 SQL Server 审计功能，专门审计LOGIN_CHANGE_PASSWORD事件。这不仅能追踪谁在何时修改了密码，更重要的是，当发生安全事件时，这是追溯操作源头的关键证据。

5. 服务账户隔离：为每个应用、每个服务、甚至每个微服务组件，分配独立的 SQL Login。禁止多个服务共享同一个sa或db_owner账号。权限按需授予，例如 Web API 只需db_datareader和db_datawriter，后台批处理任务才需要db_ddladmin。这遵循“最小权限”原则，一旦某个服务被攻破，攻击者无法横向移动到其他服务。

4. 实战排障：7 个高频连接失败场景的逐层解剖

4.1 场景一：Windows 认证连接失败，“找不到登录名”

现象：SSMS 使用 Windows 身份认证连接，报错Login failed for user 'DOMAIN\username'.
表象原因：SQL Server 中不存在该 Windows 用户或组的 Login。
深层排查链路：

1. 在 SSMS 中，执行SELECT name, type_desc FROM sys.server_principals WHERE name LIKE 'DOMAIN\%';确认该用户是否已存在。
2. 如果不存在，检查该用户是否属于某个已存在的 Windows 组（如DOMAIN\SQL-Users），并确认该组是否已在 SQL Server 中创建为 Login。
3. 如果组存在但用户仍无法登录，检查该用户在 AD 中是否真的属于该组（AD 用户属性 -> 成员资格），注意嵌套组成员关系可能需要刷新。
4. 终极验证：在 SQL Server 所在服务器上，用该 Windows 账户远程登录，然后打开 SSMS 并尝试连接。如果本地能连，说明问题出在网络或客户端配置；如果本地也不能连，问题一定在 SQL Server 的 Login 配置或权限上。

4.2 场景二：SQL 认证连接失败，“用户登录失败”

现象：连接字符串正确，但报错Login failed for user 'appuser'.
这不是密码错，而是更底层的问题：

1. 首先确认该 Login 是否被禁用：SELECT name, is_disabled FROM sys.sql_logins WHERE name = 'appuser';。如果is_disabled = 1，执行ALTER LOGIN [appuser] ENABLE;。
2. 检查该 Login 是否被锁定：SELECT name, is_policy_checked, is_expiration_checked, password_last_set_time FROM sys.sql_logins WHERE name = 'appuser';。如果is_policy_checked = 1且密码已过期，或账户被锁定（通常因多次输错密码触发），则需重置密码。
3. 最关键的一步：检查该 Login 的默认数据库是否存在且在线。SELECT name, state_desc FROM sys.databases WHERE name = (SELECT default_database_name FROM sys.sql_logins WHERE name = 'appuser');。如果默认数据库OFFLINE或RESTORING，即使密码正确，登录也会失败。解决方案：ALTER LOGIN [appuser] WITH DEFAULT_DATABASE = [master];先切到 master，再手动切换到目标库。

4.3 场景三：SSL 加密连接失败，“证书链不受信任”

现象：连接字符串含Encrypt=True;TrustServerCertificate=False;，报错[08001] ... certificate chain was issued by an authority that is not trusted.
这不是证书问题，而是信任链问题：

1. 在 SQL Server 服务器上，打开certlm.msc（本地计算机证书管理器），找到 SQL Server 的 TLS 证书（通常在“个人”->“证书”下），双击打开，切换到“详细信息”页签，查看“颁发者”字段。确认该颁发者是否是客户端操作系统信任的根 CA（如 DigiCert、GlobalSign、或你的企业内部 CA）。
2. 如果是企业 CA，必须将该 CA 的根证书导出（Base64 编码），并导入到所有客户端机器的“受信任的根证书颁发机构”证书存储区中。这是最常被忽略的一步。
3. 检查证书的Subject Alternative Name (SAN)是否包含 SQL Server 的实际访问地址。例如，如果客户端用sql-prod.contoso.com连接，证书的 SAN 中必须有这一条。如果客户端用 IP 地址连接，证书必须包含该 IP（但强烈不建议用 IP 连接，因证书不支持 IP 的 SAN 是常见限制）。

4.4 场景四：连接超时，“客户端无法建立连接”

现象：连接字符串无误，但报错[08001] ... client unable to establish connection.
这是网络层问题，与认证无关：

1. 在客户端执行telnet sql-prod.contoso.com 1433。如果连接失败，说明网络不通或防火墙拦截。telnet是最原始、最可靠的端口连通性测试工具。
2. 检查 SQL Server 配置管理器：确认SQL Server Network Configuration->Protocols for <InstanceName>中，TCP/IP协议已启用。
3. 检查SQL Server Network Configuration->Protocols for <InstanceName>->TCP/IP属性 ->IP Addresses页签，确认IPAll下的TCP Port设置为1433（或你指定的端口），且TCP Dynamic Ports为空（动态端口会导致客户端无法预知端口）。
4. 检查 Windows 防火墙：在 SQL Server 服务器上，确认入站规则SQL Server (TCP-In)已启用，且端口1433在允许列表中。

4.5 场景五：Kerberos 降级到 NTLM，性能下降

现象：SELECT auth_scheme FROM sys.dm_exec_sessions WHERE session_id = @@SPID;返回NTLM，而非预期的KERBEROS。
诊断步骤：

1. 在客户端执行klist命令（Windows），查看当前缓存的 Kerberos 票据。如果没有MSSQLSvc/...相关的票据，说明 Kerberos 请求根本没发出。
2. 在 SQL Server 服务器上，执行setspn -L DOMAIN\sqlservice，列出该服务账户注册的所有 SPN。确认输出中包含且仅包含一个正确的MSSQLSvc/...条目。
3. 使用Wireshark抓包，在客户端过滤kerberos协议，观察 Kerberos 流量。如果看到KRB_ERROR包，错误码KDC_ERR_S_PRINCIPAL_UNKNOWN (7)表示 SPN 未找到；KDC_ERR_C_PRINCIPAL_UNKNOWN (6)表示客户端主体未知（通常是客户端机器未加入域）。

4.6 场景六：混合模式下，Windows 认证优先级异常

现象：SQL Server 设置为混合模式，但某些客户端总是尝试用 SQL 认证，即使选择了 Windows 身份认证。
根本原因：客户端驱动程序或应用程序框架的默认行为。例如：

• 旧版 ODBC 驱动程序（如 SQL Server Native Client 11.0）在连接字符串中未显式指定Trusted_Connection=yes时，可能默认走 SQL 认证。
• 某些 ORM 框架（如早期版本的 Entity Framework）的连接字符串解析逻辑有缺陷。解决方案：在连接字符串中强制指定Trusted_Connection=yes（对于 Windows 认证）或Trusted_Connection=no（对于 SQL 认证），不要依赖默认值。这是最稳妥的写法。

4.7 场景七：域控策略变更，所有 Windows 认证连接中断

现象：某天上午，所有使用 Windows 身份认证的应用突然全部报错Login failed for user 'DOMAIN\...'，且域管理员确认未做任何变更。
真相往往是：域控的组策略对象（GPO）中，有一条关于“网络安全：LAN Manager 身份验证级别”的设置被修改了。该策略控制 Windows 客户端支持的 NTLM 版本。如果策略被设为“仅 NTLMv2”，而 SQL Server 服务器的操作系统较老（如 Windows Server 2008 R2），它可能只支持 NTLMv1，导致握手失败。
验证与修复：

1. 在 SQL Server 服务器上，打开gpedit.msc，导航至计算机配置 -> Windows 设置 -> 安全设置 -> 本地策略 -> 安全选项，找到Network security: LAN Manager authentication level。
2. 确保其值不低于Send NTLMv2 response only。如果域策略强制为Only send NTLMv2 response，则服务器必须升级到支持 NTLMv2 的 OS 版本，或协调域管理员调整策略。

5. 安全加固：生产环境必须执行的 5 项硬性配置

5.1 禁用 sa 账户：不是“改密码”，而是“锁进保险柜”

sa（System Administrator）账户是 SQL Server 的内置最高权限账户，也是黑客的首要目标。加固的第一步，不是给它设个复杂密码，而是彻底禁用它：

-- 1. 禁用 sa 登录 ALTER LOGIN sa DISABLE; -- 2. （可选）重命名 sa，增加攻击者识别成本 ALTER LOGIN sa WITH NAME = [sql_admin_root]; -- 3. （关键）确认禁用生效 SELECT name, is_disabled FROM sys.sql_logins WHERE name = 'sa';

注意：禁用sa后，所有需要sysadmin权限的操作，必须使用其他已创建的、具有sysadmin角色的 Windows 登录名（如DOMAIN\DBA-Team）。这迫使所有高危操作都必须通过受控的域账户进行，实现了操作留痕和权限分离。

5.2 启用默认跟踪：让每一次登录都留下“指纹”

SQL Server 的默认跟踪（Default Trace）是一个轻量级、开箱即用的审计功能，它会自动记录登录、登出、错误、DDL 变更等关键事件。它不消耗显著资源，却是事后溯源的救命稻草：

-- 查看默认跟踪是否启用 SELECT * FROM sys.configurations WHERE name = 'default trace enabled'; -- 如果为 0，启用它（需重启服务或执行 RECONFIGURE） EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'default trace enabled', 1; RECONFIGURE;

默认跟踪文件位于 SQL Server 的LOG目录下，文件名为log_*.trc。你可以用 SSMS 的“打开跟踪文件”功能，或用 T-SQL 查询：

SELECT e.name AS EventName, t.LoginName, t.HostName, t.ApplicationName, t.StartTime, t.TextData FROM ::fn_trace_gettable( (SELECT path FROM sys.traces WHERE is_default = 1), DEFAULT ) t JOIN sys.trace_events e ON t.EventClass = e.trace_event_id WHERE e.name IN ('Audit Login', 'Audit Logout', 'Error Log') ORDER BY t.StartTime DESC;

5.3 限制远程访问：只放行必要的 IP 段

SQL Server 默认监听所有网络接口（0.0.0.0），这在生产环境中是巨大风险。应将其绑定到特定的、受保护的网络接口上：

1. 打开 SQL Server 配置管理器。
2. 展开SQL Server Network Configuration->Protocols for <InstanceName>。
3. 右键TCP/IP->属性->IP Addresses页签。
4. 在IPAll下方，找到你实际使用的 IP 地址（如IP2），将其TCP Port设为1433，并将TCP Dynamic Ports清空。
5. 将所有其他 IP 地址（如IP1,IP3...）的TCP Port和TCP Dynamic Ports全部清空。
6. 重启 SQL Server 服务。

这样，SQL Server 只会在你指定的那个 IP 地址上监听 1433 端口，其他网卡上的流量将被自然隔离。

5.4 配置防火墙：应用层过滤优于网络层

Windows 防火墙的“高级安全”功能，支持基于应用程序的规则。比起单纯开放 1433 端口，更安全的做法是：

• 创建一条入站规则，仅允许sqlservr.exe进程接收 TCP 1433 端口的连接。
• 创建一条出站规则，仅允许sqlservr.exe进程向外发起连接（用于链接服务器、备份到网络位置等）。

这样，即使攻击者在服务器上植入了恶意软件，也无法利用 1433 端口进行反向连接，因为只有sqlservr.exe有权限使用该端口。

5.5 定期权限审查：用脚本代替人工记忆

权限会随着时间推移而膨胀。必须建立自动化审查机制。以下是一个核心审查脚本，它会找出所有拥有sysadmin或serveradmin角色的 Login，并检查它们是否属于高风险组：

-- 查找所有高权限 Login SELECT sp.name AS LoginName, sp.type_desc AS LoginType, sp.is_disabled AS IsDisabled, CASE WHEN EXISTS ( SELECT 1 FROM sys.server_role_members rm JOIN sys.server_principals rp ON rm.role_principal_id = rp.principal_id WHERE rm.member_principal_id = sp.principal_id AND rp.name IN ('sysadmin', 'serveradmin') ) THEN 'High Risk' ELSE 'Normal' END AS RiskLevel FROM sys.server_principals sp WHERE sp.type IN ('S', 'U', 'G') -- SQL User, Windows User, Windows Group AND sp.name NOT LIKE '##%' -- 排除系统内部账户 ORDER BY RiskLevel DESC, sp.name;

将此脚本加入 SQL Agent 作业，每周自动运行，并将结果邮件发送给 DBA 团队。任何新出现的High Risk账户，都必须在 24 小时内给出业务理由并归档。

6. 架构决策：什么时候该用 Windows 认证，什么时候必须用 SQL 认证？

6.1 Windows 认证的黄金场景：企业内网、域环境、高合规要求

Windows 身份认证的天然优势，在于它与企业现有 IT 基础设施的无缝集成。因此，它最适合以下场景：

• 企业内部应用系统：所有客户端机器都加入公司域，用户使用域账户登录 Windows。此时，Windows 认证提供了真正的单点登录（SSO）体验，用户无需记忆第二套密码，IT 部门可通过 AD 统一管理账户生命周期（入职、转岗、离职）。
• 高合规性行业：如金融、医疗、政府。这些行业通常有严格的审计要求，要求所有操作可追溯到具体的人。Windows 认证结合 AD 审计日志，能提供从用户登录 Windows 到执行 SQL 语句的完整审计链，满足 SOX、HIPAA 等法规要求。
• 需要 Kerberos 委派的场景：例如，一个 Web 应用（IIS）需要代表用户去访问后端 SQL Server。这需要配置 Kerberos 约束委派（Constrained Delegation），而这是 NTLM 无法实现的。只有 Windows 认证 + Kerberos 才能支撑这种“代入式”访问。

我的经验：只要你的应用架构允许（客户端在域内），Windows 认证永远是首选。它省去了密码管理的麻烦，降低了人为错误风险，并提供了更强的审计能力。

6.2 SQL 认证的不可替代场景：互联网应用、异构环境、第三方集成

SQL Server 身份认证并非次优选择，而是在特定约束下唯一可行的方案：

• 面向互联网的 Web 应用：用户的浏览器不在你的域内，无法提供 Windows 凭据。此时，应用服务器（如 IIS）必须使用一个固定的 SQL Login 连接数据库。这个账号的密码由应用配置管理，与用户无关。
• 跨平台或异构环境：应用部署在 Linux 服务器上，或使用 Java/.NET Core 等跨平台框架。这些环境无法原生支持 Windows 身份认证的 Kerberos/NTLM 协议栈，必须使用 SQL 认证。
• 与第三方 SaaS 或遗留系统集成：对方系统只支持提供用户名/密码的连接方式，且无法加入你的域。此时，你只能为其创建一个专用的 SQL Login，并严格限制其权限范围。

关键原则：SQL 认证账号必须是“服务账号”，而非“用户账号”。它代表的是一个应用、一个服务、一个进程，而不是某个人。因此，它的密码应该由应用的配置管理系统（如 Azure Key Vault、HashiCorp Vault）安全托管，而不是硬编码在代码或配置文件中。

6.3 混合模式的实践智慧：不是“两者都开”，而是“分层授权”

很多团队错误地认为，“混合模式”就是同时开启两种认证，然后让所有应用自由选择。这恰恰是最大的安全漏洞。正确的混合模式实践，是分层授权：

• 基础设施层（Infrastructure Layer）：DBA 团队、运维工具（如监控、备份软件）使用 Windows 身份认证，通过域组统一管理。
• 应用服务层（Application Service Layer）：每个应用、每个微服务，使用独立的、权限最小化的 SQL Login。这些账号的密码由密钥管理服务（KMS）动态注入，生命周期由 KMS 管理。
• 数据访问层（Data Access Layer）：在应用代码中，绝不拼接 SQL 字符串，一律使用参数化查询。对用户输入的任何内容，都经过严格的白名单校验和类型转换。

这样，Windows 认证负责“人”的管理，SQL 认证负责“服务”的管理，两者各司其职，互不干扰，共同构成一道纵深防御体系。

我在一个电商客户的项目中，就采用了这种分层模式。他们的核心交易数据库，DBA 使用DOMAIN\DBA-Team组进行管理；订单服务使用app_order_svcSQL Login，只拥有Orders数据库的db_datareader和db_datawriter；报表服务使用app_report_svc，只拥有Reporting数据库的db_datareader。当某次安全扫描发现app_order_svc账号存在弱密码风险时，我们只需轮换该账号密码，并更新 KMS 中的密钥，完全不影响其他服务。这种解耦，正是混合模式的真正价值所在。