はじめに

MSより2020 年初頭の Windowsアップデート(1/19確認時点では3月予定)に「LDAP 署名有効化」「LDAP チャネルバインディング （LDAPS 利用時）化」になるようです。

Windows の 2020 年 LDAP 署名と LDAP チャネル バインディングの要件
[AD管理者向け] 2020 年 LDAP 署名と LDAP チャネルバインディングが有効化。確認を！

これを見てみたんですけど、はっきり言ってよく分からん
ただ、影響範囲はでかそうな割に確かな情報がないので、検証しつつどのような対応が必要になるのかを書いていきます。

※認識違う部分ありましたらコメント頂ければとおもいます。

アップデートの内容について

今後はLDAP通信はセキュリティ的にあれなので、LDAP署名を有効化しましょうというのが主旨です。

LDAP 署名とは

そもそも「LDAP署名」とは何か？
これは単純にLDAPS通信(636)のことでしょ。

と思っていたら、よく調べてみると厳密には違いました。

こちらに以下のような記載を発見。

署名が必要な場合、SSL を使用していない LDAP 簡易バインドは拒否されます (LDAP TCP/389)。

LDAP(AD)の認証にはいくつか種類があります。
・匿名(anonymous)認証
　⇒匿名による認証
　　クライアントは特に認証を必要とすることなく，LDAPの各エントリにアクセスできるようになる。

・簡易認証(simple bind)
　 ⇒平文パスワードによる単純な認証

・SASL認証(SASL bind)
　 ⇒ざっくりいうとセキュリティの高い認証方式。詳細は参照
https://www.ipa.go.jp/security/rfc/RFC2222JA.html

・DIGEST-MD5方式
　⇒パスワードから，元の文字を推測できない（ハッシュで変換）"チャレンジ"と呼ばれるワンタイムレベルの文字列を送り，それに応答する"レスポンス"を使って行なわれる認証
　　データは暗号化されていないが、パスワードは盗聴されない。

・kerberos認証
　⇒Kerberos v5に準拠した，Active Directory標準の認証プロトコル
　　KDCと呼ばれる認証機関から認証チケットを得ることで，チケットが有効な間，認証されたサービスにアクセスできるようになる。

つまり、TCP/389を使用した簡易認証方式は今後拒否される、が正しい理解のようです。

LDAP チャネルバインディングとは

とりあえず調べてみた

チャネルバインディングとは、GSS-APIと呼ばれる認証のフレームワークの中で出てくる用語です。

なんのこっちゃ？

調べてみる、ADにはSPNEGO(読み方:スプネゴ) というSSOに使用されている仕組みがあり、そこでGSS-APIが用いられているようです。

話を戻すと、チャネルバインディングとは使用されている特定のデータチャネルを識別するためのタグのことです。
具体的には、チャネルバインディングは起動側と受け入れ側)を識別します。
これらのタグは起動側と受け入れ側のアプリケーションに固有であるため、識別情報のより有効な証明となります。

でチャネルバインディングトークン(CBT)と呼ばれるものはMSが独自にGSS-APIの仕組みを用いて開発したもののようです。

具体例をみてみる。

MSの以下サイトを参考にします。
認証の拡張保護の概要

HTTPSに置き換えて説明します。(LDAPS通信でも基本的には同様です。)
以下の登場人物がいるパターン
・クライアント
・サーバー
・攻撃者

攻撃者はあたかも自分がサーバーであるかのように見せて、
本来であれば
クライアント⇒サーバー　となる接続を
クライアント⇒攻撃者⇒サーバー　へ変えてしまいます。

そうなると、SSLチャネルは2つ作成されます。
・クライアントと攻撃者間
・攻撃者とサーバー間

そうすると、資格情報はクライアントから攻撃者にわたり
攻撃者からサーバーへ渡っていくので、サーバーから見たら正しい資格情報が送信された、としかみなさないため
通信が許可されてしまいます。

それを防ぐためにチャネルバインディングトークン(CBT)という仕組みがあります。
ざっくりいうと、CBTはTLSのチャネルのプロパティに認証情報的なものを保持していて
チャネルの送信先によって特定されます。
つまりクライアントと攻撃者のCBT、攻撃者とクライアント間のCBTは異なるため
サーバー側でCBTを比較して、攻撃を検知することができます。

今回の内容でいえば、LDAPS通信だけでは攻撃を防ぐことはできないので
CBTも有効にしましょう、というのがMSの考え方なのだと思われます。

結局どういうこと？

今回のアップデートに関しては、以下のようになります。
・LDAP署名の有効化(簡易認証のLDAP通信は使えないよ)
・LDAPチャネルバインディングの有効化(LDAPS通信にはCBTを使うよ)

なので、このアップデートを適用すると
・簡易認証方式におけるLDAP通信はできなくなる
・LDAPS通信の際に、クライアントがCBTに適応していない場合、通信が拒否される。

クライアントの影響は？

大きく分けてクライアントは以下の2つがあると思います。
・ドメインユーザー
・サードパーティー製品によるAD参照

まずドメインユーザーについてですが、ドメインユーザーがADに認証を行う際にはkerberos認証を使っています。
この場合、ldapのバインドはセキュリティ保護されているため今回のLDAP署名云々には引っ掛かりません。

問題なのはサードパーティー製品によるAD参照です。
該当製品がシンプル認証のTCP/389でLDAP認証を行っている場合、アップデート後には通信できなくなります。
この際にADSIを用いていたり、MD-5などの認証を行っている場合は該当しないので影響はありません。(今まで通りLDAPの設定自体は389のままでいける)
※ちなみにADSIもGSSAPIを用いて作られている＝SASLを用いているわけなので今回のLDAP署名云々には関係ないようです。

必要な対応について

こちらのページに以下のような対処法がありました。

◆Windowsの場合
ドメインに参加し、ADSI を使用します。
アプリケーションに大幅な改修が必要になるかもしれません。

◆Linuxの場合
ドメイン コントローラー側で「Active Directory 証明書サービス」をインストールします。 「証明機関」スナップインから DER 形式の CA ルート証明書が取得できます。

つまりWindowsの場合はADSIを使用してLDAP問い合わせをすれば問題なく使用できる。
Linuxの場合は直でLDAP参照(簡易認証)をしていることが多いと思われるため、AD側に証明書の設定が必要で、LDAPS(636)での通信が必要となります。

なので、ADをLDAP参照しているシステムがある場合
・ADSIを使用しているか
・簡易認証以外の方式で接続しているか
がカギとなります。

もし上記に当てはまらない場合は、ADSI対応するorLDAPS化が必要となります。
※ADSI対応というか、SASLに準拠したものであれば大丈夫です。

ADに証明書の設定は必要？

簡易認証のLDAP通信を使用している場合はSSL化（LDAPS）が必要となります。
その場合はADに証明書をインストールする必要があります。
ADの証明書設定については以下を参照
https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx
https://support.microsoft.com/en-us/help/321051/how-to-enable-ldap-over-ssl-with-a-third-party-certification-authority

ADSIを使用している、もしくはSASL認証などでAD参照している場合にはADに証明書等は必要ありません。
（システムをADSI化するって結構大変なんだろうか。。。）