LDAP署名とLDAPチャネルバインディングの既定有効化
2020 年 3 月のアップデートにより『LDAP 署名』と『LDAPチャネルバインディング』が既定で有効化となることがマイクロソフトからアナウンスされています。
既定 (デフォルト設定) で有効化なので、アップデート後は明示的に無効化すれば影響はなさそうですが、そのやり方についてはこの記事では触れません。
この 2 つがそもそも何者なのかについて調べてみました。
前提知識
SASL と GSS-API が出てきます。
LDAP 署名とは？
LDAP 署名 (LDAP Signing) とは、マイクロソフトの表現ではありますが、具体的には SASL (RFC 4422) という『通信プロトコルにおける認証とセキュリティのための汎用的なレイヤーを提供するフレームワーク』で定められている [Integrity] を確認する機能です。SASL のレイヤーでパケットの改竄を検知します。
SASL が動作するレイヤーは、イメージ的には TCP と LDAP の間と考えると分かり易いでしょう。
The security of a directory server can be significantly improved by configuring the server to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not request signing (integrity verification) or to reject LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. SASLs may include protocols such as the Negotiate, Kerberos, NTLM, and Digest protocols.
SASL では機能として以下の 3 つを提供します。
- 認証 (Authentication)
- 機密性 (Confidentiality)
- 完全性 (Integrity)
これらの機能をプラグインとして用意していますが、具体的なメカニズムは SASL では定められていません。
SASL で利用できるメカニズムは IANA が管理しており、下記ページで確認できます。
また、利用できるメカニズムは前述の 3 つの機能すべてを満たしている必要はありません。
Active Directory の SASL 実装では現状の既定値では『認証』の要素のみが使われていますが、LDAP 署名を有効化した場合は『完全性』の要素も使うようになります。
なので、Active Directory のドメインコントローラに内蔵する LDAP サーバを LDAP 署名付きで使うためには、LDAP クライアント側のアプリケーションでは "Simple BIND" に設定していては NG です。
『認証』だけでなく『完全性』の機能をサポートした "SASL BIND" にする必要があります。
例えば AD の LDAP ツリーを一覧表示できる『Apache Directory Studio』では"DIGEST-MD5" と "SASL-GSSAPI" が Integrity に対応しています。
The DIGEST-MD5 and GSSAPI SASL mechanisms can provide message integrity and, optionally, message confidentiality by "wrapping" or "unwrapping" data with a security layer.
LDAP チャネルバインディングとは
チャネルバインディングは GSS-API というフレームワークで使われる言葉です。
GSS-API では『認証』に関する抽象的なシーケンスを定めています。フレームワークであるため、具体的な実装が必要です。有名な実装は SPNEGO です。
(なお、 SASL のメカニズムとして GSSAPI という選択肢が存在しますが、これは Kerberos/SPNEGO での実装を意味します。)
Kerberos/NTLM の SSO (シングルサインオン) は、それはとても便利なものですが、SSO に使われる「チケット」なり「トークン」というのは、それさえ持っていれば誰でもそのチケット/トークンで許可されたアクセスができてしまう、という大きなリスクを抱えています。
今回のケースに照らして言うと、例えば Kerberos チケットの所有者は Kerberos SSO で AD ドメインコントローラの LDAP 検索などが出来てしまいますが、Kerberos チケットが外部に漏洩するような脆弱性が見つかった場合、そのユーザがそのチケットを不正利用されてしまいます。
ですが、今回の LDAP チャネルバインディングを使えば、TLS コネクションでユーザを識別できるようになり、Kerberos チケットユーザと紐付けができるようになります。
つまり、TLS コネクションと Kerberos/NTLM ユーザを紐付け、チケット/トークンの不正利用者のアクセスを拒否することができます。
Active Directory における LDAP チャネルバインディングの具体的な実装は、CBT というトークンを使うもののようです。これは RFC には明確な記載は見当たりません。
一方で、マイクロソフトで以下のサイトが見つかりました。
What is CBT (Channel Binding Token)?
Channel Binding Token (CBT) is a part of Extended Protection for Authentication. CBT is a mechanism to bind an outer TLS secure channel to inner channel authentication such as Kerberos or NTLM.CBT is a property of the outer secure channel used to bind authentication to the channel.
TLS コネクションを、Kerberos や NTLM の認証情報と紐付けるためのトークンのようです。
また、以下のサイトでは『CBT はプロパティであり、RFC 5056 に定められた通りになっている』としています。
A CBT is a property of the outer secure channel (such as TLS) used to tie (bind) it to a conversation over an inner, client-authenticated channel. The CBT must have the following properties (also defined by IETF RFC 5056):
チャネルバインディングを定めている RFC 5056 の Section 2.1 には似たような記載があるため、おそらくこのことを言っていると思われます。
【厳選 3 冊】Windows を学ぶための本
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント