none
Windows認証について RRS feed

  • 質問

  • ユーザーをAドメインからBドメインへADMTを使用し
    SIDを引継ぐかたちで移行を行い、Aドメイン所属の
    SQL2005にアクセスすることを考えています。

    SQLサーバーにはAドメインユーザーにアクセス権を
    付与しています。認証はWindows認証です。
    Aドメインユーザーでは問題なくアクセス可能です。

    SIDが引継がれているためSQLサーバー側に
    アクセス権の付与を行わなくとも問題ないと
    考えていましたが、Bドメイン側ユーザーで
    アクセスをするとアクセス権が有りませんと
    エラーが出てしまいます。
    Bドメイン側ユーザーに対しアクセス権を付与
    するとアクセス可能となります。

    SQL側に問題が有るのか、そもそもSIDを引継
    を行っていてもアクセス権の付与は必要なのか
    切り分けが出来ないでいます。

    台数・ユーザー数共に多いので、可能であれば
    アクセス権の付与を回避したいのですが、認証
    的に難しいようで有れば、付与を検討したいと
    考えています。

    何か情報をお持ちの方いらっしゃいましたら
    ご教授頂けないでしょうか。

    よろしくお願いします。
    2010年3月4日 2:41

回答

  • 頂いた情報から推測すると、SQL Server 上に、Bドメインに存在している ドメインユーザー の SID を含んだログインがなければ、SQL Server には接続できないみたいですね。
    なお、ドメイン B ユーザーに対して権限を付与することとあまり変わりませんが、ドメイン グループに対してログインを作成し、ドメイン グループに、ドメインA、B のユーザーを所属させると、SQL に接続できると思われます。
    あまりお役にたてず、すみません。

    • 回答としてマーク もとぞう 2010年3月8日 0:55
    2010年3月4日 8:29
  • こんにちは、nagino です。

    ちょっと直ぐに確認できる環境がないのですが、SQL Server のログインと Windows のアカウントのマッピングが崩れているだけではないでしょうか。
    ADMT はファイルやフォルダのアクセス許可の設定を引き継ぐことを主に用意されているツールのはずですので、SQL Server のログインはフォローしていないと思われます。
    SQL Server Management Studio (SQL Server のバージョンが分かりませんので Enteprise Manager かもしれませんが)でログインを変更してみてください。

    # AD のグループで SQL Server のログインを作っていれば、そのログインのメンテナンスだけで済みますので、そんなに大変な作業ではないかと思います。


    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク もとぞう 2010年3月8日 0:55
    2010年3月4日 10:33

すべての返信

  • 現在実施されている作業は、以下の解釈であっておりますでしょうか。

    1) ドメイン A 上の U1 ドメインユーザー情報を、ドメイン B 上に  ドメイン A 上 と同じく U1 ドメインユーザー (SIDも同じ) として移行。
    2) ドメイン A と ドメイン B には信頼関係は無い。

    AD 上のドメインユーザー(SID) には詳しくないのですが、各ドメイン固有のSIDをもっていたような気がします。
    ADMT にて、違うドメインなのに、各ドメイン固有のSIDを保持できるのかどうかは分かりませんが。

    SQL Server 上で以下のクエリを実行すると、SQL Server に登録されているログイン情報を確認することができます。
    ドメインB ユーザーに対するアクセス権限を付与する前/後にて、情報を確認されてみてはどうでしょう。

    use master
    go
    select * from sys.syslogins
    go

    恐らくですが、ドメインA\U1 と、ドメインB\U1 の "SID" が異なっている、もしくは ドメインB\U1 の "loginname" が登録されていないことに起因し、今回の現象が発生しているように思えます。
    アクセス権限を付与する手間があるのであれば、ドメインA、ドメインB にて信頼関係を結ばれてはどうでしょう。

    ※ ちなみに、アクセス権限を、ドメインB\U1 に付与することにより、SQL Server に接続できるのであれば、SQL Server の問題では無いと思います。

    2010年3月4日 4:26
  • NOBTA様
    返信ありがとうございます。

    作業環境での認識ですが、
    1)ですが、SIDは異なります。AドメインユーザーのSIDは
    SIDHistory内に保持しております。
    2)AドメインとBドメインとは信頼関係を結んでいます。

    Bユーザーのアクセス権付与前/後での情報ですが、
    SIDに記載されているSID値は異なりました。

    ちなみにサーバー側のフォルダに対しては、
    BユーザーでAアクセス権が付与されている
    ファイルにアクセス出来ました。

    よろしくお願いします。
    2010年3月4日 5:58
  • 頂いた情報から推測すると、SQL Server 上に、Bドメインに存在している ドメインユーザー の SID を含んだログインがなければ、SQL Server には接続できないみたいですね。
    なお、ドメイン B ユーザーに対して権限を付与することとあまり変わりませんが、ドメイン グループに対してログインを作成し、ドメイン グループに、ドメインA、B のユーザーを所属させると、SQL に接続できると思われます。
    あまりお役にたてず、すみません。

    • 回答としてマーク もとぞう 2010年3月8日 0:55
    2010年3月4日 8:29
  • こんにちは、nagino です。

    ちょっと直ぐに確認できる環境がないのですが、SQL Server のログインと Windows のアカウントのマッピングが崩れているだけではないでしょうか。
    ADMT はファイルやフォルダのアクセス許可の設定を引き継ぐことを主に用意されているツールのはずですので、SQL Server のログインはフォローしていないと思われます。
    SQL Server Management Studio (SQL Server のバージョンが分かりませんので Enteprise Manager かもしれませんが)でログインを変更してみてください。

    # AD のグループで SQL Server のログインを作っていれば、そのログインのメンテナンスだけで済みますので、そんなに大変な作業ではないかと思います。


    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク もとぞう 2010年3月8日 0:55
    2010年3月4日 10:33
  • NOBTA様
    nagino様

    返信頂きありがとうございます。
    アクセス権を付与しないと難しそうですね。
    付与する方向で作業を行いたいたと思います。

    ありがとうございました。
    2010年3月8日 0:55