本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。
本ヘルプセンターの一部の記事には外部リンクが含まれています。万一リンク切れなどお気づきの点がございましたら、お手数ですが弊社サポート窓口までご連絡ください。
SQL Serverドメイン認証の問題
Deep Security Managerのインストール時にSQL Serverデータベースへの接続の問題が発生した場合は、以下の手順に従って問題をトラブルシューティングしてください。
このトピックで扱う範囲は、Windowsドメイン認証の問題に限定されています。SQL Server認証を使用している場合は、「Deep Security Managerで使用するデータベースの準備 」を参照し、そのトピックに記載されている設定手順を確認して問題をトラブルシューティングします。
「Windowsドメイン認証」は、さまざまな名前で呼ばれます。Kerberos認証、ドメイン認証、Windows認証、統合認証などです。このトピックでは、「Kerberos」および「Windowsドメイン認証」という用語を使用しています。
手順2: servicePrincipalName (SPN) を確認する
手順3: krb5.confファイルを確認する (Linuxのみ)
手順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認証が使用されます。詳細については、「Microsoft 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) を特定する
手順2b: Active Directoryでアカウントを確認する
手順2d: 初期設定のインスタンスを使用しているのか、名前付きインスタンスを使用しているのかを特定する
手順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=Computer CN=<コンピュータ名> | 仮想アカウントで実行されるサービスは、コンピュータアカウントの資格情報を使用してネットワークリソースにアクセスします。初期設定のスタンドアロンSQL Serverサービスは、このアカウントを使用して起動されます。 |
| ドメインアカウント | ドメインユーザ名 (例：SQLServerServiceUser) | CN=Users CN=<ユーザ名> | このアカウントを使用して開始されたサービスは、ドメインユーザの資格情報を使用してネットワークリソースにアクセスします。SQL Serverフェールオーバークラスタでは、サービスを実行するためにドメインアカウントが必要です。スタンドアロンSQL Serverサービスは、起動にドメインアカウントを使用するように設定することもできます。 |
| 管理されたサービスアカウント | 管理されたサービス アカウント (MSA) 名 (例：SQLServerMSA) | CN=Managed Service Account CN=<アカウント名> | 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ページを参照してください。
例1: 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 Serverホストを見つけます。
- SQL Serverホストを右クリックし、[プロパティ] を選択します。
- [属性エディター] タブで、[servicePrincipalName] までスクロールし、[編集] ボタンをクリックします。
- 属性値が存在しない場合は、[追加] ボタンを使用して個別に追加します。[OK] をクリックします。
ケース2:ドメインアカウントでSPNを設定する
SQL Serverサービスを実行しているドメインアカウント (CN=Users) でSPNが設定されることを除き、SPN設定はローカル仮想アカウント設定と似ています。
ケース3:管理されたサービスアカウントでSPNを設定する
SPNは、SQL Serverサービスを実行している管理されたサービスアカウント (CN=Managed Service Account) で設定されます。
ケース4:フェールオーバークラスタのSPNを設定する
SQL Serverフェールオーバークラスタは、ドメインアカウントまたは管理されたサービスアカウントで実行できます。手順については、ケース2:ドメインアカウントでSPNを設定するまたはケース3:管理されたサービスアカウントでSPNを設定するを参照してください。SPNは、個々のSQLノードではなく、必ずSQL「クラスタ」エンドポイントのFQDNに設定してください。
SPNリファレンス
以下は、SPN設定に関するMicrosoftの公式文書へのリンクです。
SQL Server フェールオーバークラスタでKerberos認証を有効にする方法
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 (名前付きインスタンスを使用している場合) が許可されていることを確認してください。