| 方 式 | 設定の手間 | 連携の機能 | 認証先 |
|---|---|---|---|
| security = SERVER | 簡 単 | 少ない | 任意の認証サーバ |
| security = DOMAIN | やや複雑 | 少ない※ | Windowsドメイン |
| Winbind | 複 雑 | やや多い | Windowsドメイン |
認証を連携する方法を大きく分けると、従来のSamba 2.0系列から存在する「security = SERVER｜DOMAIN」による連携と、Samba 2.2系列になって導入されたWinbindによる、よりシームレスな連携とに分けられます。簡単な比較を表１にまとめましたので、御覧になってください。
認証だけを手軽に連携したいという場合は、security = SERVERが、大量のアカウントが存在している時の連携を容易に行いたいという場合は、Winbindというように、各方式には一長一短がありますので、現在のところは用途に応じて使い分けるのが現実的だと思います。それでは以下各方式について説明していきましょう。
これは一番簡単な連携方法で、Sambaにアクセスする際のパスワードの認証を認証サーバで行う設定になります。
認証サーバとしては、Windows NT系OS(注02)や別のSambaサーバなどを指定します。認証サーバとして、必ずしもドメインコントローラを指定する必要がないことに注意してください。また、認証サーバ側の設定を一切必要としないのもこの方式の特徴です。なお、認証サーバで認証されなかった場合は、「security = USER」の場合と同様のローカルのsmbpasswdファイルによる認証が行われます。
最低限必要な設定は図１の通りです。
「security = SERVER」と指定を行った上で、password serverパラメータで認証サーバを指定します。認証サーバは複数指定することも可能で、その場合は先頭に記述されたサーバから順番に認証の試行を行い、最初に成功した時点で認証されます。
[global]
security = SERVER
password server = <認証サーバ名>
「security = SERVER」では、たとえば図２のようにSambaマシンで認証を一元管理したいという場合や、スタンドアロンなWindows 2000 Serverを認証サーバとして利用するといった利用方法も可能です(注03)。
職場でWindowsドメインが導入されているのでWindowsドメインのアカウントで認証を行いたいが、Windowsドメインの管理者にSambaのためにコンピュータの登録を行ってもらいにくいという場合も多いと思います。こうした場合にも「security = SERVER」は重宝します。図４のように設定することで、ネットワークコンピュータでも「ドメイン」の中に表示され、認証もPDCやBDCで行われます。
「security = DOMAIN」の方で説明するadd user scriptパラメータを利用することも可能ですので、事実上ドメインのメンバーと同様に機能させることが可能となります。
[global]
workgroup = <ドメイン名>
security = SERVER
password server = <PDC> <BDC1> ...
この方式はSamba 2.0系列から実装された機能で、Windows NTと同様の機構でWindowsドメインに参加します(注04)。
この設定を行うには、少し準備が必要です。
ここでは「HOMEPDC」というコンピュータ名のPDC(Active Directoryの場合はPDCエミュレータ)と「HOMEBDC」というコンピュータ名のBDCがあるHOMEというWindowsドメインに「MANA」というコンピュータ名のSambaサーバを参加させる場合を例にとって説明します。
コンピュータアカウント(注05)を作成する方法については大きく
o サーバ側でコンピュータアカウントを作成した上で、クライアントからドメインに参加する
o クライアント側からコンピュータアカウントの作成とドメイン参加を同時に行う
の２通りあります。
最近のSambaはどちらの方式にも対応していますが、ここでは両方を簡単に説明しましょう。
「Active Directoryユーザとコンピュータ(Windows 2000の場合)図５」や「サーバマネージャ(Windows NT/2000)図６」などを使ってWindowsドメインにコンピュータアカウントを追加します。
「Active Directoryユーザとコンピュータ」を使ってSambaマシン用のアカウントを追加する時には、「Windows 2000以前のコンピュータに、このアカウントの使用を許可」というチェックボックスにチェックを入れておくことを忘れないようにしてください。
ここまではWindows NTマシンをドメインに追加するときと同様です。
なお、Samba日本語版では、機種依存文字も含めた日本語のコンピュータ名のSambaマシンをNTドメインに参加させることが可能なことも確認していますが、Active Directoryでは未検証です。いずれにしても無用のトラブルを避ける意味でコンピュータ名は英数字のみにすることを強くお勧めします。
コンピュータアカウントを作成したらいよいよ参加ですが、その前にSambaマシンから参加したいドメインのPDC(PDCエミュレータ)の名前解決ができることを確認しておいてください。
なお、NTドメインに参加させる場合は、コンピュータ名の名前解決が必要な点に注意してください。
今回の例でいうとHOMEPDCという名前が解決できる必要があります。例えばHOMEPDC.localというようなDNSのFQDN名が解決できてもダメです。
/etc/hostsにPDCのIPアドレスとコンピュータ名を記述しておけば安全ですので、良くわからない方は、必ず図７のように/etc/hostsファイルにエントリを追加しておいてください。
x.x.x.x HOMEPDC ← x.x.x.x はIPアドレス
Samba 2.2.2以降ではドメインに参加させる前にあらかじめsmb.confで
[global]
security = DOMAIN
encrypt passwords = Yes
の設定を行なう必要があります(注05)。最近のSambaではsmb.confをチェックして上記の設定になっていないと
ERROR: Must have both SECURITY = DOMAIN and ENCRYPT PASSWORDS = YES!
と表示されるようになりましたが、それ以前のSambaでは単にエラーになるだけですので注意してください。
それでは参加です。Sambaを停止させてから図８のように入力してください。
mana# smbpasswd -j HOME -r HOMEPDC
この結果
Joined domain HOME.
のように表示されれば成功です。
同時に行なう場合は、サーバ側での作業は発生しませんが、それ以外はほとんど同じです。
PDCの名前解決ができていることを確認したら、図９のようにドメインへ参加させる権利のあるアカウントを -U オプションで指定してsmbpasswdコマンドを実行し、適切なパスワードを入力します。
なお、ここでは「Administrator」を指定していますが、参加するのがActive Directoryの場合、デフォルトではAuthenticated Usersグローバルセキュリティグループにコンピュータをドメインに追加させる権利が付与されていますので、事実上どのアカウントを使っても構いません。
ただし、一般ユーザのアカウントで参加させる場合は、別のユーザで作成したコンピュータアカウントの上書き(再設定)はアクセス権の問題でできないので注意してください(注06)。
mana# smbpasswd -U administrator -j HOME -r HOMEPDC
Password: ← パスワード
Joined domain HOME
コンピュータアカウントの追加が完了したら、smb.confの[global]セクションに図10のような設定を追加します。
[global]
workgroup = HOME
security = DOMAIN
encrypt passwords = yes
password server = HOMEPDC HOMEBDC
なお、Samba 2.0.6以降ではpassword serverに
password server = *
と記述することも可能です。この場合Windows NT系OSと同様にWINSやブロードキャストを使ってドメインコントローラを検索します。
ここまで設定したところでSambaを起動してください。これでSambaがドメインのメンバーサーバとして機能します。
それでは早速動作を確認してみましょう。
Windowsドメイン側にsmbtestというアカウントを追加して、パスワードを適宜設定してください。次にuseraddコマンド等を使って、Sambaサーバ上にsmbtestというアカウント
を作成します。パスワードを設定する必要はありません。
ここで、Windowsドメインに属するWindowsマシンにsmbtestアカウントでログオンしてSambaサーバにアクセスしてみましょう。正しく設定されていれば、Windowsドメインのメンバサーバにアクセスするときと同様に、パスワードを聞かれることなくアクセスできる筈です。
もちろん実際は内部で認証が行われていて、Sambaサーバ上ではサーバに作成したsmbtestというアカウントの権限で各種リソースにアクセスしています。なお、認証を要求したアカウントがWindowsドメインに存在しないときは、Windows NT系OSのマシンがローカルアカウントで認証するように、Sambaサーバのローカルなsmbpasswdファイルにあるアカウントで認証が行われます。
「security = SERVER｜DOMAIN」により、Windowsドメインとの認証の統合は実現できますが、このままではWindowsドメインにアカウントを追加/削除する度にSambaサーバ上のアカウントの追加/削除を行わなければいけません。このままでは管理者にとってはかなりの負担です。
でもadd user scriptとdelete user scriptというパラメータを活用することで、ユーザの自動作成/削除を行なうことができます。以下確認していきましょう。
ただし、「security = SERVER」の場合、delete user scriptは利用できませんので、ユーザの自動削除は残念ながらできません。
まずは、図11と図12のようなスクリプトを作成してください。ここでは各々smb-useraddとsmb-userdelという名前を付けることにしましょう。/usr/local/bin等の適当な場所に保存して、実行権限をつけておいてください。
#!/bin/sh
useradd -s /bin/false -d /var/samba/home/$1 $1
mkdir -p /var/samba/home/$1
chown $1 /var/samba/home/$1
#!/bin/sh
userdel -r $1
rm -rf /var/samba/home/$1
念のため、
# /usr/local/bin/smb-useradd testuser
と入力すると、testuserというユーザが作成され、
# /usr/local/bin/smb-userdel testuser
と入力するとtestuserというユーザが削除されることを確認しておきましょう。
なお、上記で示したスクリプトは一例です。smb-useraddは引数に指定した名前のユーザをUNIX上に作成し、smb-userdelは引数に指定したユーザをUNIX上から削除する必要がありますが、後は自由に作成してください。
次にsmb.confを修正します。図13のようにadd user scriptとdelete user scriptというパラメータを[global]セクションに設定してください。
[global]
add user script = /usr/local/bin/smb-useradd %u
delete user script = /usr/local/bin/smb-userdel %u
これで準備は完了です。念のためSambaサーバのプロセスを再起動しておいて下さい。
それでは動作の方を確認してみましょう。
まず、Windowsドメイン上に新しいアカウントを作成しましょう。このアカウントと同じ名前アカウントがSambaサーバ上になければ何でもよいのですが、ここでは説明のためsmbtest1という名称にしておきます。
続いてWindowsドメインにsmbtest1でログオンします。ここで、今設定したSambaサーバにアクセスしてみてください。
何事もなかったかのようにアクセスが行われ、図14のようにホームディレクトリが表示されたはずです。Sambaサーバ上で確認すると、smb-useraddスクリプトが動作して、smbtest1というユーザアカウントおよびそのホームディレクトリが作成されたことが確認できると思います。
次に、Windowsドメイン上でsmbtest2アカウントを削除しましょう。
ここで図15のようにnet useコマンド等を使って削除したsmbtest2アカウントでSambaサーバに接続を試みます。当然接続は失敗しますが、その延長でsmb-userdelスクリプトが実行されアカウントおよびホームディレクトリが削除されることと思います。
ただし、ユーザを削除した情報がドメイン全体に行き渡るまでには少し時間がかかります。Sambaが認証先にしているドメインコントローラ上にユーザ削除の情報が反映されないと当然上記の動作は行なわれません。
このように、add user scriptとdelete user scriptを用いることで実質的にSambaサーバでのアカウントの管理を不要にすることができます。SambaサーバをWindowsドメインのファイル／プリンタサーバとして利用するという形態をとる場合、このパラメータは、非常に力を発揮すると思います。
C:\>net use \\mana\public /user:smbtest2
\\mana\public のパスワードまたはユーザー名が無効です。
'smbtest2' のパスワードを入力してください。'mana' に接続します:
システム エラー 1326 が発生しました。
ログオン失敗: ユーザー名を認識できないか、またはパスワードが間違っています。
ここまで説明を読んできた方は、「security = SERVER」と「security = DOMAIN」との違いが良くわからないと感じられた方も多いと思います。一言でいうと、これはWindows 9x系OS的にドメインに参加(注07)するか、Windows NT系OS的にドメインに参加するかといった違いともいえますが、いずれにしても見掛け上の違いはほとんどないと思います。
実際「delete user script」パラメータの使用可否とこの後で説明する信頼関係の活用を除けば、現時点では両者の機能的な違いは表面的にはないといってもよいでしょう。
このため、敢えて「security = DOMAIN」にこだわる必要はないかも知れません。「security = DOMAIN」の方がトラヒックが削減される他、ドメインコントローラから受け取る情報の量も多いため、元々はそれらをSamba側で活用することで「security = SERVER」との機能差をつける予定だったようですが、結果としてはほぼ同機能に留まってしまっています。
Samba 2.2.2でSamba本体に統合されたものの最初は不安定な上Linux上でしか動作しないなど制限の多かったWinbindですが、Sambaのバージョンアップに伴い、ようやく実用レベルになってきました。ここではこのWinbindについて機能や設定方法について紹介します。
Winbindとは、図16のように、Windowsドメインと連携して動作し、Windowsドメインの認証情報をSambaやPAM経由で動作するその他のプログラムで利用可能にするための仕組みです。この機能を実現するために、従来のsmbdやnmbdに加えてwinbinddというデーモンが新たに起動されます。
従来からの「security = SERVER｜DOMAIN」と画期的に異なるのは、NISなどと同様、Sambaサーバ上に個別のアカウントを作成する必要がないということでしょう。Winbindの実体であるwinbinddが、参照先Windowsドメインの各アカウントに対してUIDその他必要な情報を必要に応じて生成してUNIX側に通知してくれます。
また、PAMに対応しているため、telnetやftpといった他のプログラムもWinbindが提供する認証機能を用いることができるようになります。
このように便利なWinbindですが、幾つか懸案事項もあります。
まず、Winbind機能はPAMやlib_nss(ネームサービススイッチ機能)を利用しますので、利用可能なプラットフォームがLinuxなど一部のプラットフォーム(注08)に限られてしまう点が挙げられます。
機能上の懸案事項としては、UIDの生成が動的なため、Windowsドメインのあるアカウントに対するUID(やGID)は、Sambaマシンによって異なってしまうという点です。そのため、Sambaマシン間でNFSなどを利用している場合は、この点がネックになってWinbindが導入できないケースも考えられます(注09)。
また、長期間運用しているとメモリリークとみられる事象が発生するなど、安定性にやや欠ける点があるのも事実です。現状では可能な限り定期的にwinbinddの再起動を行なうような運用が必要です。
しかし、それらの懸案事項を補ってあまりあるメリットがあるのも事実です。以下インストールと設定方法について説明していきましょう。
以下インストールについて簡単に説明していきます。
最近のRed Hat Linuxを始めとするLinuxの各ディストリビューションでは、何らかの形でWinbindもパッケージ化されていることがほとんどですので、インストールは簡単です。インストールされていない場合、
# rpm -ivh samba samba-common
# apt-get install winbind
のようにしてそれぞれパッケージをインストールすればよいでしょう。
Winbindはまだまだ不安定な点もあるため、できる限り最新のものを使いたいという場合も多いと思います。またパッケージが提供されていないOSで使いたい場合は必然的にソースからのインストールが必要となります。
Winbind機能を有効にするかどうかはconfigureオプションとなっていますが、configure --helpで
--with-winbind Build winbind (default, if supported by OS)
となっているように、OSがサポートしていれば自動的にWinbind機能が有効な形でコンパイルされます。このため、通常は特にconfigureオプションを指定する必要はないでしょう。逆にconfigureオプションを強制的に指定しないとコンパイルできないような環境では、正常に動作しない可能性が高いと思います。
makeやmake installは通常通り行なえばよいのですが、そのままではpam_winbind.soがコンパイルされませんので、sourceディレクトリ以下で
% make nsswitch/pam_winbind.so
と入力して、明示的にpam_winbind.soをコンパイルする必要があります。
最終的に
nsswitch/libnss_winbind.so を /lib に
nsswitch/pam_winbind.so を /lib/security に
各々適切な位置にコピーします(注10)。
Winbindを設定するためには幾つか前準備が必要です。以下順番にみていきましょう。
まずは前述した説明にしたがって、Windowsドメインのメンバサーバとして
o smb.confの修正
o コンピュータアカウントの作成とドメインへの参加
の設定を行なっておきます。
次にWinbind特有のパラメータを設定します。Winbindに関係するパラメータを表２に示しました。
| パラメータ名 | 重要度 | 説 明 | デフォルト | 設定方針 |
|---|---|---|---|---|
| winbind gid | ● | winbinddが割り当てるGIDの範囲を指定します | <なし> | NISなど他の場所で使われないGIDの範囲を指定します。このパラメータは必ず明示的に指定する必要があります。 |
| winbind uid | ● | winbinddが割り当てるUIDの範囲を指定します | <なし> | NISなど他の場所で使われないUIDの範囲を指定します。このパラメータは必ず明示的に指定する必要があります。 |
| winbind separator | ◎ | 後述するようにwinbinddは「<ドメイン名>╲<ユーザ名>」形式のユーザ名を生成しますが、この時にドメイン名とユーザ名を区切る文字を指定します | ╲ | デフォルトはWindowsに合わせて「╲」ですが、プログラムなどで問題が発生する場合は、「_」などの文字に変更するのが無難でしょう。 |
| winbind use default domain | ◎ | ドメイン名なしのユーザ名が入力された場合、自動的にデフォルトのドメイン名を補完するかどうか | No | 状況によりますが、Yesにした方が利用者の便は向上するでしょう。 |
| template homedir | ◎ | winbinddが自動生成するユーザのホームディレクトリを指定します | /home/%D/%U | winbinddが自動生成したユーザにUNIXへのログインを許可する場合は適宜設定してください。Samba経由でのみアクセスさせる場合は、特に設定する必要はありません。なおホームディレクトリ自体が自動作成されるわけではありません。別途作成する必要があります。 |
| template shell | ○ | winbinddが自動生成するユーザのシェルを指定します | /bin/false | winbinddが自動生成したユーザにUNIXへのログインを許可する場合は適宜設定してください。Samba経由でのみアクセスさせる場合は、特に設定する必要はありません。 |
| winbind cache time | ○ | winbinddがユーザやグループの情報をキャッシュする秒数 | 15 | 必要に応じて設定してください。基本的に、変更する必要はないでしょう。 |
| winbind enum groups | ○ | グループの一覧を許可するかどうか | Yes | 基本的に設定を変更してはいけません |
| winbind enum users | ○ | ユーザの一覧を許可するかどうか | Yes | 基本的に設定を変更してはいけません |
以下とりあえずWinbindの設定を行なってみます。作成したsmb.confを図17に示します。
[global]
workgroup = DOMAIN
security = domain
password server = *
winbind uid = 10000-12000
winbind gid = 10000-12000
add user script = /usr/local/samba/mkhomedir '%u'
===== これ以下は設定しなくても良い =====
; winbind use default domain = yes
; winbind separator = +
; template shell = /bin/bash
; template homedir = /home/%U
#!/bin/bash
mkdir -p /home/$(echo "$1" | sed 's/╲╲/╲//')
chown "$1" /home/$(echo "$1" | sed 's/╲╲/╲//')
add user scriptパラメータも必須ではありませんが、このパラメータを設定しない場合ユーザのホームディレクトリは自動作成されません。従って[homes]共有を設定している場合は、このパラメータによりユーザのホームディレクトリを自動的に作成する設定にしておいた方がよいでしょう。
なお、Winbindが作成するユーザのホームディレクトリはデフォルトで/home/%D/%Uになっています。変更する場合は、template homedirパラメータを変更してください。
パスワード認証にwinbindを利用するように修正します。例えば図18のように、/etc/nsswitch.conf(注11)のpasswdとgroupにwinbindというキーワードが入っていることを確認します。
passwd: files winbind
group: files winbind
ここまでくれば、一通り設定は完了です。Sambaとwinbinddを起動した後で、確認のために、図19のようにWinbindの動作を確認した後で、Windowsドメインに存在して、Sambaマシンには存在しないアカウントでSambaマシン上の共有にアクセスしてみましょう。正しく設定されていれば、パスワードなどが聞かれずにアクセスできる筈です。また、add user scriptなどの設定が行なわれていれば、ホームディレクトリも自動的に作成されている筈です。
% wbinfo -t
Secret is good
% wbinfo -u ← ユーザの一覧を列挙する(注12)
NT4DOM2╲Administrator
NT4DOM2╲Guest
(中略)
NT4DOM2╲User2
NT4DOM2╲User3
%
念のためsmbstatus コマンドなどで接続を確認してみるとよいでしょう。
図20・図21のように、「ドメイン名╲ユーザ名」という表記が確認できる筈です。
% smbstatus
Samba version 2.2.7
Service uid gid pid machine
----------------------------------------------
IPC$ NT4DOM2╲User1 NT4DOM2╲Domain Users 3540 mayuka (192.168.79.120) Wed Jan 15 01:00:47 2003
public NT4DOM2╲User1 group1 3540 mayuka (192.168.79.120) Wed Jan 15 01:01:04 2003
No locked files
% id 'NT4DOM2\User1'
uid=10000(NT4DOM2╲User1) gid=10000(NT4DOM2╲Domain Users) groups=10000(NT4DOM2╲Domain Users)
このように、Winbindによって生成されたユーザ名は、デフォルトではWindows側のドメイン名とユーザ名が「╲」を挟んで合わさった形式になります。このため、プログラムによってはユーザ名に「╲」が含まれることにより誤動作する可能性があります。問題が発生する場合は、winbind separatorパラメータにより、区切り文字をデフォルト以外のものに変更してください。「＋」や「＿」などが無難でしょう。
Winbindに付属するpam_winbind.soを利用することで、PAMを利用する各種プログラムの認証をwinbind経由でWindowsドメインのアカウント情報を使って行なうことが可能になります。これにより、Linuxマシンの認証が完全にWindowsに統合されます。Red Hat Linux 7.3の場合(注13)、/etc/pam.d/systems-authに図22のような設定を追加します。
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok
auth sufficient /lib/security/pam_winbind.so ← 追加
auth required /lib/security/pam_deny.so
account required /lib/security/pam_unix.so
account sufficient /lib/security/pam_winbind.so ← 追加
password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow
password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel umask=0022 ← 場合によって追加
sshなどでログインした際に、ホームディレクトリを自動で作成するためには、pam_mkhomedir.so の設定も追加しておくと便利です。更に、デフォルトではwinbinddが作成したアカウントのシェルが/bin/falseになっているため、template shellパラメータで、/bin/bash などの有効なシェルを指定しておく必要があります。
ここでUNIXマシンにtelnetなどを行なってみましょう。図23のようにユーザ名を指定することで認証が行なわれ、更に自動でホームディレクトリが作成されれば成功です。
% telnet 192.168.79.1
Trying 192.168.79.1...
Connected to mana.mana-in.home.monyo.com (192.168.79.1).
Escape character is '^]'.
Red Hat Linux release 7.3 (Valhalla)
Kernel 2.4.18-4 on an i686
login: nt4dom2╲user1 ← 大文字／小文字は関係ない
Password: ← パスワードの入力
Password: ← 再度パスワードの入力
Creating directory '/home/NT4DOM2/user1'.
Creating directory '/home/NT4DOM2/user1/.kde'.
Creating directory '/home/NT4DOM2/user1/.kde/Autostart'.
Creating directory '/home/NT4DOM2/user1/Desktop'.
[NT4DOM2╲user1@mana user1] id
uid=10000(NT4DOM2╲User1) gid=10000(NT4DOM2╲Domain Users) groups=10000(NTDOM2╲Domain Users)
このようにWinbindのデフォルトでは、ユーザ名としてWindowsのドメイン名を含む長い名前を入力する必要があります。これにより、信頼関係などにより複数のドメインのアカウントが利用可能な場合に明示的に区別できるというメリットもありますが、反面繁雑になることも否めません。前述したwinbind use default domainパラメータをYesにすることで、単にユーザ名を入力した場合workgroup パラメータで指定された値がドメイン名として付加されます。
なお、この場合図24のようにwinbind use default domainで指定したドメイン名は常に表示されなくなりますので、スクリプトなどでユーザ名を処理する場合などは注意してください。
% telnet 192.168.79.1
Trying 192.168.79.1...
Connected to mana.mana-in.home.monyo.com (192.168.79.1).
Escape character is '^]'.
Red Hat Linux release 7.3 (Valhalla)
Kernel 2.4.18-4 on an i686
login: user1 ← 「nt4dom2╲user1」と入力しても同じ
Password:
Password:
Last login: Wed Jan 15 12:06:15 from mana.mana-in.home.monyo.com
[User1@mana user1]$ id
uid=10000(User1) gid=10000(Domain Users) groups=10000(Domain Users) ← ドメイン名部分が表示されない
[User1@mana user1]$
上記のようにWinbindで認証を行なう運用をする場合、UNIX上でpasswdコマンドを実行しても図25のようなエラーになってしまい変更できません。
[test5@mana test5]$ passwd
Changing password for user test5.
passwd: Authentication token manipulation error
UNIX上でパスワードを変更するには図26のようにsmbpasswdを用いてください(注14)。
% smbpasswd -r <ドメインのPDC>
Old SMB password: ← 現在のパスワード
New SMB password: ← 新しいパスワード
Retype new SMB password: ← 再度新しいパスワード
Password changed for user monyo
以上Winbindについて一通り説明しました。Sambaマシン間でUIDの同期がとれないという悩ましい問題もありますが、非常に魅力的な機能であることも理解していただけたと思います。Winbindは現在も開発が続けられており、Samba 3.0に向けてどのような機能強化が行なわれるのか、楽しみです。
現在開発中のSamba 3.0では、Windows 2000と同様にKerberos認証を使ってActive Directoryに参加することが可能になっています。ここでは具体的な参加方法や特徴について説明します。
なお、Samba 3.0自身がActive Directoryのドメインコントローラとして機能することはできません。実装されているのは、クライアントとしての参加する機能までとなっています。
ここでは、「shiori.w2k2.home.monyo.com」というFQDNをもつDCが存在する「W2K2.HOME.MONYO.COM」というActive Directoryドメインに、Red Hat Linux 8.0の「marine」というコンピュータ名のSambaマシンを参加させる場合を例にとって説明します。
まず開発中のSamba 3.0のソースを入手することが必要です。入手する方法は幾つかありますが、ここでは最新のアルファ版アーカイブである「samba-3.0alpha21.tar.gz(注15)」を利用することにします。
Active Directoryサポートを有効にするには、MIT Kerberos 5とOpenLDAPのライブラリのインストールが必要です。Red Hat Linuxの場合、Kerberosをサポートするためには、以下のパッケージがインストールされていることが必要です。
・krb5-workstation(注16)
・krb5-libs
・krb5-devel
・openldap-devel
またKerberos認証が機能するためにはサーバとクライアント間で時刻が同期している必要がありますので、ntpなどを使って時刻同期が行われるようにしておいてください。
必要なプロダクトがインストールされていれば、configureオプションなどは特に不要です。念のため、configureで作成されるsource/config.hに
#define HAVE_KRB5 1
#define HAVE_LDAP 1
という記述がある事を確認の上、makeを行ってください。なおKerberosを標準以外の場所にインストールしている場合は、--with-krb5オプションで場所を指定するとうまくいくかも知れません。
/etc/krb5.confとsmb.confに各々図27および図28のような設定を追加します。
realmとads serverの各パラメータの値は、実際に参加するドメインのものを指定してください。
[realms]
W2K2.HOME.MONYO.COM = {
↑ Active Directoryのドメイン名(Kerberos Realm名)必ず大文字で記述します
kdc = shiori.w2k2.home.monyo.com:88
↑ ドメインコントローラのFQDN名(特定できる名前であれば何でもよい)
}
[global]
realm = W2K2.HOME.MONYO.COM
ads server = shiori.w2k2.home.monyo.com
security = ADS
ここまで準備がととのったら、いよいよActive Directoryへの参加を行います。
まずはAdministratorとしてActive Direcotoryにアクセスします。図29のようにkinitコマンド(Red Hat Linuxの場合は/usr/kerberos/bin/kinit)を実行してください。適切なパスワードを入力した場合はなんのメッセージも表示されません。
[root@marine]# kinit administrator@W2K2.HOME.MONYO.COM
Password for administrator@W2K2.HOME.MONYO.COM: ← Administrator のパスワード
[root@marine]#
なお、Active Direcotoryの仕様のため、Active Directory構築後にAdministratorアカウントのパスワードを一度も変更していない場合はkinitに失敗しますので、同じパスワードで構わないので一度パスワードを変更しておいてください。パスワードを変更していない場合は図30のようなメッセージが出力され、kinitコマンドに失敗してしまいます。
[root@marine]# kinit administrator
Password for administrator@W2K2.HOME.MONYO.COM:
kinit(v5): KDC has no support for encryption type while getting initial credentials
[root@marine]#
kinitコマンドに引き続き、図31のようにnet ads joinコマンドを発行して、Active Directoryに参加します。
[root@marine]# ./net ads join
Joined 'MARINE' to realm 'W2K2.HOME.MONYO.COM'
正常に終了した場合は上記のように「Joined...」というメッセージが出力されます。ここでWindows 2000側で確認すると、図32のようにComputersコンテナにコンピュータアカウントが作成されていることが確認できます。
最後に、Sambaサーバを起動してから、Sambaサーバ上にアカウントが存在するユーザで(注17)Windows 2000側からログオンして、Sambaサーバにアクセスしてみてください。特にパスワードを聞かれることなくアクセスできるはずです。
Active Directory参加に関する詳細は、Samba as a ADS domain member(注18)というドキュメントに記述されていますので、一度参照してみてください。
[global]
passdb backend = ldapsam:ldap://ldap.home.monyo.com smbpasswd unixsam
(デフォルトは passdb backend = smbpasswd unixsam)
●The Official Samba-3 HOWTO and Reference Guide: [英文]
http://de.samba.org/samba/docs/man/howto/
●日本Sambaユーザ会：
http://www.samba.gr.jp/
●Japan Windows NT Users Group (JWNTUG) Home Page：
http://www.jwntug.or.jp/
●Samba が動作する Linux マシンを Windows ドメインに参加させる方法：
http://www.miraclelinux.com/technet/library/winbind/