Table of Contents
この章は、NT4 のドメイン管理から Samba-3 ベースのドメイン管理へ移行したいと考える 人々のための大まかなガイドです。
IT の世界では、しばしば、すべての問題は下手な計画に起因すると言われます。 この言い分への当然の反発としては、すべての問題を予測しそれに対して計画を立てることは 不可能であると言われます。しかし、良い計画は、何もかもが停止してしまうような大々的な 問題の大半を予測できるはずだとも言えるでしょう。
MS Windows NT4 のドメイン管理から Samba-3 のドメイン管理環境に移行したい場合は、 詳細な移行計画を策定すると良いでしょう。 そこで、この章では、移行に着手するための注意点を幾つかご説明します。
大半の組織にとって、MS Windows NT4 から Samba-3 のドメイン管理に移行する際の主たる目的は、 出来るだけ苦労しないことです。新しい環境を使用し続けることを経営陣に納得してもらうことこそが、 移行プロセスにおける課題の一つになると言ってもよいでしょう。 オープンソースの技術を導入した者の多くが、問題の兆しが見えた途端に、 Microsoft ベースのプラットフォーム・ソリューションに戻すようにという圧力をかけられます。
Samba-3 がコントロールするネットワークに移行する前に、全組織的な変革へのコミットメントを 取り付けるためのあらゆる努力をしてください。組織にとって、この変革が なぜ 重要なのか、正確にその理由を知ってください。移行の動機付けとなる理由には、 以下のようなものがあります:
ネットワークの管理性を高める。
ユーザー側での機能性を高める。
ネットワークの運用コストを削減する。
Microsoft 社が NT4 のサポートを止める場合に備え、潜在リスクを軽減しておく。
MS License 6 に関わることを回避する。
組織の Microsoft への依存度を下げる。
Samba-3 が MS Windows NT4 ではないことを、誰もが知っているかどうか確認してください。 Samba-3 は、MS Windows NT4 と異なる第二のソリューションを提供するのみならず、 より優れた長所を提供します。Samba-3 は、Microsoft 社が、MS Windows NT4 から MS Windows 2000 以降のバージョンへの移行を正当化するコアバリューとして宣伝した 多くの特長を持たないことを認識してもらってください。 (これは、Active Directory サービスあり・なしのどちらでも同様です。)
Samba-3 が提供できない特長は何ですか?
Active Directory サーバー
(Active Directory 内の) グループ・ポリシー・オブジェクト
マシン・ポリシー・オブジェクト
Active Directory 内のログオン・スクリプト
Active Directory 内のソフトウェア・アプリケーションとアクセス制御
あなたのサイトに取って、特に説得力があると考えられる Samba-3 の特長は、以下のようなものです:
所有コストの低減
世界中から制約の無いサポートを得られること
動的な SMB サーバー (UNIX/Linux システム一ユニットにつき複数の SMB/CIFS サーバーを走らせることができる。)
オン・ザ・フライのログオン・スクリプト作成
オン・ザ・フライのポリシー・ファイル作成
より高い安定性、信頼性、性能、及び可用性
ssh 接続による管理性
バックエンド認証の柔軟な選択 (tdbsam、ldapsam、mysqlsam)
完全なシングル・サインオンのアーキテクチャーの実現が可能
WAN のバンド幅の需要を最低限に抑えるための認証システムの分散が可能
MS Windows NT4 から Samba-3 へネットワークを移行する前に、必要な要素をすべて考慮してください。 ユーザーには変更内容を研修し、変更により必要な業務に支障を来たすのではなく、 変更を歓迎できるようにするべきです。以下に移行に成功するために考慮するべき要素を挙げます。
Samba-3 は、ドメイン・コントローラー、バックアップ・ドメイン・コントローラー (セカンダリ・コントローラーと呼ぶ方が良いかもしれません)、ドメイン・メンバー、 あるいはスタンドアローンのサーバーのいずれとしても設定できます。 Windows のネットワーク・セキュリティ・ドメインのコンセプトは、導入前にサイズと範囲を 定義しなければなりません。特にプライマリ・ドメイン・コントローラー (PDC) と バックアップ・ドメイン・コントローラー (BDC) の場所には、注意を払う必要があります。 Samba-3 が Microsoft の技術と異なる点の一つは、LDAP 認証バックエンドを使用することを選択すると、 同じデータベースを複数の異なるドメインが使用できることです。複雑性の高い組織では、単一の LDAP データベースを持ち、それ自体を分散させ (マスター・サーバーを一つと複数の スレーブ・サーバーを持たせ)、複数のドメインに同時に対応することができます。
デザインの観点から、サーバー当たりのユーザー数およびドメイン当たりのサーバー数は、 サーバーの容量とネットワークのバンド幅を考慮しながら設計するべきです。
ネットワークの物理的セグメントには、複数のドメインを置くことができます。 その一つ一つが、複数のネットワーク・セグメントにまたがることもできます。 複数のドメインが複数のルーティッド・ネットワーク・セグメントにまたがっているとき、 ネットワークのデザインとレイアウトの性能への影響を考慮・試験してください。 中央に配置したドメイン・コントローラーが、複数のルーティッド・ネットワーク・セグメントに 対応するようにデザインされているとき、深刻な性能上の問題を招くことがあります。 リモート・セグメントと PDC 間のレスポンス時間 (ping 時間) を確認してください。 時間がかかる (100 ミリ秒以上) 場合は、バックアップ・コントローラー (BDC) を リモート・セグメント上に配置し、ローカルな認証サーバー兼アクセス制御サーバーとして 機能するようにします。
効果的なネットワーク・デザインのためには、破るとただでは済まない基本的なルールがあります。 最も重要なルールは、よくコントロールされたネットワークは、必ずシンプルであるというものです。 インフラのすべての部分が管理されければならないのですから、複雑になればなるほど、 そのシステムを安全に機能させ続けるためのハードルは高くなります。
データがどのような方法で共有されなければならないのか、その本質を常に念頭に置いて考えてください。 物理的なディスク・スペースのレイアウトは慎重に考慮してください。データの一部はバックアップが必要です。 ディスクのレイアウトがシンプルであればあるほど、バックアップのニーズを追跡把握し易くなります。 どのバックアップの媒体がニーズにあっているか特定してください。テープ、CD-ROM、DVD-ROM、 その他オフラインのストレージ媒体を考慮します。最低限のメンテナンスで十分なように妥協しないでください。 バックアップが必要なものはすべてバックアップし、テストし、妥当性を確認し、災害復旧計画を策定し、 それがうまく働くことを実証してください。
ユーザーは、データアクセス制御のニーズに従ってグループ分けしてください。 ファイルとディレクトリへのアクセスは、グループごとのアクセス許可によりコントロールするのが 最良の方法であり、グループでコントロールするディレクトリに “スティッキー・ビット” を使用することで、Samba の共有ユーザーからのファイルアクセスに関する苦情を かなり防止することができます。
経験の浅いネットワーク管理者は、ファイル、ディレクトリ、共有、及び共有の定義などに関して、 アクセス制御を設定する際に、複雑なテクニックを使用したがる傾向がありますが、デザインと インプリメンテーションはあくまでシンプルにし、デザインを徹底的に記録してください。 記録したドキュメントを他者に監査してもらってください。後継者が理解できないような複雑で 混乱する状態を作り出さないでください。複雑なデザインとインプリメンテーションによって ジョブの安全性を確保すると、新しい管理者がこんがらかったデザインの謎を解くまでの間 オペレーションが止まり、ユーザーにダウンタイムを我慢してもらうことになります。 アクセス制御はシンプルかつ効果的なものにし、愚かしい複雑性のためにユーザーの業務が 中断されることが絶対にないようにしてください。
ログオン・スクリプトは、すべてのユーザーが必要な共有とプリンターへの接続を得られることを 確保するためのものです。
ログオン・スクリプトはオン・ザ・フライで作成でき、すべての実行コマンドがそのユーザーに与えられる 権利と特権に特化したものにすることができます。NETLOGON 共有への root preexec パラメーターを使ったカスタム化された ログオン・スクリプトを作成する際にグループ情報を使えるように、優先されるコントロールは グループのメンバーであるかどうかにより左右されるようにするべきです。
サイトによっては、コントロールされたユーザー環境を確立するために kixstart のようなツールを使用することを好むでしょう。その場合、ログオン・スクリプトのプロセス・コントロールに 関して Google 検索をすると良いでしょう。特に、Microsoft KnowledgeBase の KB189105 の記事に、 ログオン・スクリプトのプロセスを使ってユーザーの介入なしにプリンターを追加する方法がありますから、 研究されるとよいでしょう。
移行プロセスの概要を以下に説明します。
ユーザー、グループ、ポリシー、プロファイルを持つ NT4 PDC があって、それを移行したい。
Samba-3 は、netlogon 共有、profile 共有、その他をもつ DC として設定。smb.conf を、 BDC として機能するように設定する。つまり、domain master = No とする。
Procedure 31.1. アカウントの移行プロセス
旧 NT4 のドメインに NT サーバー・マネジャーを使用して Samba サーバー用の BDC アカウントを作成する。
Samba は作動中であってはいけない。
net rpc vampire -S NT4PDC -U administrator%passwd
pdbedit -L
注意 ユーザーが移行したかどうか確認する。
UNIX の各グループを NT の各グループに割り当てる: (このテキスト「assign each of the UNIX groups to NT groups」 を initGroups.sh というスクリプトにコピーすると便利です)。
#!/bin/bash #### これをシェル・スクリプトとして将来再利用できるようにとっておく。 # 最初によく知られたドメイン・グローバル・グループを割り当てる。 net groupmap modify ntgroup="Domain Admins" unixgroup=root rid=512 net groupmap modify ntgroup="Domain Users" unixgroup=users rid=513 net groupmap modify ntgroup="Domain Guests" unixgroup=nobody rid=514 # 次に、独自に追加されたドメイン・グローバル・グループを割り当てる。 net groupmap add ntgroup="Designers" unixgroup=designers type=d rid=3200 net groupmap add ntgroup="Engineers" unixgroup=engineers type=d rid=3210 net groupmap add ntgroup="QA Team" unixgroup=qateam type=d rid=3220
net groupmap list
すべてのグループが認識されていることを確認する。
全てのプロファイルを移行し、次に、全てのポリシー・ファイルを移行する。
MS Windows NT4 のドメイン管理から Samba ベースのソリューションへ移行したいと考えるサイトは、大体、 以下の三つの分類のいずれかに入ります。それを 下表 で説明します。
Table 31.1. サイトタイプの主な三分類
ユーザー数 | 内容 |
---|---|
< 50 | 苦労のないシンプルな変換をしたい。 |
50 - 250 | 新しい特長を導入したい。社内で、ある程度複雑な処理に対応できる。 |
> 250 | ソリューションやインプリメンテーションがより良く拡張できることを希望し、複雑なニーズを持つ。部門横断的な決裁プロセスを持ち、大半の分野でローカルに専門知識を持つ。 |
MS Windows NT4 から Samba-3 に移行しようというサイトには、基本的に三つの選択肢があります:
単純な変換 (完全に取替える)
変換しながらアップグレード (統合するという場合もある)
完全な再設計 (全く新しいソリューション)
ダウンストリームの問題を以下の方法で最小限に押さえてください。
十分な時間を掛ける。
パニックにならない。
推定事項はテストで検証する。
ワークステーションへの展開を含め、ロールアウト・プログラム全体をテストする。
下表 に、考慮している移行のタイプ別にわかれた 変換の選択肢を一覧します。
Table 31.2. 変換の選択肢
シンプル | アップグレード | 再設計 |
---|---|---|
OS 固有の特長は、最低限しか使用しない | NT4 の特長を新しいホスト OS の特長に変換する | 以下を決定する: |
全アカウントを NT4 から Samba-3 に移す | コピーし改善する | 認証方式 (データベースの場所とアクセス) |
オペレーションの変更は最小限にする | 漸進的な改善をする | デスクトップ管理メソッド |
移行に掛ける時間を最小限にする | ユーザーへの影響を最小限にする | デスクトップ・ユーザーへより良い管理を適用する |
ライブでの変換 対 隔離した状態での変換 | 機能性を最大化する | 管理性、拡張性、セキュリティ、可用性 のニーズを特定する |
Samba-3 を統合し、ユーザーがアクティブの状態で移行し、その後コントロールを変更する (スワップ・アウトする)。 | 低メンテナンスの機会を活用する |
Samba-3 は外部の認証バックエンドを使用できます。
Winbind (外部の Samba サーバーまたは NT4/200x のサーバー)
外部サーバーは Active Directory または NT4 ドメインを使用できます
pam_mkhomedir.so をホーム・ディレクトリの自動作成に使用できます
Samba-3 は、ローカルの認証バックエンドを使用できます: smbpasswd、 tdbsam、ldapsam、mysqlsam
Samba は、アクセス制御ポイントの設定を以下の方法でできます:
共有 ACL を使って、共有自体の上で設定する。
ファイルとディレクトリ上の UNIX のパーミッションを使用してファイルシステム上で設定する。
Note: ファイルシステムの Posix ACL の有効化もできます。
Samba の共有パラメーターを通して設定することは、最後の手段として以外お勧めできません。
レジストリ変更には慎重を期し、正しいツールを使用し、NT4 式の NTConfig.POL ファイルを通して行った変更は、恒久的な変更になることをよく理解して行ってください。
グループ・ポリシー・エディターを使用する (NT4)
恒久的な変更になることに注意する
プラットフォーム固有なので、ローカル・プロファイルから移動プロファイルに変換するには、 プラットフォームのツールを使用してください。新たに profiles ツールで SID (NTUser.DAT) 変更に使用できるようになりました。
どういう風に動くものかよく学んでください。
ユーザーとグループのマッピングのコードは新しいものです。Samba-2.2.x に慣れているネットワーク管理者が Samba-3 に移行する際に、様々な問題を経験されました。新しいパスワード・バックエンドの動作と 新しいグループ・マッピング機能を説明している章を注意深くお読みください。
username map の機能が必要な場合があります。
net groupmap を使用して NT4 のグループを UNIX のグループに関連付けしてください。
pdbedit を使用してユーザーの設定を設定・変更してください。
LDAP バックエンドに移行するときは、最初 LDAP データベースの情報を LDIF にダンプし、編集して、 LDAP に再度ロードする方が、やり易いかもしれません。
どの OS にも独自の癖があります。これは、デザインした者の経験に基づいたエンジニアリング上の 判断の結果であり、予測されなかった副作用が出ていることがあります。 Windows ネットワーク管理者を困らせる制約には以下のようなものがあります:
ユーザーの追加・削除: 名前サイズにおけるOSからの制約に注意してください。 (Linux は 8 文字まで、NT4 は 254 文字まで。)
マシンの追加・削除: ドメイン・メンバーにのみ適用されます。 (注: マシンネームは 16 文字までに限定さていることがあります。)
net groupmap を使用して NT4 のグループを UNIX のグループに繋げてください。
グループの追加・削除: OS からの名前のサイズや文字に関する制約に注意してください。 Linux では 16 文字までで、スペース、大文字は使用できません。(groupadd)
ドメイン管理 (NT4 式) プロファイル、ポリシー、アクセス制御、セキュリティ
Samba: net, rpcclient, smbpasswd, pdbedit, profiles.
Windows: NT4 ドメイン・ユーザー・マネジャー、サーバー・マネジャー (NEXUS)