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

John H. Terpstra

Samba Team

Volker Lendecke

Guenther Deschner

LDAP updates 

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はリードオンリで、そのためこれは滅多に 起こらない)。