Chapter 7. ドメイン・メンバーシップ

John H. Terpstra

Samba Team

Jeremy Allison

Samba Team

Gerald (Jerry) Carter

Samba Team

Andrew Tridgell

Samba Team

Jelmer R. Vernooij

The Samba Team

Guenther Deschner

LDAP updates

Table of Contents

特長と便益
MS Windows ワークステーション/サーバーのマシン信頼アカウント
マシン信頼アカウントの手動作成
NT4 サーバー・マネジャーによるドメイン・マシン・アカウントの管理
マシン信頼アカウントのオン・ザ・フライでの作成
MS Windows ワークステーションまたはサーバーをドメイン・メンバーにする
ドメイン・メンバー・サーバー
Samba-3 で NT4 式のドメインに参加する
これがなぜ security = server よりもすぐれているのか?
Samba ADS ドメイン・メンバーシップ
smb.conf の設定
/etc/krb5.conf の設定
コンピュータ・アカウントの作成
サーバー設定のテスト
smbclient によるテスト
Notes
Samba ドメイン・メンバー間でのユーザー ID マッピング共有
よくあるエラー
マシンをドメインに追加し直すことができない
マシンのドメインへの追加に失敗する
Windows 2003 PDC に参加できない

ドメイン・メンバーシップはきわめて重要なトピックです。 Samba は Microsoft ドメイン・セキュリティにメンバー・サーバーとして参加しなければならず、 Samba はドメイン・メンバーのマシン信頼アカウントを付与できなければなりません。 これなしにはユーザーに実行可能なオプションを提供できません。

この章ではドメイン・メンバーシップ、 Samba の設定及び MS Windows クライアントのドメイン参加方法について触れます。 なぜこれらが必要なのでしょうか? それは今日の MS Windows ネットワークと、 特に UNIX/Linux ネットワーク及び管理の世界に、 かなりの誤情報や誤解があり、 また知識不足が顕著であるためです。 この章によってその隙間が埋められることを望んでいます。

特長と便益

MS Windows ワークステーション及びサーバーがドメイン・セキュリティに参加するためには、 ドメイン・メンバーになる必要があります。 ドメイン・セキュリティに参加することを Single Sign On または略して SSO と呼びます。 この章ではワークステーション (または MS Windows NT4 / 200x サーバーであるもう一台のサーバー) または Samba サーバーを MS Windows ドメイン・セキュリティのメンバーにするための手順を説明します。

Samba-3 はネイティブ・メンバー・サーバーとして MS Windows NT4 式ドメインに参加したり、 ネイティブ・メンバー・サーバーとして MS Windows Active Directory ドメインに参加したり、 Samba ドメイン管理ネットワークに参加することができます。 ドメイン・メンバーシップには次のような多くの利点があります。

  • MS Windowsワークステーションのユーザーが SSO の利点を享受できます。

  • ドメイン・ユーザーのアクセス権限やファイル所有権及びアクセス制御は単一のドメイン Security Account Manager (SAM) データベース (ドメイン・メンバー・サーバー及びドメイン・メンバーである MS Windows ワークステーションで稼動可) から設定することができます。

  • ドメイン・メンバーである MS Windows NT4/200x/XP Professional ワークステーションのみネットワーク・ログオン機能を使用することができます。

  • ドメイン・メンバーであるワークステーションを、 ポリシーファイル (NTConfig.POL) 及びデスクトップ・プロファイルを使用してより良く制御できます。

  • ログオン・スクリプトを使用することにより、 ユーザーはアプリケーション・サーバー上のネットワーク・アプリケーションに自由にアクセスできます。

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

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

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

マシン信頼アカウントのパスワードは、 ドメイン・コントローラーとの安全なコミュニケーションのための共有シークレットです。 これは同一の NetBIOS 名を持つ未認証マシンがドメインに参加し、 ドメイン・ユーザー/グループ・アカウントへのアクセス権限を得ることを防ぐためのセキュリティ機能です。 Windows NT/200x/XP Professional クライアントは、 マシン信頼アカウントを使用しますが、 Windows 9x/Me/XP Homeクライアントは使用しません。 したがって、Windows 9x/Me/XP Home クライアントは、 マシン信頼アカウントを持たないために、 ドメインの真のメンバーになることはなく、 ドメイン・コントローラーとの間に共有シークレットを持ちません。

Windows NT4 PDC は Windows レジストリ内に各マシン信頼アカウントを格納します。 MS Windows 2000 の登場と共に Active Directory というマシン信頼アカウントの新しいレポジトリが登場しました。 それに対し Samba PDC では、 マシン信頼アカウントを次の二つの部分に分けて格納します:

  • ドメイン・セキュリティ・アカウントは 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 ウェブサイトで入手可能な Nexus ツールキットから得られる、 MS Windows NT4 サーバー・マネージャーを使用する方法。 上記ツールはユーザーが管理者アカウントとしてログオンしている限り、 どの MS Windows マシンからでも実行できます。

  • オン・ザ・フライ”での作成。 Samba マシン信頼アカウントはクライアントがドメインに参加すると同時に Samba によって自動的に作成されます (セキュリティ上この方法が推奨されています)。 対応する UNIX アカウントは自動もしくは手動で作成できます。

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

マシン信頼アカウントの手動作成の第1ステップは、 /etc/passwd 内に、 対応する UNIX アカウントを手動で作成することです。 この作業には vipw 又は、 通常、新規の UNIX ユーザーを作成する際に使う “add user” コマンドを使用します。 下に Linux ベースの Samba サーバーの例を紹介します:

root# /usr/sbin/useradd -g machines -d /dev/null -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 のエントリーは、 マシン名の後ろに “$” を付けたもので、 パスワードは持たず、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 ドメイン・サーバー・マネジャーを使用する場合でも必要です。

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

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

これらのツールに関する詳細情報は次の場所で得ることができます:

http://support.microsoft.com/default.aspx?scid=kb;en-us;173673
http://support.microsoft.com/default.aspx?scid=kb;en-us;172540

srvmgr.exe (ドメイン用のサーバー・マネジャー) を起動し、次のステップを実行します:

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

訳注: 原文が Server Manager Account Machine Account Management となっています。 一回目の Account が Domain の間違いではないかと推量しています。

  1. メニュー画面で Computer を選択します。

  2. Select Domain をクリックします。

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

  4. 再びメニュー画面から Computer を選択します。

  5. Add to Domain を選択します。

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

マシン信頼アカウントのオン・ザ・フライでの作成

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

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

ここで Red Hat Linux システムの例を紹介します。

[global]
# <...remainder of parameters...>
add machine script = /usr/sbin/useradd -d /dev/null -g 100 \
-s /bin/false -M %u

MS Windows ワークステーションまたはサーバーをドメイン・メンバーにする

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

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

ユーザーがクライアントをドメイン・メンバーにする時、 Windows 200x は、 ドメイン内でマシン・アカウントを作成する権限を持つアカウント及びパスワードの入力をプロンプトします。 Samba 管理者アカウント (Samba サーバー上で root 権限を持つ Samba アカウント) をここで入力しなければなりません。 通常のユーザー・アカウントが入力されると、この作業は失敗します。

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

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

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

Windows NT4 クライアント

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

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

Samba クライアント

Samba クライアントのドメイン参加手順は ドメイン・メンバー・サーバー の項に記述されています。

ドメイン・メンバー・サーバー

このモードのサーバー・オペレーションは、 Samba マシンをドメイン・セキュリティのメンバーにすることを含みます。 またこれは定義上、 全てのユーザー認証は中央で定義された認証機構で行われることを意味します。 この認証機構は NT3/4 式 (旧式のドメイン・テクノロジー) サーバーもしくは MS Windows 2000 以降に実装されている Active Directory server (ADS) が提供します。

当然、認証バックエンド自体は Samba がサポートしている分散ディレクトリ構造のサーバーなら、 いずれでも構いません。 LDAP (OpenLDAP以降) 、Sunの iPlanet、NetWare ディレクトリ・サーバーなどがあり得ます。

Note

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

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

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

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

Table 7.1. 前提

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

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

of your smb.conf to read: smb.conf ファイルの [global] セクションの security 行を次のように変更 (又は追加) して下さい。

security = domain

次に [global] セクションの workgroup 行を下のように変更します

workgroup = MIDEARTH

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

encrypt passwords パラメータを Yes に設定し、 ユーザーが NT PDC に認証されるようにします。 もしこのパラメーターが特に指定されていなければ、 デフォルトで設定されています。 このパラメーターは特に指定する必要はありませんが、 smb.conf で指定する場合は Yes に設定しなければなりません。

最後に [global] セクションの password server 行を下のように変更 (または追加) します。

password server = DOMPDC DOMBDC1 DOMBDC2

これらは Samba がユーザー認証のために連絡を取るプライマリ及びバックアップのドメイン・コントローラーです。 Samba は各サーバーにリスト順に連絡しますので、 複数のドメイン・コントローラーの間で認証負荷を分散するためには、このリストの順番を適宜変えてください。

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

password server = *

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

ドメインに参加するために次のコマンドを実行して下さい:

root# net join -S DOMPDC -UAdministrator%password

ドメイン名は smb.conf ファイルから取得します。

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

Joined domain DOM.

Where Active Directory is used: Active Directory使用の場合:

Joined SERV1 to realm MYREALM.

詳細情報に関しては net のmanページを参照下さい。

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

このコマンドは、マシン・アカウント・パスワード変更プロトコルを通して、 Samba サーバーの新規 (任意の) マシン・アカウント・パスワードを、 smbpasswd ファイルが通常格納されているディレクトリと同じディレクトリにあるファイルに書き込みます:

/usr/local/samba/private/secrets.tdb
または
/etc/samba/secrets.tdb.

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

最後に Samba のデーモンを再起動し、 クライアントがドメイン・セキュリティの使用を開始する準備をします。 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 グループなどのユーザー ID 情報を、 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 の設定

You must use at least the following three options in smb.conf: 最低、次の 3つのオプションを smb.conf で使用しなければなりません。

realm = your.kerberos.REALM
security = ADS
# The following parameter need only be specified if present.
# The default setting is not present is Yes.
encrypt passwords = yes

password server option in smb.conf: Samba がレルム名を使用して適切な ADS サーバーを正確に特定できない場合、 smb.confpassword server オプションを使用します:

password server = your.kerberos.server

Note

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

/etc/krb5.conf の設定

MIT 及び Heimdal Kerberos ではこれは必要なく、 時に害となることがあります。 全ての ADS ドメインは、DNS の _kerberos.REALM.NAME に、 レルム内の各 KDC の SRV レコードを、自動的に作成します。 MIT と Heimdal では、KRB5 ライブラリがこれらのレコードをチェックするようにデフォルト設定されており、従って、自動的に 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 too great while getting initial credentials” (kinit(v5): 最初の認証情報取得時にクロックスキューが過大) が表示されます。

Kerberos プロトコルではクロックスキューの限界値を設定できます。 デフォルト設定は 5分です。

更に、使用する KDC の IP アドレスによるリバース DNS ルックアップをできるようにしなければなりません。 また、このリバース・ルックアップがマッピングする先の名前は KDC の NetBIOS 名 (ドメインに紐づかないホスト名) またはレルムが後に付く NetBIOS 名でも構いません。

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

smbclient での Kerberos のサポートのみが必要な場合は、 次の項は飛ばして直接 「smbclientによるテスト」 smbclient によるテスト の項に行って下さい。 コンピュータ・アカウントの作成 及び サーバー設定のテスト のステップは、 smbdwinbindd で Kerberos サポートが必要な場合にのみ必要です。

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

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

root#  net ads join -U Administrator%password

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

root#  kinit Administrator@your.kerberos.REALM
root#  net ads join “organizational_unit

例えば、ある組織ディレクトリ “Computers\BusinessUnit\Department” の下の “Servers” というコンテナにマシン・アカウントを作成したい場合は次のようになります:

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

起こりうるエラー

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

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

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

を使用してドメインにログインする必要があります。 USERNAME はマシンをドメインへ追加する権限を持つユーザーでなければなりません。

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

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

サーバー設定のテスト

参加に成功したら Active Directory に Samba サーバーの NetBIOS 名の付いた新規のコンピュータ・アカウントがあるはずです (Users and Computersの下にある “Computers” フォルダ内)。

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

Note

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

smbclient によるテスト

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

Notes

DC インストール後は、正しい暗号タイプを作成するために、 少なくとも一度は管理者パスワードを変更しなれけばなりません。

Windows 200x はデフォルトの DNS 設定では _kerberos._udp_ldap._tcp を作成しないようですが、 おそらく今後サービスパックで修正されるでしょう。

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

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

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

LDAPldap idmap suffix を使用する場合、以下の設定をします:

ldap idmap suffix = ou=Idmap,dc=quenya,dc=org

詳細情報については smb.conf の manページで ldap idmap suffix パラメーターのエントリーを参照下さい。

また、 ldap admin dn を指定することと、LDAP 管理パスワードを secrets.tdb 内に設定することを忘れないでください。 これには下記を使用します:

root#  smbpasswd -w ldap-admin-password

よくあるエラー

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

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

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

前の名前がまだ NetBIOS 名キャッシュに残っているためです。 マシン・アカウントが削除されると、 同じ名前のマシンをドメイン・メンバーとして再度追加できるようになるには、 まず、その名前が期限切れにならなければなりません。 最もよいのは古いアカウントを削除し、新しい名前でマシンを追加することです。

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

Windows 200x もしくは XP Professional マシンを Samba PDC ドメインに追加しようとすると失敗します。 エラーメッセージは 今回はネットワークの問題によりマシンを追加できませんでした。 後ほどやり直して下さい。 ですが、なぜですか?

smb.conf ファイル内に add machine script があることを確認して下さい。 もしなければ OS プラットフォームに適したスクリプトを追加して下さい。 もしスクリプトが定義されている場合は、そのオペレーションをデバッグする必要があります。 smb.conf ファイルの add machine script を 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 client use spnego = yes に設定して下さい。