Table of Contents
ドメインメンバシップはきわめて重要な事項である。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ドメイン管理ネットワークに参加できる。ドメインメンバシップはたくさんの利点を持つ:
ドメインユーザアカウントの(アクセス)権限とファイルの所有権およびアクセス制御は 単一のドメインセキュリティアカウントマネージャ(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基盤経由で)以外の任意のネットワーク クライアントかサーバ上でユーザアカウントを保守する必要がないからである。
マシン信頼アカウントは(ユーザではなく)クライアントマシンをドメインコントローラサーバに対して認証するために使われる。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 の初期リリースまでは実装されない予定 である(訳注:この部分は古い)。
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/falsemachine_name
$root#
passwd -l
machine_name
$
上記の例では、全マシンアカウントのプライマリグループとして使われる“machines”という、既存のシステムグループがある。以下の例では、“machines”グループのGIDは100である。
*BSDシステム上では、この作業はchpass
ユーティリティを使うこともできる:
root#
chpass -a \'
machine_name
$:*:101:100::0:0:Windowsmachine_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プラットフォーム用のものが解凍される。
マシン信頼アカウント作成の第3の(そして推奨する)方法は、クライアントがドメインに参加する時、必要に応じて Samba サーバーアカウントを作成する方法である。
Samba の各マシン信頼アカウントは対応するUNIXアカウントを必要とするので、通常、 UNIXアカウントを自動作成する機能が提供されている。これには smb.conf
ファイル内に add machine script オプションを設定する必要がある。しかし、この方法は必須ではなく、対応するUNIXアカウントを手動で作成しても構わない。
[global] |
add machine script = /usr/sbin/useradd -d /var/lib/nobody -g 100 -s /bin/false -M %u |
Microsoft Windows ワークステーションやサーバをドメインのメンバにする手順は Windowsのバージョンによって異なる。
ユーザーがクライアントをドメインメンバにする時、 Windows 200x は、ドメイン内で マシンアカウントを作成する権限を持つアカウント及びパスワードの入力を要求する。 Samba管理者アカウント(すなわち、Sambaサーバ上でroot
権限を 持つSambaアカウント)をここで入力せねばならない。通常のユーザアカウントが入力さ れると、この作業は失敗する(訳注:net rpc rightsでSeMachineAccountPrivilege権限を 持ったユーザも出来るのでは?)
セキュリティのため、この管理者アカウントのパスワードは/etc/passwd
でルートユーザ用に使用されているパスワード以外のものを設定するべきである。
ドメインメンバのマシンアカウントを作成するために使用するアカウント名は ネットワーク管理者が任意に選択する。もしそれがroot
以外なら smb.conf
中のパラメータ username map = /etc/samba/smbusers で指定するファイル名中で容易にマッピングできる。
Samba管理者アカウントのセッションキーは、マシン信頼アカウントのパスワード 設定の際、暗号化キーの機能を果たす。マシン信頼アカウントはその場でで作成 されるか、または、既に存在していれば更新される。
マシン信頼アカウントが手動作成された場合、Identification Changes メニュー画面でドメイン名を入力するが、 Create a Computer Account in the Domain チェックボックスにはチェックを入れない。こうすることでマシン がドメインに参加する際に既存のマシン信頼アカウントが使用される。
もしマシン信頼アカウントがその場で作成される場合は、Identification Changes メニュー画面でドメイン名を入力し、 Create a Computer Account in the Domain チェックボックスにチェックを入れる。この場合、上記 Windows2000用 の手順に従いドメインに参加する(プロンプトに対してSamba管理者 アカウント名を入力する)。
Joining a Sambaクライアントをドメインに参加させる方法は 次の章に記述されている。
このモードのサーバ操作は、Sambaマシンをドメインセキュリティコンテキストのメンバーにすることを含む。またこれは定義上、全てのユーザ認証は中央で定義された認証機構(訳注:authentication regime)で行われることを意味する。この認証機構は NT3/4形式(旧式のドメインテクノロジー)サーバ又はMicrosoft Windows 2000以降で実装されているActive Directory server(ADS)が提供する。
もちろん、認証バックエンド自体はSambaがサポートしている分散ディレクトリ構造のサーバなら、いずれでも構わない。LDAP(OpenLDAPベース) 、SunのiPlanet、Novellの e-Directoryなどが使用可能である。
SambaがLDAPやその他のアイデンティティ管理、あるいは、ディレクトリサービスを使用するように設定される場合、ユーザ及びマシン認証を継続して実行するのはSambaである。Sambaが行う認証をLDAPサーバが代替するわけではないことに注意。
ドメインメンバサーバーのドメインマシンアカウント作成に関する詳細情報やSambaドメインメンバマシンがドメインに参加し完全に信頼されるようにする方法に関しては、ドメイン管理の章を参照のこと。
下記の表に、この後この章で使用される名前を示す。
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 -U
Administrator%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 サーバーが受け取ることを意味する。
この文書の内容の大半は、ウェブマガジンLinuxWorldの記事http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.htmlDoing the NIS/NT Sambaとして最初に発表された(訳注:リンク切れ)。
これは、Windows 200x KDC に対し Kerberos認証を行うSamba-3の設定方法の概略である。Kerberosの知識を有することを前提としている。
最低以下の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ドメインコントローラを指定することは問題ない。
smbpasswdファイルは必要でなく、古いクライアントはあたかもsecurity = domainのように認証され、何の害もなく、ドメインに入らないローカルユーザーを持つことができる。
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
を実行して設定をテストし、パスワードが Windows 2000 KDC に認証されることを確認する。USERNAME
@REALM
Heimdal 0.6.x 以前のバージョンでは、ADSで新規に作成されたアカウントであるか、移行後にパスワードが変更されたアカウントであるか、インストール後にAdministrator
であれば使用できる。現行、Windows 2003 KDCはHeimdal のバージョン 0.6 以降のリリース(かつkrb5.conf内にetypesの既定値の設定がないもの)とのみ使用できる。残念ながらこの領域はいまだに流動的な状態である。
レルムは大文字でなければ、“Cannot find KDC for requested realm while getting initial credentials(最初の認証情報取得時にリクエストされたレルムの KDC を見つけられない)”というエラーが表示される(Kerberos は大文字・小文字を区別する)。
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.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重にする必要がある。
Kerberosライブラリとヘッダファイルのインストール後に、Samba を再設定(config.cache を削除) して、リコンパイルする(make clean all install)。
kinit
を使ってドメインにログインする必要がある。 USERNAME
@REALM
USERNAME
はマシンをドメインへ追加する権限を持つユーザーでなければならない。
/etc/krb5.conf
システムにインストールされているKerberosの タイプとバージョンに対して適切に設定されているか確認する。
参加に成功したら、Active DirectoryにSambaサーバのNetBIOS名の付いた新規のコンピュータアカウントが表示される(ユーザとコンピュータ配下の“コンピュータ”フォルダ中)。
Windows 2000 クライアントでは、net use * \\server\share
を試してみること。パスワードを知らないでもKerberos にログインできるはずである。もしも失敗したら、klist tickets
を実行すること。サーバー用のチケットを取得できたか?それには暗号タイプ DES-CBC-MD5 があるか?
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まで増やし、ドメインへの参加を試行してみる。そのログをチェックし、どの動作が失敗しているか突き止める。
可能性のある原因:
add machine scriptはSamba バックエンドデータベースでは、マシンアカウントを作成しない。Sambaバックエンドデータベースアカウントがマッピングされる先のUNIXシステムアカウントを作成するためにのみあるものである。
Windows 2003はSMB署名を必要とする。クライアント側のSMB署名はSamba-3.0で 実現されている。Windows 2003サーバと通信する際には client use spnego = yesに設定する。 この機能は、クライアントは単純にそれ自身とサーバと両方がサポートする プロトコルをネゴシエートするので、Windows 2003が持つより高度なセキュリティ 機能をサポートしない他のWindowsクライアントとインタフェースを取れない。 これは、SMB/CIFSプロトコル中で構築されているよく知られたフォールバック 機能である。