マシン信頼アカウントの手動作成の最初の手順は、/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から生成される。

有効な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(ドメイン用のサーバーマネージャ)を起動し、以下の手順を実行する:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この方法で、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

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

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

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

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
	dns_lookup_kdc = true

[domain_realms]
	.kerberos.server = YOUR.KERBEROS.REALM

KDCを直接指定したい場合、最小の設定は以下の通り:

[libdefaults]
	default_realm      = YOUR.KERBEROS.REALM

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

[domain_realms]
        .kerberos.server = YOUR.KERBEROS.REALM

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

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

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 では次の構文でこれを実現できる:

root#  kinit Administrator@your.kerberos.REALM
root#  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重にする必要がある。

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

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

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

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

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

C:\>  nbtstat -R

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

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

可能性のある原因:

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