SQL Server on Linux およびコンテナーに対する Active Directory 認証を理解する
適用対象: 
SQL Server - Linux
この記事では、Linux またはコンテナーにデプロイされた SQL Server に関する Active Directory 認証のしくみについて詳しく説明します。
概念
ライトウェイト ディレクトリ アクセス プロトコル (LDAP)
LDAP は、Active Directory などのさまざまなディレクトリ サービスを操作するためのアプリケーション プロトコルです。 ディレクトリ サービスによって、ユーザーやアカウントの情報や、パスワードなどのセキュリティ情報が格納されます。 その情報は暗号化された後、ネットワーク上の他のデバイスと共有されます。
LDAP をセキュリティで保護する方法の詳細については、「Windows Server で LDAP 署名を有効にする方法」を参照してください。
Kerberos
Kerberos は、ユーザーまたはホスト コンピューターの ID を確認するために使用される認証プロトコルです。 クライアントとサーバーを確認する 1 つの方法と考えることができます。
Windows と Windows 以外のサーバーとクライアントが存在する異種 (混在) 環境で作業する場合、Active Directory ベースのディレクトリ サービスを操作するために必要な 2 種類のファイルがあります。
- keytab ファイル ("キー テーブル" の略称)
- Kerberos 構成ファイル (
krb5.confまたはkrb5.ini)
keytab ファイルとは
Linux または Unix システム上のサーバー プロセスは、Windows サービス アカウントを使用してプロセスを実行するように構成することはできません。 Linux または Unix システムが起動時に Active Directory に自動的にログインするようにするには、keytab ファイルを使う必要があります。
keytab は、Kerberos で保護されるサービスと、キー配布センター (KDC) の関連付けられているサービス プリンシパル名の長期間の "キー" の表現を含む、暗号化ファイルです。 そのキーはパスワード自体ではありません。
keytab は、次のいずれかのために使用されます。
- ネットワーク上の別のサービスに対してサービス自体を認証する、または
- サービスに対して受信ディレクトリ ユーザーの Kerberos サービス チケットを暗号化解除する。
krb5.conf ファイルとは
/etc/krb5.conf ファイル (krb5.ini とも呼ばれます) は、Kerberos v5 (KRB5)、GNU Simple Authentication、Security Layer API (GSSAPI) ライブラリの構成入力を提供します。
この情報には、既定のドメイン、各ドメインのプロパティ (キー配布センターなど)、Kerberos チケットの既定の有効期間が含まれます。
このファイルは、Active Directory 認証を機能させるために必要です。 krb5.conf は INI ファイルですが、キーと値のペアの各値は、{ と } で囲んだサブグループにすることができます。
krb5.conf ファイルの詳細については、MIT Kerberos Consortium のドキュメントを参照してください。
SQL Server on Linux 用に Kerberos を構成する
これらは、SQL Server on Linux を実行するホスト サーバー上に必要な値です。 同じホスト上で他の (SQL Server 以外の) サービスを実行する場合は、krb5.conf ファイルに追加のエントリがいくつか必要になることがあります。
参照用に krb5.conf のサンプル ファイルを次に示します。
[libdefaults]
default_realm = CONTOSO.COM
[realms]
CONTOSO.COM = {
kdc = adVM.contoso.com
admin_server = adVM.contoso.com
default_domain = contoso.com
}
[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM
libdefaults-default_realm値が存在する必要があります。 この値によって、ホスト コンピューターが属しているドメインを指定します。realms(省略可能) - 領域ごとに、kdc値を設定して、Active Directory アカウントを検索するときにコンピューターが接続する必要があるキー配布センターを指定できます。 複数の KDC を設定した場合、各接続の KDC はラウンドロビンによって選択されます。domain_realm(省略可能) - 各領域のマッピングを指定できます。 指定しない場合、SQL Server on Linux では、ドメインcontoso.comは領域CONTOSO.COMにマップされると想定されます。
Kerberos 認証のプロセス
Windows での Kerberos 認証と同様に、Ticket Granting Ticket (TGT) を取得する最初の 2 つの手順は同じです。
クライアントが、(暗号化された) ユーザー名とパスワードをドメイン コントローラー (DC) に送信することで、ログイン プロセスを開始します。
内部ストレージに対してユーザー名とパスワードを確認した後、DC はそのユーザーの TGT をクライアントに返します。
SQL Server on Linux では、keytab ファイルを使ってサービス プリンシパル名 (SPN) のパスワードを読み取った後、暗号化された BLOB を暗号化解除し、これを使って接続を承認します。 次の手順では、このプロセスの概要を示します。
ユーザーが TGT を取得したら、クライアントは SQL Server インスタンスのホスト名とポートを指定して SQL Server への接続を開始します。
SQL クライアントは、
MSSQLSvc/<host>:<port>という形式のサービス プリンシパル名を内部的に作成します。 これは、ほとんどの SQL Server クライアントでハードコーディングされた形式です。クライアントは、その SPN の DC からセッション キーを要求することで、Kerberos ハンドシェイクを開始します。 TGT と SPN の両方が DC に送信されます。
- DC は、TGT と SPN を検証した後、SQL Server SPN に接続するためのセッション キーをクライアントに送信します。
- セッション キーから暗号化された BLOB がサーバーに送信されます。
SQL Server によって、SPN のパスワードがその keytab (
mssql.keytab) から読み取られます。これは、暗号化された (SPN、パスワード) のタプルを含むディスク上のファイルです。SQL Server によって、クライアントからの暗号化された BLOB が、検索したパスワードを使用して暗号化解除され、クライアントのユーザー名が取得されます。
SQL Server によって、
sys.sysloginsテーブルでクライアントが検索され、そのクライアントが接続を許可されているかどうかがチェックされます。接続は承認されるか、拒否されます。
SQL Server コンテナー用に Kerberos を構成する
SQL Server のコンテナーでの Active Directory 認証は、SQL Server on Linux と本質的に同じです。 唯一の違いは、SQL Server ホスト SPN です。 前のシナリオでは、SQL Server ホストの名前を使用して接続したため、SPN は MSSQLSvc/<host>:<port> でした。 しかし、今回は、コンテナーに接続する必要があります。
SQL Server コンテナーの場合は、コンテナー内に krb5.conf ファイルを作成できます。 コンテナーを実行しているホスト ノードはドメインに属している必要はありませんが、コンテナーが接続しようとしているドメイン コントローラーにアクセスできる必要があります。
コンテナーに接続するため、クライアント接続のサーバー名は単なるホスト名とは異なる場合があります。 ホスト名、コンテナー名、または他の別名である場合があります。 また、SQL Server の公開されたポートが既定の 1433 ではない可能性が高くなります。
SQL Server コンテナーに接続するには、mssql.keytab に格納されている SPN を使用する必要があります。 たとえば、mssql.keytab の SPN が MSSQLSvc/sqlcontainer.domain.com:8000 である場合、クライアントの接続文字列として sqlcontainer.domain.com,8000 を使用します (sqlcmd、SQL Server Management Studio、Azure Data Studio を含む)。
SQL Server のグループ更新
認証にサービス プリンシパル名のみが必要な場合に、なぜ keytab にユーザー アカウントがあるか疑問に思われるかもしれません。
たとえば、グループ adGroup のメンバーであるユーザー adUser がいるとします。 adGroup が SQL Server にログインとして追加される場合、それは adUser も SQL Server インスタンスにサインインするアクセス許可を持つことを意味します。 adUser がまだ SQL Server に接続されている間に、ドメイン管理者が adGroup から adUser を削除するかもしれません。 現在、adUser は SQL Server にサインインするアクセス許可を持つべきではありませんが、既に Kerberos 認証プロセスを通過し、接続されています。
私たちは、"グループ更新" と呼ばれるプロセスを定期的に実行して、接続されたユーザーが特権アクション (ログインの作成やデータベースの変更など) の実行を許可されなくなったというシナリオから保護します。
SQL Server には、グループの更新に使われる特権付きの Active Directory アカウントがあります。 このアカウントは、mssql-conf を使って network.privilegedadaccount 設定を使用して構成されるか、既定でホスト コンピューターのコンピューター アカウント (<hostname>$) に設定されます。
mssql.keytab の特権アカウントの資格情報は、クライアントを偽装するために使用されます (この例では adUser)。 SQL Server はそれ自体と Kerberos ハンドシェイクを実行してグループ メンバーシップ情報を特定し、それを sys.syslogins と比較して、adUser が、接続して要求された Transact-SQL コマンドを実行するために必要なアクセス許可をまだ持っているかどうかを確認します。 adUser が adGroup から削除されていた場合、接続は SQL Server によって終了されます。
グループの更新には、次の 2 つの条件が必要です。
- SQL Server インスタンスとオンプレミスの Active Directory ドメインの間のネットワーク接続。
- SQL Server の接続先ドメインとオンプレミスの Active Directory ドメインの間の双方向の信頼。 詳しくは、「Active Directory について」をご覧ください。