MIRACLE

メールサービス申込 ユーザー登録&ログイン パートナー情報
お問い合わせ FAQ サイトマップ
MIRACLE LINUXの特長 製品紹介 サービス案内 購入 サポート 技術フォーラム

テクノロジー情報

技術フォーラム


Samba 3.0がやってきた

UNIX USER 2003年12月号掲載
※掲載記事の内容とは若干異なります。

  Part 1  2.2系と3.0系のバージョン選択基準
  Windowsネットワークへの参加

  SambaはUNIX/LinuxマシンとWindowsネットワークとの接続性を実現するため、Windowsのファイルサーバー/プリントサーバー機能を実装したオープンソースソフトウェアだ。
  1992年、NFSに代わるファイル交換ツールとしてAndrew Tridgell氏によって開発され、その後、ドメインコントローラやディレクトリサービスを利用した大規模ユーザー管理機能など、Windowsドメイン環境を置き換えるツールとしての地位を築いてきた。
  そのSambaが、約2年ぶりに3.0へとメジャーバージョンアップされたので、まずは変更点を中心に紹介する。

  Samba3.0 は必要か?

  長い年月をかけて待ちに待ったSamba 3.0だが、すべてのユーザーにとって最適な選択であるとは限らない。そこで新機能の詳細について触れる前に、Samba 3.0の必要性について確認しておく。
  Samba 2.2のリリース時には、「Samba 2.0でWindows XPと接続すると問題が発生する」という明確な問題点があったため、LAN内にWindows XPマシンを導入する場合はバージョンアップが必要となった。ところが今回は、以前のバージョンでも致命的な不具合は存在しない。
  つまり、Samba 2.2でもWindows Server 2003との問題は発生しないわけだ(もちろんSamba 3.0でも問題ない)。
  では、どのようなユーザーにとって、Samba 3.0は有用なのだろうか? 【表1】 にそれぞれのケースをまとめてみた。このように、Samba 3.0を利用するメリットは、LDAPとの連携強化や大規模システムへの対応など、企業ユーザーがWindowsドメインコントローラの代替として利用することにある。逆に、機能が増えたことで使い方が難しくなったうえ、日本語利用における品質が低下しており、現時点では個人ユーザーへ勧めにくい状況といえる。
  ただし、Samba 3.0も徐々に品質が向上し、日本語ドキュメントが充実してくれば、万人に勧められる状態になるだろう。現在、ミラクル・リナックスでは、経済産業省の外郭団体である情報処理振興事業協会(IPA)の支援を受け、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(チケット方式)認証が利用可能となる。セキュリティを重視するユーザーにとっては有用な機能だ。
  ただし、残念ながらADサーバーとしての機能は備わっていない。SambaサーバーをPDC(Primary Domain Controller)にした場合は、Kerberos認証は利用できなくなる。

  通信路上のUnicodeサポート

  Samba 2.2のドメインコントローラ機能はWindows NT 4.0をベースに開発されているものの、Windowsクライアントとの通信で使用される文字コードはWindows 9xと同じシフトJISである。このため、一部のWindowsアプリケーションでは互換性の問題が発生していた。
  たとえば、Windows 9xのDOSプロンプトで問題が発生する【実行例1】。これは、本来Windows側の不具合なのだが、Unicodeを利用して通信するWindows NT 4.0では発生しない。
  Samba 3.0では、Windowsクライアントとの通信で使用される文字コードがWindows NT/2000/2003と同じUCS-2(Unicode)へと変更された。このため、Samba 2.2で問題となっていた通信時に使用される文字コードによるトラブル(注1)も解決するだろう。
  このような通信経路のUnicode化は、個人ユーザーにとってそれほど大きなメリットではない。むしろ、Unicodeと既存文字コードとの変換テーブルの問題など、注意すべき点が増えている。

(注1) ネットワークアプライアンス社のNetAppFilerには、Windowsドメインへ参加してユーザー管理機能をWindowsサーバーに任せる機能が備わっている。ただ、ユーザー情報をWindowsから入手するときのコードがUnicodeのため、Samba 2.2がドメインサーバーになっている場合、NetAppFilerはドメインへ参加できなかった。

【実行例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)を参照する。
  詳細については後述するが、Sambaサーバーをドメインコントローラにして、WindowsのADドメインのような大規模なユーザー管理機構が必要ならば、ldapsam機能を利用したほうが良いだろう。
  ここで注意してほしいのが、「passdb backendパラメータはユーザー管理データベース(パスワードの格納先)を指定するものであって、認証方法を指定するものではない」という点だ。たとえば、ユーザー管理データベースにLDAPを利用したとしても、WindowsクライアントとSambaサーバーの認証については、(LDAPプロトコルによる)LDAP認証を使用できない。どのような場合でも、Sambaサーバーの認証は(SMBプロトコルの)NTLM認証となる(AD連携を使用したときのみKerberos認証)。
  さらに、SambaサーバーとLDAPサーバー間の接続は、LDAP管理者の権限でのみ行われ、各ユーザーの認証は、SambaサーバーがLDAP管理者の権限でLDAPデータを読み出した後、ユーザーのNTLM認証を行う仕組みになっている。
  以上の結果、passdb backendパラメータの推奨値は次のようになる。

  • 新規に単体のSambaサーバーを構築するなら「tdbsam」
  • 既存のSamba 2.2からそのまま移行したいなら「smbpasswd」
  • 複数サーバーでドメインを構築したり、既存のNTドメインから移行したいなら「ldapsam」
  • すでにSamba 2.2でLDAP環境を構築しており、3.0と混在させたいなら「ldapsam_compat」
  • すでにNIS+やMySQLでOSのユーザー管理/認証を構築しているなら「nisplussam」や「mysqlsam」
  名前変換アルゴリズムの変更

  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が永続的でなく、一部のプログラムで問題が発生した。
  一方、Samba 3.0では、名前変換のアルゴリズムが変更され、smb.confのmangling methodパラメータのデフォルトは新しいアルゴリズム「hash2」となった(注2)。ただし、hash2アルゴリズムは現時点で日本語が考慮されていないので、従来の変換アルゴリズム「hash」を指定したほうが良いだろう。

(注2) Samba 3.0アルファ版のロードマップには「生成したSFNをデータベースに記録し、永続的に保存する」という記述があったが、現時点では実現されていない。

  netコマンドのサポート

  Windowsに付属する管理用のnetコマンドが、Sambaでも標準サポートされた。このコマンドによって、SambaサーバーとWindowsサーバー、いずれに対しても 【表3】 のような操作が可能となった。
  たとえば、Windows NT 4.0からの移行では、まずSambaサーバーをBDC(Backup Domain Controller)として追加し、「net vampire」コマンドでユーザー情報やグループ情報をSambaサーバー側へ複製する。その後、SambaサーバーをPDCとして設定し直せば、Windows NTドメインを簡単に移行できるわけだ。
  また、Windows NT 4.0ドメインとの信頼関係についても、netコマンドを使うことで簡単に実現できるようになった。

  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の中に保存される。
  なお、個々のファイルやディレクトリに関するACLは、従来どおりファイルシステム(XFSなど)がサポートしていれば利用可能だ。

  グローバルグループ機能の追加

  従来のSamba 2.2でもsmb.confn中でDomain Adminsグループを指定できたが、Samba 3.0ではnetコマンドを実行することでWindowsと同等のグローバルグループが利用できるようになった。また、グループマッピング機能もサポートされたため、UNIX/LinuxのグループをWindowsのグループに対応可能だ。マッピングのサンプルとして、 【リスト1】 のようなものが用意されている。
  この機能によってSambaのグループ管理は高機能化されたが、逆にグループ管理の手順は大変面倒になった。たとえば、Samba 2.2ではグループ管理をOSに任せていたので、groupaddコマンドだけでOKだったが、Samba3.0ではgroupaddコマンドに加えて、netコマンドも実行する必要がある。とくに、LDAPSAM機能を使った場合のグループ管理は複雑で、初心者には敷居の高いものとなっている。
  Samba 3.0用のsmbldap-toolsはグループ管理に対応していないので、早急な改善が望まれる。

  日本語文字コードの変換方式

  前述のとおり、クライアントとの通信時の文字コードがシフトJISからUCS-2へ変更されたが、Samba 3.0では文字コードの変換方式についても変更されている。従来はcoding systemパラメータ、client code pageパラメータで文字コードを指定し、コード変換ロジックはSambaの内部に持っていたが、Samba 3.0では 【表4】 のパラメータで文字コードを指定し、コード変換は外部のiconvライブラリを使用するようになった【図】。
  各パラメータの値にはiconvライブラリがサポートする各種形式を指定するため、Samba 2.2日本語版のようなコード変換の不具合に対する修正を行う必要がなくなったものの、iconvライブラリの問題により、Samba 2.2で解決した日本語の問題が再発するようになった。さらにiconvライブラリでは、CAP(マッキントッシュとの共有用)やHEX(16進表記)が未サポートである。
  Samba 3.0で日本語が正常に扱えるかどうかは、iconvの機能と品質に依存してしまう。現在、WebDAVなどが抱えているものと同じ問題であり、「〜」や機種依存文字が利用できない。古い商用UNIXなどiconvライブラリを搭載していないUNIXマシンでは、Samba 3.0で日本語が利用できないので注意してほしい。
  日本語問題への対策についてはPart 2で解説する。

【図】Samba 3.0 における文字コード
概要図

  環境に応じたバージョンを選択しよう
  多くの新機能が追加されたSamba 3.0だが、日本語への対応という面では若干手間が増えている。また、大規模向けの新機能がメインであるため、個人ユーザーが導入および移行するには悩むところだろう。Part 2以降の具体的な導入および設定作業を参考にして、環境に応じたシステムを構築してほしい。
  Part 2  インストールの詳細と日本語対策
  Samba3.0の導入

  Part 1で解説したとおり、Samba 3.0で日本語を利用するには、iconvライブラリが必要となる。したがって、事前にiconvライブラリを導入しておかなければならない。
  2003年10月10日現在、Samba 3.0系の最新版はバージョン3.0.0である。ソース以外に、RPM系Linuxディストリビューション用バイナリパッケージも用意されているので、初心者はこちらを利用したほうが簡単に導入できるだろう。
  まずはRPM系のパッケージを利用したインストール方法から紹介する。

  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つの方法が考えられる。

  1. glibcに対してCP932対応パッチを適用(注3)
  2. CP932対応パッチを適用したlibiconvの導入
  どちらを選択しても良いが、以下の違いに留意してほしい。
  • glibcにCP932対応パッチを適用する作業は複雑である
  • glibcにCP932対応パッチを適用すると、Linuxディストリビューション側に備わっている自動アップデート機能が利用できなくなる
  • 最近のLinuxディストリビューションはlibiconvを同梱していない

  これらを考慮すると、最近のLinuxディストリビューションおよびUNIX系であれば、CP932対応パッチを適用したlibiconvを導入すると良いだろう。ただし、glibcにCP932対応パッチを適用する場合はSambaの公式サイトにあるRPMパッケージが利用できるが、libiconvにパッチを当てる際はconfigureスクリプト実行時にlibiconvの指定が必要となるため、この処理を行ったRPMパッケージを利用しなければならない。

(注1) CPとはCode Pageの略で、国別の文字セットを表したものである。
(注2) Mac OS X 10.3は、CP932の変換用ライブラリを持っているようだ。
(注3) MIRACLE LINUX V2.1の場合、CP932をサポートしたGLIBCを提供している。

  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パッチを入手する。

  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
(注4) 古いバージョンのtarコマンドでは、「j」オプションではなく「I」オプションを指定する。

  続いて、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を動作させるには、これらのファイルの準備、およびシステム側の設定ファイルの変更が必要となる。
  なお、ここでは設定ファイルの内容の詳細については扱わない。ソースディレクトリのexamples以下やpackaging以下にはサンプルファイルなどが存在するので、これらを参考にすると良いだろう。

  smb.conf

  Sambaの設定ファイルであり、これがないと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以下に収録したので、参考にしてほしい。
  なお、設定ファイルの置き場所は、configureスクリプトの「--with-configdir=<dir>」で指定したディレクトリとなる(デフォルトは/usr/local/samba/lib)。

  smbpasswd、passdb.tdb

  Sambaユーザー用のパスワードを格納するファイル。
configureスクリプトの「--with-privatedir=<dir>」で指定した場所(デフォルトは/usr/local/samba/private) に、pdbeditコマンドの実行によって自動的に作成される。
  LDAPを利用する場合を含めて、ファイル作成作業は必要ないが、格納されるディレクトリだけは必ず作成しておこう。

  SWAT用の設定

  Sambaの設定/管理をWebブラウザ経由で行うため、専用WebインターフェイスSWATが用意されている。これはinetd/xinetd経由、あるいはWebmin 経由で利用するが、前者の場合、/etc/servicesに次の行を追加しておく。

swat        901/tcp

  さらに、システムがinetdとxinetdのどちらを使用しているのか確認し、 【リスト1】 のような設定を行う。
  SWATでの認証用としては、各システムにあわせた設定が必要となる。たとえば、Red Hat Linux 9であれば、 【リスト2】 のような/etc/pam.d/sambaファイルを作成する。これは、ソースディレクトリのpackaging/RedHat以下にあるsamba.pamdをコピーしても良いだろう。

  /etc/logrotate.d/samba

  Sambaのログを定期的にローテーションさせるには、ログローテーション用の設定ファイルを用意する。たとえば、Red Hat Linux 9であれば、 【リスト3】 のような/etc/logrotate.d/sambaファイルを作成しよう。これは、ソースディレクトリのpackaging/RedHat以下にあるsamba.logをコピーしても良い。

  起動スクリプトの準備

  システム起動時にSambaを自動実行させるには、システムにあわせた起動用スクリプトを用意する。たとえば、Red Hat Linux 9であれば、 【リスト4】 のような/etc/rc.d/init/smbファイル(注5)を作成しよう。
  また、Winbindを利用する場合は、 【リスト5】 のような起動スクリプトも用意すること。

(注5) 最近のFHSに準拠したLinuxディストリビューションでは、/etc/init.d/smbとなる。Red Hat Linux 9でも、/etc/init.dはシンボリックリンクとして存在する。

  Sambaの起動設定

  起動スクリプトが用意できたら、それらがシステム起動時に読み込まれるように設定する。たとえば、Red Hat Linux 9であれば、

# chkconfig smb on
および
# chkconfig winbind on

と実行することで、現在のランレベルにおいてシステム起動時にSambaが自動実行されるようになる。
  以上によって、Samba 3.0が起動したはずだ。また、WebブラウザからSambaサーバーの901/tcpへアクセスすることで(Webmin経由でSWATを利用する場合はWebminへアクセス)、設定/管理用の画面が表示されるだろう【図】。

【図】SWATでの設定(図は動作状況の画面)
画面のイメージ
  開発者へのフィードバックが安定したSambaを生む

  筆者がLinux関連の仕事をしているため、Linux中心の解説となってしまったが、Sambaの開発チーム自体もLinux中心で開発を進めている。したがって、動作検証などもLinuxを重点的に行っているのも事実だ。
  それ以外のUNIX系OSで問題が発生した場合は、積極的に開発者へフィードバックしてほしい。そのような行動は、Sambaの安定性の向上へとつながっていくはずだ。

  Part 3  ケース別に見るSambaサーバー構築時の注意点
  スタンドアロンサーバーの構築

  最初に、Sambaを用いたスタンドアロンサーバーの構築方法について解説する。スタンドアロンサーバーとは別のホストと連携することなく単独で利用するもので、Windowsでいうワークグループサーバーのことである。この場合、ユーザーやグループの管理が重要なポイントとなる。
  ここでは、典型的な設定ファイル 【リスト1】 を基に注意点などを解説する。

  ユーザー管理データベースの選択

  Part 1でも説明したが、Samba 3.0の推奨設定ではスタンドアロンサーバー構築時のユーザー管理データベースとしてTDBを利用する。これは、Samba 2.2で一般的に利用していたsmbpasswdと比較して、性能や拡張性の面で優れている。
  実際の設定は、globalセクションでpassdb backendパラメータを指定する。

passdb backend = tdbsam
  ユーザー管理

  Samba 2.2におけるユーザーの追加作業は、システム側のuseraddコマンドを実行した後、Samba側のsmbpasswdコマンドを実行した。一方、Samba 3.0ではpdbeditコマンド 【表1】 とnetコマンドが提供されている。
  たとえばSambaユーザーodagiriを作成する場合は次のように実行する。

# useradd odagiri ←システム側にユーザーを追加
# pdbedit -a -u odagiri

  pdbeditコマンドはpassdb backendパラメータとして「tdbsam」、「smbpasswd」、「ldamsam」のいずれかを利用した場合にユーザーを管理できるが、事前にシステム側でもユーザーを追加しておく必要がある。
  netコマンドでユーザーを追加する場合は、

# net rpc user add odagiri

と実行し、管理対象がSambaでもWindowsでもユーザー管理可能だが、ネットワーク経由でアクセスするためのユーザー/パスワードが必要だ。
  pdbeditコマンドとnetコマンドの大きな違いは、実行する場所である。pdbeditコマンドはSambaマシン上(root権限)で実行しなければならないのに対して、netコマンドはリモートのサーバーに対して実行可能で、Windows Server 2003にも対応している。しかも、smb.confでadd group scriptパラメータやadd user scriptパラメータを指定しておけば、システム側でのuseraddコマンドやgroupaddコマンドの実行を省略できる。
  ただし、netコマンドを実行する際は、Samba側に管理者ユーザー(rootやAdministrator)を登録しておき、そのユーザーとパスワードを用いることになる。したがって、通常はpdbeditコマンドを利用したほうが良いだろう。
  なお、Samba用パスワードの設定/変更は、smbpasswdコマンドで行う。

  グループの管理

  Samba 2.2ではグループ管理機能を実装していなかったため、システム側のgroupaddコマンドでグループの追加を行えば良かった。ところが、Samba 3.0からはグループ管理機能を実装したため、groupaddコマンドに加えてnetコマンドでグループ管理を行わなければならない。さらに、SambaでWindowsドメイン環境を構築する場合、グローバルグループとローカルグループを区別できるようになったことで、管理上もこれらを使い分ける必要が出てきた。
  グループ管理におけるnetコマンドの書式は 【リスト2】のとおりで、たとえばスタンドアロンサーバー環境でローカルグループdevを作成するには、

# groupadd dev
# net groupmap add ntgroup=dev unixgroup=dev type=local

のように実行し、Sambaドメイン環境でグローバルグループdevを作成するには、

# groupadd dev
# net groupmap add ntgroup=dev unixgroup=dev type=domain

のように実行する。
  また、Sambaのグループ管理に先だって、次のグループを作成しておく必要がある。

  • スタンドアロンサーバー環境で必須なグループ
    Administrators、Guests、Users
  • Sambaドメイン環境で必須なグループ
    Domain Admis、Domain Guests、Domain Users

  これらのグループは、netコマンド(注1)を利用して登録しておこう【実行例1】。UNIX/Linux側のグループ名wheel、nobody、smbusersは、それぞれの環境に応じてカスタマイズしてほしい。

(注1) グループの追加は「net group add<グループ名>」でも可能だが、この場合、「net user」と同様にネットワーク経由でアクセスするためのユーザー/パスワードが必要になる。さらに、smb.confにおいてadd group scriptパラメータの設定が必要だ。

【実行例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からのユーザー/グループ管理が実現された。これによって、非常に管理しやすくなるだろう。
  Windows上での操作は、Windows NT/2000 Serverに付属するユーザーマネージャ(USRMGR.EXE)で行う【図1】。Windows 2000 ProfessionalやWindows XP、Windows Server 2003には付属しないが、Windows NT4.0やWindows 2000のサービスパックに含まれているので(「/x」オプション指定で展開できる)、これを利用すると良いだろう。
  ただし、ユーザーマネージャを利用するには、【リスト1】のようにsmb.confで次のパラメータを指定しておく必要がある。

  • add user script
  • add group script
  • add user to group script
  • delete user from group script
  • set primary group script
  • add machine script
  • delete group script
  • delete user script
【図1】ユーザーマネージャによる管理
画面のイメージ

  メンバサーバーの構築

  続いて、既存のADドメインに対して、Sambaサーバーをメンバサーバーとして登録してみよう。ここでは、ドメインコントローラとしてWindows 2000 Server/Server 2003が動作していることを前提とする。
  WindowsドメインコントローラにユーザーAdministratorでログインし、「Active Directoryのユーザーとコンピュータを管理する」から管理ツールを起動して、コンピュータをドメインに追加する【図2】。このとき、「このコンピュータアカウントをWindows 2000以前のコンピュータとして割り当てる」をチェックしてほしい【図3】。次に、smb.confのsecurityパラメータを「domain」に変更し 【リスト6】、 Sambaマシン上からnetコマンドでドメインへ参加する。

# 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+LDAPサーバーの環境構築手順について解説する。

  Samba 3.0.0での問題点

  Samba 3.0.0をLDAPサーバーと連携させる場合、注意すべき点がある。LDAPスキーマを作成するための環境が用意されていないため、手順を間違えると正常に動作しないのだ(注2)。この状況は、後述するsmbldap-toolsが改良されれば解決するだろう。

(注2) vampire機能を利用してWindows NT Server 4.0からSamba 3.0+LDAPへ移行するほうが簡単である。

  OpenLDAPの導入

  Sambaのldapsam機能はOpenLDAPをベースに開発されているが、OracleやNovellなどのLDAPサーバーにも対応しており、スキーマさえ登録すれば問題なく利用可能だ。ここでは、OpenLDAP 2.0.27による構築方法を解説する。

  RPMパッケージの利用

  Red Hat系Linuxディストリビューションの場合、RPMパッケージが用意されているので、これらを利用すると簡単だ。
    http://updates.redhat.com/
    MIRACLE LINUX OpenLDAP
  具体的には、【実行例2】のようにインストールすれば良い。

【実行例2】RPMパッケージを利用したOpenLDAPのインストール
# 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/
  2003年10月10日現在、RPMパッケージの最新版は2.0系がほとんどだが、ソースの最新版は2.1.23である。ここではRPMパッケージにあわせるために2.0系を用いるが、2.1系でも問題なく動作するだろう。
  ソースアーカイブを入手したら、適当なディレクトリで展開する。

# tar xfz openldap-2.0.27.tgz

  展開後、ソースディレクトリでconfigureスクリプトを実行するが、ここでは【実行例3】のオプションを指定した。オプションの詳細については、「--help」で出力される表示を参照してほしい。

# ./configure --help

  後は、依存関係を構築し、コンパイル、インストールすれば完了だ。

# make depend
# make
# make test
# make install
【実行例3】configureスクリプトで指定したオプション
# 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を利用するには、

  • LDAPサーバー動作用
  • LDAPクライアント用

という2種類の設定を行う必要がある。1.はLDAPデーモンを動作させるサーバーのみ行えば良く、2.はWindowsを除くすべてのUNIX/Linuxマシン(LDAPサーバーのマシン自体も含む)で行わなければならない。

  LDAPサーバー動作用の設定

  設定が必須なファイルは、/etc/openldap/slapd.confだけである。ここではSambaでドメイン環境を構築する際の関連事項のみ解説するので、OpenLDAPの詳細な設定方法については以下のWebページなどを参照してほしい。

  まずは、 【リスト7】 に示したslapd.confのサンプルファイルを見てほしい。これをベースとして、次にあげる4つのパラメータに関連する作業を行う。


include

  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

  ベースサフィックスは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)なども使われるが、ユニークであれば何を使ってもユーザーの自由である。また、大文字・子文字の区別はない。


rootdn

  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"

rootpw

  LDAPサーバーの管理者パスワードは、rootpwパラメータで設定する。テスト環境では平文のパスワードを指定しても良いが、実運用では暗号化したものを用いてほしい。
  たとえば、パスワード「miracle」をMD5ハッシュする場合は、slappasswdコマンドを使用して次のように実行する。

# slappasswd -s miracle -h {MD5}
{MD5}0SLYzLSMIRdTdundlie/5A==

  ここで表示されたものをrootpwで指定すれば良い。

rootpw = {MD5}0SLYzLSMIRdTdundlie/5A==

  なお、rootdnパラメータとしてLDAPに登録されているユーザーを指定し、LDAP内にパスワードが格納されている場合は、rootpwを省略できる。
  設定終了後、OpenLDAPデーモンを起動しよう。

# service ldap start

  無事に起動したら、システム起動時に自動実行するように設定しておく。

# chkconfig ldap on
  LDAPクライアントとしての設定

  LDAPクライアントとなるすべてのUNIX/Linuxマシンでは、次の4つのファイルについて設定を行う必要がある。

  • /etc/ldap.conf
  • /etc/openldap/ldap.conf
  • /etc/nsswitch.conf
  • /etc/pam.d/system-auth

  Red Hat LinuxやMIRACLE LINUX V2.xでは、設定ツールauthconfigが提供されているので、これを利用すると良いだろう。LDAPサーバーが動作しているマシンではサーバーを127.0.0.1とし、それ以外ではLDAPサーバーのIPアドレスやホスト名を指定する【図4】。
  authconfigで設定後、/etc/nsswitc.confと/etc/openldap/ldap.conf、/etc/pam.d/system-authの内容が以下のように変更されるので確認しておこう。なお、authconfigが存在しない場合は、各ファイルを手動で修正していくことになる。

/etc/nsswitch.conf

ネームサービススイッチの設定ファイル/etc/nsswitch.confでは、次のようなLDAPに関する設定が必要となる。

passwd:   files  ldap
shadow:   files  ldap
group:    files  ldap

/etc/ldap.confと/etc/openldap/ldap.conf

nss_ldapとpam_ldapの設定ファイルである/etc/ldap.confを編集し、ユーザーの組織と検索ベースを反映させる。/etc/openldap/ldap.confはldapsearchやldapaddなどのコマンドラインツール用設定ファイルであり、これもLDAP設定に合わせて編集する必要がある。
authconfigによって、両ファイルとも、

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

のような内容も追加しておこう。

/etc/pam.d/system-auth

PAM用設定ファイル/etc/pam.d/system-authには、次のような行が追加される。

auth sufficient /lib/security/pam_ldap.so use_first_pass

UNIX/Linuxにssh/telnetでログインして使用する場合は、自動ホームディレクトリ設定機能も指定しておくと良いだろう 【リスト8】。
最後に、各マシン上でnscd(Name Service Cache Daemon)を起動しておく。

# service nscd start
# chkconfig nscd on

これによって検索結果がキャッシュされるため、アクセスが高速になる(これを起動させなくてもLDAPの動作に支障はない)。

【図4】authconfigの実行画面
画面のイメージ

  Samba側の設定

  SambaサーバーをPDC/BDCとしてドメインを構築する場合、PDC/BDC/メンバサーバーのsmb.confファイルを 【表2】 のように設定する。

  SambaとLDAPを利用した環境では、ユーザー情報はすべてLDAPに格納されているので、PDC/BDCといった役割は簡単に変更可能だ。したがって、Sambaを複数台利用する場合は、1台だけPDCを設定し、それ以外はすべてBDCにすると良いだろう。また、SambaをPDCにするときはWINSサーバーにしたほうが良いが、その際、WindowsクライアントにおけるWINS設定の変更も忘れずに行ってほしい。
  そのほか、smb.confで設定すべき項目は、次のとおりである(これ以外の項目についてはSWATのドキュメントなどを参照)。

  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パッケージが用意されているので、そちらを利用してほしい。
    http://samba.idealx.org/dist/

  必要な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】 のスクリプト群がインストールされる。

(注3) MIRACLE LINUX V2.1では、これ以外にもNet_SSLeay.pm-1.25.tar.gz、Test-Simple-0.47.tar.gz、File-Temp-0.14.tar.gzが必要だった。

  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スクリプトを実行するだけで、初期化データが投入される。

# 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マシン名>

は英数字(子文字)で15バイト以下とし、日本語は使用できない。

  Windowsマシン上での作業

  Windows NT/2000/XP(注4)上では、まずAdministratorとしてログオンする。コントロールパネルの「システム」のプロパティにおいて、「ネットワークID」タブの[ネットワークID]のボタンをクリックしよう。「ユーザーアカウントとドメイン情報」において、Samba PDCで設定したdomainaddユーザーとパスワード、ドメイン名を入力する【図5】。最後に、「ドメインへようこそ」というダイアログが表示されればOKだ。

(注4) Samba 2.2をPDCにしてWindows XP/Server2003をドメインに参加させる場合、Windows側の「ローカルセキュリティポリシー」を変更しなければならなかったが、Samba 3.0では必要なくなった。
【図5】「ユーザーアカウントとドメイン情報」の入力
画面のイメージ


  ユーザーとグループの追加

  ユーザーの追加はsmbldap-toolsだけで可能だが(pdbeditコマンドは不要)、グループの追加にはsmbldap-toolsに加えて「net groupmap」コマンドが必要となるので注意しよう。とくに、必須グループ(Domain Admis、DomainGuests、Domain Users)の登録を忘れないでほしい。
  たとえば、Sambaユーザーodagiriを作成する場合は、

# 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では、次のような環境からの移行作業が可能となっている


NTドメイン環境からの移行

  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互換モードでは各ユーザーのSIDが移行できないので、移動プロファイルが保持できなくなる。


Samba 2.2からの移行

  Samba 2.2でユーザー管理データベースとしてsmbpasswdファイルを使用していた場合、Samba 3.0のtdbsamやldapsamの環境へ移行可能だ。
  一方、Samba 2.2でLDAPによるPDCを構築していた場合、一度LDIF(LDAP Data Interchange Format)形式のファイルにエクスポートすることで、Samba 3.0の新しいスキーマへと移行できる。


Samba 3.0からの移行

  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スキーマを使用した場合は、移動プロファイルなどが移行できない)。
  SIDが保持できるようになったことで、Windows NT上のNTFSにおけるACL情報もSamba 3.0へ移行可能だ。ただし、Samba 3.0側にはXFSなどのACLをサポートしたファイルシステムが必要となる。

NTドメインからの移行手順
  Samba 2.2 の場合
  1. (PDCにする)SambaマシンをNTドメインに追加
        ↓
  2. NTドメインからユーザー情報、グループ情報を抽出
        ↓
  3. ユーザー情報、グループ情報をsmbldap-toolsを使ってLDAPへ投入
        ↓
  4. 共有データをWindows NTからSambaへコピー
        ↓
  5. NTドメインのSIDをSambaへコピー
        ↓
  6. SambaマシンをLDAP用に修正し、PDCとして設定
  Samaba 3.0 の場合
  1. NTドメインのSIDをSambaへコピー
        ↓
  2. (PDCにする)SambaマシンをNTドメインに追加
    (この時点でSambaはBDC相当になる)
        ↓
  3. 共有データをWindows NTからSambaへコピー
        ↓
  4. 「net rpc vampire」コマンドでユーザー情報、グループ情報を移行
        ↓
  5. SambaマシンをPDCとして設定


  移行方法

  それでは、実際に移行作業を行ってみよう。ここでは、Part 3の 【リスト9】 に示したsmb.confをベースに解説する。

  1. netコマンドによるSIDのコピー

      まずは、Samba起動用の設定ファイルsmb.confを準備しよう。Part 3の 【リスト9】 から変更する点は、次のパラメータである。

    domain master=no
    os level = 20
    wins server= <Windows PDCのWINSサーバー>
    

      そのほか、LDAPのスキーマとしてSamba 2.2互換モードを利用したい場合は、以下のパラメータも変更する。前述のとおり、これを利用することで移動プロファイルなどが移行できなくなるので注意してほしい。

    passdb backend = ldapsam_compat
    ldap server = <LDAPサーバー名>
    ldap port = 389
    

      Sambaを起動する前に、netコマンドで既存のSIDをSamba側へコピーする。

    # net rpc getsid
    

      実行後、Windows NT側とSamba側のSIDを表示させ、内容が同じであることを確認しよう【実行例1】。

    【実行例1】SIDの表示
    ・Windows NT側
    # rpcclient <NTサーバー名> -U Administrator%<パスワード> -c 'lsaquery'
    
    ・Samba側
    # net getlocalsid
    

  2. NTドメインへのSambaマシンの追加

      続いて、SambaマシンをBDCとしてNTドメインへ参加させる。これは「net join」コマンドによって行う。

    # net rpc join -S winnt -w <ドメイン名> \
    > -U Administrator%<パスワード>
    

      Sambaを起動して、正常に参加できているかを確認しよう。

    # service smb start
    

      確認後、smbldap-populate.plスクリプトによって初期化を行う。

    # smbldap-populate.pl
    
  3. 共有データのコピー

      共有データをSamba側へコピーする場合は、Windowsクライアントからエクスプローラでドラッグ&ドロップするのが簡単だ。ただし、Samba側でACLサポートのファイルシステムを利用しており、アクセス権限もコピーしたいときは、「/O」オプション指定のXCOPYコマンドを用いること。

    XCOPY <コピー元> <コピー先> /S /E /O /H /G /C
    
  4. ユーザー/グループ情報の移行

      netコマンドのvampire機能を利用して、ユーザー/グループ情報をSamba側へ移行させる。

    # net rpc vampire -S winnt -U Administrator%<パスワード>
    
  5. SambaマシンをPDCとして設定

      後は、Part 3で解説したように、SambaをPDCとして起動すれば完了だ。

  現状での問題点

  NTドメインから移行してみたところ、現状では以下のような制限が存在した。実際に移行するときは、この点に注意してほしい。

  • 日本語やシングルクォート(')を使ったユーザー/グループ、および名前の先頭が数字のユーザー/グループは移行できない(UNIX/Linux側の制限)
  • ホームドライブとしてネットワークドライブを指定しているユーザーは移行できない
  • マシンアカウントがou=Computersではなくou=Usersに登録される。ou=Computersに変更するには、LDAPデータをLDIFファイルにエクスポートし、DNを変更してからインポートする
  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ユーザ会が鋭意努力中なので、成果に期待してほしい。
  それまでは、「Samba 3.0のldapsam_compatでNTドメイン環境をLDAPへ移行し、Samba 2.2でファイルサーバーを運用する」という利用法があるだろうし、Samba 3.0のユーザー管理機能の品質がもう少し上がれば「Samba 2.2でファイルサーバーを運用しながらユーザー管理だけをSamba 3.0から(GUIで)管理する」という運用が選択できるだろう。

■この資料の評価をお願いします。
とても参考になった
参考になった
どちらでもない
あまり参考にならなかった
まったく参考にならなかった

コメントがある場合は以下に記述してください。技術資料として取り上げてほしいテーマも受け付けています。

以下は任意です。

お名前(フルネーム) :
会社名 :
メールアドレス :
 

ページトップへ



テクノロジー情報
リナックス関連
イベント/セミナー資料
オラクル/DB関連
Samba関連
研修のご紹介
FAQ
インストレーションガイド
ソフトウェアダウンロード
実績のあるシステム構成

会社情報 採用情報 個人情報保護方針 情報セキュリティ基本方針 商標等取り扱い事項 English
Copyright(c)2000-2015 MIRACLE LINUX CORPORATION. All Rights Reserved.