web-dev-qa-db-ja.com

Windows認証を使用したクロスドメインSQL Serverログイン

ログインとして機能するドメイングループでWindows認証を使用するSQL Server 2005名前付きインスタンスがあります。ドメイン構造は次のとおりです。

_      Forest1                Forest2
      /      \                  |
Domain1       Domain2        Domain3
_

オブジェクトは次のドメインに編成されます。

Forest1.Domain1

  • ユーザー
  • グローバルグループ

Forest1.Domain2

  • SQL Serverインスタンス
  • ドメインローカルグループ（ログインとして機能）

Forest2.Domain3

  • ユーザー
  • グローバルグループ

すべてのユーザーは_Domain1_および_Domain3_に存在しますが、SQL Serverボックスは_Domain2_に存在します。そのため、私のログインは_Domain2_のドメイングループです。 _Domain1_のユーザーが_Domain2_のドメインローカルグループに追加され、TCP/IPプロトコルを使用してSQL Serverインスタンスに接続しようとすると、次のエラーメッセージが表示されます。

<インスタンス>に接続できません。ユーザー 'Domain1\userName'のログインに失敗しました。 （Microsoft SQL Server、エラー：18456）

私が試した他のこと：

  • ユーザーをログインとして明示的に追加すると、接続できます。

  • ユーザーがログインとしてメンバーである_Domain1_グローバルグループを明示的に追加すると、彼は接続できます。

  • ユーザーがログインとして使用される_Domain1_ドメインローカルグループのメンバーとしてメンバーである_Domain2_グローバルグループを追加すると、彼は接続できません。

  • EDIT：SQL Serverをホストしている_Domain2_サーバーのDemote Desktop Usersグループに_Domain2_ドメインローカルグループを追加した場合インスタンス、_Domain1_ユーザーはサーバーに正常に接続できます-また、_Domain1_ユーザーとしてインスタンスにローカルに接続できます（リモートではありません）。

  • EDIT：_Domain2_ドメインローカルグループをローカルサーバーグループに追加し、そのローカルサーバーグループのSQL Serverログインを作成すると、 _Domain1_ユーザーは引き続きインスタンスにリモートで接続できません。

  • EDIT：接続ネットワークプロトコルを「名前付きパイプ」に変更すると、_Domain1_ユーザーはリモートで正常に接続できます。

私が理解していることから（これらのTechNet記事を参照： グループスコープ および ネストグループ ）、ドメイングループは両方の_Domain1_および_Domain3_。

ドメイングループに_Domain1_と_Domain3_の両方のユーザーを含めることができ、ユーザーがTCP/IP経由でリモート接続できるように、Windows認証を使用してSQL Serverログインとしてドメイングループを使用するにはどうすればよいですか？

その他の注記

  • SQL Serverの名前付きインスタンスのサービスアカウントは、_Domain1_のユーザーアカウントです
  • SPNがサービスアカウントに追加されました（サーバー名とエイリアス名を含む）

[〜＃〜] update [〜＃〜]

SQLサービスインスタンスのサービスアカウントを_Domain2_に変更すると、問題が解決したようです。さらに調査し、調査結果をポストバックします！

sql-serversql-server-2005cross-domainwindows-authentication
26
bitxwise

私の質問の更新で述べたように、サービスアカウントをDomain2に変更すると問題が解決しました。それで、何が起こっていたのでしょうか？

問題-説明

サービスアカウントは元々Domain1ユーザーであったため、ユーザーの認証時に接続しているユーザーがどのドメインローカルグループであるかを判断できませんでした。 Kerberos。これがKerberosの問題であるという主な原因は、NTLM認証を使用するため、「名前付きパイプ」を使用して正常に接続したことです。

全体的なソリューション

まとめて、Domain1およびDomain3のユーザーをDomain2のグループのメンバーとして正常に追加して、グループをWindows認証でSQL Serverログインとして使用できるようにするには、次のリストを参照してください。要件の（または少なくとも強く推奨）：

  1. ドメイン間に確立された信頼関係
    1. 少なくとも、Domain2がDomain1およびDomain3を信頼するように、一方向の信頼を設定する必要があります
  2. Domain2のグループは、「ドメインローカル」をスコープにする必要があります
    1. これは、Domain1およびDomain3からユーザーとグループを追加できるようにするためです。
    2. 詳細については here を参照してください
  3. SQL Server構成マネージャーを使用して、非管理者Domain2ユーザーをサービスアカウントIDとして指定します
    1. [〜＃〜] msdn [〜＃〜] ドメインユーザーアカウントの使用が推奨される理由を文書化
    2. 構成マネージャーは、ユーザーをローカルのSQL Server 2005固有のグループ（つまり、SQLServer2005MSSQLUser $ MY_MACHINE $ MY_INSTANCE）に追加することになっていますが、そうではないいくつかのインスタンスに遭遇しました。したがって、ローカルグループをチェックして、Domain2ユーザーアカウントで適切に更新されていることを確認してください。
    3. SQL Serverセットアップはローカルグループに適切なアクセス許可を自動的に割り当てる必要がありますが、ここでもそうではないいくつかのインスタンスに遭遇しました。これが発生した場合、これを参照できます [〜＃〜] msdn [〜＃〜] 記事と、前述の許可要件の記事。
  4. SQL Serverインスタンスホスト（エイリアスを含む）およびDomain2サービスアカウントのサービスプリンシパル名（SPN）を構成します。
    1. SPNは、クライアントとサーバーホスト間の相互認証に必要です。
    2. 詳細はこちらをご覧ください TechNet 記事
  5. 偽装の使用方法によっては、Domain2サービスアカウントを委任に対して信頼できるようにすることが必要な場合があります
    1. 詳細はこちらをご覧ください TechNet 記事
  6. SQL Serviceインスタンスのリモート接続を有効にします
  7. 最後に、目的のDomain2グループのログインを作成し、Domain1またはDomain3メンバーがリモートで接続できるようにします。

注

他のリモートネットワークアクティビティと同様に、ファイアウォールをチェックして、SQL Serverポートがブロックされていないことを確認します。デフォルトのポートは1433ですが、ポートがクリアであることを確認してください。

16
bitxwise

OK、私は2017年にも問題を解決しましたが、解決策を見つけるのは難しいです、最後に、私は自分の場合にのみそれを見つけ出します。

私の環境、

フォレスト1（ドメイン1）---信頼---フォレスト2（ドメイン2）

Windows認証を使用してDomain1のSQLサーバーにログインしようとするDomain2のサービスアカウントがあります。

そして、次のエラーメッセージがポップアップします。

ログインに失敗しました。ログインは信頼できないドメインからのものであり、Windows認証では使用できません。 （Microsoft SQL Server、エラー：18452）

このソリューションは非常にシンプルで、domain1でActive Directoryドメインと信頼ツールを開き、

信頼->発信信頼->プロパティ->認証->「フォレスト全体の認証」に変更

私の問題は解決しました。

1
Larry Song