Deep Security Managerのインストール時にMicrosoft SQL Serverデータベースに接続できない場合は、次の手順に従って問題のトラブルシューティングを実行してください。
![]() |
注意このトピックで扱う範囲は、Windowsドメイン認証の問題に限定されています。SQL Server認証を代わりに使用している場合は、データベース を設定し、そのトピックに記載されている設定手順を確認して問題をトラブルシューティングしてください。
|
![]() |
ヒントWindowsドメイン認証は、さまざまな名前で呼ばれます。Kerberos認証、ドメイン認証、Windows認証、統合認証などです。このトピックでは、KerberosおよびWindowsドメイン認証という用語を使用しています。
|
手順1: ホスト名とドメインを確認する
[ホスト名] フィールドがFQDN形式であり、DNSサーバによって解決可能であることを確認する必要があります。
-
Deep Security Managerのインストーラを実行して、データベースの手順まで来たら、必ずSQLサーバのFQDNを指定してください。IPアドレスやNetBIOSホスト名を入力しないでください。有効なホスト名の例:
sqlserver.example.com
-
FQDNが登録されていて、DNSサーバによって解決可能であることを確認してください。DNSエントリに正しいホスト名が設定されているかどうかを確認するには、
nslookup
コマンドラインユーティリティを使用します。このユーティリティは、ドメイン上の任意のコンピュータから呼び出すことができます。次のコマンドを入力します。nslookup <SQL Server FQDN>
ここで、<SQL_Server_FQDN>
は、SQLサーバのFQDNに置き換えます。指定したFQDNをユーティリティが正常に解決できる場合、DNSエントリは正しく設定されています。FQDNを解決できない場合は、DNS Aレコードと、FQDNを含むリバースレコードを設定します。 -
さらに、インストーラのデータベースページで [詳細] をクリックし、[ドメイン] フィールドにSQLサーバの完全ドメイン名を指定します。ドメインには1つ以上のドット (「.」) を含める必要があります。短縮ドメイン名やNetBIOS名を入力しないでください。有効なドメイン名の例:
example.com
-
nslookup
コマンドラインユーティリティを使用して、ドメイン名がFQDN形式であることを確認します。次のコマンドを入力します。nslookup <Domain_Name>
ここで、<Domain_Name>
は、SQLサーバの完全ドメイン名に置き換えます。指定したドメイン名をユーティリティが解決できる場合、それは完全なドメイン名です。注意
Microsoftワークグループを使用したデータベース認証は、Deep Security Manager 10.2以降ではサポートされていません。Windowsドメイン認証の場合は、Active Directoryドメインコントローラをインストールし、ドメインを設定して、このドメインにSQLサーバを追加する必要があります。環境にActive Directoryドメインインフラストラクチャがない場合は、代わりにSQL Server認証を使用する必要があります。Windowsドメイン認証の代わりにSQL Server認証を使用するには、Managerのインストーラの [データベース] ページにある [ユーザ名] フィールドと [パスワード] フィールドに、Deep Security Managerデータベースの所有者のユーザ名とパスワードを入力します。ドメインを入力しないでください。ドメイン名を省略すると、SQL Server認証が使用されます。
手順2: servicePrincipalName (SPN) を確認する
servicePrincipalName (SPN) がActive Directoryで正しく構成されていることを確認する必要があります。
Microsoft SQL Serverの場合、SPNは次の形式です。
MSSQLSvc/<SQL_Server_Endpoint_FQDN>
MSSQLSvc/<SQL_Server_Endpoint_FQDN>:<PORT>
SPNが正しいことを確認するには、以下のタスクを実行します。最後に、特定の使用例での詳細な手順、他のドキュメントへの参照、およびデバッグのヒントがあります。
手順2a: SQL Serverサービスを実行しているアカウント (SID) を特定する
SPNは、SQL Serverサービスを実行しているアカウント内で設定されます。
どのアカウントがSQL Serverサービスを実行しているかを特定するには、
services.msc
ユーティリティを使用します。SQL Serverサービスが、関連付けられているアカウントと共に表示されます。
手順2b: Active Directoryでアカウントを確認する
SQL Serverサービスを実行しているアカウントの名前がわかったら、それをActive Directory内で見つける必要があります。アカウントが存在する可能性のある場所は、ローカル仮想アカウントであるか、ドメインアカウントであるか、管理されたサービスアカウントであるかに応じて決まります。以下の表は、それらの可能性のある場所をまとめたものです。Active
DirectoryコンピュータでADSIエディター (
adsiedit.msc
) を使用して、Active Directory内のさまざまなフォルダを探し、アカウントを見つけることができます。
アカウントの種類
|
アカウントの名前
|
Active Directory内のアカウントの場所
|
説明
|
ローカル仮想アカウント
|
NT SERVICE\MSSQLSERVER (初期設定のインスタンス) NT SERVICE\MSSQL$InstanceName (名前付きインスタンス)
|
CN=コンピュータ CN=<Computer_Name>
|
仮想アカウントで実行されるサービスは、コンピュータアカウントの資格情報を使用してネットワークリソースにアクセスします。初期設定のスタンドアロンSQL Serverサービスは、このアカウントを使用して起動されます。
|
ドメインアカウント
|
ドメインユーザ名 (例:SQLServerServiceUser)
|
CN=ユーザ CN=<User_Name>
|
このアカウントを使用して開始されたサービスは、ドメインユーザの資格情報を使用してネットワークリソースにアクセスします。SQL Serverフェールオーバークラスタでは、サービスを実行するためにドメインアカウントが必要です。スタンドアロンSQL
Serverサービスは、起動にドメインアカウントを使用するように設定することもできます。
|
管理されたサービスアカウント
|
管理されたサービス アカウント (MSA) 名 (例:SQLServerMSA)
|
CN=マネージドサービスアカウント CN=<Account_Name>
|
Windows Server 2008 R2で導入された、管理されたサービスアカウントは、ドメインアカウントに似ていますが、対話形式のログオンを実行するために使用できます。スタンドアロンのSQL
ServerサービスとSQL Serverクラスタサービスの両方を、管理されたサービスアカウントを使用して起動するように設定できます。
|
手順2c: SPNで使用するFQDNを特定する
命名の一貫性を保つために、SPNをエンドポイントのFQDNに設定することをお勧めします。エンドポイントは、SQL Serverクライアント (Deep Security
Manager) の接続先であり、個々のSQL Serverまたはクラスタである場合があります。使用するFQDNの詳細については、以下の表を参照してください。
SQL Serverのインストールの種類
|
SPNの設定
|
スタンドアロンSQL Server
|
SQL ServerがインストールされているホストのFQDN
|
フェールオーバーSQL Serverクラスタ
|
SQL ServerクラスタのFQDN (個々のSQL Serverノードはエンドポイントではないため、FQDNで使用しないでください)
|
手順2d: 初期設定のインスタンスを使用しているのか、名前付きインスタンスを使用しているのかを特定する
ポート番号とインスタンス名 (指定した場合) をSPNに含める必要があるため、SQL Serverが初期設定のインスタンスとしてインストールされたか、名前付きインスタンスとしてインストールされたかを知っておく必要があります。
-
初期設定のインスタンスは、通常、ポート1433を使用します。
-
名前付きインスタンスは、別のポートを使用します。このポートを判断するには、このWebページを参照してください。
例: SQL ServerサービスのFQDNエンドポイントが
sqlserver.example.com
であり、それが初期設定のインスタンスである場合、SPNは次の形式になります。MSSQLSvc/sqlserver.example.com
MSSQLSvc/sqlserver.example.com:1433
例2: SQL ServerサービスのFQDNエンドポイントが
sqlserver.example.com
であり、それがポート51635を使用するDEEPSECURITY
というインスタンス名の名前付きインスタンスである場合、SPNは次の形式になります。MSSQLSvc/sqlserver.example.com:DEEPSECURITY
MSSQLSvc/sqlserver.example.com:51635
ケース1:ローカル仮想アカウントでSPNを設定する
ローカル仮想アカウントで実行されるスタンドアロン SQL Server の SPN を設定するには:
-
Active Directoryコンピュータで
ADSIEdit.msc
を開きます。ADSI エディターが開きます。 -
[CN=Computers]でSQLサーバホストを見つけてください。
-
SQLサーバホストを右クリックし、[のプロパティ]を選択します。
-
[Attribute Editor]タブで[servicePrincipalNames]までスクロールし、[編集]ボタンをクリックします。
-
属性値が存在しない場合は、[追加] ボタンを使用して個別に追加します。[OK] をクリックします。

ケース2:ドメインアカウントでSPNを設定する
SQL Serverサービスを実行しているドメインアカウント ([CN=Users]) でSPNが設定されることを除き、SPN設定はローカル仮想アカウント設定と似ています。

ケース3:管理されたサービスアカウントでSPNを設定する
SPNは、SQL Serverサービスを実行している管理されたサービスアカウント ([CN=Managed Service Account]) で設定されます。

ケース4:フェールオーバークラスタのSPNを設定する
SQL Serverフェールオーバークラスタは、ドメインアカウントまたは管理されたサービスアカウントで実行できます。手順については、ケース2のドメインアカウントで実行されるSQL Serverの場合またはケース3の管理されたサービスアカウントで実行されるSQL Serverの場合を参照してください。SPNは、個々のSQLノードではなく、必ずSQLクラスタエンドポイントのFQDNに設定してください。

SPN参照
以下は、SPN設定に関するMicrosoftの公式文書へのリンクです。
SPNデバッグのヒント
SPNが正しく設定されていることを確認するには、コマンドラインツール
setspn
を使用して、登録済みのSPNエントリを検索します。コマンド構文は次のとおりです。setspn -T <Full_Domain_Name> -F -Q MSSQLSvc/<SQL_Server_Endpoint_FQDN>*
指定する項目は次のとおりです。
-
<Full_Domain_Name>
は、お使いの環境のドメイン名に置き換えます。 -
<SQL_Server_Endpoint_FQDN>
は、SQL ServerのFQDNに置き換えます。
たとえば、スタンドアロンのSQL Serverが
SQL2012.dslab.com
にあり、ドメインdslab.com
のローカル仮想アカウントで実行されているとします。次のコマンドを使用して、MSSQLSvc/SQL2012.dslab.com
というプレフィックスを持つすべての登録済みSPNを検索し、それが正しく設定されているかどうかを確認できます。
コマンドの結果から、SPNが、正しいLDAPパスおよびSQL Serverサービスを実行しているアカウントに、設定および登録されていることを確認できます。
手順3: krb5.confファイルを確認する (Linuxのみ)
LinuxにManagerをインストールする場合は、/etc/krb5.confが存在していることと、それに正しいドメインとレルムの情報が含まれていることを確認する必要があります。
-
Kerberosを設定するには、テキストエディタで/etc/krb5.confファイルを開くか作成します。
-
以下の情報を指定します。
[libdefaults] ... default_realm = <DOMAIN> ... [realms] <DOMAIN> = { kdc = <ACTIVE_DIRECTORY_CONTROLLER_FQDN> admin_server = <ACTIVE_DIRECTORY_CONTROLLER_FQDN> } [domain_realm] .<DOMAIN FQDN> = <DOMAIN> <DOMAIN FQDN> = <DOMAIN>
ここで、<DOMAIN>
、<ACTIVE_DIRECTORY_CONTROLLER_FQDN>
、および<DOMAIN_FQDN>
は、独自の値に置き換えます。サンプルファイル:[libdefaults] default_realm = EXAMPLE.COM default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc dns_lookup_kdc = true dns_lookup_realm = false [realms] EXAMPLE.COM = { kdc = kerberos.example.com kdc = kerberos-1.example.com admin_server = kerberos.example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM [logging] kdc = SYSLOG:INFO admin_server = FILE=/var/kadm5.log
-
ファイルを保存して、閉じます。
手順4: システム時計を確認する
ドメインコントローラ、SQL Server、およびDeep Security Managerコンピュータのシステム時計が同期していることを確認する必要があります。Kerberosでは、最大許容クロックスキューは、初期設定で5分です。
手順5: ファイアウォールを確認する
ファイアウォールがSQL接続をブロックしていないことを確認する必要があります。初期設定のSQL Serverインスタンスでは、ポート1433を介した接続が許可されますが、名前付きSQL
Serverインスタンスでは、ランダムに選択されたポートが使用されます。接続先のポートを見つけるために、SQLクライアント (この場合はDeep Security
Manager) は利用可能な名前付きインスタンスを検索し、SQL Serverブラウザサービスにルックアップ要求を発行して、マッピングポートを見つけます。SQL
Serverブラウザサービスは、ポート1434 (UDP) で実行されます。ファイアウォール設定で、ポート1433 (初期設定インスタンスを使用している場合)、または1434
(名前付きインスタンスを使用している場合) が許可されていることを確認してください。
手順6: dsm.propertiesファイルを確認します
dsm.properties
ファイルが正しく構成されていることを確認してください。-
テキストエディタでdsm.propertiesファイルを開きます。 Windowsでは、通常、ファイルは次の場所にあります。
C:\Program Files\Trend Micro\Deep Security Manager\webclient\webapps\ROOT\WEB-INF
。 -
ファイルに次の行が含まれていることを確認してください。
database.SqlServer.server=YOUR-SERVER.EXAMPLE.COM
//ドメイン名を含めます。ドメイン名には大文字を使用する必要があります。database.SqlServer.trustServerCertificate=true
//この行は、SQLサーバーが強制暗号化を有効にする場合に必要です。database.SqlServer.domain=EXAMPLE.COM
//ドメイン名は大文字を使用する必要があります。database.SqlServer.user=sqlUser@EXAMPLE.COM
//ユーザ名にはドメイン名を含める必要があり、ドメイン名には大文字を使用する必要があります。database.SqlServer.integratedSecurity=true
database.SqlServer.authenticationScheme=JavaKerberos
database.directory=null
database.SqlServer.namedPipe=false
-
必要な変更を加えてファイルを保存します。