web-dev-qa-db-ja.com

SQL ServerサービスアカウントのWindows権限と権利

私の質問は、SQL Serverプロセスごとに新しいドメインユーザーアカウントを作成する場合、各アカウントにどのようなアクセス許可を設定する必要があるかです。または、SQL構成マネージャーが実際にこれを処理し、予期しない問題が発生しただけですか?

私はかなり頻繁にMicrosoft SQL Serverをセットアップする必要があり、サービスを実行するアカウントの構成に関するアドバイスを誰かが提供できるかどうか疑問に思いました。 IMOこれは漠然とMicrosoftによって文書化されていますが、私は具体的な例を見つけることができなかった正しい方向にあなたを指しています。

これまでに見てきたことを要約すると:

シンプルなデプロイメント\開発環境の場合、インストーラーが使用する仮想アカウントのデフォルトを使用しても問題ありません。 NT SERVICE\MSSQLSERVER

SYSTEMアカウントの使用は避けてください。これは安全ではありません。

本番環境およびドメイン環境では、管理されたサービスアカウントを使用するか、サービスごとにドメインユーザーアカウント(管理者ではない)を作成することをお勧めします。インストール時にドメインアカウントを使用すると、インストーラーが必要な権限を設定するとされています。

既存のインストールのサービスアカウントを仮想アカウントからドメインアカウントに変更する場合、SQL Server構成マネージャーを使用して新しいサービスアカウントを設定することをお勧めします。これにより、必要な権限が設定されます。

既存のインストールのサービスアカウントをドメインアカウントに変更しようとしたところ、アカウントを付与するまでログオンに失敗しましたlog on as service権限。これは、SQL Server構成マネージャーが必要な権限を設定する部分と矛盾します。 (GPOがこのローカルセキュリティポリシーの設定に干渉した可能性があるかどうかはわかりませんが)

Microsoftは、SQL Serverセットアップが付与するアクセス許可のリストを提供しています このページ

しかし、それを作成するユーザーがサービスを実行するために手動で行う必要があるのか​​、またはSQL構成マネージャーを使用してこれらのアクセス許可を自動的に設定する必要があるのか​​は、はっきりしません。

SQL Server 2014、ドメインコントローラーはWindows Server 2008 R2にあります。

12
plumdog

私はかなり頻繁にMS SQL Serverをセットアップする必要があり、サービスを実行するアカウントの構成に関するアドバイスを誰かが提供できるかどうか疑問に思いました。 IMOこれは漠然とMicrosoftによって文書化されていますが、私は具体的な例を見つけることができなかった正しい方向にあなたを指しています。

実際には完全に文書化されています: http://msdn.Microsoft.com/en-us/library/ms143504.aspx

わからない部分はありますか?

シンプルなデプロイメント\開発環境の場合、インストーラーが使用する仮想アカウントのデフォルトを使用しても問題ありません。 NT SERVICE\MSSQLSERVER

これは環境に依存します。私は個人的には、ローカルアカウントを使用して誰かがセットアップしたサーバーを見つけたり、将来的にネットワークリソースへのアクセスを要求したりすることを嫌います。

本番環境およびドメイン環境では、管理されたサービスアカウントを使用するか、サービスごとにドメインユーザーアカウント(管理者ではない)を作成することをお勧めします。

繰り返しますが、一般的には同意します(反例は、すべてのインスタンスで単一のドメインアカウントを使用することが理にかなっている可用性グループです)。

インストール時にドメインアカウントを使用すると、インストーラーが必要な権限を設定するとされています。

故障等ない限りそうします。 「申し立てられた」部分がなぜなのかわかりません。

既存のインストールのサービスアカウントを仮想アカウントからドメインアカウントに変更する場合、SQL Server構成マネージャーを使用して新しいサービスアカウントを設定することをお勧めします。これにより、必要な権限が設定されます。

SQL Serverのサービスを変更する場合は、常にSSCMを使用してください。常に。限目。新しいアカウントの権限を基本に設定します。ローカルシステムアカウントが使用される前に、システム上のすべてに対する無制限のアクセス許可があった場合、より厳格に制御されたセキュリティのため、変更後に何かがアクセス許可に失敗すると予想します。これはSQL ServerのSSCMの障害ではなく、適切なEXTRA権限(ネットワーク共有へのアクセス、制限されたフォルダー、SQL Serverのインストール領域外のアイテムなど)を付与しないという管理上の障害です。

既存のインストールのサービスアカウントをドメインアカウントに変更しようとしたところ、「サービスとしてログオン」権限をアカウントに付与するまでログオンに失敗しました。これは、SQL Server構成マネージャーが必要な設定を行う部分と矛盾します。権限。 (GPOがこのローカルセキュリティポリシーの設定に干渉した可能性があるかどうかはわかりませんが)

GPOが問題を引き起こしているようです(IMHO)。初めてではないでしょう:)

つまり、私の質問は、SQL Serverプロセスごとに新しいドメインユーザーアカウントを作成すると、各アカウントにどのようなアクセス許可を設定する必要があるのでしょうか。

上記のmsdnリンクに記載されている権限(@joeqwertyとOPでも提供される)以外の権限を明示的に設定します。たとえば、ネットワーク共有の「バックアップ」フォルダ、新しいデータベースを保持するために追加された新しいドライブ(セットアップは既に実行されていたが、ドライブが存在しなかった場合)など。

しかし、それを作成するユーザーがサービスを実行するために手動で行う必要があるのか​​、またはSQL構成マネージャーを使用してこれらのアクセス許可を自動的に設定する必要があるのか​​は、はっきりしません。

サーバーで何かが極端に壊れていない限り、これらを手動で指定する必要はありません。

10
Sean Gallardy