Chapter 6. ドメインメンバシップ
Prev | Part II. サーバ設定の基本 | Next

## Chapter 6. ドメインメンバシップ

### John H. Terpstra

Samba Team

`<jht@samba.org>`

### Jeremy Allison

Samba Team

`<jra@samba.org>`

### Gerald (Jerry) Carter

Samba Team

`<jerry@samba.org>`

### Andrew Tridgell

Samba Team

`<tridge@samba.org>`

### Jelmer R. Vernooij

The Samba Team

`<jelmer@samba.org>`

### Guenther Deschner

LDAP updates
Samba Team

`<gd@samba.org>`

ドメインメンバシップはきわめて重要な事項である。SambaはMicrosoftドメインセキュリティコンテキスト中においてメンバサーバとして参加できねばならず、Sambaはドメインマシンメンバ信頼アカウントを付与できねばならない。これなしには多くのユーザに実行可能なオプションを提供できないだろう。

この章では、ドメインメンバシップに関する背景情報、Sambaの設定と、Microsoft Windows クライアントのドメインに参加方法について説明する。なぜそれが必要なのであろうか?なぜならば、現在のMicrosoft Windowsネットワーキングと、特にUNIX/Linuxネットワーキングおよび管理の世界に関してかなりの間違った情報、誤解があり、また知識の欠如が顕著だからである。この章によってその欠如を埋めることを望みたい。

## 機能と利便性

Microsoft Windows ワークステーションおよびサーバがドメインセキュリティに参加するためには、ドメインメンバにならなければならない。ドメインセキュリティに参加することは、しばしばシングルサインオンか省略してSSOと呼ばれる。この章では、ワークステーション(かあるいはMicrosoft Windows NT4/200xサーバであるもう一台のサーバ)又はSambaサーバを、Microsoft Windowsドメインセキュリティのメンバにするための手順について説明する。

Samba-3 はNT4形式のMicrosoft Windowsドメインにネイティブなメンバサーバとして、Microsoft Windows Active Directoryドメインにネイティブなメンバサーバとして、あるいは、Sambaドメイン管理ネットワークに参加できる。ドメインメンバシップはたくさんの利点を持つ:

- Microsoft WindowsワークステーションユーザはSSOの利点を享受できる。

- ドメインユーザアカウントの(アクセス)権限とファイルの所有権およびアクセス制御は 単一のドメインセキュリティアカウントマネージャ(SAM)データベース から設定できる(ドメインメンバであるMicrosoft Windowsワークステーション と同様にドメインメンバサーバで動作する)。

- ドメインメンバであるMicrosoft Windows NT4/200x/XP Professional ワークステーションのみがネットワークログオン機能を使える。

- ドメインメンバのワークステーションを、ポリシーファイル (`NTConfig.POL`)およびデスクトッププロファイルを使用 してよりよく制御できる。

- ログオンスクリプトを使用することで、ユーザはアプリケーションサーバ 上のネットワークアプリケーションへ自由にアクセスできる。 (訳注:意味はこれでよい?)。 Through the use of logon scripts, users can be given transparent access to network applications that run off application servers.

- ネットワーク管理者にとっては、より優れたアプリケーション管理およびユーザアクセス 管理が可能になる。ユーザアカウントを、中央にあるドメインデータベース (NT4/SambaでのSAM形式ドメインか、LDAPによるディレクトリがバックエンドになった NT4ドメインか、Active Directory基盤経由で)以外の任意のネットワーク クライアントかサーバ上でユーザアカウントを保守する必要がないからである。

## MicrosoftWindowsワークステーション/サーバのマシン信頼アカウント

マシン信頼アカウントは(ユーザではなく)クライアントマシンをドメインコントローラサーバに対して認証するために使われる。Windowsの用語では、これは“コンピュータアカウント”として知られている。マシン信頼アカウントの目的は、不正(訳注:rogue)ユーザとドメインコントローラが、共謀してドメインメンバのワークステーションにアクセスすることを防ぐことである。

マシン信頼アカウントのパスワードは、ドメインコントローラとの間で暗号化通信を行うために共通の秘密鍵(訳注:shared secret:共通鍵?)である。これは、同じNetBIOS名を持つ未認証マシンがドメインに参加し、ドメインセキュリティ操作をし、ドメインユーザ/グループアカウントへアクセスすることを得ることを防ぐセキュリティ機能である。Windows NT/200x/XP Professionalクライアントはマシン信頼アカウントを使うが、Windows 9x/Me/XP Homeは使わない。従って、Windows 9x/Me/XP Homeクライアントは、マシン信頼アカウントを持たないため、ドメインコントローラとの間で、共通の秘密鍵を持つことはなく、決してドメインの真のメンバにはなれない。

Windows NT4 PDCはマシン信頼アカウントをWindowsレジストリ中に格納する。Microsoft Windows 2000の登場と共に、Active Directoryという、マシン信頼アカウントのための新しいリポジトリが登場した。それに対し、Samba PDCはマシン信頼アカウントを以下のように2つの部分に分けて格納する:

- ドメインセキュリティアカウントは`smb.conf`ファイル中で設定される passdb backendに格納される。格納される アカウント情報の性質は、選択されたバックエンドデータベースの タイプに依存する。

  このデータのより古い形式は`smbpasswd`データベースで、 そこにはUNIXのログインID、UNIXのユーザ識別子(UID)、LanManおよびNT形式で 暗号化されたパスワードを格納している。また、ここでは触れないが、その他 にもいくつかの情報が含まれている。

  より新しいデータベースは、ldapsamとtdbsamと呼ばれる。どちらも、以前の `smbpasswd`ファイルよりもかなりより多くのデータを格納する。 その付加情報により、新しいユーザアカウント管理の新しい方法が可能になる。

- 対応するUNIXアカウントは通常`/etc/passwd`に格納される。 UNIX ユーザアカウントを必要としないような、より簡便なオペレーションの実現 に向けて開発中だが、この機能は Samba-3 の初期リリースまでは実装されない予定 である(訳注:この部分は古い)。

マシン信頼アカウントの作成には3つの方法がある:

- UNIX/Linuxコマンド行からの手動作成。この方法では、Sambaとそれに対応する UNIXアカウントが手動で作成される。

- NT4ドメインコントローラからMicrosoft Windows NT4サーバマネージャを使うか、 MicrosoftのWebサイトから入手可能なNexusツールキットを使う。このツールは ユーザが管理者アカウントでログオンしている限り、任意のMicrosoft Windows マシンから実行することが出来る。

- “その場での(on the fly)”作成。Sambaマシン信頼アカウントは、 クライアントがドメインに参加したときに、Sambaによって自動的に作成 される(セキュリティ上、この方法が推奨される)。対応するUNIX アカウントは自動でも、手動ででも作成できる。

Microsoft Windows NT4/200x/XP ProfessionalもSambaもマシン信頼アカウントを強制する方法を提供しない。これは管理者の選択問題である。

### マシン信頼アカウントの手動作成

マシン信頼アカウントの手動作成の最初の手順は、`/etc/passwd`中に対応するUNIXアカウントを手動で作成することである。この作業は、`vipw`か、通常、新規のUNIXアカウント作成時に使われる“adduser”コマンドを使用する。以下は、LinuxベースのSambaサーバにおける例である:

    root# /usr/sbin/useradd -g machines -d /var/lib/nobody \   -c "machine nickname" \   -s /bin/false machine_name$ root# passwd -l machine_name$

上記の例では、全マシンアカウントのプライマリグループとして使われる“machines”という、既存のシステムグループがある。以下の例では、“machines”グループのGIDは100である。

*BSDシステム上では、この作業は`chpass`ユーティリティを使うこともできる:

    root# chpass -a \'machine_name$:*:101:100::0:0:Windows machine_name:/dev/null:/sbin/nologin'

`/etc/passwd`のエントリは“$”を追加したマシン名を付けたもので、パスワードは持たず、シェル情報が空白で(訳注:/dev/nullを指定すること)、ホームディレクトリの定義がない。たとえば、マシン名が“doppy”の場合は`/etc/passwd`のエントリは以下のようになる:

    doppy$:x:505:100:machine_nickname:/dev/null:/bin/false

上記の例では、`machine_nickname`はクライアントに対する任意の名前を記述する(たとえばBasementComputer)。`machine_name`はドメインに参加するときのクライアントのNetBIOS名でなければならない。“$”をクライアントのNetBIOS名に必ず付加しなければならず、これがないと、Sambaはこれをマシン信頼アカウントと認識できない。

対応するUNIXアカウントが作成されると、次の手順は初期マシン信頼アカウントの、よく知られたパスワードを持つクライアント用のSambaアカウントを作成することである。これは以下に示すような`smbpasswd`を使用する:

    root# smbpasswd -a -m machine_name

ここで`machine_name`はマシンのNetBIOS名である。新規のマシンアカウントのRIDは対応するUNIXアカウントのUIDから生成される。

### クライアントをドメインに即座に参加させる

この方法でマシン信頼アカウントを手動作成することは、 Windows NT PDC でによりサーバマネージャによりマシン信頼アカウントを作成するのと同等である。アカウントが作成されてからクライアントがドメインに参加してパスワードを変更するまでの間、同じ NetBIOS 名を持つマシンでドメインに参加しようとする侵入者の被害を受ける可能性がある。 PDC は、ドメインのメンバを信頼するようにできており、多くのユーザ情報をこのようなクライアントに渡してしまう。注意すること!

### NT4サーバマネージャによるドメインマシンアカウントの管理

有効なadd machine scriptはマシン信頼アカウントの自動作成に必須である。これは自動アカウント作成機能を使用する場合でも、NT4 ドメインサーバマネージャを使用する場合でも必要である。

ドメインを管理しようとしているマシンがMicrosoft Windows NT4 ワークステーション又はMicrosoft Windows 200x/XP Professionalの場合、使用するツールは`SRVTOOLS.EXE`というパッケージである。これをターゲットディレクトリで実行すると、`SrvMgr.exe`及び`UsrMgr.exe`(どちらもMicrosoft Windows NT4 ワークステーションのドメイン管理ツール)が解凍される。

ワークステーションがMicrosoft Windows 9x/Meファミリー製品であれば、 Microsoft のWebサイトから`Nexus.exe`パッケージをダウンロードする。それをターゲットディレクトリから実行すると、上記と同じツールで、9x/Meプラットフォーム用のものが解凍される。

これらのツールに関する詳細情報は次のKnowledge Baseの記事で得ることができる: 173673と172540

`srvmgr.exe`(ドメイン用のサーバマネージャ)を起動し、以下の手順を実行する:

Procedure 6.1. サーバマネージャによるドメインマシンアカウント管理

1. メニューからコンピュータを選択する。

2. Select Domainをクリックする。

3. Select Domainパネルで管理対象の ドメイン名をクリックし、 OKをクリックする。

4. 再度メニュー画面からコンピュータを選択する。

5. Add to Domainを選択する。

6. ダイアログボックス中で、Add NT Workstation of Server ラジオボタンをクリックし、フィールドにマシン名を入力し、 Addボタンをクリックする。

### マシン信頼アカウントの即時作成

マシン信頼アカウント作成の第3の(そして推奨する)方法は、クライアントがドメインに参加する時、必要に応じて Samba サーバーアカウントを作成する方法である。

Samba の各マシン信頼アカウントは対応するUNIXアカウントを必要とするので、通常、 UNIXアカウントを自動作成する機能が提供されている。これには `smb.conf`ファイル内に add machine script オプションを設定する必要がある。しかし、この方法は必須ではなく、対応するUNIXアカウントを手動で作成しても構わない。

以下は、Red Hat linux での例である:

`[global]`
`add machine script = /usr/sbin/useradd -d /var/lib/nobody -g 100 -s /bin/false -M %u`

### Microsoft Windows ワークステーション又はサーバをドメインメンバにする

Microsoft Windows ワークステーションやサーバをドメインのメンバにする手順は Windowsのバージョンによって異なる。

#### Windows 200x/XP Professionalクライアント

ユーザーがクライアントをドメインメンバにする時、 Windows 200x は、ドメイン内で マシンアカウントを作成する権限を持つアカウント及びパスワードの入力を要求する。 Samba管理者アカウント(すなわち、Sambaサーバ上で`root`権限を 持つSambaアカウント)をここで入力せねばならない。通常のユーザアカウントが入力さ れると、この作業は失敗する(訳注:net rpc rightsでSeMachineAccountPrivilege権限を 持ったユーザも出来るのでは?)

セキュリティのため、この管理者アカウントのパスワードは`/etc/passwd` でルートユーザ用に使用されているパスワード以外のものを設定するべきである。

ドメインメンバのマシンアカウントを作成するために使用するアカウント名は ネットワーク管理者が任意に選択する。もしそれが`root`以外なら `smb.conf`中のパラメータ username map = /etc/samba/smbusers で指定するファイル名中で容易にマッピングできる。

Samba管理者アカウントのセッションキーは、マシン信頼アカウントのパスワード 設定の際、暗号化キーの機能を果たす。マシン信頼アカウントはその場でで作成 されるか、または、既に存在していれば更新される。

#### Windows NT4 クライアント

マシン信頼アカウントが手動作成された場合、Identification Changes メニュー画面でドメイン名を入力するが、 Create a Computer Account in the Domain チェックボックスにはチェックを入れない。こうすることでマシン がドメインに参加する際に既存のマシン信頼アカウントが使用される。

もしマシン信頼アカウントがその場で作成される場合は、Identification Changes メニュー画面でドメイン名を入力し、 Create a Computer Account in the Domain チェックボックスにチェックを入れる。この場合、上記 Windows2000用 の手順に従いドメインに参加する(プロンプトに対してSamba管理者 アカウント名を入力する)。

#### Sambaクライアント

Joining a Sambaクライアントをドメインに参加させる方法は 次の章に記述されている。

## ドメインメンバサーバ

このモードのサーバ操作は、Sambaマシンをドメインセキュリティコンテキストのメンバーにすることを含む。またこれは定義上、全てのユーザ認証は中央で定義された認証機構(訳注:authentication regime)で行われることを意味する。この認証機構は NT3/4形式(旧式のドメインテクノロジー)サーバ又はMicrosoft Windows 2000以降で実装されているActive Directory server(ADS)が提供する。

もちろん、認証バックエンド自体はSambaがサポートしている分散ディレクトリ構造のサーバなら、いずれでも構わない。LDAP(OpenLDAPベース) 、SunのiPlanet、Novellの e-Directoryなどが使用可能である。

### Note

SambaがLDAPやその他のアイデンティティ管理、あるいは、ディレクトリサービスを使用するように設定される場合、ユーザ及びマシン認証を継続して実行するのはSambaである。Sambaが行う認証をLDAPサーバが代替するわけではないことに注意。

ドメインメンバサーバーのドメインマシンアカウント作成に関する詳細情報やSambaドメインメンバマシンがドメインに参加し完全に信頼されるようにする方法に関しては、ドメイン管理の章を参照のこと。

### Samba-3でNT4形式でのドメインに参加する

下記の表に、この後この章で使用される名前を示す。

Table 6.1. 前提

Samba DMSのNetBIOS名: | SERV1
Windows 200x/NTドメイン名: | MIDEARTH
ドメインのPDCのNetBIOS名: | DOMPDC
ドメインのBDCのNetBIOS名: | DOMBDC1とDOMBDC2

まず`smb.conf`ファイルを編集し、Sambaが以後ドメインセキュリティを使用するように設定しなければならない。

`smb.conf`中の[global]セクション中にsecurity行を、下記のように変更(又は追加)する:

`security = domain`

もしも、パラメータ`security = user`が使われているならば、このマシンはスタンドアロンサーバで動作するのでドメインメンバサーバではないことに注意。ドメインセキュリティモードはSambaにドメインセキュリティコンテキスト内で動作するようにさせる。

次に、`[global]`セクション中のworkgroup行を下記のように修正する:

`workgroup = MIDEARTH`

これが参加するドメイン名である。

ユーザーが NT PDC で認証されるようにencrypt passwordsパラメータを`yes`に設定しなければならない。もしこのパラメータが特に指定されていなければ、既定値で設定されている。このパラメータを設定する必要はないが、もしも`smb.conf`ファイル中で指定されたならば、必ず`Yes`に設定されねばならない。

最後に、[global]セクションのpassword server行を下記のように追加(又は修正)する:

`password server = DOMPDC DOMBDC1 DOMBDC2`

これらはSambaがユーザ認証のために通信を行うプライマリ及びバックアップのドメインコントローラである。Sambaは各サーバに対し、リスト順に接続するので、複数のドメインコントローラの間で認証負荷を分散するためには、このリストの順番を適宜変更してもよい。

代わりに、認証に使用するドメインコントローラのリストを smbdが自動的に決めるようにしたい場合、この行を次のように設定する:

`password server = *`

この方法で、NTと全く同じメカニズムをSambaが使用するようにできる。この方法はブロードキャストベースの名前解決を使用するか、WINS データベースの検索により認証するドメインコントローラを決めるか、DNSによる名前解決によりドメインコントローラを見つける。

ドメインに参加するために次のコマンドを実行する:

    root# net rpc join -S DOMPDC -UAdministrator%password

もしも、`-S DOMPDC`引数が与えられない場合、ドメイン名は`smb.conf`から入手し、PDCのNetBIOS名は、WINS検索を使うか、NetBIOSブロードキャストベースの名前検索のどちらかで入手する。

マシンがDOMドメインに参加しようとしていて、そのドメインのPDC(ドメインのSAMデータベースへの書き込み権限のある唯一のマシン)がDOMPDCなので、`-S`オプションを使用する。`Administrator%password`は、はマシンをドメインに追加するのに必要な権限を持つアカウントのログイン名とパスワードである。これが成功すれば、使用しているターミナルの画面に下のようなメッセージが表示される。古いNT4式のドメイン環境使用の場合:

    Joined domain DOM.

Active Directory使用の場合、ADSドメインへ参加するためのコマンドは以下の通り:

    root#  net ads join -UAdministrator%password

成功すると以下の結果が表示される:

    Joined SERV1 to realm MYREALM.

詳細情報については、`net`のマニュアルページとリモート管理の章を参照のこと。

この手順により、事前にPDC上でマシン信頼アカウントを作成する必要はなく、サーバがドメインに接続できる。

このコマンドは、マシンアカウントパスワード変更プロトコルを通して、Sambaサーバの新規(任意の)マシンアカウントパスワードを、smbpasswdファイルが通常格納されているディレクトリと同じディレクトリにあるファイルに書き込む。DMSによって必要とされる信頼アカウント情報は`/usr/local/samba/private/secrets.tdb`か`/etc/samba/secrets.tdb`ファイル中に書かれる。

このファイルはrootにより作成・所有され、root 以外のユーザは読めない。これが、システムのドメインレベルのセキュリティの鍵を握る部分であり、シャドウパスワードファイル同様に慎重に扱わなければならない。

最後に、Sambaのdaemonを再起動し、クライアントがドメインセキュリティを使用開始する準備をする。Samba デーモンの再起動方法はディストリビューションにもよるが、ほとんどの場合は次のとおりである:

    root# /etc/init.d/samba restart

### これがなぜ`security = server`よりもすぐれているのか?

現在、Samba のドメインセキュリティでは、サーバに紐づくユーザに対応するローカルUNIXユーザを作成しなければならない。このことは、もしも、ドメインユーザ`DOM\fred`がドメインセキュリティのSambaサーバーに紐づく場合、UNIXファイルシステム上にそれに対応するfred というローカル UNIXユーザーがいなければならないことを意味する。これは以前のSambaのセキュリティモードであるsecurity = serverと似ているが、このモードでは、Windows 95又はWindows 98サーバと同じように、 Sambaが認証リクエストをWindows NT サーバーに回送していた。

UNIX の UID 及び GID を自動的に Windows NT ドメインユーザ及びグループへ割り当てるシステムについての情報はWinbind: ドメインアカウントの使用を参照のこと。

ドメインレベルのセキュリティの利点は、NT サーバと全く同じように、ドメインレベルセキュリティにおける認証が、認証されたRPC チャンネルを通ることである。これは、Sambaサーバが NT サーバと全く同じやり方でドメインの信頼関係に参加できることを意味する(すなわち、Sambaサーバをリソースドメインに追加し、リソースドメインPDC からアカウントドメイン PDC に認証を渡してもらうことができる)。

さらに、security = server(訳注:サーバレベルのセキュリティ)を使う場合、サーバ上のすべてのSambaデーモンは、起動している限り認証サーバーと接続し続けなければならない。これはMicrosoft NTサーバの接続リソースを使い果たし、利用可能な接続がなくなることになりかねない。それに対しsecurity = domain(訳注:ドメインレベルのセキュリティ)の場合は、Sambaデーモンはユーザー認証に必要な時のみPDC/BDCに接続し、その後接続を切断する。これにより PDC の接続リソースを節約することができる。

最後に、NT サーバと同じように PDC 認証を行うということは、認証の返答の一部として、ユーザ SIDやユーザが属する NTグループなどのユーザ識別情報を、Samba サーバーが受け取ることを意味する。

### Note

この文書の内容の大半は、ウェブマガジンLinuxWorldの記事http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html Doing the NIS/NT Sambaとして最初に発表された(訳注:リンク切れ)。

## Samba ADS ドメインメンバシップ

これは、Windows 200x KDC に対し Kerberos認証を行うSamba-3の設定方法の概略である。Kerberosの知識を有することを前提としている。

### `smb.conf`の設定

最低以下の3つのオプションを`smb.conf`で使用しなければならない:

`realm = your.kerberos.REALM`
`security = ADS`
# もしも存在するときのみ、以下のパラメータを指定する必要がある。
# もしも存在しないときの既定値はYesである。
`encrypt passwords = yes`

Samba がレルム名を使用して適切な ADS サーバーを正確に識別できない場合、`smb.conf`中のpassword serverオプションを使用する:

`password server = your.kerberos.server`

ADSドメインコントローラを識別できない最も共通的な理由は、ADS基盤のDNS要求条件に関係なくUNIXシステム上でいくつかのDNSサーバを保守しているサイトの問題である。`password server`を使って、優先するADSドメインコントローラを指定することは問題ない。

### Note

smbpasswdファイルは必要でなく、古いクライアントはあたかもsecurity = domainのように認証され、何の害もなく、ドメインに入らないローカルユーザーを持つことができる。

### `/etc/krb5.conf`の設定

MIT 及び Heimdal Kerberosでは、`/etc/krb5.conf`の設定は必要なく、時に害となることがある。

Microsoft ADSは、DNSの`_kerberos._tcp.REALM.NAME`に、レルム内の各KDCのSRVレコードを、自動的に作成する。 これは、Active Directoryドメインを作成するために使われるインストールと設定プロセスの一部である。KDCはKerberosのキー配信センタであり、Microsoft Active Directory基盤の不可欠な部分として構成されている。

UNIXシステムは、Windows2000 KDCにで認証を行うために、kinitとDES-CBC-MD5又はDES-CBC-CRCという種類の暗号手法を使える。Windows 2000 ADSのkerberos相互運用性に関連する詳細情報は、Interoperabilityというガイドを参照のこと。もう1つの、とても有用な、Kerberosの相互運用性に関する一般的な情報として参照できる文書は、RFC1510である。このRFCはKerberosの操作についてのたくさんの不可思議な背景について説明している。

MITとHeimdalでは、最新のKRB5ライブラリがSRVレコードをチェックするように既定値で設定されていて、従って、自動的にKDCを見つける。さらに、`krb5.conf`は、たとえ2つ以上あったとしても単一のKDCの指定のみ許可する。DNSルックアップを使用することによりKRB5ライブラリは使用可能な任意のKDCを使用できる。

手動で`krb5.conf`を設定する場合の最小限の設定は次のとおり:

    [libdefaults]	default_realm = YOUR.KERBEROS.REALM[realms]	YOUR.KERBEROS.REALM = {	kdc = your.kerberos.server	}[domain_realms]	.kerberos.server = YOUR.KERBEROS.REALM

Heimdal のバージョン 0.6 以前を使用する場合は次のように設定する:

    [libdefaults]	default_realm      = YOUR.KERBEROS.REALM	default_etypes     = des-cbc-crc des-cbc-md5	default_etypes_des = des-cbc-crc des-cbc-md5[realms]        YOUR.KERBEROS.REALM = {        kdc = your.kerberos.server	}[domain_realms]        .kerberos.server = YOUR.KERBEROS.REALM

`kinit`USERNAME`@`REALM``を実行して設定をテストし、パスワードが Windows 2000 KDC に認証されることを確認する。

Heimdal 0.6.x 以前のバージョンでは、ADSで新規に作成されたアカウントであるか、移行後にパスワードが変更されたアカウントであるか、インストール後に`Administrator`であれば使用できる。現行、Windows 2003 KDCはHeimdal のバージョン 0.6 以降のリリース(かつkrb5.conf内にetypesの既定値の設定がないもの)とのみ使用できる。残念ながらこの領域はいまだに流動的な状態である。

### Note

レルムは大文字でなければ、“Cannot find KDC for requested realm while getting initial credentials(最初の認証情報取得時にリクエストされたレルムの KDC を見つけられない)”というエラーが表示される(Kerberos は大文字・小文字を区別する)。

### Note

2つのサーバは時間の同期を取らなければならない。もし時間差が5分以上になるとメッセージ“kinit(v5): Clock skew toogreat while getting initial credentials(kinit(v5): 最初の認証情報取得時にクロックスキューが過大)”が表示される。

Kerberos プロトコルではクロックスキューの限界値を設定できる。既定値は5分である。

更に、使用するKDCのIP アドレスによる逆引きDNS検索をできるようにしなければならない。また、この逆引きDNS検索がマッピングする先の名前はKDCのNetBIOS名(すなわち、ドメインに紐づかないホスト名)またはレルムが後に付くNetBIOS名のどちらでもよい。

以上を確実に行うための最も簡単な方法は、使用するKDCのIPアドレスをマッピングする`/etc/hosts`のエントリを、KDCのNetBIOS名に追加することである。もし正しくなければ、レルムに参加しようとするとlocal errorが発生する。

smbclient中でのKerberos のサポートのみが必要な場合は、次の項は飛ばして直接smbclientでのテストに進むこと。コンピュータアカウントの作成とサーバ設定のテストは、smbdとwinbinddでKerberosのサポートをしたい場合にのみ必要である。

### コンピュータアカウントの作成

Samba のプライベートディレクトリに書き込み権限があるユーザ(通常はroot)として以下を実行する:

    root#  net ads join -U Administrator%password

管理者アカウントは、ADSドメインにマシンを追加することを許可されているADSドメインセキュリティの設定中で指定された任意のアカウントでも良い。それはもちろん、Administrator以外のアカウントを使うことは良いアイデアである。UNIX/Linuxシステム上では、このコマンドはUID=0(root)であるアカウントによって実行されねばならない。

複雑な組織内でWindowsクライアントをADSドメインのメンバにする場合、特定の組織単位内でマシンアカウントを作成しても良い。Samba-3では次の構文でこれを実現できる:

    root#  kinit Administrator@your.kerberos.REALMroot#  net ads join createcomputer="organizational_unit"

ADS管理者は"organizational_unit"パラメータに指定すべきものを助言することも可能である。

例をあげると、ある組織ディレクトリ“Computers/BusinessUnit/Department,”の配下の“Servers”というコンテナにマシン信頼アカウントを作成したい場合は以下のようになる:

    root#  net ads join "Computers/BusinessUnit/Department/Servers"

このコマンドは、コンテナ`Computers/BusinessUnit/Department/Servers`中に、Sambaサーバのマシン信頼アカウントを置く。コンテナはこのコマンドを実行する前にADS ディレクトリ中に存在しなければならない。バックスラッシュはOU名とその他の文字に対するエスケープ文字の両方として有効な文字のため、普通のスラッシュを使わなければならないことに注意。もしもOU名にバックスラッシュを使う必要があるならば、シェルによる解釈と、LDAPによる解釈を考慮して4重にする必要がある。

#### よくあるエラー

ADS サポートがコンパイルされていない

  Kerberosライブラリとヘッダファイルのインストール後に、Samba を再設定(config.cache を削除) して、リコンパイルする(make clean all install)。

net ads joinがユーザー名の入力を要求する

  `kinit `USERNAME`@`REALM`` を使ってドメインにログインする必要がある。 `USERNAME`はマシンをドメインへ追加する権限を持つユーザーでなければならない。

サポートされない暗号/もしくはチェックサムタイプ

  `/etc/krb5.conf`システムにインストールされているKerberosの タイプとバージョンに対して適切に設定されているか確認する。

### サーバ設定のテスト

参加に成功したら、Active DirectoryにSambaサーバのNetBIOS名の付いた新規のコンピュータアカウントが表示される(ユーザとコンピュータ配下の“コンピュータ”フォルダ中)。

Windows 2000 クライアントでは、`net use * \\server\share`を試してみること。パスワードを知らないでもKerberos にログインできるはずである。もしも失敗したら、`klist tickets`を実行すること。サーバー用のチケットを取得できたか?それには暗号タイプ DES-CBC-MD5 があるか?

### Note

SambaはDES-CBC-MD5暗号及びARCFOUR-HMAC-MD5符号を使用できる。

### smbclientによるテスト

Sambaサーバ上でsmbclientとKerberosを使用してWindows2000サーバ又はSambaサーバにログインすることを試みる。smbclientは通常通り使用するが、Kerberos認証を選択するように、`-k`オプションを指定する。

### 注意

ドメインコントローラインストール後は、正しい暗号化タイプを作成するために、少なくとも一度は管理者パスワードを変更しなれけばならない。

Windows200xは既定値のDNS設定では`_kerberos._udp`や`_ldap._tcp`を作成しないようである。おそらく今後サービスパックで修正されるだろう。

## Sambaドメインメンバ間でのユーザIDマッピング共有

SambaはUNIXユーザ及びグループ(それぞれUIDとGIDで識別される)をWindowsユーザ及びグループ(SIDで識別される)にマッピングする。これらのマッピングは Sambaの`idmap`サブシステムが行う。

これらのマッピングをSambaドメインメンバー間で共有することは、名前からIDへのマッピングが全マシンで同一になるので便利である。特に、CIFSとNFSの両方でファイルを共有する場合に有用である。

LDAP `ldap idmap suffix`を使う場合、以下のように設定する:

`ldap idmap suffix = ou=Idmap`

詳細情報については `smb.conf` マニュアルページのldap idmap suffixパラメータのエントリを参照のこと。

ldap admin dnも設定することと、`secrets.tdb`中にLDAP管理用パスワードを設定するのを忘れないこと。これには下記を使用する:

    root#  smbpasswd -w ldap-admin-password

`ldap-admin-password`の部分は、システムで使うLDAPサーバ管理用パスワードで置き換えること。

## よくあるエラー

ドメインメンバのマシンアカウントの追加/削除/再追加の手順の中には、不注意により陥りやすい多くの落とし穴や間違いを招きかねない多くの“事細かな”ことがある。興味深いことにSambaメーリングリストの購読者の中には、マシンアカウントの追加を繰り返し失敗し、最終的にMicrosoft Windows をマシンに“再インストール”しなければならないという結論を出す人がよくいる。しかし、実際はこのような種類の問題で再インストールが必要になることはめったにない。正しい解決法は単純である場合が多く、Microsoft Windowsのネットワーク機能を理解していれば容易に解決できる。

### マシンをドメインに追加し直すことができない

“Windowsワークステーションを再インストールした。元々のドメインマシンアカウントが削除されその直後に再度追加された。同じマシン名を使用するとワークステーションはドメインに参加できない。マシンの追加に失敗する際に、マシンはネットワーク上に存在していないにもかかわらず、マシンが既に存在するというメッセージが表示される。なぜこのように失敗するのか?”

前の名前がまだNetBIOS 名キャッシュに残っているためである。マシンアカウントが削除されると、同じ名前のマシンをドメインメンバとして再度追加できるようになるには、まず、その名前が期限切れにならなければならない。最もよい方法は、古いアカウントを削除し、新しい名前でマシンを追加することである。そのほかに、Windows上のクライアントから以下の`nbtstat`コマンドを使って、名前キャッシュにある現在のデータをフラッシュし、再ロードする。

    C:\>  nbtstat -R

### マシンのドメインへの追加に失敗する

“Windows200xもしくはXP ProfessionalマシンをSamba PDCドメインに追加しようとすると失敗する。エラーメッセージは今回はネットワークの問題によりマシンを追加できませんでした。後ほどやり直して下さい。である(訳注:実際に表示されるメッセージとは違います)。なぜか?”

`smb.conf`ファイル中にadd machine scriptがあることを確認する。もしも存在していないならば、OSプラットフォームに適したスクリプトを追加する。もしも、スクリプトがすでに定義されているならば、その動作をデバッグする必要がある。`smb.conf`ファイル中のlog levelの値を10まで増やし、ドメインへの参加を試行してみる。そのログをチェックし、どの動作が失敗しているか突き止める。

可能性のある原因:

- スクリプトが実際には存在していないか、指定したパスにない。

  是正処置:修正する。スクリプトを手動で実行すると、UNIX システム アカウントとSamba SAM アカウントの両方が追加されることを確認する。

- マシンをUNIXシステムアカウントファイル`/etc/passwd`に追加できない。

  是正処置:マシン名が有効なUNIXシステムアカウント名であるか確認する。 もしもUNIXユーティリティ`useradd`が呼び出されるならば、このツールを 使用して追加したいマシン名を追加できることを確認する。一部のシステム上の `Useradd`は大文字やスペースを名前に使用することを許可しない。

add machine scriptはSamba バックエンドデータベースでは、マシンアカウントを作成しない。Sambaバックエンドデータベースアカウントがマッピングされる先のUNIXシステムアカウントを作成するためにのみあるものである。

### Windows 2003 PDC に参加できない

Windows 2003はSMB署名を必要とする。クライアント側のSMB署名はSamba-3.0で 実現されている。Windows 2003サーバと通信する際には client use spnego = yesに設定する。 この機能は、クライアントは単純にそれ自身とサーバと両方がサポートする プロトコルをネゴシエートするので、Windows 2003が持つより高度なセキュリティ 機能をサポートしない他のWindowsクライアントとインタフェースを取れない。 これは、SMB/CIFSプロトコル中で構築されているよく知られたフォールバック 機能である。

Prev | Up | Next
Chapter 5. バックアップドメインコントローラ | Home | Chapter 7. スタンドアロンサーバ