Table of Contents
Microsoft Windows のネットワークの世界に考えられないような誤解をしている人がたくさんいる。それは私たちが支援を提供できる機会が増えるということですからそれはそれでいいのだが、この分野で本当にヘルプを必要とする人は、まず、既に一般向けに出されている情報に親しむことを推奨する。
ある程度の基本を理解・修得されてからこの章を読み進めることを推奨する。Microsoft Windowsネットワークでは、誤った設定の影響がはっきりと現れる。Microsoft Windows ネットワークのユーザーから、ネットワーク設定の誤りに起因すると思われる細かなトラブルにしつこく悩まされるという苦情が出ることがよくある。ところが、多くの人々にとって Microsoft Windowsネットワークの世界というのはドメインコントローラーを知るところから始まり、それはネットワーク操作の障害を魔法のように、すべて解決してくれそうに思えるてくるものである。
ドメインの例の図解は典型的な、Microsoft Windows ネットワーク ドメインセキュリティネットワーク環境を図示している。ワークステーションA、BとCは多くの物理的なMicrosoft Windowsネットワーククライアントを代表していると考えられたい。
Sambaメーリングリストから、よくあるネットワークに関する問題の多くを容易に特定できる。もしも以下の話題についてよく分からないのであれば、それについて取り扱っている、このHOWTO文書の節を読むことを強く勧める。以下は、最も一般的なMicrosoft Windowsネットワークの問題である:
基本的なTCP/IPの設定
NetBIOS名の解決方法
認証の設定
ユーザとグループの設定
UNIX/Linux上での基本的なファイルとディレクトリのアクセス制御
ネットワーク環境中で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ネットワーク領域中での残りのすべてのアカウントは全体で一意なセキュリティ識別子を持つ。
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同期を行わず、固有の認証データベースを持ち、ドメインセキュリティでは何の役割も担わないサーバ。
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アカウントによってのみ行うことが出来、これにより、ドメインマシンアカウント(もしも存在しなければ)を作成し、そのアカウントを初期化する。クライアントが最初にドメインにログオンすると、それがマシンアカウントのパスワード変更処理のトリガとなり自動的に起動される。
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クライアントをユーザレベルのセキュリティに設定 。
ドメインユーザアカウントの追加と管理。
移動プロファイルとシステム/ネットワークポリシーは、高度なネットワーク管理の話題で、このドキュメントのデスクトッププロファイル管理とシステムとアカウントポリシーで触れられている。しかしながら、それらはWindows NT ネットワークのコンセプトに関連するので、必ずしもSamba PDCに固有の説明ではない。
ドメインコントローラはSMB/CIFSサーバであって以下を行う:
それらを提供するために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の例
上記の例中で示される基本的なオプションの説明は以下の通り:
ここにすべてのユーザとグループアカウント情報が含まれている。PDCで使える値は: smbpasswd, tdbsamとldapsamである。“guest” エントリは既定値のアカウントを提供し、それは既定値で含まれている;明示的に 追加する必要はない。
BDCを使う場合、passdb backendを配信するために論理的な唯一の選択肢は LDAPを使うことである。tdbsamとsmbpasswdファイルは効果的に配信できないため、それを 使うべきではない。
パラメータos level, preferred master, domain master, security, encrypt passwordsとdomain logonsはドメイン 管理とネットワークログオンのサポートを確実にするために中心的な役割を演じる。
os levelは32以上にし、user モードセキュリティ、Microsoft互換の暗号化パスワードサポート、 ネットワークログオンサービス(ドメインログオン)を提供するように 設定しなければ ならない。暗号化パスワードは有効にしなければならない。 この設定についての詳細は、 アカウント情報データベースを参照のこと。
パラメータlogon path, logon home, logon driveとlogon script は環境サポートの設定で、クライアントログオン操作機能を支援し、ネットワーク管理の 間接費用を軽減するための、自動コントロール機能の提供するものである。 それらのパラメータに関しては、マニュアルページの情報を参照してほしい。
NETLOGON共有はドメインログオンとドメインメンバシップサポートで中心的な役割を演じる。 この共有はすべてのMicrosoftドメインコントローラ上で提供される。これは、ログオン処理のために 必要となるかもしれない他の共通ツールを見つけるのと同じように、ログオンスクリプト の提供と、グループポリシーファイル(NTConfig.POL)の格納のために使われる。これは、 ドメインコントローラ上で不可欠な共有である。
この共有はユーザのデスクトッププロファイルを格納するために使われる。各ユーザ はディレクトリのrootにこの共有を持たねばならない。このディレクトリはユーザが 書き込み可能で、グローバルに読み込み可能でなければならない。Samba-3は “fake_permissions”と呼ばれる、この共有上にインストール可能な VFSモジュールを用意している。これはSambaの管理者が、全員に対してこのディレクトリを 読み込みのみにすることを許可する。もちろん、これはプロファイルが適した形で作成された 後に行ってこそ有用である。
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と設定しなければならない。
次のことを完全に理解してほしい:Microsoft Windows XP Home Editionを Microsoft Windows NT4またはActive Directoryドメインセキュリティに統合したいと思ってもそれが出来ない。これを解決する唯一のオプションは、Microsoft Windows XP Home EditionからMicrosoft Windows XP Professional へのアップグレードを購入することである。
Microsoft Windows XP Home Editionはどのようなタイプのドメインセキュリティ機能に参加する能力は持っていない。Microsoft Windows 9x/Meと異なり、Microsoft Windows XP Home Edition はネットワークにログオンする機能を完全に欠いている。
このことは前にも説明したが、この事について、Sambaチームの誰かに質問を問い合わせたり、メーリングリストに質問を投げないでほしい。なぜなら「出来ないから」である。それが出来るとなると、それはMicrosoftとの間のライセンスに違反することになるので、それをしないことを推奨する。
ドメインとワークグループはネットワークブラウジングという言葉において全く同等である。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クライアントがログオンをどのように実行するかを見ておくことにしよう:
クライアントは(それがいるサブネットのIPブロードキャストアドレスに 対して)NetLogon要求をブロードキャストする。これは、NetBIOSレイヤ でのNetBIOS名 DOMAIN<1C> に送られる。クライアントは、最初に受け取った回答を選ぶ。 その回答には\\SERVER
という形式で、ログオンサーバのNetBIOS 名を含む。1C
という 名前はドメインコントローラ(netlogonサービスを提供するSMB/CIFSサーバ) によって登録された名前のタイプである。
クライアントがそのサーバに接続し、ログオンし(SMBsessetupXを実行) し、次にIPC$共有に接続する(SMBtconXを使って)。
クライアントは次にNetLogon共有に接続し、そのスクリプトを検索する。 もしも見つかり、読み出しできるならば、クライアントはそれを取り出し 実行する。その後、クライアントはNetLogon共有の接続を切る。
クライアントは、サーバにNetUserGetInfo要求を送り、プロファイル検索の ために使うユーザのホーム共有を検索する。NetUserGetInfo要求の 応答はユーザのホーム共有以外のものは含まれていないので、Windows 9x用のプロファイルは ユーザのホームディレクトリ内になければならない。
クライアントはユーザのプロファイルを検索するために ホーム共有に接続する。その時、共有名とパスでユーザのホーム共有を指定する こともできる。例をあげると、\\server\fred\.winprofile
である。もしもプロファイルが見つかれば、それを適用する。
クライアントは次にユーザのホーム共有を切断し、NetLogon共有に再接続し、 ポリシーファイルCONFIG.POL
を探す。もしも見つかれば、 それを読み、適用する。
PDCとWindows 9x/Me ログオンサーバ設定の主要な違いは以下の通り:
Windows 9x/Me ログオンサーバでは、パスワード暗号化は不要である。しかし、 Microsoft Windows 98 以降、既定値では平文パスワードサポートが無効化され ていることに注意。システムとアカウントポリシー で記述されているレジストリの変更で再度有効に出来る。
Samba PDCは Windows 9x/Meログオンサーバとしてどうさする。すなわち、Windows 9x/Meが期待するネットワークログオンサービスを提供するということである。
わかりにくい点が残らないように、最後に幾つかコメントを記述する。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として設定するのが賢いやり方である。
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を使うようにすること。
マシンアカウントはワークステーションが持つ名前と同じ名前でなければならない。
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のメンバ”ならば(これはやってはいけない)、このメッセージが出る。ワークグループを何か別の名前に変えて再起動し、もう一度やってみる。
“ドメイン参加に成功したが、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 schannel、server schannel、client signing、server signingの設定とそれらの値について確認すること:
testparm -v | grep channel
また、MMC ローカルセキュリティの設定を使うこと。このツールはコントロールパネルにある。ポリシーの設定は、ローカルポリシー/セキュリティオプション領域にあり、Secure Channel:..., and Digitally sign...(セキュリティチャネル、 デジタル的に署名)という言葉を含んだ項目で設定する。
これらが Samba-3 サーバー設定と一致した設定になっていることが大切である。