Chapter 4. ドメイン制御

John H. Terpstra

Samba Team

Gerald (Jerry) Carter

Samba Team

David Bannon

Samba Team

Guenther Deschner

LDAP updates 
Samba Team

Table of Contents

機能と利便性
シングルサインオンとドメインセキュリティ
ドメイン制御の基礎
ドメインコントローラの種類
ドメイン制御の準備
ドメイン制御: 設定例
SambaによるADSドメイン制御
ドメインとネットワークログインの設定
ドメインネットワークログオンサービス
セキュリティモードとマスタブラウザ
よくあるエラー
$マシン名中に$を含められない
存在するマシンアカウントがあるためにドメイン参加に失敗する
システムにログオンできない(C000019B)
マシン信頼アカウントがアクセスできない
アカウントが無効
ドメインコントローラが無効
ドメイン参加後ドメインメンバワークステーションにログオンできない

Microsoft Windows のネットワークの世界に考えられないような誤解をしている人がたくさんいる。それは私たちが支援を提供できる機会が増えるということですからそれはそれでいいのだが、この分野で本当にヘルプを必要とする人は、まず、既に一般向けに出されている情報に親しむことを推奨する。

ある程度の基本を理解・修得されてからこの章を読み進めることを推奨する。Microsoft Windowsネットワークでは、誤った設定の影響がはっきりと現れる。Microsoft Windows ネットワークのユーザーから、ネットワーク設定の誤りに起因すると思われる細かなトラブルにしつこく悩まされるという苦情が出ることがよくある。ところが、多くの人々にとって Microsoft Windowsネットワークの世界というのはドメインコントローラーを知るところから始まり、それはネットワーク操作の障害を魔法のように、すべて解決してくれそうに思えるてくるものである。

ドメインの例の図解は典型的な、Microsoft Windows ネットワーク ドメインセキュリティネットワーク環境を図示している。ワークステーションA、BとCは多くの物理的なMicrosoft Windowsネットワーククライアントを代表していると考えられたい。

Figure 4.1. ドメインの例

ドメインの例

Sambaメーリングリストから、よくあるネットワークに関する問題の多くを容易に特定できる。もしも以下の話題についてよく分からないのであれば、それについて取り扱っている、このHOWTO文書の節を読むことを強く勧める。以下は、最も一般的なMicrosoft Windowsネットワークの問題である:

がっくりする必要はない。Microsoft Windowsのネットワーク機能は、一見、大変シンプルで誰でもできそうに見える。実際には、適切な研修と準備をしないで Microsoft Windows ネットワークを設定するのは、あまりよい考えとは言えない。とはいえ、なかなか払拭できない思い込みをちょっと脇にどけることにしよう。ミスを犯すのもいいことです!時と場合によっては失敗も教訓となる。しかし、生産性のロスを招き、組織に不可避の財政負担を強いるようなミスを犯してもよいわけではない。

それでは、ミスを犯してもよい場所とはどこであろうか? それは実害のない場所である。ミスを犯すなら、テストネットワーク上で、ユーザーから遠く離れた場所で、他の人に苦痛を与えない状況でやってほしい。

機能と利便性

Microsoftドメインセキュリティの最も重要な利便性は何か?

要するに、シングルサインオン、あるいは短く言えばSSOである。これは多くの人にとって、Microsoft Windows NT 以後のネットワーキングにおける聖杯である。SSOは、ユーザーのユーザーアカウントが存在するドメインのメンバであるワークステーション(あるいは、アクセスするドメインとの間に適切な信頼関係があるドメインに属するワークステーション)のいずれからも、ネットワークにログオンできるという優れた設計を可能にする。ユーザは、自分のホームの(個人の)ワークステーションの前に座っているかのように、ネットワークにログオンでき、リソース(共有、ファイル、プリンタ)にアクセスできる。これはドメインセキュリティプロトコルの一つの特長である。

Samba PDCを実装するサイトは、ドメインセキュリティの利便性を享受できる。ドメインは、固有のネットワーク・セキュリティ識別子(SID)を提供する。ドメインユーザとグループセキュリティの識別子は、ネットワーク SID に、アカウント毎に一意の相対識別子(RID)を付け足したものである。ユーザとグループのSID(ネットワークSID+RID)は、ネットワークリソースに付けられるアクセス制御リスト(ACL)を作成するのに使用され、組織内のアクセス制御を可能にする。UNIXシステムは、ローカルセキュリティ識別子のみ認識する。

SIDはセキュリティコンテキストを表す。例をあげると、おのおののWindowsマシンは固有のSIDを持つローカルマシンのセキュリティコンテキストでのローカルアカウントを持つ。すべてのドメイン(NT4、ADS、Samba)はドメインSIDによって定義されるセキュリティドメインセキュリティコンテキストで存在するアカウントを含む。

ドメインメンバサーバはドメインSIDとは異なるSIDを持つ。ドメインメンバサーバはすべてのドメインユーザをローカルユーザとして見なすように設定できる。SIDは持続的である。標準的なドメインのユーザSIDは以下のようなものである:

S-1-5-21-726309263-4128913605-1168186429

すべてのアカウント(ユーザ、グループ、マシン、信頼関係など)はRIDが割り当てられる。これは、アカウントが作成された時に自動的に行われる。UNIX OSはユーザとグループ識別子に別々の名前空間を使う(UIDとGID)が、Windowsは同じ名前空間からRIDを割り当てる。WindowsユーザとWindowsグループは同じRIDを持てない。ちょうどUNIXユーザrootがUID=0であるように、Windows Administratorは、よく知られたRID=500を持つ。RIDはWindowsドメインRIDに連結され、そのため、上記のSIDを持つドメインのAdministratorアカウントは下記のユーザSIDを持つ。

S-1-5-21-726309263-4128913605-1168186429-500

Windowsネットワーク領域中での残りのすべてのアカウントは全体で一意なセキュリティ識別子を持つ。

Note

Microsoft Windows ドメインセキュリティ環境でのネットワーククライアントは提供される高度な機能にアクセス出来るためには、ドメインメンバでなければならない。ドメインメンバシップはワークグループ名をドメイン名に設定するだけではない。ワークステーションに対する(マシンアカウントと呼ばれる)ドメイン信頼アカウントの作成が必要である。より詳細についてはドメインメンバシップを参照のこと。

以下の機能はSamba-3リリースで新規に追加された:

  • Samba-3はユーザ、グループとマシンアカウントが格納される時に使われる バックエンドの選択を行う事をサポートしている。複数のパスワードバックエンド を、付加的なデータセット、あるいはフェールオーバデータセットのどちらでも、 組み合わせて使うことが出来る(訳注:今は使えない)。

    LDAP passdbバックエンドは、拡張性と高いレベルでの信頼性を 提供するという理由で、とても価値のある、アカウントバックエンドが 分散かつ複製が出来るメリットを享受できる。

  • Windows NT4のドメイン信頼関係である。Samba-3はワークステーションと サーバ(マシン)信頼アカウントをサポートする。これは、ネットワークの スケーラビリティと相互運用性をさらに支援する、NT4スタイルのドメイン 間信頼アカウントをサポートする。

  • NetBIOS over TCP/IPなしの操作は、むしろraw SMB over TCP/IPを使うことである。注意: これはMicrosoft active directoryドメインメンバサーバとして操作する時にのみ 実行可能である。Sambaドメインコントローラとして動作する時、NetBIOSの使用は、 ネットワークブラウジングのサポートを提供するために必要である。

  • Samba-3はNetBIOSネームサービス(WINS)、NetBIOS ever TCP/IP(TCPポート139)、 SMB over TCP(TCP port 445)セッションサービスとMicrosoft互換のONC DCE RPCサービス(TCPポート135)を提供する。

  • ドメインにユーザーマネージャ経由でユーザとグループを管理する機能。 これは、Windows 9x/MeではNexus.exeを使い、 Windows NT4/200x/XPプラットフォームではSRVTOOLS.EXEを使って任意の Microsoft Windows クライアントで行える(訳注:Windows Vista/7では 使えない)。

  • Unicodeの完全な実装。これは、ロケール間での国際化サポートを容易にする。 また、Unicode を完全にサポートしなければならないという理由でSamba-2.2.x がサポートできなかったプロトコルの活用の道を開く。

以下の機能はSamba-3では提供されていない:

  • NT4ドメインコントローラ間でのSAMの複製(すなわちSamba PDCとWindows NT BDCまたはその逆)。 これは、Sambaが、PDCがMicrosoftベースのWindows NT PDCである時にBDCと して動作出来ないことを意味する。Samba-3はWindows PDCとBDCでのアカウント データの複製に参加できない。

  • Windows 2000 Active Directoryドメインコントローラとして動作する (すなわち、KerberosとActive Directory)。実際の所、Samba-3は 現時点では若干の、実験的なActive Directory ドメイン制御の機能を 有している。Active Directoryドメイン制御は次世代のSambaリリース である、Samba-4で現在開発中の機能である。現時点ではSamba-3ライフ サイクル中でActive Directoryドメイン制御を有効にする計画はない。

  • Windows 200x/XPのMicrosoft管理コンソール(MMC)はSamba-3サーバの管理に は使えない。この目的にはMicrosoft Windows NT4ドメインサーバマネージャと Microsoft Windows NT4ドメインユーザマネージャのみが使える。両者は この後説明するSVRTOOLS.EXEパッケージ中の一部である。

この章の中で説明されている理由により、Windows 9x/Me/XP Homeクライアントはドメインの真のメンバになれない。Windows9x/Meスタイルのネットワーク(ドメイン)ログオンプロトコルはNT4/Windows 200xスタイルのドメインログオンとは完全に異なり、しばらくの間公式にサポートされてきた。これらのクライアントはおおよそSamba-1.9.15シリーズからサポートされた旧LanManネットワークログイン機能を使う。

Samba-3ではWindows NT グループとUNIXグループ間でのグループマッピングを実装している(これは、限られたスペースでは説明できないくらい非常に複雑である)。これについての詳細についてはグループマッピング:Microsoft WindowsとUNIXを参照のこと。

Samba-3はMicrosoft Windows NT4 PDCまたはWindows200x Active Directoryと同様に、適切なバックエンドデータベースにユーザとマシン信頼アカウント情報を格納することを必要とする。これについては、Microsoft Windows ワークステーション/サーバ マシン信頼アカウントを参照のこと。Samba-3では複数のバックエンドが用意されている。完全なアカウントデータベースバックエンドについての解説はアカウント情報データベースを参照のこと。

シングルサインオンとドメインセキュリティ

ネットワーク管理者が、Windows NT4とactive directoryネットワークの利点について説明を求められるとき、しばしば言及するのが、シングルサインオン(SSO)を実装しているということである。多くの会社がSSOを実装している。シングルサインオンソリューション実装のモードは、一般的に、ネットワーク業務における重要な要因であり、Windowsネットワークに関してとても重要である。会社には多くの種類の情報システムがあり、それぞれはユーザ認証と認可(訳注:authentication and validation)を要求し、そのため、一般的ではないが、ユーザは10以上のログインIDとパスワードを記憶する必要があるかもしれない。この問題は、おのおののシステムのパスワードが一定期間で更新が必定で、パスワードの複雑さとパスワード履歴が適用されるときには特に顕著となる。

非常に数多くの情報システムに対するアクセス権限(ユーザ名/パスワードペア)を扱うユーザの問題に対する回答がSSOであるという認識を包括的に持っている。多くの巧妙な案が、ユーザフレンドリーなSSOのソリューションを提供可能にするために考案された。問題は、この導入がうまく終わっていない場合、サイトは複雑さによるたくさんの費用と管理上のオーバヘッドが起きるかもしれないということである。簡単に言って、多くのSSOソリューションは管理上の悪夢である。

SSOを使うことですべてのユーザアカウント情報を集中管理できる。環境の複雑さと、SSOを導入したシステムの稼働期間に依存して、新しいアイデンティティ管理とユーザ認証システムを受け入れることは可能ではないかもしれない。多くのSSOソリューションは、ユーザのための認証を処理する新しい上位の構造から成り立つレガシーシステムを改良する。これは、SSOの追加は全体的な情報システムの複雑さを増大することを意味する。理想的には、SSOの導入は複雑さの低減と管理オーバヘッドの削減をすべきである。

たくさんのネットワーク管理の最初のゴールは、しばしば集中管理したアイデンティティ管理システムを作り、使うことである。これは、そのような集中化したシステムは、すべての情報システムによって使うことが出来る単一の認証基盤を使うことをしばしば仮定している。Microsoft Windows NT4セキュリティドメインアーキテクチャとMicrosoftActive Directoryサービスは、そのようなシステムに対しての理想的な基盤としてしばしば提供される。ユーザの認証とアクセス制御のためにMicrosoft(NT4ドメインかadsサービス)を使うことが出来る単一の認証基盤を使う、そのような集中化したシステムがしばしば仮定される。単一の集中化した認証サービスのすばらしい幻想は一般的に、現実を理解するときに一般的に壊れている。レガシーシステムを使うときの問題は、その導入がリエンジニアリングの観点から、過度に侵略的になるか、アプリケーションソフトが、設計されて実装されたユーザ認証の特定の要素に依存して組み込まれているという理由により、認証とアクセス制御を具体化する能力がしばしばないということである。

これまでの10年間、産業が、レガシー名情報テクノロジーシステムの制限の鍵となる点を回避するために作られた、いろいろな方法が開発されてきた。しばしば使われるその1つの方法はメタディレクトリを使うことである。メタディレクトリには、それぞれのシステムに固有な形式で、すべての異なる情報システムのためにユーザ認証情報を保存する。単一のユーザ認証情報を使うすべてのシステムのために、新しい基盤がユーザアクセスを可能にさせることが提供されるシステムの迷宮の中で、ユーザ権限と権利(rights and privileges)を管理するための厳格に実施されるワークフロープロトコルに、管理手続きの巧妙なセットが結合される。

Organization for the Advancement of Structured Information Standards (OASIS)は、認証情報の通信のための構造化情報であるSecurity Assertion Markup Language (SAML)を開発している。SAMLを配置するための全体的な技術と手法の包括的名称(訳注:umbrella name)はFederated Identity Management (FIM)と呼ばれる。FIMはそれぞれのユーザを認証するための異なった情報システムの複雑な迷宮中で、かつおのおのが提供するサービスの安全なアクセスを請け負うために、おのおののシステムに依存する。

SAML文書はWebサービスのために必要なコンピュータ間通信のためのSimple Object Access Protocol (SOAP)メッセージ中に包むことが出来る。あるいは、ライブサービスを共有する集合化したWebサービス間で渡されるかもしれない。リバティ・アライアンスは、SAML1.1をアプリケーションフレームワークとして適用した、連携型アイデンティティ標準(訳注:federated-identity standards)を普及させるために作られたコンソーシアム(訳注:industry group)である。MicrosoftとIBMはWS-Securityと呼ばれる別の方式を提案していた。ある人は、競合している技術と手法がSAML 2.0標準が世に出るときにまとまるのではないかと信じていた。現在ではごく少数のWebアクセス管理製品のみがSAMLをサポートしているが、技術の実装は、アプリケーション統合のためのカスタマイズとユーザインタフェースの開発のために、主に必要とされる。要するに、それがなぜFIMが大木つて成長している産業であるかの理由である。

この本の向こうの範囲の大きな絵を無視し、集中したシステムへのすべてのユーザとグループのマイグレーション管理は、正しい方向への第一歩である。Microsoft Active Directoryサービス(ADS)やその他のプロプライエティなものか、general security service application programming interface(GSSAPI)サービスによって定義されているプロトコルを使う数々の認証メカニズム(kerberosのような)の柔軟な組み合わせができる情報アクセス(LDAPのような)のための、標準プロトコルを提供するオープンソースシステムのような、ディレクトリ中にアイデンティティ管理システムデータを位置づけるのは、相互運用性のための基本である。

ますます多くの会社がLDAPシステムを使うことを許可するための異なったレガシープラットフォームのために認証エージェントを提供する。OpenLDAPの使用で、LDAP標準のオープンソース実装が支配的である。実際、LDAPとMicrosoftADSを使うためにSambaで提供することは、Sambaが、高度な拡張性とSambaは、組織のネットワーク技術に届くように前進することを意味する。

Microsoft ADSは、集中化した認証基盤を提供するために拡張できる、制限付きの完全に商用なサービスを提供する。SambaとLDAPは、集中化した認証基盤の拡張のための同様な機会を提供するが、実際、Sambaチームは、LDAPあるいは他のものを使って、認証サービスの拡張の導入中で、、持続可能な選択とFIMマーケットプレイス中での競合をより多く作成する、ntlm_authユーティリティのような完全なツールをSQUID(OSSのプロキシサーバ)のようなアプリケーションのために先を見越している。

もしも、プライマリドメインコントロールが大きなサイトに適合した拡張性があれば、LDAPを使うことが出来るに違いない。それを使うためのすばやいOpenLDAPとSambaの設定は、ディレクトリの時代が始まったことの十分な証明である。Samba-3はLDAPの使用を要求しないが、分散可能なユーザとグループのイデンティティ情報のメカニズムのための要求は、それを不可避の選択としている。

この時点で、SambaベースのBDCの使用は、LDAPアクセスありの使用を必要とする。最も一般的な、Sambaサイトによって使われるLDAP実装はOpenLDAPである。標準準拠の任意のLDAPサーバを使うことも可能である。それらは、IBM、CA、Novell(e-Directory)とその他で知られている。

ドメイン制御の基礎

長年の間に、ドメイン管理に関する一般の理解はほとんど神話の世界になってきた。ドメイン制御についての基本を概観する前に、ドメインコントローラの3つのタイプについて説明する。

ドメインコントローラの種類

  • NT4スタイルプライマリドメインコントローラ

  • NT4スタイルバックアップドメインコントローラ

  • ADSドメインコントローラ

プライマリドメインコントローラあるいはPDCはMicrosoftWindows NTで重要な役割を演じる。Windows 200xドメインアーキテクチャ中ではこの役割はドメインコントローラが担う。Microsoft Windowsネットワークにおけるドメインコントローラーの役割は、ドメインコントローラーがネットワークの中で最も強力で最も能力のあるマシンでなければならないことを示す、ということになっている。ところが、おかしなことを言うと思われるかも知れないが、ネットワークの全体的な性能を高めるためには、インフラストラクチャー全体がバランスのとれたものでなければならない。ドメインコントローラよりもスタンドアロン(ドメインメンバ)サーバに投資する方が賢明である。

Microsoft Windows NT4スタイルドメインの場合、新しいドメイン制御データベースを初期化するのはPDCである。これにより、Security Account Manager (SAM)と呼ばれるWindowsレジストリの一部分が形成される。これは、NT4スタイルのドメインユーザの認証とBDCのドメイン認証データベースとの同期で鍵となる役割を果たす。

Microsoft Windows 200xサーバベースのActive Directoryドメインでは、一つのドメインコントローラが、複数のドメイン・コントローラーの階層関係を初期化し、一つ一つのコントローラーが管理権限を代行する領域を与えられる。マスタドメインコントローラは下位のいずれかのドメインコントローラの決定を上書きする能力を持っているが、下位のコントローラはその下位のコントローラのみ制御する。Samba-3では、この機能はLDAPベースのユーザとマシンアカウントバックエンドを使うことで実現できる。

Samba-3では、新たにNT4スタイルのSAMデータベース(レジストリファイルの1つ)と同じタイプのデータを保持するバックエンドデータベースを使う機能が入った。[1]

バックアップドメインコントローラまたはBDCはネットワーク認証リクエストの処理に重要な役割を演じる。BDCはPDCに優先してログオン要求に答えるようになっている。BDCとPDCの両方があるネットワークセグメント上では、ネットワークログオン要求はおおむねBDCが処理する。PDCはBDCが高負荷(ロードアベレージが大きい)ときにログオン要求に応える。ユーザがWindowsドメインメンバクライアントにログオンした時、ワークステーションは最も近いネットワークログオンサーバを探すために、ネットワークに問い合わせを行う。WINSサーバが使われている時は、WINSサーバへの問い合わせで行われる。もしもネットログオンサーバがWINS問い合わせでは見つからないか、WINSサーバがない場合、ワークステーションはUDPブロードキャストプロトコル上でmailslotブロードキャスト経由でNetBIOS名前検索を実行する。これは、Windowsクライアントが使うことが出来るネットログオンサーバがたくさんの変数によって影響され、それゆえ、PDCまたはBDCが特定のログオン認証要求を処理する単純な決定要素はない。

Windows NT4 BDCはPDCに昇格することが出来る。BDCがPDCに昇格する時にPDCがオンラインならば、以前のPDCは自動的にBDCに降格する。Samba-3ではこれは自動的には行われない。PDCとBDCは手動で設定し、その他適切な変更を行う必要がある。

Microsoft Windows NT4では、インストール時に、サーバのマシンタイプが何になるかを決める。BDCからPDCへの昇格やその逆も可能である。Windows NT4ドメインコントローラからドメインメンバサーバかスタンドアロンサーバへの変換のためにMicrosoftが提供している唯一の手法は、再インストールである。インストール時に提供されている選択肢は以下の通り:

  • プライマリドメインコントローラ ドメインSAMを生成するサーバ。

  • バックアップドメインコントローラ ドメインSAMのコピーを受け取るサーバ。

  • ドメインメンバサーバ ドメインSAMのコピーを持たない。すべてのアクセス制御についてドメインコントローラから認証を受け取るサーバ。

  • スタンドアロンサーバ SAM同期を行わず、固有の認証データベースを持ち、ドメインセキュリティでは何の役割も担わないサーバ。

Note

Algin Technology LLC はWindows NT4スタンドアロンサーバをPDCまたはBDCに昇格することとその逆ができるが可能な商用ツールを提供している。さらなる情報はAlginのWebサイトを参照のこと。

Samba-3サーバはsmb.confファイルに簡単な変更をすることで、ドメインコントローラへ、あるいはドメインコントローラから容易に変換できる。Samba-3はWindows200xサーバのActive Directoryドメインでのネイティブなメンバとして完全に振る舞える。

完全な図を提供するために、Microsoft Windows 2000 ドメイン制御の設定はサーバがインストールされた後に行われる。ドメインメンバサーバへの変換、あるいはドメイン制御からの変換を行うための手順と、Active Directoryサービスのサポートのインストール、あるいはActive Directoryから抜けるための方法については、Microsoftの資料を参照してほしい。

Samba-3での新機能として、SAM複製コンポーネントを除く、Microsoft WindowsNT4スタイルのドメインコントローラ機能の実装が上げられる。しかし、Samba-3はMicrosoft Windows 200xドメイン制御プロトコルについてもサポートすることも注目してほしい。

現時点で、Samba-3はネイティブADSモード中でのドメインコントローラとして機能することが出来るように見えるが、これは限定的で実験的なものでしかない。この機能はSambaチームがそれに対する公式のサポートを提供するまで使うべきでない。その時期になれば、すべての設定上・管理上の要件を正当に反映するためにドキュメント類は改訂されるだろう。SambaはWindows 2000/XP環境中ではNT4スタイルのドメインコントローラとして振る舞うことが出来る。しかし、以下のように一定の短所(訳注:未実装の機能)がある:

  • マシンポリシーファイルがない

  • グループポリシーオブジェクトがない。

  • 同期して実行されるActive Directoryログオンスクリプトがない。

  • ユーザとマシンを管理するためのActive directory管理ツールが使えない。

  • レジストリの変更でメインのレジストリに恒久的な変更が残るが、Active Directoryを使うときには、結果が残らない。

  • Active Directoryなしでは、特定のアプリケーションを特定のユーザとグループにエクスポートできない。

ドメイン制御の準備

Microsoft Windows のマシンが、お互いに他のサーバやドメインコントローラとやりとりするのには2つの方法がある:そのうちの1つは、一般的にワークグループメンバとして呼ばれているスタンドアロンシステムであり、もう1つは、一般的にドメインメンバと呼ばれている、セキュリティシステム中で全面的に参加するものである。

ワークグループのメンバであるために、特別な設定は必要ないということに注意してほしい。ただ、ネットワーク設定に、ワークグループのエントリーについて共通に使う単一の名前を持つようにマシンを設定するだけである。この時WORKGROUPという名前を使うのが一般的である。この設定モードでは、マシン信頼アカウントはなく、メンバシップの概念は、すべてのマシンがネットワーク環境の中で、論理的に一緒のグループにまとめられているという以上のものではない。繰り返すが、明確言うと、ワークグループモードは、セキュリティの確保されたマシンアカウントを含まない

ドメインメンバのマシンは、ドメインアカウントデータベース中にマシン信頼アカウントを持つ。ドメインメンバシップを有効にするには、おのおののマシン上で以下の特別な手続きが必要である。この手続きは、ローカルマシンのAdministratorアカウントによってのみ行うことが出来、これにより、ドメインマシンアカウント(もしも存在しなければ)を作成し、そのアカウントを初期化する。クライアントが最初にドメインにログオンすると、それがマシンアカウントのパスワード変更処理のトリガとなり自動的に起動される。

Note

Sambaがドメインコントローラとして設定されるとき、セキュアなネットワーク操作はMicrosoft Windows NT4/200x/XP Professionalクライアントがすべてドメインメンバとして設定されることを要求する。もしもマシンがドメインのメンバでなければ、それはワークグループ(スタンドアロン)マシンとして操作される。ドメインメンバシップに関係する情報は ドメインメンバシップを参照してほしい。

以下はMicrosoft Windows NT4/200x/XPクライアントのための、Microsoft WindowsNT4スタイルとしてSamba-3を設定するために必要な手順である:

  • 基本的なTCP/IPとMicrosoft Windows ネットワークの設定。

  • 正しいサーバの役割の指定(security = user)。

  • 一貫性のある名前解決の設定。[2]

  • Windows NT4/200x/XP Professionalクライアントのためのドメインログオン。

  • 移動プロファイルの設定か、明示的にローカルプロファイルを強制使用する設定。

  • network/systemポリシーの設定。

  • ドメインユーザアカウントの追加と管理。

  • Microsoft Windows NT4/2000 ProfessionalとWindows XP Professionalクライアントマシンがドメインメンバになるような設定。

以下の準備はMicrosoft 9x/Meクライアントに機能を提供するために必要な手順である:

  • 基本的なTCP/IPとMicrosoft Windowsネットワークの設定。

  • 正しいサーバの役割の指定(security = user)。

  • ネットワークログイン設定(Windows 9x/Me/XP Homeは技術的にドメインメンバに なれないため、ドメインログオンにおけるセキュリティ面には実際には参加しない)。

  • 移動プロファイルの設定

  • システムポリシーの取り扱いの設定。

  • Microsoft Windowsネットワーク用のクライアントネットワークドライバのインストール とドメインにログオンするための設定。

  • もしもすべてのクライアント共有アクセスがドメインユーザ/グループ識別子に従って制御されることが望ましいならば、Windows 9x/Meクライアントをユーザレベルのセキュリティに設定 。

  • ドメインユーザアカウントの追加と管理。

Note

移動プロファイルとシステム/ネットワークポリシーは、高度なネットワーク管理の話題で、このドキュメントのデスクトッププロファイル管理システムとアカウントポリシーで触れられている。しかしながら、それらはWindows NT ネットワークのコンセプトに関連するので、必ずしもSamba PDCに固有の説明ではない。

ドメインコントローラはSMB/CIFSサーバであって以下を行う:

  • 自分自身をドメインコントローラとして登録し、公告する(NetBIOSブロードキャストに 加え、UDPブロードキャスト上でのMailslotブロードキャスト、WINSサーバへのUDPユニキャスト、 DNSとActive Directory経由での名前登録によって)。

  • NETLOGON サービスの提供(これは実際、複数のプロトコル上で動くサービスの集合体である。 それらにはLanManログオンサービス、Netlogonサービス、ローカルセキュリティアカウント サービスとそれらのバリエーションを含む。)。

  • NETLOGONという共有が提供される。

それらを提供するためにSambaを設定することはむしろ容易である。おのおののSambaドメインコントローラは Sambaがdomain logons機能(smb.confファイル中のパラメータから取って)と呼ぶNETLOGONサービスを提供しなければならない。さらに、Samba-3ドメイン中の1つのサーバはドメインマスタブラウザとしてそれ自身を公告しなければならない。[3]これにより、与えられたドメインまたはワークグループにDMB識別されるようなドメイン固有のNetBIOS名をPDCが取得することになる。ブロードキャストで分離されたサブネットの、同じドメインまたはワークグループ上の複数のローカルマスタブラウザ(LMB)は、WAN全体のブラウズリストの完全なコピーのために問い合わせを行う。ブラウザクライアントは次にそれらのLMBに接続し、ブロードキャストで分離されたサブネットのためのリストだけではなく、ドメイン全体のブラウズリストを受け取る。

ドメイン制御: 設定例

Samba PDCを作成するための作業の第一歩はsmb.conf中で必要なパラメータの理解である。PDCとして機能するためのsmb.confの例は以下のPDC用のsmb.confの例である。

Example 4.1. PDC用のsmb.confの例

[global]
passdb backend = tdbsam
os level = 33
preferred master = auto
domain master = yes
local master = yes
security = user
domain logons = yes
logon path = \\%N\profiles\%U
logon drive = H:
logon home = \\homeserver\%U\winprofile
logon script = logon.cmd
[netlogon]
path = /var/lib/samba/netlogon
read only = yes
[profiles]
path = /var/lib/samba/profiles
read only = no
create mask = 0600
directory mask = 0700

上記の例中で示される基本的なオプションの説明は以下の通り:

passdb backend

ここにすべてのユーザとグループアカウント情報が含まれている。PDCで使える値は: smbpasswd, tdbsamとldapsamである。guest エントリは既定値のアカウントを提供し、それは既定値で含まれている;明示的に 追加する必要はない。

BDCを使う場合、passdb backendを配信するために論理的な唯一の選択肢は LDAPを使うことである。tdbsamとsmbpasswdファイルは効果的に配信できないため、それを 使うべきではない。

ドメイン管理パラメータ

パラメータos level, preferred master, domain master, security, encrypt passwordsdomain logonsはドメイン 管理とネットワークログオンのサポートを確実にするために中心的な役割を演じる。

os levelは32以上にし、user モードセキュリティ、Microsoft互換の暗号化パスワードサポート、 ネットワークログオンサービス(ドメインログオン)を提供するように 設定しなければ ならない。暗号化パスワードは有効にしなければならない。 この設定についての詳細は、 アカウント情報データベースを参照のこと。

環境パラメータ

パラメータlogon path, logon home, logon drivelogon script は環境サポートの設定で、クライアントログオン操作機能を支援し、ネットワーク管理の 間接費用を軽減するための、自動コントロール機能の提供するものである。 それらのパラメータに関しては、マニュアルページの情報を参照してほしい。

NETLOGON共有

NETLOGON共有はドメインログオンとドメインメンバシップサポートで中心的な役割を演じる。 この共有はすべてのMicrosoftドメインコントローラ上で提供される。これは、ログオン処理のために 必要となるかもしれない他の共通ツールを見つけるのと同じように、ログオンスクリプト の提供と、グループポリシーファイル(NTConfig.POL)の格納のために使われる。これは、 ドメインコントローラ上で不可欠な共有である。

PROFILE共有

この共有はユーザのデスクトッププロファイルを格納するために使われる。各ユーザ はディレクトリのrootにこの共有を持たねばならない。このディレクトリはユーザが 書き込み可能で、グローバルに読み込み可能でなければならない。Samba-3は fake_permissionsと呼ばれる、この共有上にインストール可能な VFSモジュールを用意している。これはSambaの管理者が、全員に対してこのディレクトリを 読み込みのみにすることを許可する。もちろん、これはプロファイルが適した形で作成された 後に行ってこそ有用である。

Note

上記のパラメータが、サーバの動作モードを決めるパラメータの一式であると思って良い。smb.confパラメータのうち必須のものを以下に列挙する:

netbios name = BELERIAND
workgroup = MIDEARTH
domain logons = Yes
domain master = Yes
security = User

この節中にある、長いリスト中で示されている追加のパラメータは、より完全な説明のためのものである。

SambaによるADSドメイン制御

Samba-3はActive Directoryサーバとしては機能しない。真のActive DirectoryのPDCとして機能することもできない。いくつかのActive Directoryドメインコントローラの機能用のプロトコルが実験的なものとして部分的に実装されてはいる。しかし、Samba-3がそれらのプロトコルをサポートするとは思わないでほしい。現在または将来にわたって、そのような任意の機能に依存しないでほしい。Sambaチームは将来これらの機能を取り除いたり機能を変更するかもしれない。このことをここに言及するのは、これらの秘密の機能をすでに発見し、この機能が完成されるのはいつかという質問を寄せられた方々のためである。その答えは、「出来るかもしれないし出来ないかもしれない!」である。

たしかに、Samba-3はMicrosoft Windows NT4スタイルのドメインコントローラが持つ大部分の機能を提供するように設計されている。Samba-3にはWindows NT4の全ての機能があるわけではないが、一方Windows NT4 ドメインコントローラにはない多くのの特徴を持っている。要するに、Samba-3はNT4でもWindows Server 200xでもない。もちろんActive Directoryサーバでもない。この言い方で全ての人に簡単にシンプルに理解していただけると期待している。

ドメインとネットワークログインの設定

ネットワークとドメインのログオンについて、ここで言及するのは、ドメインコントローラが提供する本質的な機能の欠かせない部分だからである。

ドメインネットワークログオンサービス

すべてのドメインコントローラはネットログオンサービスを動かさなければならない(Samba中でのドメインログオン)。1つのドメインコントローラがdomain master = Yes(PDC)と設定しなければならない;すべてのBDCではパラメータをdomain master = Noと設定しなければならない。

設定例

Example 4.2. PDCにするためのsmb.conf

[global]
domain logons = Yes
domain master = (PDCならYes, BDCならNo)
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = Yes
browseable = No

Windows XP Home Editionにおける特別な例

次のことを完全に理解してほしい:Microsoft Windows XP Home Editionを Microsoft Windows NT4またはActive Directoryドメインセキュリティに統合したいと思ってもそれが出来ない。これを解決する唯一のオプションは、Microsoft Windows XP Home EditionからMicrosoft Windows XP Professional へのアップグレードを購入することである。

Note

Microsoft Windows XP Home Editionはどのようなタイプのドメインセキュリティ機能に参加する能力は持っていない。Microsoft Windows 9x/Meと異なり、Microsoft Windows XP Home Edition はネットワークにログオンする機能を完全に欠いている。

このことは前にも説明したが、この事について、Sambaチームの誰かに質問を問い合わせたり、メーリングリストに質問を投げないでほしい。なぜなら「出来ないから」である。それが出来るとなると、それはMicrosoftとの間のライセンスに違反することになるので、それをしないことを推奨する。

Windows 9x/Meにおける特別な例

ドメインとワークグループはネットワークブラウジングという言葉において全く同等である。2つの違いは、ネットワークへの安全なログインのための、分散認証データベースはドメインに関連づけられることである。また、ドメインログオンサーバに対して認証が成功したユーザに対して異なるアクセス権を付与できる。Samba-3はこの機能をMicrosoft Windows NT/200xと同じ方法で行う。

ドメインへのログオンするSMBクライアントは、ドメイン内のすべての他のサーバが同じ認証情報を受け取ることを期待している。ドメインとワークグループのネットワークブラウズ機能は同一であり、この文書内の、ブラウジングに関する節の中で説明される。ブラウジングはログインサポートとは直交する(互いに他方への影響を考慮する必要のない)概念であることに留意してほしい。

シングルログオン(訳注:シングルサインオンか?)ネットワークモデルに関連する課題はこの節で扱う。Sambaはドメインログオン、ネットワークログオンスクリプト、ユーザプロファイルを、この節で扱う、Microsoft Windows for WorkgropsとMicrosoft Windows 9x/Meクライアントに対してサポートする。

ドメイン中のSMBクライアントがログオンしようとした時、ログオンサーバを探す要求をブロードキャストする。最初にリプライするものが処理を行い、Samba管理者がインストールした何らかの機構を使ってパスワードを認証する。サーバ間でユーザデータベースが共有されていないドメイン(つまり、サーバが、本質的にはワークグループサーバーでありながら、しかも自分はドメインに参加していると他に周知するようなドメイン)を作成することも可能である(お勧めはしないが)。これは認証機構がドメインとはかなり異なるものでありながら、ドメインと密接に関係しているということを示している。

これらの機能を使うことで、Sambaサーバ経由でクライアントのログオンの確認させることができる。すなわち、ネットワークにログオンした時にクライアント側でバッチファイルを実行させ、クライアントの個人設定、デスクトップおよびスタートメニューをダウンロードさせる。

Microsoft Windows XP Home edition はドメインに参加できず、ドメインログオンの使用が許可されない。

設定手続きの話に入る前に、Windows 9x/Meクライアントがログオンをどのように実行するかを見ておくことにしよう:

  1. クライアントは(それがいるサブネットのIPブロードキャストアドレスに 対して)NetLogon要求をブロードキャストする。これは、NetBIOSレイヤ でのNetBIOS名 DOMAIN<1C> に送られる。クライアントは、最初に受け取った回答を選ぶ。 その回答には\\SERVERという形式で、ログオンサーバのNetBIOS 名を含む。1Cという 名前はドメインコントローラ(netlogonサービスを提供するSMB/CIFSサーバ) によって登録された名前のタイプである。

  2. クライアントがそのサーバに接続し、ログオンし(SMBsessetupXを実行) し、次にIPC$共有に接続する(SMBtconXを使って)。

  3. クライアントは、ユーザのログオンスクリプト名を検索する NetWkstaUserLogon要求を送る。

  4. クライアントは次にNetLogon共有に接続し、そのスクリプトを検索する。 もしも見つかり、読み出しできるならば、クライアントはそれを取り出し 実行する。その後、クライアントはNetLogon共有の接続を切る。

  5. クライアントは、サーバにNetUserGetInfo要求を送り、プロファイル検索の ために使うユーザのホーム共有を検索する。NetUserGetInfo要求の 応答はユーザのホーム共有以外のものは含まれていないので、Windows 9x用のプロファイルは ユーザのホームディレクトリ内になければならない。

  6. クライアントはユーザのプロファイルを検索するために ホーム共有に接続する。その時、共有名とパスでユーザのホーム共有を指定する こともできる。例をあげると、\\server\fred\.winprofile である。もしもプロファイルが見つかれば、それを適用する。

  7. クライアントは次にユーザのホーム共有を切断し、NetLogon共有に再接続し、 ポリシーファイルCONFIG.POLを探す。もしも見つかれば、 それを読み、適用する。

PDCとWindows 9x/Me ログオンサーバ設定の主要な違いは以下の通り:

  • Windows 9x/Me ログオンサーバでは、パスワード暗号化は不要である。しかし、 Microsoft Windows 98 以降、既定値では平文パスワードサポートが無効化され ていることに注意。システムとアカウントポリシー で記述されているレジストリの変更で再度有効に出来る。

  • Windows 9x/Me クライアントはマシン信頼アカウントを必要とせず、かつ使わない。

Samba PDCは Windows 9x/Meログオンサーバとしてどうさする。すなわち、Windows 9x/Meが期待するネットワークログオンサービスを提供するということである。

Note

平文パスワードの使用は避けることを強く推奨する。それを使うと、ネットワークトラフィックを解析するネットワークようなツールを使うことで、容易にパスワードを検出できてしまうからである。

セキュリティモードとマスタブラウザ

わかりにくい点が残らないように、最後に幾つかコメントを記述する。userモード以外でのセキュリティモードの時に、Sambaをドメインコントローラとして設定してもよいかについては、さまざまな議論があった。技術的な理由でうまくいかないセキュリティモードは、share モードのセキュリティのみである。domainモードとserver モードのセキュリティは、実際にはSMBのuserレベルのセキュリティの変形のようなものである。

この問題は、Samba がドメインコントローラとして機能しているときに、そのワークグループのドメインマスタブラウザでなければならないかという議論と密接に関連している。純粋なMicrosoft Windows NTドメイン中では、PDCはDMBになるために選択に勝ち、次に、DOMAIN<1B>というNetBIOS名を登録する。これはWindowsクライアントがDOMAIN<1C>名を探すためにネットワークログオンサーバ見つけるときに使う名前である。DMBはドメインマスタブラウザである。ネットワークブラウジングの章WORKGROUPブラウジングの設定を参照のこと。この問題も議論に密接に結びついている。Microsoft PDC はDMBになるためにelectionに勝つことを期待するが、もしも勝てない場合、electionはDMBになるためのelectionに負けたという内容をWindowsイベントロガー(訳注:イベントビューワ?)に、警告メッセージを短い間隔で連続して出力する。この理由のため、SambaサーバがPDCであるネットワーク中では、SambaドメインコントローラをDMBとして設定するのが賢いやり方である。

Note

DOMAIN<1C>名を登録するSMB/CIFSサーバは、ネットワークログオンサービスを提供するのでそのように処理する。DOMAIN<1B>名を登録するサーバはDMBであるすなわち、DOMAIN<1D>名を登録されたすべてのマシンを含んでのブラウズリスト同期の責任を持つと言うことである。後者は、存在しているローカルネットワークセグメントで、すべてのNetBIOS名の登録監視に責任があるLMBである。ネットワークログオンサービス(NETLOGON)はドメイン制御に関連していているが、ネットワークブラウジングとブラウズリスト管理には関係していない。1Cと1B/1Dの名前サービスはお互いに無関係である。

security = user以外のモードでSambaドメインコントローラを使うための設定の問題に戻ろう。ユーザからの接続要求を検証するためにSambaホストが他のSMBサーバかドメインコントローラを使うように設定した場合、ネットワーク上の他のマシン(password server)は、Sambaホストよりもより詳しくユーザについて知っているという状況になる。99%のケースで、この別のホストはドメインコントローラである。ドメインモードセキュリティで動作している場合、workgroupパラメータは(すでにドメインコントローラが持っている)Windows NTドメインの名前に設定しれなければならない。もしもそのドメインがドメインコントローラをまだ持っていない場合、ドメイン自体がないのと同じである。

すでに定義上PDCを持つドメイン用にSambaサーバをドメインコントローラとして設定することは問題を発生させる。それゆえ、そのドメインに対してDMBになるようにとsecurity = userを設定するようにSambaドメインコントローラをいつでも設定すべきである。この方法のみが公式にサポートされる操作モードである。

よくあるエラー

$マシン名中に$を含められない

通常/etc/passwdに格納されるマシンアカウントは、マシン名に$を追加した形である。いくつかのBSDシステムはユーザ名に$を使うものが作成できない。最近のFreeBSDのバージョンはこの制限が取り払われたが、それより古いものはまだ使われている。

問題はエントリを作る時に使われるプログラム中のみである。一度作成されると問題なく動作する。まず$なしでユーザ名を作る。次に、エントリを編集するために vipwを使い$を追加する。あるいは、最初からエントリをvipwで作っても良い。その際には固有のユーザログインIDを使うようにすること。

Note

マシンアカウントはワークステーションが持つ名前と同じ名前でなければならない。

Note

UNIXのツールvipwは直接/etc/passwdを修正する共通的なツールである。vipwを使うと(もしも使われているならば)shadowファイルがパスワードファイルと同じになることを保証する。これはセキュリティの観点から重要である。

存在するマシンアカウントがあるためにドメイン参加に失敗する

I get told,マシン信頼アカウント作成時に `You already have a connection to the Domain....'(既にドメインへの接続があります。) か`Cannot join domain, the credentials supplied conflict with an existing set...'(ドメインに参加できません。信用情報が既存のものと一致しません)が出ることについては以前に話した。

これは、そのマシン自身からマシン信頼アカウントの作成を使用としたとき、Samba PDC上の共有(かIPC$)にすでに接続している(つまりマップされたドライブ)がある時に起きる。以下のコマンドはすべてのネットワークドライブ接続を切断する:

C:\> net use * /d

これはすべてのネットワーク接続を切る。

さらに、もしもマシンがすでに参加済みのドメインと同じ名前のworkgroupのメンバならば(これはやってはいけない)、このメッセージが出る。ワークグループを何か別の名前に変えて再起動し、もう一度やってみる。

システムにログオンできない(C000019B)

ドメイン参加に成功したが、Sambaのバージョンを新しくした後、ログオン時に`The system cannot log you on (C000019B). Please try again or consult your systemadministrator(システムはあなたのログオンを許可できません(C000019B)。後ほど再試行するか、システム管理者に相談してログオンしてください)というメッセージが出た。'

これはsecrets.tdbに格納されているドメインSIDが変わったことによって引き起こされるものである。ドメインSIDが変わるよくある理由は、ドメイン名かサーバ名(NetBIOS名)が変わったことである。問題を解決する唯一の方法はオリジナルのドメインSIDに戻すか、クライアントをいったんドメインから削除して再参加することである。ドメインSIDは、netまたはrpcclientユーティリティによってリセットすることも出来る。

ドメインSIDをリセットしたり、変更するには、以下のようにnetコマンドを使用する:

root# net getlocalsid 'OLDNAME'root# net setlocalsid 'SID'

ワークステーションのマシン信頼アカウントはドメイン(またはネットワーク)SIDでのみ動作する。このSIDが変更されると、ドメインメンバ(ワークステーション)はドメインにログオンできない。オリジナルのドメインSIDはsecrets.tdbファイルから復元できる。別の解は、おのおののワークステーションが再度ドメインに参加することである。

マシン信頼アカウントがアクセスできない

ドメインに参加しようとした時 "The machine account for this computer either does not exist or is not accessible(このコンピューターのマシン・アカウントは存在しないか、アクセスできません) ."というメッセージが出た。何が悪い?

この問題は、PDCが適切なマシン信頼アカウントを持っていないことに起因する。アカウント作成時にadd machine scriptという方法を使った場合、このメッセージは、アカウント作成に失敗したことを示している。ドメイン管理ユーザのシステムが動作しているかを確認して正常動作するようにすること。

かわりに、手動でアカウントエントリを作成していた場合、正しく作られていないということである。Samba PDC上でsmbpasswdファイル中のマシン信頼アカウントのエントリが正しく出来たかどうかを確認する。もしも、smbpasswd ユーティリティを使わないでアカウントをエディタで追加した場合、アカウント名をマシンのNetBIOS名に$を追加して(すなわち、computer_name$)おくこと。これはSambaSAMAccountバックエンドと同じようにPOSIX UNIXシステムアカウントバックエンドの両方の中に存在する必要がある。Samba-3の既定値のバックエンド(すなわち、パラメータpassdb backend)はsmb.confファイル中で指定されておらず、また、もしも指定されているものがsmbpasswdだった場合、それらはそれぞれ/etc/passwd/etc/samba/smbpasswd(あるいはもしもSambaチームの既定値の設定を使ってコンパイルした場合は/usr/local/samba/lib/private/smbpasswd)である。/etc/passwdの使用はNSS /etc/nsswitch.confファイル中の別の設定で上書きすることが出来る。

SambaサーバとNTクライアントの間のサブネットマスクの不一致により、この問題が起こるという報告も一部から上がっている。クライアントとサーバ両方で整合性を取るようにすること。

アカウントが無効

NT4/W200xワークステーションからSambaドメインにログオンしようとしたとき、アカウントが無効になっているメッセージが出た。

smbpasswd -e usernameでユーザアカウントを有効化する。これは通常アカウント作成時に行われる。

ドメインコントローラが無効

Sambaが開始してから数分間、クライアントがエラー`Domain Controller Unavailable'(ドメイン・コントローラーが使えません。)を表示する。

ドメインコントローラはネットワーク上にその役割をアナウンスする。これは通常しばらくかかる。最低15分は待ち、再度試してみること。

ドメイン参加後ドメインメンバワークステーションにログオンできない

ドメイン参加成功後、2つのメッセージのうちの1つが出てユーザログオンに失敗する:1つはドメインコントローラが見つからないというもので、もう1つはアカウントがドメインにないか、パスワードが違うというものである。これは、schannel(セキュアchannel)の設定か、smb 署名の設定について、WindowsクライアントとSamba-3サーバにおいて設定の不一致によるものと考えられる。以下を実行して、Sambaのclient schannelserver schannelclient signingserver signingの設定とそれらの値について確認すること:

testparm -v | grep channel

また、MMC ローカルセキュリティの設定を使うこと。このツールはコントロールパネルにある。ポリシーの設定は、ローカルポリシー/セキュリティオプション領域にあり、Secure Channel:..., and Digitally sign...(セキュリティチャネル、 デジタル的に署名)という言葉を含んだ項目で設定する。

これらが Samba-3 サーバー設定と一致した設定になっていることが大切である。