如何停止在链接服务器中使用 sql server 登录凭据？
Mar*_*lli 5 sql-server linked-server logins kerberos connectivity
我有一个位于意大利的链接服务器，server_italia它连接到位于美国俄勒冈州的服务器ORDB1
我们在不同但受信任的域上。
从连接server_italia到ORDB1通过链接服务器使用具有登录和所要求的权限的SQL Server的帐户进行ORDB1。
我是一个sysadmin甚至domain admin在我的域中，而我的server_italia但我只sysadmin在 .sql server 中ORDB1。
有一个类似的问题：
但它没有提供the答案。
这是我的链接服务器：
当我运行以下查询时，server_italia我得到以下结果：
SELECT [the_server]=@@servername,
auth_scheme
FROM sys.dm_exec_connections WHERE session_id = @@spid ;
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
在俄勒冈州，我得到了这个：
如果我的美国同事得到：
在他们的服务器上设置 Kerberos 身份验证
配置约束委派，因为这将允许传递凭据，否则您可能仍会遇到双跳问题。– 在John Eisbrener的评论中添加
我可以在linked server没有 的情况下使用我的sql server account login impersonation吗？
我不知道你是否解决了这个问题，但在最近经历了我们自己（重新）发现让委托运行的要求之后，我想我至少可以提供一个答案，以防其他人看到你的帖子类似的问题。
为了让我的帖子更清晰（尤其是对于遇到它但没有通读您的问题的任何人），委托是中介服务代表客户将客户凭据移交给辅助服务的能力。形象地表示，如下：
在这种情况下，服务器 A是将客户端凭据移交给辅助服务服务器 B的中间服务。在您的情况下，server_italia将被视为中间服务器并且ORDB1将是辅助服务。
活动目录 (AD) 功能级别
首先，您的领域功能级别在很大程度上决定了您可用的选项。如果您的功能级别是 Windows 2012 之前的任何版本，域之间的委派仅限于无约束委派。2012 年之前，约束委派仅限于单域内，不具备跨域功能。
如果您运行的是 2012 功能级别或更高版本，则有其他选项，因此这取决于您对管理、访问控制等的偏好。2012 功能级别确实开放了通过无约束委派跨域委派凭据的能力、传统约束委派或基于资源的约束委派。我的其余答案将假设您使用的是 2012+ 功能级别，但如果不是，则无论功能级别如何，无约束委派配置说明都是相同的。
共同要求
无论您选择哪种委托类型（所有选项都将在下面列出），所有配置都需要为您将用于运行“中间”服务的帐户进行以下基本设置（例如上图中的服务器 A，但这可以适用于任何中间服务，例如数据库、托管在 IIS 上的网站、SSIS、.NET 应用程序等）。在域上，运行将凭据委派给其他服务的服务的帐户将需要设置以下 AD 属性：
- ServicePrincipalNames：这需要列出将委派凭据的服务器 A 的任何 SPN。在您的示例中，这些内容如下所示（假设您
EURO位于CONTOSO森林域中）：MSSQLSvc/server_italia.euro.contoso.com、MSSQLSvc/server_italia.euro.contoso.com:1433 - KerberosEncryptionType：应启用 AES256（如果您选择使用该加密类型，则为 AES128）。这在稍后很重要，但此设置将确保可以委托 Kerberos 加密令牌。
注意：可以通过多种方法查看和设置上述属性。该活动Direcotory用户和计算机MMC管理单元是最常见的图形用户界面，你可以用它来调整这些属性，但这种接口混淆了很多这些属性，并且是总垃圾，当涉及到管理组托管服务帐户。因此，我建议您使用ActiveDirectory PowerShell模块，因为它允许您通过Set-ADUser或Set-ADServiceAccount命令显式设置这些属性。此外，您可以通过Get-ADUser或Get-ADServiceAccount命令查看用户/服务帐户的属性。
此外，所有 SQL Server 都应该有一个注册的 SPN。您可以手动创建这些，但如果您将运行 SQL Server 的服务帐户嵌套到适当的 OU 中，则自注册的 SPN 将自动发生。可以在此处找到有关该过程的说明。
委托类型
同样，假设您使用的是 2012 年或更高版本的 AD 功能级别，您有 3 个选项来执行跨域委派。我将在最容易配置/最不安全到最令人沮丧的配置/最安全方法中列出它们。这些中的任何一个都可以使用，您希望处理多少管理/安全风险将完全取决于您。
这里的另一个花絮是，没有什么可以阻止您将帐户配置为使用下面列出的多种或所有类型的委派。这些配置并不相互排斥。不过，您应该尽量避免在多个委托方案下设置任何帐户，因为它可能会首先使用最不安全的配置（有关确定帐户设置方式的部分如下）。
不受约束的委派
无约束委派是最容易设置但限制最少的方法。此配置允许运行服务器 A 的服务帐户将任何凭据委托给任何辅助服务。这在上图中直观地表示出来，蓝色箭头表示对入站客户端连接或凭据可以委派给的辅助服务没有限制。要在中间账户上配置这种类型的委托，您只需要设置以下 AD 属性（除了上面列出的那些）：
- TrustedForDelegation – 设置为
True
这曾经是它的全部内容，但是对于2019 年 7 月的 Windows 安全补丁，您还需要重新启用跨信任的委派，如该链接中所述。该安全补丁的真正目的是解决此设置的严重缺点，在这篇文章中有更好的解释：在 Active Directory 中寻找：无约束委派和森林信任。同样，除非您使用的是 2012 年之前的 AD 功能级别，否则不建议您使用此类委派。
传统的受限授权
传统的约束委派限制了服务器 A 可以将权限委派给的服务，这样运行服务器 A 的服务帐户只能将凭据委派给明确列出的服务。例如，它仍然可以委托任何人的凭据，但它只能将所述凭据传递给明确列出的服务。所以从视觉上讲，我们限制了我们可以委托的“目的地”，如黄色箭头所示：
您必须在中间帐户上配置的 AD 属性（除了上面“通用要求”部分中列出的那些之外）如下：
- msDS-AllowedToDelegateTo - 这需要是允许此帐户将凭据委派给的所有适用 SPN 的列表。在此示例中，它们将如下所示：MSSQLSvc/ORDB1.usa.contoso.com、MSSQLSvc/ORDB1.usa.contoso.com:1433（假设
ORDB1服务器位于林USA域中CONTOSO）。
使用此配置，您只能将委派限制为 ADKERBEROS令牌。 如果您希望委托非KERBEROS 凭证，例如通过NTLM等传递的凭证，您还可以ANY通过设置以下属性将此帐户配置为委托协议：
- TrustedToAuthForDelegation – 设置为
True
但是，使用ANY协议配置本质上是有风险的。 这篇博客文章深入探讨了这些属性及其后果，除非需要将其设置为 true，否则建议您不要这样做。
从个人的角度来看，我们经常使用传统的约束委托，因为它易于设置且相对安全（除非您决定使用委托进行ANY协议，否则在我看来，您正在为自己设置问题）。
基于资源的受限授权
基于资源的约束委派限制了辅助服务允许从 委派凭据的中间服务。这与其他配置略有不同，因为我们将通过列出服务器 B 信任委派凭据的服务来配置服务器 A，而不是像之前的配置那样配置服务器 A。无需对运行服务器 A 的中间帐户进行任何其他更改即可完成此操作。因此，在这种情况下，当服务器 A 尝试传递 Bob 的凭据时，服务器 B 将识别服务器 A 是可以委派权限的“受信任”服务并且身份验证将毫无问题地进行。在视觉上表示，它将如下所示：
这里要绝对清楚，中间帐户（例如服务器 A）仍然需要配置上面常见要求部分中的属性。此外，目标服务（即服务器 A）需要设置额外的 AD 属性：
- PrincipalsAllowedToDelegateToAccount - 这需要列出所有可信任的服务的适用 SPN，以从中委派凭据。在此示例中，它们将如下所示：MSSQLSvc/server_italia.euro.contoso.com、MSSQLSvc/server_italia.euro.contoso.com:1433
就是这样……概念上。对此进行测试以确定，但从我发现的概述此方法的文章中，这确实是所需要的。事实上，这篇MS 文章贯穿了整个过程，并列出了设置此过程所需的适用 PowerShell 命令，以便可以运行示例 PowerShell 程序来确认双跳，并且基于资源的约束委派将适用于您。此外，这个委托配置应该可以跨域工作而不会出现问题（或信任的要求，据我所知）。这里的缺点是我们必须配置所有“端点”，从长远来看，这可能需要更多的管理工作，具体取决于您的设置方式。
我如何知道我配置了哪些委派设置？
在我看来，确定一个帐户在什么委托配置下运行就像泥一样清楚。幸运的是， Willem Kasdorp 发布了一篇文章以及一个PowerShell 脚本，向您展示您的帐户当前配置的内容。如果您从安装了ActiveDirectory PowerShell模块的计算机上运行它，您应该很高兴。希望我上面提到的委托配置类型和此脚本生成的矩阵的组合将使您清楚地了解您当前已配置的内容。
最后，如果您需要有关 AD PowerShell 命令的一些帮助，本文在设置我谈到的与 SPN 列表等相关的一些属性时显示了正确的语法，这已经足够了。
如果您有任何问题，请发表评论，我会尽力及时回答。