Chapter 5. バックアップドメインコントローラ

John H. Terpstra

Samba Team

Volker Lendecke

Guenther Deschner

LDAP updates 
Samba Team

Table of Contents

機能と利便性
基本的な背景情報について
Microsoft Windows NT4スタイルのドメイン制御
LDAP設定の注意
Active Directoryドメイン制御
ネットワーク上のドメインコントローラになれる要件
どのようにワークステーションがそのドメインコントローラを探すか?
バックアップドメインコントローラの設定
設定例
よくあるエラー
マシンアカウントが満了し続ける
SambaはNT4 PDCのバックアップドメインコントローラになれるか?
smbpasswdファイルの複製はどうやるか?
これをすべてのLDAPに使えるか?

このセクションを読み始める前に、ドメイン制御中で説明されているSambaドメインコントローラの設定に問題がないようにしておくこと。

機能と利便性

この章は、説明するのが最も困難な章の一つである。何を書いても、誰かがまだ実現できていない項目、あるいはまったく異なるアプローチを使った方が遥かに効果的に実現できる項目について、実現されたはずだと期待してSambaチームに問い合わせてくることを防止することはできないと思われる。もしこの章で説明されているはずなのに、いくら読んでも言及されない事項というのがある場合は、要件あるいは質問内容を明確に書いてJohn H. Terpstraまで電子メールで問い合わせてほしい。

Samba-3 は別のSambaプライマリドメインコントローラ(PDC)に対するバックアップドメインコントローラ(BDC)として機能することができる。Samba-3 PDCは、LDAPアカウントバックエンドとともに運用することができる。LDAPバックエンドは、共用のマスタLDAPサーバかスレーブサーバのどちらでも使える。スレーブLDAPサーバを使用する利点は、マスタがダウンしている時でもクライアントがネットワークにログオンできるということである。これによりSambaが高いレベルの拡張性を持つことになり、大規模な組織のための効果的なソリューションとなり得る。PDCにLDAPスレーブサーバを使用する場合、マスタの継続的な可用性を確保する必要がある。悪い時にスレーブ側から見てマスタがダウンしていると、安定性の問題や運用上の問題となる。

Samba-3 BDCをLDAPでないバックエンドとともに運用することも可能だが、バックエンドが何らかの形で「双方向の」伝達を許容し、BDC側からマスタへの変更が可能であるようにしなければならない。現段階でこれをできるのはLDAPのみである。PDCが、そのプライマリとしてLDAPマスタサーバを使うことが好ましい間、BDCはスレーブLDAPサーバを使うことが出来る。

LDAPでないバックエンドSAMデータベースを使用するのは問題に陥りやすくなる。なぜなら、ドメインメンバサーバもワークステーションも、マシン信頼アカウントのパスワードを定期的に変更するからである。新しいバスワードはローカルでしか保存されない。このことは、(LDAPベースのソリューションにあるような)集中的に格納されたアカウントデータベースが無く、Samba-3 がBDCとして動作しているとき、BDC 側のドメインメンバ信頼アカウントのパスワードの記録が、PDC(マスタ)のSAMのコピーに届かないことを意味する。もし、PDCのSAMがBDC側に複製されると、最新の(変更後の)信頼アカウントのパスワードを含むSAMが上書きされることになり、ドメイン信頼が無効になってしまう。

BDCの設定方法に関して挙げられたコメントや質問の数が多いので、可能な選択肢の一つ一つについて、おのおのの解について利点欠点を見てみよう。以下のドメインバックエンドアカウント分散オプション一覧は、PDC/BDC構成で設定可能な設定例の一覧である。

Table 5.1. 分散ドメインバックエンドアカウントの選択肢

PDCバックエンドBDCバックエンド補足事項

マスタLDAPサーバ

スレーブLDAPサーバ

高い整合性を提供する完全なソリューション。SAMは共通マスタLDAPサーバで 複製される。

単一の集中LDAPサーバ

単一の集中LDAPサーバ

フェイルオーバ機能がないが実用可能なソリューション。これは実用的なソリューションで あるが、完全ではない。

tdbsam

tdbsam + net rpc vampire

Samba-3.0では動かない。Sambaはサーバサイドプロトコル要求を実装していない。

tdbsam

tdbsam + rsync

この設定を使ってはいけない。TDBファイルが使用中の状態でデータがディスクに 完全に書き戻されていないかもしれないので、動作しない。 さらに、ドメインの信頼関係を壊すだろう。

smbpasswd file

smbpasswd file

この設定を使ってはいけない。 同期が遅延するためにエレガントな解ではなく、ドメイン信頼関係 の問題で悩むだろう。


基本的な背景情報について

ドメインコントローラは、ネットワーク上のワークステーションからのログオン要求に答えることが出来るマシンである。Microsoft LanManagerとIBM LanServerはこの機能を提供していた初期のプロダクトの2つである。その技術は、LanMan NetLogonサービスとして知られるようになった。

Microsoft Windows NT3.10 の最初のリリースで、新しいドメイン制御形式がサポートされ、同時に機能を拡張した新しい形のネットワークログオンサービスがサポートされることになった。このサービスは、NT NetLogon サービスとして知られている。このサービスの性質は、 Microsoft Windows NT の進化に伴って変更され、今日では洗練された各種技術の上に広範で複雑な各種サービスを実現している。

Microsoft Windows NT4スタイルのドメイン制御

NT4/200x/XP Professionalワークステーションにユーザがログオンするときはいつでも、ワークステーションはユーザが入力したユーザ名/パスワードペアが正しいかを検証するためにドメインコントローラ(認証サーバ)に接続する。もしも入力された情報がドメイン制御データベース(SAM、すなわちセキュリティアカウントマネージャデータベース)に格納されているアカウント情報と一致しない場合、認証要求を出したワークステーションに一連のエラーコードを返す。

ユーザ名/パスワードペアが検証されたとき、ドメインコントローラ(認証サーバ)はそのドメインに対するユーザとマシンアカウントデータベース中の、そのユーザに関係するアカウント情報の完全な項目一覧を返す。この情報はそのユーザに対する完全なネットワークアクセスプロファイルを含むが、ユーザのデスクトッププロファイルに特有の情報は含まないか、あるいはそれに関して、ユーザが属してもよいグループのためのすべてのデスクトッププロファイルも含まれない。また、それには、パスワード満了時間、パスワードの一意性制御情報、ネットワークアクセス時間制限情報、アカウント検証情報、ユーザがアクセスできるネットワークからのマシン名や空にその他の情報が含まれている。すべての情報はMicrosoft Windows NT(3.10, 3.50, 3.51, 4.0)バージョン中のSAM中に格納される。

ドメインコントローラ上のアカウント情報(ユーザとマシン)は2つのファイルに格納される。そのうちの1つにはセキュリティ情報を含み、もう1つはSAMである。それらは%SystemRoot%\System32\configディレクトリ中に同名のファイルに格納される。これは通常C:\WinNT\System32\configに変換される。ネットワーク上にBDCがあるとき、この2つのファイルがSAMデータベースの複製に関与するファイルである。

BDCをインストールすることが好ましい状況が2つある:

  • PDCがあるローカルネットワーク上で、たくさんのワークステーション がある場合、あるいはPDCが常時高負荷な場合。この場合、BDCはネットワーク上 のログオン要求を拾って、ネットワークサービスの堅牢性を向上する一助となる。

  • 各リモートサイトで、広域ネットワークの転送量を減らすためとリモート ネットワーク操作の安定性を向上したい場合。ネットワークのデザイン、戦略的な BDCの配置、及びネットワークのできるだけ多くの部分をクライアント側のやり取りに 使用するような実装を組み合わせることにより、WANのバンド幅のニーズを最小化する (従ってコストも最小化する)ことができる。

真のWindows NT4環境中でのPDCとBDCのやりとりについてここで触れておく。PDCはSAMのマスタコピーを持っている。管理者がPDCの持つローカルネットワーク上に物理的に存在するユーザアカウントデータベースに変更を加えると、この変更内容は、SAMのマスタコピーのPDC上の記録に直接行われる。このような情報更新が別のオフィスで行われると、この変更内容はローカルBDC上の差分ファイルに格納される。BDCはその後SAM同期を行うプロセスを開始するために、PDCに対してトリガを送る。PDCは当該ドメインの全BDCに接続し、全BDCが更新情報を入手し、それぞれのSAMのコピーに最新の情報を反映させるようにトリガを出す。

Samba-3は真のSAM複製に参加できないので、Microsoft Windows NT4で使われているのと同じプロトコルを使用することが出来ない。Samba-3 BDCはSAM更新差分ファイルを作成できない。BDCが持っている差分ファイルからSAMの同期をとるために、PDC(NT4またはSamba)間とやりとりもしない。

Samba-3 はMicrosoft Windows NT4 BDCとしては動作できず、Samba-3はMicrosoft Windows NT4 BDCに対するPDCとして正しく動作できない。Samba-3とMicrosoft Windows NT4はそれぞれのタイプのPDCへのBDCとして機能することは出来る。

BDCはネットワークログオン要求とユーザ認証が出来るので、読み出し専用のSAMを保持していると言える。BDCはこのサービスを提供し続けることができる。特に、PDCへのWANのリンクがダウンしている場合などに有効である。BDCは、ドメインのセキュリティとネットワークの整合性の維持に大変重要な役割を果たす。

NT4のPDCを稼働停止しなければならない場合や故障した場合、NT4 のBDCの一つをPDCに昇格することができる。このようなことを NT4 PDCがオンライン中に行うと、NT4 PDCは自動的に NT4 BDCに降格する。これはドメインコントローラの管理の中で特に重要な一面である。昇格および降格を実行するのに使用されるツールはドメインサーバーマネジャーである。ここで注意しなければならないことは、Samba-3 の BDCは同様の方法で格上げすることはできないということである。これは、そのような Samba の再設定を行うにはsmb.confファイルの変更が必要になるからである。作業は、smb.confファイルの手動での変更と、Sambaネットワークサービスに関連するものの再起動をおこなうだけでよい。

PDCの設定例

バージョン2.2の最初からSambaは公式に、Windows NT4、2003とXP Professionalを含む現行Windowsクライアントすべてでドメインログオン機能を公式にサポートしている。PDCを有効にしたSambaではsmb.conf中の[global]セクション内にいくつかのパラメータを設定しなければならない。最低限必要な設定の例はBDCと共に使う、PDC上にLDAPサーバがあるPDCのための最低限のsmb.conf の節を参照のこと。

Example 5.1. BDCと共に使う、PDC上にLDAPサーバがあるPDCのための最低限のsmb.conf

workgroup = MIDEARTH
passdb backend = ldapsam://localhost:389
domain master = yes
domain logons = yes
ldap suffix = dc=quenya,dc=org
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=sambadmin,dc=quenya,dc=org

[homes][netlogon]共有などの項目や、プロファイルパス、ユーザのホームドライブやその他を設定するための設定も一緒に行う必要がある。それらはこの章では触れない。詳細な情報については、ドメイン制御を参照のこと。PDC設定のための特定の推奨パターンはドメイン制御の章を参照のこと。また別に、地域の、あるいはオンライン書店から入手できるSamba-3 by Exampleという書籍(book)中にOpenLDAPとSambaのネットワーク動作設定例が完全に記述されている。

LDAP設定の注意

マスタとスレーブLDAPサーバを設定する時、マスタLDPサーバをPDCに、スレーブLDAPサーバをBDCで使うことが推奨される。スレーブLDAPサーバを使うことは不可欠ではないが、サービスの冗長性を提供するために多くの管理者はそのことを好んでいる。もちろん、1つ以上のBDCがどののスレーブLDAPサーバを使ってもかまわない。また、ネットワーク全体で1つのLDAPサーバを使うことも可能である。

スレーブLDAPサーバサーバを持つマスタLDAPサーバを設定する時、このことを/etc/openldap/slapd.confファイル中に設定することを忘れないように。サーバ証明書のDNは、サーバの名づけるためにCN属性を使わなければならず、CNはサーバの完全に的確性のあるドメイン名を含んでいなければならないことに注意。証明書の subjectAltNameエクステンション中に追加の別名やワイルドカードを持っていても構わない。サーバ証明書についてのより詳細な情報はRFC2830を参照のこと。

この文書の範囲内にはうまく一致しないが、LDAPをインストールすることは、LDAPを有効にしているSamba操作の基本である。トランスポートレイヤのセキュリティ(TLS)を有効にしてOpenLDAPを使う場合、/etc/ssl/certs/slapd.pem中のマシン名は/etc/openldap/sldap.confと同じものである必要がある。Red Hat Linuxスタートアップスクリプトはホスト名として、localhost.localdomainとしたslapd.pemファイルを生成する。これだと、正しいホスト名で証明書が再作成されない限り、スレーブLDAPサーバ(すなわちSamba BDC)からLDAPサーバにアクセスできない。

LDAPスレーブサーバを使うようにSamba PDCをインストールしてはいけない。ドメインへクライアントマシンを参加する時、LDAPデータベース中へのマシンアカウントの変更がマスタLDAPサーバ上で行わなければならないという理由で、この設定ではうまくいかない。PDCが出した問い合わせがスレーブサーバに複製されるまで時間がかかりすぎる。そのため、クライアントマシン上で、アカウントの証明書がセットアップできないというエラーメッセージが出る。LDAPサーバ上でマシンアカウントが作成されるが、パスワード欄は空となる。残念なことに、いくつかのサイトはこのような設定を防げず、そのため、それらのサイトでは、複製に追いつくために、Sambaの処理を十分に遅くするための、ldap replication sleepパラメータを検討すべきである。これは、その場しのぎの解決方法であり、管理者が何らかのスクリプト(たとえば、add machine scriptのようなもの)を使って手動で複製しなければならない。

PDC/BDCとLDAPを使う、設定可能なパターンは以下の通り:

  • PDC+BDC -> 1つの集中LDAPサーバ。

  • PDC -> LDAP マスタサーバ、 BDC -> LDAPスレーブサーバ。

  • PDC -> LDAPマスタ、第二のスレーブLDAPサーバあり。

    BDC -> LDAPマスタ、第二のスレーブLDAPサーバあり。

  • PDC -> マスタ、第二のスレーブLDAPサーバあり。

    BDC -> スレーブ、第二のスレーブサーバあり。

(セカンダリ)LDAPサーバサーバを持つためには、smb.confに記述する複数LDAPサーバの例のように指定する。

Example 5.2. smb.confに記述する複数LDAPサーバ

passdb backend = ldapsam:"ldap://master.quenya.org ldap://slave.quenya.org"

Active Directoryドメイン制御

Microsoft Windows 2000とActive Directoryのリリース以降、この情報は複製可能で、管理コントロールの部分的あるいは全体を複製できるディレクトリ中に格納される。Samba-3はActive Directory内でドメインコントローラにはなれず、また、Active Directoryサーバにもなれない。このことは、Samba-3はActive DirectoryドメインコントローラのBDCとなりえないことを意味する。

ネットワーク上のドメインコントローラになれる要件

ドメインMIDEARTH用のドメインコントローラであるすべてのマシンは、WINSサーバかローカルネットワークに対するブロードキャストを使ってNetBIOSグループ名MIDEARTH<1C>を登録しなければならない。またPDCはWINSサーバで一意のNetBIOS名MIDEARTH<1B>を登録する。名前タイプ<1B>はドメインマスタブラウザ(DMB)のために通常予約ていて、認証には通常何ら関係ないが、Microsoftドメインの導入時はDMBがPDCと同じマシンであることが用件となる。

WINSサーバを使っていないとき、名前登録はブロードキャストするだけで十分なはずである。ネットワークブラウジングDiscussionに、TCP/IPネットワークプロトコル関連と、どのようにSMB/CIFS名を取り扱うかについてのより詳細な情報があるので参照すること。

どのようにワークステーションがそのドメインコントローラを探すか?

ドメインコントローラを見つけるメカニズムは2つある:1つはNetBIOS over TCP/IPが有効なときに使われ、もう1つはTCP/IPネットワーク設定で無効になっているときに使われるものである。

NetBIOS over TCP/IPが無効になっているとき、すべての名前解決は、Active Directory通信技術のような、DNS、UDP上のブロードキャストを使う。このタイプの環境では、すべてのマシンが適切なDNSエントリを持つことが必要である。より詳細な情報はDNSとActive Directoryを参照のこと。

NetBIOS Over TCP/IPが有効

ドメインMIDEARTH内のMicrosoft Windows NT4/200x/XP Professionalワークステーションがローカルユーザを認証させたい場合、MIDEARTHのドメインコントローラを見つける必要がある。これは、グループ名MIDEARTH<1C>に対するNetBIOS名前解決を行うことによって行われる。ワークステーションは、問い合わせに返事を返すマシンの1つ1つがドメインコントローラであり、ログイン要求に答えることが出来ることを仮定している。セキュリティホールを造らないために、ワークステーションと選択されたドメインコントローラはおのおのを認証する。その後、ワークステーションはユーザの認証情報(ユーザ名/パスワードペア)を認証のためにローカルのドメインコントローラに送る。

NetBIOS Over TCP/IPが無効

realm quenya.org中のMicrosoft Windows NT4/200x/XP Professional workstationがユーザログオン認証をしたい場合、DNSサーバに対して_ldap._tcp.pdc._msdcs.quenya.orgレコードを再度問い合わせすることでドメインコントローラ見つける。この項目に対する関連したより詳細な情報は、DNSとActive Directoryを参照のこと。

バックアップドメインコントローラの設定

BDCの作成には最初にsmbdを動かす前にSamba サーバを準備するためのいくつかのステップが要求される。

  • ドメインSIDはPDCとBDCで同じにしなければならない。バージョン2.2.5 以前のSambaでは、ドメインSIDはprivate/MACHINE.SID ファイルに格納されていた。Sambaバージョン2.2.5以降すべてのバージョンでは、 ドメインSIDはprivate/secrets.tdbファイルに 格納されている。このファイルは各サーバで固有であり、PDCからBDCに コピーできない。BDCは新しいSIDを起動時に生成する。新しく生成したBDCのSID はPDCのドメインSIDを上書きする。これは、BDCにドメインSIDを入手することを 認める手続きである。これについては以下で説明する。

    PDCまたは既存のBDCからドメインSIDを検索するためと、検索した値を secrets.tdbに格納するためには、以下を実行する:

    root# net rpc getsid
  • ldap admin dnの指定は必須である。 また、smbpasswd -w mysecret を使って、secrets.tdb中にLDAP管理用パスワードを 設定しなければならない。

  • The ldap suffixパラメータとldap idmap suffix パラメータはsmb.confファイル中で指定しなければならない。

  • UNIXユーザデータベースはPDCからBDCへ同期しなければならない。 これは、/etc/passwd/etc/groupの両方がPDCからBDCに複製されなければ ならないことを意味している。これは変更が発生した時点で、手動で 行うことが出来る。別のやり方として、PDCをNISマスタサーバとして設定し、 BDCをNISスレーブサーバとして設定する。BDCをNISクライアントとして設定 するのでは、PDCが止まっているときにそのユーザデータベースにアクセス 出来ないので不十分である。NISはパスワード同期の唯一の手法というわけ ではない。LDAPを使う解も同様に動作する。

  • SambaパスワードデータベースはPDCからBDCに向けて複製されねばならない。 rsyncsshsmbpasswd ファイルの同期を取るのが可能であるが、この方法は破綻していて 欠陥があるので推奨できない。よりよい解決方法は、各BDCに対してスレーブ LDAPサーバを、PDCにマスタLDAPサーバを設定することである。 rsyncを使う方法は、一定間隔毎にデータが複製されるという理由で、本質的に 欠陥がある。すべての瞬間に、現在のマシンとユーザアカウントの正しい情報で BDCが操作できるという保証がない。このため、この方法では、首尾一貫しない セキュリティデータのために不連続なネットワークサービスへのアクセスによって ユーザに不都合が生じる危険性がある。Windows ワークステーションが通常の 間隔でマシン信頼アカウントパスワードを更新(変更)することを心にとめて おかねばならず、管理者は通常それが起きていることを知らない。

    POSIX(UNIXユーザとグループ)アカウントとSambaSAMAccountデータ両方のために LDAPを使うと、すべてのアカウント変更情報が共有ディレクトリに書かれること を自動的に保証する。これは、LDAPがその要求に適合するため、アカウント情報の 同期のための、何らかの特別な動作が必要ないことを意味する。

  • netlogon共有はPDCからBDCに向けて複製されねばならない。これは、ログインスクリプト が変更されるたびごとに手動で行うことができ、また、rsyncのような ツールを使うことで、この共有中のディレクトリ構造を複製する、cron ジョブを使うことで自動的に行える。netlogon共有内のファイルの複製に rsyncを使うことは、ネットワークセキュリティに対して特段 問題になることはない。管理者が netlogon 共有に対するすべての変更を明示的に 行ないたいと考えている場合は、手作業で管理するために用いることも可能である。

設定例

最後に、ワークステーションがBDCを見つけなければならない。これは、SambaをBDCになるための最低限の設定中にあるSamba smb.confファイルの[global]セクションのように設定することで行える。

Example 5.3. BDCになるための最低限の設定

workgroup = MIDEARTH
passdb backend = ldapsam:ldap://slave-ldap.quenya.org
domain master = no
domain logons = yes
ldap suffix = dc=abmas,dc=biz
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=sambadmin,dc=quenya,dc=org
idmap backend = ldap:ldap://master-ldap.quenya.org
idmap uid = 10000-20000
idmap gid = 10000-20000

完全な、OpenLDAPとSambaを使うネットワーク設定の例の説明は、近所又はオンライン書店で買える、Samba-3 by Exampleというを参照のこと。

この設定はWINSサーバに、MIDEARTH<1C>という名前のみをBDCによって登録させる。これは、MIDEARTH<1C>というNetBIOSグループ名が、複数のマシンが登録に使用することを意図した NetBIOS グループ名であることを考えれば問題ではない。パラメータdomain master = noは、PDCのために予約されている固有のNetBIOS名であるMIDEARTH<1B>をBDCが登録時に使用させないことを確保する。

idmap backendパラメータが、winbinddユーティリティをリダイレクトして、共有されるリポジトリ内にある、UNIXアカウントに関するすべての、Windows SIDからUIDとGIDへの解決のためにLDAPサーバデータベースを使用させる。BDCはnss_ldapユーティリティとNSS経由の、ローカルでのUIDとGIDの解決にも依存する。

Note

Samba-3は新しいIDマッピング機能を導入した。その機能の特徴の1つは、NTドメインのユーザとグループSIDに関してユーザとグループIDを取り扱うやり方に、より高い柔軟性を備えているということである。新しい機能の1つは、UNIX/LinuxのUIDとGIDの値が、PDC、すべてのBDCとすべてのドメインメンバサーバ上で一貫していることを明確に確保する。これを制御するパラメータは、idmap backendである。その動作に関連する詳細な情報は、smb.confマニュアルページを参照してほしい。

BDC上のみでidmap backend = ldap:ldap://master.quenya.orgオプションを使用することは、PDC上でldapsamが使われている時に意味をなす。LDAPベースのバックエンドのもう1つの目的は、(固有のpassdbバックエンドを持たない)ドメインメンバがWindowsネットワークユーザとグループを共通のUID/GIDに割り当てるためにwinbinddを使えるようにすることである。別の言い方をすると、一般的にこのオプションは、BDCとドメインメンバサーバ上で使うことを意図している。

よくあるエラー

ドメイン制御はSambaの新しい領域であるが、現在では参照可能なたくさんの事例がある。更新情報は、それが有効になった時点で、Sambaの新規リリース情報か、Samba Websiteで公開される。SambaリリースパッケージのWHATSNEW.txtを特に参照すること。Samba-3 by Exampleという本には、よくテストされ、検証された例が記述されている。これをSamba Webサイト上のからコピーを入手することもできる。

マシンアカウントが満了し続ける

この問題は、passdb(SAM)ファイルが中央のサーバからコピーしていて、しかもローカルのBDCがPDCとして動作する時に発生する。これはローカルマシン信頼アカウントのパスワードをローカルSAMへ更新を実行することで解決する。そのような更新は中央のサーバにコピーは戻されない。新しいマシンアカウントのパスワードは、PDCからのSAMが再度コピーされたときに上書きされてしまう。その結果、起動時のドメインメンバであるマシンの起動時に、そのパスワードがデータベース中と一致しないことになり、起動時のセキュリティチェックに失敗するため、このマシンはログオン要求が許可されず、アカウント満了エラーが出ることになる。

解決策は、ldapsamバックエンドのようなより堅牢なpassdbバックエンドを使うことである。すなわち、各BDCにスレーブLDAPサーバを立て、PDCにマスタLDAPサーバを立てることである。

SambaはNT4 PDCのバックアップドメインコントローラになれるか?

できない。オリジナルのNT4 SAM複製プロトコルはまだ完全に実装されていない。

SambaでBDCを使う利点はあるかと言われればもちろんある。しかし、それはSamba PDCに対してのみである。BDCを使う理由は可用性という点である。もしもPDCがSambaだった場合、2番目のSambaマシンは、PDCがダウンしている時にログオン要求をサービスするように設定できる。

smbpasswdファイルの複製はどうやるか?

smbpasswdファイルの複製は注意が必要である。SAMが変更されたときは必ず行わなければならない。各ユーザのパスワードの変更はsmbpasswdファイル中で行われるので、必ずBDCに複製されねばならない。そのため、smbpasswdファイルの複製は非常に頻繁に必要となる。

smbpasswdファイルには平文パスワードと同等のものが含まれているので、ネットワーク上で暗号化しないで送ってはならない。PDCからBDCへ、smbpasswdを複製する最もよい方法は、rsyncを使うことである。rsyncは伝送路としてsshを使える。sshは、ユーザがパスワードを入力しなくてもrsyncでの転送ができるように設定できる。

少し前に説明したが、この方法を使うことは欠陥があるため危険である。マシン信頼アカウントの同期が外れると、結果としてドメインが破壊される。この方法は推奨されない。その代わりにLDAPを使うこと。

これをすべてのLDAPに使えるか?

一言で言うと可能である。Sambaのpdb_ldapコードはレプリカLDAPサーバに対するバインドをサポートし、データベースに対する変更の必要時には、referralの追跡と再バインドを行う(通常BDCはリードオンリで、そのためこれは滅多に起こらない)。