ユーザーがドメイングループ経由でアクセスを許可すると、SQLServerデータベースアクセスが失敗する
SQL Server 2008 R2（Win2003で実行）では、ドメイングループを介したログインに問題があります。ログインアクセスはサーバーインスタンスに付与されますが、サーバー上の特定のデータベースにはアクセスできません。
SQLサーバーマシンはADドメインのメンバーですが、ドメインコントローラーではありません。 SQLServerでWindows認証を使用しています。
ドメイングループのSQLServerログインを作成します。そのサーバー上のデータベースXXXへのユーザーマッピングを設定し、ロールdatareader、datawriter、およびddladminを有効にします。その場合、これらのグループのメンバーであるドメインユーザーはSQL Serverに接続できますが、このデータベースXXXには接続できません。ユーザー「user1」が接続しようとすると、「ログインによって要求されたデータベース「XXX」を開けません。ログインに失敗しました。ユーザー「domain\user1」のログインに失敗しました。」というエラーが表示されます。
'domain\user1'をデータベースXXXに手動で追加し、データリーダー、データライターの役割を有効にすると、user1は問題なく接続できます。
不思議なことに、user1は同じサーバー上の他の2つのデータベースに接続できます。ここでもADドメイングループを介して接続できますが、以前に作成された別のグループであり、ユーザーはこれらのデータベースのユーザーとして個別に設定されません。これらのデータベースは両方とも、detach-attachを介して古いSQL Server 2005インストールからコピーされ、SQL-2005で正常に機能し、そのSQL-2008R2サーバーでも正常に機能するようになりました。 （問題のあるデータベースXXXと同じDBプロパティの所有者と同じユーザーアカウントが表示されます。）
データベースXXXは、そのR2サーバー上に作成された新しいデータベースであり、ADドメイングループも新しいものです。
今のところ、回避策としてユーザーを手動で追加できますが、これは永久に機能するわけではなく、ここで何が問題になるのかについてのヒントが必要です。追加データ-SQLServerサービスはドメイン管理者アカウントで実行されます。
SQL Server 2005のこれとまったく同じ問題について説明している記事を見つけました： https://connect.Microsoft.com/SQLServer/feedback/details/248615/login-fails-when-user-is-granted-access -via-a-domain-group しかし、それは2006年のものであり、解決策に関する手がかりは含まれておらず、修正されたと想定する必要があります。
余談ですが、SQLServerをドメイン管理者として実行することはベストプラクティスではありません。 SQLを非特権ドメインユーザーとして実行することを検討することをお勧めします。
デタッチ/アタッチを介して移動されたデータベースにアクセスできるユーザーに関しては、SIDはデータベースとともに移動します。
動作に基づいて推測する必要がある場合、SQLがグループメンバーシップを判別するのに問題があるか、データベース自体のアクセス許可が欠落していると言えます。
特定のデータベースの詳細についてはSELECT * FROM sys.database_principalsを実行し、ドメイングループがそこにあることを確認することをお勧めします。
推測しなければならないのですが、ユーザーは、SQLログインとして使用しているグループに追加された後、ログオフおよびログオンし直していません。ユーザーのアクセストークンは、そのユーザーがワークステーションにログオフして再度ログオンするまで、新しいグループメンバーシップで更新されません。これは、古いグループが機能するのに、テストしている新しいグループが機能しない理由を説明します。