Using Samba

Using Samba

Robert Eckstein, David Collier-Brown, Peter Kelly 共著
第一版 1999 年 11月
1-56592-449-5, 注文番号: 4495
416 ページ, 34.95 ドル

ハードコピー版(英語)を購入する

目次


Previous: 1.3 SMB/CIFSネットワークに詳しくなるために Chapter 1
Samba概要
Next: 1.5 An Overview of the Samba Distribution
 

1.4 Microsoftによる実装

ここまでで様々な予備知識を解説し終えたので、MicrosoftによるCIFS/SMBネットワークの世界での前述した概念の実装について説明しよう。既に予期しているだろうが、これまでと同様に、初めて見聞きする複雑な概念の拡張を行うことになる。

1.4.1 Windowsドメイン

同じサブネットに属し、同じSMBグループに所属しているSMBコンピュータの集合体であるワークグループを思い出して欲しい。 Windowsドメインは、これを拡張されたものである。SMBマシンで構成されるワークグループを一歩進めたものであって、サーバがドメインコントローラとして機能する。Windowsドメインを構成するために、 ドメインコントローラが必ず必要である[6]。そうでなければ、ただのワークグループに過ぎない。 図 1.11.を参照して欲しい。

[6]WindowsドメインはMicrosoftからは"Windows NTドメイン"と呼ばれている。これは、Windows NTマシンがドメインコントローラの役割を果たすことを仮定したためにそう呼ばれるようになった。しかしながら、Sambaによって同様にドメインコントローラとしての機能が実現されるので、混乱を避けるために、単に"Windowsドメイン"と呼びことにする。

Figure 1.11: Windowsドメインの簡単な例

Figure 1.11

ドメインコントローラ(ログオンサーバ)では、2つに別々なプロトコルが現在使われている:一つはWindows 95/98マシンと通信するためのプロトコル、もうひとつはWindows NTマシンと通信するためのプロトコルである。Sambaでは、現在Windows 95/98へのドメインコントローラプロトコルを実装している(Windows 9 xマシンのドメインコントローラとして機能可能である)が、Windows NTコンピュータへのプロトコルの完全なサポートはまだ行われていない。しかし、Sambaチームにより、Windows NTへのドメインコントローラプロトコルが来たるSamba 2.1.でサポートされると約束されている。

なぜ困難が伴っているだろうか?。Windowsドメインコントローラがクライアント、他のドメインコントローラと通信する際に使用されるプロトコルは、企業秘密となっており、Microsoftから仕様は公開されていない。このためSamba開発チームは、ドメインコントローラプロトコルで、どのコードが特定のタスクを実行しているか調べるのに、リバースエンジニアリングを行っている。

1.4.1.1 ドメインコントローラ

ドメインコントローラはWindowsドメインの神経中枢であり、NISサーバがUnixネットワーク情報サービスの神経中枢であるのと同様である。ドメインコントローラは様々な責任を負っている。関心を持つ必要であろう責任の一つとして 認証が上げられる。特にパスワードを使用する場合には、認証によってユーザが他のマシンの共有リソースにアクセスすることを許可したり拒否されたりする。

それぞれのドメインコントローラは、ユーザ-パスワードの組合わせを保つのにセキュリティアカウントマネジャー (SAM)を使っている。ドメインコントローラは、ユーザ名に結び付けられたパスワード(一つのユーザに一つのパスワードが割り当てられる)の中央リポジトリとなっている。これにより、それぞれのクライアントマシンが、利用可能なネットワークリソースにアクセスするために、多くのパスワードを保持するよりも効率的になっている。

Windowsドメインでは、認証されていないクライアントがサーバ上の共有にアクセスを要求した場合、サーバは処理を行うために、ドメインコントローラにユーザが認証されたユーザであるかどうか問い合わせを行う。正当なユーザであることが分かると、サーバはサービスとユーザに認証されたアクセス権をもとにしてセッション通信を確立する。さもなくければ、接続は拒否される。ドメインコントローラによって、ユーザは一旦認証されると特殊な認証トークンがクライアントに与えられ、ユーザはドメイン上のその他のリソースにアクセスするためにログインし直す必要がなくなる。この時点でユーザは、ドメインに"ログイン"していると考えて良い。 図 1.12.を参照して欲しい。

図 1.12: ドメインコントローラを使用した認証

Figure 1.12

1.4.1.2 プライマリとバックアップドメインコントローラ

冗長性はWindowsドメインの背後に存在している鍵となる思想である。ドメイン上で、現在稼働しているドメインコントローラは、プライマリドメインコントローラ(PDC)と呼ばれている。同様に、ドメイン上に一つまたはそれ以上のバックアップドメインコントローラが存在可能である。これはプライマリドメインコントローラが落ちたりアクセス不能になった際に、プライマリドメインコントローラに取って代わるものである。この必要が発生した場合に、BDCがクライアントに影響を与えずにDCサービスの移行を実施するために、BDCは頻繁にSAMデータの同期をプライマリドメインコントローラと行う。ただし、BDCはSAMの読み取り専用のコピーしか持たないことに注意して欲しい。;PDCと同期することによってのみデータを更新出来る。Windowsドメインのサーバは、プライマリもしくはバックアップドメインコントローラのSAMをリソースにアクセス、もしくはドメインにログオンしようとするユーザを認証するために使用出来る。

多くの点で、WindowsワークグループとWindowsドメインは似通っている。この事は偶然ではなく、Windowsドメインの概念はWindows NT 3.5が登場するまで発展していなかったのと、WindowsドメインはOSがWindows for Workgroups 3.1のマシンが存在するワークグループで下位互換性を残すようにしたために似通ったものになった。ここで覚えておいて欲しい鍵となる事は、WindowsドメインはWindowsワークグループに一つあるいはそれ以上のドメインコントローラを追加しただけのものであるということである。

Sambaは、Windows 95/98マシンのプライマリドメインコントローラとして問題なく機能する。ただし、Samba 2.0は認証のためのプライマリドメインコントローラとしてのみ機能する;認証以外のPDCの機能は、現在まだ実装されていない(この記述を読む頃までには、Samba 2.1によってNTクライアントのPDCとしてSambaを使用出来るようになっているだろう)。同様にMicrosoftによってSAMデータを同期する際に、クローズドなプロトコルが使用されているので、Sambaでは現在のところバックアップドメインコントローラとして機能しない。

1.4.2 ブラウジング

ブラウジングは、ユーザからの質問:"Windowsネットワークにどんなマシンが存在するの?"という問いに答えるには難解なものである。ワールドワイドウェブのブラウザとは何の関係もない事に注意して欲しい。明記しない限り、"そこに何があるか調べる" という一般的な意味と、Webで行われている意味での使い方は忘れて置いて欲しい。

ブラウジングの前に、ユーザはネットワーク上の接続したい特定のコンピュータの名前を知っておかなければならない。そして、それからアプリケーションやファイルマネジャーでリソースにアクセスするのに、次のようにキーボードからUNCを入力するだろう。 :

\\HYDRA\network\

ブラウジングを用いて、WindowsクライアントのネットワークコンピュータのウィンドウでGUI 操作-この場合はポイント-クリック-することによってマシンに表示されている内容を実行することも出来る。

1.4.2.1 Levels of browsing

この章のはじめの方で示したように、実際にはSMB/CIFSネットワークで行われているブラウジングには2つのタイプがある:

  • (共有リソースも含めて)マシンの一覧をブラウズする

  • 特定のマシンの共有リソースをブラウズする。

最初の内容を検討しよう。それぞれのWindowsワークグループ(ドメイン)のサブネット上では、一台のマシンが、ネットワーク上で現在のところアクセス可能なマシンの一覧を保持する機能を持っている。このコンピュータは ローカルマスタブラウザ と呼ばれており、保持されている一覧は ブラウズリストと呼ばれている。サブネット上のマシンは、ブラウジングの際に生じるネットワークトラフィックの量を削減するためにブラウズリストを使用する。それぞれのマシンが、現在のところ利用可能なマシンの一覧を決定するのに動的にポーリングを行う代わりに、単にコンピュータはローカルマスタブラウザに最新の完全な一覧を取得するための問い合わせを単に行うだけでよい。

マシン上の実際のリソースにブラウズを行うためには、ユーザは特定のマシンに接続しなければならない:この情報は、ブラウズリストから取得することは出来ない。この情報は、マシン上のリソースの一覧をブラウズし Windows 95/98 あるいは NTのネットワークコンピュータにマシンのアイコンが表示された際に、アイコンをクリックすることによって取得出来る。この章の導入の部分で示したように、認証がうまくいった場合、そのマシンはアクセス可能な共有リソースの一覧の提供を行う。

WindowsワークグループのそれぞれのサーバにはNetBIOS名を登録した後、ローカルマスタブラウザに自身の存在を通知し、(理屈の上では)マシンの電源を切る際にワークグループから離脱すると通知する事が要求される。サーバが通知したことを記録しておく事は、ローカルマスタブラウザの機能に含まれる。ローカルマスタブラウザは、初めの方で解説したNetBIOSネームサーバ(NBNS)と同じである必要はない。

注意:Windowsネットワークコンピュータは、奇妙な動作することがある:ブラウズを行う特定のマシンを選択する際にネットワークコンピュータのウィンドウに最新でないデータが表示されていることがある。このことはネットワークコンピュータのウィンドウに既にクラッシュしているマシン、マシン名の変更内容が更新されていないマシンが表示されていることを意味している。簡潔に言えば、一旦サーバを選択して接続を行えば、より確実に共有とプリンタがネットワークに実際に存在しているか知ることが出来る。

ドメインコントローラとは違って、ほとんど全てのWindowsマシン(NT Server、NT Workstation、98、95、更にはWindows 3.1 for Workgroup)がローカルマスタブラウザになることが出来る。ドメインコントローラの場合と同様に、ローカルマスタブラウザが落ちたりアクセス不能になった場合に移行出来るように、ローカルマスタブラウザは一つあるいはそれ以上の バックアップブラウザをローカルサブネット上に持つことが可能である。万全を期してローカルバックアップブラウザはブラウズリストをローカルマスタブラウザと頻繁に同期している。ローカルマスタブラウザとローカルバックアップブラウザを含むようにWindowsドメインの構成図を更新しよう。結果として 図 1.13が示される。

図 1.13: ローカルマスタブラウザとローカルバックアップブラウザを含めたWindowsドメイン

図 1.13

ワークグループに配置されるバックアップブラウザの数の最小値を計算するには次のようにする:

  • If there are between 1 and 32 Windows NT workstations on the network, or between 1 and 16 Windows 95/98 machines on the network, the local master browser allocates one backup browser in addition to the local master browser.

  • If the number of Windows NT workstations falls between 33 and 64, or the number of Windows 95/98 workstations falls between 17 and 32, the local master browser allocates two backup browsers.

  • For each group of 32 NT workstations or 16 Windows 95/98 machines beyond this, the local master browser allocates another backup browser.

There is currently no upper limit on the number of backup browsers that can be allocated by the local master browser.

1.4.2.2 Browsing elections

Browsing is a critical aspect of any Windows workgroup. However, not everything runs perfectly on any network. For example, let's say that the Windows NT Server on the desk of a small company's CEO is the local master browser - that is, until he switches it off while plugging in his massage chair. At this point the Windows NT Workstation in the spare parts department might agree to take over the job. However, that computer is currently running a large, poorly written program that has brought its processor to its knees. The moral: browsing has to be very tolerant of servers coming and going. Because nearly every Windows machine can serve as a browser, there has to be a way of deciding at any time who will take on the job. This decision-making process is called an election.

An election algorithm is built into nearly all Windows operating systems such that they can each agree who is going to be a local master browser and who will be local backup browsers. An election can be forced at any time. For example, let's assume that the CEO has finished his massage and reboots his server. As the server comes online, it will announce its presence and an election will take place to see if the PC in the spare parts department should still be the master browser.

When an election is performed, each machine broadcasts via datagrams information about itself. This information includes the following:

  • The version of the election protocol used

  • The operating system on the machine

  • The amount of time the client has been on the network

  • The hostname of the client

These values determine which operating system has seniority and will fulfill the role of the local master browser. (Chapter 6, Users, Security, and Domains, describes the election process in more detail.) The architecture developed to achieve this is not elegant and has built-in security problems. While a browsing domain can be integrated with domain security, the election algorithm does not take into consideration which computers become browsers. Thus it is possible for any machine running a browser service to register itself as participating in the browsing election, and (after winning) being able to change the browse list. Nevertheless, browsing is a key feature of Windows networking and backwards compatibility requirements will ensure that it is in use for years to come.

1.4.3 Can a Windows Workgroup Span Multiple Subnets?

Yes, but most people who have done it have had their share of headaches. Spanning multiple subnets was not part of the initial design of Windows NT 3.5 or Windows for Workgroups. As a result, a Windows domain that spans two or more subnets is, in reality, the "gluing" together of two or more workgroups that share an identical name. The good news is that you can still use a primary domain controller to control authentication across each of the subnets. The bad news is that things are not as simple with browsing.

As mentioned previously, each subnet must have its own local master browser. When a Windows domain spans multiple subnets, a system administrator will have to assign one of the machines as the domain master browser. The domain master browser will keep a browse list for the entire Windows domain. This browse list is created by periodically synchronizing the browse lists of each of the local master browsers with the browse list of the domain master browser. After the synchronization, the local master browser and the domain master browser should contain identical entries. See Figure 1.14 for an illustration.

Figure 1.14: A workgroup that spans more than one subnet

Figure 1.14

Sound good? Well, it's not quite nirvana for the following reasons:

  • If it exists, a primary domain controller always plays the role of the domain master browser. By Microsoft design, the two always share the NetBIOS resource type <1B>, and (unfortunately) cannot be separated.

  • Windows 95/98 machines cannot become or even contact a domain master browser. The Samba group feels that this is a marketing decision from Microsoft that forces customers to have at least one Windows NT workstation (or Samba server) on each subnet of a multi-subnet workgroup.

Each subnet's local master browser continues to maintain the browse list for its subnet, for which it becomes authoritative. So if a computer wants to see a list of servers within its own subnet, the local master browser of that subnet will be queried. If a computer wants to see a list of servers outside the subnet, it can still go only as far as the local master browser. This works because, at appointed intervals, the authoritative browse list of a subnet's local master browser is synchronized with the domain master browser, which is synchronized with the local master browser of the other subnets in the domain. This is called browse list propagation.

Samba can act as a domain master browser on a Windows domain if required. In addition, it can also act as a local master browser for a Windows subnet, synchronizing its browse list with the domain master browser.

1.4.4 The Windows Internet Name Service (WINS)

The Windows Internet Name Service (WINS) is Microsoft's implementation of a NetBIOS name server (NBNS). As such, WINS inherits much of NetBIOS's characteristics. First, WINS is flat; you can only have machines named fred or workgroups like CANADA or USA. In addition, WINS is dynamic: when a client first comes online, it is required to report its hostname, its address, and its workgroup to the local WINS server. This WINS server will retain the information so long as the client periodically refreshes its WINS registration, which indicates that it's still connected to the network. Note that WINS servers are not domain or workgroup specific; they can appear anywhere and serve anyone.

Multiple WINS servers can be set to synchronize with each other after a specified amount of time. This allows entries for machines that come online and offline on the network to propagate from one WINS server to another. While in theory this seems efficient, it can quickly become cumbersome if there are several WINS servers covering a network. Because WINS services can cross multiple subnets (you'll either hardcode the address of a WINS server in each of your clients or obtain it via DHCP), it is often more efficient to have each Windows client, no matter how many Windows domains there are, point themselves to the same WINS server. That way, there will only be one authoritative WINS server with the correct information, instead of several WINS servers continually struggling to synchronize themselves with the most recent changes.

The currently active WINS server is known as the primary WINS server. You can also install a secondary WINS server, which will take over in the event that the primary WINS server fails or becomes inaccessible. Note that there is no election to determine which machine becomes a primary or backup WINS server - the choice of WINS servers is static and must be predetermined by the system administrator. Both the primary and any backup WINS servers will synchronize their address databases on a periodic basis.

In the Windows family of operating systems, only an NT Workstation or an NT server can serve as a WINS server. Samba can also function as a primary WINS server, but not a secondary WINS server.

1.4.5 What Can Samba Do?

Whew! Bet you never thought Microsoft networks would be that complex, did you? Now, let's wrap up by showing where Samba can help out. Table 1.6 summarizes which roles Samba can and cannot play in a Windows NT Domain or Windows workgroup. As you can see, because many of the NT domain protocols are proprietary and have not been documented by Microsoft, Samba cannot properly synchronize its data with a Microsoft server and cannot act as a backup in most roles. However, with version 2.0. x, Samba does have limited support for the primary domain controller's authentication protocols and is gaining more functionality every day.


Table 1.6: Samba Roles (as of 2.0.4b)

Role

Can Perform?

File Server

Yes

Printer Server

Yes

Primary Domain Controller

Yes (Samba 2.1 or higher recommended)

Backup Domain Controller

No

Windows 95/98 Authentication

Yes

Local Master Browser

Yes

Local Backup Browser

No

Domain Master Browser

Yes

Primary WINS Server

Yes

Secondary WINS Server

No


Previous: 1.3 Getting Familiar with a SMB/CIFS Network Next: 1.5 An Overview of the Samba Distribution
1.3 Getting Familiar with a SMB/CIFS Network Book Index 1.5 An Overview of the Samba Distribution

O'Reilly Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies

© 1999, O'Reilly & Associates, Inc.