web-dev-qa-db-ja.com

リンクサーバーでのSQLサーバーログイン資格情報の使用を停止する方法

イタリアに拠点を置くリンクサーバーserver_italiaがあり、米国のオレゴンに拠点を置くサーバーに接続していますORDB1

私たちは別ですが 信頼できるドメイン です。

server_italiaからORDB1への接続は、ORDB1へのログインと必要な権限を持つSQLサーバーアカウントを使用して、リンクサーバーを介して行われます。

私は私のドメインのsysadminでさえdomain adminであり、私のserver_italiaですが、ORDB1のsqlサーバー内ではsysadminしかありません。

同様の質問があります：

Windows認証を使用してリンクサーバーを機能させるにはどうすればよいですか？

ただし、theの回答は提供されません。

これが私のリンクサーバーです：

enter image description here

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;

enter image description here

オレゴンで私はこれを手に入れます：

enter image description here

私のアメリカ人の同僚が得る場合：

  1. サービスアカウントによって実行されているサービスに登録されているサービスプリンシパル名

  2. Kerberos認証をセットアップする サーバー上

  3. 資格情報を渡すことができるように 制約付き委任 を構成します。そうしないと、 double-hop の問題が発生する可能性があります。 – John Eisbrener によってコメントに追加されました

linked serverなしでsql server account login impersonationを使用できますか？

sql-serverlinked-serverconnectivityloginskerberos
5
Marcello Miorelli

これが解決されたかどうかはわかりませんが、最近、委任を実行するための要件を独自に（再）発見した後、他の人があなたの投稿に遭遇した場合に、少なくとも回答を提供できると考えました同様の質問。

私の投稿を明確にするために（特に、投稿を読んでいて質問を読んでいない人に）、委任とは、仲介サービスがクライアントの資格情報をクライアントに代わってセカンダリサービスに引き渡す機能です。次のように視覚的に表現します。

enter image description here

この場合、サーバーAはクライアント資格情報をセカンダリサービスに渡す中間サービスサーバーBです。あなたの場合、server_italiaは中間サーバーと見なされ、ORDB1はセカンダリサービスになります。

Active Directory（AD）機能レベル

何よりもまず、 ドメインの機能レベル は、利用可能なオプションを大きく決定します。機能レベルがWindows 2012より前のいずれかのバージョンである場合、ドメイン間の委任は制約のない委任のみに制限されます。 2012年より前は、 制約付き委任は単一ドメイン内のみに限定されており、 クロスドメイン機能はありませんでした。

2012機能レベル以降を実行している場合は、追加のオプションがあるため、管理やアクセス制御などの設定によって異なります。2012機能レベルでは、制約のない委任を介してドメイン間で資格情報を委任する機能が開きます。 、 Traditional Constrained Delegation 、または Resource-Based Constrained Delegation 。私の残りの回答では、あなたが2012+機能レベルを使用していることを前提としていますが、そうでない場合、機能レベルに関係なく、制約なしの委任の構成手順は同じです。

一般的な要件

選択する委任のタイプに関係なく（すべてのオプションは以下にリストされます）、すべての構成では、「中間」サービスを実行するために使用する account の次の基本設定が必要です（例- 上の図ではサーバーAですが、これはデータベース、IISでホストされているWebサイト、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暗号化トークンを委任できるようになります。

注：前述のプロパティは、さまざまな方法で表示および設定できます。 Active Direcotory Users and Computers MMC Snapinは、これらのプロパティを調整するために使用できる最も一般的なグラフィカルユーザーインターフェイスですが、このインターフェイスは、これらのプロパティの多くを難読化しますグループ管理サービスアカウントの管理に関しては total garbage です。その結果、 ActiveDirectory PowerShell モジュールを使用して、 Set-ADUser または Set-ADServiceAccount コマンドを使用してこれらのプロパティを明示的に指定します。さらに、ユーザー/サービスアカウントのプロパティを Get-ADUser または Get-ADServiceAccount コマンド。

さらに、すべてのSQL ServerにはSPNが登録されている必要があります。 手動でこれらを作成できます 。ただし、SQL Serverを実行しているサービスアカウントを適切なOUにネストすると、自己登録されたSPNが自動的に発生します。そのプロセスに関する説明は、 ここにあります です。

委任の種類

繰り返しになりますが、2012以降のAD機能レベルを使用している場合、クロスドメインの委任を実行するための3つのオプションがあります。私はそれらを最も簡単に設定/最も安全ではない方法から最も苛立たしい設定/最も安全な方法にリストします。これらはどれでも機能し、どの程度の管理/セキュリティの露出を処理したいかは完全にあなた次第です。

ここでのもう1つのヒントは、以下にリストされている複数またはすべてのタイプの委任を使用するようにアカウントを構成することを妨げるものがないことです。これらの構成は相互に排他的ではありません。ただし、最初に最も安全性の低い構成を使用する可能性があるため、複数の委任スキームの下でアカウントをセットアップしないように最善を尽くす必要があります（アカウントのセットアップ方法の決定に関するセクションは以下にあります）。

制約のない委任

制約のない委任は、セットアップが最も簡単な構成ですが、最も制限の少ないアプローチです。この構成により、サーバーAを実行しているサービスアカウントが任意の資格情報を任意のセカンダリサービスに委任できるようになります。これは、上の画像で視覚的に表されており、資格情報を委任できる受信クライアント接続またはセカンダリサービスに制限がないことを青い矢印で示しています。 中間アカウントでこのタイプの委任を構成するには、（上記に加えて）次のADプロパティを設定するだけです。

  • TrustedForDelegation–これをTrueに設定します

これまではこれですべてでしたが、 2019年7月のWindowsセキュリティパッチ では、そのリンクで説明されているように、信頼全体で委任を再度有効にする必要があります。このセキュリティパッチは、このセットアップの深刻な欠点に対処するために実際に設計されました。これは、この投稿 Hunting in Active Directory：Unconstrained Delegation＆Forests Trusts で詳しく説明されています。繰り返しになりますが、2012年より前のAD機能レベルを使用していない限り、このタイプの委任を使用することはお勧めしません。

従来の制約付き委任

従来の制約付き委任サーバーAがアクセス許可を委任できるサービスを制限する。これにより、サーバーAを実行するサービスアカウントは、明示的にリストされているサービスに資格情報を委任することのみが許可されます。たとえば、それでも誰の資格情報も委任できますが、明示的にリストされているサービスにのみ、その資格情報を渡すことができます。視覚的に言えば、黄色の矢印で示されているように、委任できる「宛先」を制限しています。

enter image description here

中間アカウントで構成する必要があるADプロパティ（上記の一般的な要件セクションに記載されているものに加えて）は次のとおりです。

  • msDS-AllowedToDelegateTo-これは、このアカウントが資格情報を委任できるすべての該当するSPNのリストである必要があります。この例では、次のようになります。MSSQLSvc/ORDB1.usa.contoso.com、MSSQLSvc/ORDB1.usa.contoso.com：1433（ORDB1サーバーがUSAにあると仮定してCONTOSOフォレストのドメイン）。

この構成では、委任をAD KERBEROSトークンのみに制限します。 非委任したい場合KERBEROScredentialsNTLMを介して渡されるものなど、委任するようにこのアカウントを設定できますANYプロトコルでは、次のプロパティも設定します。

  • TrustedToAuthForDelegation–これをTrueに設定します

ただし、ANYプロトコル構成の使用は本質的に危険です。 このブログ記事 では、これらのプロパティとその影響について詳しく説明しています。これをtrueに設定する必要がない限り、使用しないことをお勧めします。

個人的な見地からは、セットアップが簡単で比較的安全であるため、従来の制約付き委任を使用することがよくあります（ANYプロトコルに委任を使用することを決定しない限り、問題に備えて設定していると思います）。

リソースベースの制約付き委任

リソースベースの制約付き委任セカンダリサービスが委任された資格情報を許可する中間サービスを制限します。これは、以前の構成のようにサーバーAを構成する代わりに、委任された資格情報を信頼するサービスを一覧表示してサーバーBを構成するという点で、他の構成と少し異なります。これは、サーバーAを実行する中間アカウントに追加の変更を加える必要なく実行されます。したがって、このシナリオでは、サーバーAがボブの資格情報を渡そうとすると、サーバーBはサーバーAがアクセス許可を委任できる「信頼できる」サービスであることを識別します認証は問題なく行われます。視覚的に表現すると、次のようになります。

enter image description here

ここで完全に明確にするために、中間アカウント（サーバーAなど）では、上記のCommon Requirementsセクションのプロパティを構成する必要があります。さらに、宛先サービス（つまりServer A）では、追加のADプロパティを設定する必要があります。

  • PrincipalsAllowedToDelegateToAccount-これには、資格情報の委任が信頼されているサービスの該当するすべてのSPNがリストされている必要があります。この例では、これらは次のようになります。MSSQLSvc/server_italia.euro.contoso.com、MSSQLSvc/server_italia.euro.contoso.com：1433

それだけです...概念的に。これを確かめるためにテストしてください、しかし私がこのアプローチを概説しているのを見つけた記事から、これは本当に必要なすべてです。実際、この MS記事 はプロセスを実行し、これを設定するために必要な該当するPowerShellコマンドをリストアップします。これにより、サンプルのPowerShellプログラムを実行して、ダブルホップとそのリソースベースの制約付き委任が役立ちます。さらに、この委任構成は問題なく（または私が読んだことから信頼の要件として）ドメインを越えて機能するはずです。ここでの欠点は、すべての「エンドポイント」を構成する必要があることです。これは、セットアップの方法に応じて、長期的にはより多くの管理作業になる可能性があります。

どのように構成された委任設定を知っていますか？

私の意見では、アカウントが実行されている委任構成を特定することは、約 clear as mud です。ありがたいことに、 Willem Kasdorpが記事 と PowerShellスクリプト を投稿して、アカウントの現在の構成を示しています。 ActiveDirectory PowerShell モジュールがインストールされているコンピューターからこれを実行する場合は、問題ありません。うまくいけば、上記で説明した委任構成のタイプとこのスクリプトが生成するマトリックスの組み合わせにより、現在構成されている内容が明確にわかるようになります。

最後に、AD PowerShellコマンドのヘルプが必要な場合、 this article は、SPNのリストなどで説明したプロパティのいくつかを設定するときに、適切な構文を表示するのに十分な仕事をします。 。

ご不明な点がございましたら、コメントをお寄せください。迅速に回答できるよう最善を尽くします。

4
John Eisbrener