web-dev-qa-db-ja.com

LDAPとKerberosを使用したFreeRADIUS

次のサイトでは、LDAPバックエンドに対して認証するようにFreeRADIUSを設定する方法について説明しています（FreeRADIUSがNTハッシュパスワードを読み取れるようにFreeIPAで公開する方法を示すチュートリアルを実行します）。

https://firstyear.id.au/blog/html/2016/01/13/FreeRADIUS:_Using_mschapv2_with_freeipa.html

また、Kerberosキータブを使用してFreeRADIUSをIPAに接続することもお勧めしません。

"FreeRADIUS can either read the NTHash and do a comparison (as above),
or it can directly bind to the LDAP server. This means in the direct
bind case, that the transport may not be encrypted due to the keytab."

反対に、さまざまなFreeRADIUSガイドはLDAPの使用を推奨していません（たとえば、デフォルトの内部トンネルサイトのコメントを参照してください。

    #  We do NOT recommend using this.  LDAP servers are databases.
    #  They are NOT authentication servers.  FreeRADIUS is an
    #  authentication server, and knows what to do with authentication.
    #  LDAP servers do not.

一般的な免責事項以外に、上記のステートメントの背後にある理論的根拠は何ですか？

誰かがセキュリティの観点から、一方のアプローチともう一方のアプローチの長所と短所を説明できますか？

LDAPバックエンド（KRBなし）を使用して正常にセットアップし、WiFi認証にPEAPを使用しています。このシナリオのセキュリティのトレードオフをよりよく理解したいと思います。

ldapkerberosradiusfreeradiusfreeipa
1
user3814483

FreeRADIUSの場合

コメントは、一般的な免責事項として、FreeRADIUSの欠陥に対処するためにあります。

ほとんどの場合、バインドを実行するユーザーのDNが何であるかがわかりません。したがって、最初に、匿名ユーザーとして、または特権資格情報のセットを使用してバインドし、その検索を実行してDNを見つける必要があります。

FreeRADIUSは、さまざまな目的のために個別の接続プールを維持しないため、認証ユーザーとして接続をリバウンドする必要があります。

つまり、LDAPでユーザーを認証するには、次の3つの操作を実行することになります。

  1. 特権/匿名ユーザーとしてバインドします。
  2. ユーザーのDNを検索します。
  3. ユーザーとしてバインドします。

LDAPサーバーとRADIUSサーバーの間の待ち時間が長い場合、バージョン<= v3.0.xのFreeRADIUSは同期I /を実装するため、スループットが（auth/sに関して）大幅に制限される可能性があります。 O。

特にLDAPサーバーが認証を実行するために専用のバックエンド認証プラグインを使用している場合は、バインド操作を使用してユーザーを認証しない理由はまったくありません。 LDAPが設計された目的は関係ありません。 RADIUSプロトコルは確かに設計されていません国際ローミングコンフェデレーションと多層認証スキームでのTLSのトンネリングそれはそれらの役割をかなりうまく果たします。

IPAの場合

リンクしたドキュメントは紛らわしいです。サービスアカウントを使用してKerberos（GSSAPI）を介してLDAPサーバーにバインドすることについて話しているようです。389DSに欠陥があるため、GSSAPIをStartTLSまたはLDAPSと組み合わせることができません。つまり、ユーザーの資格情報がその2番目のバインド操作中のクリア。

または、StartTLSでGSSAPIを使用したり389DSでLDAPSを使用したりできないため、Kerberosを使用してユーザーバインド操作を実行した場合、資格情報は平文で送信されると言えます。

いずれの場合も、これは389DSのみの制限であり、他のLDAPサーバーの大部分はTLS暗号化LDAP接続を介したGSSAPIをサポートすると確信しています。

いずれにせよ、StartTLSまたはLDAPSを使用せずに、LDAPディレクトリに資格情報を送信または取得しないでください[〜＃〜]決して[〜＃〜]記事によると：

今日、アカウントを保護するための唯一の安全で保証された方法はTLSです。 LDAPSを使用する必要があります。これにより、すべての通信が安全になります。よりシンプル、高速、そして優れています。

ディレクトリサーバーとの通信がクリアされている場合、攻撃者は、ディレクトリサーバーに送信されているプレーンテキストのパスワード、または戻ってきたNTPasswordのいずれかを簡単に盗聴する可能性があります。 NTPasswordは、パスワードの16ビットリトルエンディアンエンコーディングであり、MD4でハッシュ化されており、プレーンテキストとほぼ同じです。

3
Arran Cudbard-Bell

コメント：

#  We do NOT recommend using this.  LDAP servers are databases.
#  They are NOT authentication servers.  FreeRADIUS is an
#  authentication server, and knows what to do with authentication.
#  LDAP servers do not.

lDAPサーバーがデータベースとしてではなく認証に使用されるコンテキストにあります。これは基本的に、RADIUSサーバーが提供された資格情報を使用してLDAPサーバーへの認証を試みることを意味します。そして彼らは当然、これはLDAPが設計された目的ではないことを警告しています。

さて、LDAPをデータベースとして使用する場合、IS場合は他の場所ですが、問題はありません。

0
Tomek