#はじめに
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化するって結構大変なんだろうか。。。）