netatalk.io

Netatalk 4.5.0

認証

AFP 認証の基本

Apple は AFP クライアントとサーバー間の認証のために “User Authentication Methods” (UAM) と呼ばれる柔軟なモデルを選んだ。AFP クライアントがまず最初に AFP サーバーと接続するとき、 サーバーが提供している UAM のリストを問い合わせる。そして、クライアントがサポートしている最も強い暗号化の UAM を選ぶ。

数個の UAM は時間をかけて Apple が開発してものであり、サードパーティの開発者によるものもある。

Netatalk でサポートされている UAM

Netatalk はデフォルトで以下の UAM をサポートしている：

• “No User Authent” UAM（ユーザー認証なしのゲスト接続）

• “Cleartxt Passwrd” UAM（クリアテキスト(平文)パスワード、暗号化なし）

• “Randnum exchange”、”2-Way Randnum exchange” UAM （乱数交換・双方向乱数交換、非常に弱いパスワード暗号化、パスワードを別途保存する）

• “DHCAST128” UAM（弱いパスワード暗号化）

• “DHX2” UAM（DHCAST128 の後継で、より強力なパスワード暗号化）

• “SRP” UAM（Secure Remote Password、最も強力なパスワード暗号化と中間者攻撃への耐性、別の検証子ストレージ）

コンパイル時に Kerberos サポートが有効になっている場合、Netatalk は以下もサポートする：

• “Client Krb v2” UAM （Kerberos V、macOS で“シングルサインオン”環境には最も適当である――下記参照）

“uam list” を Global セクションで定義することによって、どの UAM を有効化すべきか設定できる。afpd はどの UAM を使っているのか、UAM を有効化した時に問題が起こっているのかどうかを、netatalk.log あるいは起動時の syslog にログとして保存する。asip-status も AFP サーバーで有効な UAM の問い合わせをするのに使うことができる。

ある特定の UAM がサーバー上で有効であるということが、直ちに、 クライアントもそれを使うことができるということを意味するわけではない。クライアント側でのサポートもまた必要である。Classic Mac OS が使われている古い Macintosh では、DHCAST128 のサポートは AppleShare クライアント 3.8.x 以降には存在している。

macOS では、AFP クライアントをもっと冗長にするクライアント側のテクニックがいくつかあるので、使用する UAM と折り合いをつけるまでに何が起こっているのか見ることができる。このヒント と比較してみるとよい。

どの UAM を有効にすべきか？

それは主に、ニーズとサポートする必要がある macOS クライアントの種類に依存する。ネットワークが macOS (Mac OS X) クライアントのみで構成されている場合は、DHX2 で十分であり、強力な暗号化と PAM（あるいはシステムのパスワードデータベース）との統合を提供する。

より強力なセキュリティを望み、別の検証子ファイルの追加のメンテナンスオーバーヘッドを気にしない場合は、SRP が最適な選択肢である。

• サーバーのボリュームに本当にゲストアクセスを供することが必要な場合以外は、”No User Authent” が無効化されているか確認すべきである。さもないと、意図しない権限のないアクセスを引き起こすことにもなる。 ゲストアクセスを有効にしなければならない場合は、アクセスコントロールを使って、 ボリューム各々についてゲストアクセスを有効化することを強制するように気を配るべきである。

  注意：Apple II ネットブートサービス (a2boot) を使用して AFP 経由で Apple //e を起動するには、「ユーザー認証なし」が必要である。

• “ClearTxt Passwrd” UAM ではパスワードがネットワーク上を暗号化されずに伝わっていくので、 字句そのまんまに良くない。クライアント側のみならずサーバー側でも無効にするよう務めるべきである。

  注意：もしネットブートサービスを使用している Mac OS 8/9 にサービスを提供したい場合、uams_cleartxt.so の UAM が必要となる。 これはそういった Mac のファームウエアに組み込まれた AFP クライアントがこうした基本的な形の認証しか扱わないためである。

• “Randnum exchange”/”2-Way Randnum exchange” は暗号化に 56 ビット DES のみを使用するので、これも避けるべきである。さらに、パスワードはサーバー上で別々に保存されるという欠点もある：DES で暗号化され、必須キーファイルで 16 進数エンコードされる。

  ただし、これは 漢字Talk 7.1 以前で使用できる最も強力な認証形式である。

• “DHCAST128” (“DHX”) は Randnum よりは大幅な改善であるが、今日の基準では暗号化が弱い。

  これは 漢字Talk 7.1 以前で使用できる最も強力な認証形式である。

• “DHX2” はより強力な暗号化と PAM 統合の利便性を組み合わせているので、ほとんどのユーザーにとって最適な選択肢である。

• “SRP” は最も強力な UAM で、最も強力なパスワード暗号化と中間者攻撃への耐性を提供するが、ユーザーごとのソルトと検証子を保存するための別のファイルの管理が必要である。このファイルの追加のメンテナンスオーバーヘッドを気にしないのであれば、SRP はセキュリティに敏感なユーザーにとって最適な選択肢である。

• Kerberos V (“Client Krb v2”) UAM を用いれば、Kerberos チケットを用いて真のシングルサインオン環境を実装することが可能である。パスワードがネットワークを通して送られることもない。 その代わり、ユーザーのパスワードは AppleShare サーバーへのサービスチケットを暗号から復号するのに用いられる。 サービスチケットにはクライアントの暗号鍵と幾らかの暗号化されたデータが含まれる （それは AppleShare サーバーだけが復号できる）。サービスチケットの暗号化された部分がサーバーに送られ、ユーザーを認証するのに使われる。afpd サービスプリンシパル検知の実装の仕方のために、この認証方法は中間者攻撃に対して脆弱である。

様々な UAM の技術的実装についてのより詳細な概要については、Apple の File Server Security ページを見ていただきたい。

パスワード保管

Randnum と SRP はシステムのパスワードを直接使用しない。両方とも afppasswd で管理される別のファイルに依存している：

• Randnum は従来の afppasswd ファイルを使用する。Randnum パスワードファイルと並んでキーファイルが必要である（同じパスで .key サフィックスがついている）。afppasswd -r -c はこのキー ファイルが存在しない場合に作成し、既存のものを検証する。キーファイルが存在し有効でない限り、パスワードの更新は進行を拒否する。Randnum UAM はキーファイルが存在しないか無効な場合に起動時の警告をログに記録するが、修正されるまでは認証とパスワード変更は失敗する。保存されたパスワードはそのキーを使って DES で暗号化される。

キーファイルには、オプションの改行を伴う 16 個の 16 進数文字が正確に含まれている必要がある。 例の値を再利用するのではなく、各サーバーのために新しいランダムなキーを生成すること。

• SRP はユーザーごとのソルトと検証子を保存する afppasswd.srp を使用する。

認証バックエンドの切り替え

いくつかの UAM は別の認証バックエンドを使えるようにしてある。いわゆる uams_clrtxt.so、uams_dhx.so 及び uams_dhx2.so である。これらは /etc/passwd (/etc/shadow) からの古典的 UNIX パスワードでも、システムがサポートしていれば PAM でもどちらでも使うことができる。 uams_clrtxt.so は uams_passwd.so ないしは uams_pam.so へのシンボリックリンクとして、 uams_dhx.so は uams_dhx_passwd.so ないしは uams_dhx_pam.so へのシンボリックリンクとして、さらには uams_dhx2.so は uams_dhx2_passwd.so ないしは uams_dhx2_pam.soへのシンボリックリンクとすることができる。

もし Netatalk の UAM フォルダー（デフォルトで /etc/netatalk/uams/）が以下のようであれば、PAM さもなくば古典的な UNIX パスワードを使用しているわけである。

uams_clrtxt.so -> uams_pam.so
uams_dhx.so -> uams_dhx_pam.so
uams_dhx2.so -> uams_dhx2_pam.so

PAM を使用することで最も有利なのは、例えば LDAP 経由、あるいは NIS 経由などの集約した認証環境に Netatalk を統合できることである。そのような環境でのユーザーのログイン資格情報 (credentials) の保護は、UAM そのものが供している暗号化の強さにもまた依存している。 ということを常に念頭においていただきたい。

Netatalk UAM を概要表

公式にサポートされているUAMの概観。

macOS で非推奨のレガシー UAM を有効にする方法については、Apple サポートのナレッジベース記事 Connecting to legacy AFP services を参照すること。ただし、これを本番環境で行うことは推奨されない。なぜなら、これにより AFP ユーザー資格情報がネットワークトラフィックにさらされる可能性があるからである。

多くのオープンソースやその他のサードパーティ製 AFP クライアントが存在する。。サポートされている UAM のリストについては、それらのドキュメントを参照すること。

パスワードの保存と変更

Netatalk はクライアントがサーバー上でパスワードを保存または変更できるように構成できる。afp.conf の Global セクションの save password オプションはこの機能を有効にするが、AFP クライアントもこのフラグをサポートし、尊重する必要がある。

クライアントがパスワードを変更できるようにするには、set password オプションを設定すること。これは使用している UAM に依存し、すべての UAM がこれをサポートしているわけではない。特に、PAM ベースの UAM はこの機能をサポートするが、古典的な UNIX パスワードに基づく UAM はサポートしない。