注意：この中で紹介しているツール類は必ず各自の責任において使用してください。一切、保証も補償もしません。
※以下 UNIX という言葉は 任意のUNIX系OS を示す意味で使われています。
| 目的 | Samba 3.x + OpenLDAP による PDC の構築と、Samba 2.x PDC からの引き継ぎ |
| OS | FreeBSD 5.3 （5.2.1 以前とは設定方法が多少異なります） |
| ports |
converters/libiconv (with WITH_EXTRA_PATCHES option for CP932 patch) net/samba3 |
| ports, pm |
converters/p5-Convert-ASN1 net/p5-perl-ldap |
| 設定方針 |
ユーザー管理を完全に LDAP には移行せず、
一部 passwd ファイルによる管理を残す |
| 読者に求める知識 |
Samba と Windows Domain の基礎知識。 |
既に稼働している Samba 2.2 ドメインですが、 Windows ドメインコントローラーとして本格的に運営してみると、 細かい不具合やちょっと気になる点があったりします。 また、LDAP などを使用しないと Windows ドメインのユーザー管理を本格的に行うことができず （方法はあるけど知らないだけ？）、 ユーザー追加の際に UNIX(FreeBSD) 上で追加してから、Samba に追加するという二度手間になり、 ユーザー管理も２ヶ所に分散、非常には煩雑でした。 本テキストは、Samba 3.x への置き換えと OpenLDAP への一元管理に移行した際のメモです。
注意：本文は「【FreeBSD 5.3】OpenLDAP の設定」 により環境構築が済んでいる状態を想定しています。必ずそちらを先に参照・設定してください。
Samba 3系に日本語版は存在せず、 また日本語の扱いに少々問題があることは、 結構話題になっていたので知っている方も多いと思います （参考）。 FreeBSD の場合、libiconv にパッチを充てるのがよいでしょう。
該当するバージョン用のパッチを
libiconv パッチ集のページから
ダウンロードします。このパッチを make 時に（自動的に）充てるよう、files の中に展開します。
-DWITH_EXTRA_PATCHES 付きで make することで上記パッチを自動的に充ててくれます（ports の libiconv 1.9.2_1 にて確認）。
# pwd /usr/ports/converters/libiconv # make -DWITH_EXTRA_PATCHES # make -DWITH_EXTRA_PATCHES install
これでパッチの充たった libiconv が作成されます。確認作業をしてみます。
# iconv -l | grep MS
EUC-JP-MS EUCJP-MS EUCJP-OPEN EUCJP-WIN
この、eucJP-ms というのは何なのか、ということですが、 Shift-JIS(cp932) と EUC の文字コード変換で、 一部の文字が文字化けする現象があり、これを改善するパッチのようです。
% ls ← on samba 2.x by EUC-JP スタートタニター/ 新しいフォタダ/ % ls | nkf ← on samba 2.x by EUC-JP and nkf スタートメニュー/ 新しいフォルダ/ % ls ← on samba 3 by EUCJP-MS スタートメニュー/ 新しいフォルダ/
Samba 3系は ports の中の、net/samba3 にあります。こちらの環境では Samba 3.0.7.1 でした （LDAP系の不具合があったりしますので、なるべく最新のものを入れるようにしてください）。 make を実行すると、コンパイルオプションの選択画面が現れます。 少なくとも、LDAP support は選択してください。 こちらの環境では、"LDAP, ADS, CUPS, WINBIND, SYSLOG, QUOTAS, UTMP" を選択しました （設定変更時に再コンパイルしなくて良いように）。 Samba 2.x とは違い "LDAP support" を選択しても強制的に LDAP 認証にさせられ smbpasswd が 使えなくなる……といったことはありませんので、ご安心ください。 なお ACL_SUPPORT はファイルシステムに Windows ACL の概念を設定するオプションです （要ファイルシステムのサポート）。 これをチェックしないと Samba おいて ACL 自体が使えなくなるわけではありません。
make && make install まで特に問題は発生しないと思います。 swat を使用するならば /etc/inetd.conf 中の swat の行のコメントを外し、 /etc/rc.d/inetd reload してください（kill -HUP でもよい）。
※make時、特に指定しなくても libiconv を使用するようです。
細かい設定は後回しにして、とりあえず samba を起動させてみましょう。 まず /etc/rc.conf に次の一行を追加します。
samba_enable="YES"
設定ファイルのサンプルは /usr/local/etc に smb.conf.default としてありますので、 これを smb.conf にコピーして最低限の設定のみします。 以下は変更点の抜粋です。
# 以下 ３行は必ずどの設定よりも最初に記述すること！ dos charset = CP932 unix charset = EUCJP-MS display charset = EUCJP-MS # ※Fedora Core 等では EUCJP-MS → UTF8 で設定 netbios name = my_machine_name ← Windows から見えるマシン名。各自で決める workgroup = my_workgroup_name ← ワークグループ名。各自で決める
これだけ書いたら、あとは実際に起動させます。 起動スクリプトは /usr/local/etc/rc.d に samba.sh.sample という名前でありますので、 そのまま samba.sh という名前に変更します。
# /usr/local/etc/rc.d/samba.sh start
Samba を使用するアカウントを設定します。 root 以外の/etc/passwd に存在する通常のUNIXアカウント（ここでは user0 とします）が samba を利用するよう設定します。
# smbpasswd -a user0
そうしたら、Windows などからきちんと起動しているか確認してみてください。 マシン一覧に表示されるのを待つか、 \\sambaマシンのIP とエクスプローラーのアドレスバーに入力してください。 ユーザー名を求められたら、user0 と今設定したパスワードを入力。 きちんと見えましたか？
【この項はサーバの設定とは関係ありません。読み飛ばし可】 SWAT から設定するのでもよいですが、 smb.conf を手書きする場合は、vi 等ではさすがに面倒です。 よくやるのは smb.conf のパーミッションを 660 にして、 wheel に所属しているユーザのホームから
% ln -s /usr/local/etc/smb.conf
として Windows のテキストエディタ（TeraPad, EmEditor等）から編集しています （当然のことですが、一通り設定が終わったらパーミッションを元に戻しておきます）。 samba の標準の設定で、ホームディレクトリは共有されますので。 また SWAT を使用しない場合、SWAT と一緒にインストールされるドキュメント類を 参照するのが煩雑になるため、apache で alias の設定をしています。 具体的には以下の記述を httpd.conf に追加しました。
# Samba manuals
Alias /samba/ "/usr/local/share/swat/"
<Directory "/usr/local/share/swat">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
なお、現 Samba 3.0.7_1 において SWAT 付属の help メニューの一部の記述がおかしいため、 index.html を無効にしました。
# cd /usr/local/share/swat/help # mv index.html _index.html
Samba PDC（Primary Domain Controler）設定の詳細については省略しますので、 他所を参照するなり、Samba 付属ドキュメント（Samba-PDC-Howto等）を参照願います。 日本 Samba ユーザ会の翻訳ドキュメント。 経験から述べますと、smb.conf の man と Samba-HOWTO-Collection は大変有益です （初めて PDC を設定したときは何度も何度も読み返しました）。
一応、少しだけ説明してみます。 Windows ドメインというのは、ユーザやマシンなどのリソースを一括管理するシステムです。 例えば Windows 2000 環境で他人のマシンの共有にアクセスしようとするとき、 いちいちユーザ名とパスワードを求められるし、 そのために共有を作成するマシンそれぞれにアカウントを作成……など という面倒な思いをした方も多いのではないかと思います。 ドメインを導入すると、こうした管理を一元化できるために、 一つのマシンでアカウント追加作業をすれば（基本的に）ドメイン内のどのマシンも使用できるようになります。
ちなみに WINS というのは、Windows Name Service の略でWindowsマシン名についての DNS みたいなものです（PDC, BDC がどれかという情報も入っているけど）。 WINS と Windows ドメインは全く別物ですが、 WINS を導入しないドメイン（ワークグループ）ではルータを超えることができません。 なぜなら、Windows はあるドメイン（ワークグループ）内の マシンを探すとき「基本的にブロードキャスト」を使用するからです。 ルータより向こうにブロードキャストは届きません （参考資料：Windowsネットワークのブラウジング問題の解明）。
この他、Windows ネットワークには（特にドメイン構築の際）学ぶべきことが沢山ありますが、 それこそキリがないので割愛します。
Samba PDC への設定は簡単です。以下の項目を追加してください。
# ドメインに対するログインを許可する domain logons = Yes # Primary Domain Controler になる domain master = Yes # Local network における ブラウズマスターの機能を on にする（default） local master = Yes # ローカルブラウズマスター選定時、絶対に勝つ値を設定する os level = 65 # WINS server になる wins support = Yes
こちらの環境では以下の設定も追加しました。詳細は省略します。
# Access to Samba allow hosts allow = 192.168. # See http://www.dd.iij4u.or.jp/%7Eokuyamak/Documents/tuning.japanese.html socket options = TCP_NODELAY SO_RCVBUF=8760 SO_SNDBUF=8760 # log file name log file = /var/log/samba/%m.log # 256KB cache per file write cache size = 262144
sabma.sh restart とすれば、Samba が PDC になっています。
Samba PDC への設定は簡単です。smbpasswd コマンドにより、 root の samba 用パスワードを設定、またドメインに参加させたいマシン名を machine としたとき、 machine$ という UNIX アカウントを作成して（*BSD では vipw で $ を付加する）次のようにする。
# smbpasswd -a -e root New SMB password: Retype new SMB password: Added user root. # smbpasswd -a -m machine$
追加方法は、2000 の場合「システム → ネットワークID → プロパティ」から。 詳細は割愛します。
「OpenLDAP の設定」により、 LDAP の設定は完了していると仮定します。 まず samba 用の スキーマ をコピーしてください。
# cd /usr/local/etc/openldap # cp /usr/local/share/examples/samba/LDAP/samba.schema schema/
続いて slapd.conf に以下のように変更し、再起動してください。
# 追加 include /usr/local/etc/openldap/schema/samba.schema # 変更 #access to attrs=userPassword access to attrs=userPassword,sambaLMPassword,sambaNTPassword by self write by users read by anonymous auth # 追加 index sambaSID
# rc.d/slapd.sh restart
今回は、samba で使用するデータ位置は "dn: dc=samba,dc=mymachine" としました。 変更する場合は、以下読み替えてください。 次の設定を smb.conf に記述します。
#----------------------------------------------------------- # LDAP setting #----------------------------------------------------------- passdb backend = ldapsam:ldap://127.0.0.1 smbpasswd ldap suffix = dc=samba,dc=mymachine ldap admin dn = cn=ldaproot,dc=mymachine ldap ssl = no # It's setting tested only samba 3.0.11 ldap user suffix = ou=Users ldap group suffix = ou=Groups ldap machine suffix = ou=Computers
経験上、次の "ldap filter" は設定しないほうが無難です （本来 Samba が問い合わせのケースによって適切にフィルタパラメーターを選択するのですが、 このパラメーターを設定すると、常にそちらを使うようになり不具合が発生するようです。 3.0.11 の GUI からのユーザー追加時に objectClass=posixAccount とすべきところを、 この設定値に書き換えるため不具合が発生することを確認済。）
# This will not set, because SAMBA is setted automatically. # ldap filter = (&(uid=%u)(objectclass=sambaSamAccount))
LDAP のパスワードを以下のようにして、Samba に教えます。
# smbpasswd -w secret
次に Samba の OpenLDAP 用ツールをコピーして使います。 これらは Perl スクリプトです。
# cd /usr/local/share/examples/samba/LDAP/smbldap-tools # cp *.pl /usr/local/sbin # cp *.pm /usr/local/lib/perl5/site_perl # cd /usr/local/sbin # chmod +x smbldap*
これらのスクリプトを実行するために、 必要な Perl module を install します。 converters/p5-Convert-ASN1 と net/p5-perl-ldap です。 続いてこれらのスクリプトの設定です。設定すべきファイルは /usr/local/lib/perl5/site_perl/smbldap_conf.pm です。 面倒なのでシンボリックリンクを張っておきます。
# cd /usr/local/etc # ln -s /usr/local/lib/perl5/site_perl/smbldap_conf.pm # chmod 600 /usr/local/lib/perl5/site_perl/smbldap_conf.pm ←必ず実行すること # net getlocalsid S-1-5-21-2712330414-357773214-3474141324
chmod の行も必ず実行してください。 なぜならば、このファイルには LDAP の rootdn のパスワードを平文で書く必要かあり、 大変危険だからです。さて、続いてこのファイルを編集します。変更箇所は以下のとおりです （他の部分は必要に応じて適時変更してください）。
# LDAP の設定で pam_min_uid を設定した場合必要 $UID_START = 10000; $GID_START = 1000; $SID='S-1-5-21-2712330414-357773214-3474141324'; ←上で表示されたもの $suffix = "dc=samba,dc=mymachine"; $binddn = "cn=ldaproot,dc=mymachine"; ←rootdn $bindpasswd = "secret"; ←rootdn の passwd # #$_defaultUserGid = 545; # Users $_defaultUserGid = 513; # Domain Users # Default Computer (Samba) GID $_defaultComputerGid = 553;
Samba を PDC として使用する場合、 標準で所属するグループを Users ではなく Domain Users にしておきます。 これを含め、色つきで示したグループを変更する際は特に注意してください。 ここに書かれた 500 番台のグループは、この後で自動的に（固定番号で）生成されます （番号については、Windows グループマッピンクの説明参照）。 ここの値を変更すると、 後々使用する smbldap-useradd.pl smbldap-usermod.pl などが次のような（意味不明の）エラーを出して動作せず、 ハマります（検索すると同じところでハマった人が沢山出てきます……（汗））。
# smbldap-useradd.pl -a xxx Can't call method "get_value" on an undefined value at smbldap-useradd.pl line 152, <DATA> line 283. # smbldap-usermod.pl -u 998 Administrator Can't call method "get_value" on an undefined value at smbldap-usermod.pl line 176, <DATA> line 283.
ここまで設定を終えたら、 あとは /usr/local/etc/rc.d/samba.sh restart として再起動し、次のスクリプトを実行してください。 （旧 NTドメインや Samba ドメインを引き継ぐ場合、 以下の作業はあとでやり直すことになりますが、確認の意味で実行しても問題はありません）。
# smbldap-populate.pl
うまく行けば、Samba の標準のグループやユーザなどが追加されています。 CoralDirectory などのツールで実際に表示させ、感覚を掴んでみてください。
# id Administrator uid=998(Administrator) gid=512(Domain Admins) groups=512(Domain Admins)
現在稼働している Windows ドメインの移行を考えるとき、 絶対に避けて通れないものが SID (Security Identifier) の話です。 同じドメイン名なのに PDC を再構築したらログオンできなくなった （再び信頼関係を築かなければならなくなった）。 ユーザを新しいドメインに移動したら「レジストリ設定が保存されない」など （顕著なのはキーボード環境が常に英語になってしまうこと）、 不具合が多発した……という経験をお持ちの方も多いのではないかと思います。 この原因となるのが、この SID です。
Windows システムは、コンピューター、コンピューターのユーザ（例：Administrator, Guest）、 グループ（Administrators, Power Users, Users）などに対して一意（決して重複しない）識別記号を付与します。 これが SID と呼ばれる物です。説明するより実際に見る方かわかりやすいので、 LDAP のディレクトリ表示ツールなどで実際に確認してみてください。 smbldap-populate.pl コマンドにより追加された標準のグループと、 Administrator, Nobody の２ユーザが "dc=samba, dc=mymachine" にあるはずです。 それぞれグループやユーザの詳細（エントリ）を表示させてみると、 sambaSID なる属性があることに気づくと思います。これが SID です。 例えば次のようになっています。
dn: ou=Groups,dc=samba,dc=mymachine Domain Adminis S-1-5-21-2712330414-357773214-3474141324-512 Domain Users S-1-5-21-2712330414-357773214-3474141324-513 Domain Guest S-1-5-21-2712330414-357773214-3474141324-514 Domain Computers S-1-5-21-2712330414-357773214-3474141324-553 Power Users S-1-5-21-2712330414-357773214-3474141324-547 Users S-1-5-21-2712330414-357773214-3474141324-545 dn: ou=Users,dc=samba,dc=mymachine Administrator S-1-5-21-2712330414-357773214-3474141324-2996 Nobody S-1-5-21-2712330414-357773214-3474141324-2998
色を変えた部分までが、特定のマシン（またはドメイン＝PDC のマシンSID）を示しています。 その手前は固定されたものです。 最後の部分（RID と呼ばれる）が、そのマシン内のどのリソースかは示しています。 つまり (マシンSID)-545 といえば、そのマシン内の Users のグループを示します。 これらのグループの値は予約されたものです。よくみると、各ユーザは sambaSID の他に、 sambaPrimaryGroupSID という値を持っています。これが所属するグループの SID です。 このように Windows におけるユーザやグループ、マシンの識別はこの SID をすべてベースにしています。
既存のドメインを引き継ぐ場合、各マシンは 信頼関係を結んだドメイン（PDCマシン）を SID にて管理しているため、同じ SID を与える必要があります。 それどころか、ドメインのユーザやグループも移行前と同じ SID を持つ必要があり、 つまりSID の情報をすべてそのまま引き継がなければいけないのです。 この項目の最初に書いた問題は、これが原因で発生します。 マシンSID（＝PDCマシンのSID）を引き継がないとドメインログオン出来ないのですぐに分かりますが、 各ユーザの SID を引き継がないと「エラーも表示されずにログイン出来るのにレジストリの設定が無効化される」という 不可思議現象に悩まされます（「移動プロファイルが使用出来ない」等のエラーは profile 格納位置の設定と、 その共有のファイルへの単なるアクセス権の問題）。 これは、各ユーザプロファイルに保存されいてるユーザレジストリ NTUSER.DAT に、 レジストリの所有者やアクセス権といった情報が書き込まれているためで、 SID が変わってしまうと（Administrator権限を持たない限り） HKEY_CURRENT_USER にマップされた NTUSER.DAT （実際には HKEY_USERS\S-1-5-21-xxxxxxx-xxxxxxx-xxxxxxx-xxx のマップ）に 書き込むことはおろか読み込みすら出来ないからです（解決法はいくつかあります）。
※参考資料：@IT「オブジェクトを識別するSIDとは？」、 Samba-HOWTO「NT4 PDC から Samba-3 PDCへの移行」
まずドメインの SID を取得しないことには始まりません。移行前のマシンが存在するならば、BDC として動作させコピーするなどいくつか方法があります。相手が NT ドメインの場合はおそらくこの方法以外に存在しません。
# net getlocalsid MY_NTDOMAIN # net getlocalsid PDC_MACHINE_NAME
とすれば、ドメインSID を取得することができます（ただし、そのドメインまたはワークグループに参加してないとうまく行きません）。"net rpc getsid" により直接取得する方法もありますが、その詳細はミラクル・リナックスの記事(part 4)を参照ください。おすすめの方法はお手軽な次のコマンドです。
# rpcclient -U admin_account old_PDC_netbios_name ←旧PDCマシンの IP アドレスでも可 Password: rpcclient $> lookupnames old_PDC_netbios_name old_PDC_netbios_name S-1-5-21-603411576-1378211384-1856622148
SID が得られたら、今度はそれを設定中の（新）PDC に記録します（Samba を止めてから行いましょう）。
# net setlocalsid S-1-5-21-603411576-1378211384-1856622148
必ず表示された SID を設定してください（例のまま入れても意味がありません）。 また3.5 Samba on OpenLDAP の設定の項で出てきた smb_ldap.conf にも、ドメインSID を設定します。 （なぜ２ヶ所に設定する必要があるかといいますと、 この設定は smbldap-tools を使用するためのもので、本来 Smaba の動作には無関係だからです。 しかし現実にはこのツールを使用せずに Samba on LDAP を実現するのは非常に面倒です）
$SID='S-1-5-21-603411576-1378211384-1856622148'; ←PDC のもの
ここまで実行してから、3.5 Samba on OpenLDAP の設定の項の最後に出てきた、 "smbldap-populate.pl" により NT の標準グループを追加するのですが、 もし既に追加してしまっていた場合は、4.1項で述べたような厄介な問題が発生しますので、 以下の "ldapdelete" コマンドを先に実行してください。
※まだ smbldap-populate.pl していない場合 ldapdelete は不要 # ldapdelete -x -r -D "cn=ldaproot,dc=mymcahine" -W "dc=samba,dc=mymachine" # smbldap-populate.pl
ここまで出来ましたら、LDAP 表示ツールなどで挿入されたグループなどを表示させてみてもよいでしょう。 それらのグループはすべて、この項で設定した SID に RID を付加したものになっているハズです （もしそうなっていなければ設定ミスです。やり直しましょう）。
smbpasswd で管理していたユーザを移行させます （他の方法で管理していた場合は、他所の記述を参照ください）。 まず smbpasswd 内のユーザに UNIXアカウント を与えるため、次のコマンドを実行します （以下随時、ディレクトリツールで表示させると感覚が掴みやすいと思います）。
# smbldap-migrate-accounts.pl smbpasswd.old
Perl 5.x では "Use of uninitialized value" とワーニングで出るようですが、 ソースの問題のようですので気にしなくてよいでしょう。 続いて、Samba アカウントのフラグやパスワードを次のコマンドで移行します。
# pdbedit -i smbpasswd:./smbpasswd.old
以上で完了……してくれたら、どんなにか楽なことか……。
このまま profiles などのデータを移行し、共有の設定を終え、 いざ稼働……とすると4.1節で述べた問題に直面してしまいます。 LDAP 内のユーザ情報を表示させてみると分かりますが、 これはユーザの SID の最後の部分（RID）が変更されてしまっていることに起因します。 Samba において RID は、UID (UNIX ID) より次の式で決定されます。
RID = UID * 2 + 1000 RID = GID * 2 + 1001
実際に LDAP 内の UID と RID はこの関係を満たしているはずです。 この式により UID の重複が起こらない限り SID の重複が起こらないというシステムになっています （SID が重複すると不具合の原因となります）。 "smbldap-migrate-accounts.pl" により移行した UNIX アカウントは、 新規の UID を持つこととなり、必ずしも古い UID とは一致しません。 pdbedit による移行時も、単に UID から上式により SID を生成するのみで SID の引き継ぎは行われません。
各ユーザのプロファイルにあるユーザレジストリ（NTUSER.DAT）には、 アクセス権限として所有者（ユーザ）の SID が記録されています。 つまり SID が変更になるとユーザ別のレジストリにアクセスできず、 レジストリ変更を伴う設定変更が全くできなくなります。 早い話が Windows がほとんど使い物にならなくなります。 この SID とレジストリ内の SID 情報の不一致を解決しないことには、 まともな運用は到底不可能です。この問題の解決策は次のようになります。
現実的なのは 2 と 3 でしょう（個人的には 2 の方法をおすすめします）。 1 を選べるケースは限られるでしょう。 1 または 2 を選択した場合はA.2 UID/SID 変更ツールをご利用ください。 なお、こちらでは一部のアカウントについて pdbedit でパスワードが 移行しない（なぜかログインできない）現象が発生しました。 原因不明ですが、その場合もこのツールをご利用ください。 次項では 3 の方法について説明します。
NTUSER.DAT のレジストリ所有権が問題ならば、それを書き換えてしまえば問題はなくなります。 Samba に付属する profiles というツールでこの書き換えが可能ですが、 このツールにはバグがあり *BSD ではまともに動作しません。 A.1 utils/profiles のバグについてを参照し、 まずきちんと動作する profiles コマンドを生成してください。
profiles コマンドの使い方は次のようになります（日本語MAN）。
# profiles -c oldSID -n newSID NTUSER.DAT
old SID は smbpasswd や /etc/passwd から、 new SID は現 SID を調べることで確認出来ます。 ですが、全ユーザに対して、手作業でこんなことをしていたら日が暮れてしまうので、 自動化スクリプトを作成しました。A.3 NTレジストリ SID 変更自動化ツールを参照ください。
SID 変更後は、以前とは違うユーザとして各マシンから扱われますので、 各マシンの "c:\Document and Setting" に古い（SID 変更前の）プロファイルが残り続けます。 完全に HDD の肥やしとなりますので、気になる場合は削除してしまってください。 コントロールパネル → システムのプロパティ → ユーザープロファイル から 消去する方が安全です（直接ファイルを消す方が楽ですか、 間違ってローカルのプロファイルやシステムのプロファイルを消すと悲惨です）。
以下は簡易なメモです。ドメインとして運用は、 ミラクル・リナックスの記事(part 3) が参考になり、他にも多くのページで紹介されていることから細かい話は割愛します。
標準では Domain Admins はドメインの管理者にはなっておらず、 マシンをドメインに参加させる時に問題が発生します。 このマシンを参加させる権限を持つユーザは、通常では root (UID=0 のユーザ) のみです。 smbpasswd に root を登録すればよいのですが、 root アカウントを Samba アカウントとして使用するのは少々抵抗があります。 ですから smb.conf の global セクションに
admin users = Administrator
と指定します。@"Domain Users" としてもよいのですが、 共有でのファイル操作などがすべて root 権限で動作するという恐ろしい状態となりますので、 普段は使用しないアカウントを指定する方がよいでしょう。
各マシンに Domain Administrator でログインして、 管理ツール → コンピュータの管理 → ローカルユーザーとグループ → グループを開く。 この中の Users に NTDOMAIN\Domain Users が、Administrator に NTDOMAIN\Domain Users が 追加されている（ドメインに参加させる際、自動的に設定される模様）。 Power Users に NTDOMAIN\Domain Users を追加すれば、 このグループに所属するユーザにローカルマシンの Power Users 権限が与えられる。 これは各マシン一台一台で設定する必要がある（リモートマシンに対してコンピュータの管理を行うのでも可）。
まず smb.conf に smbldap-tools のスクリプトを指定します。
add user script = /usr/local/sbin/smbldap-useradd.pl -m '%u' add machine script = /usr/local/sbin/smbldap-useradd.pl -w '%u' delete user script = /usr/local/sbin/smbldap-userdel.pl '%u' set primary group script = /usr/local/sbin/smbldap-usermod.pl -g '%g' '%u' # set primary group script : not work, give me idea about this. add group script = /usr/local/sbin/smbldap-groupadd.pl -p '%g' delete group script = /usr/local/sbin/smbldap-groupdel.pl '%g' add user to group script = /usr/local/sbin/smbldap-groupmod.pl -m '%u' '%g' delete user from group script = /usr/local/sbin/smbldap-groupmod.pl -x '%u' '%g'
SP4 のファイルを解凍する場合（上記記事より）。 コマンドラインから W2KSP4_ja.EXE /x として解凍した後、 コマンドプロンプトからそのディレクトリ以下の i386 の中へ移動。 "expand usrmgr.ex_ usrmgr.exe" によりファイルを復元します。 SRVMGR.EXE を持っていればマシンの追加／削除もできます。 一応、上記設定で一通りの動作は確認しています （2005/09/01 さらに"add machine script"の記述ミスを訂正しました。 確認は Samba 3.0.11にて行いました。Samba 3.0.7 では不具合があります。 また、メンバーの存在しないグループは未だ正常に扱えないようです）。
使い方はコマンドヘルプ（-h オプション）を参照。
# smbldap-useradd.pl ユーザの追加 # smbldap-userdel.pl ユーザの削除 # smbldap-usermod.pl ユーザの設定変更 # smbldap-usershow.pl ユーザの設定表示 # smbldap-passwd.pl パスワードの変更 # smbldap-groupadd.pl グループの追加 # smbldap-groupdel.pl グループの削除 # smbldap-groupmod.pl グループの設定変更（メンバの追加など） # smbldap-groupshow.pl グループの情報表示
Samba の profiles コマンドが FreeBSD 等 BSD系OS で動かないバグがありまして、
Could not mmap file: NTUSER.DAT, Cannot allocate memory
とエラーになり全く使い物になりません。この修正パッチを置いておきます。
バイナリに変な仕掛けはしていませんが、パッチを充てコンパイルし直す方が無難です。 パッチの充て方は、ソースのディレクトリで patch コマンドを呼び出すか、ports の samba3/files に patch-profiles という名前でコピーして make clean && make してください。 patch の中身をみると分かりますが、なかなか面白いバグでした （*BSD Kernel の mmap(2) の実装にも問題あるような気がしますけど……）。
方法１） # cd /usr/ports/net/samba3/work/samba-3.0.7/source # patch < profiles.patch 方法２） # cp /xxx/profiles.patch /usr/ports/net/samba3/files/patch-profiles
2005/06/09追記：Bugzilla によると Samba 3.0.12 以降では修正されているようです。
use smbldap_conf.pm するため root のみが実行できます（同じ理由により GPL です）。 当たり前ですが、作業はログイン中のユーザが居ないときに行ってください。
# smbpasswd2ldap.pl Usage: smbpasswd2ldap.pl [-acsrpf?h] smbpasswd Available options are: -c UID を smbpasswd の内の値に変更する（SID も UID から再計算される） -s SID を smbpasswd の UID から計算した値に変更する -r SID を 現在のUID から再計算する -p SMB (LMNT)パスワードを smbpasswd から再設定する -f SambaFlags をsmbpasswd から再設定する -?|-h このヘルプを表示する （例） # smbpasswd2ldap.pl -s smbpasswd ←SID のみ古い値を引き継ぐ # smbpasswd2ldap.pl -c smbpasswd ←UID/SID を引き継ぐ # smbpasswd2ldap.pl -r smbpasswd ←SID を再計算（UID を変更してなければ初期状態に戻る） # smbpasswd2ldap.pl -pf smbpasswd ←パスワードとフラグを再設定する
UID の変更は危険ですので、その危険性が分かっている人以外は実行しないでください。 -s オプションにより smbpasswd から 旧SID を引き継げます。 ただし、この場合は新規に Samba ユーザを追加していく仮定で、 ユーザSID（sambaSID）の重複が起こらないように注意する必要があります。 重複してもすぐに全体が停止するほど重大な結果にはなりませんが、 本来ユニークな識別子であるべきものですから、やはり不具合は発生します。
また手元の環境で pdbedit コマンドにより smbpasswd から移行時、 パスワードがうまく移行されなかったり、なぜかログイン出来なかったりという現象が発生しました （ログインに失敗するとユーザに無効フラグが付いていた）。 そんなときは、このツールでパスワードの移行とフラグの再設定をすると良いか知れません。
use smbldap_conf.pm するため root のみが実行できます（同じ理由により GPL です）。 当たり前ですが、作業はログイン中のユーザが居ないときに行ってください。
# ntuserdat_sid_changer.pl Usage: ntuserdat_sid_changer.pl [-opbt?h] old_smbpasswd profile_directory Available options are: -o oldSID old マシンSID を指定する（省略時は 現在のマシンSID と同一） -p command profiles コマンドを絶対パスで指定 -b 作業前のレジストリのバックアップを保存 -t テストモード（profiles コマンドを呼び出さない） -?|-h このヘルプを表示 （例） # ntuserdat_sid_changer.pl smbpasswd /home/samba/profiles/%u # ntuserdat_sid_changer.pl -o S-1-5-21-2712330414-357773214-3474141324 smbpasswd /home/samba/%u/profile
各プロファイルディレクトリから NTUSER.DAT を探しだし自動的に更新します。 内部的に Samba 3.x の profiles コマンドを呼び出しています。 古い SID(RID) は smbpasswd から計算されますが、 ディフォルトでは Machine-SID (Domain SID) に変更はないものとしてみなされます。 もし古い SID の Machine-SID を指定したい場合は "-o" オプションを利用ください （これにより SID の異なるドメイン間でユーザプロファイルの移動が可能になると思われます）。
新しい（変更後の）SID は常に LDAP から参照されます。 もし SID の書き換えとレジストリ所有者（NTUSER.DAT）の書き換えを同時に行いたい場合は、 先に SID を書き換えてから、レジストリ所有者の SID を変更してください。
FreeBSD 5.x において nss_ldap を導入して Samba VFS を設定すると （要するに reccycle = ゴミ箱）、正常に動作はしているようなのですが、 次のようなエラーメッセージを大量に吐かれます。
Error trying to resolve symbol 'init_module' in /usr/local/lib/samba/vfs/recycle.so: Shared object "nss_dns.so.1" not found, required by "smbd"
要するに共有ライブラリのファイルが見つからないと言っているのですが、 おそらく nss_ldap.so.1 に関数自体は存在するだろうと、シンボリックリンクを張りました。 すると
Error trying to resolve symbol 'init_module' in /usr/local/lib/samba/vfs/recycle.so: Shared object "nss_files.so.1" not found, required by "smbd"
続いて
Error trying to resolve symbol 'init_module' in /usr/local/lib/samba/vfs/recycle.so: Shared object "nss_compat.so.1" not found, required by "smbd"
とやかましかったので、結局、以上の３ファイルにシンボリックリンクを張りったところ、 今は問題なく動いているようです。
# cd /usr/local/lib # ln -s nss_ldap.so.1 nss_dns.so.1 # ln -s nss_ldap.so.1 nss_files.so.1 # ln -s nss_ldap.so.1 nss_compat.so.1
Sambaサーバマシンに直接接続した共有プリンタにおいて、B4、B5といったB系列の用紙を印刷時に選べなくなる不具合があるようです。色々調べたところ、samba-jpのメーリングリストに「[samba-jp:13307] Re: Windows2000proからPSプリンタ利用時のB列用紙選択不可について」というポストがありました。
記事の通りパッチを充てたところ、うまく印刷できましたので報告代わりに差分を置いておきます。パッチの充て方はA.1の項目を参考にしてください。