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

現在、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 サーバーが受け取ることを意味する。

最低以下の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

[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

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

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

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.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オプションを指定する。

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

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

“ 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システムアカウントを作成するためにのみあるものである。

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