web-dev-qa-db-ja.com

ドメインアカウントで実行されているSQL ServerがSPNを登録できない

SQL Serverの新規インストールをドメインアカウントで実行するように構成しようとしています。しかし、別のドメインアカウントを使用してサーバーに接続しようとすると断続的なエラーが発生し、ERRORLOGファイルをトロールするとThe SQL Server Network Interface library could not register the Service Principal Nameが引き続き表示されます。

サービスグル​​ープ（管理されたサービスアカウントではなく、通常のユーザーアカウントのみ）をADグループ（例：SQL Servers）に追加し、ドメインComputersコンテナーのACLにACEを追加しました、このグループでは、次を選択します。

  • 適用先：子孫コンピューターオブジェクト
  • サービスプリンシパル名への検証された書き込み：許可
  • ServicePrincipalNameの読み取り：許可
  • ServicePrincipalName：書き込み

これをすべてのドメインコントローラーに複製し、[有効なアクセス許可]タブとdsacls CN=SERVER01,CN=Computers,DC=fabrikam,DC=localの両方を使用して、新しいACEが特定のコンピューターオブジェクトに継承されていることを確認しました。

Allow FABRIKAM\SQL Servers
                                  SPECIAL ACCESS for Validated write to service principal name   <Inherited from parent>
                                  WRITE SELF
Allow FABRIKAM\SQL Servers
                                  SPECIAL ACCESS for Validated write to service principal name   <Inherited from parent>
                                  WRITE SELF
                                  WRITE PROPERTY
                                  READ PROPERTY

ただし、SQL Serverサービスを再起動しても、could not register the Service Principal Nameメッセージが表示されます。サーバーも再起動しましたが、結果は同じです。

Sysinternals Process Explorerを使用して、実行中のsqlservr.exeを検査しました。 [セキュリティ]タブには、正しいサービスユーザーとSQL Serversグループのメンバーシップが明確に表示されています。

setspn -Aを使用して手動でSPNを追加できることはわかっていますが、それが本当の意味ではありません。

サービスアカウント（およびSQL Serversグループに配置する将来のアカウント）が手動の介入なしに独自のSPNを自動的に登録できるようにするには、他に何をする必要がありますか？

AND/OR

ここで不足している特権/権限をさらに診断するにはどうすればよいですか？

active-directorysql-serverkerberos
6
jimbobmcgee

見つけた。

SPNをサービスアカウントに手動で登録し、ADSIEditを使用してADを検査したところ、手動​​で登録されたSPNがComputerアカウントのservicePrincipalNameフィールドに格納されていないことがわかりました。ただし、特定のUserアカウントのservicePrincipalNameフィールド。

そのため、自分のSQL Serversグループに独自のSPNを登録する権利を付与する代わりに、そのコンピューターでローカルシステム/ネットワークサービスアカウントとして実行されているサービスによって登録されたSPNを変更する権利を（不注意に）与えました。

Computersコンテナから新しいACEを削除し、代わりに新しいSQL Servers組織単位を作成しました。このOUにSELFのACEを追加し、子孫usersに適用するように制限しました：

  • SQL Servers OU ACL
    • SELF
      • 適用先：子孫ユーザーオブジェクト
      • ServicePrincipalNameの読み取り：許可
      • ServicePrincipalName：書き込み

SQL Serverインスタンスを起動すると、予期されたThe SQL Server Network Interface library successfully registered the Service Principal Nameが表示され、リモート接続にKerberosが使用されています。

（内部プロセスのドキュメントを更新するため、新しいSQL Serverサービスアカウントをグループに追加するのではなく、新しいOUの下に作成する必要があります）

編集：ドメイン管理者は、setspn.exeを使用して、SPNをドメインアカウントに手動で登録することもできます。

setspn -S MSSQLSvc/myhost.redmond.Microsoft.com:1433 DOMAIN\User
setspn -S MSSQLSvc/myhost.redmond.Microsoft.com DOMAIN\User

Kerberos接続のサービスプリンシパル名を登録する（TechNet） 。

編集2：Read servicePrincipalNameおよびWrite servicePrincipalNameプロパティがACEリストに表示されない場合は、 Attribute Editor オブジェクトのPropertiesダイアログのタブで、 Filter ボタンをクリックして、以下を確認します。

  • 値を持つ属性のみを表示しますはチェックされていません
  • 書き込み可能な属性のみを表示はチェックされていない
  • 属性を表示：必須はチェックされています
  • 属性を表示：オプションはチェックされています
  • 読み取り専用属性を表示：構築済みはチェック済み
  • 読み取り専用属性を表示：バックリンクはにチェックされます
  • 読み取り専用属性を表示：システムのみはチェックされています

（他の組み合わせでも機能する可能性がありますが、これは私にとってはそれです）

5
jimbobmcgee

実行しているSQL Serverのバージョンやサービスアカウントのアクセス許可（管理されたサービスアカウントではなく、SPNを書き込んでいることを除く）は言わなかったが、提供している情報から、アカウントには自分自身をSPNとして登録する権限がありません。確かに、あなたはそれを明示的に認めています。

どうやら SQL 2012requiresvirtual account or Managed Service Account on Server 2008 ：

データベースエンジンサービスは、起動時にサービスプリンシパル名（SPN）の登録を試みます。 SQL Serverを起動するアカウントにActive DirectoryドメインサービスにSPNを登録する権限がない場合、この呼び出しは失敗し、警告メッセージがアプリケーションイベントログとSQL Serverエラーログに記録されます。 SPNを登録するには、データベースエンジンがローカルシステム（非推奨）、NETWORK SERVICEなどのビルトインアカウント、またはドメイン管理者アカウントなどのSPNを登録する権限を持つアカウントで実行されている必要があります。 SQL ServerがWindows 7またはWindows Server 2008 R2オペレーティングシステムで実行されている場合、仮想アカウントまたは管理されたサービスアカウント（MSA）を使用してSQL Serverを実行できます。仮想アカウントとMSAの両方がSPNを登録できます。 SQL Serverがこれらのアカウントのいずれかで実行されていない場合、SPNは起動時に登録されないため、ドメイン管理者は手動でSPNを登録する必要があります。

お役に立てば幸いです。

2
Katherine Villyard

SQLサービスで使用されるADアカウントの名前が20文字より長い場合、SetSpn.exeはADでそれを見つけることができず、Kerberosを使用してSQLセッションを認証する唯一の方法は、AD権限の再構成とSQLの再起動。名前パラメーターを短くしてSetSpn.exe -Sをだまそうとしないでください。SetSpn.exeはアカウントを検出しますが、Kerberosに対して「不一致」の名前で登録します。

0
Marek Grzymala