そろそろLDAPにしてみないか?

第4回 UNIXアカウント以外でLDAP

この記事を読むのに必要な時間:およそ 3 分

FTPアカウントにLDAP

LDAPに対応しているアプリケーションは数多く存在するため,何から紹介すればよいのか迷ってしまうのですが,わかりやすさ,容易に構築できるという点で今回はFTPサーバ+LDAPサーバの組み合わせを紹介してみたいと思います。「えー? 今さらFTPサーバ?」なんて言わないで最後まで読んでみてください(笑)

通常であれば,あるユーザがFTPサービスを利用する場合,そのアカウント情報は/etc/passwd/etc/shadowに登録されている必要があります。

しかし,ユーザにFTPのみを使用させたい場合,/etc/passwdなどにアカウントが存在してしまうと都合が悪いことがあります。なぜなら/etc/passwdに登録されているユーザ情報はgetpwent(3)などにより,さまざまなアプリケーションから参照されるためです。ldapuserというユーザにはFTPサービスのみ提供したいのに,ldapuser@example.comというメールアドレス宛にメールを送ると/var/mail/ldapuserというメールボックスが作成されては,都合が悪い・ですよね。

さて,LDAPサーバ内にFTPアカウントを作成するためには,いくつかの方法が考えられます。1つめの方法はPAMを利用することです。多くの一般的なFTPサーバ,たとえばvsftpdはPAMによる認証に対応しているため,この方法を用いると,特別な設定をすることなくFTPアカウントを使用することができます。

開発者にとってのメリットとしては,ソフトウェアをPAMにさえ対応させれば自動的にLDAP認証(pam_ldap)にも対応できることが挙げられます。一方,認証関連の設定は/etc/ldap.confを用いて行うことになるため,設定の影響範囲が大きいことがデメリットとも言えるでしょう。例えばvsftpdの設定を変更するつもりで/etc/ldap.confを編集しても,その設定がpam_ldapを使用するすべてのソフトウェアに反映されてしまいます。

もう1つの方法は,PAMとは独立してLDAP内にFTP専用のアカウントを作成することです。このようなアカウントを作成しておけば,仮にFTP専用ユーザのユーザ名とパスワードが漏洩してしまっても,その被害の影響範囲はFTPサービスのみに限定されます。アカウント情報を勝手に使われてしまっても用途はFTPに限定されているため,その情報を元にSSHログインできるわけではありません。もちろん開発者は各種LDAP関数を活用してソフトウェアを構成しておく必要があります。Proftpdはこの方式に対応していますが,先ほど例として挙げたvsftpdには,残念ながらこの実装が含まれていません。

それではFTP専用アカウント,ということを前提として,FTP認証用の属性などを設計してみましょう。最低限の情報としては表1のようなものになると思います。

表1 必要な属性

必要な項目必要な理由
ユーザ 認証に使用するためftpuser
パスワード認証に使用するためftppass
ホームディレクトリログイン時のホームディレクトリ/home/ftproot/ftpuser
UID番号ファイル作成時などに使用される10000
GID番号ファイル作成時などに使用される10000
グループ名(必要に応じて)ls-laなどでGID番号だけでなくグループ名が表示されるようにsales

標準スキーマで用意されている属性を使えば,ftpuserのエントリはリスト1のようになるはずです。

リスト1 LDIFで表現

# FTPグループ
dn: cn=sales,ou=FTPGroup,dc=example,dc=com
cn: sales
gidNumber: 10000

# FTPユーザ
dn: uid=ftpuser, ou=ftpuser, dc=example, dc=com
uid: ftpuser
userPassword: ftppass
homeDirectory: /home/ftproot/ftpuser
uidNumber: 10000
gidNumber: 10000

とりあえずは必要な属性のみを列挙してみましたが,すでに皆さんご存じのように,ある属性を使用するにはそれが属するobjectClassを定義する必要があります。上記のFTPグループではcngidNumber属性を使用しています。ということで,gidNumberというキーワードを/etc/openldap/schema以下からgrepしてみれば,目的のobjectClassがわかります。

gidNumberが含まれるobjectClassは次のように定義されています。

objectclass ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top STRUCTURAL
        DESC 'Abstraction of a group of accounts'
        MUST ( cn $ gidNumber )
        MAY ( userPassword $ memberUid $ description ) )

ということで,cnとgidNumberが含まれている今回のエントリにobjectClass: posixGroupを追加しておくだけで良さそうです。グループではなくユーザ部分はどうなるでしょうか? 今度はuidNumberをキーワードにschemaディレクトリを検索してみます。次のようなエントリが見つかりました。

objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
        DESC 'Abstraction of an account with POSIX attributes'
        MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
        MAY ( userPassword $ loginShell $ gecos $ description ) )

このposixAccountというobjectClassを使用するためには,先ほど列挙した内容以外にuid属性が必要となります(uid属性がMUSTと定義されているため)。さらに,このobjectClassはtopから派生し,補助オブジェクト(AUXILIARY)であることもわかります。補助オブジェクトとなっているobjectClassは単体で宣言することができません。補助オブジェクトはSTRUCTURALであるaccountなどのobjectClassと一緒に使用する必要があります。

著者プロフィール

中満英生(なかみつひでお)

大学時代に出会ったSolarisがきっかけでUNIXの世界へ。その後ホスティングプロバイダ,データセンターで実務経験を積む傍ら,雑誌記事の執筆や技術セミナーの講師を務める。サーバ設定の他,セキュリティに関する著作や技術者エッセイも執筆経験あり。

コメント

コメントの記入