 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
UNIX USER 2003年12月号掲載
Part 1 2.2系と3.0系のバージョン選択基準
Windowsネットワークへの参加
SambaはUNIX/LinuxマシンとWindowsネットワークとの接続性を実現するため、Windowsのファイルサーバー/プリントサーバー機能を実装したオープンソースソフトウェアだ。
Samba3.0 は必要か？
長い年月をかけて待ちに待ったSamba 3.0だが、すべてのユーザーにとって最適な選択であるとは限らない。そこで新機能の詳細について触れる前に、Samba 3.0の必要性について確認しておく。
Samba3.0 の新機能
それでは、Samba 3.0の新機能の詳細について紹介しよう。  ActiveDirectoryドメインへの参加機能
Samba 2.2でサポートするドメイン参加機能は（プロトコル的には）Windows NT 4.0相当のものであり、Active Directory（以下AD）ドメインにも参加できるが、その際はNTLM（ハッシュパスワードによる）認証となる。今回のSamba 3.0では、Windows 2000相当のKerberos（チケット方式）認証が利用可能となる。セキュリティを重視するユーザーにとっては有用な機能だ。 通信路上のUnicodeサポート
Samba 2.2のドメインコントローラ機能はWindows NT 4.0をベースに開発されているものの、Windowsクライアントとの通信で使用される文字コードはWindows 9xと同じシフトJISである。このため、一部のWindowsアプリケーションでは互換性の問題が発生していた。
【実行例1】
C:\> net use n: \\サーバー名\共有名
C:\> n:
N:\> mkdir 123456789
N:\> cd 123456789
N:\123456789> mkdir 漢字文字
N:\123456789> cd 漢字文字
N:\123456789\漢字文字5687> l
↑余分な数字が入る
ユーザー管理機能の強化Samba 2.2ではユーザー管理データベースとしてsmbpasswd、TDB、LDAPなどが利用できたが、LDAP機能を有効にしてコンパイルすると、LDAP以外のユーザー管理機構が使用できなくなった。そのため、ユーザー管理データベースを切り分けるには、それぞれの環境を構築しなければならない。しかしSamba 3.0では、このような作業は不要となり、smb.confのpassdb backendパラメータだけで切り替えられる 【表2】。なお、2.2のデフォルト設定と同じ状態にするには、 passdb backend = smbpasswd
としておけば良い。これによって、従来どおり/etc/samba/smbpasswd（と/etc/passswd）を参照する。
名前変換アルゴリズムの変更
Windowsのファイル名には、DOS時代からの名残である8 . 3形式のシフトJ I Sコードで表現されるS F N（Short File Name）とWindows NTからサポートされたUnicodeで表現されるLFN（Long File Name）の2種類が存在する。これに対処するため、SambaにはUNIX/Linux上のファイル名からSFNおよびLFNを生成する名前マングリング機能（Name Mangling）が実装されている。従来のSamba 2.2では変換アルゴリズムが単純、かつ必要なときに生成されるため、SFNが永続的でなく、一部のプログラムで問題が発生した。
netコマンドのサポート
Windowsに付属する管理用のnetコマンドが、Sambaでも標準サポートされた。このコマンドによって、SambaサーバーとWindowsサーバー、いずれに対しても
【表3】
のような操作が可能となった。 WinbindでのUID/GID分散化Samba 2.2でWinbindを利用してWindowsドメインにユーザー管理機構を任せた場合、WindowsのRID（Relative ID：相対識別子）とLinuxのUID/GIDのマッピングはサーバーごとに行われるため、全マシンにおいて同一ユーザーが同じIDになるとは限らなかった。しかしSamba 3.0では、UIDのマッピングをLDAPに保存し、すべてのマシンで同一のIDが振られるようになった。当然、この機能を使う場合は、LDAPサーバーが必要となる。 Samba共有に対するACLサポート
Sambaの共有に対しては、従来からsmb.confの中にread listパラメータやwrite listパラメータを指定してユーザーやグループへのアクセス制御が可能だった。Samba3.0では、これに加えてWindowsのサーバーマネージャおよびコンピュータの管理MMC（Microsoft Management Console）からACL（Access Control List）を設定できるようになった。これらの設定はLinuxから実行できないが、情報はsmb.confではなく、TDBの中に保存される。 グローバルグループ機能の追加
従来のSamba 2.2でもsmb.confn中でDomain Adminsグループを指定できたが、Samba 3.0ではnetコマンドを実行することでWindowsと同等のグローバルグループが利用できるようになった。また、グループマッピング機能もサポートされたため、UNIX/LinuxのグループをWindowsのグループに対応可能だ。マッピングのサンプルとして、
【リスト1】
のようなものが用意されている。 日本語文字コードの変換方式
前述のとおり、クライアントとの通信時の文字コードがシフトJISからUCS-2へ変更されたが、Samba 3.0では文字コードの変換方式についても変更されている。従来はcoding systemパラメータ、client code pageパラメータで文字コードを指定し、コード変換ロジックはSambaの内部に持っていたが、Samba 3.0では
【表4】
のパラメータで文字コードを指定し、コード変換は外部のiconvライブラリを使用するようになった【図】。
【図】Samba 3.0 における文字コード 
環境に応じたバージョンを選択しよう
多くの新機能が追加されたSamba 3.0だが、日本語への対応という面では若干手間が増えている。また、大規模向けの新機能がメインであるため、個人ユーザーが導入および移行するには悩むところだろう。Part 2以降の具体的な導入および設定作業を参考にして、環境に応じたシステムを構築してほしい。
Part 2 インストールの詳細と日本語対策
Samba3.0の導入
Part 1で解説したとおり、Samba 3.0で日本語を利用するには、iconvライブラリが必要となる。したがって、事前にiconvライブラリを導入しておかなければならない。
RPMパッケージを利用した導入作業
Samba 3.0.0では内部構造が大幅に変更されたため、導入時に注意すべき点が存在する。 CP932への対応DOSやWindows（95/98/Me系）で使われる文字コードは一般にシフトJISといわれるが、正確にはCP932（注1）というマイクロソフト独自のものである。Linuxディストリビューションで標準的に使用されるglibcはCP932に対応していないため、日本語の変換において一部問題が発生する。同様に、FreeBSDや商用UNIXなどでも、CP932の変換に対応したライブラリを持っていない。つまり、一般的な環境では、Samba 3.0で正しく日本語を扱えないわけだ（注2）。これを解決するには、次の2つの方法が考えられる。
これらを考慮すると、最近のLinuxディストリビューションおよびUNIX系であれば、CP932対応パッチを適用したlibiconvを導入すると良いだろう。ただし、glibcにCP932対応パッチを適用する場合はSambaの公式サイトにあるRPMパッケージが利用できるが、libiconvにパッチを当てる際はconfigureスクリプト実行時にlibiconvの指定が必要となるため、この処理を行ったRPMパッケージを利用しなければならない。
libiconvの導入日本Sambaユーザ会のサイトには、Red Hat Linux 9用およびMIRACLE LINUX 2.1用のCP932対応glibcパッケージとCP932対応libiconvパッケージが用意されている。なお、これらのソフトウェアはUNIX USER 2003年12月号付録CD-ROMにも収録しているので適宜利用してほしい。 上記のLinuxディストリビューション以外を使用している場合は、【実行例1】のようにしてSRPMからRPMパッケージを作成してほしい。これによって、デフォルトでは/usr/src/redhat/RPMS/i386以下にRPMパッケージが生成されるので、それをインストールする。 # cd /usr/src/redhat/RPMS/i386/ # rpm --Uvh libiconv-1.8-1.i386.rpm【実行例1】SRPMによるlibiconvの再ビルド ・Red Hat Linux 7.xの場合 # rpm --rebuild libiconv-1.8-1.src.rpm ・Red Hat Linux 8.0以降の場合 # rpmbuild --rebuild libiconv-1.8-1.src.rpm Samba本体の導入前述のとおり、CP932対応libiconvパッケージを導入した場合は、libiconv対応のRPMパッケージを利用する必要がある。該当するLinuxディストリビューション用のRPMパッケージがないときは、先ほどと同じようにSRPMから作成してほしい【実行例2】。あとは、これを利用してインストールするだけである。 # cd /usr/src/redhat/RPMS/i386/ # rpm --Uvh samba-3.0.0-3iconv.i386.rpm【実行例2】SRPMによるSamba 3.0.0の再ビルド ・Red Hat Linux 7.xの場合 # rpm --rebuild samba-3.0.0-3iconv.src.rpm ・Red Hat Linux 8.0以降の場合 # rpmbuild --rebuild samba-3.0.0-3iconv.src.rpm
ソースからの導入作業
RPMパッケージが利用できない場合は、ソースを入手してコンパイル・インストールする。 libiconvの導入ソースからコンパイルするときは、まずlibiconvのソースアーカイブとCP932パッチを入手する。
http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.8.tar.gz
http://www2d.biglobe.ne.jp/~msyk/software/libiconv-patch.html libiconvのソースアーカイブを適当なディレクトリで展開し、パッチを適用する。 $ tar zxvf libiconv-1.8.tar.gz $ zcat libiconv-1.8-cp932-patch.diff.gz | patch -p0あとは、configureスクリプトの「--prefix」オプションでインストール先を指定し、「make」、「make check」、「make install」を行う。 $ cd libiconv-1.8 $ ./configure --prefix=/opt/libiconv $ make ; make check # make install環境によっては、/etc/ld.so.confにインストール先のライブラリ用ディレクトリ（/opt/libiconv/lib）を追加し、「ldconfig -v」を実行しておく必要がある。 インストール後は、iconvコマンドによってCP932に対応しているかどうかを確認しておこう。 $ /opt/libiconv/bin/iconv -l | egrep -i '(-31j|-ms)' EUCJP-MS CP932 WINDOWS-31J Samba本体の導入Samba本体のソースアーカイブ（samba-3.0.0.tar.bz2とsamba-3.0.0.tar.gzの2種類あるので、どちらかを利用する）は、 ftp://ftp.samba.gr.jp/pub/samba/ などから入手して、適当なディレクトリで展開する。
$ tar xvj（注4）f samba-3.0.0.tar.bz2
あるいは
$ tar xvzf samba-3.0.0.tar.gz
続いて、samba-3.0.0/sourceディレクトリに移動して、configureスクリプトを実行する。ここでは 【表1】 のようなオプションが指定可能だが、詳細については「--help」オプションで表示される内容を参照してほしい。 $ cd samba-3.0.0/source $ ./configure --with-libiconv=/opt/libiconv/ --with-pam後は「make」、「make install」で完了だ。 $ make # make installなお、UNIX/Linuxでの名前解決用としてWINSモジュールを利用する場合は、 $ make nsswitch/libnss_wins.soを実行後、libnss_wins.soを/lib以下へコピーしておこう。 # cp nsswitch/libnss_wins.so /lib 設定ファイルの準備
ソースを利用して導入した場合、Sambaの実行ファイルなどはインストールされるが、設定ファイルがインストールされない。Sambaを動作させるには、これらのファイルの準備、およびシステム側の設定ファイルの変更が必要となる。  smb.confSambaの設定ファイルであり、これがないとSambaは起動しない。Samba3.0.0で日本語を利用する場合は、必ず以下の3行を指定してほしい。 unix charset = EUCJP-MS display charset = EUCJP-MS dos charset = CP932
1行目の指定は、CP932をサポートしたlibiconvやglibcを導入していないと利用できない（Smabaが起動しない）ので注意しよう。日本語ファイル名を考慮したサンプルファイルをUNIX USER 2003年12月号付録CD-ROMの/Speciall/samba-3.0-ja以下に収録したので、参考にしてほしい。 smbpasswd、passdb.tdb
Sambaユーザー用のパスワードを格納するファイル。 SWAT用の設定Sambaの設定/管理をWebブラウザ経由で行うため、専用WebインターフェイスSWATが用意されている。これはinetd/xinetd経由、あるいはWebmin 経由で利用するが、前者の場合、/etc/servicesに次の行を追加しておく。 swat 901/tcp
さらに、システムがinetdとxinetdのどちらを使用しているのか確認し、
【リスト1】
のような設定を行う。 /etc/logrotate.d/sambaSambaのログを定期的にローテーションさせるには、ログローテーション用の設定ファイルを用意する。たとえば、Red Hat Linux 9であれば、 【リスト3】 のような/etc/logrotate.d/sambaファイルを作成しよう。これは、ソースディレクトリのpackaging/RedHat以下にあるsamba.logをコピーしても良い。
Sambaの起動設定
起動スクリプトが用意できたら、それらがシステム起動時に読み込まれるように設定する。たとえば、Red Hat Linux 9であれば、 # chkconfig smb on および # chkconfig winbind on
と実行することで、現在のランレベルにおいてシステム起動時にSambaが自動実行されるようになる。
【図】SWATでの設定（図は動作状況の画面）
開発者へのフィードバックが安定したSambaを生む
筆者がLinux関連の仕事をしているため、Linux中心の解説となってしまったが、Sambaの開発チーム自体もLinux中心で開発を進めている。したがって、動作検証などもLinuxを重点的に行っているのも事実だ。
Part 3 ケース別に見るSambaサーバー構築時の注意点
スタンドアロンサーバーの構築
最初に、Sambaを用いたスタンドアロンサーバーの構築方法について解説する。スタンドアロンサーバーとは別のホストと連携することなく単独で利用するもので、Windowsでいうワークグループサーバーのことである。この場合、ユーザーやグループの管理が重要なポイントとなる。 ユーザー管理データベースの選択
Part 1でも説明したが、Samba 3.0の推奨設定ではスタンドアロンサーバー構築時のユーザー管理データベースとしてTDBを利用する。これは、Samba 2.2で一般的に利用していたsmbpasswdと比較して、性能や拡張性の面で優れている。 passdb backend = tdbsam ユーザー管理
Samba 2.2におけるユーザーの追加作業は、システム側のuseraddコマンドを実行した後、Samba側のsmbpasswdコマンドを実行した。一方、Samba 3.0ではpdbeditコマンド
【表1】
とnetコマンドが提供されている。 # useradd odagiri ←システム側にユーザーを追加 # pdbedit -a -u odagiri
pdbeditコマンドはpassdb backendパラメータとして「tdbsam」、「smbpasswd」、「ldamsam」のいずれかを利用した場合にユーザーを管理できるが、事前にシステム側でもユーザーを追加しておく必要がある。 # net rpc user add odagiri
と実行し、管理対象がSambaでもWindowsでもユーザー管理可能だが、ネットワーク経由でアクセスするためのユーザー/パスワードが必要だ。 グループの管理
Samba 2.2ではグループ管理機能を実装していなかったため、システム側のgroupaddコマンドでグループの追加を行えば良かった。ところが、Samba 3.0からはグループ管理機能を実装したため、groupaddコマンドに加えてnetコマンドでグループ管理を行わなければならない。さらに、SambaでWindowsドメイン環境を構築する場合、グローバルグループとローカルグループを区別できるようになったことで、管理上もこれらを使い分ける必要が出てきた。 # groupadd dev # net groupmap add ntgroup=dev unixgroup=dev type=local のように実行し、Sambaドメイン環境でグローバルグループdevを作成するには、 # groupadd dev # net groupmap add ntgroup=dev unixgroup=dev type=domain
のように実行する。
これらのグループは、netコマンド（注1）を利用して登録しておこう【実行例1】。UNIX/Linux側のグループ名wheel、nobody、smbusersは、それぞれの環境に応じてカスタマイズしてほしい。
【実行例1】 必須グループの追加 # groupadd smbusers # net groupmap modify ntgroup="Administrators" unixgroup=wheel # net groupmap modify ntgroup="Users" unixgroup=smbusers # net groupmap modify ntgroup="Guests" unixgroup=nobody # net groupmap modify ntgroup="Print Operators" unixgroup=lp # net groupmap modify ntgroup="Domain Admins" unixgroup=wheel # net groupmap modify ntgroup="Domain Users" unixgroup=smbusers # net groupmap modify ntgroup="Domain Guests" unixgroup=nobody Windowsからのユーザー管理
ここまでの解説によって、「Samba 3.0ではユーザー管理が大変になった」と感じた人も多いのではないだろうか？たしかに設定やコマンドは面倒になったが、Samba 3.0ではWindowsからのユーザー/グループ管理が実現された。これによって、非常に管理しやすくなるだろう。
【図1】ユーザーマネージャによる管理
メンバサーバーの構築
続いて、既存のADドメインに対して、Sambaサーバーをメンバサーバーとして登録してみよう。ここでは、ドメインコントローラとしてWindows 2000 Server/Server 2003が動作していることを前提とする。 # net rpc join member -w <ドメイン名> -S <PDCサーバー名> -U administrator%<管理者パスワード> 後は、Winbindデーモンを起動すれば完了だ。Samba 3.0.0ではSWATからWinbindが起動できるようになったので、これを利用すると良い。また、Winbindが割り付けたUID/GIDをLDAPで管理できるので、複数のSambaサーバーが（Winbindを利用して）ドメインメンバになる場合は、LDAPサーバーを用意して、smb.conf内でidmap backendパラメータを指定しよう。 idmap uid = 1000-2000 idmap gid = 2000-3000 そのほか、LDAP関連のパラメータについては、以降の解説を参考にしてほしい。
【図2】コンピュータをドメインへ追加
【図3】新しいオブジェクト 
ドメインコントローラの構築
Samba 3.0をPDCとして起動するには、スタンドアロンサーバー構築時に用意したsmb.conf内で「domain logons = yes」と指定するだけでもOKだ。しかし、複数のSambaサーバーを用いた場合、個別のサーバーごとにユーザー登録しなければならず、BDCも構築できない。したがって、複数台のSambaサーバーによってドメインを構築する場合は、LDAPサーバーを用意し、smb.conf内で「passdb backend=ldapsam」としたほうが良いだろう。 Samba 3.0.0での問題点Samba 3.0.0をLDAPサーバーと連携させる場合、注意すべき点がある。LDAPスキーマを作成するための環境が用意されていないため、手順を間違えると正常に動作しないのだ（注2）。この状況は、後述するsmbldap-toolsが改良されれば解決するだろう。
OpenLDAPの導入Sambaのldapsam機能はOpenLDAPをベースに開発されているが、OracleやNovellなどのLDAPサーバーにも対応しており、スキーマさえ登録すれば問題なく利用可能だ。ここでは、OpenLDAP 2.0.27による構築方法を解説する。 RPMパッケージの利用
Red Hat系Linuxディストリビューションの場合、RPMパッケージが用意されているので、これらを利用すると簡単だ。 # rpm -Uvh openldap-2.0.27*.i386.rpm # rpm -Uvh openldap-clients-2.0.27*.i386.rpm # rpm -Uvh openldap-devel-2.0.27*.i386.rpm # rpm -Uvh openldap-servers-2.0.27*.i386.rpm # rpm -Uvh nscd-2.3.2*.i386.rpm # rpm -Uvh nss_ldap*.i386.rpm ソースの利用
RPMパッケージを利用できないOSについては、ソースを利用することになる。OpenLDAPのソースアーカイブは、次のサイトなどから入手可能だ。
http://www.openldap.org/ # tar xfz openldap-2.0.27.tgz 展開後、ソースディレクトリでconfigureスクリプトを実行するが、ここでは【実行例3】のオプションを指定した。オプションの詳細については、「--help」で出力される表示を参照してほしい。 # ./configure --help 後は、依存関係を構築し、コンパイル、インストールすれば完了だ。 # make depend # make # make test # make install # cd openldap-2.0.27 # ./configure --prefix=/usr --exec-prefix=/usr\ > --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc\ > --datadir=/usr/share --includedir=/usr/include\ > --libdir=/usr/lib --libexecdir=/usr/libexec\ > --localstatedir=/var --sharedstatedir=/usr/com\ > --mandir=/usr/share/man --infodir=/usr/share/info\ > --with-slapd --with-slurpd --without-ldapd\ > --with-threads=posix --enable-shared --enable-static\ > --enable-ldbm -with-ldbm-api=gdbm --enable-passwd\ > --enable-shell -enable-local --enable-cldap\ > --disable-rlookups --with-kerberos=k5only --with-tls\ > --with-cyrus-sasl --enable-wrappers --enable-cleartext\ > --enable-crypt --enable-kpasswd --enable-spasswd\ > --libexecdir=/usr/sbin --localstatedir=/var/run OpenLDAPの設定OpenLDAPを利用するには、
という2種類の設定を行う必要がある。1.はLDAPデーモンを動作させるサーバーのみ行えば良く、2.はWindowsを除くすべてのUNIX/Linuxマシン（LDAPサーバーのマシン自体も含む）で行わなければならない。 LDAPサーバー動作用の設定設定が必須なファイルは、/etc/openldap/slapd.confだけである。ここではSambaでドメイン環境を構築する際の関連事項のみ解説するので、OpenLDAPの詳細な設定方法については以下のWebページなどを参照してほしい。
まずは、 【リスト7】 に示したslapd.confのサンプルファイルを見てほしい。これをベースとして、次にあげる4つのパラメータに関連する作業を行う。
Samba用のスキーマファイルの取り込みは、includeパラメータで指定する。Samba 3.0.0のソースアーカイブに含まれるexsample/LDAP/samba.schemaファイルを/etc/openldap/schema/samba30.schemaへコピーして、slapd.confで次のように設定する。 include /etc/openldap/schema/samba30.schemaまた、Samba 3.0.0を「--with-ldapsam」オプション付きでコンパイルした場合、Samba 2.2のソースコードに含まれるスキーマを/etc/openldap/schema/samba22.schemaへコピーし、次の設定を追加しておこう。 include /etc/openldap/shema/samba22.shema
ベースサフィックスはsuffixパラメータで指定する。これは、最低でも1つ以上設定しなければならない。ユーザー側で自由に設定できるが、全世界でユニークになるようにDNSドメイン名と同じものを使用するのが一般的だ。 suffix "dc=miraclelinux,dc=com" suffix "dc=softbank,dc=co,dc=jp" suffix "ou=naniwa,dc=unixuser,dc=jp" ここで「dc」はDomain COmponent、「ou」はOrganization Unitを意味している。これ以外に「c」（Country）や「o」（Organization）なども使われるが、ユニークであれば何を使ってもユーザーの自由である。また、大文字・子文字の区別はない。
LDAPサーバーの管理者DN（Distinguished Name：識別名）は、rootdnパラメータで指定する。なお、管理者などユーザー用のDNについても自由に設定可能で（ベースサフィックスを含む必要がある）、大文字・子文字の区別はない。 rootdn "cn=Manager,dc=miraclelinux,dc=com" rootdn "cn=root,dc=softbank,dc=co,dc=jp" rootdn "cn=Administrator,ou=Users,ou=naniwa,dc=unixuser,dc=jp"
LDAPサーバーの管理者パスワードは、rootpwパラメータで設定する。テスト環境では平文のパスワードを指定しても良いが、実運用では暗号化したものを用いてほしい。
# slappasswd -s miracle -h {MD5}
{MD5}0SLYzLSMIRdTdundlie/5A==
ここで表示されたものをrootpwで指定すれば良い。
rootpw = {MD5}0SLYzLSMIRdTdundlie/5A==
なお、rootdnパラメータとしてLDAPに登録されているユーザーを指定し、LDAP内にパスワードが格納されている場合は、rootpwを省略できる。 # service ldap start 無事に起動したら、システム起動時に自動実行するように設定しておく。 # chkconfig ldap on LDAPクライアントとしての設定LDAPクライアントとなるすべてのUNIX/Linuxマシンでは、次の4つのファイルについて設定を行う必要がある。
Red Hat LinuxやMIRACLE LINUX V2.xでは、設定ツールauthconfigが提供されているので、これを利用すると良いだろう。LDAPサーバーが動作しているマシンではサーバーを127.0.0.1とし、それ以外ではLDAPサーバーのIPアドレスやホスト名を指定する【図4】。
ネームサービススイッチの設定ファイル/etc/nsswitch.confでは、次のようなLDAPに関する設定が必要となる。 passwd: files ldap shadow: files ldap group: files ldap
nss_ldapとpam_ldapの設定ファイルである/etc/ldap.confを編集し、ユーザーの組織と検索ベースを反映させる。/etc/openldap/ldap.confはldapsearchやldapaddなどのコマンドラインツール用設定ファイルであり、これもLDAP設定に合わせて編集する必要がある。 host 127.0.0.1 base dc=miraclelinux,dc=com のように変更されているはずだが、さらに、 nss_base_passwd dc=miraclelinux,dc=com?sub nss_base_shadow dc=miraclelinux,dc=com?sub nss_base_group ou=Groups,dc=miraclelinux,dc=com?one ssl no pam_password md5 のような内容も追加しておこう。
PAM用設定ファイル/etc/pam.d/system-authには、次のような行が追加される。 auth sufficient /lib/security/pam_ldap.so use_first_pass
UNIX/Linuxにssh/telnetでログインして使用する場合は、自動ホームディレクトリ設定機能も指定しておくと良いだろう
【リスト8】。 # service nscd start # chkconfig nscd on これによって検索結果がキャッシュされるため、アクセスが高速になる（これを起動させなくてもLDAPの動作に支障はない）。
Samba側の設定SambaサーバーをPDC/BDCとしてドメインを構築する場合、PDC/BDC/メンバサーバーのsmb.confファイルを 【表2】 のように設定する。
SambaとLDAPを利用した環境では、ユーザー情報はすべてLDAPに格納されているので、PDC/BDCといった役割は簡単に変更可能だ。したがって、Sambaを複数台利用する場合は、1台だけPDCを設定し、それ以外はすべてBDCにすると良いだろう。また、SambaをPDCにするときはWINSサーバーにしたほうが良いが、その際、WindowsクライアントにおけるWINS設定の変更も忘れずに行ってほしい。 LDAPサーバーの指定LDAPを利用する場合、passdb backendパラメータでは「ldapsam」を指定するが、同時にLDAPサーバーのホスト名も指定する。 passdb backend=ldapsam:ldap://
デフォルトは「localhost」なので、同一マシン上の設定であれば「:ldap:// アカウント検索用DNアカウント検索用DNは、ldap suffixパラメータで設定する。ここでは「dc=miraclelinux,dc=com」とするため、次のように設定した。 ldap suffix="dc=miraclelinux,dc=com" LDAP管理者用DNとパスワードLDAP管理者用DNは、ldap admin dnパラメータで設定する。これは/etc/openldap/slapd.confでの指定と同一にしなければならない。したがって、ここでは以下のように設定した。 ldap admin dn = cn=Manager,dc=miraclelinux,dc=com また、LDAP管理者用パスワードは、smbpasswdコマンドで設定する。 # smbpasswd -w miracle ※
以上の説明を踏まえて、ここでは 【リスト9】 のような設定ファイルを用意した。最後に、Sambaを起動する。 # service smb start OpenLDAPへの初期データ投入
LDAPへの初期データの格納や、ユーザーやグループの管理用のツールとして、smbldap-toolsが用意されている。これはSambaのソースアーカイブに含まれるが、次のサイトで最新ソースコードやRPMパッケージが用意されているので、そちらを利用してほしい。 必要なPerlモジュールsmbldap-toolsはPerlで記述されており、以下のPerlモジュール（注3）が必要なので、パッケージシステムなどを利用して導入してほしい。
IO-Socket-SSL-0.95.tar.gz
XML-NamespaceSupport-1.08.tar.gz XML-SAX-0.12.tar.gz Authen-SASL-2.04.tar.gz Convert-ASN1-0.18.tar.gz perl-ldap-0.29.tar.gz smbldap-toolsの導入によって、 【表3】 のスクリプト群がインストールされる。
smbldap-populate.plの実行smbldap-toolsの使用前には、まず/etc/samba/smbldap_conf.pmファイルにおいて次の行を設定しておく。 $masterLDAP = <LDAPサーバーのホスト名> $slaveLDAP = <LDAPサーバーのホスト名> $suffix = <ベースサフィックス> $binddn = <LDAP管理者DN> $bindpasswd = <LDAP管理者パスワード> $SID = <「net getlocalsid」コマンドで取得したSID>
これ以外にも必要な項目については、適宜設定しておこう。 # smbldap-populate.pl Windowsマシンのドメイン参加SambaマシンやWindows NT/2000/XPをドメインメンバに追加する場合は、PDC上でドメインメンバのマシンアカウントを作成する。 PDC上でのマシンアカウントの作成まずは、PDC上のroot権限で、ドメイン管理用ユーザーdomainaddを作成しよう。 # smbldap-useradd.pl -a -d /dev/null -s /bin/false \ > domainadd -g "Domain Admins" # smbldap-usermod.pl -u 0 domainadd # smbldap-passwd.pl domanadd 後は、ドメインメンバのマシン分だけ以下のコマンドを実行する。 # smbldap-useradd -w <Windowsマシン名>
Windowsマシン上での作業
Windows NT/2000/XP（注4）上では、まずAdministratorとしてログオンする。コントロールパネルの「システム」のプロパティにおいて、「ネットワークID」タブの［ネットワークID］のボタンをクリックしよう。「ユーザーアカウントとドメイン情報」において、Samba PDCで設定したdomainaddユーザーとパスワード、ドメイン名を入力する【図5】。最後に、「ドメインへようこそ」というダイアログが表示されればOKだ。
ユーザーとグループの追加
ユーザーの追加はsmbldap-toolsだけで可能だが（pdbeditコマンドは不要）、グループの追加にはsmbldap-toolsに加えて「net groupmap」コマンドが必要となるので注意しよう。とくに、必須グループ（Domain Admis、DomainGuests、Domain Users）の登録を忘れないでほしい。 # smbldap-useradd.pl -a -m odagiri と実行し、Sambaドメイン環境でグローバルグループdevを作成する場合は次のように実行する。 # smbldap-groupadd.pl dev # net groupmap add ntgroup=dev unixgroup=dev type=domain ドメインログオン設定とユーザーの追加が終了したら、Windowsクライアントをリブートし、設定したWindowsドメインへログオンする。事前にログオンスクリプトを準備しておけば、問題なく動作するはずだ。
変更点に注意した設定を
以上、Samba 3.0.0によるケース別の構築方法を駆け足で解説した。使い方が少し難しくなったが、魅力満載の機能が増えたともいえるだろう。今後の品質向上についても期待したいところだ。
Part 4 既存環境からの移行方法
移行可能な形態
Samba 3.0の目玉機能の1つは、NTドメイン環境からの移行である。Samba 3.0では、次のような環境からの移行作業が可能となっている。
Windows NT 4.0をPDCとした既存のNTドメイン環境は、「net vampire」コマンドを使用することでSamba3.0へ移行可能だ。この場合、ユーザー管理データベース（passdb backendパラメータ）としてSamba 3.0のldapsamが推奨されるが、Samba 2.2互換モード（ldapsam_compat）も利用できる。これによって、Samba 3.0でWindows NT 4.0ドメイン環境をLDAPへ移行した後、Samba2.2での運用も可能となる。
Samba 2.2でユーザー管理データベースとしてsmbpasswdファイルを使用していた場合、Samba 3.0のtdbsamやldapsamの環境へ移行可能だ。
Samba 3.0においてユーザー管理データベースにsmbpasswdやtdbsamを使用していた場合、tdbsamやldapsamの環境へと移行可能だ。
NTドメイン環境からの移行
実際に、NTドメイン環境をSamba 3.0へ移行してみよう。 2.2との移行手順の違い
Samba 3.0での移行手順は、Samba 2.2の場合と少し異なっている。Samba 3.0では作業手順が大幅に減少するうえ、新しいLDAP用Samba 3.0スキーマを利用すると、各ユーザーのSIDやRID、プライマリグループ情報など、Samba 2.2では移行できなかった情報や移動プロファイルなどにも対応できる（Samba2.2互換LDAPスキーマを使用した場合は、移動プロファイルなどが移行できない）。
Samba 2.2 の場合
Samaba 3.0 の場合
移行方法それでは、実際に移行作業を行ってみよう。ここでは、Part 3の 【リスト9】 に示したsmb.confをベースに解説する。
現状での問題点NTドメインから移行してみたところ、現状では以下のような制限が存在した。実際に移行するときは、この点に注意してほしい。
Samba2.2からの移行
Samba 2.2からの移行は、比較的簡単だ。ユーザー管理データベース別に紹介しよう。 smbpasswdの利用Samba 2.2においてユーザー管理データベースにsmbpasswdを使用していた場合、smb.confで、 passdb backend = smbpasswd と指定すれば、smbpasswdによって継続利用できる。 tdbsamの利用smbpasswdからtdbsamへ変更したい場合は、pdbeditコマンドを使用する。 # pdbedit -i smbpasswd:/etc/smbpasswd \ > -e tdbsam:/etc/samba/passdb.tdb これによって、/etc/smbpasswdのデータが/etc/samba/passdb.tdbへ移行される。 LDAPの利用Samba 2.2でLDAPを使ったPDCを構築している場合は、まずslapcatコマンドによってLDAPデータをLDIFファイルへエクスポートする。 # slapcat -l <LDIFファイル> 後は、このLDIFファイルを利用して、Samba 3.0.0のソースアーカイブ（examples/LDAP以下）に含まれるconvertSambaAccountスクリプトでSamba 3.0用スキーマへ変換する。 # convertSambaAccount --sid=<SID> \ > --input=<変換前のLDIFファイル> \ > --output=<変換後のLDIFファイル> 変換後のLDIFファイルを、slapaddコマンドでLDAPへ投入すれば完了だ。 # slapadd -l <LDIFファイル>
Samba3.0からの移行
Samba 3.0どうしでも、ユーザー管理データベースの変更を伴う移行は可能だ。この作業は、すべてpdbeditコマンドで行う【実行例2】。 【実行例2】ユーザー管理データベースのの変更・smbpasswdからtdbsamへの変更 # pdbedit -i smbpasswd:/etc/smbpasswd -e tdbsam:/etc/samba/passdb.tdb ・tdbsamからldapsamへの変更 # pdbedit -i tdbsam:/etc/samba/passdb.tdb -e ldapsam:ldap://<LDAPサーバー>
ユーザー管理機能だけでも利用する価値あり
Samba 3.0の主要機能を解説してきたが、理解していただけただろうか？ Samba 3.0に対する筆者の感想としては、品質的に問題のある部分も残っており、すべての用途において移行を勧められる状況とはいい難い。現在、ミラクル・リナックスのメンバーをはじめとする日本Sambaユーザ会が鋭意努力中なので、成果に期待してほしい。
|
|
|
|
|
include
|
|
|
|
|
