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つある:

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

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

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

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

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

マスターとスレーブ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を使う、設定可能なパターンは以下の通り:

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

Microsoft Windows 2000とActive Directoryのリリース以降、この情報は 複製可能で、管理コントロールの部分的あるいは全体を複製できるディレクトリ 中に格納される。Samba-4.0 はActive Directory内でドメインコントローラー になれ、また、Active Directoryサーバーにもなれる。これをどのようにやるかの 詳細については、 Samba 4.0 as an AD DC HOWTO を参照のこと。

ドメイン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 を参照のこと。

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

完全な、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の 解決にも依存する。

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

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

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

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

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