Chapter 6. バックアップ・ドメイン・コントロール

John H. Terpstra

Samba Team

Volker Lendecke

Guenther Deschner

LDAP updates

Table of Contents

特長と便益
基本的な背景情報
MS Windows NT4 式ドメイン・コントロール
LDAP 設定の注意事項
Active Directory のドメイン・コントロール
ネットワーク上のドメイン・コントローラーになれる要件
ワークステーションはどうやってドメイン・コントローラーを見つけるか?
バックアップ・ドメイン・コントローラーの設定
設定例
よくあるエラー
マシン・アカウントが頻繁に期限切れになる
Samba はNT4 PDCのバックアップ・ドメイン・コントローラーになれるか?
smbpasswd ファイルの複製は、どうやるか?
これをすべて LDAP ででるか?

ドメイン・コントロールの章に記述された Samba ドメイン・コントローラーの設定をよく理解した上で、この章を読み進めてください。

特長と便益

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

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

Samba-3 BDC を LDAP でないバックエンドとともに運用することも可能ですが、バックエンドが 何らかの形で「双方向の」伝達を許容し、BDC側からマスターへの変更が可能であるように しなければなりません。現段階でこれをできるのは LDAP のみです。

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

BDC の設定方法に関して挙げられたコメントや質問の数が多いので、可能な選択肢の一つ一つについて、 それぞれのソリューションのメリットとデメリットを考慮してみましょう。 下表 は、PDC/BDC インフラのための設定で考えられる デザインの一覧です。

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

PDC バックエンドBDC バックエンド備考・検討内容

マスター LDAP サーバ

スレーブ LDAP サーバ

高い整合性を提供する最適ソリューション。SAM は、共用マスター LDAP サーバーに複製される。

シングルの集中 LDAP サーバ

シングルの集中 LDAP サーバ

フェイルオーバー機能はないが稼動できるソリューション。使用はできるが最適とはいえない。

tdbsam

tdbsam + net rpc vampire

Samba-3.0.0 では動かない。より後のリリースでは実現可能になるかもしれない。このソリューションの短所は、 アカウント・データベースの整合性をコントロールするのが外部プロセスであること。このソリューションは、 LDAP の複雑性を回避したいサイトには魅力的かもしれない。net rpc vampire は PDC から BDC へドメイン・アカウントの同期を取るために使用する。

tdbsam

tdbsam + rsync

この設定は使用してはいけない。TDB ファイルがライブで、データがディスクにフラッシュされていないかも しれないのでうまくいかない。TDB データベース・ファイルの同期を取るには、PDC から BDC へ rsync を使用すること。

smbpasswd ファイル

smbpasswd ファイル

この設定は使用してはいけない。同期の遅れのため、適当なソリューションとは言えない。 TDB データベース・ファイルの同期を取るには、PDC から BDC へ rsync を使用すること。PDC から BDC へデータの同期を取るために cron を使用すれば 使うことはできる。

基本的な背景情報

ドメイン・コントローラーは、ネットワーク上のワークステーションからのログオン・リクエストに 答えることができるマシンのことです。Microsoft LanManager とIBM LanServer が、 この機能を提供した初期の二つの製品でした。この技術は、LanMan Netlogon サービスとして 知られるところとなりました。

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

MS Windows NT4 式ドメイン・コントロール

ユーザーが Windows NT4/200x/XP Professional ワークステーションにログインするとき、 ワークステーションはドメイン・コントローラー (認証サーバー) に接続して、ユーザーが入力した ユーザー名とパスワードが有効であることを確認します。入力された情報が ドメイン・コントロール・データベース (SAM またはセキュリティ・アカウント・マネジャーの データベース) に格納されているアカウント情報と一致しない場合、認証リクエストを出した ワークステーションに、一連のエラーコードを返します。

ユーザー名とパスワードの組み合わせが有効であった場合は、ドメイン・コントローラー (認証サーバー) は、当該ドメイン用のユーザー及びマシン・アカウントのデータベース内に 格納されたユーザーに関するアカウント情報を回答として返します。この中には、当該ユーザーの 全ネットワーク・アクセス・プロファイルが含まれますが、ユーザーのデスクトップ・プロファイルに 関する情報は含まれません。これについては、当該ユーザーが帰属している可能性のある グループのすべてのデスクトップ・プロファイル情報が含まれません。しかし、 パスワードのタイムリミット、パスワードの固有性コントロール、ネットワークアクセスの タイムリミット、アカウント有効性情報、ユーザーがネットワークにアクセスするのに 使用できるマシンネーム、その他多くの情報が含まれます。この全ての情報が、MS Windows NT の全バージョン (3.10、3.50、3.51、4.0) で、SAM に格納されます。

ドメイン・コントローラー上の (ユーザー及びマシンの) アカウント情報は、二つのファイルに 格納されます。一つは、セキュリティ情報のファイル、もう一つは SAM の情報のファイルです。 これらは、C:\Windows NT\System32\config のディレクトリ内の同名の ファイルに格納されます。ネットワーク上にバックアップ・ドメイン・コントローラーがあるとき、 この二つのファイルが、SAM データベースの複製に関与します。

バックアップ・ドメイン・コントローラーをインストールするのが望ましい状況が二つ考えられます:

  • プライマリ・ドメイン・コントローラが存在するローカル・ネットワーク上に多数の ワークステーションがある場合、または PDC が常にビジーの場合。この場合、BDC がネットワーク・ログオン・リクエストを拾って、ネットワークの堅牢性を向上する 一助となります。

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

真の Windows NT4 環境における PDC と BDC 間のやりとりについて、ここで述べておきましょう。 PDC は、SAM のマスターコピーを持っています。管理者が、PDC の持つローカル・ネットワーク上に 存在するユーザー・アカウント・データベースに変更を加えると、この変更は SAM の マスターコピーの PDC 上の記録に直接実行されることになります。このような情報更新が 支店で行われた場合、この変更内容はローカル BDC の Delta ファイルに格納されることに なります。BDC はその後、SAM の同期を取るプロセスを開始するため、PDC にトリガーを送ります。 PDC は、BDC からの Delta をリクエストし、それをマスター SAM に反映させます。 PDC は当該ドメインの全 BDC に連絡をとり、全 BDC が更新情報を入手し、それぞれの SAM のコピーに最新の情報を反映させるようにトリガーを出します。

Samba-3 は真の SAM 複製プロセスには参加できませんので、MS Windows NT4 が用いているものと 全く同じプロトコルを使用することはできません。Samba-3 の BDC は SAM 更新の Delta ファイルは作成しません。また、BDC に保有されている Delta ファイルから SAM の同期を取るために、 (NT4 または Samba の) PDC とやりとりもしません。

Samba-3 は、MS Windows NT4 PDC に対する BDC として機能することはできず、また Samba-3 は MS Windows NT4 BDC に対する PDC としても正しく機能することができません。Samba-3 と MS 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 ファイルの変更が必要になるからです。

PDC の設定例

Samba は現在出ているすべての Windows クライアントのためのドメイン・ログインを 公式にサポートしています。Samba が PDC となるためには、smb.conf 内の [global] のセクションのパラメーターの一部を 設定しなければなりません。下記の設定例 を 必要最低限の設定として参考にしてください。

Example 6.1. PDC 上の BDC LDAP サーバーとともに使用する PDC のための smb.conf の最低設定

workgroup = MIDEARTH
passdb backend = ldapsam://localhost:389
domain master = yes
domain logons = yes

上記以外にも、[homes][netlogon] 共有などの項目も、プロファイル・パスの設定、ユーザーのホーム・ドライブなどと共に 設定する必要があります。これは本章では詳述しませんので、詳細は ドメイン・コントロール の章を参照ください。

LDAP 設定の注意事項

マスター及びスレーブの LDAP サーバーの設定を行うときは、マスター LDAP サーバーを PDC に、 スレーブ LDAP サーバーを BDC に使用するのが望ましいです。スレーブの LDAP サーバーを 使用するのは必要不可欠なことではないのですが、多くの管理者がサービスの冗長性を確保するために この方法を好みます。もちろん、一つ以上の BDC がスレーブ LDAP サーバーのどれを使用しても 構いません。また、全ネットワークが単一の 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 サーバーへアクセスすることはできません。

OpenLDAP スレーブ・サーバー上に Samba PDC をインストールしないでください。 この設定では、クライアント側のマシンをドメインに繋ぐことができません。なぜなら、 LDAP ツリーのマシン・アカウントの変更は、マスター LDAP サーバー上で行わなければ ならないからです。PDC の出したクエリーがスレーブ・サーバーへ複製されるまでに 時間がかかりすぎます。従って、アカウントの信憑性を確認できないというエラーメッセージが クライアントのマシンで出ることになります。マシン・アカウントは、LDAP サーバー上に 作成されますが、パスワード欄は空欄になります。

PDC/BDC と LDAP の設定には、以下のものがあります。

  • PDC+BDC -> 一つの集中的 LDAP サーバー

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

  • PDC -> LDAP マスター、セカンダリ・スレーブLDAP サーバーあり

    BDC -> LDAP マスター、セカンダリ・スレーブLDAP サーバーあり

  • PDC -> LDAP マスター、セカンダリ・スレーブ LDAP サーバーあり

    BDC -> LDAP スレーブ・サーバー、セカンダリ・マスター LDAP サーバーあり

予備 (セカンダリ) の LDAP サーバーを持つためには、以下の例 に示すとおり smb.conf ファイルの中でセカンダリ LDAP サーバーを規定します。

Example 6.2. smb.conf 内の複数の LDAP サーバー

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

Active Directory のドメイン・コントロール

MS Windows 2000 と Active Directory のリリース以降、複製可能で管理コントロールの 全部または一部を代理できるディレクトリに、この情報を格納するようになりました。 Samba-3 は、Active Directory ツリーの中でドメイン・コントローラーになることができず、 Active Directory サーバーにもなり得ません。このことは、Samba-3 は、Active Directory ドメイン・コントローラーに対するバックアップ・ドメイン・コントローラーにも なり得ないことを意味します。

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

MIDEARTH ドメインのドメイン・コントローラーであるすべてのマシンは、WINS サーバーで、 かつ・または、ローカル・ネットワーク上のブロードキャストで、MIDEARTH<#1c> という NetBIOS グループネームを登録しなければなりません。また PDC は、WINS サーバーで固有の NetBIOS ネームである MIDEARTH<#1b> を登録します。<#1b> のネームタイプは、 通常ドメイン・マスター・ブラウザー用でありその機能は認証とは全く関係がありませんが、 Microsoft Domain の導入時には、PDC と同じマシン上にドメイン・マスター・ブラウザーが あることが要件となります。

WINS サーバーを使用しない場合、ネーム登録をブロードキャストするだけで事足りるはずです。 TCP/IP ネットワーク・プロトコルと SMB/CIFS ネームの扱い方についての詳細情報は、 ネットワーク・ブラウジング: 検討 の項を参照ください。

ワークステーションはどうやってドメイン・コントローラーを見つけるか?

ドメイン・コントローラーを見つけるメカニズムは二つあります。一つは、NetBIOS over TCP/IP が実現されている時に使用される方法で、もう一つは、TCP/IP のネットワーク設定で NetBIOS over TCP/IPが無効化されている場合に使用される方法です。

NetBIOS over TCP/IP が無効化されている場合、名前に関する問題解決は DNS、UDP 上の ブロードキャスト・メッセージング及び Active Directory の通信技術を使用することになります。 このタイプの環境では、全マシンが適切な DNS エントリーを持つことが要求されます。 詳細情報は DNS 及び Active Directory の章を参照ください。

NetBIOS over TCP/IP が有効の場合

MIDEARTH ドメイン内の MS Windows NT4/200x/XP Professional ワークステーションが ローカル・ユーザーの認証をしてもらいたい場合は、MIDEARTH 用のドメイン・コントローラーを 見つけなければなりません。そのやり方としては、MIDEARTH<#1c> のグループネームで NetBIOS ネーム・クエリーを行います。ワークステーションは、クエリーの返事を出してくる マシンの一つ一つがドメイン・コントローラーであり、ログイン・リクエストに答えられるものだと 推定します。セキュリティのぬけ穴を開けないように、ワークステーションと選択された ドメイン・コントローラーは、双方が相手を認証します。その後ワークステーションは、 ユーザーの認証情報 (ネームとパスワード) を有効性確認のためローカルの ドメイン・コントローラーに送ります。

NetBIOS Over TCP/IP が無効化されている場合

quenya.org の中の MS Windows NT4/200x/XP Professional ワークステーションが、 ユーザー・ログインの認証をしたい場合、DNS サーバーに対して _ldap._tcp.pdc._msdcs.quenya.org のレコードの再クエリーを行って、 ドメイン・コントローラーを見つけます。この項目に関する詳細情報は DNS 及び Active Directory の章を参照ください。

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

BDC を作成するためには、最初に smbd を実行する前に、Samba サーバーの準備の手順を 必要とします。この手順を以下に説明します:

  • ドメイン SID は PDC 上と BDC 上で同一でなければなりません。Samba の 2.2.5 より前のバージョンでは、 ドメイン SID は private/MACHINE.SID のファイルに格納されました。 現在のバージョンでは、ドメイン SID は private/secrets.tdb のファイルに 格納されるようになりました。このファイルは各サーバーに固有で、PDC から BDC へのコピーはできません。 BDC は起動時に新しい SID を作成します。その際、PDC 上のドメイン SID は新しく作成された BDC SID により上書きされます。BDC がドメイン SID を入手する手順を以下に説明します。

    PDC あるいは既存の BDC からドメイン SID を取り出し secrets.tdb に格納するには、 以下を実行します:

    root# net rpc getsid
    
  • ldap admin dn の設定は必須です。また、LDAP 管理パスワードを smbpasswd -w mysecret を使って secrets.tdb 内で設定しなければなりません。

  • ldap suffix または ldap idmap suffix を smb.conf ファイル内で設定しなければなりません。

  • UNIX のユーザー・データベースは、PDC から BDC へ同期を取らなければなりません。 これは、/etc/passwd 及び /etc/group の両方を PDC から BDC へ複製しなければいけないということです。これは、 変更が発生した時にマニュアルで実行できます。あるいは、PDC を NIS マスター・サーバーとして設定し、BDC を NIS スレーブ・サーバーとして設定します。 BDC を単なる NISクライアントとして設定するだけでは不十分です。なぜなら、BDC は PDC 故障時にユーザー・データベースにアクセスできないからです。もちろん NIS はパスワードの同期を取る唯一の方法というわけではありません。 LDAP ソリューションでもできます。

  • Samba のパスワード・データベースは PDC から BDC に複製しなければなりません。 rsyncsshsmbpasswd ファイルの同期を取ることもできますが、この方法には欠陥がありお勧めできません。 より良いソリューションは、BDC 一つ一つに対してスレーブ LDAP サーバーを設定し、 PDC にマスター LDAP サーバーを設定することです。

  • netlogon 共有は PDC から BDC に複製しなければなりません。これは、 ログイン・スクリプトが変更されたときにマニュアルで行うこともできますし、 あるいは、rsync のようなツールを用いて、この共有の中の ディレクトリ構造を複製する cron ジョブを用いて自動的に 行うこともできます。

設定例

最後に、ワークステーションが BDC を見つけなければなりません。これは、Samba を 以下の例 のように設定することでできます。

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

workgroup = MIDEARTH
passdb backend = ldapsam:ldap://slave-ldap.quenya.org
domain master = no
domain logons = yes
idmap backend = ldap:ldap://slave-ldap.quenya.org

上記は、BDC の smb.conf[global] セクションの中です。 これは、BDC をして WINSサーバーで MIDEARTH<#1c> のネームのみを登録させるということです。 これは、MIDEARTH<#1c> のネームは複数のマシンが登録に使用することを意図した NetBIOS グループ・ネームであることを考えれば、問題ありません。 domain master = no のパラメーターが、 プライマリ・ドメイン・コントローラー用に取っておかなければならない固有の NetBIOS ネームである MIDEARTH<#1b> を、BDC が登録時に使用しないことを確保します。

idmap backend が、winbindd ユーティリティをリダイレクトして、 UNIX アカウントに関するすべての UID と GID の解決に LDAP データベースを使用させます。

Note

Samba-3 は、新しい ID マッピング機能を導入しました。その特長の一つは、NT ドメイン・ユーザーと グループ SID に関連してユーザー ID とグループ ID を取り扱うやり方に、より高い柔軟性を備えていると いうことです。特に新しい機能の一つは、PDC、すべての BDC 及びすべてのドメイン・メンバー・サーバー上で、 UNIX/Linux の UID 及び GID 値が一定であることを確保します。これをコントロールするパラメーターを idmap backend と呼びます。このパラメーターの詳細については、smb.conf に関するページを参照ください。

idmap backend = ldap:ldap://master.quenya/org のオプションを、一つの BDC でのみ使用するというやりかたは、ldapsam を PDC 上で使用するときのみ意味を成します。 LDAP ベースの idmap backend のもう一つの目的は、(固有の passdb backendを持たない) ドメイン・メンバーが、 Windows のネットワーク・ユーザー及びグループを共有の UID/GID に帰属させるために、winbindd を使用できるように することです。別の言い方をすると、このオプションは BDC とドメイン・メンバー・サーバーでの使用を意図しています。

よくあるエラー

これは Samba でも新しい分野なので、参考にできる例があまりありません。更新情報が入手でき次第、公開します。 また、今後の Samba のリリースや、Samba の ウェブサイト 上で公開します。

マシン・アカウントが頻繁に期限切れになる

この問題は、passdb (SAM) ファイルを中央のサーバーからコピーしていて、しかもローカルの バックアップ・ドメイン・コントローラーが PDC として動いている時に発生します。 これは、ローカル SAM へローカル・マシン・トラスト・アカウントのパスワード更新を実行すると いうことになります。このような更新は中央のサーバーにはコピーされません。 新しいマシン・アカウントのパスワードが、PDC からの SAM が再コピーされる際に 上書きされてしまいます。その結果、ドメイン・メンバーであるマシンの起動時にそのパスワードが データベースに格納されているものと一致しないことになり、起動時のセキュリティ・チェックを クリアできないためこのマシンはログインを許可されず、アカウント期限切れというエラーが 戻ってくるのです。

解決法は、より堅牢な passdb backend を使用することです。例えば、ldapsam backend を使用し、 一つ一つの BDC にスレーブ LDAP サーバーを設定し、PDC にマスター LDAP サーバーを設定することです。

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

なれません。ネイティブの NT4 SAM の複製プロトコルはまだ完全に導入されていないからです。

Samba は BDC になれるかと言えばなれますが、Samba PDCに対応する BDC のみです。 BDC を導入する主たる理由は可用性です。PDC が Samba マシンであるなら、二台目の Samba マシンを PDC がダウンしたときにログオン・リクエストに対応するためのマシンとして 設定することができます。

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

smbpasswd ファイルの複製には、注意が必要です。SAM への何らかの変更があった場合は 必ず行わなければなりません。ユーザーのパスワード変更はすべて smbpasswd ファイル内で 行われますので、必ず BDC に複製されなければなりません。smbpasswd ファイルの複製は、 非常に頻繁に必要になります。

smbpasswd ファイルは、プレーン・テキストのパスワードと同じですので、暗号化しないで 送信してはいけません。PDC から BDC へ smbpasswd を複製する一番良い方法は、 rsync のユーティリティを使うことです。rsync は送信方法として ssh を使用できます。 ssh 自体を、ユーザーがパスワードを入力しなくても rsync 送信 のみ を許可するように設定することが できます。

前にも何度か述べましたように、この方法は欠陥があります。マシンの信頼アカウントの同期が 崩れるとドメインに欠陥が生じます。この方法はお勧めできません。LDAP を使用するように してください。

これをすべて LDAP ででるか?

一言で言うと可能です。Samba の pdb_ldap コードは、レプリカ LDAP サーバーへのバインドを サポートし、データベースを改変する必要が出た場合はリファーラルに従ってマスターへ リバインドします (通常は BDC は読み込み専用なので、これは頻繁には起こらないでしょう。)