Active Directory モードで SQL Server ビッグデータクラスターを展開する

[アーティクル]
03/21/2023

この記事では、Active Directory モードで SQL Server ビッグデータクラスターを展開する方法について説明します。この記事の手順では、Active Directory ドメインへのアクセスが必要です。作業を進める前に、「Active Directory モードで SQL Server ビッグデータクラスターをデプロイする」で説明されている要件を完了する必要があります。

重要

Microsoft SQL Server 2019 ビッグデータクラスターのアドオンは廃止されます。 SQL Server 2019 ビッグデータクラスターのサポートは、2025 年 2 月 28 日に終了します。ソフトウェアアシュアランス付きの SQL Server 2019 を使用する既存の全ユーザーはプラットフォームで完全にサポートされ、ソフトウェアはその時点まで SQL Server の累積更新プログラムによって引き続きメンテナンスされます。詳細については、お知らせのブログ記事と「Microsoft SQL Server プラットフォームのビッグデータオプション」を参照してください。

展開の準備

AD 統合でビッグデータクラスターを展開するためには、AD でビッグデータクラスター関連のオブジェクトを作成するために必要な情報をいくつか追加します。

kubeadm-prod プロファイル (または CU5 リリース以降の openshift-prod) を利用することで、AD 統合に必要なセキュリティ関連の情報とエンドポイント関連の情報のプレースホルダーが自動的に作成されます。

さらに、AD で必要なオブジェクトを作成するためにビッグデータクラスターで使用される資格情報を提供する必要があります。これらの資格情報は環境変数として提供されます。

トラフィックとポート

ファイアウォールまたはサードパーティのアプリケーションによって、Active Directory の通信に必要なポートが許可されていることを確認します。

ビッグデータクラスターと Active Directory の間のトラフィック図。コントローラー、セキュリティサポートサービス、その他のクラスターサービスは、LDAP/Kerberos を使ってドメインコントローラーと通信します。ビッグデータクラスターの DNS プロキシサービスは、DNS 経由で DNS サーバーと通信します。

Active Directory ドメインへの要求は、Kubernetes クラスターサービスとのやり取りに使用されるこれらのプロトコルで行われるため、TCP と UDP の両方に必要なポートをリッスンしているファイアウォールまたはサードパーティのアプリケーションで、受信と送信が許可されている必要があります。 Active Directory で使用される標準のポート番号は次のとおりです。

サービス	Port
DNS	53
LDAP LDAPS	389 636
Kerberos	88
Kerberos/AD パスワード変更プロトコル	464
グローバルカタログポート LDAP 経由 LDAPS 経由	3268 3269

セキュリティ環境変数の設定

次の環境変数からは、ビッグデータクラスタードメインサービスアカウントの資格情報が与えられます。この情報が AD 統合の設定に使用されます。このアカウントはまた、この先、ビッグデータクラスター関連の AD オブジェクトを維持する目的でビッグデータクラスターによって使用されます。

export DOMAIN_SERVICE_ACCOUNT_USERNAME=<AD principal account name>
export DOMAIN_SERVICE_ACCOUNT_PASSWORD=<AD principal password>

セキュリティとエンドポイントのパラメーターを指定する

資格情報の環境変数に加えて、AD 統合が機能するためのセキュリティとエンドポイントの情報も提供する必要があります。必要なパラメーターは、自動的に kubeadm-prod/openshift-prod デプロイプロファイルに含まれます。

AD 統合には次のパラメーターが必要です: この記事の後半に出てくる config replace コマンドを使用し、control.json ファイルと bdc.json ファイルにこれらのパラメーターを追加します。下の例ではすべて、サンプルドメイン contoso.local が使用されています。

security.activeDirectory.ouDistinguishedName: クラスターにより作成されたあらゆる AD アカウントが追加される組織単位 (OU) の識別名。ドメインの名前が contoso.local の場合、OU の識別名は OU=BDC,DC=contoso,DC=local です。
security.activeDirectory.dnsIpAddresses: ドメインの DNS サーバーの IP アドレスのリストが含まれます。
security.activeDirectory.domainControllerFullyQualifiedDns:ドメインコントローラーの FQDN の一覧。 FQDN には、ドメインコントローラーのコンピューター名またはホスト名が含まれています。複数のドメインコントローラーがある場合、ここで一覧を指定できます。例: HOSTNAME.CONTOSO.LOCAL.

重要

複数のドメインコントローラーがドメインにサービスを提供している場合は、セキュリティ構成の domainControllerFullyQualifiedDns 一覧の最初のエントリとして、プライマリドメインコントローラー (PDC) を使用します。PDC 名を取得するには、コマンドプロンプトで「netdom query fsmo」と入力し、Enter キーを押します。
security.activeDirectory.realm省略可能なパラメーター: ほとんどの場合、領域はドメイン名と同じです。同じでない場合は、このパラメーターを使用して、領域の名前を定義します (例: CONTOSO.LOCAL)。このパラメーターに指定する値は、完全修飾されている必要があります。
security.activeDirectory.netbiosDomainName 省略可能なパラメーター: これは、AD ドメインの NETBIOS 名です。ほとんどの場合、これは AD ドメイン名の最初のラベルになります。異なる場合は、このパラメーターを使用して NETBIOS ドメイン名を定義します。この値にドットを含めることはできません。通常、この名前は、ドメイン内のユーザーアカウントを修飾するために使用されます。たとえば、CONTOSO\user では、CONTOSO が NETBIOS ドメイン名です。

注意

security.activeDirectory.netbiosDomainName を使用している Active Directory ドメインの NETBIOS 名と Active Directory ドメイン名が異なる場合の構成のサポートは、SQL Server 2019 CU9 以降で有効になっています。
security.activeDirectory.domainDnsName: クラスターに使用される DNS ドメインの名前 (例: contoso.local)。
security.activeDirectory.clusterAdmins:このパラメーターは、1 つの AD グループを受け取ります。 AD グループのスコープは、ユニバーサルまたはグローバルである必要があります。このグループのメンバーには、クラスターの管理者アクセス許可を付与する bdcAdmin クラスターロールが割り当てられます。これは、SQL Server で sysadmin アクセス許可、HDFS で superuser アクセス許可、コントローラーエンドポイントに接続したときに管理者アクセス許可が与えられることを意味します。

重要

展開を開始する前に、このグループを AD 内に作成します。この AD グループのスコープがドメインローカルの場合、展開は失敗します。
security.activeDirectory.clusterUsers:ビッグデータクラスター内で通常のユーザー (管理者権限なし) となる AD グループの一覧。この一覧には、ユニバーサルグループまたはグローバルグループのいずれかのスコープを持つ AD グループを含めることができます。ドメインローカルグループを含めることはできません。

この一覧の AD グループは、bdcUser ビッグデータクラスターロールにマップされており、SQL Server (SQL Server アクセス許可を参照) または HDFS (HDFS アクセス許可ガイドを参照) へのアクセスが許可される必要があります。コントローラーエンドポイントに接続されている場合、これらのユーザーは azdata bdc endpoint list コマンドを使用して、クラスターで使用可能なエンドポイントのみを一覧表示できます。

これらの設定の AD グループを更新する方法の詳細については、「Active Directory モードでビッグデータクラスターアクセスを管理する」を参照してください。

ヒント

HDFS に接続するために必要な Knox ゲートウェイエンドポイントを取得するために、Azure Data Studio では sys.dm_cluster_endpoints DMV を使用しています。そのため、Azure Data Studio で SQL Server マスターに接続したときの HDFS ブラウジングエクスペリエンスを有効にするには、bdcUser ロールを持つユーザーに VIEW SERVER STATE 権限を付与する必要があります。

重要

展開を開始する前に、これらのグループを AD 内に作成します。これらの AD グループのいずれかのスコープがドメインローカルの場合、展開は失敗します。

重要

ドメインユーザーが多数のグループメンバーシップを所有している場合は、カスタム bdc.json デプロイ構成ファイルを使用して、ゲートウェイ設定 httpserver.requestHeaderBuffer (既定値は 8192) と HDFS 設定 hadoop.security.group.mapping.ldap.search.group.hierarchy.levels (既定値は 10) の値を調整する必要があります。これは、ゲートウェイへの接続タイムアウトや 431 (Request Header Fields Too Large) 状態コードの HTTP 応答を回避するためのベストプラクティスです。以下は、これらの設定の値を定義する方法と、グループメンバーシップの数が多い場合に推奨される値を示す構成ファイルのセクションです。

{
    ...
    "spec": {
        "resources": {
            ...
            "gateway": {
                "spec": {
                    "replicas": 1,
                    "endpoints": [{...}],
                    "settings": {
                        "gateway-site.gateway.httpserver.requestHeaderBuffer": "65536"
                    }
                }
            },
            ...
        },
        "services": {
            ...
            "hdfs": {
                "resources": [...],
                "settings": {
                  "core-site.hadoop.security.group.mapping.ldap.search.group.hierarchy.levels": "4"
                }
            },
            ...
        }
    }
}

security.activeDirectory.enableAES Optional parameter 省略可能なパラメーター: 自動的に生成された AD アカウントで AES 128 と AES 256 を有効にする必要があるかどうかを示すブール値。既定値は false です。このパラメーターが true に設定されている場合、ビッグデータクラスターの展開中に自動生成された AD オブジェクトに対して、次のフラグ: [このアカウントで Kerberos AES 128 ビット暗号化をサポートする] と [このアカウントで Kerberos AES 256 ビット暗号化をサポートする] がオンになります。

注意

パラメーター security.activeDirectory.enableAES は、SQL Server ビッグデータクラスター CU13 以降で使用できます。 CU13 より前のバージョンのビッグデータクラスターの場合は、次の手順を実行する必要があります。

azdata bdc rotate -n <your-cluster-name> コマンドを実行します。このコマンドによって、keytab の AES エントリが正しいことを確認するために必要なクラスター内の keytab をローテーションします。詳細については、「azdata bdc」を参照してください。さらに、azdata bdc rotate によって、指定された OU での初期展開中に自動生成された AD オブジェクトのパスワードをローテーションします。
ビッグデータクラスターの初期展開中に指定した OU に自動生成された各 AD オブジェクトに対して、次のフラグ: [このアカウントで Kerberos AES 128 ビット暗号化をサポートする] と [このアカウントで Kerberos AES 256 ビット暗号化をサポートする] を設定します。これを実現するには、ドメインコントローラーで次の PowerShell スクリプト Get-ADUser -Filter * -SearchBase '<OU Path>' | Set-ADUser -replace @{ 'msDS-SupportedEncryptionTypes' = '24' } を実行します。これにより、<OU Path> パラメーターで指定された OU 内の各アカウントの AES フィールドが設定されます。

重要

展開を開始する前に、AD で下記の設定に提供されるグループを作成します。これらの AD グループのいずれかのスコープがドメインローカルの場合、展開は失敗します。

security.activeDirectory.appOwners 省略可能なパラメーター: あらゆるアプリケーションを作成、削除、実行するアクセス許可が与えられる AD グループのリスト。この一覧には、ユニバーサルグループまたはグローバルグループのいずれかのスコープを持つ AD グループを含めることができます。ドメインローカルグループを含めることはできません。
security.activeDirectory.appReaders 省略可能なパラメーター: あらゆるアプリケーションを実行するアクセス許可が与えられる AD グループのリスト。この一覧には、ユニバーサルグループまたはグローバルグループのいずれかのスコープを持つ AD グループを含めることができます。ドメインローカルグループを含めることはできません。

次の表に、アプリケーション管理用の承認モデルを示します。

承認済みロール	Azure Data CLI (`azdata`) コマンド
appOwner	azdata app create
appOwner	azdata app update
appOwner、appReader	azdata app list
appOwner、appReader	azdata app describe
appOwner	azdata app delete
appOwner、appReader	azdata app run

security.activeDirectory.subdomain:省略可能なパラメーター このパラメーターは、同じドメインに対する複数のビッグデータクラスターのデプロイをサポートするために SQL Server 2019 CU5 リリースで導入されました。この設定を使用すると、デプロイされたビッグデータクラスターごとに異なる DNS 名を指定できます。このパラメーターの値が control.json ファイルの Active Directory セクションに指定されていない場合、既定で、ビッグデータクラスター名 (Kubernetes 名前空間名と同じ) がサブドメイン設定の値を計算するために使用されます。

注意

サブドメイン設定を介して渡される値は、新しい AD ドメインではなく、ビッグデータクラスターによって内部で使用される DNS ドメインだけです。

重要

これらの新機能を活用し、同じドメイン内に複数のビッグデータクラスターをデプロイするには、SQL Server 2019 CU5 リリース以降の Azure Data CLI (azdata) の最新バージョンをインストールまたはアップグレードする必要があります。

同じ Active Directory ドメインに複数のビッグデータクラスターをデプロイすることに関する詳細については、「概念」の Active Directory モードで SQL Server ビッグデータクラスターをデプロイする方法に関するページを参照してください。
security.activeDirectory.accountPrefix:省略可能なパラメーター このパラメーターは、同じドメインに対する複数のビッグデータクラスターのデプロイをサポートするために SQL Server 2019 CU5 リリースで導入されました。この設定により、さまざまなビッグデータクラスターサービスに対してアカウント名の一意性が保証されます。それは 2 つのクラスター間で異なる必要があります。アカウントプレフィックス名のカスタマイズは省略可能で、既定では、サブドメイン名がアカウントプレフィックスとして使用されます。サブドメイン名が 12 文字より長い場合、サブドメイン名の最初の 12 文字がアカウントプレフィックスとして使用されます。

注意

Active Directory では、アカウント名を 20 文字までに制限する必要があります。ビッグデータクラスターでは、ポッドと StatefulSet を区別するために、8 文字を使用する必要があります。これにより、アカウントプレフィックスの制限として 12 文字が残されます

AD グループのスコープを確認し、DomainLocal であるかどうかを確認します。

展開構成ファイルをまだ初期化していない場合、このコマンドを実行して構成のコピーを取得できます。次の例では、kubeadm-prod プロファイルを使用します。これは openshift-prod にも当てはまります。

azdata bdc config init --source kubeadm-prod  --target custom-prod-kubeadm

control.json ファイルで上記のパラメーターを設定するには、次の Azure Data CLI (azdata) コマンドを使用します。これらのコマンドによって展開前に構成が置換され、独自の値が提供されます。

重要

SQL Server 2019 CU2 リリースでは、展開プロファイルのセキュリティ構成セクションの構造が多少変更され、Active Directory 関連の設定はすべて、control.json ファイル内の security の下にある json ツリー内の新しい activeDirectory 内にあります。

注意

このセクションで説明されているように、サブドメインに異なる値を指定するだけでなく、同じ Kubernetes クラスターに複数のビッグデータクラスターをデプロイする場合は、ビッグデータクラスターエンドポイントに異なるポート番号を使用する必要もあります。これらのポート番号は、デプロイ時にデプロイ構成プロファイルを使用して構成できます。

次の例は、SQL Server 2019 CU2 の使用に基づいています。この例は、展開構成内の AD 関連のパラメーター値を置き換える方法を示しています。下のドメインの詳細はサンプルの値です。

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

必要に応じて SQL Server 2019 CU5 リリースを起動するだけで、subdomain と accountPrefix の設定の既定値をオーバーライドできます。

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.subdomain=[\"bdctest\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.accountPrefix=[\"bdctest\"]"

同様に、SQL Server 2019 CU2 以前のリリースでは、次のことを実行できます。

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

上記の情報に加え、さまざまなクラスターエンドポイントの DNS 名を指定する必要もあります。指定した DNS 名を使用する DNS エントリは、展開時に DNS サーバーで自動的に作成されます。これらの名前は、さまざまなクラスターエンドポイントに接続するときに使用します。たとえば、SQL マスターインスタンスの DNS 名が mastersql で、サブドメインで control.json にクラスター名の既定値を使用することを考えている場合は、mastersql.contoso.local,31433 または mastersql.mssql-cluster.contoso.local,31433 (デプロイ構成ファイルでエンドポイント DNS 名に対して指定した値によって異なります) を使用して、ツールからマスターインスタンスに接続します。

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[1].dnsName=<monitoring services DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[0].dnsName=<SQL Master Primary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[1].dnsName=<SQL Master Secondary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.gateway.spec.endpoints[0].dnsName=<Gateway (Knox) DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.appproxy.spec.endpoints[0].dnsName=<app proxy DNS name>.<Domain name. e.g. contoso.local>"

重要

任意のエンドポイント DNS 名を使用できます。ただし、これらが完全に修飾されており、同じドメインにデプロイされた任意の 2 つのビッグデータクラスター間で競合しない場合に限ります。必要に応じて、subdomain パラメーター値を使用して、クラスター間で確実に DNS 名が異なるようにすることができます。次に例を示します。

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.<subdomain e.g. mssql-cluster>.contoso.local"

AD 統合を利用し、単一ノード Kubernetes クラスター (kubeadm) で SQL Server ビッグデータクラスターを展開するサンプルスクリプトはこちらにあります。

注意

新しく導入された subdomain パラメーターに対応できないシナリオもあります。たとえば、CU5 より前のリリースをデプロイする必要があり、Azure Data CLI (azdata) がアップグレード済みである場合です。これは非常にまれですが、CU5 より前の動作に戻す必要がある場合は、control.json の Active Directory セクションで useSubdomain パラメーターを false に設定できます。これを実行するコマンドを次に示します。

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.useSubdomain=false"

これで、Active Directory 統合を使用し、ビッグデータクラスターの展開に必要なパラメーターをすべて設定できたはずです。

Azure Data CLI (azdata) コマンドと kubeadm-prod デプロイプロファイルを使用して、Active Directory と統合されたビッグデータクラスターをデプロイできるようになりました。ビッグデータクラスターをデプロイする方法の完全なドキュメントについては、「Kubernetes 上に SQL Server ビッグデータクラスターをデプロイする方法」を参照してください。

ドメインコントローラーの逆引き DNS エントリを確認する

ドメインコントローラー自体の逆引き DNS エントリ (PTR レコード) が DNS サーバーに登録されていることを確認します。これは、ドメインコントローラーの IP アドレスに対して nslookup を実行して、それがドメインコントローラーの FQDN に解決されるかを調べることで確認できます。

既知の問題と制限事項

SQL Server 2019 CU5 で注意すべき制限事項

現在のところ、ログ検索ダッシュボードとメトリクスダッシュボードは AD 認証に対応していません。展開時に設定される基本ユーザー名とパスワードは、これらのダッシュボードに対する認証に使用することができます。他のすべてのクラスターエンドポイントは、AD 認証に対応しています。
セキュア AD モードは現在のところ、kubeadm および openshift デプロイ環境でのみ動作し、AKS または ARO では動作しません。 kubeadm-prod および openshift-prod デプロイプロファイルには既定で、セキュリティセクションが含まれています。
SQL Server 2019 CU5 リリースより前は、ドメイン (Active Directory) につきビッグデータクラスターが 1 つしか許可されません。 CU5 リリース以降では、ドメインごとに複数のビッグデータクラスターを有効にすることができます。
セキュリティ構成で指定されているどの AD グループも、DomainLocal にスコープ指定できません。 AD グループのスコープは、この手順に従って確認できます。
ビッグデータクラスターへのログインに使用できる AD アカウントは、SQL Server ビッグデータクラスター用に構成されたのと同じドメインから許可されます。その他の信頼される側のドメインからのログインを有効にすることはサポートされていません。

次のステップ

SQL Server ビッグデータクラスターSQL Server ビッグデータクラスターを接続する: Active Directory モード

SQL Server ビッグデータクラスターの Active Directory 統合のトラブルシューティング

概念: Active Directory モードで SQL Server ビッグデータクラスターをデプロイする

次の方法で共有

Active Directory モードで SQL Server ビッグデータクラスターを展開する

展開の準備

トラフィックとポート

セキュリティ環境変数の設定

セキュリティとエンドポイントのパラメーターを指定する

ドメインコントローラーの逆引き DNS エントリを確認する

既知の問題と制限事項

次のステップ

フィードバック

その他のリソース

次の方法で共有

Active Directory モードで SQL Server ビッグ データ クラスターを展開する

展開の準備

トラフィックとポート

セキュリティ環境変数の設定

セキュリティとエンドポイントのパラメーターを指定する

ドメイン コントローラーの逆引き DNS エントリを確認する

既知の問題と制限事項

次のステップ

フィードバック

その他のリソース

Active Directory モードで SQL Server ビッグデータクラスターを展開する

ドメインコントローラーの逆引き DNS エントリを確認する