公式のSamba 3.2.x HOWTOとリファレンスガイド

Edited by

Jelmer R. Vernooij

The Samba Team

Edited by

John H. Terpstra

Samba Team

Edited by

Gerald (Jerry) Carter

Samba Team


Table of Contents

表紙について
Attribution
序文
前書き
凡例
はじめに
Sambaとは何か?
なぜこの本?
本の構造とレイアウト
I. 概要
1. SAMBAのインストールとテスト方法
Sambaの入手とインストール
Sambaの設定 (smb.conf)
設定ファイルの文法
TDBデータベースファイルの情報
Sambaを起動する
設定の例
SWAT
サーバー上で有効な共有の一覧表示
UNIXクライアントによる接続
リモートのSMBクライアントからの接続
うまく動かない時には
まだ解決しない?
共通のエラー
大量のsmbdプロセス
エラーメッセージ: open_oplock_ipc
ネットワーク名が見つからない
2. 手軽な始め方: 短気な方への手引き
機能と利点
例題サイトの説明
動く例
スタンドアロンサーバー
ドメインメンバーサーバー
ドメインコントローラー
II. サーバー設定の基本
3. サーバータイプとセキュリティモード
機能と利便性
サーバータイプ
Sambaセキュリティモード
ユーザーレベルのセキュリティ
共有レベルのセキュリティ
ドメインセキュリティモード(ユーザーレベルのセキュリティ)
ADS セキュリティモード(ユーザーレベルのセキュリティ)
サーバーセキュリティ(ユーザーレベルのセキュリティ)
パスワードの検査
共通のエラー
何がSambaをサーバーにするか?
何がSambaをドメインコントローラーにするか?
何がSambaをドメインメンバーにするか?
常時パスワードサーバーへの接続不可
スタンドアロンサーバーはドメインコントローラーに変換された が、ユーザーのアカウントが動作しない
4. ドメイン制御
機能と利便性
シングルサインオンとドメインセキュリティ
ドメイン制御の基礎
ドメインコントローラーの種類
ドメイン制御の準備
ドメイン制御: 設定例
SambaによるADSドメイン制御
ドメインとネットワークログインの設定
ドメインネットワークログオンサービス
セキュリティモードとマスターブラウザー
よくあるエラー
$マシン名中に$を含められない
存在するマシンアカウントがあるためにドメイン参加に失敗する
システムにログオンできない(C000019B)
マシン信頼アカウントがアクセスできない
アカウントが無効
ドメインコントローラーが無効
ドメイン参加後ドメインメンバーワークステーションにログオンできない
5. バックアップドメインコントローラー
機能と利便性
基本的な背景情報について
Microsoft Windows NT4スタイルのドメイン制御
LDAP設定の注意
Active Directoryドメイン制御
ネットワーク上のドメインコントローラーになれる要件
どのようにワークステーションがそのドメインコントローラーを探すか?
バックアップドメインコントローラーの設定
設定例
よくあるエラー
マシンアカウントが満了し続ける
SambaはNT4 PDCのバックアップドメインコントローラーになれるか?
smbpasswdファイルの複製はどうやるか?
これをすべてのLDAPに使えるか?
6. ドメインメンバーシップ
機能と利便性
MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
マシン信頼アカウントの手動作成
NT4サーバーマネージャによるドメインマシンアカウントの管理
マシン信頼アカウントの即時作成
Microsoft Windows ワークステーション又はサーバーをドメインメンバーにする
ドメインメンバーサーバー
Samba-3でNT4形式でのドメインに参加する
これがなぜsecurity = serverよりもすぐれているのか?
Samba ADS ドメインメンバーシップ
smb.confの設定
/etc/krb5.confの設定
コンピュータアカウントの作成
サーバー設定のテスト
smbclientによるテスト
注意
Sambaドメインメンバー間でのユーザーIDマッピング共有
よくあるエラー
マシンをドメインに追加し直すことができない
マシンのドメインへの追加に失敗する
Windows 2003 PDC に参加できない
7. スタンドアロンサーバー
機能と利便性
背景
設定例
参照用文書サーバー
集中印刷サーバー
よくあるエラー
8. Microsoft Windows ネットワーク設定ガイド
機能と利便性
技術的な詳細
TCP/IP設定
ドメインへの参加: Windows 2000/XP Professional
ドメインログオンの設定: Windows 9x/Me
よくあるエラー
III. 詳細な設定方法
9. Samba 3.xシリーズにおける重要で重大な変更点
重要な Samba-3.2.x の変更点
重要な Samba-3.0.x の変更点
ユーザーとグループの変更
グループマッピングの基本
Passdbの変更
Samba-3.0.23でのグループマッピングの変更
Samba-3.0.23におけるLDAPの変更
10. ネットワークブラウジング
機能と利便性
ブラウジングとは何か?
議論
NetBIOS over TCP/IP
TCP/IPなしのNetBIOS
DNSとActive Directory
どのようにブラウジングは機能するか
ワークグループのブラウジングの設定
ドメインブラウジングの設定
強制的にSambaをマスターにする
Sambaをドメインマスターにする
ブロードキャストアドレスについての注意
複数のインタフェース
リモートアナウンスパラメーターの使用
Remote Browse Syncパラメーターの使用
WINS: The Windows Internetworking Name Server
WINSサーバーの設定
WINS複製
静的なWINSエントリ
役に立つヒント
Windowsのネットワークプロトコル
名前解決の順序
ブラウジングの技術的な概要
Sambaでのブラウジングサポート
問題の解決方法
サブネット間のブラウジング
よくあるエラー
SambaのNetBIOS名前キャッシュのフラッシュ
サーバーリソースがリスト出来ない
"Unable to browse the network"というエラーメッセージが出た。
共有とディレクトリのブラウジングが非常に遅い
不正なキャッシュされた共有参照はネットワークブラウジングに影響する
11. アカウント情報データベース
機能と利便性
下位互換性のあるバックエンド
新しいアカウント格納システム
技術情報
セキュリティに関する重要な注意事項
Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング
分散マシン上の共通のUID/GIDマッピング
LDAPに関するコメント
LDAPディレクトリとWindowsのコンピュータアカウント
アカウント管理ツール
smbpasswdツール
pdbeditツール
パスワードバックエンド
平文
smbpasswd: 暗号化したパスワードデータベース
tdbsam
ldapsam
よくあるエラー
ユーザーがログオンできない
auth methodsの設定
12. グループのマッピング: Microsoft Windows と UNIX
機能と利便性
議論
警告:ユーザー固有のグループ問題
ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
管理に関する重要な情報
既定値のユーザー、グループと相対識別子
設定例
設定スクリプト
smb.confにグループを追加するスクリプト例
グループマッピング設定のためのスクリプト
よくあるエラー
グループの追加が失敗する
ワークステーションのPower UsersグループへのDomain Usersの追加
13. リモートとローカル管理:Netコマンド
概要
管理者の作業と手段
UNIXとWindowsのグループ管理
グループアカウントの追加、改名、あるいは削除
グループメンバーシップの操作
ネストされたグループのサポート
UNIXとWindowsのユーザー管理
ユーザーアカウントの追加
ユーザーアカウントの削除
ユーザーアカウントの管理
ユーザーのマッピング
管理ユーザーの権限と権利
信頼関係の管理
マシン信頼アカウント
ドメイン間の信頼関係
セキュリティ識別子(SID)の管理
共有管理
共有の作成、編集と削除
共有のACLの作成と変更
共有、ディレクトリとファイルのマイグレーション(移行)
プリンターの移行
オープンしているファイルの制御
セッションとコネクションの管理
プリンターとADS
Sambaキャッシュの操作
IDMAP UID/SIDマッピングの管理
IDMAPデータベースダンプファイルの作成
IDMAPデータベースダンプファイルのリストア
その他の雑多な操作
14. 識別情報のマッピング(IDMAP)
SambaサーバーのサーバータイプとIDMAP
スタンドアロンSambaサーバー
ドメインメンバーサーバーかドメインメンバークライアント
プライマリドメインコントローラー
バックアップドメインコントローラー
IDMAPバックエンドの使用例
規定値のWinbind TDB
IDMAP_RIDを使うWinbind
Winbindを使ったIDMAPデータのLDAPへの格納
RFC2307bis Schema拡張を使ったADSからのIDMAPとNSSに対するLDAPの使用
15. User Rights and Privileges
権利の管理能力
net rpc rightsユーティリティの使用
権限の説明
Windows2000ドメインコントローラーでサポートされている権限
管理者のドメインSID
よくあるエラー
Windowsクライアントの管理が出来る権利と権限は何か?
16. ファイル、ディレクトリと共有のアクセス制御
機能と利便性
ファイルシステムのアクセス制御
Microsoft Windows NTFSとUNIXファイルシステムとの比較
ディレクトリの管理
ファイルとディレクトリのアクセス制御
共有のアクセス制御の定義
ユーザーとグループベースの制御
ファイルとディレクトリに対するパーミッションベースの制御
その他の制御
共有のアクセス制御
共有のパーミッションの管理
Microsoft Windowsのアクセス制御リストとUNIXとの相互運用性
NTセキュリティダイアログを使用したUNIXパーミッションの管理
Samba共有上でのファイルセキュリティの表示
ファイルの所有者の表示
ファイルとディレクトリのパーミッションの表示
ファイルまたはディレクトリのパーミッションの変更
標準的なSambaのcreate maskパラメーターとの相互作用
標準Sambaファイル属性のマッピングの相互関係
Windows NT/200X ACLとPOSIX ACLの制限
よくあるエラー
Publicな共有にユーザーが書き込めない
force userセットでrootとしてファイル操作が完了する
SambaでMicrosoft Wordを使うとファイルの所有者が変更される
17. ファイルとレコードのロッキング
機能と利便性
議論
Opportunistic Lockingの概要
SambaのOplocks制御
設定例
Microsoft Windowsのoplocksとキャッシュ制御
ワークステーションサービスのエントリ
サーバーサービスのエントリ
持続的なデータ破壊
よくあるエラー
locking.tdb のエラーメッセージ
Windows XP上でのMicrosoft Officeファイルセーブ時の問題
XP SP1でネットワーク経由でファイルを消すのに長い時間がかかる
参考文献
18. Securing Samba
序論
機能と利便性
保護対応と問題に関する技術的な議論
ホストベースの保護の使用
ユーザーベースの保護
インタフェース保護の使用
ファイアウォールの使用
IPC$ 共有ベースの拒否の使用
NTLMv2のセキュリティ
Sambaのアップグレード
よくあるエラー
smbclientはローカルホストで動くが、ネットワークは死んでいる
なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?
19. ドメイン間の信頼関係
機能と利便性
信頼関係に関する背景情報
ネイティブなMicrosoft Windows NT4の信頼関係の設定
NT4ドメイン信頼関係の作成
NT4ドメイン信頼関係の構築完了
ドメイン間信頼関係の機能
SambaにおけるNT形式のドメイン信頼関係の設定
信頼されるドメインとしてのSamba
信頼するドメインとしてのSamba
Windows 2000との間での、NT4形式のドメイン信頼関係
よくあるエラー
信頼されるドメインからのブラウジングに失敗する
LDAP ldapsamと古いバージョンのsmbldap-toolsに関する問題
20. Microsoft 分散ファイルシステムツリーのホスティング
特徴と利点
よくあるエラー
MSDFSのUNIXパスは大文字小文字を識別する
21. 旧式の印刷サポート
機能と利便性
技術的な序論
クライアントからSambaへの印刷ジョブの処理
印刷に関連する設定パラメーター
簡単な印刷設定
testparmによる設定の検査
手っ取り早い設定の検証
拡張印刷設定
設定の説明詳細
Samba-2.2からの印刷環境
Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー
無効になった [printer$]セクション
[print$]共有の作成
[print$]セクションのパラメーター
[print$]共有ディレクトリ
[print$]へのドライバーのインストール
プリンターの追加ウィザードによるドライバーのインストール
rpcclientを使った印刷ドライバーのインストール
クライアントドライバーのインストール方法
最初のクライアントドライバーインストール
新しいプリンターに対するデバイスモードの設定
追加のクライアントドライバーインストール
常時最初のクライアントからの接続はrootかprinter adminで行う
その他のテクニック
クライアントドライバーのための既定値の印刷操作の設定
大量のプリンターのサポート
Windows NT APWによる新しいプリンターの追加
エラーメッセージ: 異なった名前で接続できない
ドライバーファイルを集めるときに気をつけること
Sambaとプリンターポート
共通クライアントドライバーの間違った設定の防止
Imprintsツールセット
Imprintsとは何か?
プリンタードライバーパッケージの作成
Imprintsサーバー
クライアントのインストール
ユーザーによるインストールなしにネットワークプリンターを追加する
addprinterコマンド
旧式の印刷システムの、Sambaへの移行
Active DirectoryかLDAPへのプリンター情報の公開
よくあるエラー
rootパスワードを指定したが、アクセスできない
印刷ジョブはスプールディレクトリに入ったが、その後なくなった
22. CUPS印刷環境のサポート
概要
機能と利便性
Overview
基本的なCUPSサポート設定
libcups.soを使ったsmbdとのリンク
CUPSを使う簡単なsmb.confの設定
より複雑なCUPS smb.conf設定
高度な設定
集中スプール対ピアツーピア印刷
直接印刷機能:Windowsクライアント上のベンダドライバー
Windowsクライアントドライバーのインストール
application/octet-streamのためのraw印刷を明示的に有効にする
ドライバーアップロード手法
Postscriptドライバーダウンロードを使う高度に賢い印刷
Windows上でのGDI、UNIX上でのPostScript
Windowsドライバー、GDIとEMF
UNIX印刷ファイル変換とGUIの基礎
PostScriptとGhostscript
Ghostscript: 非Postscriptプリンターに対するソフトウェアRIP
PostScriptプリンター定義(PPD)の仕様
Windows形式のベンダPPDの使用
非PostScriptプリンターのためにCUPSはPPDを使う
CUPSフィルタリングアーキテクチャ
MIMEタイプとCUPSフィルタ
MIMEタイプ変換ルール
フィルタリングの概要
Prefilters
pstops
pstoraster
imagetops と imagetoraster
rasterto [プリンター固有]
CUPSバックエンド
cupsomatic/foomaticの役割
完全な図解
mime.convs
Raw印刷
application/octet-stream 印刷
非PostScriptプリンターのためのPostScriptプリンター記述
cupsomatic/foomatic-ripネイティブなCUPS印刷
フィルタリングチェインの例
CUPSドライバー/PPDの提供元
インタフェーススクリプトを伴う印刷
ネットワーク印刷(Windowsのみ)
WindowsクライアントからNT印刷サーバーへ
クライアント上でのドライバーの実行
サーバー上でのドライバーの実行
ネットワーク印刷(WindowsクライアントとUNIX/Samba印刷サーバー)
WindowsクライアントからCUPS/Samba印刷サーバーへ
Sambaによるジョブファイルの受け取りとCUPSへの引き渡し
ネットワーク PostScript RIP
UNIX上の、非PSプリンターのためのPPD
Windows上の非PostScriptプリンターのためのPPD
CUPSクライアントとしてのWindowsターミナルサーバー (WTS)
カーネルモードでのプリンタードライバーの実行は多くの問題を引き起こす
Workarounds Impose Heavy Limitations
CUPS: A Magical Stone?
カーネルモードでもPostScriptドライバーは大きな問題はない
ドライバーダウンロードを行うためのCUPSの設定
cupsaddsmb: 不明なユーティリティ
cupsaddsmb用のsmb.confの準備
Windows NT/200x/XP用のCUPSPostScript Driver
異なったドライバーファイルの認識
ドライバーファイルの入手
Windows NT/200x/XP用のESP Print Pro PostScriptドライバー
考慮すべき警告
WindowsのCUPS PostScriptドライバー対Adobeドライバー
cupsaddsmbの実行(Quiet Mode)
詳細な結果を表示するcupsaddsmbの実行
cupsaddsmbについて理解する
もしもcupsaddsmbが正しく終了した場合、どのように認識するか
Samba PDCににおけるcupsaddsmb
cupsaddsmbフローチャート
クライアント上でのPostScriptドライバーのインストール
クライアント上での危険なPostScriptドライバー設定を防止する
rpcclientを使ったPostScriptドライバーファイルの手動インストール
rpcclientマニュアルページのチェック
rpcclientマニュアルページの理解
Producing an Example by Querying a Windows Box
adddriverとsetdriverを完了させるための要求事項
15ステップでの手動ドライバーインストール
トラブルシューティング再考
印刷関連の*.tdbファイル
Trivial Database Files
バイナリ形式
*.tdbファイルの喪失
tdbbackupの使用
Linuxprinting.orgからのCUPSプリントドライバー
foomatic-rip と Foomaticの説明
foomatic-ripとFoomatic PPDのダウンロードとインストール
CUPSによるページの課金
Quotasの設定
正しいあるいは不正な課金
Windowsクライアント用のAdobeとCUPS PostScriptドライバー
page_logファイルの形式
存在する欠点
将来の構想
他のアカウントツール
追加の材料
CUPSスプールフィルタの自動削除または保存
CUPS構成の設定の説明
準備
手動の設定
Windowsに接続された印刷へのCUPSからの印刷
より詳細なCUPSフィルタリングチェーン
よくあるエラー
Windows 9x/Meクライアントがドライバーをインストール出来ない
cupsaddsmbが、無限にrootパスワードを問い合わせてくる
cupsaddsmbrpcclient addriverがエラーを出す
cupsaddsmbのエラー
クライアントがSambaプリンターに接続できない
Windows 200x/Xpからの新しいアカウント再接続のトラブル
間違ったユーザーでSambaサーバーに接続されるのを防ぐ
AdobeドライバーからCUPSドライバーにアップグレードする
PDCであるSambaサーバー上でcupsaddsmbが使えない
削除されたWindows 200xプリンタードライバーが引き続き表示されている
Windows 200x/XP ローカルセキュリティポリシー
Administratorはすべてのローカルユーザーに対してプリンターをインストールできない
NTクライアント上での印刷の変更、機能の通知
Windows XP SP1
Windows 200x/XP上ですべてのユーザーが印刷オプションを設定出来ない
Windowsクライアント上でのドライバー設定における、多くに共通する失敗
cupsaddsmbが、新しくインストールしたプリンターで動かない
/var/spool/samba/のアクセス許可が、再起動後毎回リセットされる
lpという名前の印刷キューが印刷ジョブを間違って扱ってしまう
cupsaddsmbに対するAdobe PostScriptドライバーファイルの位置
CUPS印刷プロセスの概要
23. スタッカブルVFSモジュール
機能と利便性
議論
含まれるモジュール
audit
default_quota
extd_audit
fake_perms
recycle
netatalk
shadow_copy
他で入手可能なVFSモジュール
DatabaseFS
vscan
vscan-clamav
24. Winbind: ドメインアカウントの使用
機能と利便性
はじめに
Winbindが提供するもの
対象となるユーザー
外部のSIDの取り扱い
Winbindの動き方
Microsoft Remote Procedure Calls
Microsoft Active Directoryサービス
Name Service Switch
Pluggable Authentication Modules
ユーザーとグループIDの割り当て
結果のキャッシュ保存
インストールと設定
はじめに
用件
テスト
結論
よくあるエラー
NSCDの問題に関する警告
Winbindがユーザーとグループを解決しない
25. 詳細なネットワーク管理
機能と利便性
リモートサーバー管理
リモートデスクトップ管理
NoMachine.Comによるリモート管理
ThinLincを使うリモート管理
ネットワークログオンスクリプトの魔法
ユーザーの干渉なしにプリンターを追加する
ログオン接続の制限
26. システムとアカウントポリシー
機能と利便性
システムポリシーの作成と運用
Windows 9x/ME ポリシー
Windows NT4形式のポリシーファイル
Microsoft Windows 200x/XP Professionalのポリシー
アカウント/ユーザーポリシーの管理
管理ツール
SambaのEditregツールセット
Windows NT4/200x
Samba PDC
システムスタートアップとログオン処理の概要
よくあるエラー
ポリシーが動かない
27. デスクトッププロファイルの管理
その特長と利点
移動プロファイル
プロファイル処理のための Samba の設定
Windows クライアントのプロファイル設定に関する情報
User Profile Hive Cleanup Service
Windows 9x/Me と NT4/200x/XP ワークステーション間でプロファイルを共有する
Windows NT4/200x サーバーから Samba にプロファイルを移行する
必須プロファイル
グループプロファイルの作成と管理
Windows ユーザーのデフォルトプロファイル
MS Windows 9x/Me
MS Windows NT4 Workstation
MS Windows 200x/XP
よくあるエラー
少人数のユーザーやグループのための移動プロファイルの設定
移動プロファイルを使えない
デフォルトプロファイルを変更する
移動プロファイルと NT4 スタイルのドメインポリシーのデバッグ
28. PAM ベースの分散型認証
その機能と利点
技術的な議論
PAM 設定のための文法
システム設定の例
smb.conf の PAM 設定
winbindd.soを使った遠隔 CIFS 認証
pam_smbpass.so を使ったパスワードの同期
よくあるエラー
pam_winbind の問題
Winbind がユーザーとグループを解決してくれない
29. Microsoft Windows ネットワークへのSambaの統合
機能と利便性
背景情報
純粋なUNIX/Linux環境中での名前解決
/etc/hosts
/etc/resolv.conf
/etc/host.conf
/etc/nsswitch.conf
Microsoft Windowsネットワーク内でのような名前解決
NetBIOSネームキャッシュ
LMHOSTSファイル
HOSTSファイル
DNSによる検索
WINSによる検索
よくあるエラー
片方向しかpingが届かない
ネットワーク接続がとても遅い
Sambaサーバー名前変更の問題
30. ユニコード/文字セット
機能と利便性
文字セットとユニコードとは何か
Sambaと文字セット
古い名前からの変換
日本語の文字セット
基本的なパラメーターの設定
個別の実装
Samba-2.2系列からの移行
よくあるエラー
CP850.so が見つからない
31. バックアップテクニック
特徴と利点
バックアップ手段についての議論
BackupPC
Rsync
Amanda
BOBS: Browseable Online Backup System
32. 高可用性
機能と利便性
技術的な議論
最終目的
これがなぜ難しいか?
簡単なソリューション
高可用性サーバー製品
MS-DFS: 貧者のクラスター
結論
33. 大きなディレクトリの取扱い
34. 詳細設定のテクニック
実装
複数のサーバーのホスティング
複数仮想サーバーの性質(Personalities)
複数の仮想サーバーホスティング
IV. マイグレーションとアップグレード
35. Sambaのアップデートとアップグレード
アップデート要求の要点
Samba-3.0.xからSamba-3.2.0へのアップグレード
Samba-2.xからSamba-3.0.25へのアップグレード
お手軽移行ガイド
Samba-3.xシリーズにおける新しい機能
Samba-3.2.xシリーズにおける新しい機能
Samba-3.0.xにおける新しい機能
新しい機能
36. NT4 PDC からSamba-3 PDCへの移行
計画と開始方法
目的
移行プロセスの手順
移行オプション
うまくいくための計画
Samba-3実装の選択
37. SWAT: Samba Web 管理ツール
機能と利便性
ガイドラインと技術的なTips
SWATインストールの有効か
SWATを使用できるように有効化する
SSLを使うSWATのセキュア化
SWAT国際化サポートの有効化
概要と簡単な紹介
SWAT ホームページ
全体(Global)の設定
共有設定
プリンター設定
SWATウィザード
ステータスページ
表示(View)ページ
パスワード変更ページ
V. トラブルシューティング
38. Sambaチェックリスト
概要
前提条件
テスト
39. Sambaの問題の調査と解決方法
診断ツール
Sambaそれ自身によるデバッグ
Tcpdump
Ethereal
Windowsのネットワークモニター
参考となる外部情報(URL)
メーリングリストにからの助言
メーリングリストからの脱退方法
40. バグの報告
概要
一般的な情報
デバッグレベル
デバッグ固有の操作
内部エラー
稼働中のプロセスへのアタッチ
パッチ
41. TDB ファイルの管理
特徴と利点
TDB ファイルの管理
VI. Reference Section
42. Sambaのコンパイル方法
Subversion経由でのSambaソースコードへのアクセス
概要
samba.orgへのSubversionアクセス
rsyncとftp経由によるSambaソースへのアクセス
SambaのPGP署名の検証
バイナリの構築
Active Directoryサポートを伴うSambaのコンパイル
smbd nmbdwinbinddの起動
inetd.confからの起動
もう一つの方法: smbdをデーモンとして起動する
43. 移植性
HPUX
SCO UNIX
DNIX
Red Hat Linux
AIX: シーケンシャル先読み
Solaris
ロックの改善
Solaris9上の Winbind
44. Samba と他の CIFS クライアント
Macintoshクライアント
OS2 Client
OS/2 Warp Connect または OS/2 Warp 4の設定
他のOS/2バージョンでの設定
OS/2クライアント用のプリンタードライバーのダウンロード
Windows for Workgroups
Microsoftからの最新版 TCP/IPスタック
パスワード変更後に.pwlファイルの削除
Windows for Workgroupsにおけるパスワードの取り扱い方法の設定
パスワードにおける大文字小文字の区別
既定値のプロトコルとしてTCP/IPの使用
処理速度の改善
Windows 95/98
処理速度の改善
Windows 2000 サービスパック 2
Windows NT 3.1
45. Sambaパフォーマンスチューニング
比較
ソケットオプション
読み取りサイズ
Max Xmit
ログレベル
Read Raw
Write Raw
ログインが遅い
クライアントのチューニング
Linuxカーネルを変更した事によるSambaパフォーマンス問題
壊れたtdbファイル
Sambaのパフォーマンスがとても悪い
46. LDAPとトランスポート層のセキュリティ
概要
設定
認証局の作成
サーバー証明書の生成
証明書のインストール
評価
トラブルシューティング
47. Samba サポート
無償サポート
商用サポート
48. DNSとDHCP設定ガイド
機能と利便性
設定例
ダイナミックDNS
DHCPサーバー
A. GNU General Public License version 3
A. Preamble
A. TERMS AND CONDITIONS
A. 0. Definitions.
A. 1. Source Code.
A. 2. Basic Permissions.
A. 3. Protecting Users’ Legal Rights From Anti-Circumvention Law.
A. 4. Conveying Verbatim Copies.
A. 5. Conveying Modified Source Versions.
A. 6. Conveying Non-Source Forms.
A. 7. Additional Terms.
A. 8. Termination.
A. 9. Acceptance Not Required for Having Copies.
A. 10. Automatic Licensing of Downstream Recipients.
A. 11. Patents.
A. 12. No Surrender of Others’ Freedom.
A. 13. Use with the ???TITLE??? Affero General Public License.
A. 14. Revised Versions of this License.
A. 15. Disclaimer of Warranty.
A. 16. Limitation of Liability.
A. 17. Interpretation of Sections 15 and 16.
A. END OF TERMS AND CONDITIONS
A. How to Apply These Terms to Your New Programs
用語集
Index

List of Figures

4.1. ドメインの例
8.1. Network Bridgeの設定
8.2. インターネット プロトコル(TCP/IP)のプロパティ
8.3. ネットワークの詳細設定
8.4. DNSの設定
8.5. WINS Configuration
8.6. ローカル エリア接続のプロパティ
8.7. インターネット プロトコル (TCP/IP)のプロパティ
8.8. TCP/IP 詳細設定
8.9. DNS設定
8.10. WINS設定
8.11. Windows Me ネットワーク設定パネル
8.12. IPアドレス
8.13. DNS設定
8.14. WINS設定
8.15. 全般
8.16. コンピュータ名パネル
8.17. コンピュータ名の変更パネル
8.18. コンピュータ名の変更パネル ドメイン MIDEARTH
8.19. コンピュータ名の変更 ユーザー名とパスワードパネル
8.20. ネットワークパネル
8.21. クライアント用Microsoftネットワークプロパティパネル
8.22. 識別パネル
8.23. アクセス制御パネル
10.1. サブネット間のブラウジングの例
11.1. IDMAP: SIDのUIDへの解決
11.2. IDMAP: SIDのUIDへの解決
12.1. IDMAP: グループSIDからGIDへの解決
12.2. IDMAP: GIDから対応するSIDへの解決
12.3. IDMAPのグループマッピングの保存
16.1. UNIXパーミッション欄の概要
19.1. 信頼の概要
22.1. ローカルプリンターに対するWindowsの印刷
22.2. PostScript Printerによる印刷
22.3. 非Postscriptプリンターに対するRIPとしてのGhostscript
22.4. PostScriptを整形するためのCUPS内のprefiltering
22.5. デバイス固有印刷オプションの追加
22.6. PostScriptから中間ラスタ形式への変換ダイアグラム
22.7. Ghostscriptを使うCUPSラスタ生成の図解
22.8. イメージ形式をCUPSラスタ形式に変換する流れ
22.9. ラスタからプリンター固有形式への変換図
22.10. cupsomatic/foomaticの処理対ネイティブなCUPSの図
22.11. PDFからソケットへのチェーン
22.12. PDFからUSBチェーン
22.13. クライアント上での印刷ドライバーの実行
22.14. Print Driver Execution on the Server.
22.15. CUPS/Sambaサーバー経由での印刷
22.16. cupsaddsmbのフローチャート
22.17. フィルタリングチェーン1
22.18. cupsomaticを使うフィルタリングチェーン
22.19. CUPS印刷のダイアグラム概要
24.1. Winbind Idmap
39.1. キャプチャの開始
39.2. Etherealメインデータウィンドウ

List of Tables

1.1. 継続的なTDBファイルの説明
1.2. 一時的なTDBファイルの説明
5.1. 分散ドメインバックエンドアカウントの選択肢
6.1. 前提
9.1. 基本的なドメイングループのマッピング
10.1. ブラウズリストの例1
10.2. サブネットブラウズの例2
10.3. サブネットのブラウズの例3
10.4. サブネットのブラウズの例4
11.1. NT4ドメイン対Sambaポリシー制御
11.2. Samba SAM Accountコントロールブロックフラグ
11.3. Attributes in the sambaSamAccountのオブジェクトクラス(LDAP), Part A
11.4. sambaSamAccountオブジェクトクラスの属性, Part B
11.5. 設定可能なldap passwd syncの値
12.1. よく知られているユーザーのRID既定値
15.1. 現在有効な権限の一覧
16.1. UNIXとWindowsによるディレクトリの管理
16.2. ユーザーとグループベースの制御
16.3. ファイルとディレクトリパーミッションベースの制御
16.4. 他の制御
16.5. WindowsのファイルACLをUNIX POSIXファイルACLにマップする方法
21.1. 既定値の印刷設定
22.1. CUPSに同梱されているPPD
23.1. 拡張監査ログの情報内容
27.1. User Shell Folder レジストリキーのデフォルト値
27.2. デフォルトのプロファイル設定用のレジストリキー
27.3. デフォルトユーザープロファイルへのパスのデフォルト値 を持つレジストリエントリー
28.1. pam_smbpassで認識されるオプション
29.1. 一意なNetBIOS名
29.2. Group Names
30.1. Samba-2.2とSamba-3中の日本語文字セット
35.1. Samba-2.2.xのTDBファイルの説明
36.1. 3つの主要なサイトのタイプ
36.2. 移行方式による相違点の詳細
40.1. デバッグ単位
41.1. Samba の Trivial Database ファイル

List of Examples

1.1. 最小のsmb.conf
1.2. もう一つ別の簡単なsmb.confファイル
2.1. 匿名リードオンリサーバー設定
2.2. 変更後の匿名の読み書き可能な設定の smb.conf
2.3. 匿名プリントサーバーのsmb.conf
2.4. セキュアなオフィスサーバーのsmb.conf
2.5. メンバーサーバーのsmb.conf (Globals)
2.6. メンバーサーバーのsmb.conf (Shares and Services)
2.7. エンジニアリングオフィスのsmb.conf (globals)
2.8. エンジニアリングオフィスのOffice smb.conf (shares and services)
2.9. PDC用のLDAPバックエンドを使うsmb.conf
2.10. リモートのLDAPを使うBDCのsmb.conf
4.1. PDC用のsmb.confの例
4.2. PDCにするためのsmb.conf
5.1. BDCと共に使う、PDC上にLDAPサーバーがあるPDCのための最低限のsmb.conf
5.2. smb.confに記述する複数LDAPサーバー
5.3. BDCになるための最低限の設定
7.1. 参照用文書サーバー用のsmb.conf
7.2. 匿名印刷のためのsmb.conf
10.1. ドメインマスターブラウザーのsmb.conf
10.2. ローカルマスターブラウザーのsmb.conf
10.3. マスターブラウザーにならないsmb.conf
10.4. ローカルマスターブラウザーにするためのsmb.conf
10.5. マスターブラウザーにならないsmb.conf
11.1. LDAP idmap バックエンドを使う設定例
11.2. LDAP使用の設定例
12.1. smbgrpadd.sh
12.2. グループ追加スクリプトのためのsmb.confエントリの設定
12.3. Script to Set Group Mapping
13.1. ワークステーションのPower UsersグループにDomain Users を自動で追加するスクリプト
13.2. Magic Netlogon共有
14.1. NT4形式のドメインメンバーサーバーのsmb.conf
14.2. ADSドメインメンバーサーバーのsmb.conf
14.3. idmap_ridを使うADSドメインメンバーのsmb.conf
14.4. LDAPを使うADSドメインメンバーサーバー
14.5. NSS経由のRFC2307bisスキーマ拡張日付を使うADSドメインメンバーサーバー
16.1. サンプルファイル
17.1. いくつかのファイルがoplocksされた共有
17.2. Oplock Break Contention Limitの設定
20.1. DFS が設定された smb.conf
21.1. BSD印刷環境での簡単な設定
21.2. 拡張BSD印刷環境設定
21.3. [print$] の例
22.1. 最も簡単な印刷関連のsmb.confファイル
22.2. 1台のプリンター用にグローバルなCUPS設定を上書きする
22.3. cupsaddsmb使用のためのsmb.conf
23.1. VFSモジュールを使うsmb.confの例
23.2. 複数のVFSモジュールを使用するsmb.confの例
23.3. シャドーコピーVFSを使う共有
24.1. Winbind設定のためのsmb.conf
25.1. Script to Enforce Single Resource Logon
30.1. VFS CAP
34.1. Elasticのsmb.confファイル
34.2. CDROMサーバーのsmb-cdserver.confファイル
34.3. マスターのsmb.conf ファイルのグローバルセクション
34.4. smb-merlin.confファイルの共有セクション
34.5. smb-sauron.confファイルの共有セクション
38.1. [tmp]共有のためのsmb.conf
38.2. 特定のサブネットからのみ接続を受け付ける設定例
38.3. 特定のサブネットとローカルホストから接続を許可する例
44.1. 最低限のプロファイル共有

表紙について

この本の表紙にはオフィシャルSamba-3 HOWTOとリファレンスガイド 初版の「自由(freedom)」のテーマを踏襲している。先駆者人たちの行動の源泉 を問いかけることで過去を振り返ってもよいだろう。過去から何も得られないとい うことはまずあり得ない。我々の前に人生を歩んだ彼らの業に思いを馳せるか どうかに関わらず、我々の自由を護った彼らに対する誇りと感謝の念を忘れる ことがあってはならない。

情報テクノロジーの進化は、恐怖を抱かせるペースで進んでいる。時代の要求に 応えるかに見える進化を受け入れてきたのが人間の本性であるが、これは将来 の我々を罠にかけることにもなりかねない。情報テクノロジーの短い歴史の中 にすら、多くの実例がある。かつて MS-DOS は、我々を大型コンピュータのシ ステムを運用するコストから解放し、今日我々が享受している急速な発展を可 能としたツールと見なされていた。しかし、今日我々は、時代遅れで忘れたい 時代に束縛する技術として、侮蔑の念を以て MS-DOS を振り返っている。

Windows ネットワーク、Windows NT 4.0、近年の Active Directory と続く発 展は、今でこそ時代の先端を進んでいるように見えかも知れないが、遅かれ早 かれ、より優れたものに取って替わられる運命にある。拡張された認証情報ソ リューションやディレクトリに対する近年の注目は、想定外の事態ではない。 これらの技術が脚光を浴びる一方で、現在活気があり、力強いように見えてい たものが夜の冷たい風(the chilly wind of the night)のように扱われる日が きっとくる。何が待ち受けていようとも、進歩に逆らうことは考えられない。

Samba の開発は着々と行われている。Samba 3.0.0 からの変貌は驚くべきもの であるが、より高度でかつ迅速な進化が多くの人々から求められている。 近年の開発の成果はすぐに目に見える形で表れているが、それでもパンドラの 箱を開けるのにドキュメントが必要である。ネットワーク管理者が最小の手間 で新しい機能を迅速に導入する上で、本書がなんらかの助けになれば幸いであ る。導入を推進し、新しく実現する機能により得られたメリット(直訳:マイ レージが稼げる)を通じて、前途に待ち受けている世界に思いを馳せてほしい。 とりわけ、Samba がもたらした選択の自由を味わい、シームレスな相互接続性 がもたらす可能性を楽しんでほしい。

Attribution

SAMBAのインストールとテスト方法

手軽な始め方: 短気な方への手引き

サーバータイプとセキュリティモード

ドメイン制御

バックアップドメインコントローラー

ドメインメンバーシップ

スタンドアロンサーバー

Microsoft Windows ネットワーク設定ガイド

Samba 3.xシリーズにおける重要で重大な変更点

ネットワークブラウジング

アカウント情報データベース

グループのマッピング: Microsoft Windows と UNIX

リモートとローカル管理:Netコマンド

識別情報のマッピング(IDMAP)

User Rights and Privileges

ファイル、ディレクトリと共有のアクセス制御

ファイルとレコードのロッキング

Securing Samba

ドメイン間の信頼関係

Microsoft 分散ファイルシステムツリーのホスティング

旧式の印刷サポート

CUPS印刷環境のサポート

スタッカブルVFSモジュール

Winbind: ドメインアカウントの使用

詳細なネットワーク管理

システムとアカウントポリシー

デスクトッププロファイルの管理

PAM ベースの分散型認証

Microsoft Windows ネットワークへのSambaの統合

ユニコード/文字セット

バックアップテクニック

高可用性

大きなディレクトリの取扱い

詳細設定のテクニック

Sambaのアップデートとアップグレード

NT4 PDC からSamba-3 PDCへの移行

SWAT: Samba Web 管理ツール

Sambaチェックリスト

Sambaの問題の調査と解決方法

バグの報告

TDB ファイルの管理

Sambaのコンパイル方法

移植性

Samba と他の CIFS クライアント

Sambaパフォーマンスチューニング

LDAPとトランスポート層のセキュリティ

DNSとDHCP設定ガイド

序文

Johnが彼の最新の本のために、最初に私に紹介の文を書いてくれと依頼してきたとき、 彼が私を選んだことについて幾分不可解に思った。Johnと会話して、真の理由はわか り、彼は記事の残りを埋めるために、私にそれを任せた。そのため、背景について少 しばかり我慢するのをいとわないのであれば、Johnが提供しないであろう 記事の部分を提供しよう。

私はSun Microsystemsの企業標準ディレクタで、Sunの技術標準を管理している。それ 以前は、Johnに出会った、Netscapeでの技術標準ディレクタであった。Sun以前には、 DECでやはり標準についての仕事をしていた。私はいくつかの、標準についての本を書 き、分野としての標準を推進する、技術とビジネストレンドについての観察(時々助言) の傾向がある。技術的な分野としてではなく、管理ツールとして標準化を見る傾向が あるが、これはJohnが話してくれた理由の一部である。

あなたが以前に持っている、何らかの方法で特定の標準化手法に注目した本は、それゆ え標準についての本である。標準について留意することのうち最も重要なものは、作成 の手順の正当性である。標準は、ビジネスでも、技術的な理由のためでもなく、より深 くてずっとやむにやまれない理由のために作成される。標準は、人々が意味のある方法 で通信が出来るようにするために作成されて使われる。あらゆる標準は、それが真の標 準ならば、人々の間で関連するコミュニケーションを増大させるという完全な(そして 唯一の)ゴールセットを持つ。

しかしながら、標準が文書化されない限り、この主要なゴールには到達できない。それ が誰でも知っているようにそれらのドキュメントを提供する顕著 な感情だった時、私は余りに多くの標準化の効果の改善を行っていた。彼ら 言って知っている現在の それらは良い規格を破滅させるものである。彼らが知っているのなら、 なぜ標準化をしようとするのか?

人々が使い方を知っているので、よい標準は存続する。それが見 えなくなるくらいに簡単で、わかりやすくて、明快な時にどのように標準を使うかを知 る。うまく使う方法を記述している文書がはっきりしていで、明確で正しいときだけ、 標準は見えなくなる。これらの3つの要素は役に立つ標準のために存在しなければならな く、明白な取り組みなしで生じる、2つの分離しで異なったエンティティの間で、コミュ ニケーションと相互作用を許す。この本を読んだ後、3つの特徴の形跡を探すことと、 どのようにそれらがJohnの文書中に隙間無く織り込まれているかを注意しなさい。 正当性のない明快性と一意性は技術的な悪夢を提供する。曖昧さ がある、正当性と明快性は、おそらく小さな問題を発生させるが、明快性のない正当性 と一意性はシナリオを通して混乱状態を起こす。

そして、これが、Johnが彼自身はっきり言うことが出来ない(か望まない) 残りの話である。人-機械、機械-機械、人-人にせよ、2つあるいはそれ以上 のエンティティの間でのコミュニケーションのための資格と、コミュニケーションを増 大させるための標準を使いたいと思う誰かにとってユーザーの役に立つように、Sambaの、 明確で簡潔で、一意性があり、技術的に有効な表現である。この本の意図は、誰に対し ても、政治的、技術的、社会的な議題を納得させないことにある。意図は、Sambaについ て知りたい、どのように使うか、主要な責任を得る方法について知る必要があるユーザー に対しての文書を提供することである。Sambaの文書が素晴らしく成功して、Johnの部分 に誇りがある間、特定な仕事を達成するためのツールを必要とし、Sambaをそのツールと することを選んだ誰かのために文書を書く。

この本は、Johnの、Sambaに対する忍耐と献身と、私に言わせるならば、標準化のゴール である記念碑である。この本を書くことによって、Johnは、物事をより明確に、簡単に、 最終的に価値ある資源にするために配布することを望むSambaのユーザーに提供した。さら に、彼は非常に役に立つ、標準に対する理解と、ユーティリティを増加させ、そして、 これに関して、文書と同じくらい、我々の人生をより扱いやすくさせる標準に頼る我々 から感謝されている。

Carl Cargill, Senior Director
Corporate Standardization, The Office of the CTO
Sun Microsystems

前書き

Table of Contents

凡例

編集者は、この本を買ってくれたことに対して感謝する(訳注:最初に本として出版されていたため)。公式のSamba-3 HOWTOと リファレンスガイドは情報、フィードバック、TIPS、ヒントと幸福なソリューション の長年の蓄積の結果である。

この本は、内容が常に更新されている、生きている文書であることに注意。よりSambaユー ザにとって貴重な、この本の次の版を作るのを手助けするために、TIPS、テクニック、 役に立つヒント、Windowsネットワーク領域に関する特別な洞察を寄贈する事を勧める。

以前に行われたものよりも、より広範囲な、よりうまくSambaを使えるためとネットワー クユーザーにより多くの満足度を与えるかもしれない情報を協力して文書化した。

この本は、設定の例を提供し、それは、Microsoft Windowsネットワークの要点を文書化 し、Samba-3の重要な設定に対する徹底的な洞察を提供し、それらのすべてを役に立つフ レームワーク中に置くのを支援する。

この文書の、一番新しい電子的な版は、 http://www.samba.org/ 上のドキュメント ページで参照できる。

更新、パッチと修正は最も希望されるものである。以下の誰かに情報をメールで送ってほしい:

Jelmer Vernooij (jelmer@samba.org)
John H. Terpstra (jht@samba.org)
Gerald (Jerry) Carter (jerry@samba.org)

オリジナルと間違いがなくなったものが公開されることを助言することを願う。 著作権者からの同意のないものを公開しないでほしい。

凡例

以下の表記方法がこの本を通じて使用される:

  • TOSHARG2 は、公式Samba-3 HOWTOとリファレンスガイド第二版 編集者: John H. Terpstra and Jelmer R. Vernooij, Publisher: Prentice Hall, ISBN: 0131882228 の省略形として使われる。

  • S3bE2 は、 Samba-3 by Example第二版 編集者: John H. Terpstra, Publisher: Prentice Hall, ISBN: 013188221X の 略として使われる。

  • ディレクトリとファイル名はmonoフォントである。たとえば、 /etc/pam.conf となる。

  • 実行ファイル名は太字となる。たとえば smbd である。

  • メニュー項目とボタンは太字となるたとえば、 Next をクリック である。

  • 選択メニューは以下のように表示される: スタートコントロールパネル管理ツールActive Directory Users and Computers

はじめに

John H. Terpstra

Samba Team

June 29, 2003

人の贈り物はその人のために道を 開き、高貴な人の前にも彼を導く(訳注:聖書 18:16節?)。 Gifts are like hooks that can catch hold of the mind taking it beyond the reach of forces that otherwise might constrain it. --- Anon.

この本はSambaについての本である。多くの人の善意と、努力と、たくさんの作業から出 来上がったツールである。この本には、我々の後に続く人と同じように、価値をお互い に分け与える絶え間ない信条で寄贈されてきたものを含む。

この本は、Microsoftネットワーク管理者の必要に適合するために企画された。必要として いると考えている情報を見つけにくいと不満があるかもしれないが、UNIX管理者もこの本 から得るところがある。そのため、もしもあなたがMicrosoft認定のスペシャリストならば、 この本はあなたの要求をかなり満たすはずである。もしもUNIXかLinux管理者ならば、 現在の関心事に対する回答を探すのに苦労がないということにひどいと 感じる必要性もない。

Sambaとは何か?

Sambaは巨大で複雑なプロジェクトである。Sambaプロジェクトは野心的でわくわく するものである。Sambaを支えているチームは世界中に分散した30余人からなり、 興味深い範囲のバックグラウンドから来ている。このチームには科学者、エンジ ニア、プログラマ、ビジネスマンと学生がいる。

チームのメンバーは、Microsoft Windowsと非Microsoft IT技術領域の間での、 ワクワクする相互運用性に到達するのを助けるという願望ことを通じて、 積極的に参加していた。

Sambaプロジェクトの背景にある、努力を結集するためのスローガンは: Samba, Opening Windows to a Wider World!である。 プロジェクトの背景にあるゴールは、相互運用性の障害をなくすことである。

SambaはMicrosoft Windows クライアントのための、ファイルと印刷サービスを 提供する。それらのサービスは、任意のTCP/IPベースのプラットフォーム上で 提供されてよい。オリジナルの開発プラットフォームはUNIXとLinuxだが、現在 は、多くのシステム上で広く使われている。

Sambaプロジェクトは特徴的なファイルと印刷サービスの機能を含むだけではなく、 クライアントの機能や、Sambaへの簡単なマイグレーション用ユーティリティ、 Microsoft Windowsとの相互運用性支援ツールと管理ツールを含むように拡張され ている。

Sambaを運用する人はあなたのような人である。 You have inspired the developers (the Samba Team) to do more than any of them imagined could or should be done. ユーザーのフィードバックはSambaの開発を推進する。Samba-3は、 ユーザーの要求、助言、とコードの寄贈の結果としての大量の仕事の結果 を特に含んでいる。

なぜこの本?

現在Sambaに関するたくさんの本が市場に出回っていて、それぞれ独自の 価値がある。一見過剰な量の本が出回っているが、十分な文書を提供しそこねる ことについてSambaプロジェクトはたくさんの苦情を受けている。Sambaはまた 設定することについてとても複雑で難しいことについても苦情を受けている。 もしもSambaが成功していなかったならば、苦情がないはずなので、これは たくさんの方法によるSambaの成功の証拠である。

Sambaチームのメンバーは主にUNIXとLinuxで仕事をしているので、Sambaの 文書がその位置づけを反映していることは驚くべきには値しない。オリジナルの HOWTOテキスト文書は、いくつかのTIPS、とても貴重な情報を提供するように 意図されていて、それが誰かの手助けになるならば、それはとてもすばらしい ことである。しかしHOWTO文書はきちんと構造化されて、文脈も不統一だった。 それは、渡すことで利便性を得られるかもしれない、だれかに渡すために書かれた 情報の独立した情報のスナップショットであった。それらは、便利にマニュアル ページ中に書かれるべき多くの情報を転送することの必要性を反映した。

オリジナルのHOWTO文書は異なった著者により書かれている。ほとんどのHOWTO 文書は多数の著者からの投稿とフィードバックの結果である。この本を読むと、 各章が複数の著者により、それぞれの著者はそれぞれのスタイルで書かれてい るのに気がつくだろう。このことはオープンソースソフトウェア開発プロセス の自然なスタイルを表している。

インターネット上に広まっている非公式なHOWTO文書の集まりは、オリジナルの HOWTO文書由来のものである。この作業はずっと継続して作られている価値ある 非公式のHOWTO文書を置き換えないようにしようとして いる。もしも、非公式のHOWTOを改良しているならば、その仕事を継続してほし い!

非公式のHOWTOの作成、Sambaに関する情報ページ、メーリングリストやその他 で問い合わせに答えることをボランティアでやっていた人はこれが愛の労働で あることを知っているかもしれない。あなたが集めた貴重な知恵を喜んで受け 取ることについて、あなたの貢献について知りたいので、 John H. Terpstra(jht@samba.org). まで投稿をメールで送ってほしい。他のユーザーに対するサービスとして、技術 的に正確なものを採用したい。

既存のSamba本はUNIX管理者向けである。既存の本が適切な目的に役に立つ、 Samba-3が今出ているという1つの例外を除くこのターゲットグループの 見通しから、アップデートの必要がある!

公式のSamba-3 HOWTOとリファレンスガイドというこの 本は、Sambaととともに提供されているSamba-HOWTO-Collection.pdfを含む。 これらの文書は新しいデザインと意図で書かれている。

過去2年にわたって、多くのMicrosoftネットワーク管理者たちはSambaを採用し てその展開に興味を持つようになった。彼らの情報に対する要求は、UNIX管理 者のものとはとても異なった。以前のMicrosoftネットワーク管理トレーニング と経験から、この本は調整されて、情報が表現されるようになった。

本の構造とレイアウト

この本は6つの部分から出来ている:

概要

Samba-3をすぐに走らせるための手助けとして用意されている。 Fast Startの章は、Microsoftネットワーク管理者からの、 すぐに動くいくつかのサンプル設定 を要求されたことへの直接的回答である。

サーバー設定の基礎

この部分の目的は、既存のMicrosoft Windowsネットワークの知 識をSambaの技術や標準に変換するための方法である。この部 分の各章はそれぞれSambaサーバーの1つのインストールタイプ をカバーしている。

詳細な設定

ネットワークブラウジングの仕組みはすべてのMicrosoft Windows ユーザーにとって鬼門であった。Samba-3では、新しいユーザーとマシン アカウント管理機能、新しい、UNIXグループとWindowsグループの マッピング方法、ドメイン間の信頼関係、新しい動的ロードファイル システムドライバー(VFS)やその他を導入している。この文書では、 デスクトップとユーザーポリシーのハンドリングについての情報と同様 の拡張された印刷に関する記述、拡張されたネットワーク統合のテク ニックが新しい。このセクションはこの本の中心となる所である。 しっかり読んでほしい。

マイグレーションとアップデート

Samba-2.xからSamba-3に移行するときの問題点の概観と同様、Windows NT4からSamba-3にどのようにMicrosoftグレーとするかについての情報が たくさんの要求によりこの本に追加された。

トラブルシューティング

この短いセクションは試みがすべて失敗するときに手助けになる。

参照セクション

ここには、ほとんどのユーザーにとって末梢的なものとか、主要部分の 情報に含まれている残りのフィールドについての集積がある。

Microsoft Windowsと残りの世界との間での、相互運用性の新しい世界全体を楽しむあなたのユーザー を助けるための公開された最初の文書とSamba-3にようこそ。

Part I. 概要

Chapter 1. SAMBAのインストールとテスト方法

Andrew Tridgell

Samba Team

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Karl Auer

Dan Shearer

Samba Team

Sambaの入手とインストール

Sambaのバイナリパッケージは、ほとんどのLinuxかUNIXディストリビューション に含まれている。また、 the Samba home page(本家)にも いくつかのパッケージが置いてある。使用するOSに合わせたパッケージのイン ストールの詳細については、OSのマニュアルを参照してほしい。

もしもソースからSambaをコンパイルすることが必要ならば、 Sambaのコンパイル方法を参照してほしい。

Sambaの設定 (smb.conf)

Sambaの設定はsmb.confファイルに格納され、それは、通常 /etc/samba/smb.conf/usr/local/samba/lib/smb.confにある。このファイル を自分自身で編集するか、あるいは、たとえば、Sambaに含まれているWebベー スのインタフェースSWATのような、種々のGUIツールのどれかを使って編集する ことができる。

設定ファイルの文法

smb.conf ファイルは、昔のWindows 3.1で使われていたいろいろな .iniファイルと同じ文法を使う。おのおののファイル はいくつかのセクションからなり、それらは行の先頭が大括弧 ([])で囲まれた、セクション名から開始される。それぞれ は0またはそれ以上の、等号(=)で分離されたキー/値ペア を含む。ファイルは単なるテキストファイルなので、好みの編集ツールで開い て編集できる。

smb.confファイル中にあるおのおののセクションは、共有か、Sambaサーバー上 のメタサービスを記述している。[global]セクションは特 別であり、Sambaサーバー全体にたいして適用する設定を含む。Sambaは複数の メタサービスをサポートし、おのおのは固有の機能を提供する。例えば、 [homes]共有は、メタサービスであり、おのおののユーザー のための、個別のホーム共有を提供させる。[printers]は メタサービスであり、プリントキューサポートを確立し、それは、Windows クライアントから、UNIX/Linuxプリントスプーラに対してプリントジョブが 送られることに先立ち、中間スプールディレクトリの位置を指定する。

printers メタサービスは、printcap ファイル中で指定されたものか、lpstatコマンドか CUPS API経由かでのすべてのプリンターを共有プリントキューとして公開する ようにする。smb.confファイル中のprinters節は browseable でないように設定できる。もしもbrowseableに設定すると、 共有として見えるようになる。これは、WindowsプリントキューとしてUNIX システムプリンターを有効にするのみ反応するこのメタサービスをTmakes no sense。もしも、commentパラメーターが指定されるならば、 その値がWindowsエクスプローラーのブラウズリスト中にプリンター名の一部と して表示される。

共有またはメタサービスを指定するsmb.confファイル中のおのおののセクション は節(stanza)と呼ばれる(訳注:日本ではセクションという呼び名が通用している ため、以下はすべてセクションとする)。globalセクション はsmb.confファイル中のすべての他のセクションに影響する設定を指定する。 設定パラメーターはsmb.confマニュアルページに説明がある。いくつかのパラメーター はglobalセクションのみで使われ、その他いくつかは通常の 共有またはメタサービスセクションでのみ使われ、いくつかは、グローバルまたは 共有、メタサービスセクションで使える。

最小のsmb.conf はとても小さいsmb.confを含む。

Example 1.1. 最小のsmb.conf

[global]
workgroup = WKG
netbios name = MYNAME
[share1]
path = /tmp
[share2]
path = /my_shared_folder
comment = Some random files

TDBデータベースファイルの情報

この節では、Samba-3で使われるデータベースの簡単な説明を含む。

Sambaが格納するtdbファイルのディレクトリの位置は、コンパイル時オプ ションによって変わる。Samba-3は2つの場所にtdbファイルを格納する。 その位置を決める最も良い方法は、以下のコマンドを実行する:

root#  smbd -b | grep PRIVATE_DIR
   PRIVATE_DIR: /etc/samba/private

これは、秘密のtdbファイルが/etc/samba/private ディレクトリに格納されることを意味している。Samba-3はまた、より ありふれたデータを含むいくつかのtdbファイルを使う。それらのファイルの 位置は以下を実行することで見つけられる:

root#  smbd -b | grep LOCKDIR
   LOCKDIR: /var/lib/samba

それゆえ、例の中で表示されている残りの制御ファイルは /var/lib/samba ディレクトリに格納される。

継続的に使われるtdbファイルは 継続的なTDBファイルの説明一覧 にある。すべての継続的なtdbファイルは通常バックアップすべきである。 tdbファイルバックアップのためにtdbbackupユー ティリティを使うこと。すべての継続的なtdbファイルはマシンの マイグレーション、アップデートとアップグレードの間保存すべきである。

一時的なtdbファイルはバックアップの必要性はなく、マイグレーション、 アップデートとアップグレードの間保存する必要もない。一時的なtdb ファイルは 一時的なTDBファイルの説明 に説明がある。

Table 1.1. 継続的なTDBファイルの説明

名前説明
account_policy

Samba/NTアカウントポリシーの設定、パスワード満了の設定を含む。

group_mapping

Windows グループ/SID から UNIXグループへのマッピングテーブル。

ntdrivers

プリンター単位の、インストール済みドライバー情報を格納。

ntforms

プリンター単位の、インストール済みフォーム情報を格納。

ntprinters

プリンター単位の、devmode構成設定情報を格納。

passdb

tdbsamパスワードバックエンドが使われる時のみ存 在。このファイルはSambaSAMAccount情報を格納する。 注意:このファイルは/etc/passwdファイルからか他 の代替システムソースからのユーザーのPOSIXアカウント を必要とする。

registry

winreg RPC経由で種々のデータベーステーブルをエ クスポートすることをサポートするための、読み出 し専用Windowsレジストリスケルトンデータベース。

secrets

このファイルはWorkgroup/Domain/Machine SID、 LDAPディレクトリ更新パスワードとSambaが正常に 動作するために必要な重要な環境データのさらなる 集合。このファイルには、秘匿しなければならない とても機密性のある情報が含まれている。このファ イルはPRIVATE_DIRディレクトリに格納される。

share_info

共有単位のACL情報を格納。

winbindd_idmap

Winbinddのローカル IDMAPデータベース。


Table 1.2. 一時的なTDBファイルの説明

名前説明バックアップ
brlock

バイトレンジロック情報。

No
connections

最大接続数を拡張するために使われる一時的な接続上のキャッシュ。

no
eventlog/*tdb

イベントログエントリのレコードほとんどの環境ではこれはシステムログのキャッシュである。

no
gencache

WINSサーバーと信頼されるドメインデータのための汎用キャッシュデータベース。

no
login_cache

ログイン情報のための一時的なキャッシュで、特に不正なパスワード試行用。

no
messages

smbdによって処理されるメッセージの一時的な格納用。

no
netsamlogon_cache

net_samloginリクエストからのユーザーnet_info_3 構造データのキャッシュ(ドメインメンバーとして)。

no
perfmon/*.tdb

パフォーマンスカウンタ情報。

no
printing/*.tdb

プリントサービス単位で作成されるlpqコマンドのキャッシュされた出力。

no
schannel_store

機密ファイルで、PRIVATE_DIRに格納され、接続セッ トアッププロセスの再ネゴシエーションの必要なし で再接続可能な一時的な切断が可能になるための暗 号化した接続情報を含む。

no
sessionid

種々のセッション情報とutmp処理のための一時的なキャッシュ。

no
unexpected

どのプロセスもリッスンしていない時に受け取ったパケットを格納する。

no
winbindd_cache

NT4ドメインかADSから受け取ったアイデンテティ 情報のキャッシュ。ユーザーリストなどを含む。

yes

Sambaを起動する

Sambaは2つまたは3つのdaemonから構成される。daemonはバックグラウンドで動 作し、サービスを提供するUNIXのアプリケーションである。サービスの例としては、 httpd と呼ばれるdaemonが Apache Webサーバーである。 Sambaの場合は、3つのdaemonがあり、そのうち2つが最低必要である。

Sambaサーバーは以下のdaemonから成り立っている:

nmbd

このdaemonはすべての名前登録と名前解決要求を処理する。 これはネットワークブラウジング中で必要とされる主要な 伝達手段である。これは、すべてのUDPベースのプロトコル を処理する。nmbddaemonはSamba開始 プロセスの一部分として最初にコマンドを起動すべきである。

smbd

このdaemonはファイルと印刷関係の操作のための、TCP/IP ベースのすべてのコネクションサービスを処理する。また、 ローカルでの認証も管理する。これは nmbdの開始に引き続いて起動すべきで ある。

winbindd

このdaemonはWindows NT4またはADSドメインのメンバーの時に 起動すべきである。また、他のドメインとの信頼関係を結ぶ 時にも必要である。winbindddaemonは idmap uididmap gidパラメーターがsmb.conf ファイル中に存在するかどうかをチェックする。もしもそれ らが見つかった場合、winbinddはUIDと GIDの割り当てのために指定された値を使う。もしも、パラメー タが指定されていなければ、winbindd は起動するが、UIDとGIDの割り当てが出来ない。

SambaがOSベンダによってパッケージ化されている時、開始プロセスは通常プラッ トフォーム全体に渡って統合された固有の機能となっている。Sambaの起動の正 しい管理に関する特定の情報のためにOSプラットフォームの管理マニュアルを 参照してほしい。

設定の例

ディストリビューションtarファイル中にのソースコードのexamplesサブディレ クトリ中にサンプルの設定ファイルがある。実際問題としてオプションがどの ように組み合わさるかを見る事が出来るので、注意深く読むことを推奨する。 すべてのオプションはマニュアルページを見よ。必要があることに適用するた めと、smb.conf.defaultファイルを設定し始めること は価値があるかもしれない。そこには多くのコメントが書いてある。

最も簡単に使える設定ファイルは もう1つ別の簡単なsmb.confファイル 中で見る事ができるようなものを含んでいる。

Example 1.2. もう一つ別の簡単なsmb.confファイル

[global]
workgroup = MIDEARTH
[homes]
guest ok = no
read only = no

これは、サーバー上にアカウントを持つ誰でも、ログイン名かサービス名 として、homesへの接続を許す。 (注意:Sambaが使うワークグループ名も設定する必要がある。既定値の ワークグループ名はWORKGROUPである。)

正しい場所にsmb.confファイルをきちんと置くこと。正しい場所は、 バイナリファイルの構築方法に依存することに注意。正しい場所を知る ためには、以下のsmbdコマンド行を実行することで わかる:

root#  smbd -b | grep smb.conf

[homes]共有に対するセキュリティ設定の詳しい情報は Sambaのセキュア化を参照してほしい。

testparmによる設定ファイルの検査

testparmプログラムを使ってsmb.confファイルの内容を検査することは 重要である。もしもtestparmが正しく動けば、設定されたサービスの一覧を 表示する。もしもそうでなければ、エラーメッセージを表示する。それが 正しく動くようにして、動かす前にサービスが合理的であるようにすること。 以下のコマンドを入力する:

	root#  testparm /etc/samba/smb.conf
	

testparmは設定ファイルを解析し、不正な文法や不明なパラメーターを報告する。 また、共通の設定ミスをチェックし、それが見つかれば警告を発する。

smb.confファイルを変更した後には必ずtestparmを実行すること!

smb.confファイルはsmbddaemonによって定期的にチェッ クされ、 nmbdwinbinddによりそれがspawnさ れる毎インスタンスごとにチェックされる。可能な限りこのファイルを小さく しておくことはよいことである。多くの管理者はSamba設定を文書化すること を好み、そのため、このファイルを小さくしておくことは、賢明な文書化手法 である。これを適用する1つの解決方法は、 smb.conf.masterというような名前で別のファイルに、 すべての文書と設定を1つにまとめておくことである。 testparmユーティリティは、以下のように、マスターの 設定および文書ファイルから完全に最適化されたsmb.confファイルを作成 するのに使える:

root#  testparm -s smb.conf.master > smb.conf

この管理手法は最小限の必要性のためにsmb.confファイルサイズを同じ時に 保つ間詳細な設定変更レコードをメンテナンスすることを可能にする。

SWAT

SWATはWebベースの、Sambaの設定を行うために使うことが出来るインタフェー スである。SWATはあなたのプラットフォームでSambaパッケージで有効になって いないかもしれないが、分離したパッケージになっているかもしれない。もし もSWATを構築することが必要ならば、編集に注意してSWATのマニュアルページ を読んでソースコードからSWATを構成してインストールしてほしい。

SWATを起動するために、好みのブラウザーを起動し、 http://localhost:901/ を指定する。 Sambaを動かしているコンピュータがブラウザーが動いているコンピュータと異な るならば、localhostの部分を置き換えること。

SWATは任意のIP接続されたマシンからブラウザー経由で使えるが、平文でパスワー ドがネットワーク上を流れ、盗聴の危険性があることに注意してほしい。

SWATについての詳細な情報は、 The Samba Web Administration Tool にある。

サーバー上で有効な共有の一覧表示

設定済みのSambaサーバーから有効な共有の一覧を表示するには、以下の コマンドを実行する:

$ smbclient -L yourhostname

サーバー上で有効の共有の一覧が表示される。もしもそうでなければ、設定が どこか間違っている。この方法はたとえばWindows 2000のような、他のSMB サーバーの共有が有効かと言うことにも使える。

もしも、ユーザーレベルのセキュリティを選択しているならば、共有の一覧を表 示する前にパスワードを要求してくる。詳細はsmbclient のマニュアルページを参照のこと。コマンドラインに-N オプションを追加することで、パスワード要求なしに共有の一覧を表示出来る。

UNIXクライアントによる接続

以下のコマンドを入力する:

$ smbclient  //yourhostname/aservice

通常yourhostnamesmbdが インストールされたホストの名前である。 aservicesmb.confファイル中にある任意の サービスである。smb.confファイル中の [homes]セクションがあるならばusernameを試みる こと。

例:もしもUNIXホストがbambiで有効な ログイン名がfredならば、以下のように入力:

$ smbclient //bambi/fred

リモートのSMBクライアントからの接続

Sambaがローカルで正しく動いている時には、他のクライアントからアクセスを 試みることが出来る。数分以内に、Sambaホストは同一のサブネット上のすべて のWindowsクライアント上のマイネットワーク上(Network Neighborhood)に表示 される。他のクライアントからサーバーをブラウズするかそれをマウントするこ とを試みる。

DOS、Windows、あるいはOS/2クライアントからのマウントは以下のコマンドを 動かすことで行える:

C:\> net use m: \\servername\service

ここで、ドライブ名 m: は任意の有効なドライブ名である。使用するサービス(共有)名を ダブルクリックする時にそれが実際に存在していることは重要である。

印刷システムを試すための例は以下の通り。

C:\> net use lpt1:	\\servername\spoolservice

spoolserviceは対象のサーバー上のプリンターの名前(実際 にはプリントキュー)である。これは、指定されたspoolserviceが所有する プリンターに送られるWinbowsクライアント上のlpt1:ポートでキャプチャされ たすべてのプリントジョブを許可する。

C:\> print filename

うまく動かない時には

Sambaチェックリストを読んでみてもよい。 もしもまだ行き詰まっているならば、 Sambaの問題の解析と解決を参照しよう。 Sambaは世界中でとてもたくさん正常にインストールされている。あなたの 特定の問題が固有であれば、あなたの問題に誰かが遭遇し、それを克服する 方法を見つけていることを発見するために、インターネット上での検索を実 行することは生産的かもしれない。

もしも、Sambaを使うのが初めてで、特にWindowsかUNIX/Linuxののネット ワーキング初心者ならば、Samba-3 by Exampleという本 (訳注:Sambaのドキュメントの一部にもなっている)は評価済みのネットワーク 環境を作るのに手助けとなるだろう。最もサイトのニーズに適合するネット ワークデザインがある最初の五章から単に選び、それを展開するための 単純な段階的手順を取りなさい。その後、ネットワークが動き、更に改良の ための機会のための知識の取得のためには、この本を再度参照しよう。

まだ解決しない?

惨めなフラストレーションのストレスに対する最高のアドバイスは、クールダウ ンすることである!それはそれ自身挑戦かもしれないが、怒っているか、 悩んでいる間、解決策を探すことは難しくなる。頭を冷やせば、探している 答えを見つかることにつながる。繰り返すが、すべての問題は解決策がある 今そうすることが出来なくとも、誰かがそれを見つけるよい機会が ある。それは時間、忍耐と学習で変わる。

少しクールダウンしたなら、 the Samba Checklistを、問題の原因を 確認するために行う事が出来る手順を確認するために参照してほしい。

共通のエラー

以下の質問と問題はSambaメーリングリスト上で繰り返し発生するものである。

大量のsmbdプロセス

Sambaの3つの中心的なプログラムは:nmbd, smbd, と winbinddである。 nmbdはネームサーバーメッセージdaemonで、smbdはサーバーメッセージ daemonで、winbinddはドメインコントローラーとの間での通信を処理する daemonである。

もしもSambaがWINSサーバーとして動作していないならば、 システム上には1つのnmbdインスタンスが動作する。もしもWINSサーバーとして 動作するならば、2つのインスタンスがある。1つはWINS要求を処理 する。

smbd はすべての接続要求を処理する。おのおののクライアントに対する 接続が終わると新しいプロセスがspawnする。それゆえ、クライアント接続毎 にたくさんのdaemonが存在する。

winbinddは1つまたは2つのdaemonで動作し、 split mode(2つのインスタンスの場合)かどうかによる。

エラーメッセージ: open_oplock_ipc

smbdが起動した時にログファイル中に以下のエラーメッセージが出ることがある: open_oplock_ipc: Failed to get local UDP socket for address 100007f. Error was Cannot assign requested.

これは、loopbackデバイスが正しく動作していない。正しく設定し直すこと。 ループバックデバイスは内部(仮想の)ネットワークデバイスで、IPアドレスが 127.0.0.1である。システム上でどのようにloopback デバイスを設定するかはOSのドキュメントを読むこと。

ネットワーク名が見つからない

このエラーは以下の設定ミスのどれかによって起きる:

  • smb.conf内で共有に対する存在しない パスを指定した。

  • 共有にアクセスしようとするユーザーが 共有のパスに対する適切なアクセス権を持っていない。 読み出し(r)とアクセス(x)を有効にすべき。

  • アクセスしようとする共有が存在しない。

Chapter 2. 手軽な始め方: 短気な方への手引き

John H. Terpstra

Samba Team

Samba HOWTO文書中に含めるものについての最初に提案を受けた時、 だれかが問い合わせのためのサンプル設定をたくさん書いた。これは、 動いているシステムからたくさんのエッセンスを提示することに由来するたくさんの 価値を失わないで行う事が甚だしく難しい。それがドキュメントに抜けているもので ある。それをカバーする章の内容の中に設定の可能性の広範囲な説明がある。この 章は、要求されたことに対する処方であると思いたい。

この章中の情報は、ほとんど完成したこの本のオリジナルバージョンの後に書かれた Samba-3 by Exampleという本と比較してかなり情報量が少ない。 Samba-3 by Exampleは最初の版の最終稿をレビューした結果を フィードバックしたものである。読者フィードバックが、オリジナルのレビュアによ り反映が行われることを見ることは興味深かった。どの場合にも、経験ある ネットワーク管理者がそこから得るものと同様、何が新しいかをより理解する ための基礎的な調査に1ヶ月半かかった。Samba-3 by Exampleは その調査の結果である。この本のいくつかのページで提供されているものは、より 包括的にSamba-3 by Exampleの第二版でカバーしている。 両者の第二版は同じ時期にリリースされた。

まとめると、公式のSamba-3 HOWTO & リファレンスガイドは 自動車修理工の修理ガイドと同等のものとして意図されている。 Samba-3 by Exampleは、どのように車を運転するかを説明する ドライバー向けのガイドと同等である。もしもネットワークの設定例を完全にしたい のであれば、 Samba-3 by Exampleを参照すること。

機能と利点

基本的な動作するシステムを作成するために、Sambaは最小限の設定しか必要としない。 この節では、簡単なものから複雑なものへ、おのおのを動かすために必要とされる 設定ファイルの変更とすべてのステップを順番に提供する。徹底的に設定された システムは、追加の高機能な機能を使うだろう。それらの追加機能はこの文書の 残りの部分で触れられている。

ここで使っている例は、数多くの人が設定の例のために要求したものに依っている。 すべての識別子は問題がないようにしてあり、非現実的な存在しないサイトへ 何らかの形で似ていることは計画的に行われている。

例題サイトの説明

最初の設定例中では、例外的な、簡単なシステム要求の場合を考えてみる。 ほとんど取り組みを必要としないものを複雑にしようとする真の誘惑がある。

“匿名リードオンリ文書サーバー” はCD-ROMイメージを提供するのに十分かも しれないサーバーのタイプか、ネットワーククライアントが使う用途向けの参考 文書を提供する。この設定は “スタンドアロンサーバー”“参照用文書サーバー” でも取り上げている。この設定の目的は、ゲストも含めて誰でもリードオンリで アクセスできる共有ボリュームを提供することである。

2番目の例は、コンピュータ上にインストールされた正しいプリンタードライバーを 持つのと同じくらい長く、誰でも印刷できるプリントサーバーのための最低限の 設定である。これは “スタンドアロンサーバー”, “集中印刷サーバー” で説明されているものと同じである。

次の例は、システム上にアカウントを持つユーザーのみがアクセス可能な、安全な オフィス用ファイル/プリントサーバーである。このサーバーはワークグループの ファイル/プリントサーバーととてもよく似ているが、匿名でアクセスするマシンより はより安全である。このタイプのシステムは、一般的に小さなオフィスの用途に 適合している。サー派はネットワークログオン機能、ドメイン制御を提供しない。 その代わりにネットワーク経由のストレージデバイス(NAS)とプリントサーバーである。

最後の例は存在するMicrosoft Windowsネットワークを統合するか、それを完全に 置き換えるより複雑なシステムである。これらはSambaドメイン制御(PDC/BDC)と 同様なドメインメンバーサーバーとリモートの場所中にあるブランチオフィスでの、 大きな分散ネットワーク中で詳細が説明されるものをカバーする。

動く例

設定の例はSambaが動くために必要なすべてをカバーするためにデザインされている。 それはこのテキストの範囲を明らかに超えている、基本的なOSプラットフォームの 設定をカバーしていない。

また、OSベンダによって提供されているパッケージにか、他の手段で Sambaが正しくインストールされていることも仮定している。

スタンドアロンサーバー

スタンドアロンサーバーであるということは、それがドメインコントローラーでないこと、 ドメイン制御下に参加していないと言う事実以上のことを何も暗示しない。これは 単純で、ワークグループ風のサーバーであるか、ドメインセキュリティ管理下のメンバー であることができる。

例題が作成されている間、真のビジネスオフィスが、そのオフィスの大きさが 増えたり必要に応じて変わるようなことが起こると思うかもしれないのと同じ ように、システムが、そのすばらしい能力に向かって進歩するすべての試みが行 われた。

匿名リードオンリ文書サーバー

このタイプのサーバーの目的は、共有リソース上にある任意の文書やファイルを 任意のユーザーに有効にさせることである。共有リソースはCD-ROMでもファイル 領域でも可能である。

  • ファイルシステムの共有位置は/exportである。

  • すべてのファイルはJack Baumbachと呼ばれるユーザーが所有している。 Jackのログイン名はjackbである。そのパス ワードはm0r3pa1nである。 もちろんこれは例として使っているものである。すべての、この 文書の読者がこのことを知っているため、実環境でこれを使っては いけない。

Procedure 2.1. インストール手順: リードオンリサーバー

Example 2.1. 匿名リードオンリサーバー設定

# グローバルパラメーター
[global]
workgroup = MIDEARTH
netbios name = HOBBIT
security = share
[data]
comment = Data
path = /export
read only = Yes
guest ok = Yes

  1. ユーザーをシステムに登録する(ユーザーのホームディレクトリも作る):

    root# useradd -c "Jack Baumbach" -m -g users -p m0r3pa1n jackb
    

  2. ディレクトリを作りパーミッションと所有者を設定する:

    root# mkdir /export
    root# chmod u+rwx,g+rx,o+rx /export
    root# chown jackb.users /export
    

  3. /exportディレクトリに共有したいファイルをコピーする。

  4. 匿名リードオンリサーバー設定で 表示されているSamba設定ファイル(/etc/samba/smb.conf)を インストールする。

  5. 以下のコマンドを実行して設定ファイルをテストする:

    root# testparm
    

    代替として、smb.conf.masterと呼ばれるマスター 設定ファイルから操作している場合、以下のコマンドシーケンスの方が より適切である:

    root#  cd /etc/samba
    root#  testparm -s smb.conf.master > smb.conf
    root#  testparm
    

    何らかのエラーメッセージが出力されるかもしれないことに注意。 エラー出力がない場合にのみ先に進むこと。上記の設定ファイルで 生成される典型的な出力の例は以下の通り:

    Load smb config files from /etc/samba/smb.conf
    Processing section "[data]"
    Loaded services file OK.
    Server role: ROLE_STANDALONE
    Press enter to see a dump of your service definitions
    [Press enter]
    
    # Global parameters
    [global]
    	workgroup = MIDEARTH
    	netbios name = HOBBIT
    	security = share
    
    [data]
    	comment = Data
    	path = /export
    	read only = Yes
    	guest only = Yes
    

  6. OSプラットフォームに適した方法でSambaを起動する。その方法は プラットフォーム依存である。Sambaを起動することに関するそれ 以上の情報は、Starting Samba を参照のこと。

  7. Microsoft Windowsクライアントをワークグループ MIDEARTHに設定し、コンピュータ名を ROBBINSに設定し再起動し、数分待ち、Windowsエクスプローラー を開いてマイネットワークをクリックする。そこにマシンHOBBIT がある。このマシンアイコンをクリックすると、 data共有が現れる。共有をクリック後、 /exportディレクトリ中にある、以前に そこにおいたファイルが現れる。

上記の情報(#グローバルパラメーター以下)は /etc/samba/smb.confファイルの完全な内容を提供 する。

匿名の読み書き可能な文書サーバー

以前の例からこの設定を発展系と見なすべきである。違いは、共有アクセスが jackbというユーザーIDに、プライマリグループがjackbに強制的に設定されると いうことである。その他1つの改善点は、ユーザーjackbを smbpasswdに追加することが出来るということである。 これを行うのには以下を実行する:

root# smbpasswd -a jackb
New SMB password: m0r3pa1n
Retype new SMB password: m0r3pa1n
Added user jackb.

smbpasswdファイルへのこのユーザーの追加は、エクス プローラのプロパティにおいて所有者がUser Unknown の代わりにjackbが表示されると言うことである。

完全な変更後のsmb.confファイルは“変更後の匿名の読み書き可能な設定の smb.conf”である。

Example 2.2. 変更後の匿名の読み書き可能な設定の smb.conf

# Global parameters
[global]
workgroup = MIDEARTH
netbios name = HOBBIT
security = SHARE
[data]
comment = Data
path = /export
force user = jackb
force group = users
read only = No
guest ok = Yes

匿名プリントサーバー

匿名プリントサーバーは2つの目的で提供される:

  • 1つの所から、すべてのプリンターに印刷を許可する。

  • 制限された数のプリンターに対するアクセスのため、たくさんの ユーザーのためにネットワークのトラフィックの輻輳を減らす。

最も単純な匿名印刷サーバー中で、Windowsワークステーション上での正しい プリンタードライバーのインストール要求は共通である。この場合、プリント サーバーはスプーラに対して印刷ジョブを単に渡すだけに設定され、 スプーラはプリンターに対して素通しになるように設定される。別の言い方 をすると、プリントスプーラはプリンターに対して渡されたデータストリーム をフィルタリングもなんらかの処理もしない。

この設定中で、プリンターの追加ウィザードを使うのは好ましくなく、 また、自動ドライバーダウンロードを行うのも望まない。そのため、 以下の設定でそれを無効にする。 “匿名プリントサーバーのsmb.conf”は結果の smb.confファイルである。

Example 2.3. 匿名プリントサーバーのsmb.conf

# Global parameters
[global]
workgroup = MIDEARTH
netbios name = LUTHIEN
security = share
printcap name = cups
disable spoolss = Yes
show add printer wizard = No
printing = cups
[printers]
comment = All Printers
path = /var/spool/samba
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = No

上記の設定は理想的なものではない。よりよい機能を使っておらず、 故意にエレガントではない解決方法を提示している。しかし、これは 基本であり、これで印刷は出来る。SambaはCUPSによって提供される 直接印刷APIを使える。CUPSライブラリを、Sambaコンパイル時に指定 してリンクした場合、既定値の印刷システムはCUPSになる。princap name がCUPSを指定した場合、Sambaはすべての印刷機能のためにCUPSに直接 通信を行うため、CUPSライブラリAPIを使う。 printingの値をSYSVかBSDに設定して外部印刷 コマンドを強制的に使うことが可能で、パラメーター printcap nameの値はCUPS以外の何かに設定 しなければならない。この場合、Windowsクライアントに対して有効に させるためのプリンターの一覧が含まれている任意のファイルの名前を設定 する。

Note

Windowsユーザーはローカルプリンターのインストールが必要で、ドライバーの インストール後に通常使うプリンターを切り替える。通常使うプリンターは そのマシン上のネットワークプリンターに設定できる。

ディレクトリ/var/spool/sambaが使えるように なっていることを確かめておくこと。以下の手順はこれを達成するため に行わなければならない:

  • ディレクトリはスーパーユーザー(root)のユーザーとグループに属さねば ならない:

    root# chown root.root /var/spool/samba
    

  • ディレクトリのパーミッションは以下のようにスティッキービット を設定して「その他」をRWに設定しなければならない:

    root# chmod a+twrx /var/spool/samba
    

    スティッキービット設定の目的は、一時印刷ファイルを所有していない ユーザーが誤用で制御を得てしまう可能性を防止するためである。

Note

CUPSが有効になっているシステムで、中間のCUPSプリントフィルタ処理なしで、 直接プリンターに生データを渡す機能がある。このモードの操作を使うことが 要求される場合、生データを印刷するデバイスを設定することが必要である。 また、/etc/mime.conv/etc/mime.typesファイル中のraw mime ハンドラーを 有効にする必要もある。“application/octet-streamのためのraw印刷を明示的に有効にする”を参照のこと。

セキュアな読み書き可能ファイルと印刷サーバー

続いて、簡単なシステムからやや複雑なサーバーの例に説明を進めよう。

新しいサーバーは認証されたユーザーのみ(すなわち、ローカルアカウントを持つ)が、 ホームディレクトリと同様にファイルを保存できる共用データ領域を必要とする。 また、誰でも使える1つのプリンターも提供する。

この仮想の環境(このデータを入手するための盗聴は無いものとする)中で、 使うのに難しくない、十分な安全性を持つ簡単な環境に サイトは依存する。

サイトユーザーは Jack Baumbach, Mary Orvilleと Amed Sehkahである。おのおのは パスワード(これ以降の例では表示しない)を持つ。Maryはプリンター管理者で、 共通の共有中のファイルの所有者である。

この設定は既定値であるユーザーレベルのセキュリティを ベースとしていて、/etc/samba/smbpasswd中に Windows互換の暗号化パスワードを格納している。この設定にするための既定値 のsmb.confエントリは passdb backend = smbpasswd, guestである。 これが既定値になっているので、設定ファイルにこれを記述する必要はない。 guest バックエンドはSamba設定ファイル中で指定されるか否かに関わらす、 有効なpassdb backendに追加されることに注意。

Procedure 2.2. セキュアなオフィスサーバーのインストール

Example 2.4. セキュアなオフィスサーバーのsmb.conf

# Global parameters
[global]
workgroup = MIDEARTH
netbios name = OLORIN
printcap name = cups
disable spoolss = Yes
show add printer wizard = No
printing = cups
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[public]
comment = Data
path = /export
force user = maryo
force group = users
read only = No
[printers]
comment = All Printers
path = /var/spool/samba
printer admin = root, maryo
create mask = 0600
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = No

  1. すべてのユーザーをOSに追加する:

    root# useradd -c "Jack Baumbach" -m -g users -p m0r3pa1n jackb
    root# useradd -c "Mary Orville" -m -g users -p secret maryo
    root# useradd -c "Amed Sehkah" -m -g users -p secret ameds
    

  2. “セキュアなオフィスサーバーのsmb.conf”中で示されているようにSambaの smb.confを設定する。

  3. Microsoft Windowsパスワードデータベースに新規ユーザーを追加する:

    root# smbpasswd -a root
    New SMB password: bigsecret
    Reenter smb password: bigsecret
    Added user root.
    
    root# smbpasswd -a jackb
    New SMB password: m0r3pa1n
    Retype new SMB password: m0r3pa1n
    Added user jackb.
    
    root# smbpasswd -a maryo
    New SMB password: secret
    Reenter smb password: secret
    Added user maryo.
    
    root# smbpasswd -a ameds
    New SMB password: mysecret
    Reenter smb password: mysecret
    Added user ameds.
    

  4. CUPS Webインタフェースを使ってプリンターをインストールする。生データを 印刷するデバイスとしてMicrosoft Windowsクライアントで共有するプリンター をインストールするようにすること。

  5. OSの管理インタフェースを使ってSambaを起動する。それは以下の方法でも 手動で可能である:

    root#  nmbd; smbd;
    

    両方のアプリケーションは自動的にdaemonとして動く。daemonモードで開始 することを強制する、パラノイド的な-Dフラグを追加 することも可能である。

  6. /exportディレクトリを設定する:

    root# mkdir /export
    root# chown maryo.users /export
    root# chmod u=rwx,g=rwx,o-rwx /export
    

  7. Sambaが正しく動いているかを調べる:

    root# smbclient -L localhost -U%
    Domain=[MIDEARTH] OS=[UNIX] Server=[Samba-3.0.20]
    
    Sharename      Type      Comment
    ---------      ----      -------
    public         Disk      Data
    IPC$           IPC       IPC Service (Samba-3.0.20)
    ADMIN$         IPC       IPC Service (Samba-3.0.20)
    hplj4          Printer   hplj4
    
    Server               Comment
    ---------            -------
    OLORIN               Samba-3.0.20
    
    Workgroup            Master
    ---------            -------
    MIDEARTH             OLORIN
    

    以下のエラーメッセージはSambaが動作していないことを示している:

    root#  smbclient -L olorin -U%
    Error connecting to 192.168.1.40 (Connection refused)
    Connection to olorin failed
    

  8. ユーザーmaryoでOLORINに接続する:

    root# smbclient //olorin/maryo -Umaryo%secret
    OS=[UNIX] Server=[Samba-3.0.20]
    smb: \> dir
    .                              D        0  Sat Jun 21 10:58:16 2003
    ..                             D        0  Sat Jun 21 10:54:32 2003
    Documents                      D        0  Fri Apr 25 13:23:58 2003
    DOCWORK                        D        0  Sat Jun 14 15:40:34 2003
    OpenOffice.org                 D        0  Fri Apr 25 13:55:16 2003
    .bashrc                        H     1286  Fri Apr 25 13:23:58 2003
    .netscape6                    DH        0  Fri Apr 25 13:55:13 2003
    .mozilla                      DH        0  Wed Mar  5 11:50:50 2003
    .kermrc                        H      164  Fri Apr 25 13:23:58 2003
    .acrobat                      DH        0  Fri Apr 25 15:41:02 2003
    
    		55817 blocks of size 524288. 34725 blocks available
    smb: \> q
    

ここまでのことで、設定の基礎を会得したかと思う。これからはより複雑な 例を見ていく。この節の残りの部分は、いままでの例で説明した手順の部分 は省略する。

ドメインメンバーサーバー

ここでは、経理部門が幸せにできるような、最も簡単なサーバー設定を題材にする。ユーザーは 会計担当で、小難しい要求をしてくることに注意しよう。この部門のために1台のサーバー予算 がある。

ネットワークは社内情報サービスグループ(Information Services Group (ISG))で管理され、そこ に所属しているものとする。内部の製作は典型的な中規模の組織である。いつでもユーザーの追加削 除を行っているという理由でISGを運営しているのがHuman Resources is of the opinion。 また、スタッフのために基本的なネットワークリソースアクセスを得るために、部門の管理者は 死力を尽くして戦わなければならない。けれども経理部門は違い、彼らは正確に彼らがほしい ものを手に入れる。そのため、これは場面を設定すべきである。

ここでは最後の例からのユーザーを使うことにする。経理部門にはその部門のユーザーが使える 汎用プリンターがある。また、小切手を印刷するための権限を持つ人のそばにその人だけが 使える小切手印刷プリンターもある。最高会計責任者(CFO)はオフィス内の個人用収納場所 中に配置して完全にそのプリンターの使用を制限したいと望んでいる。そのため、それは ネットワークプリンターである必要がある。

経理部門は中央のアプリケーションサーバーから動かさなければならない SpytFullという会計アプリケーションを使っている。ソフトウェア は1台のサーバーだけで動かすようにライセンスされていて、底にはワークステーション コンポーネントがなく、マップされた共有で動く。データはUNIXベースのSQLバックエンド にある。UNIXの専門家はそれをみて、それはUNIX屋の問題ではないと言う。

経理部門のマネージャ(maryo)はフォームレター(いやなメール)のために分離したファイル 格納領域と同じような汎用ファイリングシステムを希望している。フォームレター領域は マネージャを除いてすべての経理スタッフにはリードオンリにすべきである。汎用ファイ リングシステムは、経理のチームのメンバーの、その人固有の階層構造ファイル領域を持つ 必要があるが、マネージャにはすべての領域にアクセスできることを希望している。各 ユーザーは、個人に関連したファイルのための固有のホーム領域を持つが、それは部門の 作業に関連しない。

設定例

サーバーvalinorは会社のドメインのメンバーサーバーである。 経理部門はローカルサーバーのみを持つ。ユーザーのアカウントはドメインコント ローラ上にあり、そこにはデスクトッププロファイルとすべてのネットワーク ポリシファイルがある。

Example 2.5. メンバーサーバーのsmb.conf (Globals)

# Global parameters
[global]
workgroup = MIDEARTH
netbios name = VALINOR
security = DOMAIN
printcap name = cups
disable spoolss = Yes
show add printer wizard = No
idmap uid = 15000-20000
idmap gid = 15000-20000
winbind use default domain = Yes
printing = cups

Example 2.6. メンバーサーバーのsmb.conf (Shares and Services)

[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[spytfull]
comment = Accounting Application Only
path = /export/spytfull
valid users = @Accounts
admin users = maryo
read only = Yes
[public]
comment = Data
path = /export/public
read only = No
[printers]
comment = All Printers
path = /var/spool/samba
printer admin = root, maryo
create mask = 0600
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = No

  1. UNIX/Linuxサーバーにユーザーを追加してはならない。すべては中央の ドメインで行う。

  2. メンバーサーバーのsmb.conf (globals)メンバーサーバーのsmb.conf (shares and services)と一致するようにsmb.confを設定する。

  3. ドメインに参加する。注意:このステップが終わるまでSambaを起動してはいけない!

    root# net rpc join -Uroot%'bigsecret'
    Joined domain MIDEARTH.
    

  4. winbindが設定されて動いている任意のシステム上で nscd daemonを停止する(シャットダウンする)ことを必ず行うこと。

  5. OSプラットフォームの通常の方法で、Sambaを起動する。 手動で動かしたい場合は、rootになって以下の手順で起動する:

    root# nmbd; smbd; winbindd;
    

  6. winbind経由でユーザーとグループ名を解決するために、システム上にあるネーム サービススイッチ(NSS)制御ファイルを設定する。 /etc/nsswitch.conf中の以下の行を編集する。

    passwd: files winbind
    group:  files winbind
    hosts:  files dns winbind
    

  7. wbinfoに対するパスワードを以下の方法で設定する:

    root# wbinfo --set-auth-user=root%'bigsecret'
    

  8. ドメインユーザーとグループの認証が以下を実行することで正しく解決されるかを 検証すること:

    root# wbinfo -u
    MIDEARTH\maryo
    MIDEARTH\jackb
    MIDEARTH\ameds
    ...
    MIDEARTH\root
    
    root# wbinfo -g
    MIDEARTH\Domain Users
    MIDEARTH\Domain Admins
    MIDEARTH\Domain Guests
    ...
    MIDEARTH\Accounts
    

  9. winbindが動作しているかをチェックすること。以下は、 getentシステムユーティリティ経由で正しいユーザー名の 解決を行っている例である:

    root# getent passwd maryo
    maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false
    

  10. A final test that we have this under control might be reassuring:

    root# touch /export/a_file
    root# chown maryo /export/a_file
    root# ls -al /export/a_file
    ...
    -rw-r--r--    1 maryo    users       11234 Jun 21 15:32 a_file
    ...
    
    root# rm /export/a_file
    

  11. ここまでで設定はほぼ終わり、この後、このサイト用にディレクトリ 構造を設定する:

    root# mkdir -p /export/{spytfull,public}
    root# chmod ug=rwxS,o=x /export/{spytfull,public}
    root# chown maryo.Accounts /export/{spytfull,public}
    

ドメインコントローラー

この節の残りの部分は、ドメイン制御の設定に焦点を当てる。以下は2つの実装方法の例である。 ここでの例は、簡単に作れるが、ちゃんと動くものを提示するのが目的であることを思い出して ほしい。この本の残りではより大きな機能性とそれに付随する複雑性に注目する機会を手助け するべきである。

ドメインコントローラーの設定は新しいtdbsamパスワードバックエンドを使う簡単な設定 で達成できる。このタイプの設定は小さなオフィスに適しているが、拡張性が制限され ていて(複製が出来ない)、ドメインの大きさと複雑さが増大するとパフォーマンスが 下がることが予想される。

tdbsamの使用は、PDC以外の必要性がないサイトにのみ最適である。ドメインが大きく なると、追加のドメインコントローラーが必要となるのは必定である。Microsoftネット ワーク環境に過小なリソースを提供しようと試みてはいけない;ドメインコントローラーは 基本的な認証サービスを提供する。以下は過小なリソースでのドメインコントロール 環境の症状である:

  • ドメインログオンが断続的に失敗する。

  • ドメインメンバーサーバー上のファイルアクセスが断続的に失敗し、 パーミッション拒否エラーメッセージが出る。

より拡張性のあるドメインコントロール認証バックエンドオプションは、 Microsoft Active DirectoryかLDAPベースのバックエンドを使うことである。 Samba-3はドメインメンバーサーバーとして両方のオプションを提供する。PDC として、Samba-3はActive Directoryで有効な機能の完全な代替を提供でき ない。Samba-3は拡張性のあるLDAPベースの PDC/BDCソリューションを提供 できる。

tdbsam認証バックエンドは、外部手段を除いて、データベースの内容を複製 する機能は提供していない(すなわち、独立したSamba-3のためのSAM複製 手順はない)。

Note

もしも1つ以上のドメインコントローラーが必要ならば、tdbsam認証バックエンドは 使えない。

例: エンジニアリングオフィス

ここで提供するエンジニアリングオフィスのネットワークサーバーは、新しい tdbsamパスワードバックエンドの使い方をデモするように設計されている。 tdbsam機能はSamba-3で取り入れられた。Microsoft Windows NT4で可能な たくさんのユーザーとマシンアカウント制御を提供するように設計された。 小さなネットワーク中で使うのには、これは安全である。

Example 2.7. エンジニアリングオフィスのsmb.conf (globals)

[global]
workgroup = MIDEARTH
netbios name = FRODO
passdb backend = tdbsam
printcap name = cups
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/groupmod -A %u %g
delete user from group script = /usr/sbin/groupmod -R %u %g
add machine script = /usr/sbin/useradd -s /bin/false -d /var/lib/nobody %u
# 注意: 以下は既定値のログオンスクリプトを指定する。
# ユーザー単位のログオンスクリプトは、pdbeditを使って、ユーザーアカウント中で指定できる。
logon script = scripts\logon.bat
# This sets the default profile path. Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
idmap uid = 15000-20000
idmap gid = 15000-20000
printing = cups

Example 2.8. エンジニアリングオフィスのOffice smb.conf (shares and services)

[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
# Printing auto-share (makes printers available thru CUPS)
[printers]
comment = All Printers
path = /var/spool/samba
printer admin = root, maryo
create mask = 0600
guest ok = Yes
printable = Yes
browseable = No
[print$]
comment = Printer Drivers Share
path = /var/lib/samba/drivers
write list = maryo, root
printer admin = maryo, root
# Needed to support domain logons
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
admin users = root, maryo
guest ok = Yes
browseable = No
# For profiles to work, create a user directory under the path
# shown. i.e., mkdir -p /var/lib/samba/profiles/maryo
[Profiles]
comment = Roaming Profile Share
path = /var/lib/samba/profiles
read only = No
profile acls = Yes
# Other resource (share/printer) definitions would follow below.

  1. tdbsamパスワードバックエンドを使う動作するPDCの設定は、 エンジニアリングオフィスのsmb.conf (globals)エンジニアリングオフィスのsmb.conf (shares and services)にある:

  2. OSで提供されているツールを使って、必要に応じUNIXグループを作成する:

    root# groupadd ntadmins
    root# groupadd designers
    root# groupadd engineers
    root# groupadd qateam
    

  3. OSで提供されている適当なツールを使ってシステム上にユーザーアカウントを 作成する。同時にユーザー毎のホームディレクトリを作っておくこと。Samba 環境で使うときに要求されるグループのファイル、ディレクトリ、プリンター のアクセス制御に対し、ユーザーを追加する。

  4. このシェルスクリプトを動かしてNTグループにおのおののUNIXグループを割り当 てる(スクリプトの名前はinitGroups.shとする)。

    #!/bin/bash
    #### Keep this as a shell script for future re-use
    			
    # First assign well known groups
    net groupmap add ntgroup="Domain Admins" unixgroup=ntadmins rid=512 type=d
    net groupmap add ntgroup="Domain Users"  unixgroup=users rid=513 type=
    net groupmap add ntgroup="Domain Guests" unixgroup=nobody rid=514 type=d
    
    # Now for our added Domain Groups
    net groupmap add ntgroup="Designers" unixgroup=designers type=d
    net groupmap add ntgroup="Engineers" unixgroup=engineers type=d
    net groupmap add ntgroup="QA Team"   unixgroup=qateam    type=d
    

  5. [NETLOGON] 共有中で使うための scriptsディレクトリを作成する:

    root# mkdir -p /var/lib/samba/netlogon/scripts
    

    使用するログオンスクリプト(バッチまたはcmdスクリプト)をこの ディレクトリに配置する。

上記の設定で、ファイル共有とプリンター共有を必要に応じて追加しなければ ならない、基本的なPDCシステムが提供される。

大きな組織の場合

この節では、LDAPベースの認証バックエンドを使うSamba-3の設定の簡単な 紹介を行う。このことを行う主旨は、より高次のレベルのスケーラビリティ に適合するのを可能にするための、とても分散した環境と同じように、 PDC/BDCホストを可能にすることを提供することである。

プライマリドメインコントローラー

これは、LDAP認証バックエンドを使うSamba-3 PDCを動かすための 最小限の設定例である。OSが正しく設定されていることを仮定して いる。

Idealx スクリプト(か同等のもの)が、LDAPベースのPOSIXとSambaSamAccount を管理するのに必要である。Idealxスクリプトはサイト Idealxからダウンロードする ことが出来る。また、Sambaのリリースtarファイルから得ることも出来る。 Linuxディストリビューションは、Idealxスクリプトを /usr/share/doc/packages/sambaXXXXXX/examples/LDAP/smbldap-tools ディレクトリにインストールする傾向がある。 Idealxスクリプトバージョンsmbldap-tools-0.9.1は よく動作することが知られている。

Example 2.9. PDC用のLDAPバックエンドを使うsmb.conf

# Global parameters
[global]
workgroup = MIDEARTH
netbios name = FRODO
passdb backend = ldapsam:ldap://localhost
username map = /etc/samba/smbusers
printcap name = cups
add user script = /usr/local/sbin/smbldap-useradd -m '%u'
delete user script = /usr/local/sbin/smbldap-userdel %u
add group script = /usr/local/sbin/smbldap-groupadd -p '%g'
delete group script = /usr/local/sbin/smbldap-groupdel '%g'
add user to group script = /usr/local/sbin/smbldap-groupmod -m '%u' '%g'
delete user from group script = /usr/local/sbin/smbldap-groupmod -x '%u' '%g'
set primary group script = /usr/local/sbin/smbldap-usermod -g '%g' '%u'
add machine script = /usr/local/sbin/smbldap-useradd -w '%u'
logon script = scripts\logon.bat
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
ldap suffix = dc=quenya,dc=org
ldap machine suffix = ou=People
ldap user suffix = ou=People
ldap group suffix = ou=People
ldap idmap suffix = ou=People
ldap admin dn = cn=Manager
ldap ssl = no
ldap passwd sync = Yes
idmap uid = 15000-20000
idmap gid = 15000-20000
printing = cups

  1. Sambaのソース~/examples/LDAP/samba.schema から入手し、/etc/openldap/schema/ ディレクトリにそれをコピーする。

  2. LDAPサーバーを設定する。この例はOpenLDAP 2.1.xに対応している。 The /etc/openldap/slapd.conf file. <title>Example slapd.conf File</title>

    # Note commented out lines have been removed
    include         /etc/openldap/schema/core.schema
    include         /etc/openldap/schema/cosine.schema
    include         /etc/openldap/schema/inetorgperson.schema
    include         /etc/openldap/schema/nis.schema
    include         /etc/openldap/schema/samba.schema
    
    pidfile         /var/run/slapd/slapd.pid
    argsfile        /var/run/slapd/slapd.args
    
    database        bdb
    suffix          "dc=quenya,dc=org"
    rootdn          "cn=Manager,dc=quenya,dc=org"
    rootpw          {SSHA}06qDkonA8hk6W6SSnRzWj0/pBcU3m0/P
    # The password for the above is 'nastyon3'
    
    directory     /var/lib/ldap
    
    index   objectClass     eq
    index cn                      pres,sub,eq
    index sn                      pres,sub,eq
    index uid                     pres,sub,eq
    index displayName             pres,sub,eq
    index uidNumber               eq
    index gidNumber               eq
    index memberUid               eq
    index   sambaSID              eq
    index   sambaPrimaryGroupSID  eq
    index   sambaDomainName       eq
    index   default               sub
    

  3. initdb.ldifファイルを作成する:

    # Organization for SambaXP Demo
    dn: dc=quenya,dc=org
    objectclass: dcObject
    objectclass: organization
    dc: quenya
    o: SambaXP Demo
    description: The SambaXP Demo LDAP Tree
    
    # Organizational Role for Directory Management
    dn: cn=Manager,dc=quenya,dc=org
    objectclass: organizationalRole
    cn: Manager
    description: Directory Manager
    
    # Setting up the container for users
    dn: ou=People, dc=quenya, dc=org
    objectclass: top
    objectclass: organizationalUnit
    ou: People
    
    # Set up an admin handle for People OU
    dn: cn=admin, ou=People, dc=quenya, dc=org
    cn: admin
    objectclass: top
    objectclass: organizationalRole
    objectclass: simpleSecurityObject
    userPassword: {SSHA}0jBHgQ1vp4EDX2rEMMfIudvRMJoGwjVb
    # The password for above is 'mordonL8'
    

  4. LDAPデータベース中に初期データを投入する:

    root# slapadd -v -l initdb.ldif
    

  5. OSにインストールされている方法か適当なツールを使ってLDAP サーバーを起動する。

  6. /usr/local/sbinディレクトリ中にIdealx スクリプトファイルをインストールし、システム設定に合わせて、 smbldap_conf.pmを設定する。

  7. このバックエンドを制御するsmb.confファイルの例は PDC用のLDAPバックエンドを使うsmb.conf にある。必要に応じて追加する。

  8. secrets.tdbファイルにLDAPパスワードを 追加すると、SambaはLDAPデータベースを更新できるようになる:

    root# smbpasswd -w mordonL8
    

  9. 必要に応じてユーザーとグループを追加する。Sambaツールを使った ユーザーとグループの追加は必要に応じて、自動的にLDAPバックエ ンドとOSに追加される。

バックアップドメインコントローラー

“リモートのLDAPを使うBDCのsmb.conf” ではBDCの設定例を示している。smb.conf ファイルがBDC上で必要でないsmbldap-toolsスクリプトを 指定していないことに注意。必要に応じて追加の共有とプリンターを 追加する。

Example 2.10. リモートのLDAPを使うBDCのsmb.conf

# Global parameters
[global]
workgroup = MIDEARTH
netbios name = GANDALF
passdb backend = ldapsam:ldap://frodo.quenya.org
username map = /etc/samba/smbusers
printcap name = cups
logon script = scripts\logon.bat
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 33
preferred master = Yes
domain master = No
ldap suffix = dc=quenya,dc=org
ldap machine suffix = ou=People
ldap user suffix = ou=People
ldap group suffix = ou=People
ldap idmap suffix = ou=People
ldap admin dn = cn=Manager
ldap ssl = no
ldap passwd sync = Yes
idmap uid = 15000-20000
idmap gid = 15000-20000
printing = cups

  1. BDCが固有のLDAPサーバーを持つかどうかを決める。もしもBDCが LDAPサーバーであるならば、以下のsmb.confを示されたように 変更する。既定値の リモートのLDAPを使うBDCのsmb.conf 中の設定は、中央のLDAPサーバーを使う。

  2. “リモートのLDAPを使うBDCのsmb.conf”中にあるようにNETLOGONとPROFILES ディレクトリを設定する。

Part II. サーバー設定の基本

サーバー設定の初めの一歩

SambaはSMBネットワーク内でいろいろなモードで操作することができる。このHOWTOセクションは ネットワークが必要とするサーバーのタイプとして機能するようにSambaを設定する情報を含んでい る。注意深くこのセクションを読んでほしい。

Table of Contents

3. サーバータイプとセキュリティモード
機能と利便性
サーバータイプ
Sambaセキュリティモード
ユーザーレベルのセキュリティ
共有レベルのセキュリティ
ドメインセキュリティモード(ユーザーレベルのセキュリティ)
ADS セキュリティモード(ユーザーレベルのセキュリティ)
サーバーセキュリティ(ユーザーレベルのセキュリティ)
パスワードの検査
共通のエラー
何がSambaをサーバーにするか?
何がSambaをドメインコントローラーにするか?
何がSambaをドメインメンバーにするか?
常時パスワードサーバーへの接続不可
スタンドアロンサーバーはドメインコントローラーに変換された が、ユーザーのアカウントが動作しない
4. ドメイン制御
機能と利便性
シングルサインオンとドメインセキュリティ
ドメイン制御の基礎
ドメインコントローラーの種類
ドメイン制御の準備
ドメイン制御: 設定例
SambaによるADSドメイン制御
ドメインとネットワークログインの設定
ドメインネットワークログオンサービス
セキュリティモードとマスターブラウザー
よくあるエラー
$マシン名中に$を含められない
存在するマシンアカウントがあるためにドメイン参加に失敗する
システムにログオンできない(C000019B)
マシン信頼アカウントがアクセスできない
アカウントが無効
ドメインコントローラーが無効
ドメイン参加後ドメインメンバーワークステーションにログオンできない
5. バックアップドメインコントローラー
機能と利便性
基本的な背景情報について
Microsoft Windows NT4スタイルのドメイン制御
LDAP設定の注意
Active Directoryドメイン制御
ネットワーク上のドメインコントローラーになれる要件
どのようにワークステーションがそのドメインコントローラーを探すか?
バックアップドメインコントローラーの設定
設定例
よくあるエラー
マシンアカウントが満了し続ける
SambaはNT4 PDCのバックアップドメインコントローラーになれるか?
smbpasswdファイルの複製はどうやるか?
これをすべてのLDAPに使えるか?
6. ドメインメンバーシップ
機能と利便性
MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
マシン信頼アカウントの手動作成
NT4サーバーマネージャによるドメインマシンアカウントの管理
マシン信頼アカウントの即時作成
Microsoft Windows ワークステーション又はサーバーをドメインメンバーにする
ドメインメンバーサーバー
Samba-3でNT4形式でのドメインに参加する
これがなぜsecurity = serverよりもすぐれているのか?
Samba ADS ドメインメンバーシップ
smb.confの設定
/etc/krb5.confの設定
コンピュータアカウントの作成
サーバー設定のテスト
smbclientによるテスト
注意
Sambaドメインメンバー間でのユーザーIDマッピング共有
よくあるエラー
マシンをドメインに追加し直すことができない
マシンのドメインへの追加に失敗する
Windows 2003 PDC に参加できない
7. スタンドアロンサーバー
機能と利便性
背景
設定例
参照用文書サーバー
集中印刷サーバー
よくあるエラー
8. Microsoft Windows ネットワーク設定ガイド
機能と利便性
技術的な詳細
TCP/IP設定
ドメインへの参加: Windows 2000/XP Professional
ドメインログオンの設定: Windows 9x/Me
よくあるエラー

Chapter 3. サーバータイプとセキュリティモード

Andrew Tridgell

Samba Team

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

この章では、Sambaで設定可能なサーバーのタイプに関する情報を提供する。Sambaへのマイグレーションか、 単に使いたいと思っているMicrosoft ネットワーク管理者は、Microsoft Windows管理者にわかりやすい 言葉で、Sambaの文脈においてその意味を知りたいはずである。これは、サーバーそれ自身をどのように 設定するかという詳細を得る前に重要なセキュリティモードの機能を定義すると同様に重要であること を意味する。

この章では、Microsoftサーバーとクライアントにどのように関連することと、Sambaのセキュリティモードが できることについての概要を提供する。

しばしば聞かれる質問は、なぜSambaを使うのかである。ほとんどの章は、機能と利便性 に注目した節を含んでいる。情報がこの質問に答える手助けを提供することを希望している。しかし、 我々は公正で合理的であることを望むので、すべての機能がSambaに対して好ましいとは限らないことを 警告する。利便性は競合他社の方にあるかもしれない。

機能と利便性

2人の人が汚れた道を歩いていたとき、1人が突然小さな赤い石を蹴飛ばした。それは 彼のつま先を傷つけ、サンダルに突き刺さった。彼は石を取り去り、苦しみと激怒 のあまりののしった。もう1人は石を見て、これはガーネットだ。これを 貴重な宝石に変えられる。そして、いつの日かこれはプリンセスを非常に幸福に するだろう!

この物語の教訓:2人の人は同じ石に対して2つの非常に異なった観点を持っていた。それと 同じかどうかにかかわらず、Sambaはその石と似ている。正しく扱えばとても優れた宝物に なるが、それに関わる時間を持つことが出来ないことを強いられるならば、それは非常に 不愉快なものになる。

SambaはUNIXサーバーとMicrosoft Windows 3.xクライアントのための相互運用性を提供する ためのプロジェクトとして開始された。それは、ささやかなスタートから大きく成長し、 いまや巨大システムに適合する機能を提供するようになった。しかし若干の問題点も ある。このような節ではその両方について触れる。

そのため、この章で説明されている機能の利点は何であろうか?

  • Samba-3はMicrosoft Windows NT4 ドメインコントローラーを置き換えられる。

  • Samba-3はネイティブのMicrosoft Active Directoryドメインと同じように NT4スタイルのMicrosoft Windows NT4スタイルのドメインとのすぐれた相 互運用性を提供する。

  • Samba-3は完全なNT4スタイルのドメイン間の信頼関係を許可する。

  • SambaはMicrosoft Windows NT4ドメインコントローラーで出来るよりも より柔軟性のある認証機能を許可するセキュリティモードを持っている。

  • Samba-3は複数の同時アクセス可能なアカウントデータベースバックエンドを 使える(暗号化パスワードはWindowsネットワーキングのために固有となる形 式でアカウントデータベース中に格納される)。

  • アカウントデータベースバックエンドは複数の方法で複製され配布される。 これは、Samba-3がMicrosoft Windows NT4よりもより優れた柔軟性を与え、 多くの場合、Microsoft Windows 200xのActive Directory ドメインよりも かなり便利なユーティリティとなる。

サーバータイプ

Microsoftネットワークの管理者はしばしば3つの異なったタイプのサーバーを参照する:

  • ドメインコントローラー

    • Primary Domain Controller (PDC)

    • Backup Domain Controller (BDC)

    • ADS Domain Controller

  • ドメインメンバーサーバー

    • Active Directory Domain Server

    • NT4 Style Domain Domain Server

  • スタンドアロンサーバー

ドメイン制御を扱っている節(ドメイン制御), バックアップのドメイン制御(バックアップドメイン制御),と ドメインメンバーシップ(ドメインメンバーシップ)は 3つのサーバーの役割のためのSambaの設定に言及する適切な情報を提供する。Sambaドメイン セキュリティの実装のための基礎を作るために、それらの章のそれぞれについて、精通 しておくことを強く推奨する。

スタンドアロンサーバーはアカウント管理が独立している。スタンドアロン サーバーとして設定することがサーバーにとって何を意味するかについてのより広い評価を 得るために、スタンドアロンサーバーを参照のこと。

Sambaセキュリティモード

この節では、Sambaのセキュリティモードの機能と目的について説明する。おのおののモードの ためにMicrosoft Windows クライアントを設定する方法と同様におのおののセキュリティモード についてどのようにSambaが実装しているかを正確に理解することは、ユーザーの不満と管理者の 心労をとても減らすだろう。

Microsoft Windows ネットワークはもともとServer Message Block(SMB)プロトコルと 呼ばれていたプロトコルを使っている。1996年あたりから、プロトコルは Common Internet Filesystem(CIFS)プロトコルとしてより知られるようになった。

SMB/CIFSネットワークにおいては、ユーザーレベル共有レベルという2つのセキュリティのみがある。それらをまとめて セキュリティレベルとして参照する。それら2つのセキュリティレベル の実装において、SambaはMicrosoft Windows NT4/200xサーバーでは出来ない柔軟性を提供する。 実際、Sambaは共有レベルのセキュリティを1つの方法で実装しているが、 ユーザーレベルのセキュリティについては4つの方法で実装している。 それらをまとめて、Sambaでのセキュリティレベルの実装を セキュリティモードと呼ぶ。それらは、 share, user, domain, ADSserverモードとして知られている。 それらはこの章で解説されている。

セッションのセットアップ時にクライアントに対してSMBサーバーは動作しているサーバーの セキュリティレベルを伝える。それはシェアレベルとユーザーレベルという2つのオプション である。2つのうちのどちらかをクライアントが受け取り、それは、クライアントがそれ 自身を認証するときに試みる方法に影響する。それはSambaサーバーをセキュリティ化する 方法には直接(たいして)影響しない。これは奇妙に聞こえるが、それはSMBのクライアント/ サーバーアプローチに適合する。SMB中では、すべてはクライアントによって開始され、 制御され、サーバーはクライアントに対して、何が有効で、どのような動作が許可されるか のみを通知できる。

clientという語は、たとえばWindowsワークステーション、Windows サーバー、あるいはその他の平凡なSMBまたはCIFSクライアントアプリケーション(たとえば smbclient)のような、SMB/CIFSサーバーによって提供されるサービスを 使うものすべてのエージェントを参照する。

ユーザーレベルのセキュリティ

それが簡単なため、最初にユーザーレベルのセキュリティを説明する。ユーザーレベルの セキュリティでは、クライアントはプロトコルネゴシエーションを伴って、直接 セッションセットアップ要求を送信する。この要求はユーザー名とパスワードを提供 する。サーバーはそのユーザー名/パスワードペアを受け取るか拒否するかのどちらか を行う。この段階で、サーバーはクライアントが結局接続しようと試みる共有が 何であるかを知るすべはなく、そのため、許可/拒否 について、以下の2つ以外をベースと出来ない:

  1. ユーザー名/パスワード ペア

  2. クライアントマシンの名前

もしもサーバーがユーザー名/パスワードペア認証を許可するならば、クライアントは、 その先パスワード指定なしで(tree connectionを使って) 共有をマウントできることを仮定する。クライアントは、すべてのアクセス権限が 最初のsession setup中で指定したユーザー名/パスワード認証 セットであることを仮定する。

複数のsession setup要求をクライアントが送信することも 可能である。サーバーが返信するとき、そのユーザー名/パスワードペアのための、 認証タグとして使うために、uidを送る。クライアントは この方法で複数の認証コンテキストを操作することが可能である(このことを行う アプリケーションの例としてはWinDDがある)。

Windowsネットワークユーザーアカウント名は大文字小文字に依存しない。すなわち、 アカウント名中の大文字小文字はすべて同一視されると言うことである。また、 大文字小文字の状態は保存されるが、大文字小文字の状態は関係ないということ である。Windows NT 3.10より前のWindowsとLanManagerシステムは、大文字小文字 の状態を保存する必要がない、大文字小文字を無視するパスワードを使っていた。 すべてのWindows NT ファミリシステムはパスワードについて、大文字小文字を保 存し、それを意識するように取り扱う。

設定例

ユーザーレベルのセキュリティを実現する smb.conf の例は以下の通り:

security = user

これはSamba-2.2.xの既定値である。

共有レベルのセキュリティ

共有レベルのセキュリティ中では、クライアント自身の認証はおのおのの共有毎に 分離している。クライアントはおのおのの tree connection要求(共有マウント) と共にパスワードを送るが、この操作で明示的にユーザー名を送らない。クライアント は、おのおのの共有にパスワードが関連づけられ、ユーザーから独立していることを 期待する。これは、Sambaは、ユーザー名がSMBサーバーに明示的に送られないために、 クライアントが使いたいとしているユーザー名をSambaが考えなければならないこと を意味する。たとえばNTのような、いくつかの商用SMBサーバーは共有レベルの セキュリティ中に直接共有とパスワードを関連づけるが、Sambaはいつでも、 共有/パスワードペアではなく、認証に使ったユーザー名/パスワードペアを使う UNIX認証スキームを使う。

Microsoftネットワーキングとの類似点を理解するために、パスワードあり/なし でリードオンリまたはフルアクセスできる共有フォルダーを作成できる、Microsoft Windows 9x/Meについて考えてみる。

多くのクライアントは、サーバーが共有レベルのセキュリティであったとしても、 session setup要求を送る。それらは通常有効なユーザー名を送るがパスワードは 送らない。Sambaは有効なユーザー名リスト中にこのユーザー名を記憶する。クライアント がtree connection要求を次に発行するとき、接続しようとする共有名の名前 (ホームディレクトリに有用)をこのリストに追加もし、smb.confファイル中の userパラメーター中にリストされているユーザーもである。 次にパスワードが、それらの可能なユーザー名に対して順番にチェックされる。 もしも一致したものが見つかれば、クライアントはそのユーザーとして認証される。

使用可能なユーザー名のリストが提供されていない場合、Sambaは、標準のアカウント データベースから、そのユーザーに対して提供されるパスワードとユーザーアカウントを UNIXのシステムコールを使って探し出すことを行う。システムがネームサービススイッチ (NSS)機能を持っていない場合、そのような検索は/etc/passwd データベースを対象として行う。NSSが有効なシステムの場合、検索は、 nsswitch.confファイル中で指定されたライブラリを通じて 行う。ライブラリを指定するそのファイル中のエントリは以下の通り:

passwd: files nis ldap
shadow: files nis ldap
group: files nis ldap

以下の例(実際に使われるようなものではないが)では、検索は、 /etc/passwd/etc/groupに対して 行われ、見つからなければ NISでチェックし、次にLDAPでチェックする。

設定例

共有レベルのセキュリティを設定するsmb.conf パラメーターは以下の通り:

security = share

ドメインセキュリティモード(ユーザーレベルのセキュリティ)

ドメインセキュリティは、すべてのユーザーとグループアカウントを、中央の共有されている アカウントリポジトリに保存するメカニズムを提供する。中央のアカウントリポジトリは ドメイン(セキュリティ)コントローラー間で共有される。ドメインコントローラーとして振る舞う サーバーはドメインに対するセキュリティコンテキストに参加するすべてのマシンに、認証と 確認サービスを提供する。プライマリドメインコントローラー(PDC)はセキュリティアカウント データベースの完全性を管理するための責任を負うサーバーである。バックアップドメイン コントローラー(BDC)はドメインログオンと認証サービスのみを提供する。通常、BDCはPDCが 行うよりもより反応性がよいネットワークログオン要求を提供する。

Sambaがsecurity = domainモードで動作中の時、 Sambaサーバーはドメインセキュリティ信頼アカウント(マシンアカウント)を持ち、ドメイン コントローラーに対してすべての認証要求をパススルーする。別の言い方をすると、この設定は、 実際、それがドメインコントローラーとして振る舞う場合にも、Sambaサーバーをドメインメンバー サーバーにする。ドメインセキュリティに参加するすべてのマシンはセキュリティデータベース 中にマシンアカウントを持たなければならない。

ドメインセキュリティ環境ないで、セキュリティアーキテクチャの基盤は、ユーザーレベルの セキュリティを使う。ドメインメンバーであるマシンは開始時に認証を行わなければならない。 アカウントデータベース内にあるアカウントエントリの一部であるマシンアカウントは、 その名前がマシンのNetBIOS名であり、パスワードはランダムに生成され、ドメインコントローラー と他のマシンの両方に知られている。もしもマシンアカウントがセットアップ中に認証 されなければ、ユーザーは、それが認証できないため、そのマシンを使ってドメインにログオン できない。マシンアカウントはマシン信頼アカウントとして参照される。

ドメインメンバーの設定には以下の3つのパターンがある:

  1. プライマリドメインコントローラー(PDC) - ドメインに1つのみ。

  2. バックアップドメインコントローラー(BDC) - ドメインに複数配置可能。

  3. ドメインメンバーサーバー(DMS) - ドメインに複数配置可能。

それぞれについて別の節で解説する。まずはじめに、もっとも関心のある基本的なDMSの設定について 説明する。

設定例

Sambaをドメインメンバーサーバーとする

この方法はsmb.confファイル中に以下のパラメーターを必要とする:

security = domain
workgroup = MIDEARTH

この方法を動作させるために、SambaサーバーはMicrosoft Windows NTセキュリティドメイン にジョインする必要がある。これは以下の方法で行う:

  1. Microsoft Windows NT ドメインコントローラー上で、サーバーマネージャを つかい、Sambaサーバーのマシンアカウントを追加する。

  2. UNIX/Linuxシステム上で以下を実行する:

    root# net rpc join -U administrator%password

Note

Samba-2.2.4とそれ以降の Samba 2.2.x 系列では、以下を実行することで、Windows NT4スタイル ドメインへの自動ジョインが可能である:

root# smbpasswd -j DOMAIN_NAME -r PDC_NAME \
	 -U Administrator%password

Samba-3では同じことを以下の方法で行う:

root# net rpc join -U Administrator%password

Samba-3ではDOMAIN_NAMEPDC_NAME を指定する必要はないので、smb.confファイルの設定からこれをわかるようにする(訳注:訳があやしい)。

Windowsドメインコントローラーによってアカウントが認証される時に、UIDを割り当てるため、 このモードを使う認証は、おのおののユーザーに対する標準UNIXアカウントがあることを要求 する。このアカウントは、/etc/passwdエントリ中で不正なシェルと して設定するような方法で、Microsoft Windows以外のクライアントによってログオンする ことをブロックすることができる。ユーザーアカウントに対して不正なシェルを割り当てる 最も良い方法は、シェルに/bin/falseを割り当てることである。

ドメインコントローラーは、利便性のために任意の場所に配置できる。BDCを配置する推奨は、 物理ネットワーク毎に配置し、もしもPDCがリモートネットワークセグメントにあるならば、 WINS(詳細はネットワークのブラウジングを参照)を 使うのが基本である。

Sambaサーバー上でWindowsユーザーにUIDを割り当てる別の方法は、 WinbindWinbind: Use of Domain Accountsにある。

ドメインメンバーシップについてのより詳細な情報は Domain Membershipを参照のこと。

ADS セキュリティモード(ユーザーレベルのセキュリティ)

Samba-2.2とSamba-3の両方は、NT4スタイルのRPCベースのセキュリティを使って Active Directoryドメインに参加することが出来る。これは、ドメインがネイティブ モードで動作しているときに可能である。ネイティブモードのActive Directory は完全にNT4スタイルのドメインメンバーを許可する。これは世間一般の考えに反して である。

もしも、Active DirectoryをSamba-3と一緒に使っているとき、ネイティブなAD メンバーとしてジョインできる。なぜそれを望むか?NT互換の認証プロトコルの使用 をセキュリティポリが禁止するかもしれない。Windows2000とそれ以降のすべての マシンはKerberosを使用している。この場合、NT4スタイルのドメインとしての SambaはNT互換の認証データを引き続き要求する。ADメンバーモード中のSambaは、 Kerberosチケットを受け取ることが出来る。

Microsoft WindowsのActive Directoryサービス(ADS)を使うサイトは、以下の 用語の重要性に気づくべきである: native modemixed modeの ADS操作。 The term realmという単語はKerberosベースのセキュリティアーキテクチャ (Microsoft ADSによって使われるような)を説明するのに使われる。

設定例

realm = your.kerberos.REALM
security = ADS

以下のパラメーターを必要としても良い:

password server = your.kerberos.server

この設定オプションの参考情報として、 ドメインメンバーシップSamba ADS ドメインメンバーシップを参照してほしい。

サーバーセキュリティ(ユーザーレベルのセキュリティ)

サーバー席モードはドメインメンバーサーバーとして振る舞うのが出来ない場合に残されている ものである。この機能を使わないことを強く推奨する。サーバーセキュリティモードは 以下のような多数の欠点がある:

  • Microsoft Windows NT4/200xパスワードサーバー上でアカウントロックアウトの可能性。

  • Lack of assurance that the password server is the one specified.

  • リモートでプロファイルを格納するときに特に必要な、Winbindと一緒に動かない。

  • このモードはパスワードサーバーに対して接続をオープンにでき、また長期間それとオープンしたままにできる

  • 突然リモートのパスワードサーバーが停止したときに、不正にSambaサーバーのセキュリティを壊す。

  • このモードでは、Sambaサーバーのために属するドメイン中のパスワードサーバーにセキュリティアカウントがない(訳注:訳が微妙)。

サーバーセキュリティモード中で、Sambaサーバーはクライアントに、ユーザーレベルセキュリティ であることを報告する。クライアントは次に以前に説明したようにsession setupを行う。 Sambaサーバーはユーザー名/パスワードペアをクライアントから得、クライアントから得た ユーザー名/パスワードペアと正確に同じものを送って password serverにログインしようとする。もしもサーバーが ユーザーレベルのセキュリティで動作していて、パスワードを受け入れるならば、Samba はクライアントからの接続を許可する。このパラメーターは password serverとしてSambaサーバーを、別のSMBサーバーを使う ことができるようになる。

どのセキュリティレベルであるかとクライアントに告げるとき、これらすべての開始時に もしも暗号化をサポートしているのであrばそのこともクライアントに告げる。もしも そうであれば、クライアントに対して乱数を使った暗号化キーを送信する。クライアント は暗号化形式ですべてのパスワードを送る。Sambaは既定値でこのタイプの暗号化を サポートする。

パラメーターsecurity = serveruser modeで動いていることをSambaがクライアントに報告する ことを意味するが、実際には別のユーザーモードサーバーに対してすべての認証要求を渡す。 これは、真の認証サーバーを差す追加のpassword server パラメーターを必要とする。真の認証サーバーは別のSambaサーバーでも、Windows NT サーバーでもよく、後者は標準で暗号化パスワードをサポートしている。

Note

server security modeでSambaサーバーが動作しているとき、 パラメーターpassword serverをターゲットの認証サーバーの 正確なNetBIOSマシン名に設定することは必要である。Sambaは、ターゲットの認証 サーバーの選択は任意であり、ドメイン名から決定できないという理由で、NetBIOS 名前検索からこれを決定できない。本質的に、 サーバーセキュリティモードのSambaサーバーはワークグループ モードとして知られているものとして動作している。

設定例

Microsoft Windows NTを認証サーバーとして使う

この方法はsmb.confファイル中に以下のパラメーターを追記することになる:

encrypt passwords = Yes
security = server
password server = "NetBIOS_name_of_a_DC"

ユーザー名/パスワードペアが正しいかどうかを確認する2つの方法がある。 1つは提供された認証メッセージングプロセスの一部としてリプライ情報を使う ことであり、もう1つはエラーコードを使うことである。

このモードの設定の悪い点は、セキュリティの観点でSambaが偽のユーザー名と偽の パスワードをパスワードサーバーに送る可能性があることと、もしもリモートの サーバーが偽のユーザー名と偽のパスワードの認証拒否に失敗すると代替の認証か 承認作業が使われてしまうと言うことである。数回の認証の繰り返し後にサイト がパスワードロックを使う場合、これはユーザーをロックアウトしてしまう。

認証要求でのこのモードの使用はユーザーが標準UNIXアカウントがあることを必要と する。このアカウントは非SMB/CIFSクライアントからのログオンを防止するために ブロックすることが出来る。

パスワードの検査

Microsoft Windows クライアントはチャレンジ/レスポンス認証モデル(NTLMv1と NTLMv2として知られる)の一部としての暗号化パスワードか、単独か、あるいは 単純なパスワードベースの認証のための平文パスワードを使うことが出来る (訳注:aloneがよく分からない)。これはSMBプロトコルで実現され、パスワード は平文または暗号化されてネットワーク経由で渡されるが、同じ認証要求では 両方は使われない。

暗号化パスワードが使われるとき、以下の2つの方法でユーザーが入力した パスワードは暗号化される:

  • unicodeのパスワード文字列をMD4でハッシュ。 これはNTハッシュとして知られているものである。

  • パスワードは大文字化され、14バイトに短縮 される。この文字列に5バイトのNULL文字が追加され、"magic" な8バイト値に暗号化するために、2つの56ビットDESキー形式 に分割される。結果はLanManハッシュという16ビットの値である。

Microsoft Windows 95 サービスパック1より前とWindows NT バージョン3.xとバージョン 4.0のサービスパック3より前では、パスワード認証のどちらかのモードを使う。すべての それより後のMicrosoft Windowsバージョンはもはや既定値で平文パスワードをサポート しない。

Microsoft Windows クライアントは10分またはそれより長くアイドルな時にネットワーク マッピングを切断するという習性がある。切断した、マップされたドライブ接続を 使うためにユーザーが試みるとき、クライアントはキャッシュされたパスワードの コピーを使って再接続する。

Microsoftが既定値のパスワードモードを変更したとき、平文パスワードのキャッシュ サポートをやめた。これは、平文パスワードを使うためにレジストリパラメーターを修正 したときに、それは動くようになるが、もしもリモートの認証サーバーが暗号化パスワード をサポートしないときに、切断されたサービスのマッピングを試みるときに失敗する ことを意味する。そのようなクライアントで平文パスワードを再度有効にすることは 良い考えではないと確かに言える。

以下のパラメーターは、平文テキストでの認証を使うときに、Windows 9x/Meクライアントが 大文字化したユーザー名とパスワードをSMBサーバーに送る前に問題になる時に使うことが できるものである:

既定値では、Sambaはローカルのシステムアカウントデータベース中でユーザー名を検索する前に ユーザー名を小文字に変更する。これは、UNIXユーザー名が慣習的に小文字のみで構成されている ことによるためであり、username-levelパラメーターは滅多に必要と さない。

しかしながら、UNIXシステム上のパスワードはしばしば大文字小文字を混ぜた文字で構成され ている。これは、平文認証を使ってSambaサーバーに接続しようとするWindows 9x/Meクライアント 上でのユーザーのために、password levelが、パスワードに現れること が出来る大文字の最大数を設定しなければならないことを意味する。 もしもサーバーのOSが伝統的なDESバージョンを使うcrypt()を使うならば、 password levelを8に設定することは、結果としてWindowsユーザー にとって、大文字小文字を無視したパスワードとして見える。これはまた、一致するまで (あるいはすべての組み合わせが失敗するまで)1つ1つ、Sambaがパスワード文字列の組み合わせ を試みるために、より長いログイン時間がかかるという結果となる。

最も適用するのによいオプションは、Sambaが使われている所はどこでも、暗号化パスワード をサポートすることを有効にすることである。平文パスワードを使うためにレジストリを 変更する試みは、結局はユーザーの苦情と不便を導くことになるだろう。

共通のエラー

我々はいつでも間違いを犯す。正しい場所で正しい時間と同じくらいの長さで間違いを犯す のは問題ない(訳注:意味がよく取れない)。製品版での重要な障害は重要視されるが、 ラボでの開発バージョンにおいてのバグは期待されるものである。

Sambaメーリングリスト上の議論の題名となる共通の誤解と間違いを見てみよう。 その多くは、Samba実装を試みる前にあなたの宿題としてその多くが回避可能である。 そのいくつかは、英語を母国語としない人にとって、潜在的に曖昧で、とても紛らわしい 多くのフレーズを持つ英文の誤解釈の結果である。

何がSambaをサーバーにするか?

ある人たちにとって、Sambaのセキュリティモードの性質は明白であるが、 それでも完全に間違っている(訳注:意味取れない)。 security = serverはSambaがサーバーとして 動くと言うことを意味していることを仮定している。が、違う。この設定は、 Sambaが、別のSmBサーバーがユーザー認証サーバーだけの提供元として使うことを 試みることを意味している。

Sambaはセキュリティモードが選択されたとしてもサーバーである。Sambaが ドメインセキュリティコンテキストの外で使われた場合、既定値にセキュリティ モードをしておくのが最適である。Samba-3の既定値では、ユーザーモードの セキュリティを使う。

何がSambaをドメインコントローラーにするか?

smb.conf パラメーター security = domainは 実際にSambaをドメインコントローラーとして振る舞わさせるのではない。この設定は Sambaがドメインメンバーになることを期待することを意味する。より詳細については PDCとしてのSambaを参照のこと。

何がSambaをドメインメンバーにするか?

想像してみよう!So many others do. But whatever you do, security = userはSambaをドメインメンバー として振る舞わせることを考えてはいけない。保証期限が切れる前に製造者の マニュアルを読みなさい。より詳細については、 ドメインメンバーシップを参照のこと。

常時パスワードサーバーへの接続不可

なぜ、server_validate()は単に、パスワードサーバーに対する接続を再接続しないで あきらめるのか?私はSMBプロトコルに詳しくはないが、たぶん、クラスターサーバー プロセスはそのクライアントワークステーションの方に、パスワードサーバーから 渡されたセッションキーを渡し、それはクライアントから送信されたパスワード ハッシュが、セッションキーが異なるそのあとの接続で動作しないことを意味する。 (訳注:ちょっと不安)そのため、server_validate()は中断しなければならない。

本当に。それは、なぜ security = server が全くひどいハックである理由である。認証をパススルーすることが分かっている、 security = serverモードである、 security = domainを使ってほしい。

スタンドアロンサーバーはドメインコントローラーに変換された が、ユーザーのアカウントが動作しない

DOMAINに入ろうとしたとき、イベントログに tried credentials DOMAIN/username; effective credentials SERVER/usernameが表示された。

通常これはSambaサーバーがドメインコントローラーとして設定される前にユーザーかマシン アカウントが作成されたことによるものである。サーバーがドメインコントローラーになる まえに作成されたアカウントは、ローカルのアカウントであり、 SERVERドメイン中のメンバーとして見えるものとしてに認証され、Windows 2000とそれ 以降の中のローカルユーザーアカウントとほとんど同じである。Sambaサーバーがドメイン コントローラーになったとに作成されたアカウントは、 ドメイン アカウントであり、DOMAINメンバーのメンバーとして認証される。

これは、pdbedit -L -v usernameコマンドをを発行することによって 確かめられる。もしも、これがDOMAINという結果を出したならば、アカウントはドメイン アカウントであり、もしもSERVERであれば、そのアカウントはローカルアカウントである。

これを解決する最も簡単な方法は、アカウントを削除し再作成することである。しかしながら、 この方法は、ユーザープロファイルの確率に問題を引き起こすかもしれない。 pdbedit -u username -I DOMAINコマンドを使うことも出来る。 ドメインに一致するためにユーザーSIDとプライマリグループSIDを変更する必要がある かもしれない。

Chapter 4. ドメイン制御

John H. Terpstra

Samba Team

Gerald (Jerry) Carter

Samba Team

David Bannon

Samba Team

Guenther Deschner

LDAP updates 

Microsoft Windows のネットワークの世界に考えられないような誤解をしている人が たくさんいる。それは私たちが支援を提供できる機会が増えるということですからそれはそれでいいのだが、 この分野で本当にヘルプを必要とする人は、まず、既に一般向けに出されている情報に親しむことを 推奨する。

ある程度の基本を理解・修得されてからこの章を読み進めることを推奨する。Microsoft Windowsネットワーク では、誤った設定の影響がはっきりと現れる。Microsoft Windows ネットワークのユーザーから、 ネットワーク設定の誤りに起因すると思われる細かなトラブルにしつこく悩まされるという 苦情が出ることがよくある。ところが、多くの人々にとって Microsoft Windowsネットワークの 世界というのはドメインコントローラーを知るところから始まり、それはネットワーク操作の障害を 魔法のように、すべて解決してくれそうに思えるてくるものである。

ドメインの例の図解は典型的な、Microsoft Windows ネットワーク ドメインセキュリティネットワーク環境を図示している。 ワークステーションA、BとCは多くの物理的なMicrosoft Windowsネットワーククライアント を代表していると考えられたい。

Figure 4.1. ドメインの例

ドメインの例

Sambaメーリングリストから、よくあるネットワークに関する問題の多くを容易に特定できる。 もしも以下の話題についてよく分からないのであれば、それについて取り扱っている、 このHOWTO文書の節を読むことを強く勧める。以下は、最も一般的なMicrosoft Windows ネットワークの問題である:

  • 基本的なTCP/IPの設定

  • NetBIOS名の解決方法

  • 認証の設定

  • ユーザーとグループの設定

  • UNIX/Linux上での基本的なファイルとディレクトリのアクセス制御

  • ネットワーク環境中でMicrosoft Windowsクライアントがどのようにやりとりをするかの理解

がっくりする必要はない。Microsoft Windowsのネットワーク機能は、一見、大変シンプルで 誰でもできそうに見える。実際には、適切な研修と準備をしないで Microsoft Windows ネットワーク を設定するのは、あまりよい考えとは言えない。とはいえ、なかなか払拭できない思い込みをちょっと 脇にどけることにしよう。ミスを犯すのもいいことです!時と場合によっては 失敗も教訓となる。しかし、生産性のロスを招き、組織に不可避の財政負担を強いるようなミスを 犯してもよいわけではない。

それでは、ミスを犯してもよい場所とはどこであろうか? それは実害のない場所である。ミスを犯すなら、 テストネットワーク上で、ユーザーから遠く離れた場所で、他の人に苦痛を与えない状況でやってほしい。

機能と利便性

Microsoftドメインセキュリティの最も重要な利便性は何か?

要するに、シングルサインオン、あるいは短く言えばSSO である。これは多くの人にとって、Microsoft Windows NT 以後のネットワーキング における聖杯である。SSOは、ユーザーのユーザーアカウントが存在するドメインの メンバーであるワークステーション(あるいは、アクセスするドメインとの間に適切な 信頼関係があるドメインに属するワークステーション)のいずれからも、ネットワーク にログオンできるという優れた設計を可能にする。ユーザーは、自分のホームの(個人の) ワークステーションの前に座っているかのように、ネットワークにログオンでき、 リソース(共有、ファイル、プリンター)にアクセスできる。これはドメインセキュリティ プロトコルの一つの特長である。

Samba PDCを実装するサイトは、ドメインセキュリティの利便性を享受できる。ドメイン は、固有のネットワーク・セキュリティ識別子(SID)を提供する。ドメインユーザーと グループセキュリティの識別子は、ネットワーク SID に、アカウント毎に一意の 相対識別子(RID)を付け足したものである。ユーザーとグループのSID(ネットワークSID +RID)は、ネットワークリソースに付けられるアクセス制御リスト(ACL)を作成するのに 使用され、組織内のアクセス制御を可能にする。UNIXシステムは、ローカル セキュリティ識別子のみ認識する。

SIDはセキュリティコンテキストを表す。例をあげると、おのおののWindows マシンは固有のSIDを持つローカルマシンのセキュリティコンテキストでの ローカルアカウントを持つ。すべてのドメイン(NT4、ADS、Samba)は ドメインSIDによって定義されるセキュリティドメインセキュリティコン テキストで存在するアカウントを含む。

ドメインメンバーサーバーはドメインSIDとは異なるSIDを持つ。ドメインメンバー サーバーはすべてのドメインユーザーをローカルユーザーとして見なすように 設定できる。SIDは持続的である。標準的なドメインのユーザーSIDは以下の ようなものである:

S-1-5-21-726309263-4128913605-1168186429

すべてのアカウント(ユーザー、グループ、マシン、信頼関係など)はRIDが割り当てられる。 これは、アカウントが作成された時に自動的に行われる。UNIX OSはユーザーとグループ 識別子に別々の名前空間を使う(UIDとGID)が、Windowsは同じ名前空間からRIDを 割り当てる。WindowsユーザーとWindowsグループは同じRIDを持てない。ちょうどUNIX ユーザーrootがUID=0であるように、Windows Administrator は、よく知られたRID=500を持つ。RIDはWindowsドメインRIDに連結され、そのため、 上記のSIDを持つドメインのAdministratorアカウントは下記のユーザーSIDを持つ。

S-1-5-21-726309263-4128913605-1168186429-500

Windowsネットワーク領域中での残りのすべてのアカウントは全体で一意なセキュリティ 識別子を持つ。

Note

Microsoft Windows ドメインセキュリティ環境でのネットワーククライアントは提供される 高度な機能にアクセス出来るためには、ドメインメンバーでなければならない。ドメイン メンバーシップはワークグループ名をドメイン名に設定するだけではない。ワーク ステーションに対する(マシンアカウントと呼ばれる)ドメイン信頼アカウントの作成 が必要である。より詳細については ドメインメンバーシップを参照のこと。

以下の機能はSamba-3リリースで新規に追加された:

  • Samba-3はユーザー、グループとマシンアカウントが格納される時に使われる バックエンドの選択を行う事をサポートしている。複数のパスワードバックエンド を、付加的なデータセット、あるいはフェールオーバーデータセットのどちらでも、 組み合わせて使うことが出来る(訳注:今は使えない)。

    LDAP passdbバックエンドは、拡張性と高いレベルでの信頼性を 提供するという理由で、とても価値のある、アカウントバックエンドが 分散かつ複製が出来るメリットを享受できる。

  • Windows NT4のドメイン信頼関係である。Samba-3はワークステーションと サーバー(マシン)信頼アカウントをサポートする。これは、ネットワークの スケーラビリティと相互運用性をさらに支援する、NT4スタイルのドメイン 間信頼アカウントをサポートする。

  • NetBIOS over TCP/IPなしの操作は、むしろraw SMB over TCP/IPを使うことである。注意: これはMicrosoft active directoryドメインメンバーサーバーとして操作する時にのみ 実行可能である。Sambaドメインコントローラーとして動作する時、NetBIOSの使用は、 ネットワークブラウジングのサポートを提供するために必要である。

  • Samba-3はNetBIOSネームサービス(WINS)、NetBIOS ever TCP/IP(TCPポート139)、 SMB over TCP(TCP port 445)セッションサービスとMicrosoft互換のONC DCE RPCサービス(TCPポート135)を提供する。

  • ドメインにユーザーマネージャ経由でユーザーとグループを管理する機能。 これは、Windows 9x/MeではNexus.exeを使い、 Windows NT4/200x/XPプラットフォームではSRVTOOLS.EXEを使って任意の Microsoft Windows クライアントで行える(訳注:Windows Vista/7では 使えない)。

  • Unicodeの完全な実装。これは、ロケール間での国際化サポートを容易にする。 また、Unicode を完全にサポートしなければならないという理由でSamba-2.2.x がサポートできなかったプロトコルの活用の道を開く。

以下の機能はSamba-3では提供されていない:

  • NT4ドメインコントローラー間でのSAMの複製(すなわちSamba PDCとWindows NT BDCまたはその逆)。 これは、Sambaが、PDCがMicrosoftベースのWindows NT PDCである時にBDCと して動作出来ないことを意味する。Samba-3はWindows PDCとBDCでのアカウント データの複製に参加できない。

  • Windows 2000 Active Directoryドメインコントローラーとして動作する (すなわち、KerberosとActive Directory)。実際の所、Samba-3は 現時点では若干の、実験的なActive Directory ドメイン制御の機能を 有している。Active Directoryドメイン制御は次世代のSambaリリース である、Samba-4で現在開発中の機能である。現時点ではSamba-3ライフ サイクル中でActive Directoryドメイン制御を有効にする計画はない。

  • Windows 200x/XPのMicrosoft管理コンソール(MMC)はSamba-3サーバーの管理に は使えない。この目的にはMicrosoft Windows NT4ドメインサーバーマネージャと Microsoft Windows NT4ドメインユーザーマネージャのみが使える。両者は この後説明するSVRTOOLS.EXEパッケージ中の一部である。

この章の中で説明されている理由により、Windows 9x/Me/XP Homeクライアントは ドメインの真のメンバーになれない。Windows9x/Meスタイルのネットワーク(ドメイン) ログオンプロトコルはNT4/Windows 200xスタイルのドメインログオンとは完全に異なり、 しばらくの間公式にサポートされてきた。これらのクライアントはおおよそ Samba-1.9.15シリーズからサポートされた旧LanManネットワークログイン機能を使う。

Samba-3ではWindows NT グループとUNIXグループ間でのグループマッピングを実装 している(これは、限られたスペースでは説明できないくらい非常に複雑で ある)。これについての詳細については グループマッピング:Microsoft WindowsとUNIX を参照のこと。

Samba-3はMicrosoft Windows NT4 PDCまたはWindows200x Active Directory と同様に、適切なバックエンドデータベースにユーザーとマシン 信頼アカウント情報を格納することを必要とする。これについては、 Microsoft Windows ワークステーション/サーバー マシン信頼アカウント を参照のこと。Samba-3では複数のバックエンドが用意されている。 完全なアカウントデータベースバックエンドについての解説は アカウント情報データベースを参照のこと。

シングルサインオンとドメインセキュリティ

ネットワーク管理者が、Windows NT4とactive directoryネットワークの利点に ついて説明を求められるとき、しばしば言及するのが、シングルサインオン (SSO)を実装しているということである。多くの会社がSSOを実装している。 シングルサインオンソリューション実装のモードは、一般的に、ネットワーク 業務における重要な要因であり、Windowsネットワークに関してとても重要で ある。会社には多くの種類の情報システムがあり、それぞれはユーザー認証と認可 (訳注:authentication and validation)を要求し、そのため、一般的 ではないが、ユーザーは10以上のログインIDとパスワードを記憶する必要が あるかもしれない。この問題は、おのおののシステムのパスワードが 一定期間で更新が必定で、パスワードの複雑さとパスワード履歴が 適用されるときには特に顕著となる。

非常に数多くの情報システムに対するアクセス権限(ユーザー名/パスワードペア) を扱うユーザーの問題に対する回答がSSOであるという認識を包括的に 持っている。多くの巧妙な案が、ユーザーフレンドリーなSSOのソリューション を提供可能にするために考案された。問題は、この導入がうまく終わって いない場合、サイトは複雑さによるたくさんの費用と管理上のオーバーヘッド が起きるかもしれないということである。簡単に言って、多くのSSOソリュー ションは管理上の悪夢である。

SSOを使うことですべてのユーザーアカウント情報を集中管理できる。 環境の複雑さと、SSOを導入したシステムの稼働期間に依存して、 新しいアイデンティティ管理とユーザー認証システムを受け入れること は可能ではないかもしれない。多くのSSOソリューションは、 ユーザーのための認証を処理する新しい上位の構造から成り立つ レガシーシステムを改良する。これは、SSOの追加は全体的な情報 システムの複雑さを増大することを意味する。理想的には、SSOの 導入は複雑さの低減と管理オーバーヘッドの削減をすべきである。

たくさんのネットワーク管理の最初のゴールは、しばしば集中管理した アイデンティティ管理システムを作り、使うことである。これは、 そのような集中化したシステムは、すべての情報システムによって 使うことが出来る単一の認証基盤を使うことをしばしば仮定している。 Microsoft Windows NT4セキュリティドメインアーキテクチャとMicrosoft Active Directoryサービスは、そのようなシステムに対しての理想的な 基盤としてしばしば提供される。ユーザーの認証とアクセス制御のために Microsoft(NT4ドメインかadsサービス)を使うことが出来る単一の 認証基盤を使う、そのような集中化したシステムがしばしば仮定される。 単一の集中化した認証サービスのすばらしい幻想は一般的に、現実を 理解するときに一般的に壊れている。レガシーシステムを使うときの問題 は、その導入がリエンジニアリングの観点から、過度に侵略的になるか、 アプリケーションソフトが、設計されて実装されたユーザー認証の特定の 要素に依存して組み込まれているという理由により、認証とアクセス制御 を具体化する能力がしばしばないということである。

これまでの10年間、産業が、レガシー名情報テクノロジーシステムの 制限の鍵となる点を回避するために作られた、いろいろな方法が開発 されてきた。しばしば使われるその1つの方法はメタディレクトリを 使うことである。メタディレクトリには、それぞれのシステムに固有な 形式で、すべての異なる情報システムのためにユーザー認証情報を保存 する。単一のユーザー認証情報を使うすべてのシステムのために、新しい 基盤がユーザーアクセスを可能にさせることが提供されるシステムの 迷宮の中で、ユーザー権限と権利(rights and privileges)を管理する ための厳格に実施されるワークフロープロトコルに、管理手続き の巧妙なセットが結合される。

Organization for the Advancement of Structured Information Standards (OASIS) は、認証情報の通信のための構造化情報であるSecurity Assertion Markup Language (SAML) を開発している。SAMLを配置するための全体的な技術と手法の包括的名称(訳注:umbrella name)は Federated Identity Management (FIM)と呼ばれる。FIMはそれぞれのユーザーを認証 するための異なった情報システムの複雑な迷宮中で、かつおのおのが提供するサービス の安全なアクセスを請け負うために、おのおののシステムに依存する。

SAML文書はWebサービスのために必要なコンピュータ間通信のための Simple Object Access Protocol (SOAP)メッセージ中に包むことが出来る。 あるいは、ライブサービスを共有する集合化したWebサービス間で渡される かもしれない。リバティ・アライアンスは、SAML1.1をアプリケーション フレームワークとして適用した、連携型アイデンティティ標準 (訳注:federated-identity standards)を普及させるために作られた コンソーシアム(訳注:industry group)である。MicrosoftとIBMは WS-Securityと呼ばれる別の方式を提案していた。ある人は、競合して いる技術と手法がSAML 2.0標準が世に出るときにまとまるのではないか と信じていた。現在ではごく少数のWebアクセス管理製品のみがSAMLを サポートしているが、技術の実装は、アプリケーション統合のための カスタマイズとユーザーインタフェースの開発のために、主に必要と される。要するに、それがなぜFIMが大木つて成長している産業である かの理由である。

この本の向こうの範囲の大きな絵を無視し、集中したシステムへのすべての ユーザーとグループのマイグレーション管理は、正しい方向への第一歩である。 Microsoft Active Directoryサービス(ADS)やその他のプロプライエティな ものか、general security service application programming interface (GSSAPI)サービスによって定義されているプロトコルを使う数々の認証 メカニズム(kerberosのような)の柔軟な組み合わせができる情報アクセス (LDAPのような)のための、標準プロトコルを提供するオープンソースシステム のような、ディレクトリ中にアイデンティティ管理システムデータを位置づける のは、相互運用性のための基本である。

ますます多くの会社がLDAPシステムを使うことを許可するための異なったレガシー プラットフォームのために認証エージェントを提供する。OpenLDAPの使用で、 LDAP標準のオープンソース実装が支配的である。実際、LDAPとMicrosoft ADSを使うためにSambaで提供することは、Sambaが、高度な拡張性と Sambaは、組織のネットワーク技術に届くように前進することを意味する。

Microsoft ADSは、集中化した認証基盤を提供するために拡張できる、 制限付きの完全に商用なサービスを提供する。SambaとLDAPは、集中化した 認証基盤の拡張のための同様な機会を提供するが、実際、Sambaチームは、 LDAPあるいは他のものを使って、認証サービスの拡張の導入中で、 、持続可能な選択とFIMマーケットプレイス中での競合をより多く作成する、 ntlm_authユーティリティのような完全なツールを SQUID(OSSのプロキシサーバー)のようなアプリケーションのために 先を見越している。

もしも、プライマリドメインコントロールが大きなサイトに適合した拡張性 があれば、LDAPを使うことが出来るに違いない。それを使うためのすばやい OpenLDAPとSambaの設定は、ディレクトリの時代が始まったことの十分な 証明である。Samba-3はLDAPの使用を要求しないが、分散可能なユーザーと グループのイデンティティ情報のメカニズムのための要求は、それを不可避の 選択としている。

この時点で、SambaベースのBDCの使用は、LDAPアクセスありの使用を必要と する。最も一般的な、Sambaサイトによって使われるLDAP実装はOpenLDAP である。標準準拠の任意のLDAPサーバーを使うことも可能である。それらは、 IBM、CA、Novell(e-Directory)とその他で知られている。

ドメイン制御の基礎

長年の間に、ドメイン管理に関する一般の理解はほとんど神話の世界になってきた。 ドメイン制御についての基本を概観する前に、 ドメインコントローラーの3つのタイプについて説明する。

ドメインコントローラーの種類

  • NT4スタイルプライマリドメインコントローラー

  • NT4スタイルバックアップドメインコントローラー

  • ADSドメインコントローラー

プライマリドメインコントローラーあるいはPDCはMicrosoft Windows NTで重要な役割を演じる。Windows 200xドメインアーキテクチャ中では この役割はドメインコントローラーが担う。Microsoft Windowsネットワークにおける ドメインコントローラーの役割は、ドメインコントローラーがネットワークの中で 最も強力で最も能力のあるマシンでなければならないことを示す、ということになって いる。ところが、おかしなことを言うと思われるかも知れないが、ネットワークの 全体的な性能を高めるためには、インフラストラクチャー全体がバランスのとれた ものでなければならない。ドメインコントローラーよりもスタンドアロン (ドメインメンバー)サーバーに投資する方が賢明である。

Microsoft Windows NT4スタイルドメインの場合、新しいドメイン制御データベースを 初期化するのはPDCである。これにより、Security Account Manager (SAM)と呼ばれる Windowsレジストリの一部分が形成される。これは、NT4スタイルのドメインユーザーの認証と BDCのドメイン認証データベースとの同期で鍵となる役割を果たす。

Microsoft Windows 200xサーバーベースのActive Directoryドメインでは、一つのドメイン コントローラーが、複数のドメイン・コントローラーの階層関係を初期化し、一つ一つの コントローラーが管理権限を代行する領域を与えられる。 マスタードメインコントローラーは下位のいずれかのドメインコントローラーの 決定を上書きする能力を持っているが、下位のコントローラーはその下位の コントローラーのみ制御する。Samba-3では、この機能はLDAPベースのユーザーとマシン アカウントバックエンドを使うことで実現できる。

Samba-3では、新たにNT4スタイルのSAMデータベース(レジストリファイルの1つ)と 同じタイプのデータを保持するバックエンドデータベースを使う機能が入った。 [1]

バックアップドメインコントローラーまたはBDCはネットワーク 認証リクエストの処理に重要な役割を演じる。BDCはPDCに優先してログオン要求に答える ようになっている。BDCとPDCの両方があるネットワークセグメント上では、 ネットワークログオン要求はおおむねBDCが処理する。PDCはBDCが高負荷 (ロードアベレージが大きい)ときにログオン要求に応える。ユーザーがWindows ドメインメンバークライアントにログオンした時、ワークステーションは最も近い ネットワークログオンサーバーを探すために、ネットワークに問い合わせを 行う。WINSサーバーが使われている時は、WINSサーバーへの問い合わせ で行われる。もしもネットログオンサーバーがWINS問い合わせでは見つからないか、 WINSサーバーがない場合、ワークステーションはUDPブロードキャストプロトコル 上でmailslotブロードキャスト経由でNetBIOS名前検索を実行する。これは、 Windowsクライアントが使うことが出来るネットログオンサーバーがたくさんの 変数によって影響され、それゆえ、PDCまたはBDCが特定のログオン認証要求 を処理する単純な決定要素はない。

Windows NT4 BDCはPDCに昇格することが出来る。BDCがPDCに昇格する時にPDC がオンラインならば、以前のPDCは自動的にBDCに降格する。Samba-3では これは自動的には行われない。PDCとBDCは手動で設定し、その他適切な 変更を行う必要がある。

Microsoft Windows NT4では、インストール時に、サーバーのマシンタイプが 何になるかを決める。BDCからPDCへの昇格やその逆も 可能である。Windows NT4ドメインコントローラーからドメインメンバーサーバー かスタンドアロンサーバーへの変換のためにMicrosoftが提供している唯一の 手法は、再インストールである。インストール時に提供されている選択肢 は以下の通り:

  • プライマリドメインコントローラー ドメインSAMを生成するサーバー。

  • バックアップドメインコントローラー ドメインSAMのコピーを受け取るサーバー。

  • ドメインメンバーサーバー ドメインSAMのコピーを持たない。すべてのアクセス制御についてドメインコントローラーから認証を受け取るサーバー。

  • スタンドアロンサーバー SAM同期を行わず、固有の認証データベースを持ち、ドメインセキュリティでは何の役割も担わないサーバー。

Note

Algin Technology LLC はWindows NT4スタンドアロンサーバーをPDCまたはBDCに昇格 することとその逆ができるが可能な商用ツールを提供している。さらなる情報は AlginのWebサイトを参照 のこと。

Samba-3サーバーはsmb.confファイルに簡単な変更をすることで、ドメイン コントローラーへ、あるいはドメインコントローラーから容易に変換できる。 Samba-3はWindows200xサーバーのActive Directoryドメインでのネイティブ なメンバーとして完全に振る舞える。

完全な図を提供するために、Microsoft Windows 2000 ドメイン制御の設定は サーバーがインストールされた後に行われる。ドメインメンバーサーバーへの変換、 あるいはドメイン制御からの変換を行うための手順と、Active Directory サービスのサポートのインストール、あるいはActive Directoryから抜ける ための方法については、Microsoftの資料を参照してほしい。

Samba-3での新機能として、SAM複製コンポーネントを除く、Microsoft Windows NT4スタイルのドメインコントローラー機能の実装が上げられる。しかし、Samba-3 はMicrosoft Windows 200xドメイン制御プロトコルについてもサポートすることも 注目してほしい。

現時点で、Samba-3はネイティブADSモード中でのドメインコントローラー として機能することが出来るように見えるが、これは限定的で実験的なもの でしかない。この機能はSambaチームがそれに対する公式のサポートを提供する まで使うべきでない。その時期になれば、すべての設定上・管理上の要件を 正当に反映するためにドキュメント類は改訂されるだろう。SambaはWindows 2000/XP環境中 ではNT4スタイルのドメインコントローラーとして振る舞うことが出来る。しかし、 以下のように一定の短所(訳注:未実装の機能)がある:

  • マシンポリシーファイルがない

  • グループポリシーオブジェクトがない。

  • 同期して実行されるActive Directoryログオンスクリプトがない。

  • ユーザーとマシンを管理するためのActive directory管理ツールが使えない。

  • レジストリの変更でメインのレジストリに恒久的な変更が残るが、Active Directoryを使うときには、結果が残らない。

  • Active Directoryなしでは、特定のアプリケーションを特定のユーザーとグループにエクスポートできない。

ドメイン制御の準備

Microsoft Windows のマシンが、お互いに他のサーバーやドメインコントローラー とやりとりするのには2つの方法がある:そのうちの1つは、一般的に ワークグループメンバーとして呼ばれている スタンドアロンシステムであり、もう1つは、 一般的にドメインメンバーと呼ばれている、 セキュリティシステム中で全面的に参加するものである。

ワークグループのメンバーであるために、特別な設定は必要ないということに注意してほ しい。ただ、ネットワーク設定に、ワークグループのエントリーについて共通に使う 単一の名前を持つようにマシンを設定するだけである。この時WORKGROUPという名前を使 うのが一般的である。この設定モードでは、マシン信頼アカウントはなく、メンバーシッ プの概念は、すべてのマシンがネットワーク環境の中で、論理的に一緒のグループに まとめられているという以上のものではない。繰り返すが、明確言うと、 ワークグループモードは、セキュリティの確保されたマシンアカウントを含まない

ドメインメンバーのマシンは、ドメインアカウントデータベース中にマシン信頼 アカウントを持つ。ドメインメンバーシップを有効にするには、おのおののマシン上で 以下の特別な手続きが必要である。この手続きは、ローカルマシンのAdministrator アカウントによってのみ行うことが出来、これにより、ドメインマシンアカウント(もしも 存在しなければ)を作成し、そのアカウントを初期化する。クライアントが 最初にドメインにログオンすると、それがマシンアカウントのパスワード変更処理 のトリガとなり自動的に起動される。

Note

Sambaがドメインコントローラーとして設定されるとき、セキュアなネットワーク操作は Microsoft Windows NT4/200x/XP Professionalクライアントがすべてドメインメンバー として設定されることを要求する。もしもマシンがドメインのメンバーでなければ、 それはワークグループ(スタンドアロン)マシンとして操作される。ドメインメンバーシップ に関係する情報は ドメインメンバーシップ を参照してほしい。

以下はMicrosoft Windows NT4/200x/XPクライアントのための、Microsoft Windows NT4スタイルとしてSamba-3を設定するために必要な手順である:

  • 基本的なTCP/IPとMicrosoft Windows ネットワークの設定。

  • 正しいサーバーの役割の指定(security = user)。

  • 一貫性のある名前解決の設定。[2]

  • Windows NT4/200x/XP Professionalクライアントのためのドメインログオン。

  • 移動プロファイルの設定か、明示的にローカルプロファイルを強制使用する設定。

  • network/systemポリシーの設定。

  • ドメインユーザーアカウントの追加と管理。

  • Microsoft Windows NT4/2000 ProfessionalとWindows XP Professionalクライアントマシンがドメインメンバーになるような設定。

以下の準備はMicrosoft 9x/Meクライアントに機能を提供するために必要な手順である:

  • 基本的なTCP/IPとMicrosoft Windowsネットワークの設定。

  • 正しいサーバーの役割の指定(security = user)。

  • ネットワークログイン設定(Windows 9x/Me/XP Homeは技術的にドメインメンバーに なれないため、ドメインログオンにおけるセキュリティ面には実際には参加しない)。

  • 移動プロファイルの設定

  • システムポリシーの取り扱いの設定。

  • Microsoft Windowsネットワーク用のクライアントネットワークドライバーのインストール とドメインにログオンするための設定。

  • もしもすべてのクライアント共有アクセスがドメインユーザー/グループ識別子に従って制御され ることが望ましいならば、Windows 9x/Meクライアントをユーザーレベルのセキュリティに設定 。

  • ドメインユーザーアカウントの追加と管理。

Note

移動プロファイルとシステム/ネットワークポリシーは、高度なネットワーク管理の話題で、 このドキュメントの デスクトッププロファイル管理システムとアカウントポリシーで触れられている。 しかしながら、それらはWindows NT ネットワーク のコンセプトに関連するので、必ずしもSamba PDCに固有の説明ではない。

ドメインコントローラーはSMB/CIFSサーバーであって以下を行う:

  • 自分自身をドメインコントローラーとして登録し、公告する(NetBIOSブロードキャストに 加え、UDPブロードキャスト上でのMailslotブロードキャスト、WINSサーバーへのUDPユニキャスト、 DNSとActive Directory経由での名前登録によって)。

  • NETLOGON サービスの提供(これは実際、複数のプロトコル上で動くサービスの集合体である。 それらにはLanManログオンサービス、Netlogonサービス、ローカルセキュリティアカウント サービスとそれらのバリエーションを含む。)。

  • NETLOGONという共有が提供される。

それらを提供するためにSambaを設定することはむしろ容易である。おのおののSamba ドメインコントローラーは Sambaがdomain logons機能(smb.conf ファイル中のパラメーターから取って)と呼ぶNETLOGONサービスを提供しなければな らない。さらに、Samba-3ドメイン中の1つのサーバーはドメインマスターブラウザーとして それ自身を公告しなければならない。[3]これにより、与えられた ドメインまたはワークグループにDMB識別されるようなドメイン固有のNetBIOS名 をPDCが取得することになる。ブロードキャストで分離されたサブネットの、同じドメイン またはワークグループ上の複数のローカルマスターブラウザー(LMB)は、WAN全体の ブラウズリストの完全なコピーのために問い合わせを行う。 ブラウザークライアントは次にそれらのLMBに接続し、ブロードキャストで分離 されたサブネットのためのリストだけではなく、ドメイン全体のブラウズリストを受け取る。

ドメイン制御: 設定例

Samba PDCを作成するための作業の第一歩はsmb.conf中で必要なパラメーターの 理解である。PDCとして機能するためのsmb.confの例は以下の PDC用のsmb.confの例である。

Example 4.1. PDC用のsmb.confの例

[global]
passdb backend = tdbsam
os level = 33
preferred master = auto
domain master = yes
local master = yes
security = user
domain logons = yes
logon path = \\%N\profiles\%U
logon drive = H:
logon home = \\homeserver\%U\winprofile
logon script = logon.cmd
[netlogon]
path = /var/lib/samba/netlogon
read only = yes
[profiles]
path = /var/lib/samba/profiles
read only = no
create mask = 0600
directory mask = 0700

上記の例中で示される基本的なオプションの説明は以下の通り:

passdb backend

ここにすべてのユーザーとグループアカウント情報が含まれている。PDCで使える値は: smbpasswd, tdbsamとldapsamである。guest エントリは既定値のアカウントを提供し、それは既定値で含まれている;明示的に 追加する必要はない。

BDCを使う場合、passdb backendを配信するために論理的な唯一の選択肢は LDAPを使うことである。tdbsamとsmbpasswdファイルは効果的に配信できないため、それを 使うべきではない。

ドメイン管理パラメーター

パラメーターos level, preferred master, domain master, security, encrypt passwordsdomain logonsはドメイン 管理とネットワークログオンのサポートを確実にするために中心的な役割を演じる。

os levelは32以上にし、user モードセキュリティ、Microsoft互換の暗号化パスワードサポート、 ネットワークログオンサービス(ドメインログオン)を提供するように 設定しなければ ならない。暗号化パスワードは有効にしなければならない。 この設定についての詳細は、 アカウント情報データベースを参照のこと。

環境パラメーター

パラメーターlogon path, logon home, logon drivelogon script は環境サポートの設定で、クライアントログオン操作機能を支援し、ネットワーク管理の 間接費用を軽減するための、自動コントロール機能の提供するものである。 それらのパラメーターに関しては、マニュアルページの情報を参照してほしい。

NETLOGON共有

NETLOGON共有はドメインログオンとドメインメンバーシップサポートで中心的な役割を演じる。 この共有はすべてのMicrosoftドメインコントローラー上で提供される。これは、ログオン処理のために 必要となるかもしれない他の共通ツールを見つけるのと同じように、ログオンスクリプト の提供と、グループポリシーファイル(NTConfig.POL)の格納のために使われる。これは、 ドメインコントローラー上で不可欠な共有である。

PROFILE共有

この共有はユーザーのデスクトッププロファイルを格納するために使われる。各ユーザー はディレクトリのrootにこの共有を持たねばならない。このディレクトリはユーザーが 書き込み可能で、グローバルに読み込み可能でなければならない。Samba-3は fake_permissionsと呼ばれる、この共有上にインストール可能な VFSモジュールを用意している。これはSambaの管理者が、全員に対してこのディレクトリを 読み込みのみにすることを許可する。もちろん、これはプロファイルが適した形で作成された 後に行ってこそ有用である。

Note

上記のパラメーターが、サーバーの動作モードを決めるパラメーターの一式であると思って良い。 smb.confパラメーターのうち必須のものを以下に列挙する:

netbios name = BELERIAND
workgroup = MIDEARTH
domain logons = Yes
domain master = Yes
security = User

この節中にある、長いリスト中で示されている追加のパラメーターは、より完全な 説明のためのものである。

SambaによるADSドメイン制御

Samba-3はActive Directoryサーバーとしては機能しない。真のActive Directoryの PDCとして機能することもできない。いくつかのActive Directoryドメインコントローラーの機能用の プロトコルが実験的なものとして部分的に実装されてはいる。しかし、Samba-3がそれらのプロ トコルをサポートするとは思わないでほしい。現在または将来にわたって、そのような 任意の機能に依存しないでほしい。Sambaチームは将来これらの機能を取り除いたり 機能を変更するかもしれない。このことをここに言及するのは、これらの秘密の機能を すでに発見し、この機能が完成されるのはいつかという質問を寄せられた方々のためである。 その答えは、「出来るかもしれないし出来ないかもしれない!」である。

たしかに、Samba-3はMicrosoft Windows NT4スタイルのドメインコントローラーが持つ 大部分の機能を提供するように設計されている。Samba-3にはWindows NT4の全ての 機能があるわけではないが、一方Windows NT4 ドメインコントローラーにはない 多くのの特徴を持っている。要するに、Samba-3はNT4でもWindows Server 200xでもない。 もちろんActive Directoryサーバーでもない。この言い方で全ての人に簡単にシンプルに 理解していただけると期待している。

ドメインとネットワークログインの設定

ネットワークとドメインのログオンについて、ここで言及するのは、ドメインコントローラー が提供する本質的な機能の欠かせない部分だからである。

ドメインネットワークログオンサービス

すべてのドメインコントローラーはネットログオンサービスを動かさなければ ならない(Samba中でのドメインログオン)。 1つのドメインコントローラーが domain master = Yes(PDC)と設定 しなければならない;すべてのBDCではパラメーターを domain master = Noと設定しなければならない。

設定例

Example 4.2. PDCにするためのsmb.conf

[global]
domain logons = Yes
domain master = (PDCならYes, BDCならNo)
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = Yes
browseable = No

Windows XP Home Editionにおける特別な例

次のことを完全に理解してほしい:Microsoft Windows XP Home Editionを Microsoft Windows NT4またはActive Directoryドメインセキュリティに統合したいと思っても それが出来ない。これを解決する唯一のオプションは、Microsoft Windows XP Home EditionからMicrosoft Windows XP Professional への アップグレードを購入することである。

Note

Microsoft Windows XP Home Editionはどのようなタイプのドメインセキュリティ 機能に参加する能力は持っていない。Microsoft Windows 9x/Meと異なり、 Microsoft Windows XP Home Edition はネットワークにログオンする機能を 完全に欠いている。

このことは前にも説明したが、この事について、Sambaチームの誰かに 質問を問い合わせたり、メーリングリストに質問を投げないでほしい。なぜなら 「出来ないから」である。それが出来るとなると、それはMicrosoftとの間のライセンス に違反することになるので、それをしないことを推奨する。

Windows 9x/Meにおける特別な例

ドメインとワークグループはネットワークブラウジングという言葉において 全く同等である。2つの違いは、ネットワークへの安全なログインのための、 分散認証データベースはドメインに関連づけられることである。 また、ドメインログオンサーバーに対して認証が成功したユーザーに対して 異なるアクセス権を付与できる。Samba-3はこの機能をMicrosoft Windows NT/200xと同じ方法で行う。

ドメインへのログオンするSMBクライアントは、ドメイン内のすべての他のサーバーが 同じ認証情報を受け取ることを期待している。ドメインとワークグループ のネットワークブラウズ機能は同一であり、この文書内の、ブラウジングに関する節 の中で説明される。ブラウジングはログインサポートとは直交する(互いに他方への影響 を考慮する必要のない)概念であることに留意してほしい。

シングルログオン(訳注:シングルサインオンか?)ネットワークモデルに関連する課題は この節で扱う。Sambaはドメインログオン、ネットワークログオンスクリプト、 ユーザープロファイルを、この節で扱う、Microsoft Windows for Workgrops とMicrosoft Windows 9x/Meクライアントに対してサポートする。

ドメイン中のSMBクライアントがログオンしようとした時、ログオンサーバーを探す 要求をブロードキャストする。最初にリプライするものが処理を行い、Samba 管理者がインストールした何らかの機構を使ってパスワードを認証する。 サーバー間でユーザーデータベースが共有されていないドメイン(つまり、サーバーが、本質 的にはワークグループサーバーでありながら、しかも自分はドメインに参加している と他に周知するようなドメイン)を作成することも可能である(お勧めはしないが)。 これは認証機構がドメインとはかなり異なるものでありながら、ドメインと密接に関係して いるということを示している。

これらの機能を使うことで、Sambaサーバー経由でクライアントのログオンの確認 させることができる。すなわち、ネットワークにログオンした時にクライアント側でバッチファイルを実行させ、 クライアントの個人設定、デスクトップおよびスタートメニューをダウンロードさせる。

Microsoft Windows XP Home edition はドメインに参加できず、ドメインログオン の使用が許可されない。

設定手続きの話に入る前に、Windows 9x/Meクライアントがログオンをどのように 実行するかを見ておくことにしよう:

  1. クライアントは(それがいるサブネットのIPブロードキャストアドレスに 対して)NetLogon要求をブロードキャストする。これは、NetBIOSレイヤ でのNetBIOS名 DOMAIN<1C> に送られる。クライアントは、最初に受け取った回答を選ぶ。 その回答には\\SERVERという形式で、ログオンサーバーのNetBIOS 名を含む。1Cという 名前はドメインコントローラー(netlogonサービスを提供するSMB/CIFSサーバー) によって登録された名前のタイプである。

  2. クライアントがそのサーバーに接続し、ログオンし(SMBsessetupXを実行) し、次にIPC$共有に接続する(SMBtconXを使って)。

  3. クライアントは、ユーザーのログオンスクリプト名を検索する NetWkstaUserLogon要求を送る。

  4. クライアントは次にNetLogon共有に接続し、そのスクリプトを検索する。 もしも見つかり、読み出しできるならば、クライアントはそれを取り出し 実行する。その後、クライアントはNetLogon共有の接続を切る。

  5. クライアントは、サーバーにNetUserGetInfo要求を送り、プロファイル検索の ために使うユーザーのホーム共有を検索する。NetUserGetInfo要求の 応答はユーザーのホーム共有以外のものは含まれていないので、Windows 9x用のプロファイルは ユーザーのホームディレクトリ内になければならない。

  6. クライアントはユーザーのプロファイルを検索するために ホーム共有に接続する。その時、共有名とパスでユーザーのホーム共有を指定する こともできる。例をあげると、\\server\fred\.winprofile である。もしもプロファイルが見つかれば、それを適用する。

  7. クライアントは次にユーザーのホーム共有を切断し、NetLogon共有に再接続し、 ポリシーファイルCONFIG.POLを探す。もしも見つかれば、 それを読み、適用する。

PDCとWindows 9x/Me ログオンサーバー設定の主要な違いは以下の通り:

  • Windows 9x/Me ログオンサーバーでは、パスワード暗号化は不要である。しかし、 Microsoft Windows 98 以降、既定値では平文パスワードサポートが無効化され ていることに注意。システムとアカウントポリシー で記述されているレジストリの変更で再度有効に出来る。

  • Windows 9x/Me クライアントはマシン信頼アカウントを必要とせず、かつ使わない。

Samba PDCは Windows 9x/Meログオンサーバーとしてどうさする。すなわち、 Windows 9x/Meが期待するネットワークログオンサービスを提供するということである。

Note

平文パスワードの使用は避けることを強く推奨する。それを使うと、 ネットワークトラフィックを解析するネットワークようなツールを使うことで、 容易にパスワードを検出できてしまうからである。

セキュリティモードとマスターブラウザー

わかりにくい点が残らないように、最後に幾つかコメントを記述する。 userモード以外でのセキュリティモードの時に、Sambaをドメインコントローラーと して設定してもよいかについては、さまざまな議論があった。技術的な理由で うまくいかないセキュリティモードは、share モードのセキュリティのみである。 domainモードとserver モードのセキュリティは、実際にはSMBのuserレベルの セキュリティの変形のようなものである。

この問題は、Samba がドメインコントローラーとして機能しているときに、 そのワークグループのドメインマスターブラウザーでなければならないかという 議論と密接に関連している。 純粋なMicrosoft Windows NTドメイン中では、PDCはDMBになるために選択に勝ち、 次に、DOMAIN<1B>というNetBIOS名を登録する。これはWindowsクライアントが DOMAIN<1C>名を探すためにネットワークログオンサーバー見つけるときに使う 名前である。DMBはドメインマスターブラウザーである。 ネットワークブラウジングの章WORKGROUPブラウジングの設定を参照のこと。 この問題も議論に密接に結びついている。 Microsoft PDC はDMBになるためにelectionに勝つことを期待するが、もしも 勝てない場合、electionはDMBになるためのelectionに負けたという内容を Windowsイベントロガー(訳注:イベントビューワ?)に、警告メッセージを 短い間隔で連続して出力する。この理由のため、SambaサーバーがPDCである ネットワーク中では、SambaドメインコントローラーをDMBとして設定するのが 賢いやり方である。

Note

DOMAIN<1C>名を登録するSMB/CIFSサーバーは、ネットワークログオン サービスを提供するのでそのように処理する。DOMAIN<1B>名を 登録するサーバーはDMBであるすなわち、DOMAIN<1D>名 を登録されたすべてのマシンを含んでのブラウズリスト同期の責任を 持つと言うことである。後者は、存在しているローカルネットワーク セグメントで、すべてのNetBIOS名の登録監視に責任があるLMBである。 ネットワークログオンサービス(NETLOGON)はドメイン制御に関連して いているが、ネットワークブラウジングとブラウズリスト管理には関係 していない。1Cと1B/1Dの名前サービスはお互いに無関係である。

security = user以外のモードで Sambaドメインコントローラーを使うための設定の問題に戻ろう。 ユーザーからの接続要求を検証するためにSambaホストが他のSMBサーバーかドメイン コントローラーを使うように設定した場合、ネットワーク上の他のマシン (password server)は、Sambaホストよりもより 詳しくユーザーについて知っているという状況になる。99%のケースで、 この別のホストはドメインコントローラーである。ドメインモードセキュリティ で動作している場合、workgroupパラメーター は(すでにドメインコントローラーが持っている)Windows NTドメインの名前に 設定しれなければならない。もしもそのドメインがドメインコントローラー をまだ持っていない場合、ドメイン自体がないのと同じである。

すでに定義上PDCを持つドメイン用にSambaサーバーをドメインコントローラーとして 設定することは問題を発生させる。それゆえ、そのドメインに対してDMBになるようにと security = userを設定するようにSamba ドメインコントローラーをいつでも設定すべきである。この方法のみが公式にサポート される操作モードである。

よくあるエラー

$マシン名中に$を含められない

通常/etc/passwdに格納されるマシンアカウントは、マシン名に $を追加した形である。いくつかのBSDシステムはユーザー名 に$を使うものが作成できない。最近のFreeBSDのバージョンはこの 制限が取り払われたが、それより古いものはまだ使われている。

問題はエントリを作る時に使われるプログラム中のみである。一度作成されると 問題なく動作する。まず$なしでユーザー名を作る。次に、エントリを 編集するために vipwを使い$を追加する。 あるいは、最初からエントリをvipwで作っても良い。その際には固有のユーザーログインIDを使うように すること。

Note

マシンアカウントはワークステーションが持つ名前と同じ名前でなければならない。

Note

UNIXのツールvipwは直接/etc/passwdを修正 する共通的なツールである。vipwを使うと(もしも使われているならば)shadowファイルが パスワードファイルと同じになることを保証する。これはセキュリティの観点から重要 である。

存在するマシンアカウントがあるためにドメイン参加に失敗する

I get told,マシン信頼アカウント作成時に `You already have a connection to the Domain....' (既にドメインへの接続があります。) か `Cannot join domain, the credentials supplied conflict with an existing set...' (ドメインに参加できません。信用情報が既存のものと一致しません) が出ることについては以前に話した。

これは、そのマシン自身からマシン信頼アカウントの作成を使用としたとき、 Samba PDC上の共有(かIPC$)にすでに接続している(つまりマップされたドライブ) がある時に起きる。以下のコマンドはすべてのネットワークドライブ接続を切断する:

C:\> net use * /d

これはすべてのネットワーク接続を切る。

さらに、もしもマシンがすでに参加済みのドメインと同じ名前の workgroupのメンバーならば(これはやってはいけない)、このメッセージが出る。 ワークグループを何か別の名前に変えて再起動し、 もう一度やってみる。

システムにログオンできない(C000019B)

ドメイン参加に成功したが、Sambaのバージョンを新しくした後、ログオン時に `The system cannot log you on (C000019B). Please try again or consult your system administrator (システムはあなたのログオンを許可できません(C000019B)。後ほど再試行するか、システム管理者に相談してログオンしてください) というメッセージが出た。'

これはsecrets.tdbに格納されているドメインSIDが変わったことによって引き 起こされるものである。ドメインSIDが変わるよくある理由は、ドメイン名 かサーバー名(NetBIOS名)が変わったことである。問題を解決する唯一の方法は オリジナルのドメインSIDに戻すか、クライアントをいったんドメインから 削除して再参加することである。ドメインSIDは、netまたはrpcclient ユーティリティによってリセットすることも出来る。

ドメインSIDをリセットしたり、変更するには、以下のようにnetコマンドを 使用する:

root# net getlocalsid 'OLDNAME'
root# net setlocalsid 'SID'

ワークステーションのマシン信頼アカウントはドメイン(またはネットワーク) SIDでのみ動作する。このSIDが変更されると、ドメイン メンバー(ワークステーション)はドメインにログオンできない。オリジナルの ドメインSIDはsecrets.tdbファイルから復元できる。別の解は、おのおのの ワークステーションが再度ドメインに参加することである。

マシン信頼アカウントがアクセスできない

ドメインに参加しようとした時 "The machine account for this computer either does not exist or is not accessible (このコンピューターのマシン・アカウントは存在しないか、アクセスできません) ." というメッセージが出た。何が悪い?

この問題は、PDCが適切なマシン信頼アカウントを持っていないことに起因 する。アカウント作成時に add machine scriptという方法を使った場合、 このメッセージは、アカウント作成に失敗したことを示している。ドメイン管理ユーザー のシステムが 動作しているかを確認して正常動作するようにすること。

かわりに、手動でアカウントエントリを作成していた場合、正しく作られていない ということである。Samba PDC上でsmbpasswdファイル 中のマシン信頼アカウントのエントリが正しく出来たかどうかを確認する。もしも、 smbpasswd ユーティリティを使わないでアカウントをエディターで追加した場合、 アカウント名をマシンのNetBIOS名に$を追加して(すなわち、 computer_name$)おくこと。これはSambaSAMAccountバックエンドと同じように POSIX UNIXシステムアカウントバックエンドの両方の中に存在する必要がある。 Samba-3の既定値のバックエンド(すなわち、パラメーター passdb backend)はsmb.confファイル中で指定されて おらず、また、もしも指定されているものがsmbpasswd だった場合、それらはそれぞれ/etc/passwd/etc/samba/smbpasswd(あるいはもしもSambaチームの 既定値の設定を使ってコンパイルした場合は /usr/local/samba/lib/private/smbpasswd)である。 /etc/passwdの使用はNSS /etc/nsswitch.conf ファイル中の別の設定で上書きすることが出来る。

SambaサーバーとNTクライアントの間のサブネットマスクの不一致により、この問題が起こると いう報告も一部から上がっている。クライアントとサーバー両方で整合性 を取るようにすること。

アカウントが無効

NT4/W200xワークステーションからSambaドメインにログオンしようとした とき、アカウントが無効になっているメッセージが出た。

smbpasswd -e usernameでユーザーアカウントを有効化する 。これは通常アカウント作成時に行われる。

ドメインコントローラーが無効

Sambaが開始してから数分間、クライアントがエラー`Domain Controller Unavailable' (ドメイン・コントローラーが使えません。)を表示する。

ドメインコントローラーはネットワーク上にその役割をアナウンスする。これは通常しばらくかかる。最低15分は待ち、 再度試してみること。

ドメイン参加後ドメインメンバーワークステーションにログオンできない

ドメイン参加成功後、2つのメッセージのうちの1つが出てユーザーログオンに失敗する: 1つはドメインコントローラーが見つからないというもので、もう1つはアカウントが ドメインにないか、パスワードが違うというものである。これは、schannel (セキュアchannel)の設定か、smb 署名の設定について、 WindowsクライアントとSamba-3サーバーにおいて設定の不一致によるものと考えられる。 以下を実行して、Sambaの client schannelserver schannelclient signingserver signingの設定と それらの値について確認すること:

testparm -v | grep channel

また、MMC ローカルセキュリティの設定を使うこと。このツールはコントロール パネルにある。ポリシーの設定は、ローカルポリシー/セキュリティオプション領域にあり、 Secure Channel:..., and Digitally sign...(セキュリティチャネル、 デジタル的に署名) という言葉を含んだ項目で設定する。

これらが Samba-3 サーバー設定と一致した設定になっていることが大切である。

Chapter 5. バックアップドメインコントローラー

John H. Terpstra

Samba Team

Volker Lendecke

Guenther Deschner

LDAP updates 

このセクションを読み始める前に、ドメイン制御 中で説明されているSambaドメインコントローラーの設定に問題がないようにして おくこと。

機能と利便性

この章は、説明するのが最も困難な章の一つである。何を書いても、誰かがまだ 実現できていない項目、あるいはまったく異なるアプローチを使った方が遥かに 効果的に実現できる項目について、実現されたはずだと期待してSambaチームに 問い合わせてくることを防止することはできないと思われる。もしこの章で説明 されているはずなのに、いくら読んでも言及されない事項というのがある場合は、 要件あるいは質問内容を明確に書いて John H. Terpstra まで電子メールで問い合わせてほしい。

Samba-3 は別のSambaプライマリドメインコントローラー(PDC)に対するバックアップ ドメインコントローラー(BDC)として機能することができる。Samba-3 PDCは、LDAP アカウントバックエンドとともに運用することができる。LDAPバックエンドは、 共用のマスターLDAPサーバーかスレーブサーバーのどちらでも使える。スレーブLDAPサーバー を使用する利点は、マスターがダウンしている時でもクライアントがネットワークに ログオンできるということである。これによりSambaが高いレベルの拡張性を持つ ことになり、大規模な組織のための効果的なソリューションとなり得る。PDCにLDAP スレーブサーバーを使用する場合、マスターの継続的な可用性を確保する必要がある。 悪い時にスレーブ側から見てマスターがダウンしていると、安定性の問題や運用上の 問題となる。

Samba-3 BDCをLDAPでないバックエンドとともに運用することも可能だが、 バックエンドが何らかの形で「双方向の」伝達を許容し、BDC側からマスター への変更が可能であるようにしなければならない。現段階でこれをできるのは LDAPのみである。PDCが、そのプライマリとしてLDAPマスターサーバーを使うことが 好ましい間、BDCはスレーブLDAPサーバーを使うことが出来る。

LDAPでないバックエンドSAMデータベースを使用するのは問題に陥りやすくなる。 なぜなら、ドメインメンバーサーバーもワークステーションも、マシン信頼アカウントの パスワードを定期的に変更するからである。新しいバスワードはローカルでしか保存 されない。このことは、(LDAPベースのソリューションにあるような)集中的に格納 されたアカウントデータベースが無く、Samba-3 がBDCとして動作しているとき、 BDC 側のドメインメンバー信頼アカウントのパスワードの記録が、PDC(マスター)のSAM のコピーに届かないことを意味する。もし、PDCのSAMがBDC側に複製されると、 最新の(変更後の)信頼アカウントのパスワードを含むSAMが上書きされることになり、 ドメイン信頼が無効になってしまう。

BDCの設定方法に関して挙げられたコメントや質問の数が多いので、可能な選択肢の 一つ一つについて、おのおのの解について利点欠点を見てみよう。 以下のドメインバックエンドアカウント分散オプション一覧 は、PDC/BDC構成で設定可能な設定例の一覧である。

Table 5.1. 分散ドメインバックエンドアカウントの選択肢

PDCバックエンドBDCバックエンド補足事項

マスターLDAPサーバー

スレーブLDAPサーバー

高い整合性を提供する完全なソリューション。SAMは共通マスターLDAPサーバーで 複製される。

単一の集中LDAPサーバー

単一の集中LDAPサーバー

フェイルオーバー機能がないが実用可能なソリューション。これは実用的なソリューションで あるが、完全ではない。

tdbsam

tdbsam + net rpc vampire

Samba-3.0では動かない。Sambaはサーバーサイドプロトコル要求を実装していない。

tdbsam

tdbsam + rsync

この設定を使ってはいけない。TDBファイルが使用中の状態でデータがディスクに 完全に書き戻されていないかもしれないので、動作しない。 さらに、ドメインの信頼関係を壊すだろう。

smbpasswd file

smbpasswd file

この設定を使ってはいけない。 同期が遅延するためにエレガントな解ではなく、ドメイン信頼関係 の問題で悩むだろう。


基本的な背景情報について

ドメインコントローラーは、ネットワーク上のワークステーションからのログオン 要求に答えることが出来るマシンである。Microsoft LanManagerとIBM LanServer はこの機能を提供していた初期のプロダクトの2つである。その技術は、LanMan NetLogonサービスとして知られるようになった。

Microsoft Windows NT3.10 の最初のリリースで、新しいドメイン制御形式が サポートされ、同時に機能を拡張した新しい形のネットワークログオンサービスが サポートされることになった。このサービスは、NT NetLogon サービスとして知ら れている。このサービスの性質は、 Microsoft Windows NT の進化に伴って変更され、 今日では洗練された各種技術の上に広範で複雑な各種サービスを実現している。

Microsoft Windows NT4スタイルのドメイン制御

NT4/200x/XP Professionalワークステーションにユーザーがログオンするときは いつでも、ワークステーションはユーザーが入力したユーザー名/パスワードペア が正しいかを検証するためにドメインコントローラー(認証サーバー)に接続する。 もしも入力された情報がドメイン制御データベース(SAM、すなわちセキュリティ アカウントマネージャデータベース)に格納されているアカウント情報と 一致しない場合、認証要求を出したワークステーションに一連のエラー コードを返す。

ユーザー名/パスワードペアが検証されたとき、ドメインコントローラー(認証サーバー) はそのドメインに対するユーザーとマシンアカウントデータベース中の、そのユーザー に関係するアカウント情報の完全な項目一覧を返す。この情報はそのユーザーに対する 完全なネットワークアクセスプロファイルを含むが、ユーザーのデスクトッププロファイル に特有の情報は含まないか、あるいはそれに関して、ユーザーが属してもよいグループ のためのすべてのデスクトッププロファイルも含まれない。また、それには、 パスワード満了時間、パスワードの一意性制御情報、ネットワークアクセス時間制限 情報、アカウント検証情報、ユーザーがアクセスできるネットワークからのマシン名 や空にその他の情報が含まれている。すべての情報はMicrosoft Windows NT(3.10, 3.50, 3.51, 4.0)バージョン中のSAM中に格納される。

ドメインコントローラー上のアカウント情報(ユーザーとマシン)は2つのファイルに格納 される。そのうちの1つにはセキュリティ情報を含み、もう1つはSAMである。それらは %SystemRoot%\System32\configディレクトリ中に同名の ファイルに格納される。これは通常C:\WinNT\System32\config に変換される。ネットワーク上にBDCがあるとき、この2つのファイルがSAMデータベース の複製に関与するファイルである。

BDCをインストールすることが好ましい状況が2つある:

  • PDCがあるローカルネットワーク上で、たくさんのワークステーション がある場合、あるいはPDCが常時高負荷な場合。この場合、BDCはネットワーク上 のログオン要求を拾って、ネットワークサービスの堅牢性を向上する一助となる。

  • 各リモートサイトで、広域ネットワークの転送量を減らすためとリモート ネットワーク操作の安定性を向上したい場合。ネットワークのデザイン、戦略的な BDCの配置、及びネットワークのできるだけ多くの部分をクライアント側のやり取りに 使用するような実装を組み合わせることにより、WANのバンド幅のニーズを最小化する (従ってコストも最小化する)ことができる。

真のWindows NT4環境中でのPDCとBDCのやりとりについてここで触れておく。PDCは SAMのマスターコピーを持っている。管理者がPDCの持つローカルネットワーク上に物理的に 存在するユーザーアカウントデータベースに変更を加えると、この変更内容は、SAMの マスターコピーのPDC上の記録に直接行われる。 このような情報更新が別のオフィスで行われると、この変更内容はローカルBDC 上の差分ファイルに格納される。BDCはその後SAM同期を行うプロセスを開始するために、 PDCに対してトリガを送る。PDCは当該ドメインの全BDCに接続し、全BDCが更新情報を入手し、 それぞれのSAMのコピーに最新の情報を反映させるようにトリガを出す。

Samba-3は真のSAM複製に参加できないので、Microsoft Windows NT4で 使われているのと同じプロトコルを使用することが出来ない。 Samba-3 BDCはSAM更新差分ファイルを作成できない。BDCが持っている差分 ファイルからSAMの同期をとるために、PDC(NT4またはSamba)間とやりとりもしない。

Samba-3 はMicrosoft Windows NT4 BDCとしては動作できず、Samba-3は Microsoft Windows NT4 BDCに対するPDCとして正しく動作できない。 Samba-3とMicrosoft Windows NT4はそれぞれのタイプのPDCへのBDCとして 機能することは出来る。

BDCはネットワークログオン要求とユーザー認証が出来るので、 読み出し専用のSAMを保持していると言える。 BDCはこのサービスを提供し続けることができる。特に、PDCへのWANの リンクがダウンしている場合などに有効である。BDCは、ドメインの セキュリティとネットワークの整合性の維持に大変重要な役割を果たす。

NT4のPDCを稼働停止しなければならない場合や故障した場合、NT4 のBDCの 一つをPDCに昇格することができる。このようなことを NT4 PDCがオンライン 中に行うと、NT4 PDCは自動的に NT4 BDCに降格する。これはドメインコントローラー の管理の中で特に重要な一面である。昇格および降格を実行するのに使用される ツールはドメインサーバーマネジャーである。ここで注意しなければならない ことは、Samba-3 の BDCは同様の方法で格上げすることはできないということである。 これは、そのような Samba の再設定を行うにはsmb.confファイルの変更が必要に なるからである。作業は、smb.confファイルの手動での変更と、Sambaネットワーク サービスに関連するものの再起動をおこなうだけでよい。

PDCの設定例

バージョン2.2の最初からSambaは公式に、Windows NT4、2003とXP Professional を含む現行Windowsクライアントすべてでドメインログオン機能を公式にサポート している。PDCを有効にしたSambaではsmb.conf中の[global] セクション内にいくつかのパラメーターを設定しなければならない。最低限 必要な設定の例はBDCと共に使う、PDC上にLDAP サーバーがあるPDCのための最低限のsmb.conf の節 を参照のこと。

Example 5.1. BDCと共に使う、PDC上にLDAPサーバーがあるPDCのための最低限のsmb.conf

workgroup = MIDEARTH
passdb backend = ldapsam://localhost:389
domain master = yes
domain logons = yes
ldap suffix = dc=quenya,dc=org
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=sambadmin,dc=quenya,dc=org

[homes][netlogon] 共有などの項目や、プロファイルパス、ユーザーのホームドライブや その他を設定するための設定も一緒に行う必要がある。それらはこの章では 触れない。詳細な情報については、ドメイン制御 を参照のこと。PDC設定のための特定の推奨パターンは ドメイン制御の章を参照のこと。また別に、 地域の、あるいはオンライン書店から入手できるSamba-3 by Exampleという 書籍(book) 中にOpenLDAPとSambaのネットワーク動作設定例が完全に記述されている。

LDAP設定の注意

マスターとスレーブLDAPサーバーを設定する時、マスターLDPサーバーをPDCに、スレーブLDAPサーバー をBDCで使うことが推奨される。スレーブLDAPサーバーを使うことは不可欠ではないが、 サービスの冗長性を提供するために多くの管理者はそのことを好んでいる。もちろん、 1つ以上のBDCがどののスレーブLDAPサーバーを使ってもかまわない。また、 ネットワーク全体で1つのLDAPサーバーを使うことも可能である。

スレーブLDAPサーバーサーバーを持つマスターLDAPサーバーを設定する時、このことを /etc/openldap/slapd.confファイル中に設定する ことを忘れないように。サーバー証明書のDNは、サーバーの名づけるためにCN属性を 使わなければならず、CNはサーバーの完全に的確性のあるドメイン名を含んでいなければ ならないことに注意。証明書の subjectAltNameエクステンション中に追加の別名や ワイルドカードを持っていても構わない。サーバー証明書についてのより詳細 な情報はRFC2830を参照のこと。

この文書の範囲内にはうまく一致しないが、LDAPをインストールすることは、LDAPを 有効にしているSamba操作の基本である。トランスポートレイヤのセキュリティ (TLS)を有効にしてOpenLDAPを使う場合、/etc/ssl/certs/slapd.pem 中のマシン名は/etc/openldap/sldap.confと同じものである 必要がある。Red Hat Linuxスタートアップスクリプトはホスト名として、 localhost.localdomainとしたslapd.pem ファイルを生成する。これだと、正しいホスト名で証明書が再作成されない限り、 スレーブLDAPサーバー(すなわちSamba BDC)からLDAPサーバーにアクセスできない。

LDAPスレーブサーバーを使うようにSamba PDCをインストールしてはいけない。ドメインへ クライアントマシンを参加する時、LDAPデータベース中へのマシンアカウントの変更がマスター LDAPサーバー上で行わなければならないという理由で、この設定ではうまくいかない。 PDCが出した問い合わせがスレーブサーバーに複製されるまで時間がかかりすぎる。そのため、 クライアントマシン上で、アカウントの証明書がセットアップできないというエラー メッセージが出る。LDAPサーバー上でマシンアカウントが作成されるが、パスワード欄は空となる。 残念なことに、いくつかのサイトはこのような設定を防げず、そのため、それらのサイトでは、 複製に追いつくために、Sambaの処理を十分に遅くするための、 ldap replication sleepパラメーターを検討すべきである。 これは、その場しのぎの解決方法であり、管理者が何らかのスクリプト(たとえば、 add machine scriptのようなもの)を使って手動で複製 しなければならない。

PDC/BDCとLDAPを使う、設定可能なパターンは以下の通り:

  • PDC+BDC -> 1つの集中LDAPサーバー。

  • PDC -> LDAP マスターサーバー、 BDC -> LDAPスレーブサーバー。

  • PDC -> LDAPマスター、第二のスレーブLDAPサーバーあり。

    BDC -> LDAPマスター、第二のスレーブLDAPサーバーあり。

  • PDC -> マスター、第二のスレーブLDAPサーバーあり。

    BDC -> スレーブ、第二のスレーブサーバーあり。

(セカンダリ)LDAPサーバーサーバーを持つためには、 smb.confに記述する複数LDAPサーバーの例 のように指定する。

Example 5.2. smb.confに記述する複数LDAPサーバー

passdb backend = ldapsam:"ldap://master.quenya.org ldap://slave.quenya.org"

Active Directoryドメイン制御

Microsoft Windows 2000とActive Directoryのリリース以降、この情報は 複製可能で、管理コントロールの部分的あるいは全体を複製できるディレクトリ 中に格納される。Samba-3はActive Directory内でドメインコントローラー にはなれず、また、Active Directoryサーバーにもなれない。このことは、Samba-3 はActive DirectoryドメインコントローラーのBDCとなりえないことを意味する。

ネットワーク上のドメインコントローラーになれる要件

ドメインMIDEARTH用のドメインコントローラーであるすべてのマシンは、 WINSサーバーかローカルネットワークに対するブロードキャストを使って NetBIOSグループ名MIDEARTH<1C>を登録しなければならない。 またPDCはWINSサーバーで一意のNetBIOS名MIDEARTH<1B>を登録する。 名前タイプ<1B>はドメインマスターブラウザー(DMB)のために通常予約ていて、 認証には通常何ら関係ないが、Microsoft ドメインの導入時はDMBがPDCと同じマシンであることが用件となる。

WINSサーバーを使っていないとき、名前登録はブロードキャストするだけで 十分なはずである。ネットワークブラウジングDiscussionに、TCP/IPネットワーク プロトコル関連と、どのようにSMB/CIFS名を取り扱うかについてのより詳細な 情報があるので参照すること。

どのようにワークステーションがそのドメインコントローラーを探すか?

ドメインコントローラーを見つけるメカニズムは2つある:1つは NetBIOS over TCP/IPが有効なときに使われ、もう1つはTCP/IPネットワーク設定 で無効になっているときに使われるものである。

NetBIOS over TCP/IPが無効になっているとき、すべての名前解決は、 Active Directory通信技術のような、DNS、UDP上のブロードキャストを使う。 このタイプの環境では、すべてのマシンが適切なDNSエントリを持つことが必要である。 より詳細な情報はDNSとActive Directory を参照のこと。

NetBIOS Over TCP/IPが有効

ドメインMIDEARTH内のMicrosoft Windows NT4/200x/XP Professional ワークステーションがローカルユーザーを認証させたい場合、 MIDEARTHのドメインコントローラーを見つける必要がある。これは、グループ名 MIDEARTH<1C>に対するNetBIOS名前解決を行うことによって行われる。 ワークステーションは、問い合わせに返事を返すマシンの1つ1つがドメインコントローラーで あり、ログイン要求に答えることが出来ることを仮定している。セキュリティ ホールを造らないために、ワークステーションと選択されたドメインコントローラー はおのおのを認証する。その後、ワークステーションはユーザーの認証情報( ユーザー名/パスワードペア)を認証のためにローカルのドメインコントローラーに 送る。

NetBIOS Over TCP/IPが無効

realm quenya.org中の Microsoft Windows NT4/200x/XP Professional workstationが ユーザーログオン認証をしたい場合、DNSサーバーに対して _ldap._tcp.pdc._msdcs.quenya.orgレコードを 再度問い合わせすることでドメインコントローラー見つける。 この項目に対する関連したより詳細な情報は、 DNSとActive Directoryを参照のこと。

バックアップドメインコントローラーの設定

BDCの作成には最初にsmbdを動かす前にSamba サーバーを準備するため のいくつかのステップが要求される。

  • ドメインSIDはPDCとBDCで同じにしなければならない。バージョン2.2.5 以前のSambaでは、ドメインSIDはprivate/MACHINE.SID ファイルに格納されていた。Sambaバージョン2.2.5以降すべてのバージョンでは、 ドメインSIDはprivate/secrets.tdbファイルに 格納されている。このファイルは各サーバーで固有であり、PDCからBDCに コピーできない。BDCは新しいSIDを起動時に生成する。新しく生成したBDCのSID はPDCのドメインSIDを上書きする。これは、BDCにドメインSIDを入手することを 認める手続きである。これについては以下で説明する。

    PDCまたは既存のBDCからドメインSIDを検索するためと、検索した値を secrets.tdbに格納するためには、以下を実行する:

    root# net rpc getsid
    
  • ldap admin dnの指定は必須である。 また、smbpasswd -w mysecret を使って、secrets.tdb中にLDAP管理用パスワードを 設定しなければならない。

  • The ldap suffixパラメーターとldap idmap suffix パラメーターはsmb.confファイル中で指定しなければならない。

  • UNIXユーザーデータベースはPDCからBDCへ同期しなければならない。 これは、/etc/passwd/etc/groupの両方がPDCからBDCに複製されなければ ならないことを意味している。これは変更が発生した時点で、手動で 行うことが出来る。別のやり方として、PDCをNISマスターサーバーとして設定し、 BDCをNISスレーブサーバーとして設定する。BDCをNISクライアントとして設定 するのでは、PDCが止まっているときにそのユーザーデータベースにアクセス 出来ないので不十分である。NISはパスワード同期の唯一の手法というわけ ではない。LDAPを使う解も同様に動作する。

  • SambaパスワードデータベースはPDCからBDCに向けて複製されねばならない。 rsyncsshsmbpasswd ファイルの同期を取るのが可能であるが、この方法は破綻していて 欠陥があるので推奨できない。よりよい解決方法は、各BDCに対してスレーブ LDAPサーバーを、PDCにマスターLDAPサーバーを設定することである。 rsyncを使う方法は、一定間隔毎にデータが複製されるという理由で、本質的に 欠陥がある。すべての瞬間に、現在のマシンとユーザーアカウントの正しい情報で BDCが操作できるという保証がない。このため、この方法では、首尾一貫しない セキュリティデータのために不連続なネットワークサービスへのアクセスによって ユーザーに不都合が生じる危険性がある。Windows ワークステーションが通常の 間隔でマシン信頼アカウントパスワードを更新(変更)することを心にとめて おかねばならず、管理者は通常それが起きていることを知らない。

    POSIX(UNIXユーザーとグループ)アカウントとSambaSAMAccountデータ両方のために LDAPを使うと、すべてのアカウント変更情報が共有ディレクトリに書かれること を自動的に保証する。これは、LDAPがその要求に適合するため、アカウント情報の 同期のための、何らかの特別な動作が必要ないことを意味する。

  • netlogon共有はPDCからBDCに向けて複製されねばならない。これは、ログインスクリプト が変更されるたびごとに手動で行うことができ、また、rsyncのような ツールを使うことで、この共有中のディレクトリ構造を複製する、cron ジョブを使うことで自動的に行える。netlogon共有内のファイルの複製に rsyncを使うことは、ネットワークセキュリティに対して特段 問題になることはない。管理者が netlogon 共有に対するすべての変更を明示的に 行ないたいと考えている場合は、手作業で管理するために用いることも可能である。

設定例

最後に、ワークステーションがBDCを見つけなければならない。 これは、SambaをBDCになるための最低限の設定中にある Samba smb.confファイルの[global]セクションのように設定 することで行える。

Example 5.3. BDCになるための最低限の設定

workgroup = MIDEARTH
passdb backend = ldapsam:ldap://slave-ldap.quenya.org
domain master = no
domain logons = yes
ldap suffix = dc=abmas,dc=biz
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=sambadmin,dc=quenya,dc=org
idmap backend = ldap:ldap://master-ldap.quenya.org
idmap uid = 10000-20000
idmap gid = 10000-20000

完全な、OpenLDAPとSambaを使うネットワーク設定の例の説明は、近所又はオンライン 書店で買える、Samba-3 by Exampleという を参照のこと。

この設定はWINSサーバーに、MIDEARTH<1C>という名前のみをBDCによって 登録させる。これは、MIDEARTH<1C>というNetBIOSグループ名が、 複数のマシンが登録に使用することを意図した NetBIOS グループ名であることを 考えれば問題ではない。パラメーター domain master = noは、PDCのために 予約されている固有のNetBIOS名であるMIDEARTH<1B>をBDCが登録時に 使用させないことを確保する。

idmap backendパラメーターが、 winbinddユーティリティをリダイレクトして、共有される リポジトリ内にある、 UNIXアカウントに関するすべての、Windows SIDからUIDとGIDへの解決のために LDAPサーバーデータベースを使用させる。 BDCはnss_ldapユーティリティとNSS経由の、ローカルでのUIDとGIDの 解決にも依存する。

Note

Samba-3は新しいIDマッピング機能を導入した。その機能の特徴の1つは、 NTドメインのユーザーとグループSIDに関してユーザーとグループIDを取り扱うやり方に、 より高い柔軟性を備えているということである。新しい機能の1つは、UNIX/Linuxの UIDとGIDの値が、PDC、すべてのBDCとすべてのドメインメンバーサーバー上で 一貫していることを明確に確保する。これを制御 するパラメーターは、idmap backendである。その動作 に関連する詳細な情報は、smb.confマニュアルページを参照してほしい。

BDC上のみでidmap backend = ldap:ldap://master.quenya.org オプションを使用することは、PDC上でldapsamが使われている時に意味をなす。 LDAPベースのバックエンドのもう1つの目的は、(固有のpassdbバックエンドを持たない)ドメインメンバー がWindowsネットワークユーザーとグループを共通のUID/GIDに割り当てるためにwinbindd を使えるようにすることである。別の言い方をすると、一般的にこのオプションは、 BDCとドメインメンバーサーバー上で使うことを意図している。

よくあるエラー

ドメイン制御はSambaの新しい領域であるが、現在では参照可能なたくさんの事例がある。 更新情報は、それが有効になった時点で、Sambaの新規リリース情報か、 Samba Websiteで公開される。 SambaリリースパッケージのWHATSNEW.txtを特に参照すること。 Samba-3 by Exampleという本には、よくテストされ、検証された 例が記述されている。これをSamba Webサイト上の からコピーを入手することもできる。

マシンアカウントが満了し続ける

この問題は、passdb(SAM)ファイルが中央のサーバーからコピーしていて、しかもローカルのBDC がPDCとして動作する時に発生する。これはローカルマシン信頼アカウントのパスワードを ローカルSAMへ更新を実行することで解決する。そのような更新は中央の サーバーにコピーは戻されない。新しいマシンアカウントのパスワードは、PDCからの SAMが再度コピーされたときに上書きされてしまう。その結果、起動時のドメインメンバー であるマシンの起動時に、そのパスワードがデータベース中と一致しないことになり、起動時の セキュリティチェックに失敗するため、このマシンはログオン要求が許可されず、 アカウント満了エラーが出ることになる。

解決策は、ldapsamバックエンドのようなより堅牢なpassdbバックエンドを使うことである。 すなわち、各BDCにスレーブLDAPサーバーを立て、PDCにマスターLDAPサーバーを 立てることである。

SambaはNT4 PDCのバックアップドメインコントローラーになれるか?

できない。オリジナルのNT4 SAM複製プロトコルはまだ完全に実装されていない。

SambaでBDCを使う利点はあるかと言われればもちろんある。しかし、それはSamba PDCに対して のみである。BDCを使う理由は可用性という点である。もしもPDCがSambaだった 場合、2番目のSambaマシンは、PDCがダウンしている時にログオン要求 をサービスするように設定できる。

smbpasswdファイルの複製はどうやるか?

smbpasswdファイルの複製は注意が必要である。SAMが変更されたときは必ず 行わなければならない。各ユーザーのパスワードの変更はsmbpasswd ファイル中で行われるので、必ずBDCに複製されねばならない。そのため、smbpasswdファイル の複製は非常に頻繁に必要となる。

smbpasswdファイルには平文パスワードと同等のものが含まれているので、ネットワーク 上で暗号化しないで送ってはならない。PDCからBDCへ、smbpasswdを複製する最もよい方法 は、rsyncを使うことである。rsyncは伝送路としてsshを使える。 sshは、ユーザーがパスワードを入力 しなくてもrsyncでの転送ができるように設定できる。

少し前に説明したが、この方法を使うことは欠陥があるため危険である。マシン信頼 アカウントの同期が外れると、結果としてドメインが破壊される。この方法は 推奨されない。その代わりにLDAPを使うこと。

これをすべてのLDAPに使えるか?

一言で言うと可能である。Sambaのpdb_ldapコードはレプリカLDAPサーバーに対する バインドをサポートし、データベースに対する変更の必要時には、referralの 追跡と再バインドを行う(通常BDCはリードオンリで、そのためこれは滅多に 起こらない)。

Chapter 6. ドメインメンバーシップ

John H. Terpstra

Samba Team

Jeremy Allison

Samba Team

Gerald (Jerry) Carter

Samba Team

Andrew Tridgell

Samba Team

Jelmer R. Vernooij

The Samba Team

Guenther Deschner

LDAP updates 

ドメインメンバーシップはきわめて重要な事項である。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ドメイン管理ネットワークに参加 できる。ドメインメンバーシップはたくさんの利点を持つ:

  • Microsoft WindowsワークステーションユーザーはSSOの利点を享受できる。

  • ドメインユーザーアカウントの(アクセス)権限とファイルの所有権およびアクセス制御は 単一のドメインセキュリティアカウントマネージャ(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基盤経由で)以外の任意のネットワーク クライアントかサーバー上でユーザーアカウントを保守する必要がないからである。

MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント

マシン信頼アカウントは(ユーザーではなく)クライアントマシンを ドメインコントローラーサーバーに対して認証するために使われる。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 の初期リリースまでは実装されない予定 である(訳注:この部分は古い)。

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

クライアントをドメインに即座に参加させる

この方法でマシン信頼アカウントを手動作成することは、 Windows NT PDC で により サーバーマネージャによりマシン信頼アカウントを 作成するのと同等である。アカウントが作成されてからクライアントがドメイン に参加してパスワードを変更するまでの間、同じ NetBIOS 名を持つマシンで ドメインに参加しようとする侵入者の被害を受ける可能性がある。 PDC は、 ドメインのメンバーを信頼するようにできており、多くのユーザー情報をこのような クライアントに渡してしまう。注意すること!

NT4サーバーマネージャによるドメインマシンアカウントの管理

有効な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の記事で得ることができる: 173673172540

srvmgr.exe(ドメイン用のサーバーマネージャ)を起動し、以下の手順を実行する:

Procedure 6.1. サーバーマネージャによるドメインマシンアカウント管理

  1. メニューからコンピュータを選択する。

  2. Select Domainをクリックする。

  3. Select Domainパネルで管理対象の ドメイン名をクリックし、 OKをクリックする。

  4. 再度メニュー画面からコンピュータを選択する。

  5. Add to Domainを選択する。

  6. ダイアログボックス中で、Add NT Workstation of Server ラジオボタンをクリックし、フィールドにマシン名を入力し、 Addボタンをクリックする。

マシン信頼アカウントの即時作成

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

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

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

[global]
add machine script = /usr/sbin/useradd -d /var/lib/nobody -g 100 -s /bin/false -M %u

Microsoft Windows ワークステーション又はサーバーをドメインメンバーにする

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

Windows 200x/XP Professionalクライアント

ユーザーがクライアントをドメインメンバーにする時、 Windows 200x は、ドメイン内で マシンアカウントを作成する権限を持つアカウント及びパスワードの入力を要求する。 Samba管理者アカウント(すなわち、Sambaサーバー上でroot権限を 持つSambaアカウント)をここで入力せねばならない。通常のユーザーアカウントが入力さ れると、この作業は失敗する(訳注:net rpc rightsでSeMachineAccountPrivilege権限を 持ったユーザーも出来るのでは?)

セキュリティのため、この管理者アカウントのパスワードは/etc/passwd でルートユーザー用に使用されているパスワード以外のものを設定するべきである。

ドメインメンバーのマシンアカウントを作成するために使用するアカウント名は ネットワーク管理者が任意に選択する。もしそれがroot以外なら smb.conf中のパラメーター username map = /etc/samba/smbusers で指定するファイル名中で容易にマッピングできる。

Samba管理者アカウントのセッションキーは、マシン信頼アカウントのパスワード 設定の際、暗号化キーの機能を果たす。マシン信頼アカウントはその場でで作成 されるか、または、既に存在していれば更新される。

Windows NT4 クライアント

マシン信頼アカウントが手動作成された場合、Identification Changes メニュー画面でドメイン名を入力するが、 Create a Computer Account in the Domain チェックボックスにはチェックを入れない。こうすることでマシン がドメインに参加する際に既存のマシン信頼アカウントが使用される。

もしマシン信頼アカウントがその場で作成される場合は、Identification Changes メニュー画面でドメイン名を入力し、 Create a Computer Account in the Domain チェックボックスにチェックを入れる。この場合、上記 Windows2000用 の手順に従いドメインに参加する(プロンプトに対してSamba管理者 アカウント名を入力する)。

Sambaクライアント

Joining a Sambaクライアントをドメインに参加させる方法は 次の章に記述されている。

ドメインメンバーサーバー

このモードのサーバー操作は、Sambaマシンをドメインセキュリティコンテキスト のメンバーにすることを含む。またこれは定義上、全てのユーザー認証は中央で 定義された認証機構(訳注:authentication regime)で行われることを意味する。 この認証機構は NT3/4形式(旧式のドメインテクノロジー)サーバー又は Microsoft Windows 2000以降で実装されているActive Directory server(ADS) が提供する。

もちろん、認証バックエンド自体はSambaがサポートしている分散ディレクトリ 構造のサーバーなら、いずれでも構わない。LDAP(OpenLDAPベース) 、Sunの iPlanet、Novellの e-Directoryなどが使用可能である。

Note

SambaがLDAPやその他のアイデンティティ管理、あるいは、ディレクトリ サービスを使用するように設定される場合、ユーザー及びマシン認証を継続して 実行するのはSambaである。Sambaが行う認証をLDAPサーバーが代替するわけでは ないことに注意。

ドメインメンバーサーバーのドメインマシンアカウント作成に関する詳細情報や Sambaドメインメンバーマシンがドメインに参加し完全に信頼されるようにする 方法に関しては、ドメイン管理の章を参照のこと。

Samba-3でNT4形式でのドメインに参加する

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

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 -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

これがなぜsecurity = serverよりもすぐれているのか?

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

Note

この文書の内容の大半は、ウェブマガジン LinuxWorldの記事 http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html Doing the NIS/NT Sambaとして最初に発表された(訳注:リンク切れ)。

Samba ADS ドメインメンバーシップ

これは、Windows 200x KDC に対し Kerberos認証を行うSamba-3の設定方法の概略である。 Kerberosの知識を有することを前提としている。

smb.confの設定

最低以下の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ドメインコントローラー を指定することは問題ない。

Note

smbpasswdファイルは必要でなく、古いクライアントは あたかもsecurity = domainのように 認証され、何の害もなく、ドメインに入らないローカルユーザーを持つことが できる。

/etc/krb5.confの設定

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の既定値の設定が ないもの)とのみ使用できる。残念ながらこの領域はいまだに流動的な状態である。

Note

レルムは大文字でなければ、 Cannot find KDC for requested realm while getting initial credentials (最初の認証情報取得時にリクエストされたレルムの KDC を見つけられない) というエラーが表示される(Kerberos は大文字・小文字を区別する)。

Note

2つのサーバーは時間の同期を取らなければならない。もし時間差が5分以上になると メッセージ kinit(v5): Clock skew too great 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でのテストに進むこと。 コンピュータアカウントの作成サーバー設定のテストは、 smbdwinbinddで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重にする必要がある。

よくあるエラー

ADS サポートがコンパイルされていない

Kerberosライブラリとヘッダーファイルのインストール後に、Samba を再設定(config.cache を削除) して、リコンパイルする(make clean all install)。

net ads joinがユーザー名の入力を要求する

kinit USERNAME@REALM を使ってドメインにログインする必要がある。 USERNAMEはマシンをドメインへ追加する権限を持つユーザーでなければならない。

サポートされない暗号/もしくはチェックサムタイプ

/etc/krb5.confシステムにインストールされているKerberosの タイプとバージョンに対して適切に設定されているか確認する。

サーバー設定のテスト

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

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

Note

SambaはDES-CBC-MD5暗号及びARCFOUR-HMAC-MD5符号を使用できる。

smbclientによるテスト

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

注意

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

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

Sambaドメインメンバー間でのユーザーIDマッピング共有

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まで増やし、 ドメインへの参加を試行してみる。そのログをチェックし、どの動作が失敗しているか突き止める。

可能性のある原因:

  • スクリプトが実際には存在していないか、指定したパスにない。

    是正処置:修正する。スクリプトを手動で実行すると、UNIX システム アカウントとSamba SAM アカウントの両方が追加されることを確認する。

  • マシンをUNIXシステムアカウントファイル/etc/passwdに追加できない。

    是正処置:マシン名が有効なUNIXシステムアカウント名であるか確認する。 もしもUNIXユーティリティuseraddが呼び出されるならば、このツールを 使用して追加したいマシン名を追加できることを確認する。一部のシステム上の Useraddは大文字やスペースを名前に使用することを許可しない。

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

Windows 2003 PDC に参加できない

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

Chapter 7. スタンドアロンサーバー

John H. Terpstra

Samba Team

スタンドアロンサーバーは、ネットワーク上での独立したドメインコントローラーである。 それらはドメインメンバーではなく、ワークグループサーバーのように機能する。 多くの場合、スタンドアロンサーバーは、提供されたデータが容易にすべての利用者 からアクセス可能という意図で、最低限のセキュリティ制御で設定されている サーバーである。

機能と利便性

スタンドアロンサーバーは、必要性によって、セキュアにも非セキュアにもできる。 単純あるいは複雑な設定を取ることが出来る。上記のように、ドメインセキュリティ について、過大な説明にもかかわらず、多くは普通のインストールのままである。

もしも、サーバーに必要とされるものがすべて読み込み専用ファイルか、プリンター のみならば、複雑な設定をするのは意味をなさない。たとえば、設計事務所 が古い設計図と設計標準を格納しておく必要があるとする。すべての文書が 変更されないままでいることが法律的に重要なので、誰もサーバーにファイルを 書き込めない。シェアモードのリードオンリスタンドアロンサーバーは理想的 な解決方法である。

単純さを正当化するもう1つの状態は、一つの中央サーバーから待ち行列に入れられる 多くのプリンターを持っているオフィスである。全員がプリンターに印刷出来る要求が あるが、アクセス制御の必要がなく、プリンターサーバーにはファイルがない場合である。 繰り返すと、シェアモードスタンドアロンサーバーはとても優れた解決方法を提供する。

背景

standalone serverという言葉は、ローカルな認証とその上で 有効なすべてのリソースのアクセスを制御する機能を提供するという意味である。 一般的に、これは、ローカルユーザーデータベースがあると言うことを意味する。 もう少し技術的な言葉で言うと、これは、マシン上のリソースは、 shareモードかuserモードのいずれか が有効であるということである。

ユーザーアカウントを作成するため以外に特別な操作は必要ない。スタンドアロンサーバー はネットワークログオンサービスを提供しない。これは、このサーバーを使うマシンは これに対するドメインログオンを実行しないことを意味する。ワークステーションが 使うどんなログオン機能も、このマシンからは独立している。しかし、使用する ログオン名がローカルで持っているユーザー名をスタンドアロンサーバー上でローカルに 変換(マップ)するために、任意のネットワークユーザーを一致させることは必要である。 このことを実行するためにはいくつかの方法がある。

Sambaはスタンドアロンサーバーの定義中で少しだけ区別を曖昧にするのに 役立つ。これは、SMBプロトコルの視点から、Sambaサーバーがドメイン セキュリティコンテキストのメンバーでないとしても、認証データベース がローカルかリモートサーバー上にあるという理由である。

UNIXユーザーデータベースを操作するPAMとネームサービススイッチ(NSS)を使って (PAMに付いての節を参照)、認証のソースは 別のサーバー上にあってもよい。これを認証サーバーと呼ぶ傾向がある。これは、 SambaサーバーはローカルのUNIX/Linuxシステムパスワードデータベース (/etc/passwd/etc/shadow)か、 ローカルのsmbpasswdファイルか、LDAPバックエンドか、認証のために、 PAMとWinbind経由で他のCIFS/SMBサーバーを使っても良いことを意味する。

設定例

参照用文書サーバーの例センタ印刷サーバーは単純さに ヒントを得てデザインされた。それは高度な創造性を試みることと、 サーバーとネットワーク設計においてとても複雑であることを説明することは とても簡単である。

参照用文書サーバー

誰でもアクセスできる読み込み専用データサーバーの設定はとても単純である。既定値 では、すべての共有は、smb.confファイルに何か書かれるまではリードオンリで ある。 参照用文書サーバーの例 はこれを行うためのsmb.confファイルである。すべての参照用文書はディレクトリ /exportに格納されていて、文書はnobody以外のユーザーによって 所有されていることを仮定する。ホームディレクトリは共有されず、UNIXシステム データベース/etc/passwd中にはユーザーはいない。これは 管理者にとって単純なシステムである。

Example 7.1. 参照用文書サーバー用のsmb.conf

# Global parameters
[global]
workgroup = MIDEARTH
netbios name = GANDALF
security = SHARE
passdb backend = guest
wins server = 192.168.1.1
[data]
comment = Data
path = /export
guest only = Yes

 

もう少し準備に時間があれば、もう少し簡単にできた。

 
 --Mark Twain

この例中で、マシン名はGANDALFに設定 され、ワークグループはローカルワークグループ(MIDEARTH)の名前に設定され、 ユーザーがなじみのあるシステムと一緒に表示される。必要とされる唯一のパスワードバックエンド は、既定値の非制限アカウント名として使われることを許可するguest バックエンドである。このネットワーク上でWINSサーバーがあるならば、もちろんそれを使う。

米国空軍連隊長が言った有名なことは: A US Air Force Colonel was renowned for saying: 最善は善の的(Better is the enemy of good enough!)。 専門的に完全な解決を避けることと同様、複雑さを避けることに対して、しばしば健全な理由が 存在する。不幸にも、トラブルがないことを保持するのにちょうど十分な術を、多くの ネットワーク管理者は引き続き覚える必要がある。

集中印刷サーバー

単純な印刷サーバーの設定は、システム上のすべての正しいツールがあるならば簡単である。

前提条件

  1. 印刷サーバーは管理不要でなければならない。

  2. 印刷サーバー印刷の、スプールと処理をするシステムはCUPSである。 (詳細情報はCUPS印刷システムを参照のこと)。

  3. 印刷サーバーはネットワークプリンターのみ処理を行う。ネットワーク管理者は プリンターをサポートするためにCUPS環境を正しく設定している。

  4. すべてのワークステーションはPostScriptドライバーを使う。選択したプリンター ドライバーはApple Color LaserWriterのためのWindows OS用のものを選択する。

この例では、印刷サーバーは入力したすべての印刷ジョブを、Sambaによって、CUPS 印刷プロセッサに向けて送られたジョブが実行可能になるまで /var/spool/sambaにスプールする。すべての入力された 接続は匿名(guest)ユーザーなので、匿名印刷を有効にするために、2つ設定が必要である。

匿名印刷を有効にする

  • UNIX/Linuxシステムはguestアカウントを持たねば ならない。この既定値は、通常nobodyである。 使用するバージョンで使っている正しい名前を探すためには、以下を実行する:

    $ testparm -s -v | grep "guest account"
    

    このアカウントはシステムのパスワードデータベース (/etc/passwd)に存在するようにしておかねばならない。

    このアカウントに対してパスワードを設定するか、UNIXでの使用からロックすることは 良い考えである。ゲストアカウントがpcguestであると仮定した時、 以下を実行することでロックが出来る:

    root#  passwd -l pcguest
    

    正確なコマンドは使用するUNIX/Linuxディストリビューションによって異なる。

  • Sambaがファイルをスプールするディレクトリはゲストアカウントに対して 書き込み許可を持たねばならない。以下のコマンド操作で、このディレクトリ が使えるようにする:

    root# mkdir /var/spool/samba
    root# chown nobody.nobody /var/spool/samba
    root# chmod a+rwt /var/spool/samba
    

smb.confファイルの内容は匿名印刷の例にある。

Example 7.2. 匿名印刷のためのsmb.conf

# Global parameters
[global]
workgroup = MIDEARTH
netbios name = GANDALF
security = SHARE
passdb backend = guest
printing = cups
printcap name = cups
[printers]
comment = All Printers
path = /var/spool/samba
printer admin = root
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = No

Note

CUPSが有効なシステム上で、CUPSプリントフィルタ経由の中間処理なしで生データを 直接プリンターに送る機能がある。このモードの操作が要求される場合、raw印刷デバイス の設定が必要である。また、/etc/mime.conv/etc/mime.typesファイル中にraw mime ハンドラーを有効にする 設定も必要である。CUPS印刷サポートapplication/octet-streamで明示的にraw印刷を有効にする を参照のこと。

匿名印刷の例中では、CUPSライブラリAPI経由で 直接印刷のためにCUPSを使用する。これは、すべてのプリンターはprintcapファイルを設定する 必要なしにWindowsユーザーから見えるようになるという意味である。もしも、プリンターの サブセットのみか、特別な種類のプリンター(たとえばPDFフィルタ)を見せる必要がある ならば、printcap name = cupsprintcap name = /etc/samba/myprintcapに置き換えても良い。 この場合、指定されたファイルはWindowsネットワークユーザーに見せるべきプリンター名の 一覧を含む必要がある。

よくあるエラー

よく発生するとても大きな間違いは、ネットワークの設定を複雑すぎるようにしてしまう ことである。その時に必要な最も簡単な解を使うこと。

Chapter 8. Microsoft Windows ネットワーク設定ガイド

John H. Terpstra

Samba Team

機能と利便性

時折、Microsoft WindowsクライアントがSambaサーバーに正しく相互運用を行うことが 難しいと、ネットワーク管理者が報告している。Microsoft Windows NT4か200xサーバー を使うときのように、Microsoft Windowsネットワーククライアントが正しく設定する ための正しい方法という事実を何人かが受け入れられないように見える。それでも、 詳細なWindowsクライアント設定の手順を提供するという継続的な必要性がある。

この章の目的は、最も共通的な重要な設定場面での設定について、Microsoft Windows クライアントの設定をGUIで説明することである。十分に経験のあるネットワーク管理者 は、この章の詳細については興味がないだろう。

技術的な詳細

この章では、現在一般的に使われているプラットフォームのためのネットワーク メンバーシップと同様に、TCP/IPプロトコルについて説明する。それは以下の通り:

  • Microsoft Windows XP Professional

  • Windows 2000 Professional

  • Windows Millennium edition (Me)

TCP/IP設定

大工さんは家を建てるときには基礎がしっかりしている上で建築することを保証しな ければならない(訳注:やや意訳)。TCP/IPベースのネットワークシステムの構築者に とってもこれは真である。ネットワーク基盤設定の問題はそれが解決するまで、 すべてのネットワークユーザーを悩ませる。

Microsoft Windowsワークステーションとサーバーは固定IPアドレスかDHCPのどちらでも 設定できる。以下での例ではDHCPを使い、固定IP設定に影響される場面においては、 参照先への参照のみを行っている。

特定の設定画面に到達するためにショートカットや短縮されたキーストロークを 使うことが可能である。この章でのすべての例のベースのために、 スタートボタンを使うことを決めごととした。

Microsoft Windows XP Professional

Windows XP TCP/IP 設定パネルへは2つのパスがある。どちらか好きな方を 選べばよい:

スタート -> コントロールパネル -> ネットワーク接続とクリック。

もう1つの方法は click スタート->をクリックし、マイネットワークを右クリックし、 プロパティをクリックする。

以下の手順はWindows XP ProfessionalのTCP/IP設定手続きのステップである:

  1. いくつかのインストールにおいて、インタフェースはローカルエリア接続と その他ではNetwork Bridgeと呼ばれる。ここでの例においては Network Bridgeと呼ばれる。 Network Bridge -> プロパティと右クリックする。 “Network Bridgeの設定”を参照。

    Figure 8.1. Network Bridgeの設定

    Network Bridgeの設定


  2. Network Bridge Configurationの設定か、ローカルエリア接続の設定で、TCP/IPプロトコル 設定のためにパネルが使われる。 この接続は次の項目を使用します(O):というボックス中で、 インターネット プロトコル(TCP/IP)をクリックし、次に、 プロパティをクリックする。

    既定値の設定は、DHCPが有効な動作である。 (すなわち、IPアドレスを自動的に取得する)。 “インターネット プロトコル(TCP/IP)のプロパティ”を参照。

    Figure 8.2. インターネット プロトコル(TCP/IP)のプロパティ

    インターネット プロトコル(TCP/IP)のプロパティ


    多くのネットワーク管理者は、すべてのクライアントTCP/IPプロトコルスタックの 設定においてDHCPを使う設定をしたいと思っている(Windowsクライアントをサポート するための ISC DHCPサーバーの設定方法についての情報は、 DNSとDHCP設定ガイドと、DHCPサーバー を参照)。

    もしも、固定IPを使う必要があるならば、次のIPアドレスを使うを クリックし、IPアドレス、サブネットマスク、デフォルトゲートウェイをそれぞれの ボックスに入力する。

  3. TCP/IP設定にある詳細設定をクリックする。このインタフェースに 対する追加のIPアドレスを作成することが可能になるパネルが開く。 追加のIPアドレスに対する技術的な名前はIPエイリアスであり、 さらに、追加のデフォルトゲートウェイ(ルータ)を設定することもできる。ほとんどの場合、 DHCPが使われていると、追加の設定は必要ない。このパネルの外観は、 “ネットワークの詳細設定”を参照。

    Figure 8.3. ネットワークの詳細設定

    ネットワークの詳細設定


    DHCP経由で自動的にDNSとWINSの設定が提供されない場合、 固定的な設定が必要である。

  4. DNSタブをクリックし、DNSサーバーの設定を追加する。 例題のシステムでは、手動でのDNS設定を使っている。変更が終了したなら、 OKをクリックして変更を確定する。 “DNSの設定”を参照。

    Figure 8.4. DNSの設定

    DNSの設定


  5. WINSタブをクリックして、手動でWINSサーバーの 設定を追加する。この手順は、例題のシステムで、手動でWINSサーバーの設定 を行うことを行っている。変更が終了したならば、OK をクリックして変更を確定する。“WINS Configuration”を参照。

    Figure 8.5. WINS Configuration

    WINS Configuration


Microsoft Windows 2000

TCP/IP設定パネルを表示させるためには2つの方法がある。以下のどちらを使っても良い:

スタート -> コントロールパネル -> ネットワークとダイヤルアップの設定をクリック(訳注:正しい訳か未確認)。

その代わりに、スタートをクリックし、マイネットワークを右クリックし、 プロパティを選択する。

以下の手順はWindows XP Professional TCP/IP設定の手順である:

  1. ローカルエリア設定を右クリックし、次に、 プロパティをクリックする。“ローカル エリア接続のプロパティ”を参照。

    Figure 8.6. ローカル エリア接続のプロパティ

    ローカル エリア接続のプロパティ


  2. ローカル エリア接続のプロパティはTCP/IPプロトコル設定を設定するのに使われる。 この接続は次の項目を使用します中の インターネット プロトコル (TCP/IP)をクリックし、次に プロパティボタンをクリックする。

  3. 既定値はDHCP有効な設定である(すなわちIP アドレスを自動的に取得する)。 “インターネット プロトコル (TCP/IP)のプロパティ”を参照。

    Figure 8.7. インターネット プロトコル (TCP/IP)のプロパティ

    インターネット プロトコル (TCP/IP)のプロパティ


    ネットワーク管理者の多くは、すべてのクライアントのTCP/IPプロトコルスタック設定 をDHCPを使うように設定したいと思っている(ISC DHCPサーバーをWindowsクライアントを サポートするように設定する方法についての情報は“DHCPサーバー” を参照のこと)。

    もしも、固定IPアドレスを使いたいならば、次の IP アドレスを使うをクリックし、 IPアドレスとサブネットマスクとデフォルトゲートウェイのIPアドレスを所定の位置に入力する。 この例では、すべてのネットワーククライアントはDHCPで設定されていることを仮定している。

  4. 詳細設定ボタンをクリックして、TCP/IP詳細設定を実行する。 “TCP/IP 詳細設定”を参照。

    Figure 8.8. TCP/IP 詳細設定

    TCP/IP 詳細設定


    固定設定は、DHCP経由で自動的にDNSとWINS設定が提供されない場合に要求される。

  5. DNSサーバー設定のためにDNSタブをクリックする。 例題システムでは、手動でのDNS設定を使っている。変更が完了したならば、 OKをクリックして変更を確定する。 “DNS設定”を参照。

    Figure 8.9. DNS設定

    DNS設定


  6. WINSサーバーエントリ設定のためにWINSタブをクリックする。 このステップは、例題システムにおいて、手動でのWINS設定を使うことを示している。 変更が完了したならば、OKをクリックして変更を確定する。 “WINS設定”を参照。

    Figure 8.10. WINS設定

    WINS設定


Microsoft Windows Me

Windows Millennium edition (Me)でTCP/IP設定パネルを呼び出すには2つのパスがある。以下のどちらかを実行する:

スタート -> コントロールパネル -> ネットワーク接続をクリックする。

別の方法として、スタート ->をクリックし、My Network Placesを右クリックし、 プロパティを選択する。

以下の手順は、Windows MeのTCP/IP設定手順である:

  1. The following network components are installed:というタイトルのボックス中で、 インターネットプロトコル TCP/IPをクリックし、次にプロパティボタンをクリックする。 “Windows Me ネットワーク設定パネル”を参照。

    Figure 8.11. Windows Me ネットワーク設定パネル

    Windows Me ネットワーク設定パネル


  2. ネットワーク管理者の多くは、すべてのクライアントのTCP/IPプロトコルスタック設定 をDHCPを使うように設定したいと思っている(ISC DHCPサーバーをWindowsクライアントを サポートするように設定する方法についての情報は“DHCPサーバー”と を参照のこと)。Windows Me ワークステーションでの既定値の設定はDHCP有効である (すなわち、IPアドレスを自動的に取得が有効)。 “IPアドレス”を参照。

    Figure 8.12. IPアドレス

    IPアドレス


    もしも固定IPアドレスの指定が必要ならば、IPアドレスを指定をクリックし、 IPアドレス、トサブネットマスクをボックス内に入力する。この例では、すべてのネットワーククライアントは DHCPを使うように設定されていると仮定している。

  3. 固定設定は、DHCP経由で自動的にDNSとWINS設定が提供されない場合に要求される。

  4. 必要に応じてDNSサーバー設定追加のためにDNS設定タブをクリックする。 WINSサーバー設定追加のためにWINS設定タブをクリックする。 ゲートウェイタブでは、追加のゲートウェイ(ルータアドレス)を、 ネットワークインタフェース設定追加できる。DHCPを使うほとんどの場合では、 手動でこれらの設定を作成することは不要である。

  5. 以下は、WINSを手動で設定する例である。“DNS設定”を参照。 変更が終わったら、OKをクリックして変更を確定する。

    Figure 8.13. DNS設定

    DNS設定


    これは、手動でWINS設定したシステムの例である。これができよう出来るような状況は、 複数のWindowsワークグループまたはドメインの設定を提供する単一のDHCPサーバーがある ネットワークである。“WINS設定”を参照。

    Figure 8.14. WINS設定

    WINS設定


ドメインへの参加: Windows 2000/XP Professional

Microsoft Windows NT/200x/XP Professional platformsはドメインセキュリティに参加できる。 この節では、Windows 200x/XP Professionalマシンをドメインセキュリティ環境のメンバーにする 手順を説明する。この手続きは、Windows NT4/200xによって制御されるドメインへ参加する時 とSambaPDCでは同一であることに注意されたい。

  1. Startをクリック。

  2. マイコンピュータを右クリックし、次にプロパティを選択。

  3. パネルのオープンは、コントロールパネル上のSystemをクリックしても 同様に行える。“全般”を参照。

    Figure 8.15. 全般

    全般


  4. コンピュータ名タブをクリックする。 このパネルでは、コンピュータの説明フルコンピュータ名ワークグループまたはドメイン名が表示されている。

    ネットワークIDボタンをクリックすると、設定ウィザードが起動する。Samba-3では これを使ってはならない。コンピュータ名やドメインからの離脱を行いたいならば、変更 ボタンを使う。“コンピュータ名パネル”を参照のこと。

    Figure 8.16. コンピュータ名パネル

    コンピュータ名パネル


  5. 変更をクリックする。このパネルでは例題のシステム(TEMPTATION)がWORKGROUPという ワークグループであることを示している。 MIDEARTHというドメインにこれから参加する。“コンピュータ名の変更パネル”を参照。

    Figure 8.17. コンピュータ名の変更パネル

    コンピュータ名の変更パネル


  6. 以下のドメインボタンのフィールド内にMIDEARTHを入力する。

    このパネルでは、例題のシステム(TEMPTATION)がMIDEARTHと呼ばれるドメインに参加することを示している。 “コンピュータ名の変更パネル ドメイン MIDEARTH”を参照。

    Figure 8.18. コンピュータ名の変更パネル ドメイン MIDEARTH

    コンピュータ名の変更パネル ドメイン MIDEARTH


  7. OKボタンをクリックする。マシンをドメインに参加させる権利を持つドメイン管理者 アカウントの認証(ユーザー名とアカウント)を入力するためのダイアログボックスが現れる。

    Samba-3サーバーのrootとパスワードを入力する。“コンピュータ名の変更 ユーザー名とパスワードパネル”を参照。

    Figure 8.19. コンピュータ名の変更 ユーザー名とパスワードパネル

    コンピュータ名の変更 ユーザー名とパスワードパネル


  8. OKをクリックする。

    MIDEARTHドメインへようこそダイアログボックスが現れる。この時点でマシンを再起動する必要がある。 これでドメインへの参加が完了する。

ドメインログオンの設定: Windows 9x/Me

Windows 9x/Meマシンがドメインに参加できるということを言う時に、とても一般的に用いられる慣例に従う。 実際には、これらのプラットフォームはLanManagerネットワークログオンプロトコルのみを使うことが出来る。

Note

Windows XP Home editionはドメインへの参加またはLanManagerネットワークログオンができない。

  1. ネットワークコンピュータ(Network Neighborhood)アイコンを右クリックする。

  2. ネットワーク設定パネルには、変更可能なすべての共通なネットワーク設定がある。 “ネットワークパネル”を参照。

    Figure 8.20. ネットワークパネル

    ネットワークパネル


    クライアント用Microsoftネットワークドライバーが、見えているようにインストールされているようにする。 以下のネットワークコンポーネントを使用する:中の クライアント用Microsoftネットワークをクリックする。次に、 プロパティボタンをクリックする。

  3. クライアント用Microsoftネットワークプロパティパネルではネットワークログオンの設定をするための 所である。“クライアント用Microsoftネットワークプロパティパネル”を参照。

    Figure 8.21. クライアント用Microsoftネットワークプロパティパネル

    クライアント用Microsoftネットワークプロパティパネル


    NTドメイン名を入力し、NTドメインにログオンボックスにチェックを付け、 OKをクリックする。

  4. 識別ボタンをクリックする。これは、設定すべきワークグループ (ドメイン)名とマシン名(コンピュータ名)がある所である。“識別パネル”を参照。

    Figure 8.22. 識別パネル

    識別パネル


  5. 次にアクセス制御ボタンをクリックする。もしもドメインユーザーとグループ アカウントを使って共有アクセスパーミッションを割り当てたいならば、このパネル中にある ユーザーレベルのアクセス制御を有効にする必要がある。 “アクセス制御パネル”を参照。

    Figure 8.23. アクセス制御パネル

    アクセス制御パネル


よくあるエラー

最もよくあるWindowsネットワークシステムに悪影響を及ぼすエラーは下記の通り:

  • 不正なIPアドレス。

  • 不正又は矛盾したネットマスク。

  • 不正なルータアドレス。

  • 不正なDNSサーバーアドレス。

  • 不正なWINSサーバーアドレス。

  • これについて注意するネットワークスコープ設定を使う!

Windows NT/200x/XP ProfessionalクライアントがSamba制御下のドメインに参加できない最も一般的な理由は 以下の通り:

  • smb.conf で正しいadd machine script設定をしていない

  • rootがパスワードバックエンドデータベースにない。

  • ドメインに参加するときにroot以外のユーザーアカウントを代わりにに使っている。

  • ワークステーションからサーバーに対する接続が切れている。

  • クライアント又はSambaサーバーにファイアウォールかフィルタの設定がなされている。

Part III. 詳細な設定方法

Valuable Nuts and Bolts Information

Sambaにはいくつかの必要/不必要な機能が用意されている。以下の 節では、Sambaにおける特定の機能について個別に説明している。

Table of Contents

9. Samba 3.xシリーズにおける重要で重大な変更点
重要な Samba-3.2.x の変更点
重要な Samba-3.0.x の変更点
ユーザーとグループの変更
グループマッピングの基本
Passdbの変更
Samba-3.0.23でのグループマッピングの変更
Samba-3.0.23におけるLDAPの変更
10. ネットワークブラウジング
機能と利便性
ブラウジングとは何か?
議論
NetBIOS over TCP/IP
TCP/IPなしのNetBIOS
DNSとActive Directory
どのようにブラウジングは機能するか
ワークグループのブラウジングの設定
ドメインブラウジングの設定
強制的にSambaをマスターにする
Sambaをドメインマスターにする
ブロードキャストアドレスについての注意
複数のインタフェース
リモートアナウンスパラメーターの使用
Remote Browse Syncパラメーターの使用
WINS: The Windows Internetworking Name Server
WINSサーバーの設定
WINS複製
静的なWINSエントリ
役に立つヒント
Windowsのネットワークプロトコル
名前解決の順序
ブラウジングの技術的な概要
Sambaでのブラウジングサポート
問題の解決方法
サブネット間のブラウジング
よくあるエラー
SambaのNetBIOS名前キャッシュのフラッシュ
サーバーリソースがリスト出来ない
"Unable to browse the network"というエラーメッセージが出た。
共有とディレクトリのブラウジングが非常に遅い
不正なキャッシュされた共有参照はネットワークブラウジングに影響する
11. アカウント情報データベース
機能と利便性
下位互換性のあるバックエンド
新しいアカウント格納システム
技術情報
セキュリティに関する重要な注意事項
Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング
分散マシン上の共通のUID/GIDマッピング
LDAPに関するコメント
LDAPディレクトリとWindowsのコンピュータアカウント
アカウント管理ツール
smbpasswdツール
pdbeditツール
パスワードバックエンド
平文
smbpasswd: 暗号化したパスワードデータベース
tdbsam
ldapsam
よくあるエラー
ユーザーがログオンできない
auth methodsの設定
12. グループのマッピング: Microsoft Windows と UNIX
機能と利便性
議論
警告:ユーザー固有のグループ問題
ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
管理に関する重要な情報
既定値のユーザー、グループと相対識別子
設定例
設定スクリプト
smb.confにグループを追加するスクリプト例
グループマッピング設定のためのスクリプト
よくあるエラー
グループの追加が失敗する
ワークステーションのPower UsersグループへのDomain Usersの追加
13. リモートとローカル管理:Netコマンド
概要
管理者の作業と手段
UNIXとWindowsのグループ管理
グループアカウントの追加、改名、あるいは削除
グループメンバーシップの操作
ネストされたグループのサポート
UNIXとWindowsのユーザー管理
ユーザーアカウントの追加
ユーザーアカウントの削除
ユーザーアカウントの管理
ユーザーのマッピング
管理ユーザーの権限と権利
信頼関係の管理
マシン信頼アカウント
ドメイン間の信頼関係
セキュリティ識別子(SID)の管理
共有管理
共有の作成、編集と削除
共有のACLの作成と変更
共有、ディレクトリとファイルのマイグレーション(移行)
プリンターの移行
オープンしているファイルの制御
セッションとコネクションの管理
プリンターとADS
Sambaキャッシュの操作
IDMAP UID/SIDマッピングの管理
IDMAPデータベースダンプファイルの作成
IDMAPデータベースダンプファイルのリストア
その他の雑多な操作
14. 識別情報のマッピング(IDMAP)
SambaサーバーのサーバータイプとIDMAP
スタンドアロンSambaサーバー
ドメインメンバーサーバーかドメインメンバークライアント
プライマリドメインコントローラー
バックアップドメインコントローラー
IDMAPバックエンドの使用例
規定値のWinbind TDB
IDMAP_RIDを使うWinbind
Winbindを使ったIDMAPデータのLDAPへの格納
RFC2307bis Schema拡張を使ったADSからのIDMAPとNSSに対するLDAPの使用
15. User Rights and Privileges
権利の管理能力
net rpc rightsユーティリティの使用
権限の説明
Windows2000ドメインコントローラーでサポートされている権限
管理者のドメインSID
よくあるエラー
Windowsクライアントの管理が出来る権利と権限は何か?
16. ファイル、ディレクトリと共有のアクセス制御
機能と利便性
ファイルシステムのアクセス制御
Microsoft Windows NTFSとUNIXファイルシステムとの比較
ディレクトリの管理
ファイルとディレクトリのアクセス制御
共有のアクセス制御の定義
ユーザーとグループベースの制御
ファイルとディレクトリに対するパーミッションベースの制御
その他の制御
共有のアクセス制御
共有のパーミッションの管理
Microsoft Windowsのアクセス制御リストとUNIXとの相互運用性
NTセキュリティダイアログを使用したUNIXパーミッションの管理
Samba共有上でのファイルセキュリティの表示
ファイルの所有者の表示
ファイルとディレクトリのパーミッションの表示
ファイルまたはディレクトリのパーミッションの変更
標準的なSambaのcreate maskパラメーターとの相互作用
標準Sambaファイル属性のマッピングの相互関係
Windows NT/200X ACLとPOSIX ACLの制限
よくあるエラー
Publicな共有にユーザーが書き込めない
force userセットでrootとしてファイル操作が完了する
SambaでMicrosoft Wordを使うとファイルの所有者が変更される
17. ファイルとレコードのロッキング
機能と利便性
議論
Opportunistic Lockingの概要
SambaのOplocks制御
設定例
Microsoft Windowsのoplocksとキャッシュ制御
ワークステーションサービスのエントリ
サーバーサービスのエントリ
持続的なデータ破壊
よくあるエラー
locking.tdb のエラーメッセージ
Windows XP上でのMicrosoft Officeファイルセーブ時の問題
XP SP1でネットワーク経由でファイルを消すのに長い時間がかかる
参考文献
18. Securing Samba
序論
機能と利便性
保護対応と問題に関する技術的な議論
ホストベースの保護の使用
ユーザーベースの保護
インタフェース保護の使用
ファイアウォールの使用
IPC$ 共有ベースの拒否の使用
NTLMv2のセキュリティ
Sambaのアップグレード
よくあるエラー
smbclientはローカルホストで動くが、ネットワークは死んでいる
なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?
19. ドメイン間の信頼関係
機能と利便性
信頼関係に関する背景情報
ネイティブなMicrosoft Windows NT4の信頼関係の設定
NT4ドメイン信頼関係の作成
NT4ドメイン信頼関係の構築完了
ドメイン間信頼関係の機能
SambaにおけるNT形式のドメイン信頼関係の設定
信頼されるドメインとしてのSamba
信頼するドメインとしてのSamba
Windows 2000との間での、NT4形式のドメイン信頼関係
よくあるエラー
信頼されるドメインからのブラウジングに失敗する
LDAP ldapsamと古いバージョンのsmbldap-toolsに関する問題
20. Microsoft 分散ファイルシステムツリーのホスティング
特徴と利点
よくあるエラー
MSDFSのUNIXパスは大文字小文字を識別する
21. 旧式の印刷サポート
機能と利便性
技術的な序論
クライアントからSambaへの印刷ジョブの処理
印刷に関連する設定パラメーター
簡単な印刷設定
testparmによる設定の検査
手っ取り早い設定の検証
拡張印刷設定
設定の説明詳細
Samba-2.2からの印刷環境
Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー
無効になった [printer$]セクション
[print$]共有の作成
[print$]セクションのパラメーター
[print$]共有ディレクトリ
[print$]へのドライバーのインストール
プリンターの追加ウィザードによるドライバーのインストール
rpcclientを使った印刷ドライバーのインストール
クライアントドライバーのインストール方法
最初のクライアントドライバーインストール
新しいプリンターに対するデバイスモードの設定
追加のクライアントドライバーインストール
常時最初のクライアントからの接続はrootかprinter adminで行う
その他のテクニック
クライアントドライバーのための既定値の印刷操作の設定
大量のプリンターのサポート
Windows NT APWによる新しいプリンターの追加
エラーメッセージ: 異なった名前で接続できない
ドライバーファイルを集めるときに気をつけること
Sambaとプリンターポート
共通クライアントドライバーの間違った設定の防止
Imprintsツールセット
Imprintsとは何か?
プリンタードライバーパッケージの作成
Imprintsサーバー
クライアントのインストール
ユーザーによるインストールなしにネットワークプリンターを追加する
addprinterコマンド
旧式の印刷システムの、Sambaへの移行
Active DirectoryかLDAPへのプリンター情報の公開
よくあるエラー
rootパスワードを指定したが、アクセスできない
印刷ジョブはスプールディレクトリに入ったが、その後なくなった
22. CUPS印刷環境のサポート
概要
機能と利便性
Overview
基本的なCUPSサポート設定
libcups.soを使ったsmbdとのリンク
CUPSを使う簡単なsmb.confの設定
より複雑なCUPS smb.conf設定
高度な設定
集中スプール対ピアツーピア印刷
直接印刷機能:Windowsクライアント上のベンダドライバー
Windowsクライアントドライバーのインストール
application/octet-streamのためのraw印刷を明示的に有効にする
ドライバーアップロード手法
Postscriptドライバーダウンロードを使う高度に賢い印刷
Windows上でのGDI、UNIX上でのPostScript
Windowsドライバー、GDIとEMF
UNIX印刷ファイル変換とGUIの基礎
PostScriptとGhostscript
Ghostscript: 非Postscriptプリンターに対するソフトウェアRIP
PostScriptプリンター定義(PPD)の仕様
Windows形式のベンダPPDの使用
非PostScriptプリンターのためにCUPSはPPDを使う
CUPSフィルタリングアーキテクチャ
MIMEタイプとCUPSフィルタ
MIMEタイプ変換ルール
フィルタリングの概要
Prefilters
pstops
pstoraster
imagetops と imagetoraster
rasterto [プリンター固有]
CUPSバックエンド
cupsomatic/foomaticの役割
完全な図解
mime.convs
Raw印刷
application/octet-stream 印刷
非PostScriptプリンターのためのPostScriptプリンター記述
cupsomatic/foomatic-ripネイティブなCUPS印刷
フィルタリングチェインの例
CUPSドライバー/PPDの提供元
インタフェーススクリプトを伴う印刷
ネットワーク印刷(Windowsのみ)
WindowsクライアントからNT印刷サーバーへ
クライアント上でのドライバーの実行
サーバー上でのドライバーの実行
ネットワーク印刷(WindowsクライアントとUNIX/Samba印刷サーバー)
WindowsクライアントからCUPS/Samba印刷サーバーへ
Sambaによるジョブファイルの受け取りとCUPSへの引き渡し
ネットワーク PostScript RIP
UNIX上の、非PSプリンターのためのPPD
Windows上の非PostScriptプリンターのためのPPD
CUPSクライアントとしてのWindowsターミナルサーバー (WTS)
カーネルモードでのプリンタードライバーの実行は多くの問題を引き起こす
Workarounds Impose Heavy Limitations
CUPS: A Magical Stone?
カーネルモードでもPostScriptドライバーは大きな問題はない
ドライバーダウンロードを行うためのCUPSの設定
cupsaddsmb: 不明なユーティリティ
cupsaddsmb用のsmb.confの準備
Windows NT/200x/XP用のCUPSPostScript Driver
異なったドライバーファイルの認識
ドライバーファイルの入手
Windows NT/200x/XP用のESP Print Pro PostScriptドライバー
考慮すべき警告
WindowsのCUPS PostScriptドライバー対Adobeドライバー
cupsaddsmbの実行(Quiet Mode)
詳細な結果を表示するcupsaddsmbの実行
cupsaddsmbについて理解する
もしもcupsaddsmbが正しく終了した場合、どのように認識するか
Samba PDCににおけるcupsaddsmb
cupsaddsmbフローチャート
クライアント上でのPostScriptドライバーのインストール
クライアント上での危険なPostScriptドライバー設定を防止する
rpcclientを使ったPostScriptドライバーファイルの手動インストール
rpcclientマニュアルページのチェック
rpcclientマニュアルページの理解
Producing an Example by Querying a Windows Box
adddriverとsetdriverを完了させるための要求事項
15ステップでの手動ドライバーインストール
トラブルシューティング再考
印刷関連の*.tdbファイル
Trivial Database Files
バイナリ形式
*.tdbファイルの喪失
tdbbackupの使用
Linuxprinting.orgからのCUPSプリントドライバー
foomatic-rip と Foomaticの説明
foomatic-ripとFoomatic PPDのダウンロードとインストール
CUPSによるページの課金
Quotasの設定
正しいあるいは不正な課金
Windowsクライアント用のAdobeとCUPS PostScriptドライバー
page_logファイルの形式
存在する欠点
将来の構想
他のアカウントツール
追加の材料
CUPSスプールフィルタの自動削除または保存
CUPS構成の設定の説明
準備
手動の設定
Windowsに接続された印刷へのCUPSからの印刷
より詳細なCUPSフィルタリングチェーン
よくあるエラー
Windows 9x/Meクライアントがドライバーをインストール出来ない
cupsaddsmbが、無限にrootパスワードを問い合わせてくる
cupsaddsmbrpcclient addriverがエラーを出す
cupsaddsmbのエラー
クライアントがSambaプリンターに接続できない
Windows 200x/Xpからの新しいアカウント再接続のトラブル
間違ったユーザーでSambaサーバーに接続されるのを防ぐ
AdobeドライバーからCUPSドライバーにアップグレードする
PDCであるSambaサーバー上でcupsaddsmbが使えない
削除されたWindows 200xプリンタードライバーが引き続き表示されている
Windows 200x/XP ローカルセキュリティポリシー
Administratorはすべてのローカルユーザーに対してプリンターをインストールできない
NTクライアント上での印刷の変更、機能の通知
Windows XP SP1
Windows 200x/XP上ですべてのユーザーが印刷オプションを設定出来ない
Windowsクライアント上でのドライバー設定における、多くに共通する失敗
cupsaddsmbが、新しくインストールしたプリンターで動かない
/var/spool/samba/のアクセス許可が、再起動後毎回リセットされる
lpという名前の印刷キューが印刷ジョブを間違って扱ってしまう
cupsaddsmbに対するAdobe PostScriptドライバーファイルの位置
CUPS印刷プロセスの概要
23. スタッカブルVFSモジュール
機能と利便性
議論
含まれるモジュール
audit
default_quota
extd_audit
fake_perms
recycle
netatalk
shadow_copy
他で入手可能なVFSモジュール
DatabaseFS
vscan
vscan-clamav
24. Winbind: ドメインアカウントの使用
機能と利便性
はじめに
Winbindが提供するもの
対象となるユーザー
外部のSIDの取り扱い
Winbindの動き方
Microsoft Remote Procedure Calls
Microsoft Active Directoryサービス
Name Service Switch
Pluggable Authentication Modules
ユーザーとグループIDの割り当て
結果のキャッシュ保存
インストールと設定
はじめに
用件
テスト
結論
よくあるエラー
NSCDの問題に関する警告
Winbindがユーザーとグループを解決しない
25. 詳細なネットワーク管理
機能と利便性
リモートサーバー管理
リモートデスクトップ管理
NoMachine.Comによるリモート管理
ThinLincを使うリモート管理
ネットワークログオンスクリプトの魔法
ユーザーの干渉なしにプリンターを追加する
ログオン接続の制限
26. システムとアカウントポリシー
機能と利便性
システムポリシーの作成と運用
Windows 9x/ME ポリシー
Windows NT4形式のポリシーファイル
Microsoft Windows 200x/XP Professionalのポリシー
アカウント/ユーザーポリシーの管理
管理ツール
SambaのEditregツールセット
Windows NT4/200x
Samba PDC
システムスタートアップとログオン処理の概要
よくあるエラー
ポリシーが動かない
27. デスクトッププロファイルの管理
その特長と利点
移動プロファイル
プロファイル処理のための Samba の設定
Windows クライアントのプロファイル設定に関する情報
User Profile Hive Cleanup Service
Windows 9x/Me と NT4/200x/XP ワークステーション間でプロファイルを共有する
Windows NT4/200x サーバーから Samba にプロファイルを移行する
必須プロファイル
グループプロファイルの作成と管理
Windows ユーザーのデフォルトプロファイル
MS Windows 9x/Me
MS Windows NT4 Workstation
MS Windows 200x/XP
よくあるエラー
少人数のユーザーやグループのための移動プロファイルの設定
移動プロファイルを使えない
デフォルトプロファイルを変更する
移動プロファイルと NT4 スタイルのドメインポリシーのデバッグ
28. PAM ベースの分散型認証
その機能と利点
技術的な議論
PAM 設定のための文法
システム設定の例
smb.conf の PAM 設定
winbindd.soを使った遠隔 CIFS 認証
pam_smbpass.so を使ったパスワードの同期
よくあるエラー
pam_winbind の問題
Winbind がユーザーとグループを解決してくれない
29. Microsoft Windows ネットワークへのSambaの統合
機能と利便性
背景情報
純粋なUNIX/Linux環境中での名前解決
/etc/hosts
/etc/resolv.conf
/etc/host.conf
/etc/nsswitch.conf
Microsoft Windowsネットワーク内でのような名前解決
NetBIOSネームキャッシュ
LMHOSTSファイル
HOSTSファイル
DNSによる検索
WINSによる検索
よくあるエラー
片方向しかpingが届かない
ネットワーク接続がとても遅い
Sambaサーバー名前変更の問題
30. ユニコード/文字セット
機能と利便性
文字セットとユニコードとは何か
Sambaと文字セット
古い名前からの変換
日本語の文字セット
基本的なパラメーターの設定
個別の実装
Samba-2.2系列からの移行
よくあるエラー
CP850.so が見つからない
31. バックアップテクニック
特徴と利点
バックアップ手段についての議論
BackupPC
Rsync
Amanda
BOBS: Browseable Online Backup System
32. 高可用性
機能と利便性
技術的な議論
最終目的
これがなぜ難しいか?
簡単なソリューション
高可用性サーバー製品
MS-DFS: 貧者のクラスター
結論
33. 大きなディレクトリの取扱い
34. 詳細設定のテクニック
実装
複数のサーバーのホスティング
複数仮想サーバーの性質(Personalities)
複数の仮想サーバーホスティング

Chapter 9. Samba 3.xシリーズにおける重要で重大な変更点

John H. Terpstra

Samba Team

Gerald (Jerry) Carter

Samba Team

Sambaをアップデートまたはアップグレードする前に、この章を注意深く読んでほしい。 ここにはとても重大か、とても重要な情報のみが書いてある。包括的な変更記録とガイ ダンス情報は Sambaのアップデートとアップグレード の章にある。

重要な Samba-3.2.x の変更点

!!!!!!!!!!!!Add all critical update notes here!!!!!!!!!!!!!

重要な Samba-3.0.x の変更点

以下の記述は、特にSamba 3.0.23からSamba 3.0.25c(あるいはより最新のSamba 3.0.25の更新版) に関連する。Sambaは常に変化しているプロジェクトである。3.0.xシリーズ中での変更点は、 この文書中で記述されている。 Upgrading from Samba-2.x to Samba-3.0.25 を参照のこと。

時々、HOWTO文書の、新しい、あるいは変更された機能の影響を反映するために更新すべき部分を 指示するのが難しいことがある。あるいは別の時点では、この文書を再構成することが必要で あることが明白になる。

近年では、Samba のユーザーも Samba Wiki 構築の推進に加わった。新しく作成される Samba ドキュメントは、すべてここに集約 される予定である。Wikiは規模の大きなコミュニティからの投稿に適していて、より いっそう最新情報を提供できることを期待している。そのすばらしい夢が実現して、 十分な価値が出てくるまでは、このHOWTO文書を維持管理することは必要である。 この章では、このHOWTO文書の主要部分が再構成されるか変更される時点までの間 での主要な変更点を文書化する。

この章は、Samba 3.0.23リリースでHOTWOに加わった。ここにはSambaソースコードリリース 一式中に含まれるWHATSNEW.txtファイル中で提供されているたくさんの 注意点を含んでいる。

ユーザーとグループの変更

マップされていないユーザーとグループアカウントのみに影響する変更点はここで文書化されている。

ユーザーとグループに対する内部管理ルーチンは割り当てられた相対識別子(RID) の重複を防ぐために書き直された。過去では、net groupmapコマンド 又はnet rpc vampireコマンドで net rpc vampire を実行してWindowsドメインをSambaドメインにマイグレートすることによって、 手動でUnixグループにマッピングするときに問題が発生する可能性があった。

マップされていないユーザーは、今回からS-1-22-1ドメイン中の SIDが割り当てられ、マップされていないグループはS-1-22-2ドメイン 中のSIDを割り当てられる。以前はSambaサーバー上のSAM内のRIDを割り当てていた。 ドメインコントローラーにとって、これは、メンバーサーバーかスタンドアロンサーバー上のような ドメインSIDの権限の配下にあり、これはローカルSAM(net getlocalsid マニュアルページを参照)の権限下にあった。

結果は、アップグレードされたSambaドメインコントローラー上の、あるマップされていない ユーザー又はグループは新しいSIDを割り当てられることになる。Windowsセキュリティ 記述子中に名前というかSIDが格納されるので、これは、そのユーザーが たとえば、Sambaファイルサーバーからローカルの WindowsクライアントNTFSパーティションにファイルがコピーされた場合、もはやリソースに アクセスできないという現象を引き起こす。Sambaサーバー上自身で格納された任意のファイル は、UNIXがUNIXのGIDを格納し、権限の検査にSIDを使わないために引き続きアクセスできる。

変更を図示するのに例題が役立つ:

developersという名前のグループがありそのUNIX GIDが782だと する。この場合、このグループはSambaのグループマップテーブル中には存在しない。 このグループがACLエディター中に現れることは全く通常通りである。Samba-3.0.23より 前では、グループSIDは S-1-5-21-647511796-4126122067-3123570092-2565として 表示される。

Samba-3.0.23のリリースから、グループSIDはS-1-22-2-782のよう に表示されるようになった。任意の、Windows NTFSパーティション上に格納されるファイルに付 随するセキュリティ記述子は、ユーザーが S-1-5-21-647511796-4126122067-3123570092-2565グループ のメンバーでない場合、グループパーミッションベースのアクセスを許可されない。 このグループSIDがS-1-22-2-782で、ユーザートークン中に 表示されないという理由で、たとえ両方のSIDが同じUNIXグループを参照する という観点においても、Windowsは認証に失敗する。

Samba 3.0.23より前での回避方法は、グループdevelopersS-1-5-21-647511796-4126122067-3123570092-2565という SIDを示すグループマップエントリを手動で作成することである。Samba-3.0.23 のリリースから、この回避方法は不要になった。

グループマッピングの基本

Samba 3.0.xシリーズの3.0.23より前のリリースでは、 Domain Admins, Domain Users, Domain GuestsというWindows ドメイングループに対するグループマッピングは自動的に作成された。Samba-3.0.23 から、これらのマッピングはSamba管理者によって作成されなければならないように なった。これが失敗すると、正しい認証と、有効なドメインユーザーの認識に失敗する 結果となる。これが起きた場合、ユーザーはWindowsクライアントにログオンできなくなる。

Note

グループマッピングは、SambaサーバーがPDC/BDCとして動作している時にのみ重要である。 スタンドアロンサーバーはグループマッピングを必要としない。

以下のマッピングが必要である:

Table 9.1. 基本的なドメイングループのマッピング

Domain GroupRIDUNIXグループ例
Domain Admins512root
Domain Users513users
Domain Guests514nobody

POSIX(UNIX)グループがLDAP内に格納される場合、それぞれ domadmins, domusers,domguestsと指定すると 便利である(訳注:やや意訳です)。

グループマッピングに関するさらなる情報は グループマッピング: Microsoft Windows と UNIXを参照のこと。

Passdbの変更

もはやpassdb backendパラメーターは、複数のpassdbバックエンドを 連続して設定できない。SQLとXML passdbバックエンドもSamba-3.0.23のリリースから取り除 かれた。外部のSQL passdb サポートについてのより詳細な情報は pdbsqlページを参照のこと。

Samba-3.0.23でのグループマッピングの変更

Domain Adminsのようなグループのための既定値のマッピングエントリは もはやsmbpasswdファイルかtdbsam passdbバックエンド を使う時に作成されない。このことは、グループマッピングを作成するためには、明示的に net groupmap addコマンドを実行することが必要であると言うことであり、 WindowsのグループSIDをUNIXのGIDへのマッピングを作成するために、 net groupmap modifyを使うということである。この変更は ドメイングループに対するwinbinddのIDMAP機能には何らの影響はない。

Samba-3.0.23におけるLDAPの変更

Samba LDAPスキーマファイルに少々の変更がある。sambaSID 属性定義にサブストリングマッチルールが追加された。OpenLDAPでは、これは、 slapd.conf設定ファイルにindex sambaSID sub を追加することが必要となる。実際のデータの内容については変更はない。

Chapter 10. ネットワークブラウジング

John H. Terpstra

Samba Team

Jelmer R. Vernooij

The Samba Team

Jonathan Johnson

Sutinen Consulting, Inc.

July 5, 1998

Updated: September 20, 2006

この章にはサブネット越しあるいはワークグループ(ドメイン)越しのブラウジング を実行するための早わかりと、さらに詳細な情報を含んでいる。WINSはNetBIOS名 からIPアドレスへの名前解決のために最適のツールである。しかし、WINSは 名前->アドレス解決方法を除いてブラウズリストの扱いを改善するわけではない。

Note

WINSとは何か?

WINSはNetBIOS名をそのIPアドレスに名前解決する機能を提供する。WINSはNetBIOS ネットワーク名のための動的DNSサービスに似ている。

Note

Microsoft Windows 2000とそれ以降のバージョンでは、NetBIOS over TCP/IPなしで 操作するように設定できる。Samba-3とそれ以降のバージョンもこの操作モードを サポートしている。NetBIOS over TCP/IPが無効になっている場合、Microsoft Windows マシン名の解決を行う主要な手段はDNSとActive Directory経由である。 以下の情報は使用するサイトでNetBIOS over TCP/IPが動いていることを仮定している。

機能と利便性

Charles Dickensはかつて次のような名言を言った: それはすべての時世の中で最もよい時世でもあれば、 すべての時世の中で最も悪い時世でもあった。 (訳注:二都物語の冒頭部分:佐々木 直次郎訳、青空文庫より) 振り返れば振り返るほど、あったことをより切望するが、それが決して 戻らないことを望む。(訳注:かなり怪しい)

多くのMicrosoft Windowsネットワーク管理者に対し、その一節はNetBIOSネットワーキングに ついて感じていることを要約している。NetBIOSネットワーキングをマスターした人にとって、 その気まぐれな性質はよくあることである。そのやんちゃな性質を押さえ込むことが全く 管理できない人にとって、NetBIOSはパターソンののろいのようである。

オーストラリアの植物問題をよく知らない人のために、パターソンののろい、すなわち エキウム・プランタギネウムは19世紀の中頃、ヨーロッパから オーストラリアに導入された。それ以来、急激に広まった。種がたくさん出来、 平方メートルあたり何千の密度で、種の寿命は7年以上もあり、年中発芽する能力があり、 正常な条件がそろえば、持続的に雑草として生える能力がある。

この章では、動いているNetBIOS(Network Basic Input/Output System) over TCP/IP を通して実装されているSMBに注目するServer Message Block (SMB)ネットワーキング の不可欠な側面を探求する。Sambaは他のプロトコル上でSMBまたはNetBIOSを実装 していないので、ネットワーク環境で、どのように設定をするかを知る必要があり、 また、すべてのMicrosoft ネットワーククライアント上でTCP/IP以外のものを使う ことはないことを単に覚えておけばよい。

SambaはWINS(Windows Internetworking Name Server)を実現することと、Microsoft のWINS拡張を実現する能力を提供する。これらの拡張は、通常の範囲のMicrosoft WINS を超えて安定したWINS動作を提供することを支援する。

WINSはNetBIOS overTCP/IPが動作しているシステムにのみ適用される サービスである。Microsoft Windows 200x/XPはNetBIOSが無効でも 動作することが出来る。そのような場合、WINSは無関係となる。Sambaは これもサポートする。

NetBIOSが無効になったこれらのネットワークでは(すなわち、WINSを必要としない)、 ホスト名の解決のためにDNSを使うことが必要である。

ブラウジングとは何か?

一般的には、ブラウジングとは、Microsoft WindowsとSambaサーバーがマイネットワーク中に 見える事を意味し、特定のサーバーのコンピュータアイコンをクリックすると、その サーバー上の共有と有効なプリンターを表示するウィンドウが開いて表示される。

とても単純に見えるが、これは実際には、異なった技術の複雑な相互作用によるもの である。これらのすべてを行うために使われる技術(か方式)は以下を含む:

  • ネットワークへのMicrosoft Windowsマシンの存在を登録。

  • ネットワーク上の他のマシンにそれ自身を通知。

  • ネットワーク上の複数の1つ以上のマシンはローカルアナウンスメントをまとめる。

  • クライアントマシンはマシンのリストをまとめたマシンを見つける。

  • クライアントマシンはマシン名をIPアドレスに変換する。

  • クライアントマシンはターゲットマシンに接続する。

ブラウズリスト管理と名前解決を制御するSambaアプリはnmbdである。 nmbdの動作に関連する設定パラメーターは以下の通り:

ブラウジング動作:

名前解決方法:

WINS動作:

(*)というマークが付いたものは通常変更が必要なオプションである。これらのパラメーターが 設定されていなくても、nmbdは動作することが出来る。

Sambaでは、wins server と wins support は相互に排他的なオプションである。 nmbdが起動するとき、smb.confファイル中に両方の オプションが設定されていると、起動に失敗する。nmbd は、それ自身のWINSサーバーを使わなければならないWINSサーバーとして動作する ために、それ自身のインスタンスをフォークする。

議論

すべてのMicrosoft Windows ネットワークは SMBベースのメッセージングを使う。 SMBメッセージングはNetBIOSがあってもなくてもよい。Microsoft Windows 200x は下位互換のために、NetBIOS over TCP/IPをサポートする。Microsoftは段階的に NetBIOSサポートを打ち切っているように見える。

NetBIOS over TCP/IP

Sambaは、TCP/IP上でカプセル化することによって、Microsoft Windows NT/200x/XPが するようなNetBIOSを実装している。NetBIOSベースのネットワークはブラウズリストの 管理を行うために、ブロードキャストメッセージングを使う。NetBIOS over TCP/IP が動いている時、これはUDPベースのメッセージングを使う。UDPメッセージは ブロードキャストかユニキャストのどちらも使える。

通常、ユニキャストUDPメッセージングのみがルータによって転送される。 smb.confのremote announceパラメーターはユニキャストUDB を通じて、リモートネットワークセグメントにブラウズアナウンスメントを公開する ことを支援する。同様に、smb.confremote browse sync パラメーターはユニキャストUDPを使ってブラウズリストの収集を実現する。

名前検索要求(名前解決)を実行するためにMicrosoft Windowsによって使われる方法 はNetBIOSノードタイプと呼ばれる設定パラメーターによって決まる。基本的なNetBIOS ノードタイプは4つある:

  • b-node (type 0x01):UDPブロードキャストを 使ってNetBIOSブロードキャスト要求のみを使うWindowsクライアント。

  • p-node (type 0x02):WINSサーバーに直接UDP ユニキャストを行う、ポイントツーポイント(NetBIOSユニキャスト)要求を使う Windowsクライアント。

  • m-node (type 0x04):、最初にUDPブロード キャストを使ってNetBIOSブロードキャストを行い、次に(NetBIOSユニキャストで) WINSサーバーに直接UDPユニキャストを行うWindowsクライアント。

  • h-node (type 0x08):UDPユニキャスト (NetBIOSユニキャスト)を使ってWINSサーバーに直接要求し、次にUDPブロードキャストを 使ってNetBIOSブロードキャスト要求をするWindowsクライアント。

既定値のWindowsネットワーククライアント(あるいはサーバー)のネットワーク設定は、 NetBIOS over TCP/IPを有効にしていて、b-ノードになっている。WINSを使うと、 WINSが故障か有効になっていない場合、クライアントがブロードキャストベースの 名前解決を使えるように、h-ノード(ハイブリッドノード)動作が意味をなすようになる。

SambaがSMBサーバー技術のみのネットワーク中ではnmbd のうち少なくとも1台はWINSサーバーとして設定する必要がある。これは、 ブラウジング環境の管理を簡単にする。もしもおのおののネットワークセグメントが 固有のSamba WINSサーバーを設定している場合、セグメント間のブラウジングを動作させ る唯一の方法はremote announceremote browse syncパラメーターをsmb.confファイルで 使うことである。

もしも全体の複数ネットワークで1つだけのWINSサーバーを使う場合、 remote announceremote browse syncパラメーターの使用は必須ではない。

Samba-3では、WINS複製は作業中である。大量のコードがコミットされていたが、 まだ改良が必要である。Samba-3.0.20のリリース時点ではまだサポートされた機能では ない。希望としては、Samba-3のどこかのリリース時点でサポートされた機能になること を予定している。開発者がこれを完了させようと思うほどの、十分な重要性がないとい う理由で、これは遅れている。

現時点で、SambaのWINSはMS-WINS複製をサポートしていない。これは、SambaをWINSサー バとして設定しても、ネットワーク上で、1つだけnmbdをWINSサーバーとして 設定する必要がある。あるサイトでは(サブネット単位に1つのサーバーを)冗長性のために、 複数のSamba WINSサーバーを使っていて、セグメントをまたいですべてのセグメントの ブラウズリストを集めるために、remote browse syncremote announceを使っている。 この設定では、クライアントがローカル名の解決のみが出来るので、他のサブネット上 を見ることができる、サーバーのIPアドレスを解決するために他のサブネット上の名前を 解決するためのDNSを使うように設定しなければならない。この設定は推奨されないが、 実用的なやり方として(すなわち、もしも他の場合がすべて失敗の場合 というシナリオ)、記述されている。NetBIOS over TCP/IPはとてもひどくて管理しにく いプロトコルである。この置き換えとして、NetBIOSless SMB over TCP/IP is not without its own manageability concerns. NetBIOSベースのネットワークは妥協とトレードオフの固まりである。WINSは DNSに格納出来ない情報を格納する。従って、DNSはNetBIOS over TCP/IPが 使われている時にWINSから得られるものよりも貧弱な代わりにしかならない。 WindowsクライアントはWINSを使うように設計されている。

最後に、ブラウズリストは15分間よりも短い間隔で繰り返される信頼性のない ブロードキャストメッセージの集合から校正されていることに注意。これは、 ブラウズリストを作成するために時間がかかると言うことであり、特に、 ネットワークセグメントをまたぐ場合は、安定するまでには45分かかる可能性が あるということである。

Microsoft Windows 200x/XPシステムでホスト名をIPアドレスに解決しようとする場合、 以下の手順で行う:

  1. hostsファイルを調べる。これは%SystemRoot%\System32\Drivers\etcにある。

  2. DNS 検索を実行する。

  3. NetBIOSネームキャッシュを調べる。

  4. WINSサーバーに問い合わせる。

  5. UDPでブロードキャストの名前検索を行う。

  6. %SystemRoot%\System32\Drivers\etcにあるLMHOSTSファイルのエントリを調べる。

どのようにNetBIOS over TCP/IPプロトコルが実装されているを考えた上で、WINSのみが、 TEMPTATION<1C> というネットワークログオンサーバーを探すための NetBIOS名前問い合わせのようなサービス指向の名前の、信頼性のある名前検索を解決す る能力を持つ。実際、Microsoft ADSでの実装は特に拡張されたサービス指向のDNSエン トリ全体を管理するようになっている。このタイプの機能はNetBIOS over TCP/IPプロト コルの名前空間では実装も、サポートもされていない。

TCP/IPなしのNetBIOS

すべてのTCP/IPが有効なシステムは、いろいろなホスト名解決方法を使う。TCP/IPの ホスト名解決で最初に使う方法は固定のファイル(/etc/hosts) かDNSである。DNSはインターネットを使えるようにする技術である。DNSベースのホスト 名解決はほとんどすべてのTCP/IPが有効なシステムでサポートされている。ごくわずか の組み込みシステムのみがDNSのサポートをしていない。

Windows 200x/XPはダイナミックDNSサーバー(DDNS)にそのホスト名を登録できる。 Windows 200x/XP上で ipconfig /registerdnsを使うことで、 ダイナミックDNSサーバーに強制的に登録できる。

Active Directoyでは、正確に動作しているDNSサーバーが確実に必要である。正しく設定 されていて動作しているDNSサーバーがない場合、Microsoft Windows クライアントとサー バはお互いを認識できず、そのためネットワークサービスはひどく使い物にならないだ ろう。

raw SMB over TCP/IP(NetBIOSレイヤなし)の使用は、Active Directoryドメインのみで 行える。SambaはActive Directory ドメインコントローラーではない:故に、NetBIOSを 使わないで同じ時にSambaをドメインコントローラーとして動かす のは不可能である。SambaをActive Directoryのメンバーサーバー(DMS)として動かしているとき、 NetBIOS over TCP/IPを使わないでSambaを設定することは可能である。Samba DMSは Active Directoyドメインに完全に統合できるが、もしも、NetBIOS over TCP/IPが無効 の場合、SambaまたはADS環境のどちらかで自動的に生成されないという理由で、Samba DMS用に適切なDNSエントリを手動で作成する必要がある。

DNSとActive Directory

時折、Microsoft DNSサーバーの代わりにUNIXベースのDDNSサーバーを使いたいというUNIXネッ トワーク管理者の要望を聞くことがある。これが誰かにとって都合がよい間、Microsoft Windows 200x DNSサーバーはActive Directoryと共に動作するように自動的に設定される。 BIND 8または9を使うのは可能だが、Microsoft Active Directoryクライアントが基本的 なネットワークサービスを確実に使えるために、ホスト名を解決できるために、サービ スレコード(SRVレコード)を確実に作成することがほとんど必要となる。以下は、 Active Directoryが要求する既定値のサービスレコードのいくつかである:

Active Directoryで必要とされるSRV(サービス)レコードを十分にサポートする能力を BIND9を使うときに望まれるため、Active DirectoryでDDNSを使うことは強く推奨される。 もちろん、ADSが動いているとき、ADSとMicrosoft DNSの間で自然な類似性があるという 理由で、Microsoft固有のDDNSサーバーを使うことは意味があることである。

_ldap._tcp.pdc._msdcs.Domain

これは、ドメイン内のWindows NT PDCアドレスを提供する。

_ldap._tcp.pdc._msdcs.DomainTree

ドメイン内のグローバルカタログのアドレスを解決する。

_ldap._tcp.site.sites.writable._msdcs.Domain

サイト上のドメインコントローラーの一覧を提供する。

_ldap._tcp.writable._msdcs.Domain

Enumerates list of domain controllers that have the writable copies of the Active Directory data store.

_ldap._tcp.GUID.domains._msdcs.DomainTree

グローバルな一意の識別子を使うマシンをクライアントが認識するためにMicrosoft Windowsによって使われるエントリ。

_ldap._tcp.Site.gc._msdcs.DomainTree

サイト設定に依存するグローバルカタログサーバーをクライアントが認識するためにMicrosoft Windowsによって使われる。

サンプルのドメインquenya.orgのために基本的なサービスを Microsoftクライアントが認識するために使われる特定のエントリは以下を含む:

  • _kerberos._udp.quenya.org UDP経由でKDCサーバーに接続す るために使われる。のエントリはおのおののKDC向けにポート88にしな ければならない。

  • _kpasswd._udp.quenya.org ユーザーのパスワード変更処理を 行わなければならない時にkpasswdサーバーを見つけるときに使う。 このレコードはマスターKDCのポート464でなければならない。

  • _kerberos._tcp.quenya.org TCP経由でKDCサーバーを見つけ るときに使う。このエントリはおのおののKDCでポート88でなければならない。

  • _ldap._tcp.quenya.org PDC上でLDAPサービスを見つける のに使う。このレコードはPDCのためにポート389でなければならない。

  • _kpasswd._tcp.quenya.org ユーザーパスワード変更を行う ことを許可するためにkpasswdを探すときに使う。これはポート 464でなければならない。

  • _gc._tcp.quenya.org グローバル型ログサーバーを探すとき に使う。これはポート3268でなければならない。

以下のレコードも、Windows ADS ドメインコントローラー上の重要なサービスを 探すために、Windowsドメインクライアントによって使われる。

  • _ldap._tcp.pdc._msdcs.quenya.org

  • _ldap.gc._msdcs.quenya.org

  • _ldap.default-first-site-name._sites.gc._msdcs.quenya.org

  • _ldap.{SecID}.domains._msdcs.quenya.org

  • _ldap._tcp.dc._msdcs.quenya.org

  • _kerberos._tcp.dc._msdcs.quenya.org

  • _ldap.default-first-site-name._sites.dc._msdcs.quenya.org

  • _kerberos.default-first-site-name._sites.dc._msdcs.queyna.org

  • SecID._msdcs.quenya.org

正しいDNSエントリの存在は以下を実行することによって検証できる:

root#  dig @frodo -t any _ldap._tcp.dc._msdcs.quenya.org

; <lt;>> DiG 9.2.2 <lt;>> @frodo -t any _ldap._tcp.dc._msdcs.quenya.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3072
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2


;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.quenya.org. IN        ANY


;; ANSWER SECTION:
_ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 frodo.quenya.org.
_ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 noldor.quenya.org.


;; ADDITIONAL SECTION:
frodo.quenya.org.  3600  IN      A       10.1.1.16
noldor.quenya.org. 1200  IN      A       10.1.1.17


;; Query time: 0 msec
;; SERVER: frodo#53(10.1.1.16)
;; WHEN: Wed Oct  7 14:39:31 2004
;; MSG SIZE  rcvd: 171

どのようにブラウジングは機能するか

Microsoft WindowsマシンはそのNetBIOS名を起動時に登録する(すなわち、動作に対する おのおののサービスタイプのためのマシン名)。この名前登録の正確な方法は、 Microsoft Windowsクライアント/サーバーにWINSサーバーアドレスが与えられているか否か か、LMHOSTS検索が有効になっているか否か、NetBIOS名の名前解決にDNSを使うかどうか か否か、あるいはその他によって決まる。

WINSサーバーがない場合、名前検索と同様、すべての名前登録は、UDPブロードキャストに よって行われる。これは、すべての名前とIPアドレスの一覧を用意するLMHOST を使う以外、ローカルサブネット単位で分割した名前解決を行う。このような状態で、 リモートのMicrosoft Windowsネットワークのブラウズリスト中にSambaサーバーの名前を 強制的に入れ込むことによる方法を提供する (remote announceを使って)。

WINSサーバーを使う場合、Microsoft Windows蔵案とはWINSサーバーにUDPユニキャストで名 前を登録する。このようなパケットはルーティング出来、WINSはルーティングされたネッ トワークを超えて名前解決が出来る。

スタートアップ処理中、すでに存在していなければ、ローカルマスターブラウザー(LMB)の 選定が起こる。おのおののNetBIOSネットワークで、ある1つのマシンがドメインマスター ブラウザー(DMB)として機能するように選択される。このドメインブラウジングは、 Microsoftセキュリティドメインコントロールとは何らの関係もない。その代わり、DMB は(WINSまたはLMHOSTを使って見つけた)おのおののLMBに接続する役割を行い、ブラウズ リストの内容を交換する。このようにして、すべてのマスターブラウザーは、結果として、ネットワーク 上にあるすべてのマシンの完全な一覧を得ることになる。毎11から15分ごとに、どのマ シンがマスターブラウザーになるかという選択が行われる。使用される選択基準の性質によ り、最も大きなuptime、あるいは最も上位のプロトコルバージョン、あるいは、そのた の基準を持つものがDMBとして選択される。

WINSサーバーが使われているとき、DMBはそのIPアドレスをドメインの名前とNetBIOS名前 タイプ1B(すなわちDOMAIN<1B>)を使ってWINSサーバーに登録する。WINSサーバーを使 うすべてのLMBも、ドメインの名前とNetBIOS名前タイプ1Dを使ってそのIPアドレスを登 録する。タイプ1Bの名前はドメインセキュリティコンテキスト内であるサーバー1つだけに 割り当てられ、たった1つのタイプ1Dの名前がおのおののネットワークセグメントで登録 される。タイプ1Dの名前を登録したマシンは、そのマシンがいるネットワークセグメン トにおける、ブラウズリストメンテナの権限を持つ。DMBはLMBから得られたブラウズリ ストを同期させることに責任がある。

ネットワークをブラウズしようとするクライアントは、このリストを使うが、有効なIP アドレスへの名前解決の有効性に依存する。

Any configuration that breaks name resolution and/or browsing intrinsics will annoy users because they will have to put up with protracted inability to use the network services.

Sambaはsmb.confファイル中にremote browse sync パラメーターを使うことで、ルーティングされたネットワーク越しにブラウズリストの 同期を強制的に行う機能をサポートしている。この機能のためにSambaはリモートネットワーク上 のLMBに接続し、ブラウズリストの同期を要求する。これはルータによって分離された2 つのネットワークを効果的に接続する。2つのリモートネットワークはブロードキャスト ベースの名前解決か、WINSベースの名前解決のどちらを使っても良いが、 remote browse syncパラメーターがブラウズリストの同期を提 供するが、それは名前からアドレスへの解決とは異なることに注意する必要 がある。別の言い方をすると、サブネット間のブラウジングをきちんと機能させるため には、名前解決メカニズムが提供されていることが基本であるということである。この メカニズムとはDNS、/etc/hosts、あるいはその他である。

ワークグループのブラウジングの設定

ネットワークが、NTドメインでない、ワークグループに属するマシンを含むサブネット 間のブラウジングを設定するために、ある1つのSambaサーバーをDMBにする必要がある( NTドメイン中では両方の役割を同じマシンが担うが、これはPDCとは違うと言うことに注 意)。DMBの役割はワークグループ中に参加しているマシンがあるすべてのサブネット上 のLMBからブラウズリストを収集することである。DMBとして設定されたマシンがないと、 おのおののサブネットは分離された、他のサブネットのマシンを見ることができないワー クグループとなってしまう。これが、ワークグループに対してサブネット間ブラウジングをさせ るDMBの存在理由である。

ワークグループ環境で、DMBはSambaサーバーでなければならず、ワークグループ名につき1 つのDMBでなければならない。SambaサーバーをDMBとして設定するためには、smb.conf ファイル中の[global]セクションに以下のオプションを記述 する:

domain master = yes

DMBはそれがいるサブネット上でのLMBであるべきである。これを達成するためには、 smb.confファイル中の[global]セクション中に、 ドメインマスターブラウザーのsmb.conf で示されるオプションを設定する:

Example 10.1. ドメインマスターブラウザーのsmb.conf

[global]
domain master = yes
local master = yes
preferred master = yes
os level = 65

必要であれば、DMBはWINSサーバーと同じマシンでも良い。

次に、ワークグループに対するLMBとして振る舞うことが出来るマシンを、おのおののサ ブネットごとに存在するようにする。任意のWindows NT/200x/XPマシンはこれが出来、 Windows 9x/Meマシン(しばしばリブートの必要があるため、この目的に使うのには適さ ないが)もできる。SambaサーバーをLMBにするには、以下の、 ローカルマスターブラウザーのsmb.confで示されているよ うに、smb.confファイルの[global]セクション中に以下の オプションを記述する。

Example 10.2. ローカルマスターブラウザーのsmb.conf

[global]
domain master = no
local master = yes
preferred master = yes
os level = 65

おのおののサブネットごとに1つ以上のSambaサーバーに対してこれを行わないこと。そう しないと、LMBになるための競合が発生してしまう。

local masterパラメーターはSambaに、LMBとして機能するように させる。preferred masterは、nmbdに対 して起動時にブラウザー選択を強制的に実行するようにさせ、 os levelパラメーターは、Sambaが、ブラウザー選択に勝つために 必要十分となる大きな値を設定する。

もしもLMBにしたいNTマシンがサブネット上にある場合、以下の、 マスターブラウザーにならないsmb.confで 示されているように、smb.confファイル中の[global] セクション中に、以下のパラメーターを設定して、SambaがLMBにならないようにする。

Example 10.3. マスターブラウザーにならないsmb.conf

[global]
domain master = no
local master = no
preferred master = no
os level = 0


ドメインブラウジングの設定

もしも、Windows NTドメインにSambaサーバーを追加する場合、SambaサーバーをDMBとして設 定してはならない。既定値では、ドメインに対するWindows NT PDCはそのドメインに対 するDMBでもある。WINSを使って、DMB NetBIOS名 (DOMAIN<1B>)をSambaサーバーがPDCとして登録すると、 ネットワークブラウジングは崩壊する。

Windows NT PDCを含んでいる以外のサブネットでは、Sambaサーバーを説明しているように LMBとして設定しても良い。SambaサーバーをLMBにするためには、以下の ローカルマスターブラウザーにするためのsmb.conf のように、smb.confファイル中の[global]セクション中に 以下のオプションを設定する。

Example 10.4. ローカルマスターブラウザーにするためのsmb.conf

[global]
domain master = no
local master = yes
preferred master = yes
os level = 65

もしも、同じサブネット上のマシンとの間で選択作業を行いたいのであれば、 os levelパラメーターをより小さな値に設定しても良い。 これを行うことで、LMBになり得る、動いているマシンの順番を調整することができる。 より詳細については 強制的にSambaをマスターにする を参照のこと。

もしもすべてのサブネット上でのドメインのメンバーであるWindows NTマシンがあり、 それが常時確実に動いているならば、以下で示される、 マスターにブラウザーにならないsmb.conf のように、smb.confファイル中の[global] セクション中で以下のオプションを指定することで、Sambaがブラウザー選択を しなくなり、LMBに絶対にならないようにすることができる。

Example 10.5. マスターブラウザーにならないsmb.conf


強制的にSambaをマスターにする

マスターブラウズになるマシンはブロードキャストを使った選択プロセスで決められる。 各選択パケットには選択作業において、ホストがどのような優先項目(バイアス)を持つ べきかを決定するための、たくさんのパラメーターを含んでいる。既定値では、Sambaは、 各Windowsサーバー又はクライアントについて、低い優先度を持ち結果として選択からは外 れる。

Sambaを選択したい場合には、smb.conf中のos levelグロー バルオプションをより大きい数字に設定する。既定値では20である。34を使うと、他の すべてのシステム(他のSambaシステムを除く)との選択に勝つ。

os levelが2の場合はWindows for Workgroupsと Windows 9x/Meに勝つが、Microsoft NT/200x サーバーには勝てない。Microsoft Windows NT/200x サーバーのドメインコントローラーはレベル32を使う。os levelの最大値は255である。

もしも、起動時にSambaに選択を強制させたいならば、smb.conf中の preferred masterグローバルオプションを yesに設定する。Sambaは優先マスターブラウザーでない、他のポテン シャルマスターブラウザーよりも若干の優位性を持つようになる。これは注意深く使うこと。 そうしないと、同じローカルサブネット上でpreferred masteryesに設定した2つのホスト(Windows 9x/MeかNT/200x/XPかSamba) があった場合、LMBになるための強制的な選択が、定期的かつ継続的に発生してしまう。

もしも、SambaをDMBにしたいならば、ブロードキャストが届かな い分離されたサブネット上のLMBでもない、LANまたはWAN全体のDMBにSambaがならないと いう理由で、 preferred masteryesに設定するこ とを推奨する。

2つのSambaサーバーがドメイン用にDMBになるように試みることは出来る。最初のサーバーは DMBになる。その他のすべてのサーバーは5分ごとにDMBになるように試行する。それらは、 すでに他のSambaサーバーがDMBであることを見つけて失敗する。これは、現在動いている DMBが故障したときに、自動的な冗長性を提供する。ブラウザー選択のネットワークバンド 幅のオーバーヘッドは相対的に小さく、おおよそ1つの選択ごとかつ1つのマシンごとに4つのUDPパ ケットを要求する。最小のUDPパケットは576バイトである。

Sambaをドメインマスターにする

ドメインマスターブラウザーは複数のサブネットのブラウザーリストを集めることに責任があ り、それゆえ、サブネット間でのブラウジングが可能になる。smb.conf中に domain master = yesを設定することで、Samba をドメインマスターブラウザーにすることが出来る。既定値では、ドメインマスターになる設 定ではない。

SambaをNT/200xドメインと同じ名前を持つワークグループ向けのドメインマスターに設定 してはならない。もしも、同じネットワーク上で同じ名前を持つWindows NT/200xドメイ ンと同じワークグループ名用にドメインマスターとしてSambaを設定すると、ネットワーク ブラウジングの問題が確実に発生する。

Sambaがドメインマスターでマスターブラウザーの場合、他のサブネット上のLMBからのマスター アナウンスをリッスンし(おおよそ12分間隔)、ブラウザーリストの同期を行うために、そ のマシンに接続する。

Sambaをドメインマスターにしたい場合、選択に勝つために、 os levelを十分に大きな値にすべきであり、 preferred masteryesにし、 起動時にSambaに強制的に選択を行わせるようにする。

(Sambaを含む)すべてのサーバーとクライアントは、NetBIOS名を解決するためにWINSサー バを使うべきである。もしもクライアントがNetBIOS名を解決するためにブロードキャス トのみを使うと、以下の2つが発生する:

  1. ローカルサブネットのみしか見えないため、LMBはDMBを見つけられなくなる。

  2. もしもクライアントがドメイン全体のブラウズリストを入手し、そのリストに あるホストにアクセスしようとした場合、そのホストに対するNetBIOS名の解決 が出来なくなる。

しかし、Sambaとクライアント両方がWINSを使う場合:

  1. LMBはWINSサーバーに接続し、SambaがDMBである間はWINSサーバーに登録を行い、 LMBはDMBとしてSambaのIPアドレスを受け取る。

  2. クライアントがドメイン全体のブラウズリストを入手し、ユーザーがそのリスト 中のホストに接続しようとしたとき、そのホストに対するNetBIOS名を解決する ために、WINSサーバーに接続する。同じWINSサーバーにホストのNetBIOS名が登録さ れている間はそのホストを認識することが出来る。

ブロードキャストアドレスについての注意

ゼロベースのブロードキャストアドレスをネットワークが使っている場合(たとえば、0 で終わる)、問題が発生する。Windows fore Workgroupはゼロベースのブロードキャスト をサポートしていないようなので、ブラウジングと名前検索が動かないだろう。

複数のインタフェース

Sambaは複数のネットワークインタフェースをサポートする。もしも複数のインタフェー スがある場合、smb.conf中のinterfacesオプションを使っ て設定を行う必要がある。たとえば、eth0, eth1,eth2, eth3 という4つのネットワークインタフェースを持つマシンがあり、 eth1eth4のみSambaが使う場合があったとす る。この場合、この意図に合わせるようにするためには、smb.confファイル中に以下 のエントリを記述する:

interfaces = eth1, eth4
bind interfaces only = Yes

bind interfaces only = Yesは指定されていな いインタフェース上でTCP/IPセッションサービス(ポート135,139と445)を含めない時に 必要である。nmbdはリストされていないポート上でのUDPポート137 から来るパケットをリッスンするが、それには返答しないことに気がつくこと。しかし ながら、リストされていないインタフェース上でブロードキャストパケットは送信する。 完全にイーサネットインタフェースを分離するには、Sambaサーバーがアクセスできないよ うにしなければならないすべてのネットワークインタフェース上で、ポート137と 138(UDP)、ポート135、139と445(TCP)をファイアウォール上でブロックすることが必要 である。

リモートアナウンスパラメーターの使用

smb.conf中のremote announceパラメーターは ネットワーク上のすべてのNetBIOS名がリモートネットワークにアナウンス されることを保証するために使うことが出来る。 remote announceパラメーターの文法は以下の通り:

remote announce = 192.168.12.23 [172.16.21.255] ...

or

remote announce = 192.168.12.23/MIDEARTH [172.16.21.255/ELVINDORF] ...

ここで:

192.168.12.23 and 172.16.21.255

はリモートネットワークのLMBのIPアドレスか、ブロードキャストアド レスである。これは、LMBが192.168.1.23か、ネットマスクが24ビット (255.255.255.0)であるときに172.16.21.255として与えられる。 リモートアナウンスがリモートネットワークのブロードキャストに対 して行われるとき、各ホストはこのアナウンスを受け取る。これはノイズであり、 好ましくないが、もしもリモートLMBのIPアドレスが分からないときには必要である。

ワークグループ

はオプションで、自ワークグループかリモートネッ トワークのワークグループを指定できる。リモートのネットワークの ワークグループ名を使う場合、自マシンのNetBIOS名はそのネット ワークに所属するように見えるようになる。これは名前解決問題 を引き起こしかねず、避けるべきである。

Remote Browse Syncパラメーターの使用

smb.confremote browse syncパラメーターは 手元のSamba LMBとの間で同期を取らなければならない他のLMBへアナウンスを行うのに 使用する。これは、そのネットワークセグメント上でSambaサーバーがが同時にLMBの時に のみ動作する。

remote browse syncパラメーターの文法は以下の通り:

ここで、192.168.10.40は、リモートのLMBのIP アドレスか、リモートセグメントのネットワークブロードキャストアドレスである。

WINS: The Windows Internetworking Name Server

WINSの使用(Samba WINS又はWindows NTサーバーWINS)は強く推奨する。 各NetBIOSマシンは、有効なサービスのサービスタイプの名前タイプの値と共に、 名前を登録する。ユニーク名(タイプ0x03)として名前を直接登録する。 また、LanManager互換のサーバーサービス(他のユーザーに対してファイル共有と プリンター共有を提供する)が動いているときには、サーバー名(タイプ0x20) を登録することによりその名前も登録する。

すべてのNetBIOS名は最大15文字である。名前タイプの値が名前の後に付加され、 合計16文字となる。15文字より小さい名前は15文字になるように空白が埋め込まれる。 そのため、すべてのNetBIOS名は16文字(名前タイプ情報を含め)である。

WINSは登録された16文字長の名前を格納できる。ネットワークにログオンしたい クライアントはNetLogonサービス名前タイプで登録されたすべての名前のリストを WINSサーバーに問い合わせる。これはブロードキャストトラフィックを減少し、 ログオン処理を高速化する。ネットワークセグメント越しにブロードキャスト による名前解決が出来ないため、このタイプの情報はWINSサーバーがいないときに、 すべてのクライアントが内包しなければならないlmhosts ファイルを固定的に設定するか、WINSサーバーによってのみ提供される。

WINSはすべてのLMBによってブラウズリストの同期を強制的に行う。LMBはDMB を使ってそのブラウズリストを同期し、WINSはそのDMBの識別をLMBに対して 手助けする。定義によって、これは単一のワークグループ内でのみ動作する。 DMBはMicrosoft NTドメインとして呼ばれているとは無関係であることに注意。 DMBがブラウズリスト情報のみに関してマスターコントローラーとしてDMBが言及する 間、後者はセキュリティ環境について言及する。

WINSは、WINSサーバーのためにすべてのTCP/IPプロトコルスタックが設定されて いる時のみ正しく動作する。あるクライアントがWINSサーバーを使うように設定 されておらず、ブロードキャストでの名前登録のみを引き続き使うようになって いる場合、WINSはそれを認識できない。この場合、WINSサーバーで名前登録を 行わないマシンは、他のクライアントによる名前-アドレス変換が失敗し、 それゆえ、ワークステーションへのアクセスエラーが発生する。

SambaをWINSサーバーとして設定するためには、 smb.confファイルの[global]セクションで、 wins support = yesを追加する。

SambaがWINSサーバーに登録するためには、smb.confファイルの [global]セクションで wins server = 10.0.0.18を追加する。

Important

特にその固有IPアドレスを指定して、 wins support = yesと一緒に、 wins server = 10.0.0.18 を使わないこと。両者を同時にsmb.confで指定すると起動しなくなる!

WINSサーバーの設定

SambaサーバーまたはWindows NTサーバーのどちらも、WINSサーバーとして設定できる。 SambaサーバーをWINSサーバーとして設定するためには、選択したサーバーのsmb.conf ファイルに以下を[global]セクションに追加しなけ ればならない:

wins support = yes

Samba 1.9.17より前のバージョンでは、このパラメーターは既定値でyesになって いる。もしも、ネットワーク上で古いバージョンのSambaを使っている場合、 最新のバージョンへのアップグレードを強く推奨する。そうしないと、 それらすべてのマシンでこのパラメーターをnoに設定しなければ ならなくなる。

wins support = yesを設定したマシンは、 登録されたすべてのNetBIOS名を保持し、NetBIOS名のためのDNSとして機能する。

単一のWINSサーバーを設定することを強く推奨する。ネットワーク上で2つ以上の サーバーに、wins support = yesを 指定しないこと。

Windows NT/200xサーバーをWINSサーバーとして設定するためにはWINSサービスを設定する。 詳細は、Windows NT/200xの説明書を参照のこと。Windows NT/200xのWINSサーバーは、 お互いに複製が出来、複雑なサブネット環境で2つ以上設定できる。Microsoftが 複製プロトコルの開示を行っていないため、Sambaは現在それらの複製機能に参加でき ない。Samba間同士のWINS複製プロトコルは将来作成する予定だが、その場合、2つ 以上のSambaマシンがWINSサーバーとして設定できるようになる。現在は、1台のみの Sambaサーバーがwins support = yesと設定 できる。

WINSサーバーを設定後、ネットワークに参加しているすべてのマシンはこのWINSサーバー のアドレスを設定するようにしなければならない。もしも、WINSサーバーがSambaマシン ならば、コントロールパネル->ネットワーク接続->ローカルエリア接続等-> プロパティ->インターネットプロトコル(TCP/IP)->プロパティ->詳細設定-> WINSダイアログ中のWINSアドレスフィールド にSambaマシンのIPアドレスを設定する(WindowsXPの場合)。SambaサーバーにWINS サーバーのIPアドレスを設定する場合には、すべてのsmb.confファイルの [global]セクションに以下を追加する:

wins server = <名前またはIPアドレス>

ここで、<名前またはIPアドレス>は、WINSサーバーのDNS名かそのIPアドレスである。

この行はSambaサーバー自身がWINSサーバーとして動作する場合に、smb.confファイル 中に設定してはならない。もしも wins support = yesオプションと wins server = <name>オプションを 同時に設定すると、nmbdは起動に失敗する。

サブネット間のブラウジングを設定するためには2つの方法がある。 最初のもの詳細は、Windows NTドメインの一部としては設定されていない、Windows9x/Me、 SambaとWindows NT/200xを含むネットワーク上でのサブネット間ブラウジングを 設定するものである。2番目のものの詳細は、NTドメインを含むネットワーク上 でのサブネット間ブラウジングを設定するものである。

WINS複製

Samba-3はWINS複製をサポートしていない。これを実装する試みはあり、 wrepldと呼ばれていたが、すでに開発は停止している。

一方、samba4WINSというプロジェクトがあり、これは、 Samba-3バージョン3.0.21から、Samba-4のWINSサーバーを並列に動かせるように するものである。samba4WINSに付いての詳細は、 http://ftp.sernet.de/pub/samba4WINS を参照のこと。

静的なWINSエントリ

Samba WINSサーバーに静的な円入折りを追加するのはとても簡単である。 通常/usr/local/samba/var/locks/var/run/sambaにある wins.datファイルに行を追加するだけである。

wins.dat中のエントリは以下の形式である:

"NAME#TYPE" TTL ADDRESS+ FLAGS

ここでNAMEはNetBIOS名、TYPEはNetBIOS名前タイプ、TTLはそのエントリの、秒単位の 生存時間、ADDRESS+は登録したい1つ以上のアドレス、FLAGは登録時に使うNetBIOS フラグである。

Note

nmbdを再起動するまで、wins.datへの変更は反映されない。 wins.datは動的に変更されるので、nmbdはこのファイルを 変更する前に停止しておかなければならないことに注意。このファイルを編集後、 nmbdを再起動するのを忘れないこと。

通常の動的エントリは以下のようになる:

"MADMAN#03" 1155298378 192.168.1.2 66R

NetBIOS名を静的に(恒久的に)するためには、以下のように、単純にTTLを0にする:

"MADMAN#03" 0 192.168.1.2 66R

NetBIOSフラグは16進数で、ビット単位に意味を持つ: 00 - Bノードの登録、20 - Pノードの 登録、40 - Mノードの登録、60 - Hノードの登録、02 - 恒久名、04 - アクティブ名、 80 - グループ名 である。'R'は登録レコードであることを表示する。そのため、 66Rは ハイブリッドノードで、アクティブで、恒久的なNetBIOS名であることを意味する。これら の値は、Sambaソースコードリポジトリのnameserv.hで定義されて いる。それらはNBフラグのための値である。

初期のSamba-3バージョンから、この方法は動作するが、WINS複製機能が追加された、 将来のバージョンでは変更の可能性がある。

役に立つヒント

多くのネットワーク管理者がつまずく点なので、以下のヒントは十分に検討する 必要がある。

Windowsのネットワークプロトコル

Microsoft Windowsマシン上で2つ以上のプロトコルをインストールした場合、 よくあるブラウジングの問題が発生する。

Warning

2つ以上のプロトコルをMicrosoft Windowsクライアントでは使わない。

すべてのNetBIOSマシンは15分間隔のLMB(とDMB)の選択プロセスに参加する。 複数の選択基準がこの選択プロセスでの決定の順番を決めるのに使われる。 動作しているSambaまたはWindows NTは優先順位が変更されていて、そのため、 最も適したマシンが予想通り決定に勝ち、この役割を保持する。

選択プロセスはすべてのNetBIOSネットワークインタフェースで、 いわば、最後まで行われる。 TCP/IPとIPXがインストールされ、NetBIOSが両方のプロトコルで有効な Windows 9x/Meマシンの場合、選択は両方のプロトコル上で行われる。しばしば 発生するが、もし、Windows 9x/Meマシンが両方のプロトコルを持つ唯一のマシン ならば、LMBはIPXプロトコル上でのNetBIOSインタフェース上で勝つ。 Sambaは、Windows 9x/Meが、LMBがどのマシンかということを知っていると 主張することによって、LMBでなくなる。SambaはLMB機能をやめるため、 すべてのTCP/IPのみで動くマシンのブラウズリスト操作はそのために失敗する。

Windows 95、98、98SEとMeは一般的に Windows9x/Meと言われる。Windows NT4、 200xとXPは共通のプロトコルを使う。これらはざっとWindows NTファミリと言われるが、 2000と XP/2003は、Microsoft Windows NT4とは異なる動作をする新しい 拡張プロトコルを導入したと認識されねばならない。一般的に、サーバーはより新しいか 拡張プロトコルをサポートせず、NT4プロトコルで処理をするようになる。

最も安全な、従うべきルールのすべては単一のプロトコルを使う! である。

名前解決の順序

NetBIOS名からIPアドレスへの名前解決は、いくつもの方式を使って行われる。 NetBIOS名前タイプ情報を提供可能なものは以下の通り:

  • WINS 最適の方法。

  • LMHOSTS 静的でメンテナンスしづらい。

  • Broadcast UDPを使うが他セグメントの名前を解決できない。

名前解決の別の意味は以下を含む:

  • Static /etc/hosts メンテナンスしづらく、名前タイプ情報が欠落している。

  • DNS は良い選択肢だが、基本的なNetBIOS名前タイプ情報が欠落している。

ブロードキャスト名前解決のトラフィックを防ぐこととDNS検索の制限をしたい と考えているサイトが多数ある。name resolve order パラメーターはこれをとても助ける。name resolve order パラメーターの文法は以下の通り:

name resolve order = wins lmhosts bcast host

or

name resolve order = wins lmhosts (bcastとhostを省略)

既定値は:

name resolve order = host lmhost wins bcast

ここで、hostは、UNIXシステムに実装されているgethostbyname() 呼び出しを使う方法である。これは、通常/etc/host.conf/etc/nsswitch.conf/etc/resolv.conf によって制御される。

ブラウジングの技術的な概要

SMBネットワークは、browse listと呼ばれる ネットワーク中のマシンのリストにクライアントがアクセスできる機能を 提供するメカニズムである。このリストには、ネットワーク中の他のマシンに 対してファイルまたは印刷サービスを提供するマシンを含んでいる。サーバーの 機能を現在提供出来ない他のマシンは含んでいない。ブラウズリストはすべての SMBクライアントによって頻繁に使われる。SMBブラウジングの設定はある種の Sambaユーザーには問題があり、そのためにこの文書????? Configuration of SMB browsing has been problematic for some Samba users, hence this document.

Microsoft Windows 2000とその後継バージョン、Samba-3とその後継バージョン は、NetBIOS over TCP/IPを使わないように構成できる。この方法で構成した 場合、(DNS/LDAP/ADSでの)名前解決を正しく設定して動くようにしておくことは 必定である。SMBマシン名からIPアドレスへの名前解決が正しく機能しない場合、 ブラウジングは動作しない。

NetBIOS over TCP/IPが有効な時、WINSサーバーを使うことは、NetBIOS(SMB) 名からIPアドレスへの名前解決を支援するために強く推奨される。 名前解決の他のどの手段でも提供出来ない、リモートセグメントクライアントの NetBIOS名前タイプ情報を提供することがWINSでは出来る。

Sambaでのブラウジングサポート

Sambaはブラウジングを容易にする。ブラウジングはnmbdでサポートされて、 smb.confファイル中のオプションで制御される。Sambaはワークグループの LMBとして動作でき、ドメインログオンとスクリプト機能をサポートする能力を 現在持っている。

SambaはワークグループのDMBとしても動作する。これは、LMBからのリストを 広範囲のネットワークサーバーリストに集めることを意味する。このリスト中 にある名前をブラウズクライアントが解決するために、Sambaとクライアント両方が WINSサーバーを使うことを推奨する。

NTドメインにおいて同じ名前を持つ、ワークグループのドメインマスターに設定 してはならない。各ワイドエリアネットワークで、それがNTかSambaか、 あるいはこのサービスを提供する他のタイプのドメインマスターに関わらず、 ワークグループ毎に一つのみのDMBを設定するようにしなければならない。

Note

nmbdはWINSサーバーとして設定できるが、特段、Sambaを WINSサーバーとして使用することは必要ない。Microsoft Windows NT4、 Microsoft Windows Server又は Advanced Server 200xをWINSサーバーとして 設定できる。WAN上でのNT/200xとSambaの混在環境では、Microsoft WINS サーバーの能力を使うことを推奨する。Sambaのみの環境では、ある1つのSamba サーバーをWINSサーバーとして使うことを推奨する。

ブラウジングを機能させるために、nmbdを通常どおり動作 させるが、どのワークグループにSambaが属するかを制御する、smb.conf 中のworkgroupオプションを使わなければならない。

Sambaは他のサブネット上のブラウジングのために、それ自身を提供するために 便利なオプションも持っている。このオプションは通常でない 使い方のためにのみ使うことを推奨する。例をあげると、インターネット越しの通知 である。smb.confマニュアルページのremote announce を参照のこと。

問題の解決方法

もしもうまく動かない場合、問題を把握するためにlog.nmbd ファイルが役に立つ。問題を発見するために、log level を2または3にしてみる。現在のブラウズリストはbrowse.dat というファイル中に、テキスト形式で格納されていることにも注意。

もしもうまく動かない場合、ファイルマネージャ中で サーバー名を\\SERVERという形で入力することが出来、 enterを入力すると、ファイルマネージャは有効な共有の 一覧を表示する。

[global]セクションでguest accountを 有効なアカウントとして設定していないと、何人かはブラウジングに失敗する。 共有を表示するためのIPC$接続は、guestで行われ、そのため、有効なguest account を設定しておかなければならない。

Note

IPC$共有はすべてのSMB/CIFSクライアントで、 サーバー上で有効なリソースのリストを得るために使われる。 これは、SMB/CIFSサーバーが、Windowsサーバーに対してマイネットワーク経由で Windowsエクスプローラーがリソースを閲覧するために使われる時の、共有とプリンターの リストの元になるものである。この時点で、クライアントは \\server\IPC$リソースに接続を行う。共有をクリックすると、 \\server\shareに接続する。

Microsoft Windows 2000とその後継(Sambaも)はIPC$共有に対する匿名(すなわち guest account)アクセスを無効に出来る。この場合、SMB/CIFSクライアントとして 動作するMicrosoft Windows 2000/XP/2003マシンは、IPC$共有に問い合わせるために 現在ログインしているユーザーの名前を使う。Microsoft Windows 9x/Meはこれが できず、サーバーリソースをブラウズできない。

他の大きな問題はブロードキャストアドレス、ネットマスク、あるいはIPアドレスが 間違っている場合(smb.conf中でinterfaces を指定した場合)である。

サブネット間のブラウジング

Samba1.9.17(α1)のリリースから、Sambaはサブネット境界をまたがってのブラウズリスト の複製をサポートしてきた。この節ではどのようにこの機能を異なった設定中で設定 するかを説明する。

TCP/IPサブネットをまたがったブラウズリストを見るために(すなわち、ブロードキャスト パケットが通らない、ルータによって分離されたネットワーク)、少なくとも1つのWINS サーバーを設定する必要がある。WINSサーバーはNetBIOS名のためのDNS都市的脳する。これは、 WINSサーバーに直接問い合わせを行う事によって、NetBIOS名からIPアドレスへの変換を 可能にする。これは、WINSサーバーマシンのポート137に直接UDPパケットを投げることで 行われる。WINSサーバーは、問い合わせたマシンからのUDPを使うことによって行われる、 既定値のNetBIOSからIPアドレスへの変換の必要性を防ぐ。これは、ある1つのサブネット は、WINSサーバーを使わないで他のサブネット上のマシンの名前を解決することができない ということである。Sambaのハック、すなわちremote browse syncremote announceはUDPのブロードキャストによる伝搬を防ぐ 普通の制限をうまく乗り越えるようにできている。ハックは一般的な解ではなく、 WINSがあるところでは使うべきではなく、最後の手段として考えるべきである。

ネットワーク越えのブラウジングを正しく動かすために、すべてのマシン、すなわち、 Windows95、WindowsNTあるいはSambaサーバーはDHCPサーバー経由かあるいは手動で、 WINSサーバーのIPアドレスを設定する必要があることを思い出してほしい: Windows 9x/MeとWindows NT/200x/XPでは、これはネットワーク設定配下の TCP/IPプロパティ中にあり、Sambaではsmb.confファイル中にある。

NetBIOS over TCP/IPなしでSamba-3を動作させることは可能である。もしも、これを 行う場合、Microsoft ADSの外側で使うと、これは、ネットワークブラウジングサポートを やめることになると警告される。ADSは、すべてのSambaサーバーのために適切な DNSレコードが挿入されるDNSを経由してブラウジングをサポートしている。

サブネット間ブラウジングの動作

サブネット間のブラウジングはとても複雑で、多数の動いている部分を含んでいる。 正確に動くコードが出来るまで、Microsoftは数年掛けることになり、Sambaは それから数年遅れて追いついている。設定が正しければ、Sambaはサブネット間の ブラウジングが出来る機能がある。

サブネット間ブラウジングの例のようなネット ワーク設定を考えてみることにする。

Figure 10.1. サブネット間のブラウジングの例

サブネット間のブラウジングの例

これは、2つのルータ(R1,R2)で接続されている3つのサブネット(1,2,3)から成り立ち、 それらはブロードキャストが届かない。サブネット1はその中に5つのマシンがあり、 サブネット2は4つ、サブネット3は4つマシンがある。すべてのマシンは同じワーク グループ名(単純にするために)に設定されている。サブネット1上のマシンN1-Cは DMB(すなわち、ワークグループのブラウズリストを集める)として設定されている。 マシンN2_DはWINSサーバーとして設定されていて、すべての他のマシンはそのNetBIOS名 をそこに登録している。

それらのマシンが起動するとき、3つのサブネット上それぞれで、マスターブラウザーの 選択作業が発生する。サブネット1上ではマシンN1_Cが選択され、サブネット2上で はN2_Bが、サブネット3上ではN3_Dが選択されると仮定する。それらのマシンはその マシンがいるサブネット上ではLMBとなる。N1_CはそれがDMBとして設定されている ために、サブネット1上のLMBとなる。

各3ネットワーク上で、共有サービスを提供するように設定されたマシンは、その サービスを提供していることをブロードキャストする。各サブネット上のLMBは そのブロードキャストを受け取り、マシンがサービスを提供していることを記録 する。この記録のリストはブラウズリストの基礎となるものである。この場合、 すべてのマシンがサービスを提供するように設定されていることを仮定しているので、 すべてのマシンがブラウズリスト上に載る。

各ネットワークで、そのネットワークのLMBは、ローカルブロードキャスト 経由で受け取ったすべての名前を信頼できると 考える。これは、ローカルブロードキャスト経由でのLMBで見えるマシンは ローカルマスターブラウザーとして同じネットワーク上にいなければならない という理由であり、そのため、信頼された、かつ 検証可能なリソースである。ブラウズリストを 収集する時に学習した他のネットワーク上のマシンは、LMBからは直接見え ない。これらのレコードは信頼できない

この時点で、ブラウズリストは ブラウズリストの例1のようになる (それらはたった今特定のネットワーク上でネットワークコンピュータを 見た時に見えるマシンである)。

Table 10.1. ブラウズリストの例1

サブネットブラウズマスターリスト
サブネット1N1_CN1_A, N1_B, N1_C, N1_D, N1_E
サブネット2N2_BN2_A, N2_B, N2_C, N2_D
サブネット3N3_DN3_A, N3_B, N3_C, N3_D


この時点で、すべてのサブネットは分離され、任意のサブネットをまたいで見える マシンはない。

次に、サブネットのブラウズの例2中のサブネット2を 眺めてみよう。NB_2がLMBになると同時に、そのブラウズリストを同期するDMBを探す。 これは、NetBIOS名 WORKGROUP<1B>に関連づけられているIPアドレスをWINS サーバー(N2_D)に問い合わせることによって行われる。この名前は、WINSサーバーが起動 するとすぐにDMB(N1_C)によって登録される。

N2_BがDMBのアドレスを知ると、DMBに対して、UDPのポート138を使って、 マスターアナウンスパケットを送ることによって、サブネット2 のLMBであることを告げる。次に、NetServerEnum2コールを 行うことで、DMBとの同期作業を行う。これは、DMBが知っているすべてのサーバー名を 送信元に送るようにさせる。DMBがマスターアナウンスパケットを 受け取ると、そのパケットの送信者への同期要求をスケジュールする。両方の同期が 終了すると、ブラウズリストは、 サブネットのブラウズの例2中のようになる。

Table 10.2. サブネットブラウズの例2

サブネットブラウズマスターリスト
サブネット1N1_CN1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*)
サブネット2N2_BN2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
サブネット3N3_DN3_A, N3_B, N3_C, N3_D

サーバー名の後に(*)が付いたものは信頼されていない名前である。

この時点で、ユーザーは、サブネット1または2上で両方のすべてのサーバーを、ネット ワークコンピュータで見ることができる。サブネット3上のユーザーは引き続き 自分がいるサブネット上のもののみが見える。

N2_Bで起きた同じ手順のイベントがサブネット3のLMB(N3_D)に対して起こる。DMB(N1_A) とブラウズリストの同期を行うと、サブネット1とサブネット2のサーバーエントリを得る。 N3_DがN1_Cと同期を取るとvica versa、ブラウズリストは サブネットのブラウズの例3 のようになる。

Table 10.3. サブネットのブラウズの例3

サブネットブラウズマスターリスト
サブネット1N1_CN1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
サブネット2N2_BN2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
サブネット3N3_DN3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)

サーバー名の後に(*)が付いたものは信頼されていない名前である。

この時点で、サブネット1または3上でのネットワークコンピュータでは、 サブネット2上のユーザーが引き続きサブネット1と2上のサーバーのみが見え、 3が見えないのに対し、すべてのサブネット上のサーバーを見る事ができる。

最後に、サブネット2のLMB(N2_B)は再度DMB(N1_C)と同期をとり、抜けていた サーバーエントリを受け取る。最終的に、定常状態(1台もマシンが削除されず、 停止もしていない状態)になると、ブラウズリストは サブネットのブラウズの例4のようになる。

Table 10.4. サブネットのブラウズの例4

サブネットブラウズマスターリスト
サブネット1N1_CN1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
サブネット2N2_BN2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
サブネット3N3_DN3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)

サーバー名の後に(*)が付いたものは信頼されていない名前である。

DMBとLMBの同期は引き続き行われるが、これは定常状態の操作として 行われる。 Synchronizations between the DMB and LMBs will continue to occur, but this should remain a steady-state operation.

もしもルータR1かR2が故障した場合、以下のことが発生する:

  1. アクセスできないネットワーク部分にある各コンピュータ名は、ネットワークコンピュータ ネットワークコンピュータのリスト中に36分維持される。

  2. それらアクセスできないコンピュータへの接続は失敗するが、ネットワークコンピュータ のリスト中からは消えない。

  3. もしも、あるネットワーク部分からWINSサーバーが見えなくなると、サブネットで 分割されたブロードキャストによるNetBIOS名前解決を使ったローカルサブネット 上のサーバーにのみアクセスできる。この結果はDNSサーバーへのアクセスが出来なく なることと似ている。

よくあるエラー

ブラウジングに関する質問は数多くメーリングリスト上に投稿される。 ブラウジングに関する大多数の問題は、NetBIOS名前解決の間違った設定に 起因するものである。ただ、いくつかは特に注目に値する。

SambaのNetBIOS名前キャッシュのフラッシュ

Sambaを再起動しないでSambaのNetBIOS名前キャッシュをフラッシュする方法はあるか?

Sambaのnmbdプロセスはすべてのブラウザーリストハンドリングを 制御する。通常の環境では、nmbdの再起動に問題はない。これは SambaのNetBIOS名キャッシュをフラッシュする効果があり、再構築を行う。 これは、異常なマシン名は再度ブラウズリストに現れないということが確実になる わけではない。nmbdがサービスを停止後、ネットワーク上の他の マシンがブラウズマスターになる。この新しいリスト中には異常なエントリがそのまま 含まれるかもしれない。もしもリストから異常なマシンを消したいのならば、ネットワーク 上のすべてのマシンをシャットダウンし、すべてのマシンが停止後に再起動しなければ ならない。完全な再起動に失敗すると、唯一出来る他のことは、エントリがタイムアウト するまで待ち、その後リストからフラッシュされる。これは、ある種のネットワークでは 長い時間(月単位)かかる。

サーバーリソースがリスト出来ない

あるクライアントは"This server is not configured to list shared resources."と報告した。

おそらく何らかの理由でゲストアカウントが無効になっている。Sambaは smbdでブラウジングするためにゲストアカウントを使う。 ゲストアカウントが有効か確認する。

smb.conf マニュアルページのguest accountも参照 のこと。

"Unable to browse the network"というエラーメッセージが出た。

このエラーは複数の原因が考えられる:

  • LMBがない。nmbdを設定するか、他のマシンでLMBを立てる。

  • LMBマシンにログオンできない。 ゲストユーザーでログオンできるか?

  • LMBに対してIPレベルで接続できない。 ブロードキャストで到達可能か?

共有とディレクトリのブラウジングが非常に遅い

テストネットワークに2台だけマシンがあったとする。1つはSambaサーバーで他はWindows XPマシンである。 認証とログオンは正常に動作するが、Sambaサーバー上の共有を表示させようとするとWindows XP クライアントは反応がなくなる。時々、数分反応がなくなる。最終的にはWindowsエクスプローラーは 反応して問題なくファイルとディレクトリを表示する。

しかし、共有はコマンドシェル(cmd)でDOSコマンドを使うと すぐに使える。これはSambaの問題か、それともWindowsの問題か?この問題の解決 方法は?

いくつかの可能性がある:

ネットワークハードウェアの不良

最も一般的な、不完全なハードウェアの問題は、低コストまたは不完全なハブ、 ルータ、ネットワークインタフェース(NIC)と良くないケーブルに集中する。 もしも、ハードウェアの1部分が不良だと、ネットワーク全体が被害を受ける かもしれない。悪いハードウェアはデータの喪失を引き起こす。ほとんどの ネットワークハードウェアの不良問題は見た目のネットワークトラフィックの 増大をもたらすがそれだけではない。

Windows XPのWebClient

数多くのサイトで、同様のネットワークブラウジングが遅くなる問題が報告され、 WebClientサービスを停止すると、問題が出なくなることがわかっている。これは、 動けば簡単な解であるという理由で、確かに探求されるべきことで ある。

矛盾しているWINSの設定

このタイプの問題は、あるクライアントがWINSサーバーを使うように設定され て(それはTCP/IP設定で)、ネットワーク上にWINSサーバーがない場合である。 言い換えると、WINSサーバーがあり、Sambaがそれを使うように設定されて いない場合である。NetBIOS over TCP/IPを使う場合はWINSの使用は強く 推奨される。すべてのクライアントでNetBIOS over TCP/IPを無効にしている ならば、SambaはWINSサーバーとして設定されるべきでも、それを使うように されるべきでもない。

不正なDNS設定

もしも、NetBIOS over TCP/IPが無効になっているならば、Active Directory が使われ、DNSサーバーが正しく設定されない。詳細な情報は、 DNSとActive Directory を参照のこと。

不正なキャッシュされた共有参照はネットワークブラウジングに影響する

Microsoft Windowsクライアント(ワークステーションまたはサーバー)上での、存在しない 共有あるいはサーバーに対するキャッシュされた参照はそれらの共有に接続する際に、 Microsoft Windowsエクスプローラーが無反応になると言う現象を引き起こす。しばらく経つと (かなり長い時間だが)、タイムアウトになり、ブラウジングが通常通りになる。

この現象を除くために、腐ったキャッシュされた参照は取り除かれるべきである。 これは自動的には起こらず、手動での作業が必要である。これはMicrosoft Windows のデザインによるものであり、Sambaで変えることは出来ない。現時点で無効になって いる、マイネットワーク内の共有またはサーバーへの無効な ショートカットを削除するためには、 HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ 配下にあるWindows レジストリを編集する必要がある。エントリ MountPoints2(Windows XP以降、またはWindows 2000以前では MountPoints)を編集する。 \\server\shareという名前(ここで'server'と'share'は 存在しないサーバーまたは共有を参照している)のすべてのキーを削除する。

Note

存在しないネットワークリンクの削除はユーザー単位で行う必要がある。言い換えると、 Microsoft Windowsエクスプローラー内でのマイネットワーク 中のショートカットは、右クリックして削除を選択することで 削除できる。

Sambaのユーザーは、Windows、SambaとNovellサーバーのネットワークブラウジングに 対して、これらの存在しない参照が、悪影響を及ぼすと報告している。これは Sambaサーバーに関連しない一般的な問題であると思われる。Sambaユーザーは、 Sambaが、時として人柱ツールとして見られていることがあるために、しばしば これを経験するかもしれない。これは、異なった名前、異なった共有で何回かSamba サーバーを再設定したり元に戻すことをユーザーが行うことという事実の結果は、 不完全(不正)なキャッシュされた共有参照が出来てしまうことを増大させてしまう。 Windowsクライアントは、それらの参照を満了としないので、手動による削除を必要とする。

現在アクセスするディレクトリにいなくても、すべてのキャッシュされた参照を見に いくことを試みるので、ダイアログボックスのオープンは (たとえばWordやExcel)、一般的に反応がとても遅くなる。

Chapter 11. アカウント情報データベース

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Gerald (Jerry) Carter

Samba Team

Jeremy Allison

Samba Team

Guenther Deschner

LDAP updates 

Olivier (lem) Lemaire

May 24, 2003

以前のSamba3リリースでは複数のアカウント情報バックエンドを同時に動作させることが できた。この機能はSamba3.0.23からなくなった。Samba3.0.23からは、passdbバックエンド は1つのみ指定できる。

3つのpassdbバックエンドがSambaチームで完全なメンテナンスが行われており、それは以下である: smbpasswd (旧式)、tdbsam(tdbベースのバイナリファイル 形式)とldapsam(LDAP)。もちろん、ldapsamバックエンド のみが、POSIX(UNIX)とSambaのユーザーとグループアカウント情報を単一のリポジトリに格納できる。 smbpasswdtdbsamバックエンドはSambaユーザー アカウントのみ格納する。

厳密な意味で、3つのアカウントストレージとアクセスシステムがサポートされている。それらの 1つは旧式である(smbpasswd)。すべての簡単なシステムには tdbsam方式 を使用することを推奨する。ldapsamはもっと大規模か、複雑なネット ワークで使用すること。

厳格かつ文字通りの意味で、passdbバックエンドはアカウント格納メカニズム(あるいは方法) のみである。技術の選択はミスリードの可能性があるが、言い回しの選択で困っている。 この章では、ユーザーと信頼アカウントにフォーカスをあてたアカウント格納システムの 本質について記述する。信頼アカウントは2つの形式があり、それはマシン信頼アカウント (コンピュータアカウント)とドメイン間信頼アカウントである。それらはユーザーのような エントリとして扱われる。

機能と利便性

Samba-3 は Samba-2.2.x の以下の機能について完全な下位互換性を提供する:

下位互換性のあるバックエンド

平文

これは全く持ってバックエンドではないが、単純化のためにここに表示する。 Sambaは伝統的なUNIX/Linuxの/etc/passwd/etc/shadow形式のサブシテムに平文認証要求を渡す ように設定できる。Pluggable Authentication Modules (PAM) サポートが あるシステム上では、 全てのPAMモジュールがサポートされる。動作は、 Samba-2.2.x の場合と全く同様で、Microsoft Windowsクライアントにより 課されるプロトコルの制約も同様に適用される。平文パスワードの使用に 関する制約に関する詳細情報は、 技術情報の項を参照のこと。

smbpasswd

このオプションは、Microsoft Windows LanMan と NT の暗号化パスワード 及び一部のアカウント情報を格納するフィールドを含む平文ASCII(テキスト) レイアウトを維持するsmbpasswdファイルの継続的 使用を可能にする。この種のパスワードバックエンドは、Microsoft Windows NT4/200xサーバーと包括的な相互運用を行うために必要な拡張 コントロールを提供するための、Microsoft Windows NT/200x SAM (Security Account Manager)情報を一切格納しない。

このバックエンドは、Samba のより古いバージョンとの下位互換性のために のみ使用するべきである。将来のリリースでは、切り捨てられていくかもしれない。

ldapsam_compat (Samba-2.2 LDAP互換)

これは、Samba-2.2.x LDAP スキーマ拡張を使用する、既存のOpenLDAP バックエンドとの継続的運用を可能にするパスワードバックエンドの オプションである。このオプションはマイグレーションツールとして 提供されているが、この時点で強制的にマイグレーションする意味はない。 このツールは最終的には切り捨てられることになる。

新しいアカウント格納システム

Samba-3では多数の新しいパスワードバックエンド機能が導入された。

tdbsam

このバックエンドは、ローカルサーバーに、リッチなデータベースバックエンドを 提供する。このバックエンドは、複数のドメインコントローラー(つまり、PDC+ 一つ以上のBDCをインストールしている場合には適さない。

tdbsamパスワードバックエンドは古い smbpasswd情報のほかに、拡張された Microsoft Windows NT/200xのSAM情報をバイナリ形式のTDB(トリビアルデータベース) ファイルに格納する。拡張情報を含むことで、Samba-3が、Microsoft Windows NT4/200x ベースのシステムと同様のアカウントアクセス及びシステムアクセス制御を実現する ことを可能にする。

tdbsamを入れたのは、OpenLDAPを稼動する伴う 複雑性と、その間接費用を発生させずに、シンプルななサイト運用を 可能にしたいというユーザーからの要求にに直接応えるためである。これは、 ユーザー数250未満のサイトにのみ推奨する。これより大規模のサイト、 または実装では、OpenLDAP の使用またはActive Directoryへの統合を強く 推奨する。

ldapsam

これは、分散アカウントを導入している場合に、リッチなディレクトリバックエンド を提供する。

Samba-3ではLDAP用拡張の実装が新しくなり、これにより新しい形式のSambaスキーマを 持つOpenLDAPの設定を必要とする。新しい形式のスキーマファイルは、Samba ディストリビューションの examples/LDAPのディレクトリにある。

新しいLDAPの実装は、Sambaの過去のバージョンで可能だったコントロール能力を 著しく向上するものである。このバージョンでは、ユーザーごとの プロファイル設定、ホームディレクトリ、アカウントアクセス制御、その他 多くの設定が可能になった。企業サイトでは、機能性と拡張性の向上要求に、 Sambaチームがしっかり耳を傾けたと いうことが理解できるはずである。

技術情報

古いWindowsクライアントは、平文パスワードを送信する。Sambaはこれらの パスワードを暗号化し、UNIXユーザーデータベースに格納されているハッシュと 比較することにより、確認することができる。

より新しいWindowsクライアントは、平文パスワードのかわりに、暗号化された パスワード(Lanman及びNTハッシュと呼ばれるもの)を送信する。最新のクライアントは、 暗号化されたパスワードのみを送信し、クライアントのレジストリが改変されていない 限り、平文パスワードを送信することを拒否する。

Sambaはなぜ単純にUNIXパスワードデータベースを使うことが出来ないかという質問は 多くの人から聞く。Windowsは、パスワードに対してそれ固有の暗号化形式を要求する。 WindowsのパスワードはUNIX形式の暗号化パスワードに変換できない。そのため、標準 UNIXユーザーデータベースを使うことが出来ず、Lanman ハッシュとNTハッシュは別の所に 格納しなければならない。

パスワードの暗号化方式が異なるのみならず、WindowsはUNIXユーザーデータベースには 格納されないような各ユーザーに関する特定のデータを格納する。例えば、ユーザーが ログインする可能性のあるワークステーション、ユーザーのプロファイルが格納されて いる場所等々である。Sambaはpassdb backendを使用して この情報を取り出し、格納する。 通常、使用できるバックエンドは、LDAP、tdbsum および平文ファイルである。passdb backendのパラメーター に関する詳細は、smb.confのマニュアルページを参照のこと。

Figure 11.1. IDMAP: SIDのUIDへの解決

IDMAP: SIDのUIDへの解決

SIDのUIDへの解決は、Samba の適正運用の根幹を成す。以下の両例で、winbinddが 稼動していないか、あるいは、接続できない状況のとき、ローカルのSID/UID解決 のみが可能である。SIDのUIDへの解決 およびUIDのSIDへの解決の図を参照のこと。

Figure 11.2. IDMAP: SIDのUIDへの解決

IDMAP: SIDのUIDへの解決

セキュリティに関する重要な注意事項

UNIXとSMBのパスワード暗号化のテクニックは、一見、類似しているように見える。しかし、 この類似性は、皮一枚だけの表面的なものである。。UNIXのスキームでは、通常 ログインの際に、 平文パスワードをネットワークを通して送信します。これは悪い方法である。SMBの暗号化 スキームは、ネットワークを通して平文パスワードを送信することは絶対にないが、ディスク上に 16バイトのハッシュ値を格納する。これも悪い方法である。なぜか。それは、16バイトのハッシュ 値は、パスワードと同等だからである。ユーザーのパスワードをハッシュ値から 導き出すことはできないが、クライアントに手を加えれば、サーバーにアクセスするために使える 可能性がある。これは、侵入者の側にかなりの技術的知識があることを前提としてるが、それでも 可能であることは確かである。従って、(smbpasswdファイル、 LDAP)いずれのパスワードデータ ベースバックエンドを使用していても、そこに格納されたデータが、全ユーザーの平文パスワードを 持っているかのように、慎重に取り扱わなければならない。これらのデータベースの内容は極秘とし、 ファイルは、適切に保護されていなければならない。

理想的には、ネットワーク上でもディスク上でも平文パスワードを持ったり送信したり しないようなパスワードのスキームが欲しいところである。残念ながら、Sambaは他の SMBシステム(Windows NT、Windows for Workgroups、Windows 9x/Me)との互換性を 確保しなければならないという要件のために、これは実現できない。

Windows NT 4.0 サービスパック 3は既定値で平文パスワードの送信を無効化している。 これにより、暗号化されたパスワードのサポートを使用するか、平文パスワードを再度 有効化するように Windows NT レジストリを編集するか、どちらかが必要となる。

Microsoft Windowsの下記のバージョンは、ドメイン環境にログオンする可能性があるにも かかわらず、完全なドメインセキュリティのプロトコルをサポートしていない:

  • MS DOS ネットワーククライアント3.0で基本的なネットワーク リダイレクタがインストールされているもの

  • Windows 95で、アップデートされたネットワークリダイレクタがインストールされているもの

  • Windows 98 [Second Edition]

  • Windows Me

Note

MS Windows XP Home は、ドメインメンバーになる機能はなく、ドメインログオンは実行できない。

下記のバージョンのMicrosoft Windowsは、ドメインセキュリティのプロトコルを完全にサポートしている。

  • Windows NT 3.5x.

  • Windows NT 4.0.

  • Windows 2000 Professional.

  • Windows 200x Server/Advanced Server.

  • Windows XP Professional.

Microsoft SMB/CIFS クライアントの現在のリリース版は全て、ここに説明するSMBの チャレンジ/ レスポンス認証の仕組みをサポートしている。平文認証を有効化しても、 クライアントが暗号化による認証に参加する能力を無効化するわけではない。そうではなく、 クライアントが平文でも暗号化でもどちらのパスワード認証方式にも対応できるようにする。

Microsoft Windowsのクライアントは、暗号化されたパスワードのみキャッシュする。 レジストリの変更により、平文パスワードが再度有効化されても、平文パスワードは キャッシュされない。このことは、ネットワーク接続が切れた場合、 キャッシュされた (即ち暗号化された)パスワードのみがリソースサーバーに送られて、自動再接続を実行する ために使用されるということを意味する。リソースサーバーが暗号化された パスワードを サポートしていない場合、自動再接続はできない。暗号化されたパスワードの使用を強く 推奨する。

暗号化されたパスワードの長所

  • 平文パスワードがネットワーク経由で送信されない。誰かがネットワーク スニファーを使用して、SMBサーバーに送られるパスワードを記録することができない。

  • 平文パスワードが、メモリにもディスクにも、どこにも保存されない。

  • Windows NTは暗号化パスワードをサポートしないサーバーとやりとりする ことを好まない。また、サーバーが「userレベル」のセキュリティモード になっているとき、そのサーバーを ブラウズすることを拒否する。そのため、 接続の度に、ユーザーにパスワードを入力するように要求するので、大変厄介 である。 これを止めさせる唯一の方法は、SMB暗号を使用することである。

  • 暗号化パスワードのサポートにより、共有(リソース)への自動再接続が可能になる。

  • PDC/BDC の運用に暗号化パスワードは不可欠である。

暗号化されていないパスワードの長所

  • 平文パスワードは、ディスクに保存されず、メモリにキャッシュされない。

  • 平文パスワードは、LoginやFTPなどの、UNIXの他のサービスと同じパスワード ファイルが使用できる。

  • TelnetやFTPなどの他のサービスが、平文パスワードをネットワーク上で 送信している。従って、SMBのために送信しても大勢に影響はない。

Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング

Microsoft Windows NT4/200xがセキュリティ識別子(SID)を要求するのと同様に、 UNIX/Linuxの全ての操作は、ユーザー識別子(UID)を要求する。SambaはMicrosoft Windows のユーザーをUNIX/LinuxのUID にマッピングするために、二つの方法を提供する。

第一に、すべてのSamba SAM(セキュリティアカウントマネージャデータベース) アカウントが、そのアカウントとマッピングされるべきUNIX/Linux UID を必要とする。 アカウント情報データベースにユーザーが追加されるにつれ、SambaはSambaのホストOSに そのアカウントを追加するために、add user script インタフェースを呼ぶ。本質的には、ローカルSAMの中の全アカウントが、 ローカルユーザーアカウントを必要とする。

Windows SIDをUNIX UIDにマップする2番目の方法は、smb.conf中の idmap uididmap gidパラメーターを経由する 方法である。これらのパラメーターの情報についてはマニュアルページを参照のこと。リモート (非メンバーのWindowsクライアントあるいは外部ドメイン)SAMサーバーからのユーザーマッピング 時にはこれらのパラメーターは不可欠である。

分散マシン上の共通のUID/GIDマッピング

Samba-3は、分散ネットワーク環境中で、すべてのサーバー上で同一のUIDとGIDを使うことを 可能にする特別な機能を持っている。分散ネットワークとは、PDCが存在するもの、一つ以上の BDCがあるもの、あるいは1つ以上のドメインメンバーサーバーがあるものである。なぜこれが 重要かというと、ファイルが1つ以上のプロトコル(たとえばNFS)で共有され、たとえば rsyncのようなツールを使ってUNIX/Linuxシステム間で、ユーザーが ファイルをコピーすることがあるからである。

idmap backendと呼ばれるパラメーターを使って、 特別な機能を有効に出来る。このパラメーターの既定値は空の文字列である。 技術的に、LDAPベースのidmapバックエンドをUIDとGID向けに使うことは可能 であるが、SAMバックエンド用にLDAPの使用も行うネットワーク設定用にこれを 使う時にこれは最も意味を持つ。この設定については LDAP idmap バックエンドを使う設定例 にある。

Example 11.1. LDAP idmap バックエンドを使う設定例

[global]
idmap backend = ldap:ldap://ldap-server.quenya.org:636
# Alternatively, this could be specified as:
idmap backend = ldap:ldaps://ldap-server.quenya.org

LDAPバックエンドに重要な仕事をさせたいネットワーク管理者は、遅かれ 早かれPADLソフトウェアによって優れた功績を知ることになろう。 PADL http://www.padl.comはとても興味深い一連の ツールをオープンソースで作成し、公開している。これらのツールは 以下を含む:

  • nss_ldap:AIX、Linux、Solarisやその他のOS向けの ネイティブなネームサービスサポートを提供するLDAPネームサービススイッチ (NSS)モジュール。このツールはUID/GIDの一元的な格納と検索に使う ことができる。

  • pam_ldap:PAMモジュールで、UNIX/Linuxシステムの アクセス認証のLDAP統合を提供する。

  • idmap_ad:PADL Web サイト からの、Microsoftサービスのための、UNIX RFC2307スキーマを サポートするIDMAPバックエンド。

LDAPに関するコメント

現在の情報技術界で、多くの興奮と関心がLDAPディレクトリに向けられている。 LDAPアーキテクチャは高度に拡張性があるように設計された。また、広範囲な OSとプラットフォームを取り巻く、非常にたくさんのアプリケーションの潜在的 な領域をまたがって使うようにも設計されている。LDAP技術は会社全体のシングル サインオン(SSO)環境の基盤となる連携アイデンティティ管理(FIM)ソリューション の中心部をなしている(訳注:TivoliとかRSAでこのような製品がある様子)。

LDAPの実装は広範囲な種類のプラットフォームで構築されている。これは、 Microsoft Windows Active Directory(ADS)、NovellのeDirectoryやその他の もののの中心に位置する。LDAPによるディレクトリサービスの実装は、 新しい世代のアプリケーションと同様に古いものとも相互に関係し、 それらはすべて何らかの認証サービスに依存する。

UNIXのサービスは、ツールやユーティリティを介することによって、LDAPディレクトリ の情報を認証のために利用することが出来る。LDAPディレクトリ とミドルウェアのツールとユーティリティからなる統合環境により、すべての ユーザーが一元管理されたUNIXプラットフォームにアクセスすることが可能になる。 プラットフォームは、必要に応じて物理的に分散配置されてもよい。この機構の 恩恵を受けるアプリケーションとしては、UNIXログインシェル、メールとメッセージ システム、quota制御、印刷システム、DNSサーバー、DHCPサーバーやもちろんSambaも 含まれる。

多くのサイトが、Samba用に拡張性のあるpassdbバックエンドを提供するために、 まずはじめにLDAPをインストールする。その他はSamba SAMバックエンドのような 新しいユーザーのために存在するLDAPディレクトリに適合することが必要な場面に 直面する。Sambaに対する特別な必要性と魅力が何であっても、LDAPディレクトリ 構造とその実装のデザインに関する決定は、そのサイトの永続的な本質である。 これらは、長期にわたる情報システム管理コストに影響する広範囲な影響がある。

LDAPの展開を急いではならない。どのように、ディレクトリ情報ツリーが現在と 将来のサイトのニーズに影響するかのデザインを、それらが使える可能性と同じ ように理解する時間を取ること。SambaのSAM情報は、サイトからサイトに異なる DIT内に格納すべきであり、おのおのの実装において新しい経験が得られる。 最初の実装で目が覚め、2番目の実装では心配事が出来、三世代目でやっとうまく いくというのは、LDAPのベテランはよく理解していることである。

LDAPとSambaに対する注意

SambaはUNIX POSIX識別情報を、SambaとWindowsネットワーク環境に特有の 情報を格納する場所と同様に必要とする。取り扱われなければならない、 最もよく使われる情報はユーザーアカウント、グループアカウント、マシン 信頼アカウント、ドメイン間信頼アカウントとSamba内部で使う固有の中間 情報を含む。

この文書中の、展開ガイドラインは、他の本とインターネット上で公開されて いるHOWTO文書と同じように、出来上がっているディレクトリデザインと実装に 適合するわけではない。存在するDITは、共通のソース中で提案された単純な 情報レイアウトに適合することが出来ないかもしれない。更に追加すると、 Samba用に使われるLDAPディレクトリを提供するのに使われる共通スクリプトと ツールはあなたの要求に適合しないかもしれない。

これは一般的ではないが、存在するLDAP DITを持つサイトのために、サイト 固有のスクリプトとユーティリティ一式を作成する必要がある場合に、サイト 操作のスコープ内でSambaを供給することは可能である。DITを使ってユーザーと グループアカウントを配布する方法はこれをチャレンジングなことにさせる。 解決方法は、もちろん、価値があることであるが、それを行うための試行錯誤は チャレンジングである。サイトの要求を理解する時間を取り、急いで提供する ことは避けること。

上記から、サイトに適合しないスクリプトとツールをむやみやたらに使わないこと。 存在する基盤が、不適切なツールの不用意な使用によって被害を被らないことを 確実にするために、すべてのスクリプトを、それを実行する前に検査して検証すること。

LDAPディレクトリとWindowsのコンピュータアカウント

SambaはLDAPに対するターンキーソリューションを提供しない。Sambaとの統合の 前に、LDAPのデザインと設定を行う事は最も良いことである。LDAPの実用的な 知識はSambaの統合を容易にし、LDAPの知識がない場合には、いらいらした経験 しか得られない。

コンピュータ(マシン)アカウントは、この章で説明されている、若干の制約を 受けるLDAPディレクトリサブジェクト中の好みの位置に配置できる。

コンピュータ(マシン)アカウントのPOSIXとsambaSamAccountコンポーネントは、 両者ともSambaによって使われる。そのため、マシンアカウントは、Windows NT/200xが扱うのと同じ方法で、Samba内部で扱われる。ユーザーアカウントと マシンアカウントは、マシンアカウントが$文字で終わることを除いてお互い を識別できず、信頼アカウントも同じである。

有効なUNIX uidに結びつくWindowsのユーザー、グループ、マシン、信頼およびその他の アカウントの必要性は、遙か昔前のSambaの開発時に決められた。この決定が覆されたり 変更することは、Samba-3.x系列の間にはありそうもない。

Windows SIDからのUID解決はSambaが動作しているホストOSを参照しなければならない メカニズムによって、Samba内で行われる。NSSは、それが動いているすべてのホスト OSについて全部を知る必要があるということから、(Sambaのような)アプリケーション を隠蔽する良いメカニズムである。

SambaはNSS制御(設定)ファイル中のpasswdshadowgroup機能経由でホストOSが提供するUIDを問い合わせる。これを 達成するための最適なツールはUNIX管理者の決定にゆだねられている。それはSamba によっては強制されない。Sambaは1つの方法としてそのサポートライブラリとwinbindd を提供する。これをLDAP経由で行う事は可能で、すべてのアカウントエンティティが LDAPディレクトリ中にあることが可能なような適切なフックを提供する。

多くの人に対して、良い選択肢は、PADL nss_ldapライブラリを使うことである。 このユーティリティは、コンピュータアカウントがPOSIX/UNIXアカウントのUID に解決できるように設定されねばならない。これは基本的にLDAPのデザインの問題 である。Sambaメーリングリストとドキュメントで提供される情報は役に立つ例だけ を提供するようになっている。LDAPディレクトリのデザインは複雑な問題であり、 この文書の範囲外である。

アカウント管理ツール

Sambaはユーザーとマシンアカウントを管理するための2つのツールを提供する: smbpasswdpdbeditである。

pdbeditはSambaユーザーアカウント情報に加えてアカウントポリシーを 管理するために使うことが出来る。ポリシー管理機能は、パスワードのエージングと ログイン失敗の扱いの管理を行うドメインの既定値の設定を管理するために使われる。

何人かは、名前がSambaSAMAccount情報への格納メカニズムを参照しているために、 参照がsmbpasswd担っていることに困惑することがある。 しかし、これはユーティリティツールの名前でもある。このツールは結局、 netツールセット(Netコマンドを参照) という、新しく追加された新しい機能に取り替えられることになる。

smbpasswdツール

smbpasswdpasswdyppasswd プログラムに似たユーティリティである。これはpassdbバックエンド中の2つの32バイト パスワードフィールドを管理する。このユーティリティは実際のアカウントと、(smb.conf ファイル中の passdb backendによって指定される)パスワード 格納方式とは独立して動作する。

smbpasswdは、ユーザーのパスワードを変更する時に、ローカルのsmbd に接続する時にクライアント-サーバーモードで動作する。これは非常なメリットがある。

smbpasswdはWindows NT上のパスワードを変更する能力もある(これは NTドメインのユーザーのパスワードを変更する時に、NT PDCにその要求を送る時にのみ動作 する)。

smbpasswdは以下のように使うことが出来る:

  • ユーザーまたはマシンアカウントの追加

  • ユーザーまたはマシンアカウントの削除

  • ユーザーまたはマシンアカウントの有効化

  • ユーザーまたはマシンアカウントの無効化

  • ユーザーパスワードの削除

  • ドメイン間信頼アカウントの管理

通常のユーザーでsmbpasswdを実行するには、以下のように入力する:

$ smbpasswd
Old SMB password: secret

secretには、古いパスワードを入力するか、もしも 古いパスワードがなければ単にリターンキーのみを入力する。

New SMB Password: new secret
Repeat New SMB Password: new secret

もしも古い値が、このユーザーに対して格納されている現在の値と異なる場合か、 2つの新しい値が一致しない場合、パスワードは変更されない。

普通のユーザーによって起動された場合、コマンドはそのユーザーのみのSMBパスワード のみ変更できる。

rootで実行される場合、smbpasswdはSMBパスワードを変更 したいユーザー名をオプションの引数として指定できる。rootで実行される場合、 smbpasswdは古いパスワードの値をチェックするための プロンプトを出さないので、パスワードを忘れたユーザーのパスワードを設定できる。

smbpasswdは、passwdyppasswd コマンドを使っているUNIXユーザーに親しみやすい方法で動作するように設計されて いる。管理用として設計されているが、このツールは基本的なユーザーレベルの パスワード変更機能を提供する。

smbpasswd,の使い方の詳細は、マニュアルページ(最終的な 参照)を参照すること。

pdbeditツール

pdbeditはrootでのみ使えるツールである。これは、 ドメイン全体でのアカウントポリシーの設定のようにpassdbバックエンド を管理するのに使われる。pdbeditは以下のように使える:

  • ユーザーアカウントの追加、削除および変更。

  • ユーザーアカウントの表示。

  • ユーザーアカウントの移行(migrate)。

  • グループアカウントの移行。

  • アカウントポリシーの管理。

  • ドメインアクセスポリー設定の管理。

上場企業会計改革および投資家保護法(いわゆる米国SOX法)下で、アメリカの企業と 組織は一連の内部統制と伝達手段、記録、会計データの 保護を実施することが必要となった。米国SOX法はさらに以下の点についても影響 する:

  1. 財務データを格納する情報システムにだれがアクセスするかということ。

  2. どのように個人情報と会計情報が、従業員とビジネスパートナーとの間で扱われるかと言うこと。

  3. どのようにセキュリティの欠陥を管理するかと言うこと。

  4. すべての情報システムへのセキュリティとパッチレベル管理。

  5. どのように情報システムの変更が文書化され、追跡できるようになるかと言うこと。

  6. どのように情報アクセス制御が実装されて管理されているかと言うこと。

  7. 変更点とセキュリティに関するすべての情報システムの監査機能。

  8. プライバシーを確実にするための規律手順と制御。

手短に言うと、米国SOX法は、ビジネス関連の情報システムに関して責任を 強める道具である。特に会計データ処理と個人情報の記録に使われるすべての 情報システムのコンプライアンスを強化する。同様な責任は世界中で要求され ている。

政府の法律に従って情報システム操作を許可するSambaのツールと機能に 精通している必要性は明らかである。pdbeditは アカウントとシステムアクセス制御とポリシーを管理する能力を提供する 唯一のSambaツールである。Samba-3シリーズの残存ライフサイクル中、 この重要な領域で新しいツールが実装されることはあり得る。

Sambaと比較した場合のWindows NT4で有効なドメイングローバルポリシー 制御はNT4 ドメイン対 Sambaポリシー制御 中にある。

Table 11.1. NT4ドメイン対Sambaポリシー制御

NT4ポリシー名

Sambaポリシー名

NT4 レンジ

Samba レンジ

Samba 既定値

Maximum Password Age(パスワード有効期間)

maximum password age

0 - 999 (日)

0 - 4294967295 (秒)

4294967295

Minimum Password Age(パスワード変更禁止期間)

minimum password age

0 - 999 (日)

0 - 4294967295 (秒)

0

Mimimum Password Length(最小パスワード長)

min password length

1 - 14 (文字)

0 - 4294967295 (文字)

5

Password Uniqueness(パスワード履歴)

password history

0 - 23 (#)

0 - 4294967295 (#)

0

Account Lockout - Reset count after(アカウントロックアウト期間)

reset count minutes

1 - 99998 (分)

0 - 4294967295 (分)

30

Lockout after bad logon attempts(ロックアウトの閾値)

bad lockout attempt

0 - 998 (#)

0 - 4294967295 (#)

0

*** Not Known ***

disconnect time

TBA

0 - 4294967295

0

Lockout Duration(ロックアウト閾値のリセット)

lockout duration

1 - 99998 (min)

0 - 4294967295 (min)

30

Users must log on in order to change password

user must logon to change password

0/1

0 - 4294967295

0

*** Registry Setting ***

refuse machine password change(マシンパスワード変更の禁止)

0/1

0 - 4294967295

0


pdbeditツールはアカウントセキュリティとポリシー 設定を管理できる唯一のツールである。これは、smbpasswdが出来ること と同様のことを含むスーパーセットである。

pdbeditの用途の中で特に重要なものの一つとして、 passdbバックエンドから他へのアカウント情報のインポート/エクスポート 機能がある。

ユーザーアカウントマネージャ

pdbeditツールはsmbpasswdツールと 同様、UNIX/Linuxシステムアカウントデータベース(バックエンド)中にすでに 存在するPOSIXユーザーアカウントを必要とする。システム管理者の責任と 考えられるので、ユーザーアカウントを作成するためにOSを呼び出すことは どちらのツールも行わない。NT4のドメインユーザーマネージャがアカウント を追加するために使われた時、Sambaは、ユーザー、グループ、マシンアカウント が正しく作成され、変更されることを行うために、(他のインタフェース スクリプトと同様)add user scriptを使う。 pdbeditツールを使用しても、それらのインタフェース スクリプトは使わない。

pdbeditを、ユーザーとマシンアカウントを管理 するために使うことを試みる前に、システム(POSIX)アカウントが すでに作成されているかを確かめておくこと。

ユーザーとマシンアカウントの表示

以下は、tdbsamパスワードバックエンド中に格納されているユーザーアカウント 情報の例である。表示は以下のコマンドを実行することで行える:

$ pdbedit -Lv met
UNIX username:        met
NT username:          met
Account Flags:        [U          ]
User SID:             S-1-5-21-1449123459-1407424037-3116680435-2004
Primary Group SID:    S-1-5-21-1449123459-1407424037-3116680435-1201
Full Name:            Melissa E Terpstra
Home Directory:       \\frodo\met\Win9Profile
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\frodo\Profiles\met
Domain:               MIDEARTH
Account desc:
Workstations:         melbelle
Munged dial:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time:         Mon, 18 Jan 2038 20:14:07 GMT
Password last set:    Sat, 14 Dec 2002 14:37:03 GMT
Password can change:  Sat, 14 Dec 2002 14:37:03 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT

アカウントは古いsmbpasswd形式でも表示出来る:

root# pdbedit -Lw
root:0:84B0D8E14D158FF8417EAF50CFAC29C3:
     AF6DD3FD4E2EA8BDE1695A3F05EFBF52:[U          ]:LCT-42681AB8:
jht:1000:6BBC4159020A52741486235A2333E4D2:
     CC099521AD554A3C3CF2556274DBCFBC:[U          ]:LCT-40D75B5B:
rcg:1002:E95D4331A6F23AF8AAD3B435B51404EE:
     BB0F2C39B04CA6100F0E535DF8314B43:[U          ]:LCT-40D7C5A3:
afw:1003:1AAFA7F9F6DC1DEAAAD3B435B51404EE:
     CE92C2F9471594CDC4E7860CA6BC62DB:[T          ]:LCT-40DA501F:
met:1004:A2848CB7E076B435AAD3B435B51404EE:
     F25F5D3405085C555236B80B7B22C0D2:[U          ]:LCT-4244FAB8:
aurora$:1005:060DE593EA638B8ACC4A19F14D2FF2BB:
     060DE593EA638B8ACC4A19F14D2FF2BB:[W          ]:LCT-4173E5CC:
temptation$:1006:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
     A96703C014E404E33D4049F706C45EE9:[W          ]:LCT-42BF0C57:
vaioboss$:1001:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
     88A30A095160072784C88F811E89F98A:[W          ]:LCT-41C3878D:
frodo$:1008:15891DC6B843ECA41249940C814E316B:
     B68EADCCD18E17503D3DAD3E6B0B9A75:[W          ]:LCT-42B7979F:
marvel$:1011:BF709959C3C94E0B3958B7B84A3BB6F3:
     C610EFE9A385A3E8AA46ADFD576E6881:[W          ]:LCT-40F07A4

このコマンドが返すアカウント情報は、左から右に、以下の、コロンで 分離されたデータを含む:

  • ログインID。

  • UNIX UID。

  • Microsoft LanManagerパスワードハッシュ(パスワードは大文字に変換された後ハッシュされる)。

  • Microsoft NTパスワードハッシュ(大文字小文字の状態を保持したパスワードのハッシュ)。

  • Samba SAM アカウントフラグ。

  • LCTデータ(パスワード最終変更時刻)。

アカウントフラグパラメーターはpdbeditマニュアルページに 説明があり、 アカウントフラグ管理の節 で簡単に説明されている。

LCTデータは8桁の16進値で、最後にパスワードが変更された時刻の、 1970年1月1日からの値を保持している。

ユーザーアカウントの追加

pdbeditは、スタンドアロンサーバーまたはドメインに ユーザーアカウントを追加する時に使える。ここで紹介する例では、 vlaanというユーザーのアカウントが、SambaSAMAccount を追加する前に作成されている。

root#  pdbedit -a vlaan
new password: secretpw
retype new password: secretpw
Unix username:        vlaan
NT username:          vlaan
Account Flags:        [U          ]
User SID:             S-1-5-21-726309263-4128913605-1168186429-3014
Primary Group SID:    S-1-5-21-726309263-4128913605-1168186429-513
Full Name:            Victor Laan
Home Directory:       \\frodo\vlaan
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\frodo\profiles\vlaan
Domain:               MIDEARTH
Account desc:         Guest User
Workstations:
Munged dial:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time:         Mon, 18 Jan 2038 20:14:07 GMT
Password last set:    Wed, 29 Jun 2005 19:35:12 GMT
Password can change:  Wed, 29 Jun 2005 19:35:12 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

アカウントの削除

以下のコマンドを実行することで、SambaSAMAccountデータベースから アカウントを削除できる。

root#  pdbedit -x vlaan

アカウントは出力結果なしで削除される。アカウントはSambaSAMAccount (passdb バックエンド)データベースからのみ削除され、UNIXアカウント バックエンドからは削除されない。

アカウントを削除するためにNT4ドメインユーザーマネージャを使うと、 delete user scriptを起動するが、それは pdbeditツールではない。

ユーザーアカウントの変更

pdbeditマニュアルページにこのツールで有効な すべての操作の完全な詳細が記述されている。

下記は、ユーザーアカウント情報の、フルネーム情報を変更する例である:

root#  pdbedit -r --fullname="Victor Aluicious Laan" vlaan
...
Primary Group SID:    S-1-5-21-726309263-4128913605-1168186429-513
Full Name:            Victor Aluicious Laan
Home Directory:       \\frodo\vlaan
...

ユーザーのパスワードが満了して、ユーザーがパスワードを変更できなくなった を仮定してみよう。そのアカウントと本来のパスワードで作業が出来るように するには、ユーザーに追加の猶予時間が必要かもしれない。これは、どのように パスワード満了の設定を更新できるかの例を示している。

root#  pdbedit -Lv vlaan
...
Password last set:    Sun, 09 Sep 2001 22:21:40 GMT
Password can change:  Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Thu, 03 Jan 2002 15:08:35 GMT
Last bad password   : Thu, 03 Jan 2002 15:08:35 GMT
Bad password count  : 2
...

ユーザーは2回ログオンに失敗し、次でアカウントがロックされるが、 パスワードはすでに満了している。以下で、どのようにこのアカウントを リセットするかを示す。

root#  pdbedit -z vlaan
...
Password last set:    Sun, 09 Sep 2001 22:21:40 GMT
Password can change:  Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Thu, 03 Jan 2002 15:08:35 GMT
Last bad password   : 0
Bad password count  : 0
...

Password must change:パラメーターは以下のようにして リセットする:

root#  pdbedit --pwd-must-change-time=1200000000 vlaan
...
Password last set:    Sun, 09 Sep 2001 22:21:40 GMT
Password can change:  Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Thu, 10 Jan 2008 14:20:00 GMT
...

別の方法として、このツールで日付を設定する方法もある:

root#  pdbedit --pwd-must-change-time="2010-01-01" \
              --time-format="%Y-%m-%d" vlaan
...
Password last set:    Sun, 09 Sep 2001 22:21:40 GMT
Password can change:  Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Fri, 01 Jan 2010 00:00:00 GMT
...

時刻の形式についての情報は、strptimeマニュアルページを参照のこと。

SambaSAMAccountの操作に関するさらなる情報はpdbeditのマニュアルページ を参照のこと。

アカウントフラグ管理

Samba SAMアカウントフラグはSambaソースコード中で、ACB (account control block)と呼ばれている。Sambaソースコードの一部では、 これらはaccount encode_bitsやaccount control flagsとしても参照される。

手動での、ユーザー、マシン(ワークステーションまたはサーバー)、あるいは ドメイン間信頼アカウントのアカウントフラグの調整は、通常Sambaを 使用している場合には必要ない。別の観点からすると、何らかの理由で この情報が壊れた場合、壊れたデータの修正ができる可能性があると便利で ある。そのような修正のためのツールの選択枝はpdbedit ユーティリティである。

固有のSamba管理ツールを作成する開発者からアカウントフラグの情報に関する いくつかの要求があった。アカウントフラグの適切な管理に関する必要な情報 例は、LDAPディレクトリを管理するためのスクリプトの開発時に明白である。

アカウントフラグフィールドは最大16文字である。現在11個が使われている。 Samba SAM Accountコントロールブロックフラグ に一覧がある。pdbeditコマンドによって指定されたフラグの 順番に意味はない。実際、LDAPディレクトリ中のSambaAcctFlagsレコード中を どのような順番にしても問題はない。

Table 11.2. Samba SAM Accountコントロールブロックフラグ

フラグ説明
Dアカウントが無効。
Hホームディレクトリが必要。
Iドメイン間信頼アカウント。
Lアカウントが自動ロックされている。
MMNS (Microsoft network service)ログオンアカウント。
Nパスワードが不要。
Sサーバー信頼アカウント。
T一時的な重複アカウントエントリ。
U通常のユーザーアカウント。
Wワークステーション信頼アカウント。
Xパスワードは満了していない。

アカウントコントロールフラグを設定するためのpdbedit 使用例は以下の通り:

root#  pdbedit -r -c "[DLX]" jht
Unix username:        jht
NT username:          jht
Account Flags:        [DHULX      ]
User SID:             S-1-5-21-729263-4123605-1186429-3000
Primary Group SID:    S-1-5-21-729263-4123605-1186429-513
Full Name:            John H Terpstra,Utah Office
Home Directory:       \\aurora\jht
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\aurora\profiles\jht
Domain:               MIDEARTH
Account desc:         BluntObject
Workstations:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time:         0
Password last set:    Sun, 03 Jul 2005 23:19:18 GMT
Password can change:  Sun, 03 Jul 2005 23:19:18 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

以下を実行することでフラグを既定値に設定できる:

root#  pdbedit -r -c "[]" jht
Unix username:        jht
NT username:          jht
Account Flags:        [U          ]
User SID:             S-1-5-21-729263-4123605-1186429-3000
Primary Group SID:    S-1-5-21-729263-4123605-1186429-513
Full Name:            John H Terpstra,Utah Office
Home Directory:       \\aurora\jht
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\aurora\profiles\jht
Domain:               MIDEARTH
Account desc:         BluntObject
Workstations:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time:         0
Password last set:    Sun, 03 Jul 2005 23:19:18 GMT
Password can change:  Sun, 03 Jul 2005 23:19:18 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

ドメインアカウントポリシー管理

設定されているドメインアカウントアクセスポリシーを見るためには以下を実行する:

root#  pdbedit -P ?
No account policy by that name
Account policy names are :
min password length
password history
user must logon to change password
maximum password age
minimum password age
lockout duration
reset count minutes
bad lockout attempt
disconnect time
refuse machine password change

ドメインに対する以下の制御を確立するとする:

  1. min password length = 8 characters.

  2. password history = last 4 passwords.

  3. maximum password age = 90 days.

  4. minimum password age = 7 days.

  5. bad lockout attempt = 8 bad logon attempts.

  6. lockout duration = forever, account must be manually reenabled.

以下のコマンドでこれらの設定を実行する:

root#  pdbedit -P "min password length" -C 8
account policy value for min password length was 5
account policy value for min password length is now 8
root#  pdbedit -P "password history" -C 4
account policy value for password history was 0
account policy value for password history is now 4
root#  pdbedit -P "maximum password age" -C 7776000
account policy value for maximum password age was 4294967295
account policy value for maximum password age is now 7776000
root#  pdbedit -P "minimum password age" -C 7
account policy value for minimum password age was 0
account policy value for minimum password age is now 7
root#  pdbedit -P "bad lockout attempt" -C 8
account policy value for bad lockout attempt was 0
account policy value for bad lockout attempt is now 8
root#  pdbedit -P "lockout duration" -C -1
account policy value for lockout duration was 30
account policy value for lockout duration is now 4294967295

Note

最大(無限)なロックアウト時間を設定するためには値として-1を使用する。

Warning

アカウントポリシーはおのおののPDCとBDC上で個別にに設定する必要がある。この時点 (Samba 3.0.11からSamba3.0.14a)で、アカウントポリシーは自動的に複製されない。 これはSamba3.0.20がリリースされるか、それより少し後に修正される予定である。 Samba-3リリースファイル中の、この機能に関する特定の更新情報がある WHATSNEW.txt ファイルをチェックしてみること。

アカウントのインポート/エクスポート

pdbeditツールはあるバックエンドからほかのものに 認証情報(アカウント)データベースのインポート/エクスポートができる。 例えば、古いsmbpasswdデータベースから tdbsamバックエンドにアカウントをインポート/ エクスポートするためには以下のように行う:

  1. root# pdbedit -i smbpasswd -e tdbsam
    

  2. smb.conf中のpassdb backendの設定を smbpasswdからtdbsamに 置き換える。

パスワードバックエンド

Sambaはバックエンドアカウントデータベースのデザインに柔軟性を提供する。この柔軟性 は探せばすぐに見つかる。Sambaにおける最近の変更(Samba 3.0.23以降)はいくつかのインストール時 にうまくいかなくなる問題を単純化するために複数バックエンド機能が削除された。この 削除によりSamba-3の内部動作はより首尾一貫し安定した。

Samba 3.0.23から、もはや複数のpassdbバックエンドを指定して使うことは出来なくなった。 それ以前のSamba-3では、同じタイプのバックエンドを含む複数のpassdbバックエンドが指定できた。 複数のpassdbバックエンド機能は名前->SID変換とSID->名前解決で多くの問題を引き起こした。 Sambaチームはいろいろと検討した結果この機能を取り除く必要があると決定した。

平文

古いバージョンのSambaではUNIXユーザーデータベースからユーザー情報を検索し、 結局いくつかの他のフィールドは/etc/samba/smbpasswd/etc/smbpasswdファイルから得ていた。パスワードの 暗号化が無効になっている時、SMB固有のデータは全く格納されない。その代わり、 すべての操作はSambaホストOSがその/etc/passwd データベースによってアクセスする方法経由で制御される。ほとんどのLinux システムでは、たとえば、すべてのユーザーとグループの解決はPAM経由で行われる。

smbpasswd: 暗号化したパスワードデータベース

伝統的にencrypt passwords = yes とSambaのsmb.confファイル中で設定した時、ユーザー名、LM/NTパスワード ハッシュ、パスワード変更時間とアカウントフラグのようなユーザーアカウント 情報はsmbpasswd(5)ファイルに格納される。これは、 たくさんのユーザー(数千くらい)を抱えるサイトに対するアプローチとしては 不利である。

  • 最初の問題は、すべての検索をシーケンシャルに行わなければならないという ことである。ドメインログオン時におおよそ二つの検索(1つは最初のログオン 検証で、もう1つはセッション接続セットアップで、それはネットワーク ドライブやプリンターのマッピング)が行われ、これは、大きなサイトでは、 性能のボトルネックになる。この場合必要なことは、データベースを使う ような、インデックスを使うアプローチである。

  • 二番目の問題は、一つ以上のSambaサーバーにsmbpasswdファイルを複製しよう とする管理者は、たとえば、rsync(1)ssh(1)と、内製したカスタムスクリプトのような 外部ツールを使う必要があるということである。

  • 最後に、smbpasswdエントリ中に格納されている情報の量には、たとえば ホームディレクトリ、パスワード満了時刻や相対識別子(RID)のような 追加の属性を入れる領域がない。

上記のような機能不足の点から、ユーザー属性を格納するより堅牢な手段を smbdによって使うことが開発されてきた。ユーザーアカウントにアクセス することを定義するAPIは、共通的にsamdbインタフェースとして参照される (以前には、これはpassdb APIとして呼ばれていて、現在もSambaソース コード中ではそのように名前が付けられている)。

Sambaは、Samba平文データベースの機能不足点を克服する一連の拡張された passdbバックエンドを提供している。これらはtdbsamとldapsamである。 もちろん、ldapsamは、大きな会社や巨大サイトが興味を持つものである。

tdbsam

SambaはTDB(trivial database)中にユーザーとマシンアカウント を格納できる。このバックエンドを使う時には追加の設定は不要である。 このバックエンドはLDAPを必要としない、新しくインストールする場合に 推奨される。

一般的なガイドとして、Sambaチームは250人あるいはそれ以上のユーザーが いるサイトに、tdbsamバックエンドを使うことを推奨していない。さらに 追加で、tdbsamは、アカウントデータベースを複製することが要求される PDC/BDC実装を要求するサイト中で使うための拡張性の能力はない。 明確にいうと、拡張性という理由で、ldapsamを使用すべきである。

250ユーザー制限は、純粋に、一般的に、おそらく一つ以上の物理配置 にまたがってばらけている、ルーティングネットワークを持つサイトを必要 とするという概念に基づく目安でしかない。Sambaチームは現時点で、tdbsam アーキテクチャのパフォーマンスベースの拡張性制限を把握していない。

数千のユーザーを抱えているが、1台のサーバーだけを必要とするサイトがある。 1つのサイトは最近UNIXシステム上で4500ユーザーを保持していることを報告し、 tdbsampassdbバックエンドでよい性能が出たことを 報告した。tdbsampassdbバックエンドを使う場合の制限は、 TDB格納場所の制限に関連し、それはSambaSAMAccountバックエンドのための 分散メカニズムの必要性にのみ基づく。

ldapsam

ldapsamが提供しないいくつかの弱点がある。この文書で参照されるLDAP サポートは以下を含まない:

  • Windows 200x Active Directoryサーバーからの ユーザーアカウント情報を検索する手段。

  • /etc/passwdを置き換える手段。

2番目の項目はLDAP NSSとPAMモジュールを使うことにより達成できる。LGPL バージョンのそれらのライブラリは PADL Softwareで作成されて いる。これらのパッケージに着いてのより詳細な情報は、 Gerald CarterによるLDAP, System Administration の第6章、NISを置き換えるを参照のこと。

このドキュメントでは、伝統的にsmbpasswd(5)ファイルに格納されている Sambaユーザーアカウント情報をLDAPディレクトリに格納するための使い方に ついて説明している。読者はすでに基本的なLDAPの概念とすでにインストール している動作中のディレクトリサーバーを持っていることを仮定している。 LDAPのアーキテクチャとディレクトリについてのより詳細な情報は、以下の サイトを参照してほしい:

有効に使える2つのSambaリソースは以下の通り:

  • The Samba-PDC-LDAP-HOWTO Ignacio Coupeauによって管理されている。

  • IDEALXからのNTマイグレーション スクリプトは、Samba-LDAPドメインコントローラー構成でユーザーとグループの 管理に関連づけるものである。Idealxはsmbldap-toolsと対話的な コンソール管理ツールも作成している。

サポートしているLDAPサーバー

LDAPのldapsamコードはOpenLDAP 2.xサーバーとクライアントライブラリを 使って開発とテストが行われている。同じコードはNetscape's Directory Server とクライアントSDKでも動作する。しかし、それらはコンパイルエラーとバグが 必ず生じる。それらを直すのはとても難しい。 バグ報告中で概要が説明されている手順 経由で修正を投稿してほしい。

Sambaは任意の標準準拠のLDAPサーバーとともに動作できる。

RFC 2307 posixAccountとの関係とスキーマ

Samba-3.0はソースコードディストリビューション中の examples/LDAP/samba.schema中にある OpenLDAP 2.x用に必要なスキーマファイルを用意している。 sambaSamAccountオブジェクトクラスのスキーマエントリは以下の通り:

ObjectClass (1.3.6.1.4.1.7165.2.2.6 NAME 'sambaSamAccount' SUP top AUXILIARY
    DESC 'Samba-3.0 Auxiliary SAM Account'
    MUST ( uid $ sambaSID )
    MAY  ( cn $ sambaLMPassword $ sambaNTPassword $ sambaPwdLastSet $
          sambaLogonTime $ sambaLogoffTime $ sambaKickoffTime $
          sambaPwdCanChange $ sambaPwdMustChange $ sambaAcctFlags $
          displayName $ sambaHomePath $ sambaHomeDrive $ sambaLogonScript $
          sambaProfilePath $ description $ sambaUserWorkstations $
          sambaPrimaryGroupSID $ sambaDomainName ))

samba.schemaファイルはOpenLDAP 2.0/2.1 用の形式である。Sambaチームは上記のスキーマが使うOID空間を 所有し、この利用を推奨している。もしもNetscape DSが使うように スキーマを変換したならば、 jerry@samba.org にパッチとしてスキーマファイルを送ってほしい。

smbpasswdファイルが、ユーザーの/etc/passwdエントリ に追加の情報を提供する情報を格納するように、sambaSamAccountアカウント オブジェクトはUNIXユーザーアカウント情報を補う。sambaSamAccountは 補助型オブジェクトクラスであるので、LDAP ディレクトリ中の存在するユーザーアカウント情報に付随するものとして 使うことが出来、Sambaアカウントの操作のために必要な情報を提供する。 しかし、RFC2307で定義されているposixAccountオブジェクトクラスと 重複するいくつかのフィールド(たとえばuid)がある。これは意図的なものである。

すべてのユーザーアカウント情報(UNIXとSamba)をディレクトリ中に格納する ために、sambaSamAccountとposixAccountオブジェクトクラスを組み合わせて 使う必要がある。しかし、smbdはそれでもgetpwnam() のような標準Cライブラリコール経由でユーザーのUNIXアカウント情報を、 得ることがある。これは、SambaサーバーはLDAP NSSライブラリのインストールと 正しく動くための設定も必要とすることを意味する。このように情報を区分することで、 すべてのSambaアカウント情報をLDAP中に格納することが出来るようにするが、 ネットワークが完全なLDAP基盤に移行しながら、UNIX のアカウント情報は NISで管理することができる。

OpenLDAPの設定

OpenLDAPディレクトリサーバー中でsambaSamAccountのサポートを行うためには、 最初にsamba.schemaファイルをslapdの設定ディレクトリにコピーする。 samba.schemaファイルはSambaソースディストリビューション中の examples/LDAPディレクトリ中にある。

root# cp samba.schema /etc/openldap/schema/

次に、slapd.conf中にsamba.schema ファイルを含める。sambaSamAccountオブジェクトは他のスキーマファイルに 依存する2つの属性を含んでいる。uid属性は cosine.schema中で定義され、 displayName属性は inetorgperson.schema中で定義されている。両方は samba.schemaファイルの前で定義しておかなければならない。

## /etc/openldap/slapd.conf

## スキーマファイル(core.schemaは既定値で必要とされる)
include	           /etc/openldap/schema/core.schema

## sambaSamAccountに必要なもの
include            /etc/openldap/schema/cosine.schema
include            /etc/openldap/schema/inetorgperson.schema
include            /etc/openldap/schema/nis.schema
include            /etc/openldap/schema/samba.schema
....

以下の例のように、sambaSamAccountオブジェクトクラス上での検索のスピード を上げるため、最もよく使う属性のいくつかにインデックスを付加することは 推奨される(そして、可能ならばそれはposixAccountとposixGroupも)。

# インデックスの管理
## OpenLDAPで要求されるもの
index objectclass             eq

index cn                      pres,sub,eq
index sn                      pres,sub,eq
## pdb_getsampwnamをサポートするのに必要なもの
index uid                     pres,sub,eq
## pdb_getsambapwrid()をサポートするのに必要なもの
index displayName             pres,sub,eq

## uncomment these if you are storing posixAccount and
## posixGroup entries in the directory as well
##index uidNumber               eq
##index gidNumber               eq
##index memberUid               eq

index   sambaSID              eq
index   sambaPrimaryGroupSID  eq
index   sambaDomainName       eq
index   default               sub

以下を実行し新しいインデックスを作成する:

root# ./sbin/slapindex -f slapd.conf

上記の変更後、slapdを再起動するのを忘れないこと:

root# /etc/init.d/slapd restart

LDAPデータベースの初期化

LDAPデータベースにアカウントが追加できる前に、格納するためのアカウント コンテナを作成する必要がある。以下のLDIFファイルは必要に応じて変更 する必要がある(DNSエントリなど):

# Organization for Samba Base
dn: dc=quenya,dc=org
objectclass: dcObject
objectclass: organization
dc: quenya
o: Quenya Org Network
description: The Samba-3 Network LDAP Example

# Organizational Role for Directory Management
dn: cn=Manager,dc=quenya,dc=org
objectclass: organizationalRole
cn: Manager
description: Directory Manager

# Setting up container for Users OU
dn: ou=People,dc=quenya,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People

# Setting up admin handle for People OU
dn: cn=admin,ou=People,dc=quenya,dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz
# Setting up container for groups
dn: ou=Groups,dc=quenya,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Groups

# Setting up admin handle for Groups OU
dn: cn=admin,ou=Groups,dc=quenya,dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz

# Setting up container for computers
dn: ou=Computers,dc=quenya,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Computers

# Setting up admin handle for Computers OU
dn: cn=admin,ou=Computers,dc=quenya,dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz

上記で示されているuserPasswordはslappasswdを使って 生成する必要がある。

以下のコマンドでLDAPデータベース中にLDIFの内容をロードする。

$ slapadd -v -l initldap.dif

adminパスワードと同様に、アクセス制御リストを十分に使ってLDAPサーバーの 安全性を確保することを忘れないこと。

Note

SambaがLDAPサーバーにアクセスできる前に、Samba-3の secrets.tdbデータベース中にLDAP adminパスワード を以下のようにして格納する必要がある:

root# smbpasswd -w secret

Sambaの設定

以下のsmb.conf中のパラメーターは、SambaがLDAPサポートを出来るように 構築された場合にのみ有効である。Sambaは、LDAPライブラリを見つけると、 自動的にLDAPをサポートするように構築する。LDAPをサポートしているか 否かを調べる最も良い方法は以下の通り:

root#  smbd -b | grep LDAP
   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_DOMAIN2HOSTLIST
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS

もしも使用したsmbdコマンドがHAVE_LDAP_H を出力しない場合、なぜLDAPヘッダーとライブラリがコンパイル中に見つから なかったかということを調べる必要がある。

LDAP関連のsmb.confオプションは以下の通り:

passdb backend = ldapsam:url

これらはsmb.confマニュアルページに説明があり、ここでは繰り返さない。 しかし、LDAPディレクトリを使うための例は LDAP使用の設定例にある。

Example 11.2. LDAP使用の設定例

[global]
security = user
encrypt passwords = yes
netbios name = MORIA
workgroup = NOLDOR
# LDAP関連のパラメーター:
# LDAPサーバーにバインドする時に使うDNの定義。
# smb.conf中にはこのDNのパスワードは格納されない。
# これは'smbpasswd -w secret'を使って
# secrets.tdbファイル中にパスフレーズを格納する。
# "ldap admin dn"を変更する場合、再設定する必要がある。
ldap admin dn = "cn=Manager,dc=quenya,dc=org"
# ディレクトリに接続ときのSSLオプションを設定する:
# ('off', 'start tls', または 'on' (既定値))
ldap ssl = start tls
# syntax: passdb backend = ldapsam:ldap://server-name[:port]
passdb backend = ldapsam:ldap://frodo.quenya.org
# smbpasswd -x delete the entire dn-entry
ldap delete dn = no
# マシンとユーザーサフィックスはベースサフィックスに追加される
# 引用符なしで記述すること。未定義状態が既定値である
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
# LDAP中の信頼UNIXアカウント情報
# (詳細はsmb.confマニュアルページを参照)
# ディレクトリを検索する時に使うベースDNの指定
ldap suffix = dc=quenya,dc=org

アカウントとグループの管理

ユーザーアカウントはsambaSamAccountオブジェクトクラスを通じて管理 されるため、使っている管理ツールをsambaSamAccount属性を扱えるよう に修正する必要がある。

マシンアカウントはsambaSamAccountオブジェクトクラスを使って管理 されるため、ユーザーアカウントと同じように扱われる。しかし、これらの アカウントをLDAP名前空間の異なったツリーに格納することはそれも 可能である。グループを格納するために、 ou=Groups,dc=quenya,dc=orgを使うべきであり、 ユーザーのためにou=People,dc=quenya,dc=orgを 使うべきである。NSSとPAMの設定をそれに合わせて設定すること (通常は、/etc/openldap/sldap.conf設定 ファイル中で設定する)。

Samba-3では、グループ管理システムはPOSIXグループをベースにして いる。これは、SambaはposixGroupオブジェクトクラスを使うという ことを意味する。今の所、NT風のグループシステム管理はない( グローバルとローカルグループという)。Samba-3は Domain Groupsのみを認識し、Microsoft Windows 2000と Active Directoryとは異なり、Samba-3はネスト されたグループをサポートしない。

セキュリティとsambaSamAccount

ディレクトリ中のsambaSAMAccountエントリについてのセキュリティに関する 議論の際に覚えておかなければならない2つの重要な観点がある。

  • 絶対にSambaLMPasswordか SambaNTPasswordの属性値を暗号化されていないLDAPセッション下で検索しない。

  • 絶対に管理者以外のユーザーに SambaLMPasswordかSambaNTPasswordの属性値を閲覧させない。

これらのパスワードハッシュは平文と同等であり、オリジナルの平文 文字列を得ないでもユーザーを詐称するために使える。LM/NTハッシュ についてのより詳細な情報は、この章の アカウント情報データベース を参照のこと。

最初のセキュリティ問題に対応するため、ldap ssl smb.confパラメーターは、ディレクトリサーバーに接続する際に、 既定値のポート636を使う暗号化セッション (ldap ssl = on)を既定値で 要求する。OpenLDAPサーバーを使う場合、LDAPSを指定する場所で、 StartTLS LDAP拡張操作を使うことが可能である。この場合、安全な 通信プロトコルを使うことを強く推奨する(そのため、 ldap ssl = offを設定しては ならない)。

LDAPSプロトコルはLDAPv3 StartTLS拡張オプションが優先されるので、非推奨 であることに注意。しかし、OpenLDAPライブラリは引き続きクライ アントとサーバー間の古い安全な通信方法をサポートする。

次の安全対策は、管理者以外がディレクトリからパスワードハッシュを 得ることを防ぐことである。これはslapd.conf 中に以下のACLを設定することで行える:

## "ldap admin dn" アクセスは許可するがそれ以外は拒否
access to attrs=SambaLMPassword,SambaNTPassword
     by dn="cn=Samba Admin,ou=People,dc=quenya,dc=org" write
     by * none

sambaSamAccountsのための特別なLDAP属性

sambaSamAccountオブジェクトクラスは以下の表にあるような属性の集合である: Part APart B

Table 11.3. Attributes in the sambaSamAccountのオブジェクトクラス(LDAP), Part A

sambaLMPassword16進文字列表現で格納されているLanManパスワードの16バイトハッシュ値。
sambaNTPassword16進文字列表現で格納されているNTパスワードの16バイトハッシュ値。
sambaPwdLastSetsambaLMPasswordsambaNTPasswordが 最後に設定された時刻の、1970年からの経過秒数(整数値)。
sambaAcctFlags大カッコ[]で囲まれた11文字の文字列で、U(ユーザー)、W(ワークステーション)、 X(パスワード満了なし)、I(ドメイン信頼アカウント)、H(ホームディレクトリが必要)、 S(サーバー信頼アカウント)とD(無効)のようなアカウントフラグが格納。
sambaLogonTime未使用(整数値)。
sambaLogoffTime未使用(整数値)。
sambaKickoffTimeユーザーがロックされてログインできなくなる時刻(UNIX時刻形式)を指定。 もしも属性が省略された場合、アカウントは決して満了しない。この 属性をshadowAccountオブジェクトクラスのshadowExpire属性と一緒に 使うことで正確な日時で完全にアカウントを満了できる。
sambaPwdCanChangeユーザーにパスワード変更が許可されている時刻(UNIX時刻形式)。 もしもこの属性が設定されていない場合、ユーザーは任意の時刻に パスワードを変更できる。
sambaPwdMustChangeパスワードを強制的に変更しなければならない時刻(UNIX時刻形式)。 もしもこの値が0ならば、ユーザーは最初のログイン時にパスワードを変更 しなければならない。この属性が設定されていない場合、パスワードは 決して満了しない。
sambaHomeDrivesambaHomePathによって指定されるUNCパスにマップされるドライブ 名を指定。ドライブ名はXがマップするドライブ名である、 X:という形式で指定する必要がある。 smb.conf(5)マニュアルページ中のlogon drive パラメーターにある詳細を参照のこと。
sambaLogonScriptsambaLogonScriptプロパティは、.CMD, .EXE, や .BATファイルの ようなユーザーのログオンスクリプトのパスを指定する。文字列は空 でもよい。パスはnetlogon共有からの相対パスである。詳細な情報は、 smb.confマニュアルページのlogon script パラメーターを参照のこと。
sambaProfilePathユーザーのプロファイルのパスを指定。この値は空、ローカル な絶対パス、あるいはUNCパスが使える。詳細な情報は、smb.conf マニュアルページのlogon pathパラメーター を参照のこと。
sambaHomePathユーザーのホームディレクトリのパスを指定するsambaHomePath プロパティ。この値は空でも良い。もしもsambaHomeDriveが 設定され、ドライブ名の場合、sambaHomePathはUNCパスである 必要がある。パスは\\server\share\directory のようなネットワークUNCパスでなければならない。詳細な情報は、 smb.confマニュアルページのlogon home パラメーターを参照のこと。

Table 11.4. sambaSamAccountオブジェクトクラスの属性, Part B

sambaUserWorkstationsユーザーのログイン可能な、カンマで分離されたマシンのリスト。 Sambaドメインメンバーに接続することを試みる時に問題が発生する かもしれない。なぜならば、ドメインメンバーがこのリストになく、 ドメインコントローラーはそれを拒否するため。この属性が省略された 場合、既定値は何の制限がないことを仮定する。
sambaSIDユーザーのセキュリティ識別子(SID)。WindowsにおけるUNIX UID相当のもの。
sambaPrimaryGroupSIDユーザーのプライマリグループのセキュリティ識別子(SID)。
sambaDomainNameユーザーが属するドメイン。

これらのパラメーターの大多数はSambaがドメイン (どのようにSambaをPDCとして設定するかについての詳細がある ドメイン制御を参照)として振る舞う 時にのみ使われる。以下の4つの属性は、値が既定値でない場合にのみ sambaSamAccountエントリに格納される。

  • sambaHomePath

  • sambaLogonScript

  • sambaProfilePath

  • sambaHomeDrive

これらの属性は、値が既定値でない場合にのみsambaSamAccountに 格納される。例えば、MORIAがPDCとして設定され、そのsmb.conf ファイル中でlogon home = \\%L\%u が定義されているとする。beckyという名前のユーザーが がドメインにログオンした時にはlogon home 文字列は\\MORIA\beckyに展開される。もしも、smbHome属性が uid=becky,ou=People,dc=samba,dc=orgエントリ中に 存在するならば、この値が使われる。しかし、もしもこの属性が存在 しない場合、logon homeパラメーターの値が その場所に使われる。Sambaは、値が既定値以外の何かである場合 (例えば\\MOBY\becky)にのみ、属性値を ディレクトリエントリに書き込む。

sambaSamAccountのLDIFエントリの例

以下は、SambaSamAccountオブジェクトクラスの、動作するLDIFの使用例である。

dn: uid=guest2, ou=People,dc=quenya,dc=org
sambaLMPassword: 878D8014606CDA29677A44EFA1353FC7
sambaPwdMustChange: 2147483647
sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-513
sambaNTPassword: 552902031BEDE9EFAAD3B435B51404EE
sambaPwdLastSet: 1010179124
sambaLogonTime: 0
objectClass: sambaSamAccount
uid: guest2
sambaKickoffTime: 2147483647
sambaAcctFlags: [UX         ]
sambaLogoffTime: 2147483647
sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5006
sambaPwdCanChange: 0

以下はsambaSamAccountとposixAccountオブジェクトクラスに対するLDIF エントリである:

dn: uid=gcarter, ou=People,dc=quenya,dc=org
sambaLogonTime: 0
displayName: Gerald Carter
sambaLMPassword: 552902031BEDE9EFAAD3B435B51404EE
sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-1201
objectClass: posixAccount
objectClass: sambaSamAccount
sambaAcctFlags: [UX         ]
userPassword: {crypt}BpM2ej8Rkzogo
uid: gcarter
uidNumber: 9000
cn: Gerald Carter
loginShell: /bin/bash
logoffTime: 2147483647
gidNumber: 100
sambaKickoffTime: 2147483647
sambaPwdLastSet: 1010179230
sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5004
homeDirectory: /home/moria/gcarter
sambaPwdCanChange: 0
sambaPwdMustChange: 2147483647
sambaNTPassword: 878D8014606CDA29677A44EFA1353FC7

パスワードの同期

Samba-3以降のバージョンは、アカウントとして格納される非Samba(LDAP)パスワード を更新できる。pam_ldapを使う場合、UNIXとWindowsパスワードを同時に変更できる。

ldap passwd syncオプションでは、 設定可能なldap passwd sync の値にある値を使うことが出来る。

Table 11.5. 設定可能なldap passwd syncの値

説明
yes

ユーザーがパスワード変更時に SambaNTPassword, SambaLMPasswordpasswordフィールドを更新する。

no

SambaNTPasswordSambaLMPasswordのみ更新する。

only

LDAPパスワードとLDAPサーバーに他の フィールドについても更新を行う。このオプションはいくつかのLDAP サーバーと、LDAPサーバーがLDAP_EXOP_X_MODIFY_PASSWDをサポートする 時のみ有効である。


より詳細な情報は smb.conf マニュアルページにある。

パスワード同期のためのOpenLDAPオーバーレイの使用

Howard Chuは、smbk5pwdという特別なオーバーレイを書いた。 このツールは、LDAP_EXOP_X_MODIFY_PASSWD操作が実行される時に、 OpenLDAPエントリ中のSambaNTPassword, SambaLMPasswordHeimdalハッシュを 変更する。

オーバーレイはOpenLDAP-2.3に含まれ、 contrib/slapd-modules/smbk5pwdサブディレクトリ にある。このモジュールはOpenLDAPでも使える。

よくあるエラー

ユーザーがログオンできない

Sambaをインストールしたが、UNIXアカウントを使ってログオンできない!

現在のpassdb backendにユーザーが追加されて いるかを確認すること。詳細は アカウント管理ツールを読むこと。

auth methodsの設定

明示的にauth methodsパラメーターを設定する場合、 guestはエントリの最初の行に指定しなければならない 例えば、auth methods = guest samである。

Chapter 12. グループのマッピング: Microsoft Windows と UNIX

John H. Terpstra

Samba Team

Jean François Micouleau

Gerald (Jerry) Carter

Samba Team

Samba-3からWindowsのグループSIDとUNIXのグループを関連づける新しいグループ マッピング機能が利用できる。netツールに含まれる。groupmap サブコマンドを、 関連づけの管理に使用する。

NTのグループとUNIXのシステムグループをマッピングするこの新しい機能では、 管理者が、どのNTドメイングループをMicrosoft Windowsクライアントに公開するか を決定することができる。既定値(-1)以外の値を持つ UNIXのグループにマッピングするNT のグループのみが、ドメインユーザー及び グループにアクセスするツールのグループ選択リストに含まれる。

Warning

Samba-3ではdomain admin groupパラメーターが削除されたので、 smb.conf中にもはや指定してはならない。Samba-2.2.x中では、このパラメーターは このパラメーターは、一覧表示されたユーザーに、 ワークステーション上でローカル管理 権限を与えるDomain AdminsWindowsグループのメンバーシップを 付与するのに使用されていた(既定値の設定では)。

機能と利便性

Sambaでは、管理者がMicrosoft Windows NT4/200x グループアカウントを作成し、それらを 任意にUNIX/Linuxのグループアカウントと関連づけることができる。

グループアカウントは、Microsoft Windows NT4またはMicrosoft Windows 200x/XP Professional のMMCツールを使用して管理することができる。これらのツールを使って自動的にUNIX/Linux のシステムアカウントを作成するには、適切なスクリプトをsmb.confで提供する必要が ある。それらのスクリプトが無い場合、winbinddが動作している 限りは、これらのツールを使って作成されたSambaグループアカウントはsmb.conf ファイル中のidmap uid/idmap gid パラメーターで指定されているID範囲内でUNIX UID/GIDを割り当てられる。

Figure 12.1. IDMAP: グループSIDからGIDへの解決

IDMAP: グループSIDからGIDへの解決

Figure 12.2. IDMAP: GIDから対応するSIDへの解決

IDMAP: GIDから対応するSIDへの解決

どちらのケースでもwinbinddが動作していない場合は、ローカルで解決可能なグループ のみが認識される。IDMAP: グループSIDからGIDへの解決IDMAP: GIDから対応するSIDへの解決を 参照のこと。IDMAPのグループマッピングの保存 で示すように、net groupmapが、NTのSIDに対応するUNIXグループの 作成に使用される。

Figure 12.3. IDMAPのグループマッピングの保存

IDMAPのグループマッピングの保存

smb.confのグループインタフェーススクリプトが、直接UNIX/Linuxシステムツール (shadowユーティリティ,groupadd,groupdelgroupmod)を呼び出した場合、UNIX/Linuxグループ名は、これらの ツールが課す制約を受けることを、管理者は知っていなければならない。もし、 ツールが、大文字や空白文字を認めない場合、Microsoft Windows NT4/200x風の Engineering Managersというグループの作成は、同名のUNIX/Linux グループの作成が試みられることになるが、それはもちろん失敗する。

このOSツールの制約に対しては幾つかの回避策がある。一つはOSの制約に合うUNIX/Linux システムグループ名を作成し、Sambaインターフェースの呼び出しには、UNIX/Linuxの グループID(GID)を返すようなスクリプトを使う方法である。これは、動的な回避策である。

もう一つの回避策は、手動でUNIX/Linuxグループを作成し、次に手動でSamba サーバーに Microsoft Windows NT4/200xグループを作成し、そしてnet groupmap ツールを使ってこの2つを互いに関連付けることである。

議論

コンピュータにMicrosoft Windows NT4/200xをインストール するとき、インストールプログラムは既定値のユーザーとグループを作成し、特に、 Administratorsグループの場合は、必須のシステムタスクを実行 するのに必要な権限をグループに付与する。例えば、ローカルマシンの日付や時間を変更 したり、ローカルマシン上の実行中のプロセスを止める(又は閉じる)ような権限である。

AdministratorユーザーはAdministrators グループのメンバーで、そのため、Administratorsグループの 権限を引き継ぐ。もし、joeというユーザーが Administratorsグループのメンバーとして作成された場合、 joeAdministratorというユーザーと 全く同じ権限を持つ。

Microsoft Windows NT4/200x/XPマシンがドメインメンバーになる場合、 PDCのDomain Adminsグループは、ワークステーションのローカル Administratorsグループに追加される。 Domain Adminsグループのいずれのメンバーもワークステーション にログオンすると、ローカルのAdministratorsグループの 権限を継承する。

以下のステップは、Samba PDCユーザーをDomain Adminsグループの メンバーにする方法を説明する。

  1. domadmと呼ばれるUNIXグループを作成(通常/etc/groupの中に)。

  2. このグループにAdministratorsにならなければならないユーザーを 追加。たとえば、joe, johnmary administratorsにしたいならば、/etc/groupのエントリは 下記のようになる:

    		domadm:x:502:joe,john,mary
    		

  3. 以下のコマンドを実行して、Domain Adminsグループをdomadm グループにマップする:

    root# net groupmap add ntgroup="Domain Admins" unixgroup=domadm rid=512 type=d
    

    Domain Adminsの両側の引用符は、グループ名に空白があるために 必要である。また、イコール記号(=)の前後に空白を入れないこと。

これでjoe, johnmaryはdomain administratorsになった。

任意のUNIXグループを任意のWindows NT4/200xグループにマッピングしたり、UNIX グループをWindowsドメイングループにすることが可能である。例えば、あるUNIXグループ (例: acct)をドメインメンバーマシンのローカルファイルやプリンターのACLに含めたい場合、 以下のコマンドをSamba PDC上で実行して、そのグループをドメイングループにする:

root# net groupmap add rid=1000 ntgroup="Accounting" unixgroup=acct type=d

ntgroupの値は、コマンドのデリミタとして解釈されてしまうことを 防ぐために、空白が入っている場合には引用符で囲まなければならない。

RIDパラメーターは通常1000から始まる符号なしの32ビット整数である。しかし、このRIDは ユーザーに割り当てられるRIDと重複してはならない。これを検証する方法は、使用して いるpassdbバックエンドによって異なる。このツールの今後のバージョンでは自動検証が 可能になるかもしれまないが、現行では、使用者が自分でやらなければならない。

警告:ユーザー固有のグループ問題

Windowsは同じ名前のユーザーとグループアカウントを許可しない。これは、プライベート グループを使っているすべてのサイトに重大な影響がある。プライベートグループ アカウントは、ユーザーがおのおの固有のグループアカウントを持つという管理上の 設定である。Red Hat Linuxやいくつかの自由なLinuxディストリビューションでは、 既定値でプライベートグループを作成する。

UNIX/LinuxグループアカウントがWindowsグループアカウントにマップされた場合、 すべての競合は、任意のユーザーアカウント名にWindowsドメイングループ名が オーバーラップしないことを保証することで防げる。

ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加

nested groupsとして知られているこの機能は、Samba-3.0.3 で初めて追加された。

Windows NT 3.10リリース以降のすべてのMicrosoft Windows製品は、ネストされた グループをサポートしている。セキュリティ管理をとても簡単にするので、多くの Windowsネットワーク管理者はこの機能に依存している。

ネストされたグループアーキテクチャは、日々のユーザーとグループメンバー管理をドメイン セキュリティデータベース上で実行されるべきという理由でデザインされた。グループ セキュリティの応用は、ローカルグループのみを使うドメインメンバーサーバー上で実装 されるべきである。ドメインメンバーサーバー上で、すべてのファイルシステムセキュリティ 制御は、ドメイングローバルグループとドメイングローバルユーザーを含むローカル グループの使用を制限する。

この取り決めの利便性は何か、という疑問があるかもしれない。Windowsネットワーク アーキテクチャの深い闇を知っている人にとって、答えは明確である。20万ものファイル があり、各ファイルは個別のドメインユーザーとドメイングループに設定されているサーバー について考えてみよう。ファイルサーバーを持つ会社が別の会社を買い、その結果、サーバー を別の場所に移動し、別のドメインのメンバーにするとする。誰がすべてのファイルと ディスクを所有すると思うか? 答えは「不明なアカウント」である。

ファイル所有権の混乱を解決することは、すべてのファイルとディレクトリアクセス 制御をコントロールするためにローカルグループを用いて簡単に避けられることが できる面白くない管理業務である。この場合、ローカルグループのメンバーのみが 失われる。記憶サブシステム中のファイルとディレクトリは引き続きローカル グループによって所有される。同じことはそれらに対するすべてのACLについても 存在する。サーバーがメンバーとなった新しいドメイン中のドメイングローバルグループ のための適当なエントリをもつローカルグループ内の 不明なアカウントメンバーシップエントリを削除するのは 管理的により簡単である。

ネストされたグループを使用する、もう一つの突出した例は、ドメインメンバーワーク ステーションとサーバーで管理特権の実装を伴う。管理特権は各ドメインメンバーマシンの ビルトインAdministratorsローカルグループのすべてのメンバーに 与えられる。すべてのdomain administratorsがメンバーサーバーまたはワークステーション に対してとドメインの参加に対して完全な権限を持つようにするには、 Domain AdminsグループをローカルのAdministratorsグループに 追加する。そのため、Domain Adminsグループのメンバーとしてドメインにログオンする 誰もが、各ドメインメンバー上のローカル管理特権をも持つ。

UNIX/Linuxはネストされたグループという概念を持たないので、Sambaは長い間それを サポートしてこなかった。問題は、/etc/group中の追加グループ のメンバーとしてUNIXグループを入力しなければならないことである。これは、今実装 されているUNIXファイルシステムセキュリティモデルのデザインの要求でないために 動作しない。Samba-2.2以降、winbindは、メンバーであるSambaサーバーのドメイン コントローラーからのユーザーとグループ情報をオンデマンドで /etc/groupに提供出来る。

実際、Sambaは動的なlibnss_winbindメカニズム経由で /etc/groupデータを補完する。Samba-3.0.3から、この機能は Windowsが行うのと同じ方式でローカルグループを提供するために使われる。これは、 アクセス時にその場でローカルグループに展開されることによって動作する。たとえば、 ドメインのDomain Usersグループがローカルグループ demoのメンバーになるというようなことである。Sambaが ローカル(alias)グループdemoのメンバーであることを解決する 必要がある時はいつも、winbindはDomain Usersグループのdemoメンバーについて ドメインコントローラーに問い合わせる。定義によって、UNIX/Linuxグループ demoのメンバーであるように見せかけることが出来る、ユーザー オブジェクトのみを含むことが出来る。

ネストされたグループを有効にするために、winbinddはNSS winbind と一緒に使わなければならない。ローカルグループの作成と管理はWindowsのドメイン ユーザーマネージャかそれのSambaでの相当品、net rpc group ユーティリティ経由が最適である。ローカルグループdemo の作成は以下のように行う:

	root#  net rpc group add demo -L -Uroot%not24get
	

ここで、-Lスイッチはローカルグループ作成を意味する。適切なユーザーかルート権限で 正しいホストにアクセスするために、-Sと-Uスイッチの追加が必要かもしれない。 グループメンバーの追加と削除はnet rpc groupコマンドの addmemdelmemサブコマンド経由で 行える。たとえば、ローカルグループdemoDOM\Domain Usersを追加するのは以下のように行う:

	net rpc group addmem demo "DOM\Domain Users"
	

これら2つのステップを完了し、getent group demoを実行すると、 グループdemoのメンバーとしてグローバルな Domain Usersグループのメンバーとしてdemoを表示する。 これはまた、任意のローカルまたはドメインユーザーでも動作する。ドメインDOMが 他のドメインを信頼している場合、信頼されたドメインに、 demoのメンバーとしてグローバルユーザーとグループを追加すること も可能である。demoグループに追加されたグループのメンバーで ある他のドメインからのユーザーはローカルドメインユーザーが持つのと同じアクセス許可を 持つことになる。

管理に関する重要な情報

管理者権限は以下の二つの用途に対して必要である:

  1. Samba-3のドメインコントローラー、ドメインメンバーサーバー及びクライアントのため。

  2. Windowsのドメインメンバーワークステーション管理のため。

Samba 3.0.10までのバージョンは、Windowsドメインメンバークライアントマシンから システム管理作業のために必要である権利と特権を割り当てる機能は提供しない。その ため、ユーザーの追加、削除とユーザーとグループ情報の変更と、ワークステーションの ドメインメンバーシップ管理のような管理作業はroot以外のどのようなアカウントでも 扱える。

Samba-3.0.11から、管理作業を非root(すなわち、Microsoft Windows Administratorと 同等以外のアカウント)に委譲できる新しい特権管理インタフェースが含まれるように なった(ユーザーの権限と権利を参照)。

Windowsドメインメンバーワークステーション上の管理作業はDomain Admins グループのメンバーの誰かによって行える。このグループは任意の適切なUNIXグループに マップできる。

3.0.11より前のバージョンのみに適用

ユーザーの追加削除のようなUNIX/Linux上の管理作業はrootと 同等の権限が必要である。Samba のドメインに対するWindowsクライアントの追加は、 Windows クライアントに対するユーザーアカウントの追加が含まれる。

多くのUNIX管理者がSamba Teamに対してrootの権限を持たなくても Windowsクライアントの追加、ユーザーの追加、変更、削除ができるようにしてほしいという 要望を寄せ続けている。このような要望はUNIXシステムの基本的なセキュリティの観念と 接触するものある。

rootレベルの権限を与えずにUNIX/Linuxシステムに対してアクセス する安全な方法はない。root権限は、ドメインに rootユーザーでログインするか、ある特定のユーザーを、 /etc/passwdデータベースの中にUID=0とすることで可能となる。 それらの ユーザーは、NT4 のドメインユーザーマネージャやドメインサーバーマネージャ などのツールを使用してユーザーやグループに加えドメインメンバーサーバーやクライアント アカウントの管理ができる。また、このレベルの権限が、共有レベルのACL管理には 必要である。

既定値のユーザー、グループと相対識別子

インストール直後、Windows NT4/200x/XPは特定のユーザー、グループ及び別名のエントリ が事前に設定される。それらはよく知られている相対識別子(RID)を持つ。これらは 運用の継続的な整合性のために維持しなければならない。Sambaは必須のドメイン グループを持たなければならず、それらのグループは適切なRID値を必要とするSamba-3 がtdbsamを使用するよう設定されていると、必須のドメイン グループは自動的に作成される。その既定値のNTグループを作成(準備)するのはLDAP 管理者の責任である。

必須のドメイングループには良く知られているRIDを割り当てなければならない。既定値の ユーザー、グループ、別名とRIDは よく知られているユーザーのRID既定値を参照のこと。

Note

必須のドメイングループ作成と、それに既定値のRIDを割り当てるのは管理者の責任である。

他にも必要なドメイングループを作成することは問題ありませんが、必須のドメイン グループ(良く知られているもの)が作成済みで、既定値のRIDが割り当てられている ことを確認すること。作成する他のグループには任意のRIDを割り当てることができる。

各ドメイングループをUNIXシステムグループにマッピングすること。それが、これらの グループをNTドメイングループとして使用できる唯一の方法である。

Table 12.1. よく知られているユーザーのRID既定値

よく知られているエントリRIDタイプ必須
Domain Administrator500UserNo
Domain Guest501UserNo
Domain KRBTGT502UserNo
Domain Admins512GroupYes
Domain Users513GroupYes
Domain Guests514GroupYes
Domain Computers515GroupNo
Domain Controllers516GroupNo
Domain Certificate Admins517GroupNo
Domain Schema Admins518GroupNo
Domain Enterprise Admins519GroupNo
Domain Policy Admins520GroupNo
Builtin Admins544AliasNo
Builtin users545AliasNo
Builtin Guests546AliasNo
Builtin Power Users547AliasNo
Builtin Account Operators548AliasNo
Builtin System Operators549AliasNo
Builtin Print Operators550AliasNo
Builtin Backup Operators551AliasNo
Builtin Replicator552AliasNo
Builtin RAS Servers553AliasNo


設定例

net groupmap listを実行することでマッピングデータ ベース中の種々のグループを表示出来る。以下が例である:

root#  net groupmap list
Domain Admins (S-1-5-21-2547222302-1596225915-2414751004-512) -> domadmin
Domain Users (S-1-5-21-2547222302-1596225915-2414751004-513) -> domuser
Domain Guests (S-1-5-21-2547222302-1596225915-2414751004-514) -> domguest

net groupmapの完全な詳細は、net(8)のマニュアルを参照のこと。

設定スクリプト

誰もがツールを必要とする。自分のツールを作ることが好きな人もいれば、既成のツール (汎用に誰かが作成したもの)を好む人もいる。

smb.confにグループを追加するスクリプト例

Sambaのグループインタフェースで使用するグループ名を作成するスクリプトは smbgrpadd.shで提供されている。 このスクリプトは一時的なエントリを/etc/group ファイルに追加し、指定された名前に改名する。これは、いくつかの バージョンのgroupaddツールに存在する、OS管理ツールの 制限を避ける方法の例である。

Example 12.1. smbgrpadd.sh

#!/bin/bash

# 通常のgroupaddツールを使ってのグループ追加。
groupadd smbtmpgrp00

thegid=`cat /etc/group | grep ^smbtmpgrp00 | cut -d ":" -f3`

# 次にMicrosoft Windowsネットワーク用に使いたい名前に変更。
cp /etc/group /etc/group.bak
cat /etc/group.bak | sed "s/^smbtmpgrp00/$1/g" > /etc/group
rm /etc/group.bak

# 通常のようにGIDを返す。
echo $thegid
exit 0


グループ追加スクリプトのためのsmb.confエントリの設定 中に示している上記のスクリプトのためのsmb.confエントリは、どのように動くかを デモする。

Example 12.2. グループ追加スクリプトのためのsmb.confエントリの設定

[global]
add group script = /path_to_tool/smbgrpadd.sh "%g"


グループマッピング設定のためのスクリプト

上記の例では、ntadminと呼ばれるUNIX/Linuxグループを作成した。 このスクリプトで、Orks, ElvesGnomesという追加のグループも作成することにする。 後でマッピングデータベースを再作成する必要がある場合に備え、このシェルスクリプト を保存することを推奨する。便宜上、initGroups.shという ファイル名で保存する。このスクリプトは intGroups.shで提供されている。

Example 12.3. Script to Set Group Mapping

#!/bin/bash

net groupmap add ntgroup="Domain Admins" unixgroup=ntadmin rid=512 type=d
net groupmap add ntgroup="Domain Users" unixgroup=users rid=513 type=d
net groupmap add ntgroup="Domain Guests" unixgroup=nobody rid=514 type=d

groupadd Orks
groupadd Elves
groupadd Gnomes

net groupmap add ntgroup="Orks"   unixgroup=Orks   type=d
net groupmap add ntgroup="Elves"  unixgroup=Elves  type=d
net groupmap add ntgroup="Gnomes" unixgroup=Gnomes type=d


もちろん、必要に合わせて管理者がこれを編集することを想定している。 net groupmapツールの使用方法の詳細についてはマニュアル ページを参照のこと。

Note

Sambaのバージョン3.0.23未満では、 Domain Admins, Domain UsersDomain Guests Windowsグループに対する既定値のグループマッピングを自動的に生成する。しかし、 UNIX GIDへのマップは行わない。これは管理者の混乱と障害を引き起こす。Samba-3.0.23 以降はこの異常は修正された。そのため、Windowsグループは、手動かつ明示的にSamba 管理者によって有効なUNIX GIDへのマップの作成とマッピングを行わなければならない。

よくあるエラー

この時点で、油断していると管理者はいろいろな細かいことにびっくりされられることになる。 現実問題として、自動の制御スクリプトの全ステップを本番環境に移す前には、注意深く手動で テストしなければならない。

グループの追加が失敗する

これはSambaインタフェーススクリプトがsmb.confファイル中の add group scriptとして直接 groupadd呼んだ時によくある問題である。

もっともよくある失敗の原因は、名前に大文字かつまたはスペースを含む Microsoft Windows グループアカウントを追加しようとしたということである。

これには 3 つの回避策がある。一つ目は、UNIX/Linuxのgroupadd システムツールの制約に沿うグループ名のみを使用することである。二つ目は、 この章で先に言及したスクリプトを使用することである。三つ目は、 Microsoft Windowsグループ名に代わるUNIX/Linuxグループアカウントを手動で作成し、 上で説明した手順でそのグループをMicrosoft Windows グループにマッピングする という方法である。

ワークステーションのPower UsersグループへのDomain Usersの追加

domain usersをPower Usersグループに追加するにはどうすればいいですか?

Power Usersグループは各Windows 200x/XP Professionalワークステーションの ローカルグループである。Domain Usersグループは自動でPower Usersグループに 追加することはできない。ローカルマシンにadministrator としてローカルワークステーションにログオンすることで、各ワークステーション でこの作業を行わなければならず、その後以下の手続きを行う:

  1. Click スタート -> コントロールパネル -> ユーザーとパスワードをクリック。

  2. 詳細タブをクリック。

  3. 詳細ボタンをクリック。

  4. グループをクリック。

  5. Power Usersをダブルクリック。この作業後、ローカル マシンのPower Usersグループにユーザーとグループを 追加するパネルが起動する。

  6. 追加ボタンをクリック。

  7. Domain Usersグループに追加するドメインを選択。

  8. Domain Usersグループをダブルクリック。

  9. OKボタンをクリック。この作業中にログオン ボックスが表示されたならば、 接続するために DOMAIN\UserNameを入力することを忘れないこと。 すなわち、ドメインMIDEARTHとユーザー rootMIDEARTH\rootとして入力する。

Chapter 13. リモートとローカル管理:Netコマンド

John H. Terpstra

Samba Team

Volker Lendecke

Guenther Deschner

May 9, 2005

netコマンドはSamba-3における新しい機能の1つで、共通作業のために、 多くの必要なリモート管理操作用の便利なツールを提供する試みである。net は自由度が高いデザインで、スクリプト制御アプリケーションのためと同様にコマンド行操作 でも使うように出来ている。

当初は同じ名前のMicrosoft Windows コマンドの模倣を狙って作られたが、net は、Sambaネットワーク管理者の道具箱の基本的な部分になる、非常に強力なツールに変貌した。 Samba Teamは、smbgroupeditrpcclientのような ツールも提供していて、それらは本当に役に立つ能力がnetコマンドに集約 された。smbgroupeditコマンドは、いくつかの機能のみが rpcclientに集約された間、netコマンドに完全に移植された。 それらのユーティリティや機能に対する古いリファレンスを見つけた場合、それ以外を探す前に、 netコマンドを見るべきである。

Samba-3管理者は、そうすることが、自ら招いた痛み、苦しみと自暴自棄を科すことをほとんど 確実に引き起こすので、この章を取り繕うことができない。

概要

Samba-3サーバーのインストールに伴う作業は、スタンドアロンかドメインメンバーの どちらも、さらにドメインコントローラー(PDCまたはBDC)は管理者権限の作成を必要と するところから始まる。もちろん、ユーザーとグループアカウントの作成は、スタンド アロンサーバーとPDC両者において必須である。BDCまたはドメインメンバーサーバー(DMS) においては、ドメインユーザーとグループアカウントは中央のドメイン認証バック エンドから得られる。

インストールされているサーバーのタイプに関係なく、ローカルUNIXグループはWindowsの ネットワークにおけるドメイングローバルグループアカウントにマップされねばならない。 なぜだろうか?それは、Sambaは常時、伝統的なUNIXのUIDとGID制御によってホスト サーバーのリソースのアクセスを制限するからである。これは、ドメイングローバル グループのメンバーであるドメインユーザーは、Sambaがホスティングしているサーバーの ローカルなUIDとGIDをベースとしたアクセス権が与えられるようにするために、 ローカルグループはドメイングローバルグループにマップされなければならない。 このようなマッピングはnetコマンドを使うことで実装される。

メンバー(PDC、BDCあるいはDMS)として動作しているSamba-3サーバーがホスティングしている UNIXシステムは、ドメイン認証データベース(かあるいはディレクトリ)中にマシン信頼 アカウントを持たねばならない。そのようなセキュリティ(あるいは信頼)アカウントの 作成も、netコマンドを使うことよって扱える。

netコマンドを使うことで、ドメイン間信頼関係をも確立でき、 また、ユーザー管理、グループ管理、共有とプリンター管理、ファイルとプリンターの マイグレーション、SIDの管理などのような、有り余るほどの典型的な管理作業も できる。

全体の構成は今明確にすべきである:netはSamba-3の動作において 重要な役割を演じる。その役割は継続して開発されている。この章に含まれているもの は、その重要性の証拠であり、それは、完全にオンラインUNIXマニュアル中でその 使用をカバーすることが賢明であるとは、もはや考えられない点において、複雑に成長 してきた。

管理者の作業と手段

netの基本的な動作はここに文書化されている。この文書は完璧 ではなく、不完全である。WindowsサーバーからSambaサーバーへの移行について最も着目 しているので、分散コンピューティング環境のリモートプロシジャーコール(DCE RPC) モードの操作について強調している。Active Directoryドメインのメンバーであるサーバーに 対して使用されるとき、ADSモード操作を使うことは望ましい(そして、それはしばしば 必要である)。netは両方ともサポートするが、すべての操作に 対してではない。モードが指定されない多くの操作では、netは 自動的にads, rpcrapモードにフォールバックする。このユーティリティの 能力についてのより包括的な概要はマニュアルページを参照のこと。

UNIXとWindowsのグループ管理

初めに、この章の主要な注目点は、Sambaによってサポートされている net rpcファミリの動作の使用方法である。それらの大半は、 Active Directoryに接続したときに使われるnet adsモードでも サポートされる。net rap動作モードもそれらの操作のいくつかで サポートされる。RAPプロトコルはIBM OS/2といくつかの初期のSMBサーバーによって 使われる。

Sambaのnetツールはコマンドラインで完結するための、すべての 共通な管理作業が出来る十分な能力を実装している。このセクションでは、必須の ユーザーとグループ管理機能のそれぞれについて説明している。

Samba-3は2種類のグループを認識する。それは、ドメイングループローカルグループである。ドメイングループは(メンバーとして) ドメインユーザーアカウントのみを含むことは出来る。ローカルグループはローカル グループ、ドメインユーザーとメンバーとしてのドメイングループをを含むことが出来る。

ローカルグループの目的は、そのグループアカウントに対して、通常のUNIX/Linux グループのようにファイルのアクセス権を 設定することであり、また、Windows ファイルサーバーを再配置しても継続的である。

グループアカウントの追加、改名、あるいは削除

SambaはWindowsクライアントにファイルと印刷サービスを提供する。Windows環境に 対して有効にしたファイルシステムリソースは、必要に応じてWindowsネットワーク 環境と互換の方式で提供しなければならない。UNIXグループはUNIX OSとそのファイル システム内で、操作の必要で提供するために要求に応じて作成および削除される。

Windows環境に対して有効にするために、Sambaは、Windows(あるいはドメイン)グループ と呼ばれる論理的なエントリに、UNIXグループをマップされることが出来る機能を持つ。 Sambaはローカルとグローバルと言う2つのタイプのWindowsグループをサポートする。 グローバルグループはメンバーとグローバルユーザーを含むことが出来る。このメンバーシップは 通常のUNIX流儀に影響されるが、UNIXユーザーをUNIXグループに追加する。Windowsユーザー アカウントはユーザーのSambaSAMAccount(論理エントリ)とUNIXユーザーアカウントとの マッピングから成り立つ。そのため、UNIXユーザーはWindowsユーザーにマップされ(すなわち、 Windowsユーザーアカウントとパスワードが与えられる)、そのユーザーに属するUNIX グループはWindowsグループアカウントにマップされる。この結果は、Windowsアカウント 環境においてそのユーザーが、UNIXグループメンバーシップであるという理由で、Windows グループアカウントのメンバーでもあるということである。

Windowsグループ管理を扱う以下の項では、Windowsグループアカウントとそのメンバーの 間の関係について、それぞれのWindowsグループアカウントの関係をデモする。これは、 論理マッピングが作成されるとすぐに、どのように自動的にUNIXグループメンバーをWindows グループメンバーシップに渡すかを表示する。

新しいグループの追加又は作成

Windowsグループアカウントを追加する前に、現在有効なグループは以下のようにして表示できる:

root#  net rpc group list -Uroot%not24get
Password:
Domain Admins
Domain Users
Domain Guests
Print Operators
Backup Operators
Replicator
Domain Computers
Engineers

SupportEngrsというWindowsグループアカウントは、以下のコマンドを 実行することで追加できる:

root#  net rpc group add "SupportEngrs" -Uroot%not24get

以下のコマンドを実行することで、新しいグループアカウント追加の結果が有効になって いることが検証できる:

root#  net rpc group list -Uroot%not24get
Password:
Domain Admins
Domain Users
Domain Guests
Print Operators
Backup Operators
Replicator
Domain Computers
Engineers
SupportEngrs

以下はPOSIX(UNIX/Linuxシステムアカウント)グループが、 add group script = /opt/IDEALX/sbin/smbldap-groupadd -p "%g" インタフェーススクリプトを呼び出すことによって作成されたことを表示する:

root#  getent group
...
Domain Admins:x:512:root
Domain Users:x:513:jht,lct,ajt,met
Domain Guests:x:514:
Print Operators:x:550:
Backup Operators:x:551:
Replicator:x:552:
Domain Computers:x:553:
Engineers:x:1002:jht
SupportEngrs:x:1003:

以下は、グループアカウントを追加するnetの使用で、Windows グループアカウントのために作られたPOSIXグループの即時的なマッピング中での結果を示す:

root#  net groupmap list
Domain Admins (S-1-5-21-72630-4128915-11681869-512) -> Domain Admins
Domain Users (S-1-5-21-72630-4128915-11681869-513) -> Domain Users
Domain Guests (S-1-5-21-72630-4128915-11681869-514) -> Domain Guests
Print Operators (S-1-5-21-72630-4128915-11681869-550) -> Print Operators
Backup Operators (S-1-5-21-72630-4128915-11681869-551) -> Backup Operators
Replicator (S-1-5-21-72630-4128915-11681869-552) -> Replicator
Domain Computers (S-1-5-21-72630-4128915-11681869-553) -> Domain Computers
Engineers (S-1-5-21-72630-4128915-11681869-3005) -> Engineers
SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs

WindowsグループからUNIXグループへのマッピング

Windowsグループは、SambaサーバーをホスティングしているOSに適した方法での首尾一貫 した方法で主張できるファイルシステムのアクセス制御が出来るように、UNIXシステム (POSIX)グループにマップされる必要がある。

SambaサーバーをホスティングしているUNIX/Linuxサーバーのファイルシステムで、すべての ファイルシステム(ファイルとディレクトリ)アクセス制御はUID/GID識別の組を使って 実装される。SambaはUNIXファイルシステムの仕組みに優先したり、置き換えることは しない。これは、ファイルシステムにアクセスするすべてのWindowsネットワーク操作は、 Windowsユーザーから特定のUNIX/Linuxグループアカウントにマップするメカニズムを 提供する。ユーザーアカウントはローカルに知られているUIDにもマップする必要がある。 netコマンドはここでは任意のRPC機能は呼び出さないが、passdbに 直接アクセスすることに注意。

SambaはDomain Admins, Domain UsersDomain Guestsグローバルグループの既定値のマッピングに 依存する。追加のグループはサンプルで与えられた中でのように追加できる。存在する UNIXグループアカウントをWindowsグループにマップすることが必要なときがある。 この操作は実際Windowsグループアカウントをマップ生成の結果として作成する。

addmodifydelete を含む操作が許可される。それぞれの操作の例はここで示される。

Note

Samba-3.0.23で始まるWindowsドメイングループは明示的に作成する必要がある。既定値 では、すべてのUNIXグループはWindowsローカルグループとしてWindowsネットワーク に対して公開される。

存在するUNIXグループは以下の例のようにして存在するWindowsグループにマップされる:

root#  net groupmap modify ntgroup="Domain Users" unixgroup=users

存在するUNIXグループは以下の例のようにして新しいWindowsグループにマップされる:

root#  net groupmap add ntgroup="EliteEngrs" unixgroup=Engineers type=d

サポートされているマッピングタイプは'd'(ドメイングローバル)と'l'(ドメインローカル) である。Windowsグループは削除でき、新しいWindowsグループは以下のコマンドでUNIX グループにマップ出来る:

root#  net groupmap delete ntgroup=Engineers
root#  net groupmap add ntgroup=EngineDrivers unixgroup=Engineers type=d

削除と追加操作はWindowsグループかドメイングループとして知られている論理エントリ のみに影響する。操作は、UNIXシステムグループの削除も作成もしないので、UNIX システムグループには影響しない。UNIXグループからWindowsグループへのマッピングは、 ドメインメンバークライアント上(ワークステーションとサーバー)のファイルとフォルダーが、 ドメインユーザーとグループに対してドメイン全体のアクセス制御を得ることが出来る ようにするために、WindowsグループとしてWindowsグループを有効にさせる。

domain(グローバル)localという 二種類のWindowsグループか作成できる。前者の例では、作成されたWindowsグループは domainかグローバルタイプである。以下のコマンドでは、 localタイプのWindowsグループを作成する。

root#  net groupmap add ntgroup=Pixies unixgroup=pixies type=l

サポートされているマッピングタイプは'd' (ドメイングローバル)と 'l' (ドメイン ローカル)で、Samba中でのドメインローカルグループは個別のSambaサーバーに対する ローカルなものとして扱われる。ローカルグループは、複数ネストされたグループの サポートを有効にするためにSambaで使うことができる。

グループアカウントの削除

グループアカウントは以下のコマンドで削除できる:

root#  net rpc group delete SupportEngineers -Uroot%not24get

削除の検証は有効である。同じコマンドは以下で示されるように実行できる。

グループアカウントの改名

Note

このコマンドはマニュアルページには記述がない。ソースコード上では実装されているが、 現時点では動作しない。ソースコード上から得られた文書例は、どのようにそれが 動くかを示す。これがいつ修正されるかを、今後のリリースにおけるリリースノート で確認すること(訳注:3.4.0でもマニュアルに記載はない)。

時々グループアカウントの改名が必要なときがある。良い管理者は、この単純な要求が 無視されるならば、何人かのマネージャの要求がどのくらい痛ましくなるかを知っている。 以下のコマンドは、どのようにWindowsグループSupportEngrsCustomerSupportに改名できるかを示す:

root#  net rpc group rename SupportEngrs \
    CustomerSupport -Uroot%not24get

グループメンバーシップの操作

3つの操作をグループメンバーシップに関して行うことが出来る。それは、(1)Windows ユーザーをWindowsグループに追加する、(2)WindowsグループからWindowsユーザーを削除する、 (3)Windowsグループに属するWindowsユーザーを表示する である。

混乱を防ぐため、何らかの変更を行う前に、グループメンバーシップを確認することは 意味がある。getent groupはUNIX/Linuxのグループメンバーシップを 表示する。UNIX/Linuxグループメンバーはnet groupmapコマンド (“グループのマッピング: Microsoft Windows と UNIX”を参照)で、マップされたWindowsグループのメンバー としても見ることができる。以下のUNIX/Linuxメンバーシップは、ajt というユーザーがEngineersというUNIX/Linuxのグループのメンバー であることを示している。

root#  getent group
...
Domain Admins:x:512:root
Domain Users:x:513:jht,lct,ajt,met,vlendecke
Domain Guests:x:514:
Print Operators:x:550:
Backup Operators:x:551:
Replicator:x:552:
Domain Computers:x:553:
Engineers:x:1000:jht,ajt

WindowsグループにマップされたUNIX/Linuxのグループは以下のようになる:

root#  net groupmap list
Domain Admins (S-1-5-21-72630-412605-116429-512) -> Domain Admins
Domain Users (S-1-5-21-72630-412605-116429-513) -> Domain Users
Domain Guests (S-1-5-21-72630-412605-116429-514) -> Domain Guests
Print Operators (S-1-5-21-72630-412605-116429-550) -> Print Operators
Backup Operators (S-1-5-21-72630-412605-116429-551) -> Backup Operators
Replicator (S-1-5-21-72630-412605-116429-552) -> Replicator
Domain Computers (S-1-5-21-72630-412605-116429-553) -> Domain Computers
Engineers (S-1-5-21-72630-412605-116429-3001) -> Engineers

与えられたajtというユーザーは、すでにUNIX/Linuxグループの メンバーで、グループマッピング経由、Windowsグループのメンバーで、このアカウントを 再度追加する試みは失敗する。これのデモは以下の通り:

root#  net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP

これは、UNIX/LinuxグループとWindowsグループの間のグループマッピングは有効でかつ 透過的であることを示している。

ユーザーajtを、net rpc groupユーティリティ を使って追加することを許可するために、このアカウントは最初に削除されねばならない。 削除とその確認は以下のようになる:

root#  net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24get
root#  getent group Engineers
Engineers:x:1000:jht
root#  net rpc group members Engineers -Uroot%not24get
MIDEARTH\jht

この例2つの中で、UNIX/Linuxシステムレベルで、グループはもはやajt をメンバーとしてはいない。上記は又Windowsグループメンバーシップの場合も示している。

net rpc groupユーティリティを使ってアカウントは再度追加される:

root#  net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
root#  getent group Engineers
Engineers:x:1000:jht,ajt
root#  net rpc group members Engineers -Uroot%not24get
MIDEARTH\jht
MIDEARTH\ajt

この例では、WindowsのDomain Usersアカウントのメンバーは net rpc groupユーティリティを使って検証される。この UNIX/Linuxグループの内容は4つ前のパラグラフで示されていることに注意。 Windows(ドメイン)グループメンバーシップは以下のようになる:

root#  net rpc group members "Domain Users" -Uroot%not24get
MIDEARTH\jht
MIDEARTH\lct
MIDEARTH\ajt
MIDEARTH\met
MIDEARTH\vlendecke

この特別な例は、Windowsグループ名が、大文字小文字を区別しない流儀で (Microsoft Windowsと同じ)Sambaによって扱われることを示す:

root#  net rpc group members "DomAiN USerS" -Uroot%not24get
MIDEARTH\jht
MIDEARTH\lct
MIDEARTH\ajt
MIDEARTH\met
MIDEARTH\vlendecke

Note

単純にDomain Usersの代わりに MIDEARTH\Domain Usersという形でグループ名を指定しても 失敗する。net rpc group の既定値の動作はローカルマシンへコマンドの動作を 行うからである。Windowsグループはマシンに対してローカルなように扱われる。 もしも他のマシンに対して問い合わせが必要ならば、その名前は、 netコマンドの-S servername パラメーターを使って指定する。

ネストされたグループのサポート

ドメインユーザーとドメイングループのメンバーである(含む)ローカルグループを作成する ことはWindows(と現在はSambaも)で可能である。demoという ローカルグループは以下のようにして作成できる:

root#  net rpc group add demo -L -S MORDON -Uroot%not24get

ここで、-L スイッチはローカルグループ作成を意味する。特定のサーバーに対しての 動作を行う場合は、 -S 引数を使う。-U引数はマシン上で適切な権限と権利を持つ ユーザーを指定するのに使う。

グループメンバーの追加と削除はnet rpc groupコマンドの addmemdelmemサブコマンドを使う ことで行える。たとえば、ローカルグループdemoに対して DOM\Domain Usersを追加するには以下のように行う:

root#  net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get

以下のようにして、ネストされたグループのメンバーを表示することが出来る:

root#  net rpc group members demo -Uroot%not24get
DOM\Domain Users
DOM\Engineers
DOM\jamesf
DOM\jht

ネストされたグループメンバーは以下のようにして削除出来る:

root#  net rpc group delmem demo "DOM\jht" -Uroot%not24get

Sambaサーバーからのワークステーション上のネストされたグループの管理

Windowsネットワーク管理者はしばしばSambaメーリングリストに、個々のワーク ステーション上ですべての人に管理者権限を許可することが可能かと言うことを 質問してくる。これは、もちろんとても悪い習慣ではあるが、一般的にユーザーの不満を 防ぐために行われる。個々では、どのようにSamba PDCまたはBDCからリモートでそれが 出来るかを示す:

root#  net rpc group addmem "Administrators" "Domain Users" \
    -S WINPC032 -Uadministrator%secret

これはスクリプト化出来、そのためにWindowsワークステーションからドメインに ログオンするユーザーとして実行できる。どのようにそれが行われるかの簡単な例を 以下に示す。

Procedure 13.1. ワークステーションの Power Usersグループへの自動的なユーザーの追加

Example 13.1. ワークステーションのPower UsersグループにDomain Users を自動で追加するスクリプト

#!/bin/bash

/usr/bin/net rpc group addmem "Power Users" "DOMAIN_NAME\$1" \
                   -UAdministrator%secret -S $2

exit 0

Example 13.2. Magic Netlogon共有

[netlogon]
comment = Netlogon Share
path = /var/lib/samba/netlogon
root preexec = /etc/samba/scripts/autopoweruser.sh %U %m
read only = Yes
guest ok = Yes

  1. “ワークステーションのPower UsersグループにDomain Users を自動で追加するスクリプト”で示されているスクリプトを 作成し、autopoweruser.shという名前で ディレクトリ/etc/samba/scripts中に配置する。

  2. ログオンプロセスの一部として実行できるようにスクリプトにパーを設定する:

    root#  chown root:root /etc/samba/autopoweruser.sh
    root#  chmod 755 /etc/samba/autopoweruser.sh
    

  3. Netlogonのsmb.confファイルでの例 で示されるようなNETLOGONセクションが含むパラメーター のようにsmb.confファイルを変更する。

  4. すべてのWindowsワークステーション管理者アカウントが、 Netlogonのsmb.confファイルでの例 にあるようなスクリプト中で使われるのと同じパスワードを持つようにする。

このスクリプトはユーザーがネットワークにログオンする時には毎回実行される。 そのため、すべてのユーザーはローカルWindowsワークステーションの管理権限を 持つ。これはもちろんグループを使って割り当てることが出来、その場合、 この手続きの使用のためには微少な修正ですむ。この方法の使用のための修正 点の肝心なところは、すべてのユーザーがワークステーション上で適切な権限を 持つことを保証することである。

UNIXとWindowsのユーザー管理

すべてのWindowsネットワークユーザーアカウントはUNIX/Linuxユーザーアカウントに変換 されねばならない。実際には、UNIX/LinuxのSambaサーバーは、アカウント情報の内のUID のみを必要とする。UIDは、システム(POSIX)アカウントか、Windowsユーザーアカウントに よって使われるために割り当てられる目的で予約されるUID番号の事前割当範囲(レンジ) から取得される。この場合、UID事前割当範囲(訳注:pool)の場合、特定のユーザーに 対するUIDはwinbinddによって割り当てられる。

ここは、異なった名前を持つUNIXアカウントにWindowsユーザーアカウントをマッピング する重要な方法であusername mapインタフェース機能を 議論するのにふさわしい場所ではない。この機能についての詳細はsmb.confファイルの マニュアルページを参照のこと。

ユーザーアカウントの追加

net経由(詳細はマニュアルページ)でのユーザーの追加は以下の通り:

net [<method>] user ADD <name> [-c container] [-F user flags] \
    [misc. options] [targets]

ユーザーアカウントのパスワードは以下の方法で設定できる:

net rpc password <username> [<password>] -Uadmin_username%admin_pass

以下ではサーバーFRODOにアカウントを追加する例を示す:

root#  net rpc user add jacko -S FRODO -Uroot%not24get
Added user jacko

アカウントのパスワードは以下の方法で追加できる(すべて同じ操作を示す):

root#  net rpc password jacko f4sth0rse -S FRODO -Uroot%not24get
root#  net rpc user password jacko f4sth0rse \
    -S FRODO -Uroot%not24get

ユーザーアカウントの削除

ユーザーアカウントの削除方法は以下の通り:

net [<method>] user DELETE <name> [misc. options] [targets]

以下ではユーザーアカウントjackoを削除する:

root#  net rpc user delete jacko -Uroot%not24get
Deleted user account

ユーザーアカウントの管理

2の基本的なユーザーアカウント操作が定常的に使われる:パスワード変更とどのグループに ユーザーが所属しているかの問い合わせである。パスワード変更操作は “ユーザーアカウントの追加”の通り。

Windowsグループのメンバーシップの問い合わせ能力は基本的である。以下では、リモート サーバーが、どのグループにユーザーが属しているかを調べることが出来るかを示す:

root#  net rpc user info jacko -S SAURON -Uroot%not24get
net rpc user info jacko -S SAURON -Uroot%not24get
Domain Users
Domain Admins
Engineers
TorridGroup
BOP Shop
Emergency Services

古いユーザー名から新しいユーザー名へのユーザーアカウントの改名も可能である。ただし、この操作はSambaサーバーに対しては動作しないことに注意。しかし、ユーザー名の改名はWindowsサーバーでは可能である。

ユーザーのマッピング

ある条件下で、ユーザーのWindowsにおけるログオン名はSambaサーバー上で持つユーザーの ログインIDと異なることは避けられない。Sambaサーバー上で、Windowsユーザー名を 異なったUNIX/Linuxユーザー名にマップできる特別なファイルを作ることが出来る。 smb.confファイルも、[global]セクションで以下の パラメーターを含むように変更しなければならない。

username map = /etc/samba/smbusers

/etc/samba/smbusersファイルの内容は以下の通り:

parsonsw: "William Parsons"
marygee: geeringm

この例では、WindowsユーザーアカウントWilliam ParsonsはUNIXユーザー parsonswにマップされ、Windowsユーザーアカウント geeringmはUNIXユーザーmarygeeにマップされる。

管理ユーザーの権限と権利

3.0.11より前のすべてのSambaは、Sambaサーバー上で、ユーザー、グループ、共有、プリンター とその他の管理を行うのに、rootアカウントしか使えなかった。 これは、何人かのユーザーには問題を引き起こし、しばしばUNIX/Linuxシステム上で、最も セキュリティに敏感なアカウントの権限を渡す必要があるという弱点の元であった。

Sambaバージョン3.0.11から、ユーザーまたはユーザーが属するグループに対して必要に応じて 管理者権限を委譲する機能が加わった。管理者特権の重要性は“User Rights and Privileges”に 説明がある。ユーザー権限と権利管理に関するnetコマンドの使用例は この章の適切な箇所にある。

Note

ユーザー権限と権利が正しく設定した場合、UNIX UID=0であるrootユーザー (およびその同義語)のためのWindowsネットワークアカウントの必要がなくなる。初期のユーザー 権限と権利は、Domain Adminsグループのメンバーの任意のアカウントに 割り当てることが出来る。権利はグループアカウントと同じように割り当てられる。

既定値では、何らの権利と権限も割り当てられない。これは以下のコマンドを実行する ことで以下のように表示される:

root#  net rpc rights list accounts -U root%not24get
BUILTIN\Print Operators
No privileges assigned

BUILTIN\Account Operators
No privileges assigned

BUILTIN\Backup Operators
No privileges assigned

BUILTIN\Server Operators
No privileges assigned

BUILTIN\Administrators
No privileges assigned

Everyone
No privileges assigned

netコマンドは、以下の方法で現在サポートされている権利と 権限を得るのに使える:

root#  net rpc rights list -U root%not24get
     SeMachineAccountPrivilege  Add machines to domain
      SePrintOperatorPrivilege  Manage printers
           SeAddUsersPrivilege  Add users and groups to the domain
     SeRemoteShutdownPrivilege  Force shutdown from a remote system
       SeDiskOperatorPrivilege  Manage disk shares
             SeBackupPrivilege  Back up files and directories
            SeRestorePrivilege  Restore files and directories
      SeTakeOwnershipPrivilege  Take ownership of files or other objects

Machine account権限は、Windows NT4以降のネットワーククライアントをドメインに 参加させるために必要である。disk operator権限は、ユーザーが所有していない オブジェクトの、共有のACLとファイルとディレクトリのACLを管理するために必要である。

この例では、すべての権利はDomain Adminsグループに割り当てられる。これは、このグループのメンバーが通常全権を有することになっている。この割り当ては以下のようになっている:

root#  net rpc rights grant "MIDEARTH\Domain Admins" \
    SeMachineAccountPrivilege SePrintOperatorPrivilege \
    SeAddUsersPrivilege SeRemoteShutdownPrivilege \
    SeDiskOperatorPrivilege  -U root%not24get
Successfully granted rights.

次に、ドメインユーザーjhtは、日々の管理の必要性のために権限を 割り当てられる:

root#  net rpc rights grant "MIDEARTH\jht" \
    SeMachineAccountPrivilege SePrintOperatorPrivilege \
    SeAddUsersPrivilege SeDiskOperatorPrivilege \
    -U root%not24get
Successfully granted rights.

以下のステップでは今行った変更の確認を行う:

root#  net rpc rights list accounts -U root%not24get
MIDEARTH\jht
SeMachineAccountPrivilege
SePrintOperatorPrivilege
SeAddUsersPrivilege
SeDiskOperatorPrivilege

BUILTIN\Print Operators
No privileges assigned

BUILTIN\Account Operators
No privileges assigned

BUILTIN\Backup Operators
No privileges assigned

BUILTIN\Server Operators
No privileges assigned

BUILTIN\Administrators
No privileges assigned

Everyone
No privileges assigned

MIDEARTH\Domain Admins
SeMachineAccountPrivilege
SePrintOperatorPrivilege
SeAddUsersPrivilege
SeRemoteShutdownPrivilege
SeDiskOperatorPrivilege

信頼関係の管理

基本的な信頼関係には2つのタイプがある:最初のものは、ドメインコントローラーと ドメインメンバーマシン(ネットワーククライアント)間のものであり、2番目のものは、 ドメイン間(ドメイン間信頼関係と呼ばれる)である。ドメインセキュリティに参加する すべてのSambaサーバーは、Windows NT/200x/XPワークステーションがそうであるように、 ドメインメンバーシップ信頼アカウントを必要とする。

マシン信頼アカウント

それ自身の固有の設定を取得するために、netコマンドはsmb.confファイルを見に行く。 そのため、以下のコマンドは、smb.confから、どのドメインに参加するかを知っている。

Sambaサーバーのドメイン信頼アカウントは以下の例のようにして確認できる:

root#  net rpc testjoin
Join to 'MIDEARTH' is OK

ここで、ドメインメンバーシップアカウントがないか、アカウントの認証が無効の場合、 以下の結果が表示される:

net rpc testjoin -S DOLPHIN
Join to domain 'WORLDOCEAN' is not valid

The equivalent command for joining a Samba server to a Windows ADS domain is shown here:

root#  net ads testjoin
Using short domain name -- TAKEAWAY
Joined 'LEMONADE' to realm 'TAKEAWAY.BIZ'

ADSの信頼関係が確立されていない状態か、何らかの理由で無効になっている場合、 以下のエラーメッセージが表示される:

root#  net ads testjoin -UAdministrator%secret
Join to domain is not valid

以下は、コマンドが実行された時にSambaサーバーがターゲットのドメイン中でマシン 信頼アカウントを作成する手順を示す:

root#  net rpc join -S FRODO -Uroot%not24get
Joined domain MIDEARTH.

SambaドメインにSambaサーバーを参加させると、マシンアカウントが作成される。 その例は以下の通り:

root#  pdbedit -Lw merlin\$
merlin$:1009:9B4489D6B90461FD6A3EC3AB96147E16:\
176D8C554E99914BDF3407DEA2231D80:[S          ]:LCT-42891919:

大カッコの中のSは、これがサーバー(PDC/BDC)アカウントであることを意味する。 ドメインの参加は、純粋にワークステーションとして参加するために処理が行われ、 その場合はSはW(ワークステーションアカウントを意味する)に置き換えられる。 これを行うには以下のコマンドを使う:

root#  net rpc join member -S FRODO -Uroot%not24get
Joined domain MIDEARTH.

コマンドラインパラメーターmemberはこれをjoin固有にすること に注意。既定値では、タイプはsmb.confファイルの設定から推測される。特に、PDC又は BDCとしてjoinするためには、コマンドラインパラメーターを [PDC | BDC]とする。例をあげると、

root#  net rpc join bdc -S FRODO -Uroot%not24get
Joined domain MIDEARTH.

となる。これは、smb.confファイル中の設定からドメインへのjoinのタイプを Sambaに理解させるのに最も良い方法である。

Windows ADSにSambaサーバーをjoinさせるコマンドは以下の通り:

root#  net ads join -UAdministrator%not24get
Using short domain name -- GDANSK
Joined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ'

NT4ドメインからマシンを削除するための特定のオプションはない。ドメインから削除 されるドメインメンバーがWindowsマシンの場合、ドメインメンバーシップアカウントは自動的 には削除されない。無効になっているドメインアカウントは、何らかのツールで削除する ことが出来る。もしも必要ならば、マシンアカウントは以下のnet コマンドで削除できる:

root#  net rpc user delete HERRING\$ -Uroot%not24get
Deleted user account.

削除は、マシンアカウントが末尾に$が付いたユーザーアカウントのようになっている ために可能となる。アカウント管理操作はユーザーとマシンアカウントの間で同じ方法で 扱える。

Windows ADS メンバーであるSamba-3サーバーはドメインから、以下のコマンドで離脱できる:

root#  net ads leave

ADSドメインについての詳細な情報は、以下を使ってSamba DMSマシンから得られる:

root#  net ads status

この件に関する情報は非常にたくさんある。詳細はSamba-3 by Example という書籍の第七章を参照してほしい。この本は書籍か、あるいはオンライン上では Samba-3 by Example (訳注:英語版)で入手できる。

ドメイン間の信頼関係

ドメイン間の信頼関係は、あるドメインのユーザーが、他のドメインでアクセス許可と 権利を得ることが出来ることについての主要なメカニズムを構成する。

ドメイン間の信頼歓迎がどうなっているかを調べるには、以下のコマンドを実行する:

root#  net rpc trustdom list -Uroot%not24get
Trusted domains list:

none

Trusting domains list:

none

この時点ではドメイン間の信頼関係はない;以下のステップでこれを作成する。

ローカルドメインで信頼アカウントを作成することが必要である。2番目のドメイン中の ドメインコントローラーはこのアカウントを使って信頼された接続を作成できる。これは、 外部のドメインがローカルドメイン中でアクセスするために信頼されていると言うことを 意味する。このコマンドはローカル信頼アカウントを作成する:

root#  net rpc trustdom add DAMNATION f00db4r -Uroot%not24get

アカウントはpdbeditを使って表示できる:

root#  pdbedit -Lw DAMNATION\$
DAMNATION$:1016:9AC1F121DF897688AAD3B435B51404EE: \
7F845808B91BB9F7FEF44B247D9DC9A6:[I         ]:LCT-428934B1:

信頼アカウントはいつでも大括弧の中にIという値を持っている。

もしも信頼されているドメインへ接続できないと、以下のコマンドは失敗する:

root#  net rpc trustdom list -Uroot%not24get
Trusted domains list:

none

Trusting domains list:

DAMNATION           S-1-5-21-1385457007-882775198-1210191635

The above command executed successfully; a failure is indicated when the following response is obtained:

net rpc trustdom list -Uroot%not24get
Trusted domains list:

DAMNATION           S-1-5-21-1385457007-882775198-1210191635

Trusting domains list:

DAMNATION           domain controller is not responding

信頼アカウントが外部ドメインで作成された場合、Sambaは信頼関係を外部アカウントに 対して(接続して)確立する。プロセスの中で、リモートドメイン上でリソースに対する 1方向の信頼を確立する。このコマンドは信頼関係に参加する目的を達成する:

root#  net rpc trustdom establish DAMNATION
Password: xxxxxxx	== f00db4r
Could not connect to server TRANSGRESSION
Trust to domain DAMNATION established

今確立した双方向の信頼関係の表示は以下のように行える:

root#  net rpc trustdom list -Uroot%not24get
Trusted domains list:

DAMNATION           S-1-5-21-1385457007-882775198-1210191635

Trusting domains list:

DAMNATION           S-1-5-21-1385457007-882775198-1210191635

時々、外部ドメインにアクセするためのローカルユーザーのための能力を取り去る必要が ある。信頼している接続は以下のように取り去ることが出来る:

root#  net rpc trustdom revoke DAMNATION -Uroot%not24get

また別の時には、ローカルドメイン内のリソースにアクセス出来る外部ドメインから、 ユーザーを削除する機能が必要な時がある。以下はこれを行えるようにする:

root#  net rpc trustdom del DAMNATION -Uroot%not24get

セキュリティ識別子(SID)の管理

すべてのWindowsネットワーキング操作で使われる基本的なセキュリティ識別子は Windowsセキュリティ識別子(SID)である。すべてのWindowsネットワークマシン(サーバーと ワークステーション)、ユーザーとグループはそれぞれのSIDで確認される。すべてのデス クトッププロファイルも、ユーザーが存在しているドメインのSIDに固有のユーザーと グループSIDでエンコードされる。

保護のためにマシンやドメインのSIDをファイルに保存することは、本当に重要である。 なぜか?なぜならば、ホスト名中かドメイン(ワークグループ)中の名前の変更点が、 SID内の変更になるかもしれないからである。SIDが手元にある場合、それを回復さ せることは簡単な問題である。別の方法を取ると、ユーザーデスクトッププロファイルを 回復しなければならず、すべてのメンバーメンバーマシンを再結合しなければならないとい う手間暇で苦しむことになる。

最初に、ファイル中にローカルSIDを格納することを忘れないこと。smb.confが保存 されているディレクトリ中に配置しておくのは良い方法である。これを行うのは 以下のように行う:

root#  net getlocalsid > /etc/samba/my-sid

これで、ローカルのマシンSIDが安全に保存できた。PDC/BDC上ではドメインSID でもある。

以下のコマンドは、前者がmy-sidと呼ばれているファイル中に 入れなければならなかったことを明らかにする:

root#  net getlocalsid
SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429

もしも、my-sidファイル中に格納されたSIDをリストアする 必要性がある場合、単純にSID(S-1-5-21で始まる文字列)を 以下のコマンドラインのように行う:

root#  net setlocalsid S-1-5-21-1385457007-882775198-1210191635

マシンSIDのリストアは単純な操作であるが、バックアップコピーがないととて も大変である。

以下の操作はマシンがPDCまたはBDCに設定されている時のみ有用である。DMSとワーク ステーションクライアントは名前空間の競合の可能性を防ぐために固有のSIDを持つ べきである。以下は、BDCのSIDをPDCに同期する例である(これは既定値の NT4 ドメインの動作である):

root#  net rpc getsid -S FRODO -Uroot%not24get
Storing SID S-1-5-21-726309263-4128913605-1168186429 \
    for Domain MIDEARTH in secrets.tdb

通常、ターゲットのサーバー(-S FRODO)や管理者アカウントのパスワード(-Uroot%not24get) を指定する必要はない。

共有管理

共有管理は、すべてのファイルサービス操作にとって主要なものである。通常の共有 操作は以下を含む:

  • 共有の作成/変更/削除

  • 共有へのACLの設定/変更

  • サーバー間での共有の移動

  • 共有内容のパーミッションの変更

上記のおのおのは、それらが必要としている範囲において、 netコマンドを使ってここで分けられる。このコマンドの 範囲外の操作はこの文書のどこかで触れられている。

共有の作成、編集と削除

共有はnet rpc shareの能力を使って追加できる。ターゲットマシン はローカルまたは-Sオプションを指定することでリモートでもよい。このツールを使った 共有の追加と削除は、適切なインタフェーススクリプトが有効であることに依存する ことに注意しなければならない。Sambaのsmbdが使うインタフェース スクリプトは、add share commanddelete share commandと smbconfoption name="change share command"/>と呼ばれる。スクリプトの例一式は、 Sambaのソース内のディレクトリ~samba/examples/scripts で提供されている。

以下のステップは、netユーティリティの共有管理能力を使う例を 表示する。最初のステップで、Bulgeという共有が追加される。 ファイルシステム内の共有ポイントは/dataというディレクトリ である。この共有を追加するためのコマンドの実行例は以下の通り:

root#  net rpc share add Bulge=/data -S MERLIN -Uroot%not24get

検証は重要なプロセスで、何もオプションを付けないでnet rpc share を実行することで、以下のように有効な共有のリストを得ることが出来る:

root#  net rpc share -S MERLIN -Uroot%not24get
profdata
archive
Bulge   <--- This one was added
print$
netlogon
profiles
IPC$
kyocera
ADMIN$

コマンドラインツールを使って共有を削除することもしばしば好ましい。以下の手順では、 以前に作成した共有を削除する:

root#  net rpc share delete Bulge -S MERLIN -Uroot%not24get

共有が削除された結果の簡単な検証は以下の通り:

root#  net rpc share -S MERLIN -Uroot%not24get
profdata
archive
print$
netlogon
profiles
IPC$
ADMIN$
kyocera

共有のACLの作成と変更

現時点で、netツールはSamba共有上のACLを管理するのには使えない。 Microsoft Windowsの用語で、これは、共有のアクセス許可(訳注:Share Permissions) と呼ばれる。

SRVTOOLの NT4ドメインサーバーマネージャかコンピュータの管理のMMCスナップインの どちらかを使うことでSamba共有上のACLを設定することが可能である。それらは ここでは触れないので、“ファイル、ディレクトリと共有のアクセス制御”を参照のこと。

共有、ディレクトリとファイルのマイグレーション(移行)

共有とファイルはユーザー、マシンとグループアカウントと同じように移行できる。移行 プロセスを通じて、セキュリティの設定と同様にアクセス制御(ACL)の設定を保持する ことは可能である。net rpc vampire昨日は、Windows NT4(か それ以降)からSambaサーバーにアカウントを移行する時に使われる。このプロセスは パスワードとアカウントセキュリティの設定を保持し、共有とファイルの移行のための 前身である。

net rpc shareコマンドは共有、ディレクトリ、ファイルとその他の 該当するデータをWindowsサーバーからSambaサーバーに移行するのに使うことが出来る。

コマンドラインスイッチは、Windowsファイルサーバーのほとんど直接のクローンを作成できる。 たとえば、ファイルサーバーを移行するとき、WindowsサーバーのファイルのACLとDOSファイル 属性は以降プロセスの中に含まれ、移行が完了したときにSambaサーバー上で、ほとんど同じ ように現れる。

以降プロセスはSambaサーバーが完全に動作可能な時にのみ完了できる。ユーザーとグループ アカウントは、データの共有、ファイルとプリンターを移行する前に移行されねばならない。 ファイルとプリンター設定の移行は、SMBとMS DCE RPCサービスの両方を使用する。移行の プロセスでの良い方法は、あるサーバーから他へのデータの転送に影響する"中間者" (訳注:man-in-middle)による移行としてSambaサーバーを使うために現在存在するように 実装されている。たとえば、もしもSambaサーバーがMESSERという名前で、移行元の Windows NTサーバーがPEPPYという名前で、移行先のSambaサーバーがGONZALESであれば、 マシンMESSERはすべてのデータ(ファイルと共有)をPEPPYからGONZALESに移行を行う のに使うことが出来る。もしも移行先が指定されていない場合、ローカルサーバーが 既定値として、ネットワーク上での一般的な原則のように仮定される。

サーバー移行を成功裏に行うには、移行作業がとても依存するプロセスのように移行元の サーバー(かドメイン)の構造をしっかり理解しておくことが要求される。

移行プロセスでは2つの制限が知られている:

  1. netコマンドは移行元と移行先両方でユーザー資格証明が 存在することを必要とする。

  2. プリンターの設定は完全に移行できないか不正になるかもしれない。これは、 Windows 2003 サーバーをSambaに移行する際に特に発生するかもしれない。

共有の移行

net rpc share migrateコマンド操作は簡単な共有セクションの移行 ができる。セクションはファイル又はプリンター共有が定義されているパラメーターを含む。 この移行方法はパラメーターとして、ファイルシステムディレクトリパス、オプション記述 と、ファイルへの書き込み許可を行う単純なセキュリティ設定を持つ共有セクションを 作成する。以下の移行で必要な最初のステップの1つは、共有セクションの設定が利用に 適しているかを確認することである。

共有は移行プロセスの一部として動的に作成される。smbdは、 smb.confパラメーターのadd share commandによって 指定されるスクリプトを実行するためにOSを呼び出すことでこのことを行う。

$SAMBA_SOURCES/examples/scriptsディレクトリ中に add share commandのための適切な例がある。移行を 行うときに使うアカウントは、必要に応じて、適切なファイルシステムへのアクセス 権とそれらに対するACL設定および共有の作成権限を持たねばならないことに注意。 そのような権限は、SeAddUsersPrivilegeSeDiskOperatorPrivilegeという権限である。 権限と権利についてのより詳細な情報は、“User Rights and Privileges”を参照のこと。

共有の移行のためのコマンドの文法は以下の通り:

net rpc share MIGRATE SHARES <share-name> -S <source>
        [--destination=localhost] [--exclude=share1,share2] [-v]

When the parameter <share-name> is omitted, all shares will be migrated. The potentially large list of available shares on the system that is being migrated can be limited using the --exclude switch. For example:

root#  net rpc share migrate shares myshare\
         -S win2k -U administrator%secret"

これは、パスワードがsecretであるアカウント administratorに結びついたパーミッションを使ったSambaサーバーに win2kというサーバーから共有myshareを 移行する。使用するアカウントは移行元と移行先のSambaサーバーで同じでなければ ならない。共有の移行に先だってnet rpc vampireを使用する には、両方のシステムでアカウントが同じにしておく必要がある。共有の移行開始の 前に行う価値があることは、移行するアカウント(Sambaサーバー上)が必要とする権利と 権限について確認しておくことである。これは以下のように行う:

root#  net rpc right list accounts -Uroot%not24get

ここまでの手順で実行されることは、共有の移行だけである。ディレクトリと ディレクトリ中に含まれるものは、この時点で、今までの手順では移行されない。

ファイルとディレクトリの移行

この時点でカバーされてきたすべてのことは、ファイルとディレクトリデータの移行の 準備である。多くの人にとって、準備作業は退屈であり、ファイルとデータを使える 時になってやっと感激が得られる。次の手順は、netコマンドを 使ってデータファイルを転送(移行)するのに使えるテクニックを示す:

1つのサーバーから他にファイルを転送することは、Windows NTと200xサーバーが、いつでも 必要とされるツールを含んでいないために、Microsoft Windows管理者にとって挑戦的な 作業である。Windows NTからのxcopyコマンドはファイルと ディレクトリのACLを保存する能力がなく、Windows 200xのみができる。Microsoftは scopyと呼ばれる、ACL(セキュリティの設定)をコピーできる ユーティリティを提供していないが、それは、Windows NT か 200xのサーバーリソース キットの一部として提供している。

商用またはフリーウェアでWindowsサーバーから、完全なセキュリティ設定の維持をしながら ファイルとディレクトリのコピーを行うのに使えるツールがある。よく知られている フリーなツールで一番よいものは、robocopyというものである。

netユーティリティは、DOSファイル属性と同じように、完全にACLを 保持しながらファイルとディレクトリのコピーを行うのに使える。注意すべきは、 ACLを含むことは、移行先のシステムが、移行元のシステムと同じセキュリティ コンテキストの範囲内で 操作できるときにのみ意味をなすと言うことである。これは、 vawpireコマンドを使われたドメインからの結果のDMSとドメインコントローラーの両方に 適用される。ファイルとディレクトリの移行の前にすべての共有はすでに存在しなければ ならない。

移行コマンドの文法は以下の通りである:

net rpc share MIGRATE FILES <share-name> -S <source>
    [--destination=localhost] [--exclude=share1,share2]
    [--acls] [--attrs] [--timestamps] [-v]

もしも、<share-name>パラメーターが省略された場合、すべての共有が移行される。 移行元システム上での、潜在的にある大量の共有の一覧は、 --excludeコマンドスイッチで制限できる。

すべてのファイルのACLを保存することが必要な場合、--acls スイッチは上記のコマンドラインに追加すべきである。オリジナルのファイルの タイムスタンプは--timestampsスイッチを指定することで 保存でき、DOSファイル属性(すなわち hidden,archiveなど)は --attrsスイッチを指定することで保存できる。

Note

ACLの保存の能力は、移行先のサーバー上のホストOSの一般的なファイルシステムの機能と 同じように適切なACLのサポートに依存する。Windowsファイルサーバーから他への 移行は、すべてのファイル属性を完全に保存する。WindowsのACLをPOSIX ACLをサポート しているシステム上へのマッピングが困難なため、Windows ACLをSambaサーバーへ 完全に移行することはできない。

Sambaサーバー上でのACLの結果はオリジナルのACLには、おおかた一致しない。Windowsは グループのみで所有されるファイルをサポートしている。グループのみが所有する ファイルはUNIX/Linuxでは不可能である。移行におけるエラーは、smb.confファイル 中にforce unknown acl user = yes パラメーターを使うことで防ぐことが出来る。この機能は自動的に、グループのみが所有 するファイルを、Windows上でユーザーが所有するファイルに修正する。

nt4boxというマシンから、Sambaサーバーへのファイルの移行の 手続きの例は以下の通り:

root#  net rpc share migrate files -S nt4box --acls \
    --attrs -U administrator%secret

このコマンドは、nt4boxというWindowsサーバーから、移行作業を 始めるSambaサーバーに、すべての共有の、すべてのファイルとディレクトリを移行する。 グループのみが所有するファイルは administratorという ユーザーアカウントが所有するようになる。

共有のアクセス許可の移行

Administratorであっても、その中に任意のファイルやディレクトリをコピー できない、共有のアクセス許可(セキュリティ記述子)を設定することは可能である。 そのため、共有のアクセス許可は、独立した機能で用意されている:

root#  net rpc share migrate security -S nt4box -U administrator%secret

このコマンドは、ローカルのSambaシステムへ、nt4box上の各共有のにおける、共有の アクセス許可のみをコピーする。

共有とファイルの同時移行

以下で示される動作モードは今まで示したものを組み合わせたものである。これは 最初に共有の定義を移行し、次にすべての共有されているファイルとディレクトリを、 最後に共有のアクセス許可を移行する:

net rpc share MIGRATE ALL <share-name> -S <source>
    [--exclude=share1, share2] [--acls] [--attrs] [--timestamps] [-v]

組み合わせ移行の例は以下の通り:

root#  net rpc share migrate all -S w2k3server -U administrator%secret

これは、w2k3serverサーバーの完全な複製を生成する。

プリンターの移行

新しいネットワーク環境への移行と同様、新しいサーバーをインストールすることは、 しばしば家を建てることと類似している。基礎を作るところから家の構造部分の 完成までのステージは進歩がとても早いが、建築作業が完成に近づくにつれ、 仕上げ作業はより長くかかるように見える。

印刷の必要性は、ネットワーク環境にとても大きく依存し、とても簡単かもしれないが、 複雑かもしれない。もし必要性がとても単純ならば、印刷サポートを実装する最も良い 解決法は、古い設定から移行する代わりに、白紙の状態からすべてを再インストール することである。別の言い方をすると、たくさんの国際オフィスとたくさんある ローカルな支店が、印刷機能の拠点間で複雑怪奇になっているように統合された複雑な ネットワークのプリンター設定を移行することは、とてつもなく有望である。手動で 複雑な印刷ネットワークを再インストールするのは、とても時間がかかり、 フラストレーションが溜まる。しばしば、今使っているドライバーファイルを見つける のが困難で、より新しいバージョンのドライバーのインストールが必要となる。新しい ドライバーはしばしばプリンターの使用方法の変更を必要とする印刷機能を実装している。 更に追加で、非常に複雑な印刷設定は、それがどんなに広範囲に文書化されたとしても、 同じ環境を再作成することはほとんど不可能になる。、

既存の印刷構成の移行は以下のように行う:

  • 印刷キューを確立する。

  • プリンタードライバーをインストールする(プリントサーバーとWindowsクライアント上両方)。

  • 印刷フォームを設定する。

  • セキュリティの設定を行う。

  • プリンターの設定を行う。

Sambaのnetユーティリティは1つのWindowsプリントサーバーから 他への移行ができる。このツールをSambaサーバーsmbdに対して プリンターを移行するのに使った時、必要なサービスを作成するためにネットワーク リクエストを受け取るアプリケーションは、配下のプリンターを作成するためにOS を呼び出さなければならない。OS呼び出しは、smb.confファイル中のパラメーター で指定することが出来るインタフェース パラメーターを経由して行われる。このスクリプトは移行プロセスで必須である。 適切なスクリプトの例は、 $SAMBA_SOURCES/examples/scriptsから得られる。 このスクリプトはOS環境に適するようにカスタマイズせねばならず、また、プリント キューを作成するためにこのツールを使うことも出来る。

上記で説明した各コンポーネントは、個別に完了することが出来、また、自動操作の 一部として完了することができる。多くのネットワーク管理者は、特に事がうまく 行かない時、移行の問題を最も手慣れた手法で対処することを好む。各操作の 文法を簡単に以下で説明する。

Windows サーバー(NT4または200x)からのプリンター移行は以下である。この手順は、 プリンター共有を、ベースとなるプリントキューとともに作成する:

net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets]

プリンタードライバーをWindowsプリントサーバーからSambaサーバーに移行するのには、この コマンドライン操作を使用する:

net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]

以下の操作でプリンターフォームを移行できる:

net rpc printer MIGRATE FORMS [printer] [misc. options] [targets]

プリンターのセキュリティ設定(ACL)は以下のコマンドを使うことでWindowsサーバーからSambaサーバーに移行できる:

net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]

プリンター構成の設定は、紙のサイズや既定値の紙の方向のような要素を含む。 これらは以下のコマンドを使うことでWindowsサーバーからSambaサーバーに移行できる:

net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]

上記で説明した情報を含むプリンターの移行は、以下の文法を使う単一のコマンドで完了しても良い:

net rpc printer MIGRATE ALL [printer] [misc. options] [targets]

オープンしているファイルの制御

マニュアルページには、RAPかRPC機能呼び出しのどちらかを使うオープンしている ファイルをクローズするためのツールを提供する、net file コマンドの機能について説明がある。特定なし用法の情報についてのマニュアル ページを参照してほしい。

セッションとコネクションの管理

net sessionコマンドのセッション管理インタフェースは、以下の ようにSambaサーバーへの接続の一覧を示すための古いRAPメソッドを使う:

root#  net rap session -S MERLIN -Uroot%not24get
Computer             User name            Client Type        Opens Idle time
------------------------------------------------------------------------------
\\merlin             root                 Unknown Client         0 00:00:00
\\marvel             jht                  Unknown Client         0 00:00:00
\\maggot             jht                  Unknown Client         0 00:00:00
\\marvel             jht                  Unknown Client         0 00:00:00

セッションは以下のコマンドを実行することでクローズできる:

root#  net rap session close marvel -Uroot%not24get

プリンターとADS

Samba-3がMicrosoft Windows ADS環境で使われる場合、Samba経由で共有されるプリンターは ADSドメインに対して公開されるまではブラウズできない。公開されたプリンターに関する 情報は以下の文法で、net ads print infoコマンドを実行する ことで、ADSから入手できる:

net ads printer info <printer_name> <server_name> -Uadministrator%secret

もしも星印(*)がプリンター名引数の場所で使われた場合、すべてのプリンターの一覧が返る。

ADSに対してプリンターを公開する(有効にする)には、以下のコマンドを実行する:

net ads printer publish <printer_name> -Uadministrator%secret

これはローカルSambaサーバーのプリンターをADSに公開する。

ADSからSambaプリンターを削除するには、以下のコマンドを実行する:

net ads printer remove <printer_name> -Uadministrator%secret

ADSドメイン全体に渡ってプリンターの場所を調べる一般的な検索(問い合わせ)も、以下を使うことで出来る:

net ads printer search <printer_name> -Uadministrator%secret

Sambaキャッシュの操作

キャッシュ管理についての情報は、netマニュアルページを参照のこと。

IDMAP UID/SIDマッピングの管理

winbinddによって、IDMAP UIDからSIDとSIDからUIDへのマッピング は、テキストファイルにバックアップできる。テキストファイルは、手動で編集 できるが、自分自身が正確に何をやっているのかを知っている時にのみ、それを行う ことを強く推奨する。

IDMAP テキストダンプファイルはリストア(再ロード)できる。この動作が必要とされる 2つの状況は次の通り: a) 存在するIDMAPファイルが壊れたか、b)編集されたマッピング 情報をインストールする必要がある場合。

WinbindはIDMAPファイルをダンプするためには停止しなければならない。ダンプファイルを リストアする前に、winbinddを停止し、古い winbindd_idmap.tdbファイルを削除する。

IDMAPデータベースダンプファイルの作成

IDMAPデータベースは以下の方法でテキストファイルにダンプできる:

net idmap dump <full_path_and_tdb_filename> > dumpfile.txt

ここで、特定のSambaのビルドのランタイムtdbファイルが、ダンプファイルを 作成するための以下のコマンドで、/var/lib/samba ディレクトリに格納される:

net idmap dump /var/lib/samba/winbindd_idmap.tdb > idmap_dump.txt

IDMAPデータベースダンプファイルのリストア

IDMAPダンプファイルは以下のコマンドを実行することでリストアできる:

net idmap restore idmap_dump.txt

ここで、データをtdbファイルにリストアするために使える以下のコマンドで、 /var/lib/sambaディレクトリ中にSambaのランタイムtdb ファイルが格納される:

net idmap restore /var/lib/samba/winbindd_idmap.tdb < idmap_dump.txt

その他の雑多な操作

以下のコマンドは、Sambaドメインに関して基本的な統計を取るのに便利である。 このコマンドは現在のWindows XP Professionalクライアントでは動作しない。

root#  net rpc info
Domain Name: RAPIDFLY
Domain SID: S-1-5-21-399034208-633907489-3292421255
Sequence number: 1116312355
Num users: 720
Num domain groups: 27
Num local groups: 6

そのほかの便利なツールは、net timeサブコマンド群である。この サブコマンド群は以下のように、対象のサーバー上の現在の時刻を問い合わせるのに使える:

root#  net time -S SAURON
Tue May 17 00:50:43 2005

UNIXの/bin/timeから得られる時刻情報を渡すことが目的の場合は、 渡すために準備されたフォーマットで対象のサーバーから時刻を得るのはよい方法である。 これは、以下を実行することで行える:

root#  net time system -S FRODO
051700532005.16

対象のサーバー上で時刻を設定するためには以下のようにする:

root#  net time set -S MAGGOT -U Administrator%not24get
Tue May 17 00:55:30 MDT 2005

以下のコマンドを実行することで、サーバーのタイムゾーンを得ることが出来る:

root#  net time zone -S SAURON
-0600

Chapter 14. 識別情報のマッピング(IDMAP)

John H. Terpstra

Samba Team

Microsoft Windows オペレーティングシステムは、Sambaを実装したOSとの間での相互運用性を 行うために、難しい問題を要求してくるといういくつかの特徴がある。この章では、 SambaサーバーをMicrosoft Windowsネットワーク環境に統合するための難問の1つを解決するために 使う、Samba-3(バージョン 3.0.8以降)のメカニズムについて明示的に説明する。この章では、 Windowsのセキュリティ識別子(SID)をUNIXのUIDとGIDについての識別情報マッピング(IDMAP) について説明する。

いろいろな場面において十分に適用出来るようにするため、各可能なSambaの配布タイプに ついて解説を行う。これは、どのようにIDMAP機能が実装されたかについての概要によって フォローされる。

IDMAP機能は、複数のSambaサーバー(またはSambaネットワーククライアント)がドメイン中で インストールされている場合に重要である。単一のSambaサーバーにおいては、IDMAP基盤 については余り気にかける必要はない。既定値におけるSambaの動作はほとんど の場合、十分に使えるものである。複数のSambaサーバーが使われる場合、あるサーバーから 別のサーバーにデータを移動する時にはしばしばこれが必要で、それはやっかい事が始まる 所でもある!

LDAPディレクトリ中にユーザーとグループアカウント情報が格納されている場合、すべてのサーバーは ユーザーとグループに対して一貫したUIDとGIDを使うことが出来る。これは、NSSとnss_ldapツール を使うことで出来る。Sambaはローカルアカウントのみを使うように設定出来、その場合、IDMAP での問題が発生する範囲は若干少なくなる。これは、サーバーが単一のドメインに属していて、 ドメイン間の信頼関係が必要ない時に有効に動作する。別の言い方をすると、もしもSamba サーバーがNT4ドメインのメンバーかADSのドメインメンバーである場合か、不慮のクロスオーバーが ないように、セキュリティ名前空間を保持する必要がある場合、(すなわち、ユーザー DOMINICUS\FJonesFRANCISCUS\FJonesという ユーザーのアカウントリソースへのアクセスが出来ないようにしなければならない) [4]クローズする試みは、 IDMAP機能が設定されているという方法に対して提供されなければならない。

IDMAPの使用は、Sambaサーバーが一つ以上のドメインからワークステーションまたはサーバーによって アクセスされる場合に重要であり、そのような場合、winbindを動作させることが重要で、そうする と、外部のSIDをローカルのUNIX UIDとGIDに解決(IDマッピング)することが出来るようになる。

IDMAP機能は、Samba起動時にwinbinddの実行を必要とする。

SambaサーバーのサーバータイプとIDMAP

4つの基本的なサーバータイプがあり、これは、 サーバータイプとセキュリティモードの章に 説明がある。

スタンドアロンSambaサーバー

スタンドアロンSambaサーバーはWindows NT4ドメイン、Windows 200x Active Directory ドメインかSambaドメインのメンバーでない形で動く。

定義により、これは、ユーザーとグループはローカルに作成/制御され、ネットワーク ユーザーの識別はローカルのUNIX/Linuxユーザーログイン情報に一致しなければならない。 そのため、IDMAP機能はほとんど関心を払う必要はなく、winbindも不要で、IDMAP 機能は関連しないか、興味を持つべきものではない。

ドメインメンバーサーバーかドメインメンバークライアント

Samba-3はWindows NT4 PDCまたはBDCとして動作でき、それによって、Windows NT4と 互換性を持つドメイン制御プロトコルを提供する。Samba-3のファイルと印刷共有 プロトコルはすべてのバージョンのMicrosoft Windows製品と互換がある。Windows NT4は Microsoft Windows Active Directoryと同様、広範囲にWindows SIDを使用する。

Samba-3ドメインメンバーサーバーとクライアントはMicrosoft Windows SIDと正しく相互に 処理を行わなければならない。入力されたSIDはローカルのUNIX UIDとGIDに変換され なければならない。Sambaサーバーから出力する情報は、適切なSIDでMicrosoft Windows クライアントとサーバーに提供されなければならない。

Windowsネットワークドメイン(NT4形式またはADS)のメンバーであるSambaはいろいろな 方法で識別情報のマッピングを扱うように設定出来る。使用するメカニズムは、 winbinddデーモンが使われるか否かとどのようにwinbindの 機能が設定されているかに依存する。設定オプションの簡単な説明は以下の通り:

Winbindが使用されず、ユーザーとグループがローカルの場合:

winbinddが使われないと、Samba (smbd)は、入力されたネットワークからの 情報の識別を解決するための、基本的なUNIX/Linuxメカニズムを 使用する。これは、セッションセットアップ要求時にLoginID (アカウント名)を使い、getpwnam()システムファンクションコール にそれを渡す。この呼び出しは最近のUNIX/Linuxシステム上では ネームサービススイッチ(NSS)メカニズムを使うように実装されて いる。"ユーザーとグループがローカル"という場合、それらは ローカルシステム上の、/etc/passwd/etc/groupにそれぞれ格納されることを 意味する。

たとえば、ユーザーBERYLIUM\WambatWが Sambaサーバーに対して接続をオープンしようとする場合、 入力されるSessionSetupAndX要求は、/etc/passwd ファイル中のユーザーWambatWを検索するために システムを呼び出す。

この設定は、スタンドアロンSambaサーバー、ドメインメンバーサーバー (NT4またはADS)とsmbpasswdまたはtdbsamベースのSamba passdb バックエンドを使うPDCに対して使うことが出来る。

Winbindは使わないが、ユーザーとグループはNSS経由で解決する場合

この場合、ユーザーとグループアカウントは、ローカルアカウントとして 取り扱われる。ローカルアカウントそのものとただ1つ違う点は、 共有可能なリポジトリ内にアカウントが格納されると言うことである。 一般的には、これは、NIS形式のデータベースか、そうでなければ LDAP内にあると言うことである。

この設定は、スタンドアロンSambaサーバー、ドメインメンバーサーバー (NT4またはADS)とsmbpasswdまたはtdbsamベースのSamba passdb バックエンドを使うPDCに対して使うことが出来る。

Winbind/NSSと既定値のローカルなIDMAPテーブルの場合:

Windows NT4ドメインかADSドメインのメンバーである単一のSamba サーバーか単純なSambaサーバーのみを必要とするサイトは多数ある。 標準的なサーバーの例は、ドメイン用のドメインコントローラー からアカウント認証情報を入手するためにwinbindを使うように 設定され、ローカルアカウントを持たないアプライアンスの ようなファイルサーバーである。ドメイン制御機能は、Samba-3、 Microsoft Windows NT4かMicrosoft Windows Active Directory によって提供される。

Winbindは、この状態においては非常に有益である。必要と されるすべては、smb.confファイル中で定義することが出来る UIDとGIDの値の範囲である。/etc/nsswitch.conf ファイルは、入力されたSIDを適切なUIDとGIDにマッピングする ための、すべての難しい作業をこなすwinbind を使うために設定される。SIDはwinbindがそれを受け取る順で UID/GIDに割り当てられる。

この設定は、複数のSambaサーバーにまたがってUID/GIDとユーザーや グループとのマッピングが同一であることが求められる環境(サイト) では実用的でない。この方法の危険性の1つは、winbind機構の IDMAPデータベースファイルが壊れるか喪失した場合、IDMAP ファイル修正、再生成しても、UIDやGIDが以前と異なるユーザーや グループにマッピングされてしまい、結果としてSambaサーバー上に 格納されたWindowsファイルの所有者が不正になってしまう可能性 がある点である。

Winbind/NSSがRIDベースのIDMAPの場合:

IDMAP_RID機能はSamba 3.0.8から提供された。これは、 ADSスキーマ拡張を適用しないMicrosoft ADSを使用する ことに関わりがあり、IDMAPテーブルをメンテナンスする 目的のためにLDAPディレクトリサーバーをインストールして いない、たくさんのサイトのために作業を簡単にする。 もしも単一のADSドメイン(ドメインのフォレストではなく 複数のドメインツリーでない)で、IDMAPテーブル問題に 対して単純なステレオタイプの解決方法を望んでいるなら、 IDMAP_RIDは明らかな選択肢である。

この機能はidmap uididmap gidのレンジを割り当てることを 要求し、それが、SIDの相対識別子(RID)の部分を直接UIDのベースにRIDの 値を足した分に、自動マッピングするための、このレンジの サブセットを割り当てることが可能な idmap uidの範囲内であることを要求する。 たとえば、もしもidmap uidの範囲が 1000-100000000で、 idmap backend = idmap_rid:DOMAIN_NAME=1000-50000000 で、発生したSIDが S-1-5-21-34567898-12529001-32973135-1234 という値ならば、結果のUIDは1000 + 1234 = 2234である。

WinbindとNSS/LDAPバックエンドベースのIDMAP機能:

この設定では、winbindsmb.confファイル内で 指定されたidmap uididmap gidの範囲からSIDからUIDとGIDに 解決を行うが、ローカルのwinbind IDMAPテーブルを使う代わりに、 すべてのドメインメンバーマシン(クライアントとサーバー)が共通の IDMAPテーブルを共有できるためのLDAPディレクトリ中に格納された ものを使う。

すべてのLDAP IDMAPクライアントは、smb.confファイル中の idmap backend機能がLDAPリダイレクトを 正しく扱えないため、マスターLDAPサーバーのみを使うということは 重要である。

UNIX/LinuxのユーザーとグループIDを解決するためにNSSを使うwinbindの場合:

passdb バックエンドとしてのLDAPの使用はPDC、BDCとドメイン メンバーサーバーに対する優れた解である。それは、UID、GIDと 一致したSIDがすべてのサーバー間で首尾一貫している事を 保証するきちんとした解である。

LDAPベースのpassdbバックエンドの使用は、PADL nss_ldap ユーティリティか同等品を要求する。この状況の場合、 winbindは外部のSID、すなわち、スタンドアロン WindowsクライアントからのSID(すなわち、このドメインの メンバーでない)を他のドメインからのSIDと同じように 扱うために使われる。外部のUID/GIDは、ローカルのIDMAP テーブルでwinbindを使う時と同じ方法で正確に、 割り当てられた範囲(idmap uidとidmap gid)にマップされる。

nss_ldapツールセットはActive Directory経由と同様に、LDAP 経由でUIDとGIDにアクセスするために使われる。Active Directory を使うために、AD4UNIXスキーマ拡張か、Microsoft Services for UNIXバージョン3.5かそれ以降のどちらかをを、UNIXアカウント 認証情報を管理するために、ADSスキーマを 拡張するために インストールしてADSスキーマを変更することが必要である。 ADSスキーマが拡張されると、Microsoft管理コンソール(MMC) スナップインもADSのユーザーとコンピュータ管理ツールから UNIXの認証情報を設定/管理することが出来るようにインストール される。各アカウントは、UIDとGIDデータがSambaによって使われる ことが出来る前に、UNIXで有効な状態と分離されなければならない。

プライマリドメインコントローラー

Microsoft Windowsドメインセキュリティシステムは、アカウント作成のプロセスの 一部として、ユーザーとグループSIDを生成する。WindowsはUNIXのUIDかGIDのような 概念を持たない。その代わり、固有のタイプのセキュリティ記述子を持つ。Sambaが ドメインコントローラーとして使われる時、各ユーザーとグループに固有のSIDを生成する 手段を提供する。Sambaは、smb.confファイル中で指定されたベースの値にUID またはGIDを2倍した値を足すという算術的に計算されたRIDを足すマシンとドメイン SIDを生成する。この方法は算術的マッピングと呼ばれる。

例をあげると、もしもユーザーのUIDが4321の場合、算術的なRIDベースが1000だとすると、 RIDは1000 + (2 x 4321) = 9642となる。そのため、もしもドメイン SIDがS-1-5-21-89238497-92787123-12341112ならば、 結果のSIDはS-1-5-21-89238497-92787123-12341112-9642となる。

前述のタイプのSIDはSambaによって、自動的な機能としてその場で生成されるか (passdb backend = [tdbsam | smbpasswd]を使った場合)、 あるいはLDAPベースのldapsam中でアカウントの一部として恒久的に格納されても よい。

ADSはUIDとGIDのような追加のアカウント属性に適応するために拡張できるディレクトリ スキーマを使う。Microsoft Service for UNIX 3.5をインストールすると、通常のADS スキーマをUNIXアカウント属性を含むように拡張する。これらはもちろん通常の ADSアカウント管理のMMCインタフェーススナップインモジュールを等して別途管理され なければならない。

ドメイン内で使われるセキュリティ識別子は、競合を避けるためと完全性を保つために 管理されねばならない。NT4ドメインコンテキスト中で、PDCはすべてのセキュリティ 認証情報の、バックアップドメインコントローラー(BDC)への配布を管理する。現時点で、 そのような情報のために適したSambaドメインコントローラーのpassdbバックエンドは、 LDAP中バックエンドのみである。

バックアップドメインコントローラー

ユーザーとグループアカウントの中の情報の変更はBDCからPDCに送られる。PDCのみが ディレクトリに対して書き込むことができる。

IDMAPの情報は、すべてのドメインコントローラーがマスター(書き込み可能な)LDAPサーバーに 対してアクセス可能である限り、LDAPサーバーに直接書き込める。Samba-3は現時点で IDMAPバックエンド中でLDAPリダイレクトを扱えない。これは、IDMAP機能をスレーブ (複製される)LDAPサーバーで使うのは危険だということである。

IDMAPバックエンドの使用例

winbindを使う誰にとっても、下記の設定例は有用である。多くの場合、 winbindは、ドメインメンバーサーバー(DMS)とドメインメンバークライアント (DMC)を使うために一番興味がある事項である。

規定値のWinbind TDB

2つの共通的な設定が使われる:

  • ネットワーク上にNT4 PDC(BDCがあってもなくても)かSambaPDC(BDCがあってもなくても)がある。

  • ネットワークは Microsoft Windows 200x ADSを使っている。

NT4形式のドメイン(Sambaドメインを含む)

NT4ドメインメンバーサーバーのsmb.conは、NT4 DMSに対するsmb.confファイルのグローバルセクション部分の例を示す。

Example 14.1. NT4形式のドメインメンバーサーバーのsmb.conf

# グローバルパラメーター
[global]
workgroup = MEGANET2
security = DOMAIN
idmap uid = 10000-20000
idmap gid = 10000-20000
template primary group = "Domain Users"
template shell = /bin/bash

winbindの使用は、NSSの設定を必要とする。以下を含むように /etc/nsswitch.confのエントリを編集する:

...
passwd: files winbind
shadow: files winbind
group:  files winbind
...
hosts:  files [dns] wins
...

ホストエントリでDNSを使う場合は、サイト上でDNSが使われている場合にのみ行う。

DMSを作成するには以下のような手順を踏む:

  1. 上記の設定を使って、smb.confファイルを作成するかインストールする。

  2. 以下を実行する:

    root#  net rpc join -UAdministrator%password
    Joined domain MEGANET2.
    

    ドメインへの参加が成功するかどうかは、以下のコマンドで確認できる:

    root#  net rpc testjoin
    Join to 'MIDEARTH' is OK
    

    ドメインへの参加が失敗した場合、以下のようなエラーメッセージが出力される:

    root#  net rpc testjoin
    [2004/11/05 16:34:12, 0] utils/net_rpc_join.c:net_rpc_join_ok(66)
    Join to domain 'MEGANET2' is not valid
    

  3. nmbd, winbind,smbdをこの順番で起動する。

ADSドメイン

ADSドメインへの参加手続きは、NT4ドメインへの参加と似ているが、smb.confファイルは ADSドメインメンバーサーバーのsmb.confで示された 内容の部分が異なる。

Example 14.2. ADSドメインメンバーサーバーのsmb.conf

# グローバルパラメーター
[global]
workgroup = BUTTERNET
netbios name = GARGOYLE
realm = BUTTERNET.BIZ
security = ADS
template shell = /bin/bash
idmap uid = 500-10000000
idmap gid = 500-10000000
winbind use default domain = Yes
winbind nested groups = Yes
printer admin = "BUTTERNET\Domain Admins"

ADSのDMS操作はkerberos(KRB)を使用すること要求する。これを動作させるため、 krb5.confファイルを設定する必要がある。正確な要求 内容は、どのバージョンのMITかHeimdal kerberosが使われているかに依存する。 現時点でMIT Kerberosのバージョンが1.3.5で、Heimdal が 0.61である最新の バージョンのみを使うことを推奨する。

DMSを作成するには以下のステップを必要とする:

  1. 上記の設定でsmb.confファイルを作成するかインストールする。

  2. 上記で示されたように、/etc/nsswitch.confファイルを編集する。

  3. 以下を実行する:

    root#  net ads join -UAdministrator%password
    Joined domain BUTTERNET.
    

    ドメインへの参加が成功するか失敗するかは以下のコマンドで確認出来る:

    root#  net ads testjoin
    Using short domain name -- BUTTERNET
    Joined 'GARGOYLE' to realm 'BUTTERNET.BIZ'
    

    ドメインへの参加が不正か失敗するかは以下を実行することで検出できる:

    root#  net ads testjoin
    GARGOYLE$@'s password:
    [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
      ads_connect: No results returned
    Join to domain is not valid
    

    特定のエラーメッセージは、発生した不成功のタイプに依存するため、 上記とは異なるかもしれない。log levelを10まで 増やし、テストを再実行し、失敗の真の原因を探るために、生成されたログ ファイルを調べること。

  4. nmbd, winbindsmbd デーモンをこの順番で起動する。

IDMAP_RIDを使うWinbind

idmap_rid機能は、ネイティブなwinbindとは異なり、新しい ツールで、MicrosoftのSIDをUNIXのUIDとGIDに、予測可能なマッピングを作成する。 Samba IDMAP機能にこの手法を実装する一番の利点は、集中したIDMAPデータを保存する 必要性をなくすということである。不都合な点は、単一のADSドメイン内のみで使う 事ができる事と、ドメイン間信頼機能とは互換性がないことである。

このSIDからUID/GIDへのマッピングにおける代替手法はidmap_ridプラグインを 使って実現できる。このプラグインは、RIDに指定されたベース値を加える事に よってUIDとGIDを引き出すために、ユーザーSIDのRIDを使う。このユーティリティは 複数のドメイン環境とは互換がない、allow trusted domains = No パラメーターを指定することを要求する。idmap uididmap gidの範囲を指定する必要がある。

idmap_rid機能はNT4/Samba形式のドメインとActive Directoryで使える。これをNT4 ドメインで使うためには、realmパラメーターを含んでは いけない。さらに、ドメインに参加するために使う手法は、 net rpc joinを使う。

ADSドメイン環境でのsmb.confファイルの例は、 idmap_ridを使うADSドメインメンバーのsmb.conf である。

Example 14.3. idmap_ridを使うADSドメインメンバーのsmb.conf

# グローバルパラメーター
[global]
workgroup = KPAK
netbios name = BIGJOE
realm = CORP.KPAK.COM
server string = Office Server
security = ADS
allow trusted domains = No
idmap backend = idmap_rid:KPAK=500-100000000
idmap uid = 500-100000000
idmap gid = 500-100000000
template shell = /bin/bash
winbind use default domain = Yes
winbind enum users = No
winbind enum groups = No
winbind nested groups = Yes
printer admin = "Domain Admins"

たくさんのユーザーが居る大きなドメイン中で、ユーザーとグループを列挙することを無効に することは避けられない。例えば、Active Directory中に22000人ものユーザーが居る サイトで、winbindベースのユーザーとグループの解決は、winbindを 最初に開始する時点から12分以上利用できない。列挙を無効にすると、瞬間的に反応が 返る。ユーザーとグループの列挙を無効にすると言うことは、getent passwdgetent groupコマンドを使ってユーザーかグループの一覧を 表示することが出来ないと言うことである。特定のユーザーのみを検索することは 以下のような方法で可能である。

このツールを使用するには、ネイティブなwinbindの使用ごとにNSSの設定を必要とする。 以下のパラメーターを含むように/etc/nsswitch.confファイルを 編集する。

...
passwd: files winbind
shadow: files winbind
group:  files winbind
...
hosts:  files wins
...

以下の手順でidmap_rid機能を使うことが出来る:

  1. 上記の設定でsmb.confファイルを作成またはインストールする。

  2. 上記で示されたように/etc/nsswitch.confファイルを編集する。

  3. 以下を実行する:

    root#  net ads join -UAdministrator%password
    Using short domain name -- KPAK
    Joined 'BIGJOE' to realm 'CORP.KPAK.COM'
    

    ドメインへの参加が不正または失敗するかは以下を実行することで検出できる:

    root#  net ads testjoin
    BIGJOE$@'s password:
    [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
      ads_connect: No results returned
    Join to domain is not valid
    

    特定のエラーメッセージは、発生した問題のタイプに依存するため、上記と 異なるかもしれない。log levelを10まであげて、 テストを再実行し、失敗の真の原因を識別するために生成したログファイルを 調べること。

  4. nmbd, winbindsmbd デーモンをこの順番で起動する。

  5. この設定の動作は以下を実行することで検証できる:

    root#  getent passwd administrator
    administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash
    

Winbindを使ったIDMAPデータのLDAPへの格納

IDMAPの情報をLDAP中に格納することは、NT4/Samba-3形式のドメインとADSドメインで 利用できる。OpenLDAPは、多くの標準準拠のLDAPサーバーが使われているにもかかわらず、 この目的に多用されているLDAPサーバーである。従って、このIDMAP設定を、Sun iPlanet LDAP Server,Novell eDirectory, Microsoft ADS plus ADAMやその他で使うことは可能で ある。

ADSドメインのための例は、 LDAPを使うADSドメインメンバーサーバーにある。

Example 14.4. LDAPを使うADSドメインメンバーサーバー

# グローバルパラメーター
[global]
workgroup = SNOWSHOW
netbios name = GOODELF
realm = SNOWSHOW.COM
server string = Samba Server
security = ADS
log level = 1 ads:10 auth:10 sam:10 rpc:10
ldap admin dn = cn=Manager,dc=SNOWSHOW,dc=COM
ldap idmap suffix = ou=Idmap
ldap suffix = dc=SNOWSHOW,dc=COM
idmap backend = ldap:ldap://ldap.snowshow.com
idmap uid = 150000-550000
idmap gid = 150000-550000
template shell = /bin/bash
winbind use default domain = Yes

NT4またはSamba-3形式のドメインの場合、realmは使わず、 ドメインに参加するために使うコマンドはnet rpc joinである。 上記の例は、バグの報告に記述されている高度な エラー報告のテクニックも示している。

MIT kerberosがインストールされている場合(バージョン 1.3.4以降)、以下の内容を 含むように/etc/krb5.confを編集する:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = SNOWSHOW.COM
 dns_lookup_realm = false
 dns_lookup_kdc = true

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

Heimdal kerberosがインストールされている場合、/etc/krb5.conf ファイルは空白にするか(すなわち内容が無い)、以下の内容を含むように編集する:

[libdefaults]
        default_realm = SNOWSHOW.COM
        clockskew = 300

[realms]
        SNOWSHOW.COM = {
                kdc = ADSDC.SHOWSHOW.COM
        }
        
[domain_realm]
        .snowshow.com = SNOWSHOW.COM

Note

Sambaは、/etc/krb5.confファイルがない時はHeimdalライブラリを 使えない。それが空白のファイルであるならば、Heimdal kerberosライブラリは使用可能 である。SambaがHeimdalライブラリを使う時には、自動的にこれを見つけることが出来る ので、特に何も設定しなくても良い。

以下のエントリを含むようにNSS制御ファイル/etc/nsswitch.conf を編集する:

...
passwd: files ldap
shadow: files ldap
group:  files ldap
...
hosts:  files wins
...

この解決方法のためには、PADLnss_ldapツールセットが必要である。必要とされる情報を /etc/ldap.confファイルに設定すること。以下は、 動作するファイルの例である:

host    192.168.2.1
base    dc=snowshow,dc=com
binddn  cn=Manager,dc=snowshow,dc=com
bindpw  not24get

pam_password exop

nss_base_passwd ou=People,dc=snowshow,dc=com?one
nss_base_shadow ou=People,dc=snowshow,dc=com?one
nss_base_group  ou=Groups,dc=snowshow,dc=com?one
ssl     no

以下の手続きは動くようにするための設定手順である:

  1. 上記で示されたようにsmb.confファイルを設定する。

  2. 上記で示されたように/etc/krb5.confファイルを作成する。

  3. 上記で示されたように/etc/nsswitch.confファイルを設定する。

  4. PADL nss_ldapツールセットをダウンロードし、コンパイルし、インストールする。 上記で示されたように/etc/ldap.confファイルを設定する。

  5. LDAPサーバーを設定し、以下のLDIFファイルで示されるような、IDMAPによって 必要とされるトップレベルのエントリをディレクトリに追加(初期化)する。

    dn: dc=snowshow,dc=com
    objectClass: dcObject
    objectClass: organization
    dc: snowshow
    o: The Greatest Snow Show in Singapore.
    description: Posix and Samba LDAP Identity Database
    
    dn: cn=Manager,dc=snowshow,dc=com
    objectClass: organizationalRole
    cn: Manager
    description: Directory Manager
    
    dn: ou=Idmap,dc=snowshow,dc=com
    objectClass: organizationalUnit
    ou: idmap
    

  6. Samba DMSをADSドメインに、以下のコマンドを使って参加させる:

    root#  net ads testjoin
    Using short domain name -- SNOWSHOW
    Joined 'GOODELF' to realm 'SNOWSHOW.COM'
    

  7. 以下のようにして、Sambaのsecrets.tdbファイルに LDAPサーバーへのアクセスパスワードを格納する:

    root#  smbpasswd -w not24get
    

  8. nmbd, winbindsmbd デーモンをこの順番で起動する。

ドメインへの参加が成功するか失敗するかを識別するため、この章の始めの方で 紹介された診断手続きに従うこと。多くの場合、失敗の理由が何も示されない コマンドプロンプトの静かな結果によって、失敗は表示される。

RFC2307bis Schema拡張を使ったADSからのIDMAPとNSSに対するLDAPの使用

この方法はきれいなものではない。以下で提供される情報は手引きのみであり、かつ、 全くもって不確かで完全ではない。この方法は動く。数多くの巨大サイトで使用され、 耐えられるレベルのパフォーマンスを提供している。

smb.confファイルの例は NSS経由のRFC2307bisスキーマ拡張日付を使うADSドメインメンバーサーバー にある。

Example 14.5. NSS経由のRFC2307bisスキーマ拡張日付を使うADSドメインメンバーサーバー

# グローバルパラメーター
[global]
workgroup = BOBBY
realm = BOBBY.COM
security = ADS
idmap uid = 150000-550000
idmap gid = 150000-550000
template shell = /bin/bash
winbind cache time = 5
winbind use default domain = Yes
winbind trusted domains only = Yes
winbind nested groups = Yes

DMSは通常の手順でドメインに参加しなければならない。更に追加で、PADL nss_ldap ツールセットのコンパイルとインストールが必要である。以下のようにしてこのツールを 構築する:

./configure --enable-rfc2307bis --enable-schema-mapping
make install

/etc/nsswitch.confファイル中には以下の内容が必要である:

...
passwd: files ldap
shadow: files ldap
group:  files ldap
...
hosts:  files wins
...

/etc/ldap.confも設定しなければならない。特定の説明に ついては、PADLのドキュメントとnss_ldapのソースコードを参照のこと。

次のステップではADSスキーマの準備を必要とする。これは、この章の残りの部分で 簡単に説明する。

IDMAP, Active DirectoryとMicrosoftの Services for UNIX 3.5

Microsoft Windows Service for UNIX (SFU)バージョン3.5は、Microsoftの Webサイトダウンロード から自由にダウンロードできる。このツールをダウンロードする必要はあり、 以下のMicrosoftの手順に従ってインストールする。

IDMAP, Active Directory と AD4UNIX

AD4UNIXツールの取得とインストールの手順は、 Geekcomix というWebサイトにある。



[4] DOMINICUS\FJonesFRANCISCUS\FJonesFJones

Chapter 15. User Rights and Privileges

Gerald (Jerry) Carter

Samba Team

John H. Terpstra

Samba Team

Sambaがドメインを制御しているネットワーク中で、Windowsのユーザー、グループとマシン アカウントを管理するには、Microsoft Windowsネットワーク環境とUNIX OS環境の間で インタフェースを取る必要がある。Windows セキュリティドメインにマシンを追加するための 権利(許可)は、Windows NT4ドメインとActive Directoryドメインの両方で、非管理者ユーザーに 割り当て(設定)することができる。

ドメインへWindows NT4/2kX/XPProましんを追加するには、追加されるマシンごとにマシン アカウントを作成する必要がある。マシンアカウントは、ユーザーのログオンを許可する ために信頼できるマシンを検証するために使うのに必要である。

マシンアカウントはユーザーアカウントに類似していて、そのため、Sambaをホスティングしている UNIXマシンでの実装では(すなわちSambaが動いているマシン)、ユーザーアカウントの特別なタイプ として作成する必要がある。マシンアカウントは、通常のユーザーアカウントと比べて、 アカウント名(ログインID)が$記号で終わっているところが異なる。 更に、このタイプのアカウントは、システムユーザーとしてUNIX環境に決してログイン出来ない ことと、ログインシェルが/bin/falseに設定されていることと、ホーム ディレクトリが/dev/nullに設定されていることも違う。マシンアカウントは 起動時にドメインメンバーのマシンであることを検証するためのみに使われる。このセキュリティ 対応は、ネットワークの完全性を破る中間者攻撃をブロックするために設計されている。

Note

マシン(コンピュータ)アカウントは、ドメインメンバーサーバーとワークステーションのための セキュリティ証明書(credentials)を格納するために、Windows NT OSファミリで使われる。 ドメインメンバーの起動時、ドメインコントローラーと証明書の交換を含む検証プロセスを 行う。もしもドメインコントローラーが保持している証明書を使っての認証に失敗した 場合、マシンはドメインユーザーからのアクセスが出来なくなる。コンピュータアカウント は、Microsoft Windowsのセキュアな認証方法において必須のものである。

UNIXシステムアカウントの作成は、rootアカウントと言う方が通りがよい、 システム管理者の伝統的な唯一の権利であった。UNIX環境では、同じUIDを持つ複数のユーザーを 作ることが可能である。UID=0のUNIXユーザーはだれでもrootアカウント ユーザーと本質的に同じである。

すべてのバージョンのSambaは、UNIX環境で、ユーザー、グループとマシンアカウントを管理する ためのCIFS機能呼び出しを許可するシステムインタフェーススクリプトを呼び出す。3.0.10 を含むそれまでのすべてのバージョンのSambaは、それらのインタフェーススクリプトを 実行するために、明確にUNIXのrootアカウントにマップされる Windows管理者アカウントを使用することを要求する。こうする必要性は、無理もない話だが、 特に、UNIXホストシステムでrootレベルのアクセスを行ってはならない 人が特権を得てしまう事について、Samba管理者の間では評判が悪い。

権利の管理能力

Samba 3.0.11から、Windowsの権限モデルのサポートが導入された。このモデルは、特定の 権利をユーザーかグループSIDに割り当てるというものである。この機能を有効にするため、 smb.confファイル中のglobalセクション中で、 enable privileges = yesを定義しなければならない。

現在、Samba-3でサポートされている権利は“現在有効な権限の一覧”に一覧がある。 この章の残りでは、Sambaサーバー上でどのように権限を管理し使うかについて説明する。

Table 15.1. 現在有効な権限の一覧

権限説明

SeMachineAccountPrivilege

マシンをドメインに追加する

SePrintOperatorPrivilege

プリンターの管理

SeAddUsersPrivilege

ドメインへのユーザーとグループの追加

SeRemoteShutdownPrivilege

リモートシステムの強制シャットダウン

SeDiskOperatorPrivilege

ディスク共有の管理

SeTakeOwnershipPrivilege

ファイルか他のオブジェクトに対する所有権の取得


net rpc rightsユーティリティの使用

Sambaサーバー上でユーザーとグループに権利を割り当てる管理には2つの主要な手段がある。 止め引用のNT4ユーザーマネージャはSambaドメインコントローラーに接続 するためにWindows NT4、2000かXP Professionalのドメインメンバークライアントのどれから でも使うことが出来、権限の割り当てを表示したり修正できる。しかし、このアプリケーション は、Windows 2000かそれ以降のクライアント上で動かす時にはバグがある。そのため、管理 操作の実行を行うために必要なコマンドラインユーティリティを提供している。

Samba-3.0.11以降のnet rpc rightsユーティリティは新しい3つの サブコマンドを提供している:

list [name|accounts]

引数なしで起動した場合、net rpc listは単純にサーバー 上の有効な権利の一覧を表示する。特定のユーザーまたはグループを指定した 場合、ツールは指定されたアカウントに割り当てられている現在の権限を 表示する。accountsという特別な文字列を付けて起動 した場合、net rpc rights listはサーバー上のすべての 特権アカウントの一覧とそれに割り当てられた権利を表示する。

grant <user> <right [right ...]>

引数なしで起動すると、この機能は指定されたユーザーかグループに一連の 権利を割り当てるのに使う。例えば、Sambaドメインコントローラー上の Domain Admins groupのメンバーに、ドメインにクライアントマシンを追加する 能力を許可するためには、以下のように実行する:

root#  net -S server -U domadmin rpc rights grant \
	 'DOMAIN\Domain Admins' SeMachineAccountPrivilege

以下のような指定も同じ結果となる:

root#  net rpc rights grant 'DOMAIN\Domain Admins' \
     SeMachineAccountPrivilege -S server -U domadmin

空白で区切った権利の一覧を指定することで、複数の権限を割り当てることも 可能である。パラメーター'Domain\Domain Admins'はシステムシェルによって バックスラッシュと空白が解釈されてしまうのを防ぐために、シングルクォート かダブルクォートで囲まなければならない。

revoke <user> <right [right ...]>

このコマンドはnet rpc rights grantと形式が似ている。 これは、ユーザーとグループから割り当てられた権利(か権利の一覧)を削除する。

Note

、アカウントに割り当てられる権限の設定か削除を可能にするため、Domain Admins グループ メンバーとして接続する必要がある。この能力はDomain Adminsグループに固有で変更できない。 Domain Adminsのメンバーに割り当てられた能力以外、既定値の権利と権限はない。これは、 すべての管理者の権利と権限(それらに割り当てられた能力以外)は、Domain Adminsグループ でも明示的に割り当てられなければならないということを意味する。

いったんsmbdが、ユーザーが必要な権利を持っていると確認した場合、特定の操作はrootとして 実行されるので、初期状態では、どのユーザーに対しても、何らの権利は割り当てられない。 例えば、Windowsドメインにクライアントを参加させる時、add machine script はほとんどの場合、スーパーユーザーの権利で動作させる必要がある。この理由のため、アカウントに 対して権限を割り当てるのはとても注意すべきである。

root ユーザー(UID=0)としてのアクセスは、すべての権限チェックをバイパスする。

権限の説明

Samba-3.0.11で実装された権限は以下の通りである。ありそうではあるが、可能であれば、 この後のSambaのリリースで権限が追加実装されるかもしれない。また、現在実装されて いるが、使われていないものは、管理項目として将来のリリースで削除されるかも しれないので、それらの機能を使った時の成功/失敗はSambaメーリングリスト上で報告 することは重要である。

SeAddUsersPrivilege

この権利は、net rpc user addか、 NT4 User Manager for Domainsのような ツール経由で新しいユーザーまたはグループアカウントを作成 するか否かをsmbdがユーザーに許可することを決める。

SeDiskOperatorPrivilege

この権利を所有するアカウントは、 smb.confファイル中で定義した 共有を追加/削除/変更するコマンドをrootとして 実行出来る。このようなユーザーはSambaサーバー上のファイル共有に関連 づけられているACLを変更も出来る。

SeMachineAccountPrivilege

この権利は、ユーザーがSambaが制御しているドメインにクライアント マシンを参加させることが出来るか否かを制御する。

SePrintOperatorPrivilege

この権限はsmb.confファイル中のprinter admin オプションと、それがグローバルな権利であるという(プリンター単位毎ではない) ことを除いて同じように動作する(セクション5のsmb.confマニュアルページ 参照)。結局smb.confのオプションは無効となり、プリンターへの管理者権限は このオプションと、ntprinters.tdbファイル中にある プリンターオブジェクトに対するセキュリティ記述子によって排他的に制御される。

SeRemoteShutdownPrivilege

Sambaはサーバーのシャットダウンと再起動のためと、直前に出されたシャット ダウンコマンドを中止するためののフックを提供する。この操作は通常OS によってrootユーザーにのみ制限されているので、上記のフックのどれかを使う ことができるアカウントはこの権利を持っていなければならない。

SeTakeOwnershipPrivilege

この権利はファイルとディレクトリの所有権を得る事を許可する。

Windows2000ドメインコントローラーでサポートされている権限

参照のために、Windows NT4 PDCで表示される権限は以下の通り:

         SeCreateTokenPrivilege  Create a token object
  SeAssignPrimaryTokenPrivilege  Replace a process level token
          SeLockMemoryPrivilege  Lock pages in memory
       SeIncreaseQuotaPrivilege  Increase quotas
      SeMachineAccountPrivilege  Add workstations to domain
                 SeTcbPrivilege  Act as part of the operating system
            SeSecurityPrivilege  Manage auditing and security log
       SeTakeOwnershipPrivilege  Take ownership of files or other objects
          SeLoadDriverPrivilege  Load and unload device drivers
       SeSystemProfilePrivilege  Profile system performance
          SeSystemtimePrivilege  Change the system time
SeProfileSingleProcessPrivilege  Profile single process
SeIncreaseBasePriorityPrivilege  Increase scheduling priority
      SeCreatePagefilePrivilege  Create a pagefile
     SeCreatePermanentPrivilege  Create permanent shared objects
              SeBackupPrivilege  Back up files and directories
             SeRestorePrivilege  Restore files and directories
            SeShutdownPrivilege  Shut down the system
               SeDebugPrivilege  Debug programs
               SeAuditPrivilege  Generate security audits
   SeSystemEnvironmentPrivilege  Modify firmware environment values
        SeChangeNotifyPrivilege  Bypass traverse checking
      SeRemoteShutdownPrivilege  Force shutdown from a remote system

また、Windows 200x/XP ドメインコントローラーとワークステーションでサポートされている権限は以下の通り:

         SeCreateTokenPrivilege  Create a token object
  SeAssignPrimaryTokenPrivilege  Replace a process level token
          SeLockMemoryPrivilege  Lock pages in memory
       SeIncreaseQuotaPrivilege  Increase quotas
      SeMachineAccountPrivilege  Add workstations to domain
                 SeTcbPrivilege  Act as part of the operating system
            SeSecurityPrivilege  Manage auditing and security log
       SeTakeOwnershipPrivilege  Take ownership of files or other objects
          SeLoadDriverPrivilege  Load and unload device drivers
       SeSystemProfilePrivilege  Profile system performance
          SeSystemtimePrivilege  Change the system time
SeProfileSingleProcessPrivilege  Profile single process
SeIncreaseBasePriorityPrivilege  Increase scheduling priority
      SeCreatePagefilePrivilege  Create a pagefile
     SeCreatePermanentPrivilege  Create permanent shared objects
              SeBackupPrivilege  Back up files and directories
             SeRestorePrivilege  Restore files and directories
            SeShutdownPrivilege  Shut down the system
               SeDebugPrivilege  Debug programs
               SeAuditPrivilege  Generate security audits
   SeSystemEnvironmentPrivilege  Modify firmware environment values
        SeChangeNotifyPrivilege  Bypass traverse checking
      SeRemoteShutdownPrivilege  Force shutdown from a remote system
              SeUndockPrivilege  Remove computer from docking station
           SeSyncAgentPrivilege  Synchronize directory service data
    SeEnableDelegationPrivilege  Enable computer and user accounts to
                                 be trusted for delegation
        SeManageVolumePrivilege  Perform volume maintenance tasks
         SeImpersonatePrivilege  Impersonate a client after authentication
        SeCreateGlobalPrivilege  Create global objects

SambaチームはUNIX/Linux環境で論理的に問題が無く、有用な権限のみを実装している。 Windows 200X/XPにおける権限の多くはUNIX中のものに直接相当するものは無い。

管理者のドメインSID

すべてのWindows NT4とそれ以降のサーバーはdomain Administratorアカウントを必要とすることに 注意。Sambaバージョン3.0.11以降は、割り当てられた権利と権限 (ユーザーの権利と権限を参照)経由で管理者の任務を実行する ことを許可する。サーバーのpassdbバックエンド中のアカウントは、よく知られている既定値の 管理者アカウントのRIDに設定できる。Sambaドメインコントローラー上のドメインSIDを得る ためには、以下のコマンドを実行する:

root#  net getlocalsid
SID for domain FOO is: S-1-5-21-4294955119-3368514841-2087710299

以下のように、pdbeditを使ってアカウントにドメイン管理者のRIDを 割り当てても良い:

root#  pdbedit -U S-1-5-21-4294955119-3368514841-2087710299-500 -u root -r

Note

500というRIDの値は、よく知られた既定値のAdministratorアカウントの標準値である。これは、 Windowsマシン上かドメイン上のAdministratorアカウントが持つ権利と権限を割り当てるRIDで ある。UNIX/Linux環境下では、同等なものはUID=0(rootアカウント)である。

Sambaバージョン 3.0.11以降のリリースでは、WindowsのユーザーかWindowsのグループアカウントの ために設定された権利と権限と同等のものを提供するAdministratorアカウントなしで動作させる ことが可能である。

よくあるエラー

Windowsクライアントの管理が出来る権利と権限は何か?

Windows NT4(とそれ以降)のクライアントがドメインに参加したとき、ドメイン全体での Domain Adminsグループはクライアント上のローカルな Administratorsグループのメンバーシップに追加される。ドメイン グローバルのDomain Adminsグループのメンバーであるユーザーは誰でも Windowsクライアント上で管理者の権利と権限を持つ。

これは、ユーザーがドメインサーバー上でも管理者の権利と権限を持ってしまうために、 必ずしもすべての場合において良い解決方法とは言えない。Windowsクライアント上の Power Usersグループはワークステーションのみのローカルな 管理者権限を持つ。任意のグローバルユーザーかドメイングローバルグループは、 ローカルワークステーションのPower Usersグループのメンバーに 追加できる。

ネストされたグループのサポートに、Windows ワークステーション上でのローカルグループにドメインユーザーとグループを追加する 方法の例がある。Sambaサーバーからnetを使うことで、この作業が 行える。

これを行う別の方法は、WindowsワークステーションにAdministrator としてログオンし、cmdシェルを開き、以下を実行する:

C:\>  net localgroup administrators /add domain_name\entity

ここで、entityは、ドメインユーザーかドメイングループのアカウント名である。

Chapter 16. ファイル、ディレクトリと共有のアクセス制御

John H. Terpstra

Samba Team

Jeremy Allison

Samba Team

Jelmer R. Vernooij

drawing 
The Samba Team

May 10, 2003

慣れたMicrosoft Windowsユーザーは、期待しているようにはSamba経由で共有されている、 ファイル、ディレクトリと共有リソース操作が動かないことに、しばしば当惑する。 Microsoft Windowsネットワーク管理者は、ネットワークのアクセス制御と、未認証の アクセスからリソースを保護する時に、ユーザーが必要とするアクセスを提供する方法 についてしばしば当惑している。

多くのUNIX管理者は、Microsoft Windows環境には慣れておらず、ファイルとディレクトリの アクセスパーミッションを設定しようとするMicrosoft Windowsユーザーが望むことを図式化する ことに困難が生じている。

問題は、2つの環境の間で、ファイルとディレクトリのパーミッションと制御がどのように動くかの 違いにある。この違いは、その大きな違いに橋を架けようとしても、Sambaが完全にはそれを 隠せないということにある。

POSIX ACL技術は、現在有意義な使用の例があまりないにもかかわらず、長い期間UNIX用に (拡張属性と共に)提供されてきている。これは、商用Linux製品で、ACLの適用が遅い理由 について、ある程度の説明になる。Microsoft Windows管理者にとっては、Microsoft Windows NT において10年以上も前から基本的な機能としてACLが提供されていることを鑑みると、 このことは驚くべきことである。

この章の目的は、Microsoft Windowsデスクトップユーザーに対して、最も良い環境を提供する ための、最適の方法を見つけるためにネットワーク管理者を手助けする、Samba-3で可能な、 各制御の要点を提供することである。

これは、異なったOS環境での相互運用性とデータの交換を提供するためにSambaが作成した ことを説明するのに良い機会である。SambaはMicrosoft Windowsのようなプラットフォームに UNIX/Linuxを変化させるつもりはない。その代わり、2つの環境間で、十分なレベルでデータの 交換を提供することを目的としている。現在利用可能なものは、当初の計画と希望から大きく 拡大していているが、それでもギャップは縮み続けている。

機能と利便性

Sambaはファイルシステムアクセス管理に多くの自由度を提供する。現在のSambaでは キーとなるアクセス制御機能が提供されている:

Sambaアクセス制御機能

  • UNIXのファイルとディレクトリのパーミッション

    SambaはUNIXファイルシステム制御を実装し、それを使う。Samba サーバーにアクセスするユーザーは特定のMicrosoft Windowsユーザーとして そうする。この情報はログオンか接続のセットアップ手順の一部として Sambaサーバーに渡される。Sambaはこのユーザー識別情報を、ファイル システムリソース(ファイルとディレクトリ)へのアクセス許可を与える かどうかを検証するために使う。この章では、UNIXパーミッションと 制御が少々奇妙か未知な人について、概要を提供する。

  • Sambaの共有定義

    共有の設定と制御をsmb.confファイル中で設定するとき、ネットワーク 管理者は本来のファイルシステムのパーミッションと動作を上書き設定 することが出来る。これはMicrosoft Windows NTユーザーがより期待する ような動作を引き起こすために有用かつ便利であるが、それに到達する 最も良い方法は滅多にない。基本的なオプションと テクニックはここで説明されている。

  • Sambaの共有のACL

    共有それ自身に対するACLの設定がMicrosoft Windows NTで可能なように、 Sambaでもそれは可能である。この機能を使う人は少ないが、アクセス 制御(制限)に影響を与えるために簡便な方法の一つとして残っている ことと、他の方法と比較して最小の影響でしばしばそれを行うことが できる。

  • UNIX POSIX ACLを経由したMicrosoft Windows ACL

    UNIX/Linux上でPOSIX ACLを使う場合は、ベースとなるOSがそれをサポート している場合にのみ可能である。もしもそうでない場合、このオプションは 有効ではない。現在のUNIX技術基盤ではPOSIX ACLを標準サポートしている。 このサポートを提供するLinux kernelへのパッチも存在する。残念なことに、 Linuxプラットフォームの一部のみがネイティブなACLと拡張属性を有効にして 現時点で提供を行っている。この節では、それをサポートしているプラット フォームのユーザーに対する関連情報が記述されている。

ファイルシステムのアクセス制御

おそらく、最も重要な認識される点は、UNIX OS環境で提供されているものと、Microsoft Windows NT4/200x/XP におけるフィルシステムの技術の実装が完全に異なるという単純な事実である。最初に最も 有意義な違いが何かを考え、次にその違いを乗り越えるためにSambaが何をしているかを見てみる ことにする。

Microsoft Windows NTFSとUNIXファイルシステムとの比較

SambaはUNIXファイルシステムの上で動作する。これは、UNIXファイルシステムの 取り決めとパーミッションの適用を受けることを意味する。また、もしも Microsoft Windowsネットワーク環境がファイルシステムの動作を要求するならば、 それはUNIXファイルシステムの動作とは異なり、何らかの方法でSambaは透過的かつ 一貫した方法でエミュレートを行う。

Sambaがこれをかなりの部分、それらの最上位で、既定値の動作を上書きする高度な オプションの設定を提供するという良いニュースがある。いくつかの上書きについて 説明はあるが、大部分は既定値の動作の範囲内にとどまっている。制御可能性の詳細な 点について知りたい場合は、smb.confマニュアルページを調べること。

以下では、UNIXファイルシステムの機能とMicrosoft Windows NT/200xを比較する:

名前空間

Microsoft Windows NT4/200x/XPのファイル名は254文字まで有効だが、UNIX ファイル名は1023文字まで大丈夫かもしれない。Microsoft Windows中で、 ファイルの拡張子は特定のファイルタイプを意味する。UNIXではすべての名前が 任意であると考えられるので、これは厳格には見かけない。

Microsoft Windowsがフォルダーと読んでいるものは、UNIXではディレクトリである。

大文字小文字の区別

Microsoft Windowsファイル名は8.3形式(8文字のファイル名と3文字の拡張子)の 場合、一般的に大文字である。8.3形式より長いファイル名は、大小文字を保持 するが、それは無視される。

UNIXのファイルとディレクトリ名は大文字小文字を区別し、その状態は保存 される。SambaはMicrosoft Windowsファイル名の動作を実装しているが、それは ユーザーアプリケーションとしてである。UNIXファイルシステムは大文字小文字を 無視したファイル名の検索を実行する機能は提供していない。Microsoft Windows はこれを既定値で行う。これは、UNIX OS環境で標準としては備わっていない 機能を提供するために、処理のオーバーヘッドがかかってしまうと言うことである。

以下の例を考えてみる。以下はUNIX名としては一意だが、Microsoft Windows ファイル名としては同一である:

				MYFILE.TXT
				MyFile.txt
				myfile.txt
		

明らかに、Microsoft Windowsファイルの名前空間ではこれらの3つのファイルは 同時に存在できないが、UNIXではできる。

もしも上記3つがすべて存在していたときにSambaは何をすべきか? 辞書的に最初のものがMicrosoft Windowsユーザーから見えるようにすることで ある。残りは見えず、アクセスも出来ない。それ以外の解は自殺的 行為である。Windowsクライアントは大文字小文字を区別しないファイル検索を 要求するため、大文字小文字を区別しないファイルの一覧に一致する、 複数のファイルがあるUNIXディレクトリの場合、Sambaは一貫した選択方法を 提供しなければならないということになる。

ディレクトリの区切り文字

Microsoft Windows とDOSはディレクトリの区切り文字としてバックスラッシュ \を使い、UNIXでは通常のスラッシュ/ をディレクトリの区切り文字として使う。これはSambaによって透過的に扱われる。

ドライブの識別

Microsoft Windows製品は、ディレクトリのパーティションを表現するために、 C:のようなドライブレターの概念を持つ。UNIXはファイルの パーティションに対して分離された識別子を持つという概念がない。そのような 各ファイルシステムはディレクトリツリー全体の一部としてマウントされる。 UNIXディレクトリツリーは、C:\のような、DOSの ドライブのrootを指定するような形で、/から始まる。

ファイル名に関する規則

Microsoft Windowsは一般的に先頭がドット(.)で始まる ファイル名は使わないがUNIXの場合、はユーザーのホームディレクトリ中では 当たり前のように使われている。ドット(.)で始まる ファイルは通常多くのUNIXアプリケーションの起動ファイルか、スタートアップ 設定データを含むファイルである。

リンクとショートカット

Microsoft Windowsは、実際の位置にあるファイルに対してそのファイルを実行する ためにリダイレクトを行う、特別なタイプのファイルとして振る舞う リンクとショートカットを使う。UNIXでは、ファイルと ディレクトリのリンクを使うが、それはMicrosoft Windowsユーザーが使っているもの とは全く異なる。

シンボリックリンクは、UNIX中ではデータ(ファイル又はディレクトリ)の実際の 位置を含むファイルである。(読み出しあるいは書き込みのような)操作は参照 されたファイルに対して直接行われる。シンボリックリンクは ソフトリンクとしても参照される。ハードリンクはMicrosoft Windowsではなじみのないものである。これは、1つの物理的なファイルを、複数の ファイル名で同時に参照できるようにするものである。

Microsoft Windows管理者が、UNIX/Linuxを理解するようになるプロセス中で、一時的に 若干当惑することを引き起こすかもしれな微妙な違いがある。それらは、UNIX/Linuxの トレーニングと教育の目的としての専用のテキストを見ると良い。

ディレクトリの管理

ディレクトリ操作には3つの基本的な操作がある。それは作成, 削除,改名である。 UNIXとWindowsによるディレクトリの管理 では、WindowsとUNIX中でのコマンドにおける、上記の操作の実装について比較している。

Table 16.1. UNIXとWindowsによるディレクトリの管理

動作Microsoft WindowsのコマンドUNIXのコマンド
createmd foldermkdir folder
deleterd folderrmdir folder
renamerename oldname newnamemv oldname newname

ファイルとディレクトリのアクセス制御

ネットワーク管理者は、ファイルとディレクトリのパーミッションのメンテナンスに 関連する、基本的なUNIX学習マニュアルとリファレンス資料を読むことを強く推奨する。 POSIX ACLや拡張属性(EA)のようなより複雑な機能に訴求しない基本的なUNIXの パーミッションについて多くの説明がある。

UNIX/Linuxのファイルとディレクトリアクセスパーミッションは3つの主要なデータの設定と 1つの制御の設定がある。UNIXでのファイル一覧は下記のようになる:

$ ls -la
total 632
drwxr-xr-x   13 maryo   gnomes      816 2003-05-12 22:56 .
drwxrwxr-x   37 maryo   gnomes     3800 2003-05-12 22:29 ..
dr-xr-xr-x    2 maryo   gnomes       48 2003-05-12 22:29 muchado02
drwxrwxrwx    2 maryo   gnomes       48 2003-05-12 22:29 muchado03
drw-rw-rw-    2 maryo   gnomes       48 2003-05-12 22:29 muchado04
d-w--w--w-    2 maryo   gnomes       48 2003-05-12 22:29 muchado05
dr--r--r--    2 maryo   gnomes       48 2003-05-12 22:29 muchado06
drwsrwsrwx    2 maryo   gnomes       48 2003-05-12 22:29 muchado08
----------    1 maryo   gnomes     1242 2003-05-12 22:31 mydata00.lst
--w--w--w-    1 maryo   gnomes     7754 2003-05-12 22:33 mydata02.lst
-r--r--r--    1 maryo   gnomes    21017 2003-05-12 22:32 mydata04.lst
-rw-rw-rw-    1 maryo   gnomes    41105 2003-05-12 22:32 mydata06.lst
$ 

1行の中の各項目は(左から右に)パーミッション、ファイルのハードリンク数、所有者、 グループ、サイズ(バイト)、アクセス日付、最終更新日付とファイル名である。

パーミッション欄の概要はUNIXパーミッション欄の概要 にある。

Figure 16.1. UNIXパーミッション欄の概要

UNIXパーミッション欄の概要

どのビットフラグもOFFにできる。OFFになったフラグは"できない"と同値で、 -文字で表現される(“サンプルファイル”を参照)。

Example 16.1. サンプルファイル

-rwxr-x---   意味: 
 ^^^                所有者(ユーザー)はこのファイルを読み、書き、実行できる。
    ^^^             グループに属したユーザーは読み、実行できる。
       ^^^          それ以外のユーザーはこのファイルに対して何も出来ない。

[タイプ]フィールドにはさらに別の意味もあり、それは、c = キャラクターデバイス、 b = ブロックデバイス、p = パイプデバイス、s = UNIXドメインソケットである。

文字rwxXstはユーザー、グループとその他に対して、読み出し(r)、 書き込み(w)、実行(あるいはディレクトリへのアクセス許可) (x)、ファイルが ディレクトリかすでにあるユーザーに対して実行許可を与えられた場合に実行可能(X)、 実行時にset user ID (SUID)か set group ID (SGID) (s)かスティッキー(t)である。

スティッキービットがディレクトリ上に設定された場合、そのディレクトリ内にある ファイルは、rootか所有者のみunlink(削除)か改名できる。スティッキービットがない 場合、書き込み可能なディレクトリでは、誰でもファイルの削除や改名が出来る。 スティッキービットは、誰でも書き込み可能な、/tmpのような ディレクトリでは一般的に使われる。

setuidやsetgidビットがディレクトリに設定された場合、その中に作成された ファイルは、setuidビットsetgidビットのいずれが設定されたかに応じて、ディレクトリの 所有ユーザーたはグループによって所有される。これは、あるグループに所属している すべてのユーザーがファイルの読み書きをできるようにすることが望ましく、これらの ユーザーが所属しているものと異なるプライマリグループを持つユーザーが、該当の ファイルを排他的に所有してしまうことが望ましくないようなディレクトリの パーミッションを設定する際に有効なことがあろう。

ディレクトリがd-wx--x---に設定された時、所有者はその中の ファイルを読んだり作成(書き込み)出来るが、読み出し(r)フラグが設定されていない ので、だれも、ファイルの一覧を表示(見る)事が出来ない。グループに属するユーザーは そのディレクトリ中のファイルを読めるが新しいファイルは作成できない。もしも、 ディレクトリ中のファイルがグループに対して読み書き可能なように設定された場合、 グループメンバーはそれらに書き込み(または削除)ができる。

ディレクトリとファイルの削除操作からの保護

どのように、ユーザーの削除操作から、ファイルやディレクトリを保護したらよいか、 という事についてSambaメーリングリストに質問が来ることがある。例えば、Windows NT/2K/XP は、ディレクトリ配下に、ファイルを書くことは出来るが削除できないというアクセス制御を 設定する機能がある。これは、ファイルに書き込みは出来るが、削除は出来ないというACLを Windows上で設定することで可能になる。このような考え方はUNIX OSファイル空間ではない。 UNIXファイルシステムでは、ファイルを作成出来るユーザーはファイルに書き込みが出来る。 ファイルがあるディレクトリへの書き込み権があり、ファイルへの書き込み権があるユーザーは それを削除できてしまう。

確認ではあるが、UNIX環境では、ファイルの削除はそのファイルがいるディレクトリの パーミッションによって制御される。別の言い方をすると、対象となるファイルの 所有者ではなくても、書き込み権があるユーザーは、ディレクトリ中のファイルを 削除できる。

必要に応じて、SambaはホストOSのファイルシステムの構造を受け取る。Sambaは Windows ACLを有効にすることについてと"最も最適な"POSIX ACLへの変換実行に ついては、ファイルシステムの能力に制限される。いくつかのUNIXファイルシステム では、拡張属性と呼ばれている機能をサポートしている。Windowsでの 継承という概念のみ、適切な拡張属性を使ってSambaは 実装している。

拡張属性の特定の動作は、UNIXと例えばLinuxのようなUNIX風のシステム全体には 一貫していない。例えば、ディレクトリやファイルを削除操作から防ぐためのフラグを セットすることは、拡張属性の特定の実装では可能である。これを達成する拡張属性は immutableビットと呼ばれている。残念なことに、immutable フラグの実装は公開された文書とは一致していない。たとえば、SuSE Linux 9.2上の chattrのマニュアルには:

A file with the i attribute cannot be modified: it cannot be deleted
or renamed, no link can be created to this file and no data can be
written to the file. Only the superuser or a process possessing the
CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
(訳: i 属性を持つファイルは変更できない:削除も改名もこのファイルへの
リンク作成も出来ないし、このファイルへの書き込みも出来ない。スーパー
ユーザーかCAP_LINUX_IMMUTABLE機能を所有するプロセスがこの属性を設定
および削除できる)。

immutable フラグが、Sambaが動いているファイルシステム上でサポートされているか、 簡単なテストは以下のように出来る。

Procedure 16.1. ファイルの Immutibilityサポートのテスト

  1. filenameという名前のファイルを作成。

  2. rootユーザーとしてログインし、以下のようにimmutibileフラグをテストファイルに設定:

    root#  chattr +i `filename'
    

  3. ファイルを所有しているユーザー(非root)でログインし、以下のようにしてファイル削除を試みてみる:

    mystic:/home/hannibal > rm filename
    

    immutableが正しく効いているならばファイル削除は出来なくなっている。

immutable bitをサポートしているファイルシステムがあるOS上では、ディレクトリを 作成できるが削除できないようにするのは可能である。immutableディレクトリが書き込み 可能かどうかを、そのホストシステム上のマニュアルページでチェックすること。 もしも出来なければ、ディレクトリ全体とその内容は、書き込み(ファイル作成も)と 削除から効果的に保護される。

共有のアクセス制御の定義

smb.confセクション中の以下のパラメーターは、共有の制御かアクセス制御の設定を 定義する。以下のオプションのどれかを使う前に、smb.confのマニュアルページを 参照のこと。

ユーザーとグループベースの制御

ユーザーとグループベースの制御はとても便利なことがわかっている。ある特定の状態に おいては、単一のユーザーが行うような形で、すべてのファイルシステムへの操作を強制する ことはとても望ましいことがある。force userforce groupの動作を使うとこれを行う事ができる。 他の状態においては、特定の認証された人のみが共有またはその内容にアクセス出来る ようにさせるような、偏執的なレベルの制御を使うことが必要かもしれない。これには、 valid usersinvalid users パラメーターが便利である。

いつものように、管理するためと、アクセスを制御する方法の不明確な点を最小化する、 一番簡単な方法を使うことを特に推奨する。覚えていてほしいが、状態をそのまま残すと、 他の誰かが手助けを提供する必要があり、もしもだれかが、あまりにも大きな混乱状態 を見つけるか、何をしていたかが理解できない場合、Sambaが削除され、別の解が適用 されてしまうと言う危険性が出てくる。

ユーザーとグループベースの制御は上記の制御について列挙している。

Table 16.2. ユーザーとグループベースの制御

制御パラメーター説明、動作、備考
admin users

共有に対して管理者権限を許可するユーザーの一覧。そのユーザーは スーパーユーザー(root)と同様すべてのファイル操作ができる。 この一覧中のユーザーは共有上でファイルのパーミッションに関わらず 何でも出来る。

force group

このサービスに接続するすべてのユーザーに既定値のプライマリグループ として割り当てるUNIXのグループ名を指定する。

force user

このサービスに接続するすべてのユーザーに既定値のユーザーとして 割り当てるUNIXのユーザー名を指定する。 これは、ファイルの共有に便利である。間違って使うとセキュリティ 上の問題が発生する。

guest ok

もしもパラメーターがサービスに対して接続されたならば、サービスに 接続する時にパスワードが不要になる。権限は guestアカウントになる。

invalid users

このサービスにログイン出来ないユーザーのリスト。

only user

接続を許可しないユーザー名の一覧。

read list

サービスに対してリードオンリアクセスを許可するユーザーの一覧。 この一覧中のユーザーはリードオンリオプションがどのように設定 されていても、書き込み権はない。

username

詳細はsmb.confマニュアルページを参照。これは複雑で潜在的に 間違って使われるパラメーターである。

valid users

サービスにログイン出来るユーザーの一覧。

write list

サービスに読み書き可能なアクセスが出来るユーザーの一覧。


ファイルとディレクトリに対するパーミッションベースの制御

ディレクトリパーミッションベースの制御は、間違って使った場合、間違った設定の 原因を診断するのにかなりの困難が生じる。控えめに、そして厳重に使うこと。 徐々に、1つずつ、おのおのを導入すると、好ましくない副作用が見つかるかもしれない。 問題発生時には、いつでもそれらをコメントアウトし、徐々に様子を見ながらそれらを 元に戻していく。

ファイルとディレクトリパーミッションベースのアクセス制御を使うためのパラメーターに 関連する情報は、 ファイルとディレクトリパーミッションベースの制御 を参照のこと。

Table 16.3. ファイルとディレクトリパーミッションベースの制御

制御パラメーター説明、動作、備考
create mask

smb.confマニュアルページを参照のこと

directory mask

UNIXディレクトリを作成する時に、DOSのモードをUNIXのモードに 変換する時に使う8進のモード値。directory security maskも参照。

dos filemode

このパラメーターを有効にすると、ファイルに書き込み権があるユーザーに そのパーミッションの変更を許可する。

force create mode

このパラメーターは、Sambaによって作成されたファイル上に常時設定 されるUNIXモードのビット単位のパーミッションを指定する。

force directory mode

このパラメーターは、Sambaによって作成されたディレクトリ上に常時設定 されるUNIXモードのビット単位のパーミッションを指定する。

force directory security mode

Windows NTクライアントがディレクトリ上のUNIXパーミッションを操作 する時に変更されるUNIXパーミッションビットを制御する。

force security mode

Windows NTクライアントがUNIXパーミッションを操作する時に変更 されるUNIXパーミッションビットを制御する。

hide unreadable

読めないファイルを、クライアントから見えなくする。

hide unwriteable files

書き込めないファイルをクライアントから見えなくする。書き込めない ディレクトリは通常通り見える。

nt acl support

このパラメーターはsmbdがUNIXパーミッションをWindows NT ACLにマップ するかどうかを制御する。

security mask

Windows NTクライアントがファイル上のUNIXパーミッションを操作する 時に変更されるUNIXパーミッションビットを制御する。


その他の制御

他の制御中に記載があるパラメーターはファイルアクセスへの 不注意によるバリアを作成する方向で、管理者によってしばしば使われる。それらは、 smb.confのファイル設定の完全な影響がわからない結果である。 The parameters documented in Other Controls are often used by administrators in ways that create inadvertent barriers to file access. Such are the consequences of not understanding the full implications of smb.conf file settings.

Table 16.4. 他の制御

制御パラメーター説明、動作、備考
case sensitive, default case, short preserve case

これは、すべてのファイル名検索を大文字小文字を意識した形で行う 事を意味する。Microsoft Windowsくらい亜入おから受け取った正確な 名前で、ファイルはSambaによって作成される。

csc policy

クライアントサイトのキャッシングポリシーは、Microsoft Windowsの クライアントサイドのファイルキャッシング機能に類似している。

dont descend

常時空白としてサーバーが見せる、カンマで分離されたディレクトリ一覧を指定する。

dos filetime resolution

このオプションは、Samba共有に対して、主にVisual C++との互換オプションとして使われる。

dos filetimes

ファイルに書き込みが出来るときにDOSとWindowsは、ユーザーにファイルの 時刻変更を許可する。POSIXでの流儀ではこれは出来ない。このオプションは DOSとWindowsの流儀を許可する。

fake oplocks

Oplocksは、SMBクライアントがサーバーから、ファイル操作をローカルに キャッシュする許可を得る方法である。もしもサーバーがoplockを許可 すると、クライアントは、ファイルへのアクセスが唯一であると仮定 することから自由になり、ファイルのデータをより頻繁にキャッシュする。

hide dot files, hide files, veto files

注意:Microsoft Windowsエクスプローラーはhiddenが設定されたファイルの 状態を無視するので、結局それは見えてしまう。

read only

このパラメーターがyesの場合、サービスのユーザーはサービスのディレクトリ 中のファイルを作成又は変更できない。

veto files

見えないか、アクセスできないファイルとディレクトリの一覧。


共有のアクセス制御

この節では、Sambaの共有単位でのアクセス制御における制限の設定方法について取り 扱う。既定値では、Sambaは共有自身には何らの制限も設定しない。共有自身への 制限は、Microsoft Windows NT4/200x/XP共有上で設定出来る。これは、共有に 接続する人を効果的に制限できる方法である。特定の制限がない場合、既定値の 設定はグローバルユーザーに対してEveryone - フルコントロール (フルコントロール、変更と読み出し)である。

現時点ではSambaは共有上のアクセス制御の設定を行うためのツールを提供していない。 それらの設定を作成する唯一の方法は、NT4のサーバーマネージャか Windows 200xの、コンピュータの管理のための、Microsoftマネジメントコンソール (MMC)を使うことである。Sambaのコマンドラインツールでこの機能を提供することは 現時点では予定されていない。

Sambaはshare_info.tdbというファイル中に共有単位のアクセス 制御の設定を格納する。サーバー上にこのファイルがある場所は、Sambaがコンパイル された状態に依存する。Sambaのtdbファイルがある既定値の位置は、 /usr/local/samba/var配下である。もしもtdbdump ユーティリティがコンパイルされシステム中にインストールされているならば、 tdbファイルがあるディレクトリ中でtdbdump share_info.tdbを 実行する事によってこのファイルの内容を検査することが出来る。

共有のパーミッションの管理

共有のパーミッションの管理を行うための最適のツールはプラットフォーム 依存である。環境に応じて最適のツールを選択されたい。

Windows NT4 Workstation/Server

Windows NT4 ワークステーションかサーバーからSambaサーバー上の 共有のパーミッションを管理するのに必要なツールは、 NT サーバーマネージャである。サーバーマネージャはWindows NT4 サーバー製品とともに出荷されているが、Windows NT4ワークステーション には付いていない。Microsoft Windows NT4 ワークステーション 用のNT サーバーマネージャは、MicrosoftのWebサイト support から入手できる(訳注:日本語版は こちらから)。

Procedure 16.2. 手順

  1. NT4 サーバーマネージャを起動し、管理 したいSambaサーバーをクリックする。メニューから コンピュータを選択し、 共有ディレクトリをクリックする。

  2. 管理したい共有をクリックし、次にプロパティ タブをクリックし、パーミッションタブを クリックする。これで、アクセス制御を追加/変更できるようになる。

Windows 200x/XP

Microsoft Windows NT4/200x/XP上では、 共有のACLはMicrosoftエクスプローラーのようなツールで設定する。 たとえば、Windows 200xでは、共有フォルダーを右クリックし、次に、 共有を選択し、次に パーミッションをクリックする。 Windows NT4/200xでの既定値のパーミッションはグループ "Everyone"が共有に対してフルコントロールを持つようになっている。

Microsoft Windows 200xとそれ以降のバージョンでは、MMCに対して コンピュータの管理スナップインと 呼ばれるツールが提供されている。このツールは、 コントロールパネル->管理ツール->コンピュータの管理 経由でアクセス出来る。

Procedure 16.3. 手順

  1. MMCのコンピュータマネジメントスナップインを起動後、メニュー項目 操作(A)をクリックし、 別のコンピュータに接続(C)を選択する。もしも、 ドメインにログオンしていない場合、ドメインログオンユーザー名と パスワードを聞いてくるので入力する。それでドメインの認証を行う。 もしも管理者権限でログインしているならば、このステップは省略される。

  2. もしも、Sambaサーバーがコンピュータを選択 ボックス中に表示されていないならば、Name: フィールド中に対象のSambaサーバーの名前を入力する。次に システムツールのそばにある [+]をクリックし、左パネル中の 共有フォルダーのそばにある [+]をクリックする。

  3. 右パネル中でアクセス制御のパーミッションを設定したい共有上で 右クリックする。次に、共有のパーミッション を右クリックする。これで、小浮遊フォルダーにアクセス制御 エンティティを追加できる。各エントリに割り当てたいアクセスの タイプ(フルコントロール、変更、読み込み)を覚えておくこと。

Warning

注意深く作業する必要がある。このユーザーを削除しないで Everyoneユーザーからすべてのパーミッションを 取り去ると、この共有に対しては誰もアクセス出来なくなる。これは ACLの優先順位として知られていることの結果である。Everyoneに 対してアクセス権なしということは、 Everyoneのグループに属している MaryKというユーザーは、明示的な、フルアクセス の権利を与えられたとしても、アクセスできない。

Microsoft Windowsのアクセス制御リストとUNIXとの相互運用性

NTセキュリティダイアログを使用したUNIXパーミッションの管理

Windows NTクライアントは、基盤となるUNIXパーミッションを表示したり変更 するための、ネイティブなセキュリティ設定ダイアログボックスを使うことが できる。

この機能は、Sambaが動作しているUNIXホストのセキュリティを危うくしない ように留意し、かつ、Samba管理者が設定出来るすべてのファイル パーミッションルールに依然として従う。

SambaはPOSIX ACLの範囲内で動くので、種々の、Windowsで提供されている よりきめ細かいアクセス制御は実際の所無視される。

Note

Samba経由での、UNIX/LinuxシステムファイルへのすべてのアクセスはOSの ファイルアクセス制御によって制御される。ファイルアクセスの問題を理解 しようとする時、Sambaによってファイルアクセスを行う時に提供されるWindows ユーザーの識別子を見つけることはきわめて重要である。これは、Sambaのログ ファイルから見つけるのが最も良い。

Samba共有上でのファイルセキュリティの表示

NT4/200x/XPクライアントからSambaでマウントしたドライブレターかUNCパス 中のファイルかディレクトリのどれかを右クリックする。メニューがポップ アップするのでメニューの最下部にあるプロパティ エントリをクリックする。この動作でファイルのプロパティ ダイアログボックスが上がってくる。セキュリティタブを クリックすると3つのボタンが表示される:アクセス許可監査所有者である。 監査ボタンは、ユーザーがNTの管理者でない場合、 "要求された権限をクライアントが持っていません(A requested privilege is not held by the client)" というエラーメッセージを表示するか、ユーザーがNT管理者としてログオンしている 場合、ファイルに対する監査要求を追加するために、管理者に許可を行う ダイアログを表示する。このダイアログは現時点ではSamba共有には機能しない ので、唯一使えるボタンである 追加ボタンは、 表示されているユーザーの一覧を現時点では許可出来ない。

ファイルの所有者の表示

所有者ボタンをクリックすると、ダイアログボックスが 表示され、そのファイルの所有者を表示する。所有者は以下のように表示される:

		SERVER\user (長い名前)
		

ここでSERVERはSambaサーバーのNetBIOS名である。 userはこのファイルを所有しているUNIXユーザー のユーザー名であり、(長い名前)はユーザーを識別 するための説明文字列である(通常はUNIXパスワードデータベースのGECOS フィールドが使われる)。閉じるボタンをクリック して、このダイアログを閉じる。

もしもnt acl supportパラメーターが falseに設定されているならば、ファイルの所有者は NTユーザーのEveryoneとして表示される。

所有権の取得ボタンでは異動したい先の人がこの ファイルの所有権を取得することは出来ない(それをクリックすると、現在 NTクライアントにログオンしているユーザーが見つからないということを通知する ダイアログボックスが表示される)。この理由は、ファイルの所有者の変更は、 UNIX上では特権操作であり、rootユーザーにのみ許可されて いるからである。このボタンをクリックすると、NTに対してNTクライアントに ログオンしている現在のユーザーにファイルの所有者を変更するようにNTに指示 するが、これは現時点ではSambaでは動作しない。

NTにあるchownコマンドはSambaでも動作し、rootとして Sambaサーバーに接続している管理者権限を持つユーザーに、ローカルのNTFSファイル システムとリモートマウントしたNTFSかSambaドライブの両方のファイルの所有者 の変更を許可する。これは、Sambaチームの一員であるJeremy Allisonによって 書かれたNTセキュリティライブラリであるSeclibの 一部として提供されていて、これはSambaのFTPサイトからダウンロードできる。

ファイルとディレクトリのパーミッションの表示

3番目のボタンはアクセス許可である。これをクリックすると、 パーミッションとファイルかディレクトリのUNIXでの所有者の両方を表示する ダイアログボックスが起動する。所有者は以下のように表示される:

SERVER\ user (長い名前)

SERVERはSambaサーバーのNetBIOS名であり、 userはファイルを所有しているUNIXユーザーの ユーザー名であり、(長い名前)は、ユーザーを識別 する説明文字列である(通常はUNIXパスワードデータベースのGECOSフィールドが 使われる)。

もしもnt acl supportパラメーターが falseに設定されている場合、ファイルの所有者は EveryoneというNTユーザーとして表示され、パーミッション はNTのフルコントロールとして表示される。

パーミッション欄はファイルとディレクトリでは異なって表示される。詳細は次項で説明する。

ファイルのパーミッション

標準のUNIXユーザー/グループ/その他の三つ組みと、それに対応する 読み、書き、実行パーミッションの三つ組みは、Sambaによって r, w, と xビットが対応するNT パーミッションにマップされる、NT ACLのパーミッションの3つの要素にマップされる。 UNIXの「その他」パーミッションは、UNIXの世界で許可されるパーミッションのリストを 伴ってグローバルNTグループのEveryoneにマップされる。 UNIXの所有者とグループパーミッションは、それぞれUNIXのユーザーとグループに 許可されるパーミッションのリストを伴って、NTのユーザーアイコンと NTのローカルグループアイコンとして表示される。

多くのUNIXパーミッションのセットが、たとえば読み込み変更, あるいは フルコントロール のような共通のNTの名前にマップしないという理由で、通常パーミッションは NTの表示リスト中で特殊なアクセス許可という単語が 前に付く。

しかし、もしもファイルに、特定のUNIXユーザー、グループ、その他に対して何も 許可しないパーミッションが付いているとどうなるだろうか? アクセス権なしを見えるように、かつ変更できるように するため、Sambaは所有権の取得というNTのACL属性を 上書きし(UNIXでは何の意味もない)、NTのOビットを設定 して、アクセス権なしというコンポーネントを報告する。これはもちろん、 それを0のようにするために選ばれ、結局アクセス権なしの意味になる。 この動作の背景にある結論についての詳細は、以下に記述がある。

ディレクトリのパーミッション

NT NTFSファイルシステム上のディレクトリは、2つの異なったパーミッションの 組を持っている。最初の組は、通常のRW NT形式中での 最初の括弧の組中に表示される、ディレクトリそれ自身上のACLセットである。 このパーミッションの最初の組は通常のファイルのパーミッションに対して、 上記で説明があったようなのと正確に同じ方式で、Sambaによって作成され、 同じ方法で表示される。

2番目のディレクトリパーミッションの組はUNIXパーミッションの世界では実際の 意味を持たず、このディレクトリが継承する範囲内で作成された任意のファイルの 継承されたパーミッションを表す。

SambaはNT用にそれら継承されたパーミッションをまとめ、NT ACLとして返すので、 Sambaによって新しく作成されたこの共有のUNIXパーミッションモードを 受け取れる。

ファイルまたはディレクトリのパーミッションの変更

ファイルとディレクトリのパーミッションの変更はダイアログボックス中に表示された パーミッションの変更と同じくらい簡単で、OKをクリック すればよい。しかし、ユーザーが認識する必要がある制限があり、また、Samba標準の パーミッションマスクと注意を払わなければならない事も必要なDOS属性のマッピング も相互に影響する。

もしも、nt acl supportパラメーターがfalse ならば、"アクセスが拒否されました"というメッセージが 出力されて、セキュリティパーミッションを設定することは失敗する。

最初に注意することは、追加ボタンはSamba中のユーザーの一覧を 返さない事である("リモートプロ子ジャーコールは失敗し、実行出来ませんでした" というエラーメッセージが表示される)。これは、ダイアログボックス中に一覧表示されて いる、現在のユーザー/グループ/その他 のパーミッションのみを操作できると言うことで ある。これらはUNIXが実際に持っているパーミッションのみなので、これは実際にちゃん と動く。

もしもパーミッションの三つ組み(ユーザー、グループかその他のどれか)がNTダイアログ ボックス中でパーミッションのリストから削除されたならば、OK ボタンが押されたとき、UNIXサイド上ではパーミッションなし 状態になる。もしもサイドパーミッションを表示させると、NTのO フラグとして、上記で説明したようにパーミッションなしが表示 される。これはパーミッションの三つ組から取り去ったものをファイルかディレクトリに もういちど戻すためにパーミッションを追加できるようにする。

UNIXはNT ACLのr, w, と xビットのみを サポートするため、もしも、削除のような他のセキュリティ属性が 選択された場合、Sambaサーバー上に適用するときには無視される。

ディレクトリにパーミッションを設定する場合、2番目のパーミッションの組(括弧の組の 二番目)は既定値でディレクトリ中のすべてのファイルに適用される。もしも、これが やりたいことではない場合、NTダイアログボックス中の Replace permissions on existing filesチェックボックスの チェックを、OKボタンを押す前に外さなければならない。

もしもすべてのパーミッションを、ユーザー/グループ/その他から取り去りたい場合、 コンポーネントをハイライトさせ、削除ボタンをクリック するか、特別な所有権の取得パーミッション(Oとして表示される)のみををハイライトさせてもよい。

標準的なSambaのcreate maskパラメーターとの相互作用

標準的なSambaのcreate maskパラメーターとの相互作用を制御する4つのパラメーターがある:

ユーザーがパーミッションを適用するためにOKをクリックした 時、Sambaは与えられたパーミッションを、ユーザー/グループ/その他のr/w/x三つ組 にマップし、次にsecurity maskパラメーター中で設定された ビットに対し、ファイルに対して変更されたパーミッションを検査する。このパラメーター 中で1に設定されていない変更されたすべてのビットは、ファイル パーミッション中でそのまま残る。

本質的に、security mask中のゼロビットは、ユーザーが 変更を許可しないビットの組として、1のビットは変更を認めるビットとして扱っても よい。

もしも明示的に設定されていない場合、このパラメーターは既定値として create maskパラメーターと同じ値になる。ユーザーにファイル 上のすべてのユーザー/グループ/その他 のパーミッションの設定変更を許可したいならば、 この値を0777にする。

次にSambaは、force security modeパラメート中で設定された ビットに対して、ファイルのパーミッションの変更点をチェックする。このパラメーター 中で1に設定されたものに対応する、変更された任意のビットは、 強制的にセットされる。

基本的に、force security modeパラメーター中でビットを設定 することは、ファイル上のセキュリティを変更する時、ユーザーが常時on に設定するとして、ビットのまとまりを扱っても良い。

もしも、明示的に設定されない場合、このパラメーターの既定値は、 force create modeパラメーターでの値と同じになる。 何の制限もなしにすべてのユーザー/グループ/その他のパーミッションの変更を許可したい ならば、このパラメーターを000に設定する。 security maskforce security mode パラメーターはその順で、変更要求のために適用される。

ディレクトリには、security maskの代わりに directory security maskを、 force security modeの代わりに force directory security modeパラメーターを使う点を除いて、 上記で説明したファイルへの操作と同じ動作をSambaは実行する。

directory security maskパラメーターの既定値は、 directory maskパラメーターと同じ値に設定され、 force directory security modeパラメーターの既定値は、 force directory modeパラメーターと同じ値に設定される。 この方法で、その制限内で引き続きパーミッションビットをユーザーに変更許可する 間、Samba共有上で管理者が設定出来るパーミッションの制限を実施する。

もしも、ファイルとディレクトリ上でパーミッションビットを変更する フルコントロール権をユーザーに許可するように、かつ、強制的に特定のビットを onに設定しない、共有を設定したいならば、 smb.confファイル中の共有固有のセクションに、以下のパラメーターを記述する:

security mask = 0777
force security mode = 0
directory security mask = 0777
force directory security mode = 0

標準Sambaファイル属性のマッピングの相互関係

Note

Sambaは(read-onlyのような)DOS属性の一部をファイルのUNIX パーミッションにマップする。これは、セキュリティダイアログ経由での パーミッションビットの設定とファイル属性マッピングによって設定されるビットとの の間に競合が生じることがでてくる。

もしも、ファイルが所有者に対して読み込み権がない場合、これは標準ファイル属性 タブダイアログ中で読み取り専用として表示される。都合の悪いことに、 このダイアログは、他のタブ中にあるセキュリティ情報を含むものと同じである。

これができる事が意味するものは、もしも所有者がセキュリティダイアログを使って 自分自身に読み込みを許可するためにパーミッションを修正するならば、 標準セキュリティダイアログに戻るためにOKをクリックし、 次にNTはファイルのパーミッションを読み取りのみに戻す(ダイアログ中では引き続き 表示される属性)。これは、パーミッション設定後、属性ダイアログに戻るために OKをクリックした後、変更を書き戻さないようにするため、 OKの代わりにキャンセルをクリック する事を意味する。

Windows NT/200X ACLとPOSIX ACLの制限

Windowsの管理者は簡単なACL制御になれていて、通常UNIXのユーザー/グループ/その他(ugo) のパーミッションは不十分で十分にきめ細かくないと考えている。

競合しているSMBの実装は、Windows ACLをどのように取り扱うかについて異なる。Sambaは Windows ACLを、UNIXのファイルシステム管理の構造で取り扱い、そのため、POSIX ACLの 制限が適用される。そのため、Windows NT/200X ACLの機能が POSIX ACLには欠如している ので、POSIX ACLのセマンティックスと制限は、Windows管理者に課される。

POSIX ACLはUNIX管理者におもしろい難問を提供し、そのため、Windows ACL管理に適用 するために妥協を強いる。POSIX ACLは公式の標準としては適用されていない。という よりは、最終の標準は、draft standard 1003.1e revision 17である。これが、Samba が実装しているPOSIX文書である。

UNIXベンダは別々の流儀でPOSIX ACLを実装している。ACLをサポートしている数多くの Linuxファイルシステムがある。Sambaは数多くのPOSIX ACLの実装間のすべての違いを 透過的にする仕組みを提供する必要がある。SambaにおけるACLサポートのプレッシャー は、UNIXの世界でのACLサポートの標準化への圧力を顕著に増大する。

SambaはUNIXファイルシステムで実装されているPOSIX ACLが予想していない、 継承を実装しているWindows ACLという難問を取り扱う 複雑な事項を扱う必要がある。Sambaは通常のugoとACL機能を上書きすることが出来る masksのサポートを提供する。これは、WindowsのACLが 実装しなければならない方法を更に複雑にする。

UNIX POSIX ACLの概要

POSIX ACLを調べる際に、ファイルとディレクトリ両方に対して操作する方法を 考えておかなければならない。ファイルのACLは以下の意味を持つ:

# file: testfile      <-- ファイル名
# owner: jeremy       <-- ファイルの所有者
# group: users        <-- POSIXグループの所有者
user::rwx             <-- ファイルの所有者に対する許可 (user)
user:tpot:r-x         <-- 追加のユーザーに対する許可 `tpot'
group::r--            <-- ファイルグループの所有者に対する許可 (group)
group:engrs:r--       <-- 追加のグループに対する許可 `engineers'
mask:rwx              <-- グループに対して'論理積'を取る時のマスク値
other::---            <-- その他に対する許可 (other)

ディレクトリのACLは以下の意味を持つ:

# file: testdir       <-- ディレクトリ名
# owner: jeremy       <-- ディレクトリの所有者
# group: jeremy       <-- POSIXグループの所有者
user::rwx             <-- 所有者に対するディレクトリの許可 (user)
group::rwx            <-- 周遊するグループに対するディレクトリの許可 (group)
mask::rwx             <-- グループに対して'論理積'を取る時のマスク値
other:r-x             <-- その他に対する許可 (other)
default:user::rwx     <-- 継承された所有者に対する許可
default:user:tpot:rwx <-- 継承されたあるユーザーに対する許可 `tpot'
default:group::r-x    <-- 継承されたグループに対する許可
default:mask:rwx      <-- 継承された既定値のマスク
default:other:---     <-- 継承されたその他に対するパーミッション (other)

Windowsのファイル ACLsからUNIX POSIX ACLへのマッピング

Microsoft Windows NT4/200XのACLはPOSIX ACLに当然マップされねばならない。 ファイルパーミッションのマッピングは、 WindowsのファイルACLをUNIX POSIXファイルACLにマップする方法 で示されている。文字#は、Windows管理者がファイルにフルコントロール フラグをセットする時のみこのフラグがセットされる事を意味する。

Table 16.5. WindowsのファイルACLをUNIX POSIXファイルACLにマップする方法

WindowsのACEファイル属性フラグ

フルコントロール

#

フォルダーのスキャン/ファイルの実行

x

フォルダーの一覧/データの読み取り

r

属性の読み取り

r

拡張属性の読み取り

r

ファイルの作成/データの書き込み

w

フォルダーの作成/データの追加

w

属性の書き込み

w

拡張属性の書き込み

w

サブフォルダーとファイルの削除

w

削除

#

アクセス許可の読み取り

all

アクセス許可の変更

#

所有権の取得

#


マッピングテーブルを見てわかるように、1対1でマッピングされるものは1つもなく、 そのため、Sambaは、Windowsに、管理者によって意図されるおおよその方向に操作 させる、論理的なマッピングをしなければならない。

一般的に、UNIX POSIXのユーザー/グループ/その他のパーミッションのマッピングは Windows ACLにマップされる。これは、POSIX ACLの作成に優先する。POSIX ACLは ファイルかディレクトリを所有しているユーザーとグループ以外のユーザーとグループの ためのアクセス制御を行うために必要である。

UNIX管理者はUNIX環境下で任意のディレクトリパーミッションを設定出来る。 Windows管理者はファイルの所有者に対して読み取り許可を削除するために、Windows エクスプローラーで行う事が出来ないというように、より制限されている。

WindowsのディレクトリACLs の UNIX POSIX ACLへのマッピング

UNIX POSIXのディレクトリパーミッションとUNIX POSIXのACLを、Windowsのディレクトリ ACLにマップされる、Windows ACEにマッピングする時に、おもしろいことが起きる (アクセスコントロールエントリ(ACE)はACLの個々の要素である)。

ファイルパーミッションの時に説明したのと全く同じように、ディレクトリ パーミッション機能するが、いくつか注意しなければならない例外と、 ディレクトリパーミッションを準備する時に、抜け目のない管理者が注意を払う2、3の 特色がある。

よくあるエラー

ファイル、ディレクトリと共有アクセスの問題はメーリングリスト上での共通の話題である。 以下は最近メーリングリストで話題になった例である。

Publicな共有にユーザーが書き込めない

以下の不満はSambaメーリングリスト上でしばしば聞かれる: ファイルとディレクトリのパーミッションに関していくつかの問題に直面している。 ドメインにadmin user(root)としてログイン出来、ファイルを作成/変更するための パーミッションを、誰でも持つ必要があるPublicな共有があるが、rootしかファイルを 変更できず、それ以外の人は出来ない。結局常時サーバーの所に行って、 chgrp -R users *chown -R nobody * を実行し、他のユーザーに対してファイルに対して変更が出来るようにしなければならない。

この問題を解決できる1つの方法がある:

  1. 共有されているディレクトリの最上位に移動する。

  2. 好みのpublicなユーザーとグループに所有者を設定する

    $ find `directory_name' -type d -exec chown user:group {}\;
    $ find `directory_name' -type d -exec chmod 2775 {}\;
    $ find `directory_name' -type f -exec chmod 0775 {}\;
    $ find `directory_name' -type f -exec chown user:group {}\;
    

    Note

    上記はすべてのディレクトリにSGID ビットを 設定する。これが何をするかはUNIX/Linuxのマニュアルページを読む こと。これにより、ディレクトリ中に作成されるすべてのファイルと ディレクトリツリーは現在のユーザーと、ディレクトリ作成時に所有する グループによって所有される。

  3. ディレクトリが/foodbarだとする:

    $ chown jack:engr /foodbar
    

    Note

    これは以下と同じである:

    $ chown jack /foodbar
    $ chgrp engr /foodbar
    
  4. 以下のようにタイプする:

    $ chmod 2775 /foodbar
    $ ls -al /foodbar/..
    

    以下が表示される:

    drwxrwsr-x  2 jack  engr    48 2003-02-04 09:55 foodbar
    

  5. 以下のようにタイプする:

    $ su - jill
    $ cd /foodbar
    $ touch Afile
    $ ls -al
    

    AfileがJillによって作成されて、所有権を持っている ことを確認し、以下のようにJackが許可されていることを確認する: and permissions of Jack, as follows:

    -rw-r--r--  1 jill  engr     0 2007-01-18 19:41 Afile
    

  6. もしも、ディレクトリに書き込みパーミッションを持たねばならないユーザーが グループengrのメンバーでないならば、smb.conf中の 共有のエントリを以下のようにする:

    force group = engr

force userセットでrootとしてファイル操作が完了する

admin users中にユーザーがある時、 force userが設定されていたとしても、 Sambaは常時このユーザーに対してファイル操作をrootとして行う。

SambaでMicrosoft Wordを使うとファイルの所有者が変更される

質問:Aが所有者のword文書をBがセーブする。 更新したファイルは所有者がBになる。なぜSambaはこのようにするのか? どうやったら修復できる?

答え:Wordは、Wordの文書を修正/変更した時に以下の 作業を行う:Microsoft Wordは一時的な名前で新しい文書を作成する。Wordは 次に古い文書をクローズしてそれを削除し、新しい文書をオリジナルの文書 の名前に改名する。Sambaが、新しい文書がオリジナルの文書の所有者によって 所有すべきであるということを知るための機構はない。SambaはMicrosoft Word によってファイルが改名されたことを知るすべはない。Sambaが告げることが 出来る限りのことは、作成されるファイルは新しいファイルであり、 アプリケーション(Word)が更新しているものではない、ということである。

パーミッション問題を解決するための回避方法がある。これは、smb.conf ファイル中からファイルシステムの動作を管理できる方法についての理解と、 同様に、UNIXファイルシステムの動作について理解することを深める。 Word文書を変更するディレクトリにchmod g+s `directory_name' を設定する。これは、生成されるすべてのファイルはディレクトリを所有している グループになるようにする。 smb.conf中の共有定義セクションを以下のように 設定する。

force create mode = 0660
force directory mode = 0770

これらの2つの設定は、共有中で作成される、すべてのディレクトリとファイルが ディレクトリそれ自身上に設定された所有者とグループによって読み書きができる ようにする。

Chapter 17. ファイルとレコードのロッキング

Jeremy Allison

Samba Team

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Eric Roseme

HP Oplocks Usage Recommendations Whitepaper

多くのネットワーク管理者に問題を発生させる1つの領域はロッキングである。 問題の範囲はインターネット上で検索することですぐにはっきりする。

機能と利便性

Sambaは、Microsoft Windows NT4/200xサーバーも提供する、Microsoft Windowsクライアントが 期待するすべてのロッキングのセマンティクスを提供する。

ロッキングという用語は、並外れて広い意味を持ち、この1つの用語の 配下にすべてカテゴライズされる機能の範囲をカバーしている。

Opportunistic lockingはネットワークで結合されたクライアント上で、アプリケーションの 見かけの性能を向上させることが出来る好ましい機能である。しかし、opportunistic locking プロトコルは頑丈ではなく、そのため、極端に単純化した設定か、広範囲の遅くて障害の多い ネットワーク上を超えて起動するときに、問題に遭遇する。この場合、opportunistic locking のOSによる管理か、反復的なエラーは提供することを意図した考えられる性能の利点を相殺する。

Microsoft Windows ネットワーク管理者は、ファイルとレコードのロッキングセマンティックス (動作)はSamba中かMicrosoft Windowsクライアント上のレジストリの設定で制御できることを 知っておく必要がある。

Note

時々、各Microsoft WindowsクライアントのようにSambaサーバー上でロッキングの制御の設定を 無効化する必要がある!

議論

SMBサーバーによって実行されることが必要な2つのタイプのロッキングがある。最初のものは オープンしているファイル中の一定の範囲のバイト範囲をクライアントがロックすることが できるレコードロッキングである。2番目のものは、ファイルが オープンしているときに指定される拒否モードである。

UNIX配下のレコードロッキングのセマンティックスは、Windows配下のレコードロッキングと大幅に 異なる。Samba2.2より前のSambaは、異なったSambaクライアントとの間で、適切なレコード ロッキングを実装するために、ネイティブなfcntl()UNIXシステムコールを使うことを試みた。 これはいくつかの理由で完全に正しいものにはならなかった。最も簡単なものは、Windows クライアントはロックするバイトレンジとして、クライアントのOSに依存するが、2の32乗か2の 64乗の範囲を指定できた。UNIXロッキングはレンジの幅として2の31乗までしかサポートして いなかった。そのため、2の31乗以上のロック要求を正確に満足させることは出来なかった。 そのほかにもここに記述するのには余りにも多すぎる数多くの違いがあった。

Samba2.2以降では、UNIXシステムに依存しない、独立したレコードロッキングを完璧に実装した。 もしもクライアントが0から2の31乗までの間でバイト幅ロックを要求した場合、SambaはUNIX システムにこの要求を落として扱う。他のどのようなロックもUNIXでは扱わない。

厳密に言うと、Sambaサーバーはファイル上への各読み/書きの呼び出し前にロックのチェックを すべきである。不幸にも、fcntl()が機能する方法で、これは遅延を引き起こし、 rpc.lockdに負荷を掛けることになる。これは、それに対してロッキングが 重要なとき、読み書きの前にロッキングを呼び出すことをクライアントは独立して行うはずという 理由で、ほとんど常時不必要である。既定値では、Sambaはクライアントによって明示的に 問い合わせがあったときにのみロッキングコールを行うが、もしも strict locking = yesを設定した場合、 読み/書きの呼び出し毎にロックチェックの呼び出しを行う。

locking = noを使うことによってバイト幅ロッキングを 完全に停止することも出来る。これは、ロッキングをサポートしない共有か、必要がないとき (たとえばCD-ROMなど)に便利である。この場合、Sambaは毎回OKであると、ロッキング呼び出しの 戻り値をクライアントに返すようにごまかす。

2番目のクラスのロッキングは、deny modesである。これらは、その オープンに対して同時に許されるべきアクセスのタイプを決めるため、ファイルをオープン したときにアプリケーションによって設定される。クライアントは、 DENY_NONE, DENY_READ, DENY_WRITE, か DENY_ALLを問い合わせできる。 DENY_FCBDENY_DOSと呼ばれる特別な互換 モードもある。

Opportunistic Lockingの概要

Opportunistic locking (oplocks)はサーバー上に存在するファイルにアクセスする時に、 ネットワークの効率を増大させる目的で、レジストリエントリ(サーバーとクライアント上) 経由でWindowsファイルシステム(APIと対照した場合)によって起動される。効率は、 以下を許容することでクライアント上にローカルにファイルをキャッシュすることにより 増大させる:

Read-ahead:

クライアントはファイルのローカルコピーから読み、ネットワークの待ち時間を なくす。

Write caching:

クライアントはファイルのローカルコピーに書き込み、ネットワークの待ち 間をなくす。

Lock caching:

クライアントはアプリケーションをローカルにロックし、ネットワークの待ち 間をなくす。

oplocksによる効率の増大は、他のプロセスからの同時アクセスのためのファイルのステータスを Windowsがモニターするために、deny-noneでオープンされていたとしても、ファイルに対する 排他的なアクセスを行うことによる。

Windowsは4つの種類のOplocksを定義する:

Level1 Oplock

リダイレクタは、ファイルがdeny none(同時アクセスを許可)で オープンしていることを確認し、ファイルに他のプロセスからの アクセスが無いことを検査し、oplocksが有効になっていることを 確認し、次に、ファイルに対するdeny-all/read-write/exclusive アクセスを許可する。その後、クライアントはキャッシュされたローカル ファイルに対して操作を実行する。

もしも2番目のプロセスがファイルをオープンしようとすると、 オリジナルのoplockをリダイレクタが"ブレーク"するまで オープンは待たされる。oplockブレークは、キャッシュしている クライアントに、サーバーにローカルファイルを書き戻し、ローカルの ロックをフラッシュし、先読みしたデータを廃棄するように通知する。 ブレークが完了し、遅延したオープンが許可され、多重プロセスが、 強制的かバイト幅ロッキングオプションによって指示されたように、 同時ファイルアクセスが出来るようになる。しかし、もしもオリジナルの ファイルがdeny-mode以外の共有モードの場合、次に、2番目の プロセスは、oplockがブレークしても、アクセスが制限されるか アクセスが拒否される。

Level2 Oplock

キャッシングを除いて、Level1 oplockのような機能は、すべての読み出しに 対してのみ重要である。すべてのその他の操作は、サーバー上でファイルの ディスクへのコピーを実行する。

Filter Oplock

ファイルへの書き込み又は削除アクセスを許可しない。

Batch Oplock

ファイルのオープンとクローズを操作し、ファイル属性のキャッシュを行う。

oplocksはファイルシステムによって起動され、アプリケーションAPIではないということは重要な 詳細事項である。そのため、あるアプリケーションはoplockされたファイルをクローズできるが、 ファイルシステムはoplocksを放棄しない。oplockのブレークが発生したとき、ファイルシステムは 次に、2番目のプロセスによる、次のファイルオープンの準備中で、単純にファイルをクローズする。

Opportunistic lockingは、この機能に対して、実際には妥当ではない名前 である。この機能の真の利点は、クライアントサイドのデータキャッシングであり、oplocksは ネットワーク上のディスクストレージにデータを書き戻すための、単なる通知メカニズムである。 oplocksの制限は、サーバーとキャッシュしているクライアント間でのoplocksブレーク(通知)を 処理するためのメカニズムの信頼性である。もしもこの交換に失敗すると(通常、数多くの理由で タイムアウトするという場合)、クライアントサイドキャッシングの優位性は否定される。

ユーザーか管理者が考慮すべき、実際の決断点は、ローカルにクライアント上にキャッシュされる 複数のユーザーのデータ間で共有するのは賢明であるかどうかと言うことである。多くの場合、 答えは「否」である。データをキャッシュするかしないかの決断は真の質問であり、そのため、 oplocksはクライアントサイドのキャッシングのトグルとして取り扱うべきである。クライアント サイドのキャッシングが望ましく、信頼性がある場合、それをonにする。 クライアントサイドのキャッシングが不必要で、信頼性に欠け、あるいは反生産的な場合、 offにする。

Oplocksは既定値ではすべての設定された共有上にSambaによってonに設定されて いるので、もしも潜在的な利便性が、遅延の可能性より小さい場合、それぞれのケースで決定 するときには注意深く行うべきである。以下の推奨項目は、oplocksが効果的になる環境を特徴 づけるのに役に立つだろう。

Windowsのoplocksは簡易な効率向上機能である。これは堅牢でも信頼できるプロトコルではない。 oplocksのすべての実装は、考え得る性能と信頼性との間でのトレードオフとして評価される べきである。信頼性は、上記での継続したルールが適用されないように減少する。oplockが 有効で、WAN上をまたいで、南太平洋の環礁の、高信頼性のサーバー上で、ミッション クリティカルな、多人数で使う会社のデータベースが台風にさらされている状況を考えてみよう。 この設定はoplockの問題に遭遇するだろう。

Oplocksは、クライアントサイドでのデータキャッシングのための構成要素のトグルとして 扱われる時、クライアントの性能を理解するために有益であり得る。もしもデータのキャッシングが さえぎられそうな場合、oplocksの使用は評価されるべきである。Sambaはすべての共有に対して oplocksを既定値で有効にする。サーバー上の共有データ、サーバーネットワークの信頼性と各共有の oplocksの設定の使用法をクライアントに提供すべきであることに注意深く注意を払う。 ミッションクリティカルな領域、高信頼性環境では、データの整合性はしばしば優先度が高く なる。複雑で高価な構成は、もしもクライアントがファイルサーバーへの接続が切れた時、 継続したデータの可用性を提供するために、フェイルオーバーによるサーバー切り替えがすぐに出来る ことが出来るように、実装される。

Windowsクライアントのフェイルオーバーの動作は、確立しているTCP/IPトランスポートコネクション に依存するという理由で、他のプラットフォームよりもアプリケーションの中断のリスクがより 大きい。もしも、ファイルサーバーのフェールオーバーとして接続が中断されたならば、新しい セッションは再度確立せねばならない。トランスポート層が切断された時から正しく復帰するために プログラミングされているWindowsクライアントはまれである。そのため、ほとんどの アプリケーションは、ある種の中断を経験することになる。最悪の場合、アボートして再起動が 必要となる。

もしもクライアントセッションが、oplocksのために、ローカルに書き込みと読み取りを キャッシングしているなら、TCPの中断からアプリケーションの再起動または復帰のときに データが喪失するだろう。ファイルサーバーが復旧すると、oplocksのブレークはクライアント には送信されない。この場合、先のセッションからの作業は失われる。oplocksが無効に なっていて、リアルタイムにファイルサーバーにクライアントがデータを書き込むという シナリオを観察することで、フェイルオーバーは、切断時に存在するディスク上のデータを 提供する。

ミッションクリティカルな、高可用性環境では、oplocksに対して厳重な注意をはらうべきである。 理想的には、広範囲なテストは、oplocksが有効かつ無効な状態で、すべての影響される アプリケーションで行うべきである。

共有の排他的なアクセス

oplocksは、単一のユーザーか、同時に1人のみのユーザーで、排他的にアクセスされる共有に限定 される時に最も有効である。oplocksの本当の姿は、ローカルにクライアントでキャッシング されているデータという理由により、キャッシングを中断する何らかの操作は遅延を引き起こす。

ホームディレクトリは、oplocksが問題ないと理解され、効率を得られる、最も明らかな例である。

共有またはファイルに対する多重アクセス

共有中のファイルへ各追加ユーザーがoplocksを有効にしてアクセスすると、遅延の可能性と、 結果として生じる性能の低下が増大する。複数のユーザーが、oplocksを有効にした共有上の ファイルにアクセスする時、oplocksブレークの送受信と、の管理と、データのオフセットを フラッシュするためにクライアントのキャッシングを他のクライアントが待つ間に結果として 生じる遅延の管理の影響は、キャッシュしているユーザーの効率向上を相殺する。

oplocksを設定して各追加のクライアントがファイルにアクセスする時、潜在的な効率の 向上は否定され、最終的には効率のボトルネックとなる。

UNIXまたはNFSクライアントがアクセスしたファイル

ローカルのUNIXとNFSクライアントは強制的なファイルロックメカニズムなしでファイルにアクセス する。そのため、それらクライアントプラットフォームは、ファイルをキャッシュしている Windowsクライアントにサーバーからのoplocksブレークを初期化できない。ローカルのUNIXか NFSファイルアクセスはこのため、データが壊れるようなファイルを公開している、Windows クライアントによってキャッシュされたファイルに書き込める。

もしも、ファイルがWindows間とローカルUNIXかNFSユーザーによって共有されているならば、 oplocksはoffにする。

遅くて信頼できないネットワーク

クライアントサイドの読み取りと書き込みのキャッシングが、回線上でそれらの読み書きを送る 上での大部分の差分を送る時に、oplocksが遭遇する性能向上の最も大きな可能性がある。 これは、ネットワークがとても遅く、詰まっているか分散している(WAN中の場合)には、頻繁に起きる。 しかし、ネットワークの遅延がoplocksメカニズムの信頼性に関して大きな影響があり、そのため、 潜在的に知覚できる効率の向上を十二分に相殺するoplocks問題を発生する見込みを増大する。 もちろん、もしもoplocksブレークが、決して送られる必要がなければ、これは、oplocksを利用 する最も効率的なシナリオである。

もしもネットワークが遅いか、信頼性がないばあいか、WANの場合、もしも複数のユーザーが 同じファイルを定期的に開く事がある場合、決してoplocksを設定しないこと。

マルチユーザーデータベース

マルチユーザーデータベースは、その本質的な性質から、明らかに危険である。それらは通常不定 間隔でたくさんのユーザーによって激しくアクセスされる。oplocksが有効になっている共有上で マルチユーザーデータベースを配置すると、Sambaサーバー上でのロッキング管理のボトルネックに なるだろう。手作りあるいは所用製品のデータベースアプリケーションのどちらにせよ、 共有のoplocksは無効にすること。

PDM Data Shares

IMAN、EnoviaやCleacaseのようなProcess data management (PDM)アプリケーションはWindows クライアントプラットフォームでの使用が増え、そのため、SMBによるデータ格納も増えている。 PDMアプリケーションは、重要なデータのセキュリティとアクセスのために、複数ユーザー環境を 管理する。一般的なPDM環境では、必要に応じてローカルにロードするデータは、洗練された クライアントデザインのアプリケーションに関連づけられる。更に追加で、PDMアプリケーションは 通常各クライアントのデータ状態をモニターする。この場合、クライアントサイドのデータ キャッシングは、ローカルのアプリケーションとPDMサーバーで協調して保守するために、最も 残される。任意のキャッシング作業からクライアントOSを、任意のoplocks管理から、共有上で oplocksを無効にすることによって取り除くことは適切である。

Force Userに対する注意

Sambaには、smb.confの変数によって定義されるどんなユーザーにも、接続してきたユーザーが 共有にアクセスする時に、ユーザーを変更するforce userという パラメーターをsmb.conf中に含むことが出来る。もしもoplocksが共有上で有効になっている場合、 ユーザーアクセス中の変更は、ユーザーが明示的にファイルをロードしなくとも、クライアントに送信 するoplocksブレークを発生させる。ネットワークが遅いか信頼性がない場合、ファイルにアクセス しているユーザーなしでoplocksブレークが失われることがある。これは、oplocksブレークの喪失を 補うために、絶えず再接続するクライアントとして見た目の効率低下を引き起こす。

以下を組み合わせることを防ぐ:

  • smb.conf中の共有定義中のforce user

  • 遅いか信頼性のないネットワーク。

  • Oplocksが有効。

高度なSamba Oplocksパラメーター

Sambaはタイミングと使用レベルの計測のためにoplocksメカニズムの、種々のプロパティを 管理者が調整できるoplocksパラメーターを提供する。これらのパラメーターは、問題を引き起こす ような環境中でoplocksを実装するために、すぐれた融通性を提供する。パラメーターは、 oplock break wait timeoplock contention limitである。

ほとんどのユーザー、管理者と環境にとって、もしも、これらのパラメーターが必要ならば、より良い 選択肢は、単にoplocksをoffにすることである。Samba SWATでは、両パラメーターについて、 Samba oplocksコードを読解しない限り、このパラメーターを変更しないこと。 という説明がある。これは良い助言である。

ミッションクリティカル、高信頼性

ミッションクリティカル、高信頼性を必要とする環境では、データの整合性がしばしば 優先される。複雑で高価な構成は、もしもクライアントとファイルサーバーへの接続が切れた時、 フェイルオーバーによる切り替えが、継続したデータの有効性を提供するためにすぐに行われる ように実装される。

Windowsクライアントのフェイルオーバーの動作は、確立したTCPトランスポート層の接続に 依存しているために、他のプラットフォームよりアプリケーションの中断というリスクとなる。 もしも、ファイルサーバーのフェイルオーバーで接続が中断されたならば、新しいセッションは 確立されねばならない。トランスポート層の切断から正しく復帰するためにコードが書かれている Windowsアプリケーションはまれである。そのため、ほとんどのアプリケーションは、ある種の 中断が生じることになる。最悪の場合、アボートして再起動が必要となる。

もしもクライアントセッションが、oplocksにより、ローカルに読み書きをキャッシュしている ならば、TCPの中断からアプリケーションが再起動か復帰する時、データが失われるかもしれない。 TCPの接続が失われた時、oplocksブレークはクライアントには送られない。この場合、以前の セッションからの作業は失われる。oplocksを無効にしてこのシナリオを観察すると、 もしもクライアントがリアルタイムにファイルサーバーにデータを書き込んでいたら、 フェイルオーバーはディスコネクト時に存在したディスク上のデータを提供するだろう。

ミッションクリティカル、高可用性を要求する環境では、oplocksの使用については厳重に注意を 払う必要がある。理想的には、oplocksを有効/無効にした、すべての影響があるアプリケーション について、広範囲なテストを行うべきである。

SambaのOplocks制御

oplocsは、ユニークなWindowsファイルロッキング機能である。これは真のファイルロッキング機能 ではないが、Windowsのファイルロッキングの多くの議論中に含まれ、そのため、事実上の ロッキング機能として考えられる。oplocksは、実際の所、Windowsクライアントファイル キャッシング機能の一部である。これは、エンタープライズコンピューティング領域中に存在 する、種々のカスタマイズされたネットワーク上で実装される時には、とりわけ丈夫か信頼性が ある機能ではない。

SambaではWindowsと同様に、クライアント側のキャッシング機構であるoplockを、サーバー側の コンポーネントとして実装している。Windowsの機能設計上、oplock は軽量型として設定されて いる(機能が限定されている)。このためoplockを効果的に設定するには、これらの制限事項の 把握が不可欠であり、またカスタマイズされたネットワークやクライアントの利用状況に特化 したデータアクセスを構成する際の理解が行き届いている場合にのみ適用されるものである。

Oplocksの基本的な意味は、クライアントが、変更中にそのハードドライブ上にファイルを ダウンロードし、キャッシュ出来るということである。もしも、2番目のクライアントがファイルに アクセスしようとした場合、最初のクライアントはブレークを受け取り、サーバーに対して 同期を取らねばならない。これは、ある場合においては、かなり効率が向上する。いくつかの プログラムは、単一の変更のためにサーバーに対してファイルの内容すべてを戻して同期を取る ことを行うものもある。

Level1 Oplocks(単にoplocksとしても知られている)はopportunistic lockingの 別の言い方である。

Level2 Oplocksはリードオンリとして取り扱うファイルに対して opportunistic lockingを提供する。通常これはリードオンリか、クライアントが、ファイルの オープン時に、最初に書き込まないファイルに使われる。

Kernel OplocksはLinux kernelに、Microsoft Windowsネットワークファイルロッキングのより良い 統合を提供するにも関わらず、Sambaがoplocksしたファイルとの共存を許可する基本的な方式 である。SGI IRIXとLinuxは現時点でoplocksを認識するただ2つのOSである。

使用しているシステムがkernel oplocksをサポートしている限り、UNIX/LinuxとSMBクライアントの 両方から同じファイルをアクセスする時、oplocksを無効にすべきである。もしも、複数の クライアントからデータベースファイルを共有している時(たとえば、Microsoft Access)、 顕著なパフォーマンスダウンと、さらに、最初の場所におけるデータベースのアクセス問題が 発生する、ファイル全体(1つのレコードではなく)の同期に影響する、最初のクライアントが 受け取る任意のブレークという理由で、oplocksは気にせず常時無効にすべきである。 特に、Microsoft Outlookのパーソナルフォルダー(*.pst)はoplocksに対してとてもひどく反応する。 疑っているのならば、oplocksを無効にして、その辞典からシステムを調整してみると良いだろう。

もしもクライアントサイドのキャッシングが無効で、ネットワークの信頼性があるのであれば、 oplocksをonにすることで利点が得られる。もしも、使用しているネットワークが遅くて、信頼性が ないか、他のファイル共有方式(たとえばNFS)との間でファイルを共有しているか、WAN経由の 場合か、頻繁に同一ファイルを複数の人がアクセスする場合、クライアントがoplocksブレークを 送るオーバーヘッドからの利益を得られず、そのかわりに共有に対してoplocksを無効にしたいと 思うだろう。

考慮すべき他の要素は、ファイルアクセスの認識されたパフォーマンスである。もしもoplocks が使用するネットワーク上で、わかるほどのスピード向上を提供しない場合、それを取り扱う 難しさ分の価値がないかもしれない。

設定例

以下の節では、Sambaロッキングの制御に関する2つの異なった側面について評価する。

oplocksを無効にする

以下のようにして、共有単位でoplocksを無効にすることが出来る:

[acctdata]
oplocks = False
level2 oplocks = False

既定値のoplocksタイプはLevel1である。Level2 oplocksはsmb.confファイル中で、共有単位に 有効に出来る。

代わりに、以下のようにして、共有内でファイル単位にoplocksを無効に出来る:

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

もしも、Sambaのログエントリから確認出来る、oplocksの問題に遭遇した場合、 安全を期すために、oplocksとLevel2 oplocksを無効にしても良い。

Kernel oplocksを無効にする

Kernel oplocks は、キャッシュされているファイルをUNIXプロセスがオープンしようとする 時に、(もしもUNIX kernelがWindowsクライアントに対してoplocksを送信する機能がある時) Sambaに対して通知するsmb.confパラメーターである。このパラメーターはUNIXと、Sambaサーバー 上でoplocksが有効になっているWindows間で共有するファイルをアドレスする。UNIXプロセスは Windowsクライアントによってoplockedされた(キャッシュされた)ファイルを開くことが出来、 ファイルがデータ破壊のリスクがあるという事を伝える、oplocksブレークをsmbdプロセスは 送らない。もしもUNIX kernelがoplockブレークを送る機能があるならば、kenel oplocks パラメーターは、Sambaにoplockブレークを送ることを有効にする。kernel oplocksは、 smb.confファイル中でサーバー単位に有効に出来る。

kernel oplocks = yes

既定値はnoである。

Veto oplocksは、oplocksが無効になる特定のファイルを識別するための、 smb.confパラメーターである。veto oplocksに設定されているファイルをWindowsクライアントが オープンする時、クライアントはoplocksが許可されず、すべての操作はクライアント上に キャッシュされたファイルのコピーの代わりにディスク上のオリジナルのファイル上で実行 される。UNIXプロセスとoplocksを無効にしたそれらファイルとの間で共有されるファイルを 明示的に識別することで、サーバー全体でのoplocks設定が、データ破壊のリスクがない、ファイルの キャッシングという効率の向上を、Windowsクライアントが利用できることを有効にできる。 veto oplocksは、以下の“いくつかのファイルがoplocksされた共有”で示されるような、smb.conf中で、 共有単位か、サーバー全体で有効に出来る。

Example 17.1. いくつかのファイルがoplocksされた共有

[global]
veto oplock files = /filename.htm/*.txt/
[share_name]
veto oplock files = /*.exe/filename.ext/


oplock break wait timeは、smb.conf中のパラメーターで、oplock ブレーク要求をSambaが繰り返す時間感覚を調整する。Sambaは Sambaのoplocksコードを読んで理解しない限りこのパラメーターを変更しないこと と忠告している。oplock break wait timeは、以下のように、smb.conf中でグローバルな形で のみ設定できる。

oplock break wait time = 0 (default)

Oplock break contention limitは、smb.conf中のパラメーターで、 パラメーターによって指定された制限に、設定された数多くの競合するクライアントが到達する 場合、 oplockを許可するためのSambaサーバーのレスポンスを制限する。Sambaは Sambaのoplocksコードを読んで理解しない限りこのパラメーターを変更しないこと と忠告している。oplock break contention limitは、“Oplock Break Contention Limitの設定”のように、 smb.conf中で共有単位あるいはグローバルにサーバー全体で有効に出来る。

Example 17.2. Oplock Break Contention Limitの設定

[global]
oplock break contention limit = 2 (default)
[share_name]
oplock break contention limit = 2 (default)


Microsoft Windowsのoplocksとキャッシュ制御

ネットワーク経由で共有データベースにアクセスする任意のアプリケーションに影響しうる Windows 2000/XPワークステーション上でアプリケーション(Norton Antivirusのような)を 動かす時によく知られている問題がある。これは、Windows 2000/XP OSの既定値の設定の結果に よるものである。他の 2000/XPコンピュータ上の共有データベースファイルに、 ワークステーションがアクセスする時、Windows 2000/XP OSは、ファイルをロックし、情報を ローカルにキャッシュすることで効率を向上することを試みる。これが起きると、 アプリケーションは、ネットワーク操作中、アクセスが拒否されましたという エラーが表示されて適切に動作しなくなる。

データファイル(データファイルがそこに格納されて、他のWindows PCによってアクセスされる という意味で)のためのデータベースサーバーとして振る舞う、NTファミリの、すべての Windows OSは、データファイルの破損を防ぐリスクを最小限にするために、oplocksを無効にする 必要があるかもしれない。これには、Windows 9x/Me、Windows NT、Windows 200xと Windows XPが含まれる。 [5]

もしも、サーバーの代わりにWindows NTファミリのワークステーションを使っているならば、 そのワークステーション上でoplocksを無効にしなければならない。例えば、もしも、 Windows NT サーバーの代わりにWindows NT ワークステーションをPC上で使っていて、 その上に、他のWindows PCからアクセスされるデータファイルがあるならば、そのシステム上で oplocksを無効にしなければならないかもしれない。

大きな違いは、oplocksを無効にするための値を入れるWindowsレジストリの位置である。 LanManServerの位置の代わりにLanManWorkstationの位置が使われる。

Windowsレジストリエディターを使ってこのレジストリの値を検査(必要に応じて変更か追加)する ことができる。このレジストリ値を変更する時、新しい設定を反映させるために、PCを再起動 しなければならない。

oplocksのためのクライアントレジストリエントリの位置は、Microsoft Windows NTよりも 前の位置から、Windows 2000では変わっている。

Note

Windows 2000 は、以前のWindows中でoplocksを無効にするために使うEnableOplocksレジストリ エントリを引き続き使用している。

以下のレジストリエントリを変更することによって、oplocksの許可を拒否することも出来る:

	HKEY_LOCAL_MACHINE\System\
		CurrentControlSet\Services\MRXSmb\Parameters\

		OplocksDisabled REG_DWORD 0 又は 1
		既定値: 0 (無効になっていない)

Note

OplocksDisabledというレジストリエントリ値は、リモートファイル上のoplocksの要求のあるなしを Windowsクライアント上で設定する。oplocksを無効にするためには、OplocksDisabledの値は 1に設定しなければならない。

	HKEY_LOCAL_MACHINE\System\
		CurrentControlSet\Services\LanmanServer\Parameters

		EnableOplocks REG_DWORD 0 又は 1
		既定値: 1 (既定値で有効)

		EnableOpLockForceClose REG_DWORD 0 又は 1
		既定値: 0 (既定値で無効)

Note

EnableOplocksという値はWindowsベースのサーバー(ファイルを共有しているワークステーションを 含む)で、ローカルファイル上のoplocksを許可/拒否することを設定する。

クローズまたはプログラム終了時でオープンしているoplocksを強制的に終了するためには、 EnableOpLockForceCloseを1に設定しなければならない。

Level2 oplocksの動作概要は以下の通り:

  • ステーション1がoplockを要求してファイルを開く。

  • 他のどのステーションもファイルを開かない間、サーバーはステーション1に排他的oplockを許可する。

  • ステーション2がoplockを要求してファイルを開く。

  • ステーション1がまだファイルを書き込んでいないなら、サーバーはステーション1にレベル2の oplockのブレーク通知を行う。

  • ステーション1はローカルにバッファーした情報をサーバーに書き戻す。

  • ステーション1はレベル2のoplockを素unしたサーバーに情報を送る(代わりにステーション1は ファイルをクローズすることが出来たはずである)。

  • サーバーはステーション2のオープン要求に対応し、レベル2のoplockを許可する。 その他のステーションは同じくファイルを開くことが出来、同様にレベル2のoplockが 許可される。

  • ステーション2(か、ファイルをオープンしている他のステーション)はSMB書き込み要求を 送る。サーバーは書き込み応答を返す。

  • サーバーは、ファイルをオープンしているすべてのステーションに対して、ロックを 壊さないこと、すなわちファイルに対して oplock を保持しているステーションが ないことを確認する。この時点で、ワークステーションはキャッシュされた 書き込みもロックも保持していないため、break-to-none 勧告に対して応答する 必要がないからである。それぞれのワークステーションは、単にローカルで キャッシュしている先読みデータを無効にするだけでよい。

ワークステーションサービスのエントリ

	\HKEY_LOCAL_MACHINE\System\
		CurrentControlSet\Services\LanmanWorkstation\Parameters

	UseOpportunisticLocking   REG_DWORD   0 又は 1
	既定値: 1 (真)

これは、リダイレクタがoplockの効率向上機能を使うかどうかを指示する。 このパラメーターは問題を判別するためにのみ無効にすべきである。

サーバーサービスのエントリ

	\HKEY_LOCAL_MACHINE\System\
		CurrentControlSet\Services\LanmanServer\Parameters

	EnableOplocks   REG_DWORD   0 又は 1
	既定値: 1 (真)

これは、サーバーが、ファイルにoplocksを使うことをクライアントに対して許可するか どうかを指定する。oplocksは明確に効率を向上させるが、特にWANのような、ある種の ネットワーク上でキャッシュされたデータを失う可能性がある。

	MinLinkThroughput   REG_DWORD   0 は秒あたり無限のバイト量
	既定値: 0

これは、この接続のための、生の(raw) I/Oとoplocksを無効にする前に、サーバーによって 許可される最小のリンクスループットを指定する。

	MaxLinkDelay   REG_DWORD   0 から 10万秒
	既定値: 60

これは、リンクのディレイで許される最小限の時間を指定する。もしもこの値よりも遅延が 大きい場合、サーバーは生の(raw)I/Oとoplocksを、この接続では無効にする。

	OplockBreakWait   REG_DWORD   10 から 180 秒
	既定値: 35

これは、oplockブレーク要求に対してクライアントが返答するまで、サーバーが待つ時間を指定 する。より小さな値はより速やかにクラッシュしたクライアントを検出できるが、キャッシュした データを失う可能性がある。

持続的なデータ破壊

もしもこの章で議論されている設定のすべてを適用したが、データの破壊問題と他の症状が持続 しているのであれば、追加して監視するものがある。

単独の欠陥があるネットワークカードのような、欠陥があるネットワークハードウェアについて、 開発者から信用できる報告を受けていることが、読み取りキャッシングとデータ破壊に類似して いる兆候を引き起こす。もしも、繰り返しインデックスした後にもかかわらす、持続的なデータ 破壊が起きているならば、問い合わせ中でデータファイルの再構築をしなければならないかも しれない。これは、リビルドするようなのと同じいくつかの定義で新しいデータファイルを作成 することを改善し、古いファイルから新しいファイルにデータを転送する。Samba知識ベース中で 見つけることが出来る、これを行う、いくつかの手法がある。

よくあるエラー

サーバーをインストールするやいなや、問題が表面化するサイトがある。他のサイト内では長い 間問題が表面化していない。例外を除いてほとんど、問題が表面化したとき、当惑と、潜在的な データ破壊を引き起こすだろう。

過去数年の間、Sambaがデータ破壊を引き起こすというクレームの、数多くの不満が、Samba メーリングリスト上に投稿されてきた。3つの原因が認識されてきた:

  • 不正なoplocksの設定(アプリが使うものとの非互換)。これは、Microsoft Windows NT4か Microsoft Windows 200xベースで使っているサーバーでも共通の問題である。ソフトウェア アプリケーションベンダのファイルロッキングに関する設定手順に急いで従うべきである。 もしも疑うのであれば、サーバーとクライアント両方でoplocksを無効にする。Microsoft Windowsクライアント上でキャッシングするすべての形式のファイルを無効にすることも 必要かもしれない。

  • 不完全なネットワークカード、ケーブル、あるいはハブ/スイッチ。これは、一般的に 低コストネットワークハードウェアにおける一般的な事項であるが、より高級なハード ウェアにおける非互換性の問題も時折ある。

  • データファイルを書く時にSambaのログファイルに時折痕跡が残ることがある。これは、 ごく少数のサイトで報告されていて(過去3年でおおよそ5つ)、すべての再現試験は 失敗した。Sambaチームはこの現象を捕まえられず、そのため、何らかの特定の現象と して分離できていない。Sambaを使う非常に数多くのシステムがあることを考えると、 Sambaチームと同様に、これに影響を受けたサイトにとって、これはいらいらする、 やっかいな難問である。もしも、このタイプの現象に遭遇したならば、遅滞なく、 SambaのBugzillaにバグレポートを 投稿してほしい。可能な限りのたくさんの情報をもらえると、現象の特定の手助けと、 (問題の特定と修正のための基本的なステップである)問題の再現の手助けになる。

locking.tdb のエラーメッセージ

以下のようなたくさんのエラーメッセージがSambaのログ中にある:

tdb(/usr/local/samba_2.2.7/var/locks/locking.tdb): rec_read bad magic
 0x4d6f4b61 at offset=36116

これは何を意味するのか?

このエラーはtdbファイルが壊れていることを表示している。smbdのすべてのプロセスを停止し、 locking.tdbを削除してsmbdを再起動する。

Windows XP上でのMicrosoft Officeファイルセーブ時の問題

これはWindows XPのバグである。より詳細な情報は、 Microsoft KBの記事812937 を参照のこと。

XP SP1でネットワーク経由でファイルを消すのに長い時間がかかる

XP SP1を適用語、ネットワーク経由でファイルを消すのに、時々おおよそ35秒もかかる。

これはWindows XPのバグである。より詳しい情報は、 Microsoft KBの記事 を参照のこと。

参考文献

Microsoftのサポートwebサイトで、 ファイルとレコードのロッキングに関する更新された文書をチェックしても良いだろう。 追加で、Sambaのwebサイトで、 lockingという単語を探しても良いだろう。

Microsoft MSDNライブラリ上にある opportunistic locking 節は以下の通り:

Microsoft KB, OPLOCKS によるトランザクションの整合性を維持, Microsoft Corporation, April 1999, Microsoft KB の記事 224992(訳注:機械翻訳).

Microsoft KB, Windows で Opportunistic Lock を構成する, Microsoft Corporation, April 2001 Microsoft KB の記事 296264.

Microsoft KB, PC Ext: Windows NT の Opportunistic Locking の説明, Microsoft Corporation, April 1995 Microsoft KB の記事 129202.



[5] Microsoftはこの件について KB 300216で解説している。

Chapter 18. Securing Samba

Andrew Tridgell

Samba Team

John H. Terpstra

Samba Team

May 26, 2003

序論

この章に含まれる情報は、一般的にすべての導入したSambaに対して適用できる。セキュリティは IT界において、すべての人の関心事である。驚くべき数のSambaサーバーが直接インターネットに 接続するマシン環境上にあり、そのため、ファイアウォールの内側でプライベートネットワーク 上にあるサーバーよりもよりセキュリティ的に危険な状態にある。極端にサーバーセキュリティを重視 する場合、セキュアなネットワーク中に配置されるサーバーはもちろん、頑丈なファイアウォールを、 ネットワーク管理者の一部が要求することになる。この章では、どのように必要とされる障壁 (バリア)を作るかと言うことと、脅威に対する防御を理解する管理者(所属は 問わない)を手助けする情報を提供する。

新しい実習生が、ボイラー室のチーフエンジニアの所に、任務のために出勤してきた。彼曰く、 ただいま出勤しました。ボイラーを見せていただければ作業を開始します。 エンジニア曰く、そのボイラーに腰掛けているぞ!

セキュリティに関する関心はこのようなものである。その大部分が本当にどのくらい明白かを 評価するため、この問題に対して多少知っておく必要がある。挑戦の大部分は、熟練者が持つ 秘技を解き明かすかもしれない知識の最初のかけらを探り出すことである。

機能と利便性

サイトを少なくとも適度に安全にするために守るべき、セキュリティ原則の3つのレベルがある。 それらは外側に対するファイアウォール、Sambaが動いているホストサーバーの設定とSambaそれ 自身である。

Sambaは、ネットワークセキュリティに対する最も柔軟なアプローチを認めている。可能な限り、 Sambaは、Microsoft Windowsのファイルとプリント操作に対して許可される、よりセキュアな、 最も最新のプロトコルを実装している。

Sambaはローカルネットワーク外から来る接続からセキュアに出来る。これは ホストベースの保護を、tcpwrappersとして知られている、 技術の実装を使うことか、インタフェースベースの除外を使うことで行え、 その結果、smbdは許可された特定のインタフェースのみにバインドする。また、たとえば [IPC$]自動共有上のような、共有またはリソースベースの除外を 設定することも可能である。[IPC$]共有は、TCP/IPコネクションを 確立するのと同様、ブラウジング目的に使われる。

Sambaをセキュアに出来る他の方法は、共有それ自身に、アクセスコントロールリスト(ACL)中に アクセス制御エントリ(ACE)を設定することである。これは ファイル、ディレクトリと共有のアクセス制御 に説明がある。

保護対応と問題に関する技術的な議論

既知のセキュリティ上の弱点と侵害技術に対して保護するために、せいぜいドアを閉めることで 十分であることが、セキュリティの鍵となる難問である。これらの少ない処置を行ったので、 Sambaサーバーが入り込めない要塞になると仮定してはいけない。これまでの情報システムの歴史を 見れば、誰かが他の脆弱性を見つけ出すのは時間の問題である。

ホストベースの保護の使用

数多くのインストール済みSambaにおいて、最も大きな脅威は、隣接したネットワークの 外部から来る。既定値で、Sambaは任意のホストからの接続を受け、それはすなわち、 もしも、インターネットに直接接続されているホスト上でセキュアでないバージョンの Sambaを動かしていた場合、特に脆弱になるということである。

この場合の最も簡単な修正の1つは、hosts allowhosts denyをSambaのsmb.conf設定ファイル中で、 特定の範囲のホストから飲みサーバーにアクセスを許可するように使うことである。 設定例は以下の通り:

hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24
hosts deny = 0.0.0.0/0

上記はSMB接続を、localhost(自分自身)と2つのプライベート ネットワークである192.168.2 と 192.168.3. からのみ許可する。その他の接続要求は クライアントから最初のパケットが来たらすぐに拒否される。拒否は、 呼び出された名前ではリッスンしていないというエラーとして マークされる。

ユーザーベースの保護

もしも、サーバーへのアクセスを有効なユーザーのみに制限したいならば、以下の方法を 使うことが出来る。smb.conf中の[global]セクションに 以下を記述する:

valid users = @smbusers, jacko

これは、ユーザーjackoかシステムグループsmbusers のメンバーのみに、すべてのサーバーアクセスを制限する。

インタフェース保護の使用

既定値では、Sambaはシステム上にある任意のネットワークインタフェースからの 接続を受け付ける。これは、もしもISDNかPPPでインターネットに接続している 場合、Sambaはそれらからの接続を受け付けるということである。これはおそらく 希望していることではないだろう。

この動作は、以下のようなオプションで変更できる:

interfaces = eth* lo
bind interfaces only = yes

これは、たとえばeth0eth1のような ethで始まる名前のインタフェースと、lo という名前のループバックインタフェースからの接続のみを受け付ける事を指示する。 必要とする名前はどのOSを使っているかに依存する。上記ではLinux上での共通的な イーサネットアダプターの名前を使っている。

もしも、上記を使い、誰かがppp0という名前のPPPインタフェース 上でホストに対してSMB接続を行おうとした時には、TCPの接続が拒否されたという応答が 帰る。この場合、OSが、任意のSambaプロセスに対して、そのインタフェースからの接続を 渡さないと通知するため、Sambaは全く動作しない。しかし、接続拒否という応答は、 クラッカーに対して、そのIPアドレスが有効なサービスを提供しているという確認をさせて しまうということにもなる。

もっと良い対応は、接続を全く無視することである(たとえばppp0から)。接続を拒否する ことと比較して接続を無視する試みの利点は、脆弱性攻撃かサービス不能(DoS)攻撃時に 後で使うための有効なIPアドレスを見つけるためが唯一の意図の探索を失敗させることで ある。潜在的な悪意がある行動を取り扱うこの方法は、適切なファイアウォール機構 を使うことが必要である。

ファイアウォールの使用

多くの人が、使用しているネットワーク外に公開したくないサービスへのアクセスを拒否 するためにファイアウォールを使っている。これはよいアイデアではあるが、上記の と関連して使用することを勧める。そうすると、何らかの理由でファイアウォールが 無効になったとしても保護が出来る。

もしもファイアウォールを設定するとき、どのTCPとUDPポートを許可し、ブロック るかを知っておく必要がある。Sambaは以下のポートを使う:

Port 135/TCP - used by smbd
Port 137/UDP - used by nmbd
Port 138/UDP - used by nmbd
Port 139/TCP - used by smbd
Port 445/TCP - used by smbd

最後のものは、多くの古いファイアウォールの設定がそれを知らないかもしれない という理由で重要である。このポートは最近付け加えられた。

ファイアウォールを設定するとき、ハイオーダポート(1024-65535)は外向きの接続に 使われ、そのため、ファイアウォールを通るようにする必要がある。確立した接続を 除いて、ハイオーダポート上の入力パケットをブロックすることは賢明である。

IPC$ 共有ベースの拒否の使用

もしも、上記の方法が適していないのであれば、最近セキュリティホールで使われた IPC$共有に拒否の設定をすることが出来る。これは、潜在的に信頼できないホスト からのIPC$へのアクセスを拒否する間、他の共有へのアクセスを提供する。

これを行うには以下のようにする:

[IPC$]
hosts allow = 192.168.115.0/24 127.0.0.1
hosts deny = 0.0.0.0/0

これは、2つの指定されたネットワークアドレス(ローカルホストと 192.168.115の サブネット)以外のどこからもIPC$共有への接続を許可しないようにSambaに指示する。 IPC$共有のみが常時匿名でアクセスできる共有であるという理由で、これは、 そのホストで有効なユーザー名/パスワードを知らない攻撃者に対してあるレベルの 保護を提供する。

もしもこの方法を使うのであれば、クライアントがIPC$共有にアクセスした時に、 `access denied'となる。それらクライアントは共有をブラウズ 出来ず、その他のリソースの一部にもアクセスできないだろう。この方法は、ここで説明 してきた方法のどれかが、何らかの理由で使えない場合を除いて推奨しない。

NTLMv2のセキュリティ

NTLMv2認証を設定するためには、以下のレジストリキーは知っておく価値がある:

		[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
		"lmcompatibilitylevel"=dword:00000003
		

0x00000003という値はNTLMv2レスポンスのみを送ることを意味する。クライアントは NTLMv2認証を使う。もしもサーバーがサポートしているなら、NTLMv2セッション セキュリティを使うこと。ドメインコントローラーはLM、NTLMとNTLMv2認証を受け取る。

		[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
		"NtlmMinClientSec"=dword:00080000
		

0x00080000という値はNTLMv2セッションセキュリティのみを許可することを意味する。 もしも、NtlmMinClientSecかNtlmMinServerSecが0x00080000に設定されるならば、 もしもNTLMv2セッションセキュリティがネゴシエートされたときに接続は失敗する。

Sambaのアップグレード

アップデートと重要な通知があるかどうかを、 http://www.samba.org/ で定期的に確認してほしい。時折セキュリティリリースが作成され、セキュリティ上の脆弱性が 発見されたときには直ちにSambaをアップグレードすることを強く推奨する。また、OS固有の アップグレードはOSベンダに確認すること。

よくあるエラー

もしも、SambaおよびSambaが動作するホストの設定が、誰もが期待するように直感的であれば、 この章は不必要である。セキュリティの問題は、問題の複雑性の理由からではなく、 セキュリティ問題の要求と判明することを投稿するほとんどの管理者が、全くSambaの問題で あると確信しているという理由で、サポート担当の人にとってしばしばやっかいである。

smbclientはローカルホストで動くが、ネットワークは死んでいる

これはよくある問題である。Linuxベンダは既定値のファイアウォールをインストールする 傾向がある。既定値のファイアウォールの状態ではループバックアダプター (IPアドレスが 127.0.0.1)のみの通信が、ファイアウォール経由で許可される。

解決方法は、ファイアウォールを取り除く(停止する)か、SMBネットワークトラフィックが 通過できるようにファイアウォールスクリプトを修正することである。 ファイアウォールの使用の節を参照のこと。

なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?

一度有効なパスワードが供給されると、他のユーザーのホームディレクトリへ個別のユーザーが マッピングすることを阻止できない。ユーザーが自分自身のホームディレクトリのみを マッピング出来るように、Sambaを設定する方法を見つけられない。

ユーザーxyzzyは自分自身のホームディレクトリをマップ出来る。一度マップすると、ユーザー xyzzyは他の誰のホームディレクトリでもマップ出来る。

これはセキュリティの欠陥ではない。これはデザインによるものである。Sambaは、 定義された共有に許されるように、ファイルシステム上のそのような表示のみを 認める事を除いて、UNIXマシンにログオンしていた時と正確に同じような、 UNIX ファイルシステムへのアクセスをユーザーに認める。

もしも、使用しているUNIXのホームディレクトリが設定されていてあるユーザーが、 他のユーザーのディスク中に、何の問題もなくcdでき、 lsを実行出来るならば、UNIXのセキュリティの解は、 ユーザーのホームディレクトリ上のファイルのパーミッションを変更して、 そのために、 cdlsは拒否される。

Samba は、UNIX管理者が定めるセキュリティポリシを勝手に解釈(second guess) しないように、非常に気を使っており、UNIX管理者が、ポリシーやパーミッションを 意図通りに(desire)設定していると確信している。

Sambaは要求した動作を許可する。[homes]共有定義中に only user = %Sオプションを単におくこと。 Samba allows the behavior you require. Simply put the only user = %S option in the [homes] share definition.

only userパラメーターは users = listパラメーターと一緒に動作するので、 要求する動作を得るためには以下の行を追加する:

users = %S

これは下記を追加するのと同じである。

valid users = %S

[homes]共有の定義のためには、smb.conf マニュアルページでの推奨のようにする。

Chapter 19. ドメイン間の信頼関係

John H. Terpstra

Samba Team

Rafal Szczesniak

Samba Team

Jelmer R. Vernooij

drawing 
The Samba Team

Stephen Langasek

April 3, 2003

Samba-3はNT4形式のドメイン信頼関係をサポートする。NT4形式のドメインからSamba-3に移行 したいが、Active Directory やLDAPベースの認証バックエンドを採用したくないという多くの サイトが使用したいと思う機能である。この章では、信頼関係に関する背景情報と信頼関係の 作成方法を説明する。Samba-3はNT4を信頼することができ(その逆も可)、またSamba対Sambaの 信頼を作成することも可能である。

ドメイン間の信頼関係を使う場合、winbindを使うことが必要であるので、 winbinddが動いていなければならない。このモードにおけるwinbindの 動作は、smb.confファイル中の有効なUIDレンジと有効なGIDレンジの指定に依存する。 これらは以下のように指定する:

idmap uid = 10000-20000
idmap gid = 10000-20000

指定されたレンジの値はホストOSで使っている値とPOSIXユーザーアカウント用のpassdbバック エンドで使っている値を上書きしてはならない。最大値はホストOSによって許可されている 上限の値で制限される。これはUNIXカーネルで制限されるパラメーターである。Linux kernel 2.6ベースのシステムは最大値として4294967295(符号なし32ビット値)である。

Note

winbindを使用するのはSambaが信頼しているドメインの時のみであり、信頼されたドメインの時 には不要である。

機能と利便性

Samba-3はSambaとMicrosoft Windows NT4形式と同じようにSamba間の信頼関係に参加できる。 これは、Microsoft Windows NT4と同様な拡張性をSambaに付与する。

Samaba-3はLDAPのような拡張性のあるバックエンド認証データベースと共に動作でき、プライマリ 及びバックアップドメイン管理モードで動作できるので、管理者はドメイン間の信頼関係を使用 する代わりの選択肢を考慮するべきである。なぜならば、この機能はその動作原理からして、 本質的に脆弱なものだからである。このことこそが、Microsoft Active Directory が開発され 採用される主な理由でもある。

信頼関係に関する背景情報

MS Windows NT3/4形式のセキュリティドメインは、階層がないセキュリティ構造を採用している。 この構造の制約が、大規模な組織では Microsoft Windows ネットワークの拡張性に影響を与える ことはよく知られている。さらに、この設計の結果であるフラットな名前空間は、大規模で 多様性に富む組織における管理責務の代行に多大な影響を及ぼす。

Microsoft は、古いテクノロジーの制約を回避するために、Active Directory Service(ADS)を、 Kerberos及びLDAPをベースとして開発した。しかし全ての組織が ADSを採用する準備ができ、 その意思があるわけではない。小規模の組織にとっては古い NT形式のドメインセキュリティで 充分である。また、ADS を採用するために面倒な変更作業を行うことを望まない保守的な ユーザーも残っている。

Microsoft Windows NTで、Microsoft はあるドメインのユーザーが、別のドメインのアクセス権や 他の権限を付与されるような機構を実現するため、多様なセキュリティドメインの存在を可能に する機能を導入した。この機能を信頼(Trusts)という言葉で言い表わす。 具体的には、あるドメインが別のドメインのユーザーを信頼するという ことである。あるドメインのユーザーが別のセキュリティドメインのユーザーになれる時、 そのようなドメインを信頼される(trusted)ドメインと言う。そのようなユーザーに権利や権限を 与えた方のドメインは信頼する(trusting) ドメインと言う。NT3.x/4.0 では信頼関係は一方向 のみである。そのため双方のドメインのユーザーが他方のドメインで権限と権利を持とうとする 場合には、それぞれの方向に一つずつ、二つの信頼関係を設定する必要がある。

NT4形式のMicrosoft セキュリティドメインでは、全ての信頼は非推移的である。この意味は、 例えば三つのドメインがあり(仮に赤、白、青とする)、その赤と白が信頼関係を持ち、また 白と青が信頼関係を持つとする。この場合、赤と青のドメインの間に暗黙に了解された 信頼関係を持つわけではない。関係は明示的でなければならず、推移的ではない。

Microsoft Windows 2000から登場した新たなADSセキュリティの方式では、信頼関係は既定値で 双方向になっている。また、全てのADSドメイン間の信頼は推移的である。上の赤、白、青 ドメインの例では、Windows 2000及びADSを使用する場合、赤と青ドメインは互いに信頼できる。 これはADSドメインの本質的な特長である。Samba-3 はMicrosoft Windows NT4方式のドメイン間 信頼機能を実装し、Microsoft Windows NT4方式のドメインと類似した方法で、 Microsoft Windows 200x ADS セキュリティドメインとの相互運用を実現している。

ネイティブなMicrosoft Windows NT4の信頼関係の設定

ドメイン間信頼関係を作成するには二つのステップがある。双方向の信頼関係を有効にする ためには、双方のドメイン管理者が相手のドメインのために信頼アカウントを作成し、 セキュリティに関する信用情報を確認する際に使用できるようにしなければならない。

NT4ドメイン信頼関係の作成

Microsoft Windows NT4では、全てのドメインの信頼関係は ドメインユーザーマネジャを使って設定する。これは、 メニューバーのドメインユーザーマネジャーポリシーのエントリから行う。 ポリシーメニューから信頼関係を選択する。 信頼する側のドメインと記された低い方のボックスの隣に二つの ボタンがある。 追加削除である。 追加ボタンは、自ドメイン内のユーザーにアクセス権限を付与することが できるリモートドメイン名を入力するパネルを開く。また、信頼するドメインが信頼される ドメインのユーザーを認証するときに使用する、信頼関係のパスワードも入力する必要がある。 パスワードは(標準的な確認の手続きとして)二度入力しなければならない。

NT4ドメイン信頼関係の構築完了

信頼関係は、もう一方のドメイン(信頼するドメイン)が信頼されるドメインと適切に接続された 場合のみ動作する。信頼関係を完成するためには、管理者はまず、ドメインユーザーマネジャを 起動し、メニューからポリシーを選択し、 それから信頼関係を選択し、信頼される側のドメイン と記されたボックスの横の追加ボタンをクリックする。パネルが 開いたらリモートドメイン名とパスワードを入力する。

ドメイン間信頼関係の機能

双方向の信頼関係は、二つの方方向の信頼がそれぞれ互いの方向に作成されることで築かれる。 二つのMicrosoft Windows NT4ドメイン間で片方向の信頼が確立されている場合(仮にDomAとDomB とする)、次の機能が可能になる:

Figure 19.1. 信頼の概要

信頼の概要

  • DomA(DomB への信頼接続を完了する)はDomBを信頼する

  • DomAが信頼するドメインである。

  • DomBが信頼されるドメインである(信頼アカウントの起点)。

  • DomB のユーザーは DomA のリソースにアクセスすることができる。

  • DomA のユーザーは DomB のリソースにアクセスすることはできない。

  • DomB のグローバル・グループは DomA で使用できる。

  • DomA のグローバル・グループは DomB では使用できない。

  • DomB は DomA のクライアントワークステーションのログオンダイアログボックスに表示される。

  • DomA は DomB のクライアントワークステーションのログオンダイアログボックスに表示されない。

  • 信頼するドメインのユーザー/グループは信頼されるドメインへの権限、許可、 アクセスは与えられない。

  • 信頼するドメインは信頼されるドメインにアクセスしたり(ユーザー/グローバルグループの) アカウントを使用することができる。

  • 信頼されるドメインの管理者は信頼するドメイン内で管理権限を付与される。

  • 信頼されるドメインのユーザーは信頼するドメインで権利や特権を付与される。

  • 信頼されるドメインのグローバルグループは信頼するドメインで権利や許可を 与えられる。

  • 信頼されるドメインのグローバルグループはMicrosoft Windowsドメインメンバー マシンのローカルグループのメンバーになることができる。

SambaにおけるNT形式のドメイン信頼関係の設定

ここでは、Samba サーバーがドメイン間の信頼関係に参加できるようにするための設定方法を、 簡潔に紹介する。Samba における信頼関係のサポートは初期段階なので、正しく機能しない ことがあっても驚かないこと。

下記における手順の説明では、信頼関係の相手先のドメインは、Windows NT4 サーバーで管理 されていると仮定する。しかし、リモート側は Samba-3 ドメインであっても構わない。 この文書を読み終わるころには明らかになることであるが、以下に書かれている説明のうち、 Samba固有の部分のみを合わせると、純粋なSamba環境におけるドメイン信頼の構築の説明と なる、ということである。

信頼されるドメインとしてのSamba

Samba PDC を、信頼関係のある二者のうち信頼される側に設定するためには、まず信頼する側の ドメインのための特別なアカウントを作成する必要がある。そのためには smbpasswdユーティリティを使う。信頼されるドメインアカウントを 作成するのは、信頼されるマシンアカウントを作成するのに似ている。仮にドメイン名をSAMBA とし、リモートドメインをRUMBAとする。最初のステップは好みのシェルからこのコマンドを 発行することである:

root#  smbpasswd -a -i rumba
New SMB password: XXXXXXXX
Retype SMB password: XXXXXXXX
Added user rumba$

ここで、-aはパスワードデータベースの中に新規のアカウントを追加するこ とを意味し、-iは、 このアカウントをドメイン間の信頼フラグ付きで作成せよということを意味する。

このアカウント名はrumba$(リモートドメインの名前)である。もしもこの ステップが失敗した場合、信頼アカウントがシステムのパスワードデータベース (/etc/passwd)に追加されたか確認すること。もしも追加されて いなければ、手動で追加し、上のステップを再度行うこと。

このコマンドを実行後、そのアカウントのパスワードの入力要求が来る。ここでは任意の パスワードを使用できるが、Windows NTではアカウント作成後7日間はパスワードを変更できない ので、注意すること。コマンドの実行が成功すると、新しいアカウントのエントリを、 (設定した環境でのの標準的な方法で)見ることができるので、アカウント名が本当にRUMBA$で、 フラグ欄にIが設定されているか確認する。この信頼関係の設定を完成する ために、次は Windows NTサーバーの方から信頼を設定する。

ドメインユーザーマネージャを開き、メニューから ポリシーを選び、信頼関係を選択する。 信頼されたドメインリストボックスのそばの追加 ボタンをクリックする。信頼されたドメインの名前とそのパスワードを入力するダイアログ ボックスが表示される。リモートドメインの名前としてSAMBAを入力し、アカウント作成時に 使用したパスワードを入力する。OKをクリックし、すべてが何事も なくうまくいくならば、 信頼関係が確立しました(訳注:英文では Trusted domain relationship successfully established )が表示される。

信頼するドメインとしてのSamba

ここでは作業の順番が逆になる。今回も、Samba PDCに管理されるドメインを「SAMBA」とし、 NTが管理するドメインを「RUMBA」とする。

一番初めのステップはRUMBAのPDCにSAMBAドメインのアカウントを追加することである。

ドメインユーザーマネージャを起動し、ポリシー信頼関係を選択する。次に、 信頼するドメインのボックスのそばの追加 ボタンをクリックし、信頼されるドメイン(SAMBA)の名前を入力し、信頼関係を確立するために 使用するパスワードを入力する。

パスワードは任意に選択できる。Sambaサーバーでは、いつでも容易にパスワードを変更することが できる。パスワードを確定するとアカウントは準備完了である。次は Sambaの番である。

rootでログインし、好みのシェルを使って以下のコマンドを発行する:

root# net rpc trustdom establish rumba

Windows NT4サーバーで入力したばかりのパスワードが聞かれる。時々、 NT_STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNTというエラーメッセージが 現れるが、問題はないので無視して構わない。これは入力したパスワードが正しく、この アカウントは通常の接続ではなく、ドメイン間接続のための準備ができている、と NTサーバーが 言っている、という意味である。その後、(大規模ネットワークの場合は特に)しばらく時間が かかるかもしれないが、我慢する。しばらくするとSuccessという メッセージが表示される。おめでとう! これで信頼関係が成立した。

Note

secrets.tdbファイルに書き込み権がなければならないので、上記の コマンドはrootとして実行すること。

Windows 2000との間での、NT4形式のドメイン信頼関係

ドメインユーザーマネージャが無いにもかかわらず、ミックスモードで 動作するWindows 2000ドメインコントローラーを、信頼するサーバーとして、NT4形式の信頼関係を設定 することは可能である。また、SambaがWindows 2000サーバーを信頼することもできるはずだが、 この領域ではさらにテストが必要である。

前述のように、 Sambaサーバー上でのドメイン間信頼関係の作成 で、信頼関係を作成したら、SambaユーザーにアクセスさせたいリソースのあるドメインのAD コントローラー上で、Active Directoryドメインと信頼関係 ダイアログボックスを開く。NT4形式の信頼関係は推移的ではないので、自ドメインのユーザーが、 AD内の複数のミックスモードのドメインにアクセスできるようにしたい場合は、各ドメインに ついて上記の手順を繰り返さなければならない、ということを忘れないこと。 Active Directoryドメインと信頼関係を開き、Samba ドメインを信頼する Active Directory ドメインの名前を右クリックし、プロパティを選択し、 信頼タブをクリックする。パネルの上部に このドメインによって信頼されるドメイン:という名前の付いた一覧が 表示され、その隣に追加...ボタンがある。このボタンをクリックすると、 NT4のように、信頼されるドメインの名前と関係パスワードを聞かれる。OK をクリックし、しばらくすると、 Active Directoryから、信頼されるドメインが追加されて信頼関係が確認された というメッセージが表示される。これで、自システムのSamba ユーザーに、ADドメインの リソースへのアクセス権限が付与された。

よくあるエラー

ドメイン間の信頼関係は、不安定な、又は頻繁にダウンするようなネットワークで試みるべきでは ない。ネットワークの安定性と整合性は、分散型ネットワークにおけるドメイン間の信頼関係の ための必須要件である。

信頼されるドメインからのブラウジングに失敗する

信頼されるWindows200xドメインのマシンから信頼するSambaドメインのWindows200x メンバーをブラウズしようとすると、次のエラーが出

システムはセキュリティを侵害しようとするような行為を検出しました。
認証を受けるサーバーに連絡が取れることを確認してください。

接続しようとしているサーバーのイベントログに、下位レベルのドメインのメンバーで あるためにグループポリシーが適用されない、というエントリがある。

問題のマシンのコンピュータアカウントが Windows200xドメインにあり、それが無効化されて いる場合にこの問題が起こり得る。コンピュータアカウントがない(削除されたか、もともと 存在しない)か、そのアカウントを有効になっていない(すなわち、そのアカウントを他の ドメインに参加させただけという)場合は、問題は起こらないようである。既定値では、 ドメイン(Windows 200xドメイン) から離脱する場合、コンピュータは自動的にドメイン内の コンピュータ・アカウントを無効にしようとする。アカウントを無効化する権限をもつ アカウントととして操作していた時にドメインからマシンを離脱した場合、アカウントの 無効化が実行される。そうでなければ実行されない。

LDAP ldapsamと古いバージョンのsmbldap-toolsに関する問題

ドメイン間の信頼関係を設定するために、信頼アカウントを作成するために、 smbldap-useraddスクリプトを使うと、信頼関係の設定処理は失敗する。 LDAPデータベース中に作成されたアカウントはアカウントフラグとして [W ]となっていて、ドメイン間の信頼関係が動作する時に 必要である[I ]がない。

これに対する簡単な解決方法がある。 以下のようにして、マシンアカウントを作成する:

root#  smbldap-useradd -w domain_name

次に、信頼アカウントのパスワードを設定する:

root#  smbldap-passwd domain_name\$

テキストエディターを使って以下のファイルを作成する:

dn: uid=domain_name$,ou=People,dc={your-domain},dc={your-top-level-domain}
changetype: modify
sambaAcctFlags: [I         ]

次に、以下のようにして、LDAPデータベースにテキストファイルを適用する:

root#  ldapmodify -x -h localhost \
 -D "cn=Manager,dc={your-domain},dc={your-top-level-domain}" \
 -W -f /path-to/foobar

NT4のドメインユーザーマネージャから片方向の信頼関係を作成した後、以下を実行する:

root#  net rpc trustdom establish domain_name

この機能は Samba-3とNT4ドメインで動くし、Samba-3とミックスモードの Windows 200x ADSでも 動作する。sambaとNTの両方のDCが同じWINS サーバーを使用していなければならず、 そうでなければ信頼関係は動作しない。

Chapter 20. Microsoft 分散ファイルシステムツリーのホスティング

Shirish Kalele

Samba Team & Veritas Software

John H. Terpstra

Samba Team

12 Jul 2000

特徴と利点

分散ファイルシステム (DFS) はネットワーク上にある資源について実際の物理的な配置 から、ユーザーが見ているファイルとディレクトリの論理的ビューを切り離す手 段を提供する。 高い可用性と円滑なストレージ拡張、負荷分散などを可能にする。

DFS の情報について、Microsoft documentationを参照のこと。 この文書は、 Samba を利用している UNIX で (DFS対応クライアントがブラウズするため) DFS ツリーを どのようにホスティングするか説明する。

Samba サーバーは、smb.conf ファイルのグローバル Boolean パラメーター host msdfsを設定することで DFS サーバーにできる。 共有レベルの論理値パラメーターmsdfs rootによっ て共有を DFS ルートとして指定できる。 Samba 上の DFS ルートディレクトリはシンボリックリンクの形式で DFS リンクを提供 できる。例えば、共有ディレクトリ内のシンボリックリンク junction->msdfs:storage1\share1 は DFS ジャン クション (接点) として機能する。 DFS 対応クライアントがジャンクションリ ンクにアクセスしようとするとき、それらは実際のストレージ ( この場合 は \\storage1\share1 ) にリダイレクトされる。

Samba 上の DFS ツリーは、 Windows 95 から Windows 200x までの DFS 対応クライア ントをサポートしている。 以下の設定例は、 Samba サーバーでどのよう に DFS ツリーを設定するかを示す。 ディレクトリ/export/dfsroot 内で、他のネットワーク上のサー バへの DFS リンクを設定する。

root# cd /export/dfsroot
root# chown root /export/dfsroot
root# chmod 755 /export/dfsroot
root# ln -s msdfs:storageA\\shareA linka
root# ln -s msdfs:serverB\\share,serverC\\share linkb

Example 20.1. DFS が設定された smb.conf

[global]
netbios name = GANDALF
host msdfs = yes
[dfs]
path = /export/dfsroot
msdfs root = yes

DFS ルートとして使用しているディレクトリのパーミションと所有者の設定を行い、 特定のユーザーだけが msdfs リンクを作成、削除、変更できるように設定すべきであ る。 シンボリックリンク名は、すべて小文字にすべきことに留意すること。この制約は、 Samba が、リンク名を取得するために、すべての大文字、小文字の組み合わせを試 すことを避けるために設けられている。 最後に、ネットワーク上の共有したいところへシンボリックリンクを張り、Sambaを起動する。

これで DFS 対応クライアントは、 \\samba\dfs にある Samba サーバー上の DFS ツリーをブラウズすることができる. リンクa,リンクb(クライアントからはディレクトリとしてみることができる) に アクセスすると、ユーザーは直接ネットワーク上の共有資源にアクセスす ることになる。

よくあるエラー

  • Windows クライアントは、以前 DFS でなくマウン トされていたものが、 DFS ルートとしてマウントされたり、その逆 を行ったりすると、 リブートする必要がある. よりよい解決方法は、新規の共有として 公開し、DFS ルートとすることである。

  • 現状では制約事項として、msdfs シンボリックリン ク名はすべて小文字で記述される必要がある。

  • セキュリティのために、DFS ツリーのルートとな るディレクトリは、特定のユーザーのみがそのディレクトリ内でシンボ リックリンクを変更できるように所有者とパーミッションを設定する 必要がある。

MSDFSのUNIXパスは大文字小文字を識別する

あるネットワーク管理者は何故 DFS が機能しなかったかを究明しようとした長い会議 の後に Samba メーリングリストにアドバイスを送った。 彼のアドバイスには注意する価値がある。

私の特定の DFS ルートが機能しない理由を解明するためにいくらかの時間を費やした。 私はシンボリックリンクはすべて小文字で記述するべきであると文書に書かれているこ とに気がついた。シンボリックリンクへのフルパスをも小文字で書き直すことにした。

設定例: 以下のように定義された共有がある

[pub]
path = /export/home/Shares/public_share
msdfs root = yes

そして (DFS クライアントがインストールされた) Windows で、以下のシンボリックリンクをたどることができなかった。

		damage1 -> msdfs:damage\test-share
		

デバッグレベルを10にして実行して明らかになったこと

		[2003/08/20 11:40:33, 5] msdfs/msdfs.c:is_msdfs_link(176)
		  is_msdfs_link: /export/home/shares/public_share/* does not exist.
		

気になる。 私はディレクトリ名 を .../Shares/... から .../shares/... に変更した。 (サービス定義 に伴って) そして、機能するようになった!

Chapter 21. 旧式の印刷サポート

Kurt Pfeifle

Danka Deutschland GmbH

Gerald (Jerry) Carter

Samba Team

John H. Terpstra

Samba Team

May 31, 2003

Table of Contents

機能と利便性
技術的な序論
クライアントからSambaへの印刷ジョブの処理
印刷に関連する設定パラメーター
簡単な印刷設定
testparmによる設定の検査
手っ取り早い設定の検証
拡張印刷設定
設定の説明詳細
Samba-2.2からの印刷環境
Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー
無効になった [printer$]セクション
[print$]共有の作成
[print$]セクションのパラメーター
[print$]共有ディレクトリ
[print$]へのドライバーのインストール
プリンターの追加ウィザードによるドライバーのインストール
rpcclientを使った印刷ドライバーのインストール
クライアントドライバーのインストール方法
最初のクライアントドライバーインストール
新しいプリンターに対するデバイスモードの設定
追加のクライアントドライバーインストール
常時最初のクライアントからの接続はrootかprinter adminで行う
その他のテクニック
クライアントドライバーのための既定値の印刷操作の設定
大量のプリンターのサポート
Windows NT APWによる新しいプリンターの追加
エラーメッセージ: 異なった名前で接続できない
ドライバーファイルを集めるときに気をつけること
Sambaとプリンターポート
共通クライアントドライバーの間違った設定の防止
Imprintsツールセット
Imprintsとは何か?
プリンタードライバーパッケージの作成
Imprintsサーバー
クライアントのインストール
ユーザーによるインストールなしにネットワークプリンターを追加する
addprinterコマンド
旧式の印刷システムの、Sambaへの移行
Active DirectoryかLDAPへのプリンター情報の公開
よくあるエラー
rootパスワードを指定したが、アクセスできない
印刷ジョブはスプールディレクトリに入ったが、その後なくなった

機能と利便性

印刷はユーザーに取ってしばしばミッションクリティカルなサービスである。Sambaは、 Windows ワークステーションからなるクライアントネットワークのために、信頼性が あり、シームレスなこのサービスを提供出来る。

Samba印刷サービスは、ファイルサービス機能と並列に、あるいは専用のサーバー上で、スタンド アロンかドメインメンバーサーバーで動かす事が出来る。これは、必要に応じて強力に、あるいは 比較的穏やかにセキュアにすることが出来る。設定は簡単になることも複雑になることもある。 有効な認証スキームは、以前の章にあるようなファイルサービス用に説明されたのと基本的に 同じである。全体的に、現在、Sambaの印刷サポートは、多くの場合、付加機能を付けた上で、 Windows NTまたはWindows2000印刷サーバーと完全に対等で、置き換えることが出来る。 クライアントはクライアント上でなじみのあるポイント アンド プリント メカニズムを通して、ドライバーをダウンロードし、プリンターをインストールできる。 ログオンスクリプトで実行されるプリンターのインストールは何の問題もない。 管理者はおなじみのプリンター追加ウィザードを使ってクライアントで 使うことによって、ドライバーのアップロードと管理ができる。更に追加の便利な機能としては、 ドライバーとプリンター管理はコマンド行かスクリプトを通して実行でき、これは、大量の プリンターがある場合により効率的である。もしも、集中した印刷ジョブの利用状況管理 (訳注:原文はaccount)(すべての単一ページの追跡といろいろな統計レポートに生データを 供給すること)が必要とされる場合、この機能は、Sambaサーバー下の印刷サブシステムとして、 新しい共通UNIX印刷システム(CUPS)によって最もよくサポートされている。

この章では、より現代的なUNIXのBSDとSystem V形式の印刷システムによって実装された、 Sambaの印刷機能の基礎を概観する。この章中の情報の大多数はCUPSにも適用出来る。 もしもCUPSを使っているならば、次の章に飛んでも良いが、すべきことのうち少なくとも いくつかはきっと取りこぼすだろう。さらなる情報は、 CUPS 印刷環境を参照のこと。

Note

ほとんどの以下の例はWindows XP Professionalクライアントで評価されている。この文書で コマンドを発行した結果を記述しているところは、Windows 200x/XPクライアントでほとんど 同じだが詳細では多少違っている事を心に留めておくこと。Windows NT4は更に多少異なる。

技術的な序論

Sambaの印刷サポートは、常時それが動作しているUNIX OS上の、インストールされている印刷 サブシステム上に依存している。Sambaは仲介者である。Windows(か 他のSMB)クライアントから印刷ファイルを受け取り、それをさらなる処理のために実際の印刷 システムに渡す。そのため、両方に接続する必要がある。すなわち、Windows印刷クライアントと UNIX印刷システムである。それゆえ、異なった機能と異なった形でアクセスされる、種々の UNIX印刷サブシステムと同様、おのおのが異なって振る舞う種々のクライアントOSの間での違いを 認める必要がある。

この章では伝統的なUNIX印刷方式について取り扱う。次の章では、より最新のCUPSについて、 より詳しく説明する。

Important

CUPSユーザーに注意:次の章まで飛ばないこと。ここのみで説明がある重要な情報を読み飛ばすことになる!

現在、Samba管理の側面において、最も問題があることの一つは印刷の設定であることは、Samba メーリングリスト上で投稿されたことでも明らかである。多くの新しいSamba管理者は、Sambaが ある種の印刷処理を実行しているというような印象を持っている。保証するが、Sambaは 何らの印刷処理をも実行しない。何らの印刷フィルタリングも行わない。

Sambaは、ローカルスプール領域にスプールされる、クライアントからデータストリーム (印刷ジョブ)を受け取る。印刷ジョブ全部を受け取ると、SambaはローカルのUNIX/Linux印刷 コマンドを起動し、それに対してスプールされたファイルを渡す。それはローカルの印刷 サブシステムを起動し、正しく印刷ジョブを処理し、プリンターに対してデータを渡す。

クライアントからSambaへの印刷ジョブの処理

Sambaサーバー経由でWindowsクライアントからUNIXプリンターへの印刷がうまくいくためには、 6つ(潜在的には7つ)のステージがある:

  1. プリンター共有に対してWindowsがコネクションをオープンする。

  2. Sambaはユーザーを認証しなければならない。

  3. Windowsがネットワーク経由でSambaのスプール領域に印刷ファイルの コピーを送る。

  4. Windowsはコネクションをクローズする。

  5. Sambaは、UNIX印刷サブシステムの印刷領域経由でファイルを扱う ために印刷コマンドを起動する。

  6. UNIX印刷サブシステムが印刷ジョブを処理する。

  7. 印刷ファイルはSambaスプール領域から明示的に削除される必要がある。 これの要素は使用しているマシンのプリントスプーラの構成の設定に依存する。

印刷に関連する設定パラメーター

Sambaの印刷動作を制御するための設定パラメーターは多数ある。それらの概要については smb.confのマニュアルページを参照してほしい。他のパラメーターと同様、グローバルレベル (一覧上でGとタグが付いているもの)とサービスレベル (S)パラメーターがある。

グローバルパラメーター

これらは明示的に共有定義に記述しなくても良い。 もしもエラーになったならば、(もしも動作させたならば)testparm ユーティリティでそれを見つけることが出来、そのことを表示する。

サービスレベルパラメーター

これらはsmb.conf中の[global] セクションで指定しても良い。この場合、個人毎すべてかサービスレベルの 共有の既定値の動作を定義する(同じパラメーターに対して異なった設定の定義を を持たない形で提供されるので、グローバルの既定値を上書きする)。

簡単な印刷設定

BSD印刷環境での簡単な設定は、簡単な印刷の設定を示して いる。もしも現在使っている環境と比較して、OSベンダによってあらかじめ設定されている追加の パラメーターを見つけるかもしれない。以下は、パラメーターについての議論と説明である。この例は 多くのパラメーターを使っていない。しかし、多くの環境において、すべてのクライアントに対して 印刷を有効にする有効なsmb.confファイルを提供するためには、これは十分である。

Example 21.1. BSD印刷環境での簡単な設定

[global]
printing = bsd
load printers = yes
[printers]
path = /var/spool/samba
printable = yes
public = yes
writable = no

これは単に例としての設定である。Sambaはすべての設定パラメーターに対して既定値を割り当てて いる。既定値は保守的でかつ賢明な値となっている。パラメーターがsmb.confファイル中で指定 されたならば、それは既定値を上書きする。rootでtestparmユーティリティ を実行すると、smb.confファイルの設定のように両方の既定値とすべての設定を報告する 機能がある。Testparmは間違った設定のすべてに対して警告を表示する。 完全な出力は360行を軽く超えるので、その結果をページャープログラムに渡しても良いだろう。

設定ファイルの文法は理解するのが簡単である。その文法について細かいことを知らなくても よい。この文書のどこかで説明されているが、Sambaはある種の綴りミスには寛容であり (たとえば、browsableの代わりにbrowseable など)、綴りは大文字小文字を無視する。論理値に対して、Yes/NoTrue/Falseを使うことも出来る。名前のリストは、カンマ、空白か タブで分離できる。

testparmによる設定の検査

暗黙で使えるものを含む、Samba中で印刷に関連したすべての(あるいはほとんど全部)を見る ためには、以下で概要を説明しているコマンドを使う。このコマンドは testparmの出力中に現れるすべての lpprintspooldriver, ports[を検出する。これは、動作している smbdの印刷設定の簡便な概要を提供する。このコマンドは個別に作成された プリンター共有かそれが使えるスプールパスを表示しない。 上記の例で示される設定で設定したSambaの出力は以下の ようになる:

root# testparm -s -v | egrep "(lp|print|spool|driver|ports|\[)"
 Load smb config files from /etc/samba/smb.conf
 Processing section "[homes]"
 Processing section "[printers]"
 
 [global]
        smb ports = 139 445
        lpq cache time = 10
        load printers = Yes
        printcap name = /etc/printcap
        disable spoolss = No
        enumports command =
        addprinter command = 
        deleteprinter command = 
        show add printer wizard = Yes
        os2 driver map =
        printer admin =
        min print space = 0
        max print jobs = 1000
        printable = No
        printing = bsd
        print command = lpr -r -P'%p' %s
        lpq command = lpq -P'%p'
        lprm command = lprm -P'%p' %j
        lppause command =
        lpresume command =
        printer name =
        use client driver = No

 [homes]

 [printers]
        path = /var/spool/samba
        printable = Yes

Sambaの既定値の動作によって暗黙で追加される設定を検査するのは簡単である。 確認:Sambaの将来の関係で重要かもしれない。

Note

Samba-3中のtestparmは2.2.xのものとは動作が異なる。-v スイッチなしで使うと、実際に書かれた設定のみを表示する。使用している完全な設定を見る ためにはtestparmに-vオプションを追加する。

手っ取り早い設定の検証

どのようなステージでもトラブルシュートをする必要があるので、常時、最初にこの点に戻り、 testparmが期待しているパラメーターを表示するかを検査する。 個人的な経験から忠告すると、load printersパラメーターを コメントアウトすることを試すこと。もしも2.2.xシステムの動作が、私の環境のようで あれば、以下のような表示が出る:

root# grep "load printers" /etc/samba/smb.conf
        #  load printers = Yes
        # This setting is commented out!!
 
root# testparm -v /etc/samba/smb.conf | egrep "(load printers)"
        load printers = Yes

この設定をコメントアウトするとSambaが自分のプリンターを公開させなくすると仮定したが、 実際には引き続き公開している。理由を理解するのには時間がかかった。少なくともこれに よって、もはや馬鹿にされることはない。

root# grep -A1 "load printers" /etc/samba/smb.conf
        load printers = No
        # The above setting is what I want!
        #  load printers = Yes
        # This setting is commented out!

root# testparm -s -v smb.conf.simpleprinting | egrep "(load printers)"
        load printers = No

パラメーターを明示的にload printers = Noに設定する時 にのみ、Sambaは意向にかなう。そのため、以下を強く推奨する:

  • コメントアウトしたパラメーターには決して頼らない。

  • 常時、そう動作させたいと意図するものについては、明示的に パラメーターを設定する。

  • 意向を反映しないかもしれない隠れた設定を、見える化するために testparmを使う。

以下は最小の設定ファイルである:

root# cat /etc/samba/smb.conf-minimal
        [printers]

この例は、任意のSamba構成ファイルをテストするために、testparmを 使って表示すべきである。実際、現在動いているシステム(正確に何をやっているか知っている 限り)を変更しないことを勧める。smbd再起動後にのみ変更の影響が 反映されるという仮定に頼ってはいけない!これは本当ではない。Sambaは60秒ごととクライアント からの接続時に再読込を行う。適用する事を意図しない製品のクライアントのために、変更に 直面しなければならないかもしれない。そのほか、いくつかの興味深いことに注意するとよい。 testparmは、この最低限の構成を使う時にSambaの印刷設定がどうあるかを 識別するために便利である。以下では、見つけようと思っているものがある:

root# testparm -v smb.conf-minimal | egrep "(print|lpq|spool|driver|ports|[)"
 Processing section "[printers]"
 WARNING: [printers] service MUST be printable!
 No path in service printers - using /tmp

        lpq cache time = 10
        load printers = Yes
        printcap name = /etc/printcap
        disable spoolss = No
        enumports command =
        addprinter command =
        deleteprinter command =
        show add printer wizard = Yes
        os2 driver map =
        printer admin =
        min print space = 0
        max print jobs = 1000
        printable = No
        printing = bsd
        print command = lpr -r -P%p %s
        lpq command = lpq -P%p
        printer name =
        use client driver = No

 [printers]
        printable = Yes

testparmは2つの警告を表示する:

  • [printers]セクションが印刷可能と指定していない。

  • どのスプールディレクトリを使うかをSambaに指定していない。

しかし、これは致命的ではなく、Sambaは動作するように既定値を設定する。が、この例を 頼らず、使わないでほしい。これは、自分が何を要求しているかを正確にわかっている設定と 注意深い設計を手助けするために用意された。使用しているシステムからの結果は、異なった コンパイル時オプションによって構築されたSambaで、いくつかのパラメーターによっていろいろと 変わる。警告:有効な行の行末にコメントサイン を置いてはいけない。この場合、パラメーターは無視される(行頭にコメントサインを置いたのと 同じになる)。最初にこれは使用しているSambaのバージョンのバグではないかと思った。しかし、 マニュアルページには明確に パラメーター値の内部の空白は、正確にその通りに保持されると書いてある。 これは、たとえば以下のような行があると

# これはLPRngを印刷システムとして定義する。
printing = lprng

定義したい値として=記号の後の文字列すべてを尊重する。これは、不正な 値なので無視され、この場所では既定値が使われる。

拡張印刷設定

拡張BSD印刷環境の設定は、BSD形式の印刷設定中の印刷に 関連した設定のためのより詳細な設定を表示する。下記は、いろいろなパラメーターの議論と 説明である。昔からのUNIX/Linuxマシン上で最も一般的に使われているので、BSD形式の 印刷環境を使う事をした。主に新しいシステムでは、別の章で議論されているCUPSを使う だろう。例は、既定値で設定されていないという理由で、指定するのが不要なたくさんの パラメーターを明示的にリストアップする。よりスリムなsmb.confを使うことも、 testparmを使う事も、既定値に設定されているすべてのパラメーターを smb.confから削除して最適化するために、SWATを使う事もできる。

Example 21.2. 拡張BSD印刷環境設定

[global]
printing = bsd
load printers = yes
show add printer wizard = yes
printcap name = /etc/printcap
printer admin = @ntadmin, root
max print jobs = 100
lpq cache time = 20
use client driver = no
[printers]
comment = All Printers
printable = yes
path = /var/spool/samba
browseable = no
guest ok = yes
public = yes
read only = yes
writable = no
[my_printer_name]
comment = Printer with Restricted Access
path = /var/spool/samba_my_printer
printer admin = kurt
browseable = yes
printable = yes
writable = no
hosts allow = 0.0.0.0
hosts deny = turbo_xp, 10.160.50.23, 10.160.51.60
guest ok = no

これは設定の例である。OSベンダによって提供されている設定ファイル中でのすべての設定は ここにはない。明示的に設定されていないSamba設定パラメーターは、既定値で賢明な値に設定 されている。すべての設定を見るには、rootになり、 testparmユーティリティを使う。testparmは 設定の間違いを指摘する。

設定の説明詳細

以下は拡張BSD印刷環境の設定についての議論である。

[global]セクション

[global]セクションは4つの特別なセクションの1つであり (残りは[homes], [printers][print$])、これらはサーバー全体に適用されるすべてのパラメーターを 含んでいる。ここにはグローバルな意味を持つパラメーターのみが配置される。すべての他の セクションと共有に対しての既定値の設定を定義する、サービスレベルのパラメーターを含む こともできる。この方法は設定を簡単化し、同じ値を繰り返し設定することを防ぐ(設定 できる個別のセクションか共有内で行えるが、グローバルに設定した共有の設定と他の値の 指定を上書きする)。

printing = bsd

BSD(RFC 1179形式かLPR/LPD)として知られてもいる)BSDのために適用出来る Sambaが使う既定値の印刷コマンドを指定する。一般的に、 printingパラメーターは、仮定している印刷サブシステム をSambaに告げる。SambaはCUPS, LPD, LPRNG, SYSV, HPUX, AIX, QNXと PLPを サポートしている。各システムは異なったprint command (と他のキュー制御コマンド)を既定値としている。

Caution

printingパラメーターは通常サービスレベルの パラメーターである。[global]セクション中のここに 含まれた後、異なった設定をしていないすべてのプリンター共有に効果が及ぶ。 Samba-3はもはやSOFTQ印刷サービスをサポートしない。

load printers = yes

Sambaにすべての有効なプリンター共有を自動的に作成させる。有効なプリンター 共有はprintcapファイルをスキャンすることで調べる。作成されたすべての プリンター共有はブラウジングでも表示される。もしもこのパラメーターを使う 場合、各プリンター毎に分割する必要はない。自動的に作成されたプリンター 共有のおのおのは、[printers]セクション中に ある設定オプションの設定の複製である (load printers = noの設定は、 誰でも見えて使えるようにしたくないいくつかのものをする(leaving out)、 各UNIXプリンターを指定できるようにする)。

show add printer wizard = yes

設定は通常既定値によって有効になっている(たとえパラメーターがsmb.conf 中で指定されていなくても)。これは、Sambaホストの共有リストの中での プリンターフォルダー中に プリンター追加ウィザードが出る原因である( ネットワークコンピュータnet viewコマンドで見られる)。これを無効にするには、 明示的にnoと設定する必要がある(コメントアウトは 十分ではない)。プリンター追加ウィザード[print$]共有にプリンタードライバーをアップロード させ、それをプリンターに関連づけるか(もしもそれぞれのキューが動作の前に 存在するならば)、以前にアップロードされたドライバーとプリンタードライバーを 交換する)。

max print jobs = 100

ある時間にSambaサーバー上で有効な印刷ジョブを最大100までに設定する。この数よりも 大きなジョブをクライアントが投稿すると、"サーバー上に容量がありません"という エラーメッセージがSambaサーバーからクライアントに返す。ゼロという設定(既定値) は全く制限がない事を意味する。

printcap name = /etc/printcap

Sambaに有効なプリンター名ののリストがどこにあるかを告げる。CUPSを使って いる場合、printcapファイルが書かれているかを確認する。これは cupsd.confファイル中のPrintcap ディレクティブによって制御される。

printer admin = @ntadmin

ntadminグループメンバーはドライバーを追加するためとプリンタープロパティを設定することが 出来るようにすべきである(ntadminは単なる例としての名前で ある。有効なUNIXグループ名が必要である)。rootは暗黙的にいつでも printer adminである。グループ名の前に付く @記号は/etc/group中の名前である。 printer adminは、MS-RPC (Samba-2.2からの印刷環境開発を参照) によって提供されるリモート管理インタフェース経由でプリンターのすべてを操作出来る。 より大きなシステムでは、printer adminパラメーターは 通常共有単位に存在するパラメーターである。こうすると、各プリンター共有の管理者に 異なったグループを割り当てる事ができる。

lpq cache time = 20

lpqコマンドの結果のキャッシュ時間を制御する。これは、過度にlpqコマンドが 呼ばれる事を防ぎ、高負荷のプリントサーバーの負荷を減少させる。

use client driver = no

もしもyesに設定されると、Windows NT/200x/XPクライアント のみに(Windows 95/98/MEには関係ない)影響する。このパラメーターの既定値は Noで(あるいはFalse)である。 これは、Sambaサーバー上で有効なドライバーがインストールされているプリント共有 では(yestrueを設定して) 決して有効にしてはならない。より詳細な説明は、 smb.confマニュアルページを参照のこと。

[printers]セクション

printersセクションは2つめの特別なセクションである。もしもこの名前のセクションがsmb.conf 中に現れると、Samba起動時に、printcapファイル中で見つかるすべてのプリンター名に対してプリンター 共有を作成するので、ユーザーはSambaホスト上のprintcapファイル中で定義されている任意の プリンターに接続できる。このセクションを最低の設定ですべてのプリンターを共有するための、 便利なショートカットとして見なすことができる。これはまた、すべてのプリンターに対する 既定値として適用すべき設定のためのコンテナでもある(より詳細は、smb.confマニュアル ページを参照)。この内側にあるコンテナの設定は共有レベルパラメーターでなければならない。

comment = All printers

commentは、クライアントが ネットワークコンピュータnet view コマンド経由でサーバーに問い合わせた時、有効な共有一覧を表示する時に、 共有のそばに表示される。

printable = yes

[printers]サービスはprintableとして 定義されねばならない。もしもそれ以外を指定すると、 smbdは起動時にロードを停止する。このパラメーターは、このサービスに対して pathパラメーターで指定したディレクトリ中に、 オープン、書き込みとスプールファイルの投稿を、接続したクライアントに 許可する。これは、ファイル共有とプリンター共有とを区別するために、 Sambaによって使われる。

path = /var/spool/samba

入力された印刷ファイルをSambaによってスプールするためのディレクトリを 指定しなければならない。UNIX印刷サブシステムの設定中で指定された スプールディレクトリと同じに設定してはならない!パスは通常 stickyビットを設定した、その他に書き込み可能な ディレクトリを指定する。

browseable = no

printable = yesのときは常時 noに設定する。これは、共有それ自身が、 net viewコマンドか、エクスプローラーのブラウズリスト 中で有効な共有の一覧中で不可視にする(もちろん個々のプリンターを見る ことは出来る)。

guest ok = yes

もしも、このプリンターがyesに設定されているならば、 印刷サービスに接続する時にパスワードを必要としない。アクセスは、 guest accountの権限で許可される。多くのシステム では、ゲストアカウントは"nobody"という名前にマップされる。このユーザーは 通常空白のパスワード尾持つUNIXのpasswdファイルにあるが、UNIXログインは 無効である。いくつかのシステムでは、ゲストアカウントユーザーは印刷権限を 持たないかもしれない。su - guestを使い、以下の システムの印刷コマンドを動かし、使用するシステムのguestユーザー中で ロギングすることでこれをテストする:

lpr -P printername /etc/motd

public = yes

guest ok = yesの同義語である。 guest ok = yesを設定すると、 これは本当にここにある必要はない(これは 同じ共有に対して2つの矛盾している設定が偶然あるときはどうなるか? という興味深い質問を導く。答えはSambaが最後に見つけたものが使われる。 testparmは同じ共有に対して同じパラメーターに対する 異なった設定に対しては注意を喚起しない。異なったユーザー名で guest accountパラメーターに対して複数の行を 設定することでこれをテストでき、次にtestparmを動作させて、どの行が Sambaによって本当に使われるかを見る事ができる)。

read only = yes

通常(共有の他のタイプのために)サービスのディレクトリ中で、ユーザーによる ファイルの作成と変更を防止する。しかし、printable サービス中では、常時ディレクトリへの書き込みが許可 されるが(もしもユーザーの権限として接続が許可されているならば)、 それは印刷スプール操作経由でのみである。通常の書き込み操作は許可 されない。

writable = no

これはread only = yesの同義語である。

任意の[my_printer_name]セクション

もしも、[my_printer_name]セクションが、 printable = yesを含んでsmb.confファイル中にある 場合、Sambaはこれをプリンター共有と見なして設定する。Windows 9x/Meクライアントは、 共有名が8文字以上の場合、接続かプリンタードライバーのロードで問題が発生するかもしれない。 存在するユーザーかファイル共有の名前と競合する、プリンター共有名を付けてはならない。 クライアントからの接続時に、Sambaは常時その名前を最初に持つものを見つけようとする。 もしもそれが見つかると、これに対して接続を行い、同じ名前を持つプリンター共有には接続 できない!

comment = Printer with Restricted Access

上記で書いたとおりのコメントである。

path = /var/spool/samba_my_printer

このプリンターに対するスプール領域のディレクトリを既定値の代わりに設定する。 これは異なって設定する必要はないが、オプションは有効である。

printer admin = kurt

printer admin定義は、この一般的な[printers]共有から 明示的に定義されたプリンター共有と違う。もし要求がなければ、可能であればそれを 表示しない。

browseable = yes

これは、クライアントが、ネットワークコンピュータで ブラウズするのが便利なように、プリンターをブラウズ可能にする。

printable = yes

20.4.1.2節を参照。

writable = no

20.4.1.2節を参照。

hosts allow = 10.160.50.,10.160.51.

hosts allowhosts deny パラメーターを使って特定の数値でのアクセス制御を試す。これは、決して安全な 賭けではない。これは使用しているプリンターをセキュアにする方法ではない。この 行は、最初に評価されるアクセス制御中での特定のサブネットからの、すべての クライアントを許可する。

hosts deny = turbo_xp,10.160.50.23,10.160.51.60

すべての一覧表示されたホストはここでは許可されない(たとえ許可された サブネットにあったとしても)。見ての通り、NetBIOSホスト名をここに書くのと 同様にIPアドレス名前を付けることが出来る。

guest ok = no

このプリンターはゲストアカウントには公開していない。

印刷コマンド

各セクション(か[printers]セクション中で)はプリンターを 定義し、print commandは定義されるかもしれない。これは、その プリンターに対するSambaの印刷スプールディレクトリ中に位置するファイルを処理するコマンドを 設定する。(もしも覚えているならば、このスプールディレクトリはpath パラメーターで設定される)。通常、このコマンドはSambaが動いているホストの印刷サブ システムに、適切なシステムの印刷コマンドを使ってスプールファイルを渡す。しかし、もしも この必要性に要求がなければ、たぶんそうだろう。デバッグかその他の理由で、ファイルの印刷 より何かが完全に異なることを行う事を望んでも良い。例は、プリンティングをデバッグする ために必要とする時、さらなる調査のために一時的な場所に印刷ファイルをコピーするだけの コマンドである。もしも、固有の印刷コマンドを作る場合(か印刷コマンドシェルスクリプトの 開発)、Sambaスプールディレクトリからファイルを削除する必要があることに注意をはらうこと。 そうしないと、すぐにディスクがいっぱいになってしまうだろう。

既定値のUNIXシステム印刷コマンド

設定ファイル中で明示的に設定されていない場合、Sambaがほとんどの場合、多くのパラメーター について、内蔵の値を使うということは、以前の説明で理解されているかと思う。 print commandでも同じである。既定値の印刷コマンドは printingパラメーターの設定に依存して変わる。 既定値の印刷設定に一覧があるコマンド中で、 Xp,s,Jのようなものである、 %X形式を持ついくつかのパラメーターに気がつくだろう。 これらの文字は、それぞれプリンターの名前、スプールファイルとジョブIDを表す。これらは、 キーとなる印刷オプションの概要を提供する 既定値の印刷設定中に詳細が説明されているが、 CUPSの場合は特別で、CUPS印刷サポートで 説明があるので、ここに記述はない。

Table 21.1. 既定値の印刷設定

設定既定値の印刷コマンド
printing = bsd|aix|lprng|plp印刷コマンドはlpr -r -P%p %s
printing = sysv|hpux印刷コマンドはlp -c -P%p %s; rm %s
printing = qnx印刷コマンドはlp -r -P%p -s %s
printing = bsd|aix|lprng|plplpq コマンドはlpq -P%p
printing = sysv|hpuxlpq コマンドはlpstat -o%p
printing = qnxlpq コマンドはlpq -P%p
printing = bsd|aix|lprng|plplprm コマンドはlprm -P%p %j
printing = sysv|hpuxlprm コマンドはcancel %p-%j
printing = qnxlprm コマンドはcancel %p-%j
printing = bsd|aix|lprng|plplppause コマンドはlp -i %p-%j -H hold
printing = sysv|hpuxlppause コマンド(...は存在しない)
printing = qnxlppause コマンド(...は存在しない)
printing = bsd|aix|lprng|plplpresume コマンドはlp -i %p-%j -H resume
printing = sysv|hpuxlpresume コマンド(...は存在しない)
printing = qnxlpresume コマンド(...は存在しない)

printing = CUPS用に、もしもSambaがlibcupsを使うようにコンパイル されたならば、ジョブの投稿にCUPS APIを使用する(通常使わない位置に自動生成された printcap ファイルに書き込むために、使用しているシステム中のcupsd.conf ファイルが設定されている場合、printcap = cupsを 設定するのはよい方法である)。ほかの場合は、Sambaは印刷処理のために、-orawオプションを 付けて、System Vの印刷コマンドにマップする。これはすなわち、 lp -c -d%p -oraw; rm %sを使うことである。 printing = cupsの場合と、もしもSambaがlibcupsを使うように コンパイルされた場合、手動で設定したprint commandは何であっても無視される!

カスタム印刷コマンド

サービスに対して印刷ジョブのスプーリングが終了後、print command はスプールファイルを処理するためにsystem()呼び出し経由でSambaによって使われる。 通常指定されたコマンドはホストの印刷サブシステムにスプールファイルを投稿する。 しかし、これが本当にそうであるというべき要求は全くない。印刷サブシステムは それ固有のスプールファイルを削除しないかもしれないので、指定したコマンドは何であっても、 それが処理された後にスプールファイルは消去されるようにすべきである。

伝統的な印刷システムに対して作成した固有の印刷コマンドを使うことについては何ら違いは ない。しかし、固有のものを動かしたくないのであれば(訳注:to roll your own)、各印刷 サブシステムに対してSambaが使う既定値の内蔵コマンドについて熟知すべきである (既定値の印刷設定を参照)。最後のパラグラフに 一覧表示されているすべてのコマンドには%Xという形式のパラメーターが ある。これらはマクロかショートカットで、真のオブジェクトの 名前のためのプレースフォルダーとして使われる。このようなプレースフォルダーを使って、 コマンドを動かしたとき、Sambaは自動的に適切な値に置き換える。印刷コマンドは すべてのSambaマクロ置換を扱える。印刷に関しては、以下の以下のものは特別に扱われる:

  • %s, %f スプールファイル名へのパス。

  • %p 適切なプリンター名。

  • %J クライアントから送られたジョブ名。

  • %c (もしも分かるならば)スプールされたジョブのページ数。

  • %z スプールされた印刷ジョブのサイズ(バイト単位)。

印刷コマンドは少なくとも%s%fのどちらか 1つを使っている必要がある。%pの使用は任意である。もしも プリンター名が指定されないと、%pは印刷コマンドから何のメッセージも なしに取り去られる。この場合、ジョブは既定値のプリンターに送られる。

[global]セクション中で指定されると、指定されたprint commandは 固有のprint commandを持たない任意の印刷サービスに対して使われる。もしも、印刷サービスの ためのprint commandも、グローバルのprint commandも指定されない場合、スプールファイルは 作成されるが処理されない!最も重要なことは、印刷ファイルは削除されず、そのため、ディスク スペースを消費してしまうと言うことである。

印刷は、nobodyアカウントを使うとき、ある種のUNIXでは失敗するかも しれない。もしもそのような事態に遭遇したら、代替のゲストアカウントを作成し、印刷権限を 付与する。このゲストアカウントを、[global]セクション中に、 guest accountパラメーターを使って設定する。

非常に複雑な印刷コマンドを構成することも出来る。印刷コマンドはUNIXシェルに渡される ようにする必要がある。シェルは通常のように指定されている環境変数を展開できる(UNIXの 環境変数$variableを、Sambaの印刷コマンドの中で指定するための 形式は%$variableである)。下記の動作する print commandの例では、以下は印刷ジョブのログを /tmp/print.logに取り、ファイルを印刷し、次にそれを削除する。 セミコロン(;)は通常通り、シェルスクリプト中でのコマンドの分離符号である:

print command = echo Printing %s >> /tmp/print.log; lpr -P %p %s; rm %s

動作させるシステム上で、通常どのようにファイルを印刷するかに例が依存することを考慮して、 固有のコマンドを変更しなければならないかもしれない。既定値の print commandパラメーターは、printing の設定状態に依存して代わる。他の例は下記の通り:

print command = /usr/local/samba/bin/myprintscript %p %s

Samba-2.2からの印刷環境

Samba-2.2.xより前は、Windowsクライアントへの印刷サーバーサポートは、 LanMan印刷機能に限定されていた。これは、Windows 9x/Me PCがプリンターを 共有するときのものと同じプロトコルレベルである。2.2.0リリースの最初から、Sambaは ネイティブなWindows NTの印刷方式のサポートを開始した。これらは MS-RPC (Remote Procedure Call)経由で実装されている。MS-RPCは すべての印刷のために、SPOOLSSという名前付きパイプを使用する。

新しいSPOOLSSサポートによって提供される追加の機能は以下を含む:

  • オンデマンドでWindows 95/98/NT/2000クライアントにプリンタードライバーのダウンロードを サポートする(Point'n'Print)。

  • Windows NTのAdd Printer Wizard (APW)か Imprintsツールセット経由で プリンタードライバーをアップロードする。

  • StartDocPrinter, EnumJobs()のような、ネイティブなMS-RPC印刷呼び出しをサポートする (Win32印刷APIについてのより詳細な情報は MSDN documentationを参照のこと)。

  • プリンターオブジェクト上のNTアクセス制御(ACL)のサポート。

  • スプールされたジョブ情報のための、内部データベースを使用することによる、プリンター キュー操作のサポートの改善(種々の*.tdbファイルによって 実装された)。

Samba-3へのアップデートによって便利になることは、そのプリンターをActive Directory(かLDAP) に公開できることである。

Microsoft Windows NTサーバーとSambaでの操作の間には基本的な違いが存在する。Windows NTは 共有しないローカルプリンターのインストールを許可する。これは任意のWindows NTマシン(サーバーか クライアント)はユーザーがワークステーションとして使えるという不自然な結果となる。Sambaは、 既定値か、プリンター固有の共有経由での特定の定義のどちらかで、有効にしたすべてのプリンターを 公開する。

Windows NT/200x/XP Professionalクライアントは標準SMBプリンター共有を使ってはならない。 それらはMS-RPCを使って他のWindows NTホスト上の任意のプリンターに直接印刷が出来る。これは、 もちろん、クライアントがプリンターリソースを提供しているリモートホスト上で必要な権限を 持っていることを仮定している。プリンターに対してWindows NTによって割り当てられている 既定値のパーミッションは、よく知られたEveryoneグループに印刷の パーミッションを与える(Windows 9x/Meタイプの古いクライアントは、共有されたプリンター への印刷のみ出来る)。

Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー

このことが意味することについて多くの混乱がある。次のような疑問がしばしば質問される。 Windowsクライアントからの印刷をサポートするためにSambaホスト上にプリンター ドライバーをインストールすることは必要か否か?答えは No で不必要である。

もちろん、Windows NT/2000クライアントではドライバーをローカルに (次にSambaベースの印刷キューに繋ぎ)インストールするためにそれらのAPWも動かすことも できる。これはWindows 9x/Meクライアントによって使われるのと同じ手法である(しかし、 Samba 2.2.0では、プリンターに対する有効なドライバーをSambaサーバーが処理することを Windows NT/2000クライアントが要求させる、というバグがある。これはSamba 2.2.1で 修正されている)。

しかし、これはSambaサーバーの[print$]共有中にプリンタードライバーを インストールする新しい機能であり、これはとても便利である。次に、 すべてのクライアント(95/98/MEを含む)はこのプリンター共有に最初に 接続した時にインストールされているドライバーを入手する。この [print$]中へのドライバーのアップロード または供託と、以下の存在するSambaプリンター共有へ、このドライバーを 結びつけることは異なった手段で達成できる:

  • NT/200x/XP Professionalクライアント上でAPWを動かす(これは95/98/MEクライアントでは動かない)。

  • Imprintsツールセットを使う。

  • smbclientrpcclientコマンド行ツールを使う。

  • cupsaddsmbを使う(CUPS印刷システムのみ動作し、LPR/LPD、LPRngなどでは動かない)。

Sambaはスプールされたファイルに対してどのような方法でも、これらのアップロードされた ドライバーを使わない。これらのドライバーは、Sambaによってサポートされている ポイントアンドプリントメカニズム経由でダウンロード、インストールする クライアントによって完全に使われる。クライアントは、プリンター(かUNIX印刷システム)が 要求する形式に印刷ファイルを生成するためにこれらドライバーを使う。Sambaが受け取る 印刷ファイルは、必要に応じてすべてのさらなる処理のために責任のある、UNIX印刷システムに 渡される。

無効になった [printer$]セクション

2.2より前のSambaのバージョンでは[printer$]という名前の 共有を使う事が出来た。この名前はWindows 9x/Meクライアントがそれによって共有される プリンターによって作成された、同じ、名前付きのサービスから取られている。 Windows 9x/Meプリンターサーバーは、プリンタードライバーのダウンロードをサポートするために、 ードオンリのアクセス(かつパスワードなし)のサービスを常時用意している。しかし、 Sambaの最初の実装では、printer driver locationという名前の、 共有単位で使われるパラメーターが使えた。これはそのプリンターに関連するドライバー ファイルの位置を指定した。printer driverという名前の他の ラメータは、クライアントに送られるプリンタードライバー名を定義する手段を提供した。

printer driver fileを含むこれらのパラメーターは、Samba-3 では取り除かれ、使う事は出来ない。共有名[print$]は ダウンロード可能なプリンタードライバーの位置のために使われる。これは、Windows NT が動いているPCが、それによって共有されるプリンターによって作成された、 [print$]という共有名から取られている。Windows NTの 印刷サーバーは、プリンタードライバーのダウンロードとアップロードをサポートするために、 読み書きアクセス(そのACLのコンテキスト中で)を提供する、 [print$]というサービスを常時提供している。これは Windows 9x/Meクライアントがこの時点で捨てられるという事を意味するわけではない。 それらにはSambaの[print$]共有がきちんとサポートする ものを使える。

[print$]共有の作成

プリンタードライバーファイルのアップロード/ダウンロードをサポートするために、まずはじめに [print$]という名前のファイル共有を作成しなければならない。 この共有の公開される名前は、Microsoft Windowsクライアント中で埋め込まれている。 これは、プリンタードライバーファイルを検索しようとした時に、正確にこの前のサービスを 探すように、Windowsクライアントがプログラムされているため、改名することは出来ない。

グローバルパラメーターを追加するためにサーバーのファイルを変更し、 [print$]ファイル共有を作成すべきである(もちろん、 たとえばpathのようないくつかのパラメーターの値は、サイトに よって適切な値に置き換えるべきである)。[print\$] の例 を参照。

Example 21.3. [print$] の例

[global]
# ドライバーの追加と設定を可能にすべき、ntdomainグループのメンバー
# プリンターのプロパティ。rootは常時'printer admin'と仮定される。
printer admin = @ntadmin
# ...
[printers]
# ...
[print$]
comment = プリンタードライバーのダウンロード領域
path = /etc/samba/drivers
browseable = yes
guest ok = yes
read only = yes
write list = @ntadmin, root

もちろん、pathパラメーターによって名付けられたディレクトリが、 UNIXファイルシステム上に存在するようにしておく必要もある。

[print$]セクションのパラメーター

[print$]smb.conf中で特別なセクションである。これは、 潜在的なプリンタードライバーダウンロードに関連する設定を含み、ローカルプリンタードライバーの インストールのためにWindowsクライアントによって使われる。以下のパラメーターはこの共有 セクションでしばしば必要とされるものである:

comment = プリンタードライバーダウンロード領域

共有リスト中に一覧表示された時に、共有のそばにあるコメント(通常Windows クライアントはそれを見る事ができないが、 smbclient -L sambaserverの出力中にも表示される)。

path = /etc/samba/printers

UNIXの観点からのWindowsドライバーファイルの保存場所の位置のパス。

browseable = no

ネットワークコンピュータでクライアントに [print$]共有を見せないようにさせる。 cmdシェルで以下を実行すると:

C:\>  net use g:\\sambaserver\print$

任意のクライアントから引き続き見る事ができる。これは、Windows エクスプローラーからネットワークドライブの割り当て からでも行う事が出来る。

guest ok = yes

すべてのゲストユーザーにこの共有をリードオンリにする。クライアント上への ダウンロードとプリンターのドライバーのインストールを行うためのアクセスは 許可される。guest ok = yesが必要かどうかは、 どのようにサイトが設定されているかに依存する。もしもユーザーがSamba ホスト上のアカウントを持つことを許可されているならば、これは何の 問題もない。

Note

もし、Sambaサーバーによって認証されることを、すべてのWindows NTユーザーが 保証されているならば(たとえば、もしも、NTドメインサーバー経由でSambaが 認証するとき、ユーザーはすでにWindows NTセッションのためにログオンするために ドメインコントローラーによって認証されていた場合)、ゲストアクセスは 不要である。もちろん、ばかげたアカウントとセキュリティについて 心配せずに、ワークグループ環境で印刷を行いたいのであれば、ゲストアクセス のための共有を設定する。同じように、[global] セクション中で、 map to guest = Bad User を追加することを考えるべきである。これを使う前に、このパラメーターが 行う事を理解しておくこと。

read only = yes

誰でもがドライバーファイルをアップロード(あるいはドライバーの設定の変更)する ことは望まないので、この共有を書き込み不可にする。

write list = @ntadmin, root

[print$]は以前の設定によってリードオンリになって いるので、write listも一緒に作成すべきである。UNIX グループは先頭に@が付いたものである。共有上にファイルの アップデートを必要とするこの一覧にあるユーザーは、(一般的にパブリックな リードオンリアクセスの例外として)書き込みが許可される。 通常この設定中で管理者レベルのユーザーのみ指名したいであろう。もしもこれが 非rootアカウントである場合、アカウントはグローバルの printer adminパラメーター中で言及されるべきである。 ファイル共有上の設定についてのより詳細な情報は、smb.confマニュアル ページを参照のこと。

[print$]共有ディレクトリ

Windows NT印刷サーバーが、複数のクライアントアーキテクチャによってドライバーのダウンロードが 出来るようにするために、[print$]サービス内にいくつかのサブ ディレクトリを作成しなければならない(すなわち、pathパラメーターに よって指定されたUNIXのディレクトリ)。これらはサポートされる各クライアントアーキテクチャ に一致する。Sambaは同様にこのモデルに追従する。[print$]共有 それ自身の名前と同じように、サブディレクトリは下記に一覧表示された名前と正確に一致 しなければならない(サポートする必要のないアーキテクチャのサブディレクトリはなくても よい)。

すなわち、下記のように、[print$]共有配下に、サポートしたい 各アーキテクチャのためのディレクトリを作成する。

[print$]--+
          |--W32X86           # serves drivers to Windows NT x86
          |--WIN40            # serves drivers to Windows 95/98
          |--W32ALPHA         # serves drivers to Windows NT Alpha_AXP
          |--W32MIPS          # serves drivers to Windows NT R4000
          |--W32PPC           # serves drivers to Windows NT PowerPC

必要とされるパーミッション

Sambaホスト上に新しいドライバーを追加するためには、2つの条件のうちの1つを真にしておかねばならない:

  • Sambaホストに接続する時に使われるアカウントはUIDが0でなければならない(すなわちrootアカウント)。

  • Sambaホストに接続する時に使われるアカウントはprinter adminリスト中に列挙されねばならない。

もちろん、接続されたアカウントは[print$]下のサブ ディレクトリファイルを追加するための書き込み許可が必要である。すべてのファイル 共有は既定値でリードオンリに設定されていることを覚えておくこと。

要求された[print$]サービスと関連したサブディレクトリを作成した 後、Windows NT 4.0/200x/XPクライアントワークステーションの所に行く。 ネットワークコンピュータマイネットワークを 開き、Sambaホストをブラウズする。所定のサーバーを選択後、その プリンターとFAXフォルダーに移動する。そうすると、Sambaホスト上で 定義されたプリンター共有にい位置するプリンターの一覧の初期値を見る事ができる。

[print$]へのドライバーのインストール

smb.conf中に[print$]共有を無事作成でき、smb.confファイルを 強制的にSambaに再読込させただろうか?であれば問題はない。しかし、新しい機能を使うには まだもう少し手間がかかる。この共有中にクライアントドライバーファイルをインストールする 必要がある。そのため、まだこの共有は空の状態である。不幸にも、そこにドライバーファイルを コピーするだけでは十分ではない。正しくインストールする必要があり、そうすると、各 ドライバーに対する適切なレコードがSamba内部データベース中に存在するようになり、 Microsoft Windowsクライアントから要求された正しいドライバーを提供することが出来るように なる。さらに、控えめに言ってもそれは厳重さが必要である。下記では [print$]中にドライバーをインストールする2つの代替方法について 説明する:

  • 任意のUNIXワークステーションから、Sambaのコマンドラインユーティリティ rpcclientを、種々のサブコマンド (adddriversetdriverなど)を組み合わせて 使う。

  • 任意のWindows NT/200x/XPクライアントワークステーションから、GUI (プリンターのプロパティプリンターの追加ウィザード) を走らせる。

後者のオプションが、おそらくより易しいであろう(たとえプロセスが最初多少奇妙に振る舞うとしても)。

プリンターの追加ウィザードによるドライバーのインストール

プリンターは、最初、実際のプリンタードライバーがそれに割り当てられていない状態で、クライ アントのエクスプローラーからアクセスされる、Sambaホストのプリンター フォルダーに一覧表示される。既定値で、このドライバーの名前は空の文字列に設定されている。 これは変更しなければならない。NT/2000/XPクライアントから、ローカルの プリンター追加ウィザード(APW)を動かすことで、この作業ができる。

有効なプリンタードライバーのインストールは簡単である。ドライバーを割り当てたいプリンターに 対するプリンターのプロパティを表示させなければならない。Windowsのエクスプローラーを 起動し、ネットワークコンピュータを開き、Sambaホストをブラウズし、 Sambaのプリンターフォルダーを開き、プリンターアイコンを右クリックし、 プロパティを選択する。これでプリンターと既定値の NULLドライバーが割り当てられているキューのためのドライバー プロパティが見えるようになる。そして、 デバイス設定が表示できません。指定されたプリンターのドライバーがインストールされて いません。スプーラのプロパティのみ表示されます。ドライバーを今インストールしますか? というエラーメッセージが表示される。

ここで、Yesをクリックしてはいけない! その代わり、エラーダイアログでNoをクリックする。これで、 プリンタープロパティウインドウが表示される。ここから、プリンターへのドライバーの割り当ての 手順は公開されている。以下を選べる:

  • インストール済みのポップアップリストからドライバーを選択。通常は最初リストは空である。

  • 新しいプリンタードライバーをインストールするために新しいドライバー をクリック(これはAPWを起動する)。

一度APWが起動すると、Windows中でなじみがある、ものと手続きは正確に同じである(Windows NT 上のプリンタードライバーインストール手続きに慣れていることを仮定している)。接続を確認し、 printer admin権限を持つユーザーとしてセットアップ(ユーザーが 権限を持つか分からない場合はsmbstatusでチェックしてみる)。 クライアントOSに対してWindows NT x86の代わりのプリンター ドライバーをインストールしたい場合、プリンタープロパティダイアログの共有 タブを使う必要がある。

管理者(root)アカウント(printer adminパラメーターで指定されたもの) で接続していると仮定すると、さらに、このダイアログを使ってACLと既定値のデバイスの設定 のようなプリンターのプロパティをも修正できる。既定値のデバイス設定のためには、 rpcclientを使った印刷ドライバーのインストール に助言が書いてあることを考慮してほしい。

rpcclientを使った印刷ドライバーのインストール

[print$]にプリンタードライバーをインストールし、有効な方法で それを設定するための2番目の方法は、UNIXコマンドラインから行う方法である。これは、 4つの異なったステップを必要とする。

  1. 要求されたドライバーファイルについての情報を集め、ファイルを収集する。

  2. [print$]共有の正しいサブディレクトリ中にドライバー ファイルを置く(おそらくsmbclientを使うだろう)。

  3. rpcclientコマンドラインユーティリティを起動し、その adddriverサブコマンドを使う。

  4. rpcclientをもう一度起動し、setdriver サブコマンドを使う。

以下の節で、これらのステップのおのおのについて詳細な説明を行う。

ドライバーファイルの識別

ドライバーファイルを見つけるためには2つのオプションがある。プリンターに付属のドライバー CD-ROMの内容を検査することが出来る。CD-ROM上にある*.infファイルの 位置を覚えておく。これは*.infファイルが無いかもしれないので、 出来ない場合もある。残念なことに、最近ではベンダ固有のインストールプログラムを使う 傾向がある。これらのインストールパッケージはしばしば何らかのWindows上での書庫形式 を使っている。更に追加で、インストール処理中にファイル名が改名されるかもしれない。 これは、必要とされるドライバーファイルの識別がとても難しくなることを意味する。

次に、2番目のオプションがある。ドライバーをWindowsクライアント上にローカルに インストールし、インストール後にそれが使うファイル名とパスを調査する (サポートしたい各クライアントプラットフォーム毎にこの手続きを繰り返さなければ ならない。ここでは、すべてのWindows NT/200x/XPクライアントのためにMicrosoftによって 使われる名前である、W32X86プラットフォームのみを 表示する)。

ドライバーファイルを認識する良い方法は、ドライバーのプロパティ ダイアログでテストページを印刷してみることである(全般タブ)。 次に、印刷されたドライバーファイルのリストを見てみる。Windows(とSamba)が ドライバーファイルデータファイル設定ファイルと(オプションの) 依存するドライバーファイル(これはWindows NTでは若干変わる)の 何を呼び出しているかを認識する必要がある。次のステップのためにすべてのファイル名を 記録する必要がある。

ドライバーファイル名と関連するパスを迅速にテストする別の方法は、rpcclient ユーティリティによって提供される。enumdriversgetdriverサブコマンドを指定し、infoレベルを3に してこれを動かす。以下の例では、TURBO_XPがWindows PCの名前である (この場合、これはWindows XP Professionalラップトップ)。KDE-BITSHOP という名前のSambaサーバーからTURBO_XPにローカルにドライバーをインストールしたとする。 次に対話的なrpcclientを動かす。そうすると、 rpcclient />が表示され、このプロンプトの状態でサブコマンドが入力 出来るようになる。これは練習として残しておこう。次に、1つのサブコマンド行を実行し、 すぐに終了するような-cオプションをつけてrpcclient を起動する。これは大量のプリンターとドライバーのために自動作業を行うスクリプトを作成する 時に使う手法である。異なる引用符を使い分けて単語間の異なった空白を解決するように注意:

root# rpcclient -U'Danka%xxxx' -c \
	'getdriver "Heidelberg Digimaster 9110 (PS)" 3' TURBO_XP
cmd = getdriver "Heidelberg Digimaster 9110 (PS)" 3

[Windows NT x86]
Printer Driver Info 3:
  Version: [2]
  Driver Name: [Heidelberg Digimaster 9110 (PS)]
  Architecture: [Windows NT x86]
  Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01_de.DLL]
  Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.ppd]
  Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01U_de.DLL]
  Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01U_de.HLP]
  
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.DLL]
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.INI]
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.dat]
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.cat]
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.def]
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hre]
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.vnd]
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hlp]
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01Aux.dll]
  Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01_de.NTF]
  
  Monitorname: []
  Defaultdatatype: []

このドライバーは大量の依存ファイル(しかしながらこれは 悪い場合である)を持つことに気がついても良いだろう。また、不思議なことに、 ドライバーファイルはここでドライバーファイル にタグ付けされている。インストールされた、いわゆるWIN40 アーキテクチャに対してまだサポートをしていない。この名前は、Microsoftによって Windows 9x/Meプラットフォームに使われる。もしもこれらをサポートしたいならば、 W32X86(すなわち、Windows NT/2000クライアント) Windows PC上に、それらのために追加でWindows 9x/Meドライバーをインストールしなければ ならない。このPCは、Windows NT,2000あるいはXPで動いたとしても、Windows 9x/Me への機能提供も出来る。

[print$]共有が通常 ネットワークコンピュータ経由でアクセス出来るので、そこにアクセス するためにWindowsエクスプローラーからUNC記述を使う事が出来る。Windows 9x/Meドライバー ファイルはWIN40ディレクトリの0という サブディレクトリで終わる。これらに対するフルパスアクセスは \\WINDOWSHOST\print$\WIN40\0\である。

Note

Windows 2000とWindowsXP上のより最新のドライバーは、2の代わりに 3というサブディレクトリ中にインストールされる。Windows NT中で使われる バージョン2のドライバーはカーネルモードで動作する。Windows2000ではこれを変更した。 それは引き続きカーネルモードのドライバーを使えるが(もしAdminによって有効にされれば)、 そのネイティブモードのプリンタードライバーはユーザーモードで動作する。これは、この目的の ために設計されたドライバーを要求する。これらのタイプのドライバーは3 サブディレクトリにインストールされる。

Windowsクライアントの[print$]共有からのドライバーファイルの取得

ここで、以前のステップで認識したすべてのドライバーファイルを収集する必要がある。さて、 どこからそれを得ればよいだろうか?最後のファイルを識別する手段中で調査した、同じ [print$]共有とそのPCからそれを検索しないのだろうか?これを 行うのにsmbclientが使える。getdriverによって 分かったパスと名前を使える。下記のコマンドライン業は、可読性向上のために、継続行文字を 入れて編集できる:

root# smbclient //TURBO_XP/print\$ -U'Danka%xxxx' \ 
   -c 'cd W32X86/2;mget HD*_de.* hd*ppd Hd*_de.* Hddm*dll HDN*Aux.DLL'

added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Got a positive name query response from 10.160.50.8 ( 10.160.50.8 )
Domain=[DEVELOPMENT] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Get file Hddm91c1_de.ABD? n
Get file Hddm91c1_de.def? y
getting file \W32X86\2\Hddm91c1_de.def of size 428 as Hddm91c1_de.def
Get file Hddm91c1_de.DLL? y
getting file \W32X86\2\Hddm91c1_de.DLL of size 876544 as Hddm91c1_de.DLL
[...]

このコマンドが完了すると、カレントローカルディレクトリにファイルが置かれる。この時点で、 セミコロンで分離した、-cパラメーターのためにいくつかのコマンドが渡される ことにおそらく気がつくだろう。これは、smbclientコマンドが再度終了 する前にリモートのWindowsサーバー上で順番にすべてのコマンドを実行するようにさせる。

WIN40アーキテクチャが、Windows 9x/Me/XPクライアントをサポート しなければならないために、手続きを繰り返すことを忘れないこと。さらに、それらの アーキテクチャはWIN40/0/サブディレクトリにあることを忘れないこと。 これがいったん終わると、Sambaサーバーの[print$]共有にある、 収集されたファイルを格納するためにsmbclient. ..putを動作させる ことができる。

[print$]へのドライバーファイルインストール

次は、[print$]共有にドライバーファイルを配置する作業である。この 共有へのUNIXパスはsmb.confファイル中で以前に定義した事を忘れないこと。また、サポート したい異なったWindowsクライアントタイプのためには、サブディレクトリを作成する。たとえば もしも、[print$]/etc/samba/drivers/ というUNIXパスにマップされているならば、ドライバーファイルは以下のように配置すべきである:

  • すべてのWindows NT, 2000,と XPクライアント用は /etc/samba/drivers/W32X86/ だが、2サブディレクトリ中ではない。

  • すべてのWindows 95, 98,とMeクライアント用は /etc/samba/drivers/WIN40/ だが、0サブディレクトリ中ではない。

再度、ネットワーク経由で、ドライバーファイルを転送するためにsmbclientを使う。オリジナルの Windowsインストールに対してgetdriverを走らせた 事により情報を得た同じファイルとパスを指定する。しかし、ここでは、 Samba/UNIX印刷サーバーの[print$]共有中に ファイルを格納する。

root# smbclient //SAMBA-CUPS/print\$ -U'root%xxxx' -c \
  'cd W32X86; put HDNIS01_de.DLL; \
  put Hddm91c1_de.ppd; put HDNIS01U_de.DLL;        \
  put HDNIS01U_de.HLP; put Hddm91c1_de.DLL;        \
  put Hddm91c1_de.INI; put Hddm91c1KMMin.DLL;      \
  put Hddm91c1_de.dat; put Hddm91c1_de.dat;        \
  put Hddm91c1_de.def; put Hddm91c1_de.hre;        \
  put Hddm91c1_de.vnd; put Hddm91c1_de.hlp;        \
  put Hddm91c1_de_reg.HLP; put HDNIS01Aux.dll;     \
  put HDNIS01_de.NTF'

added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Got a positive name query response from 10.160.51.162 ( 10.160.51.162 )
Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
putting file HDNIS01_de.DLL as \W32X86\HDNIS01_de.DLL
putting file Hddm91c1_de.ppd as \W32X86\Hddm91c1_de.ppd
putting file HDNIS01U_de.DLL as \W32X86\HDNIS01U_de.DLL
putting file HDNIS01U_de.HLP as \W32X86\HDNIS01U_de.HLP
putting file Hddm91c1_de.DLL as \W32X86\Hddm91c1_de.DLL
putting file Hddm91c1_de.INI as \W32X86\Hddm91c1_de.INI
putting file Hddm91c1KMMin.DLL as \W32X86\Hddm91c1KMMin.DLL
putting file Hddm91c1_de.dat as \W32X86\Hddm91c1_de.dat
putting file Hddm91c1_de.dat as \W32X86\Hddm91c1_de.dat
putting file Hddm91c1_de.def as \W32X86\Hddm91c1_de.def
putting file Hddm91c1_de.hre as \W32X86\Hddm91c1_de.hre
putting file Hddm91c1_de.vnd as \W32X86\Hddm91c1_de.vnd
putting file Hddm91c1_de.hlp as \W32X86\Hddm91c1_de.hlp
putting file Hddm91c1_de_reg.HLP as \W32X86\Hddm91c1_de_reg.HLP
putting file HDNIS01Aux.dll as \W32X86\HDNIS01Aux.dll
putting file HDNIS01_de.NTF as \W32X86\HDNIS01_de.NTF

ヒュー;これはとても大量なタイプ量である!ほとんどのドライバーはより小さい。多くはたった 3つの汎用Postscriptドライバーファイルと1つのPPDのみを持つ。Windowsマシンからの W32X862サブディレクトリからファイルを検索した 時、Sambaサーバーの同じサブディレクトリ中に(今は)それらを置かない。この再配置は、 間もなく動く(そして、それらを必要とすべき場合、WIN40/サブ ディレクトリ中に、Windows 9x/Meアーキテクチャのためのファイルを置くことを忘れない)、 adddriverによって自動的に行われる。

smbclientによるドライバーインストールの確認

次は、所定の場所にファイルがあるかどうかを確認する。これは、smbclient で行える(が、もちろん、SSH経由でログインし、標準のUNIXシェルアクセスを通して行える)。

root# smbclient //SAMBA-CUPS/print\$ -U 'root%xxxx' \
	-c 'cd W32X86; pwd; dir; cd 2; pwd; dir'
 added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Got a positive name query response from 10.160.51.162 ( 10.160.51.162 )
Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.8a]

Current directory is \\SAMBA-CUPS\print$\W32X86\
.                                  D        0  Sun May  4 03:56:35 2003
..                                 D        0  Thu Apr 10 23:47:40 2003
2                                   D        0  Sun May  4 03:56:18 2003
HDNIS01Aux.dll                      A    15356  Sun May  4 03:58:59 2003
Hddm91c1KMMin.DLL                   A    46966  Sun May  4 03:58:59 2003
HDNIS01_de.DLL                      A   434400  Sun May  4 03:58:59 2003
HDNIS01_de.NTF                      A   790404  Sun May  4 03:56:35 2003
Hddm91c1_de.DLL                     A   876544  Sun May  4 03:58:59 2003
Hddm91c1_de.INI                     A      101  Sun May  4 03:58:59 2003
Hddm91c1_de.dat                     A     5044  Sun May  4 03:58:59 2003
Hddm91c1_de.def                     A      428  Sun May  4 03:58:59 2003
Hddm91c1_de.hlp                     A    37699  Sun May  4 03:58:59 2003
Hddm91c1_de.hre                     A   323584  Sun May  4 03:58:59 2003
Hddm91c1_de.ppd                     A    26373  Sun May  4 03:58:59 2003
Hddm91c1_de.vnd                     A    45056  Sun May  4 03:58:59 2003
HDNIS01U_de.DLL                     A   165888  Sun May  4 03:58:59 2003
HDNIS01U_de.HLP                     A    19770  Sun May  4 03:58:59 2003
Hddm91c1_de_reg.HLP                 A   228417  Sun May  4 03:58:59 2003
              40976 blocks of size 262144. 709 blocks available

Current directory is \\SAMBA-CUPS\print$\W32X86\2\
.                                  D        0  Sun May  4 03:56:18 2003
..                                 D        0  Sun May  4 03:56:35 2003
ADOBEPS5.DLL                        A   434400  Sat May  3 23:18:45 2003
laserjet4.ppd                       A     9639  Thu Apr 24 01:05:32 2003
ADOBEPSU.DLL                        A   109568  Sat May  3 23:18:45 2003
ADOBEPSU.HLP                        A    18082  Sat May  3 23:18:45 2003
PDFcreator2.PPD                     A    15746  Sun Apr 20 22:24:07 2003
              40976 blocks of size 262144. 709 blocks available

2サブディレクトリ(おそらく以前のインストールで)中に、すでに ドライバーファイルが存在することに注意。いったん新しいドライバーのためのファイルがそこに あると、クライアント上からそれらを使うことが出来るようにするためからは違ういくつかの ステップを処理することになる。この時点で行うべき唯一のことは、Windowsエクスプローラーから print$共有を開いて、ファイル共有から普通のファイルを検索するのと同じように、クライアント から、それらを検索することである。しかし、それはポイントアンドプリント単位でそれらを インストールしない。その理由は、Sambaはまだそれらのファイルが特別か、すなわち、 プリンタードライバーファイルかどうかを知らないのと、それらのドライバー ファイルが属する印刷キューがどれかを知らないということによる。

adddriverを付けたprinter driver filesの実行

次に、[print$]共有中に今アップロードしたファイルの特別な カテゴリについてSambaに通知する必要がある。これは、adddriverで 行える。これは、Samba内部のTDBデータベースファイルにドライバーを登録するように表示 してくる。以下のコマンドと出力は、可読性向上のために編集してある:

root# rpcclient -Uroot%xxxx -c 'adddriver "Windows NT x86" \
  "dm9110:HDNIS01_de.DLL: \
  Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP:   \
  NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI,          \
  Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre,   \
  Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
  HDNIS01Aux.dll,HDNIS01_de.NTF,                     \
  Hddm91c1_de_reg.HLP' SAMBA-CUPS

cmd = adddriver "Windows NT x86" \
  "dm9110:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL:   \
  HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \
  Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre,          \
  Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL,        \
  HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP"

Printer Driver dm9110 successfully installed.

このステップの後、ドライバーはプリントサーバー上のSambaによって認識される。このコマンドを 入力するときには特別に注意を払う必要がある。フィールドの順番を交換しないこと。それは 明白である。他の変更は、ドライバーファイルのインストールが成功するかもしれないが、 ドライバーの実行が不可能になる。そのため、注意を払うこと!adddriverコマンドの文法に関する ヒントはマニュアルページにあり、必要ならばより詳細な記述を見ておくこと。

adddriver処理完了の確認

ファイルをドライバーファイルとしてSambaが認識したことを示す表示の1つは、 successfully installedというメッセージである。 他のものは、adddriverコマンドによってファイルが 2サブディレクトリ中に動かされた、という事実である。これは再度 smbclientコマンドで確認できる:

root# smbclient //SAMBA-CUPS/print\$ -Uroot%xx \
	-c 'cd W32X86;dir;pwd;cd 2;dir;pwd'
 added interface ip=10.160.51.162 bcast=10.160.51.255 nmask=255.255.252.0
 Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]

  Current directory is \\SAMBA-CUPS\print$\W32X86\
  .                                  D        0  Sun May  4 04:32:48 2003
  ..                                 D        0  Thu Apr 10 23:47:40 2003
  2                                   D        0  Sun May  4 04:32:48 2003
                40976 blocks of size 262144. 731 blocks available 

  Current directory is \\SAMBA-CUPS\print$\W32X86\2\
  .                                  D        0  Sun May  4 04:32:48 2003
  ..                                 D        0  Sun May  4 04:32:48 2003
  DigiMaster.PPD                      A   148336  Thu Apr 24 01:07:00 2003
  ADOBEPS5.DLL                        A   434400  Sat May  3 23:18:45 2003
  laserjet4.ppd                       A     9639  Thu Apr 24 01:05:32 2003
  ADOBEPSU.DLL                        A   109568  Sat May  3 23:18:45 2003
  ADOBEPSU.HLP                        A    18082  Sat May  3 23:18:45 2003
  PDFcreator2.PPD                     A    15746  Sun Apr 20 22:24:07 2003
  HDNIS01Aux.dll                      A    15356  Sun May  4 04:32:18 2003
  Hddm91c1KMMin.DLL                   A    46966  Sun May  4 04:32:18 2003
  HDNIS01_de.DLL                      A   434400  Sun May  4 04:32:18 2003
  HDNIS01_de.NTF                      A   790404  Sun May  4 04:32:18 2003
  Hddm91c1_de.DLL                     A   876544  Sun May  4 04:32:18 2003
  Hddm91c1_de.INI                     A      101  Sun May  4 04:32:18 2003
  Hddm91c1_de.dat                     A     5044  Sun May  4 04:32:18 2003
  Hddm91c1_de.def                     A      428  Sun May  4 04:32:18 2003
  Hddm91c1_de.hlp                     A    37699  Sun May  4 04:32:18 2003
  Hddm91c1_de.hre                     A   323584  Sun May  4 04:32:18 2003
  Hddm91c1_de.ppd                     A    26373  Sun May  4 04:32:18 2003
  Hddm91c1_de.vnd                     A    45056  Sun May  4 04:32:18 2003
  HDNIS01U_de.DLL                     A   165888  Sun May  4 04:32:18 2003
  HDNIS01U_de.HLP                     A    19770  Sun May  4 04:32:18 2003
  Hddm91c1_de_reg.HLP                 A   228417  Sun May  4 04:32:18 2003
                40976 blocks of size 262144. 731 blocks available

他の検査方法は、印刷関連のTDBファイルのタイムスタンプが更新されたという事 (と、もしも条件がそろえば、そのファイルサイズが増えたこと)である。

Sambaがドライバーを認識したかの確認

この時点で、ドライバーはSambaによって登録された。ほんの少しの時間でこのことを確認できる。 しかし、このドライバーはまだ特定のプリンターに対して関連づけられていない。少なくとも3つの 方法で、ドライバーファイルのステータスを確認できる:

  • 任意のWindowsクライアントの、ネットワークコンピュータによるブラウズから、Samba ホストを検索し、SambaのプリンターとFAXフォルダーを開く。任意の プリンターアイコンを選択し、右クリックしてプリンターの プロパティを選択する。詳細タブを クリックする。そのプリンターに対するドライバーを示すフィールドがここにある。ドロップ ダウンメニューでそのドライバーを変更できる(知らずにこれをしないように気をつける こと)。Sambaが理解しているすべてのドライバーの一覧を、これを使うことで見ることが できる。新しいものがその中にあるべきである(クライアントの各タイプはこの固有の アーキテクチャリストの中にのみ見ることができる。もしも各プラットフォーム用に インストールされた各ドライバーが無いならば、Windows95/98/MEかWindows NT/2000/XP を見たときとは、このリストは違っている)。

  • Windows 200x/XPクライアント(Windows NTではなく)の ネットワークコンピュータによるブラウズから、Sambaサーバーを 探し、サーバーのプリンターフォルダーを開き、空白の部分(プリンターが ハイライトされていないようにして)を右クリックする。 サーバーのプロパティを選択する。 ドライバータブ上で、新しいドライバーが一覧表示されていることが 確認できる。この表示は、そのドライバーに属するファイルの一覧を調べるのにも使える (これはWindows NTでは動作せず、Windows 2000とWindows XPでのみ動作する。 Windows NTはドライバータブを提供しない)。この ダイアログをより簡単に起動するための代替の方法は、DOSプロンプトで入力する方法 である(もちろん、SAMBA-CUPSの代わりに使用している Sambaサーバーの名前を使わなければならない)。

    	rundll32 printui.dll,PrintUIEntry /s /t2 /n\\SAMBA-CUPS
    	

  • UNIXプロンプトから、SAMBA-CUPSになっている場所を 使用しているSambaホストの名前にして、xxxxは、rootに割り当てられている実際の Sambaのパスワードにして以下のコマンド(かあるいはその変形)を動かす:

    	rpcclient -U'root%xxxx' -c 'enumdrivers' SAMBA-CUPS
    	

    これで、Sambaが知っているすべてのドライバーが表示される。新しいものはこの中に あるべきである。しかし、[Windows NT x86]ヘッデイング 配下のもののみが一覧表示され、その部分をインストールしていないため、 [Windows 4.0]配下はない。3番目のカラムは、他に インストールされたドライバーを、各サポートしたアーキテクチャ用に、一度に 2度表示する。新しいドライバーはWindows NT 4.0 or 2000 のみに表示される。Windows 95, 98, と Meに存在 しているようにするためには、WIN40アーキテクチャとサブディレクトリに対する 完全な手続きを繰り返さなければならない。

指定したドライバー名の自由度

ドライバーに好みの名前を付けることが出来る。前と同じファイルではあるが、異なったドライバー 名を付けてadddriverステップを繰り返したいのならば、以下のように 行う:

root# rpcclient -Uroot%xxxx         \
  -c 'adddriver "Windows NT x86"                     \
  "mydrivername:HDNIS01_de.DLL:              \
  Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP:   \
  NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI,          \
  Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre,   \
  Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
  HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP' SAMBA-CUPS
  

cmd = adddriver "Windows NT x86" \
 "mydrivername:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL:\
  HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI,           \
  Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre,                    \
  Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL,                  \
  HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP"

Printer Driver mydrivername successfully installed.

任意のプリントキューにそのドライバーをバインドすることが出来る(しかし、ターゲットの プリンターに関して意味をなすキューへのドライバーを連携させる事については、責任を 追わねばならない)。繰り返しrpcclient adddriver コマンドを実行することは出来ない。おのおのの実行は、それぞれのサブディレクトリ中に それらを移動することで、[print$]共有中にファイルを配置して しまったので、各rpcclient ... adddriverコマンドの前に smbclient ... putを1回実行させなければならない。

setdriverを付けたrpcclientの実行

Sambaはどのプリンターがどのドライバーに対応しているかを知る必要がある。ドライバーからプリンター へのマッピングを作成し、この情報をSambaのTDBファイルに格納する。 rpcclient setdriverはこれを正しく処理する:

root# rpcclient -U'root%xxxx' -c 'setdriver dm9110 mydrivername' SAMBA-CUPS
 cmd = setdriver dm9110 mydrivername

Successfully set dm9110 to driver mydrivername.

これはまずい、こういう事は期待していない。この時点では、指定する名前を繰り返す:

root# rpcclient -U'root%xxxx' -c 'setdriver dm9110 dm9110' SAMBA-CUPS
 cmd = setdriver dm9110 dm9110
Successfully set dm9110 to driver dm9110.

コマンドの文法は下記の通り:

rpcclient -U'root%sambapassword' -c 'setdriver printername \
 drivername' SAMBA-Hostname. 

これで、ほとんどの仕事が完了したが、まだ全部ではない。

Note

setdriverコマンドは、Sambaがそのプリンターをすでに知っているときにのみ 成功する。2.2.x中にあるバグは、新しくインストールされたプリンターの認識を妨害する。Samba を再起動するか、少なくともこれに対応するために、動作中のすべてのsmbdに対してHUPシグナルを kill -HUP `pidof smbd`のように送信する必要がある。

クライアントドライバーのインストール方法

Don Quixote曰く、論より証拠。印刷することでセットアップした内容の証明が できる。そのため、クライアントPC上にプリンタードライバーをインストールしてみよう。が、 これは思ったよりも簡単ではない。以下で説明する。

最初のクライアントドライバーインストール

特に重要なことは、最初のクライアントPCへのインストール(各アーキテクチャプラットフォーム ごとに)である。一度これが正常に終わると、その後他のクライアントへは、簡単にセットアップ でき、さらなる注意事項は必要ない。以下でフォローすることは、推奨する最初の手順の説明で ある。ここから先はクライアントワークステーションで作業する。そのクライアントからの接続が 書き込みできないbad user nobodyにマップされていないことを確認する。 DOSプロンプトで以下を入力する:

net use \\SAMBA-SERVER\print$ /user:root

必要であれば、printer adminで定義している他の有効なユーザーに rootを置き換える。異なったユーザーですでに接続しているならば、エラーメッセージが表示 される。Windowsは共有の接続からログオフする概念が内容に見えるので、その接続のridを 取得するのに簡単な方法はない(ローカルワークステーションからのログオフと混同しない ように。それは別の事柄である)。Windows NT/200x上では、workstation サービスを再起動することで、すべての smb/cifs接続から強制的にログオフすることが できる。Windows ファイルエクスプローラーとWindows用のMSIEのすべてを閉じることを試みる ことができる。苦肉の策として、再起動しても良い。自動的な再接続の設定が無いことを 理解すること。別のワークステーションに行ってそこからつなぐ方が簡単かもしれない。 printer adminユーザーとして接続出来た後(Samba上のsmbstatusコマンドで これを確認できる)、Windowsワークステーションから以下を実行する:

  1. ネットワークコンピュータを開く。

  2. Sambaサーバーをブラウズする。

  3. そのプリンターとFAXフォルダーを開く。

  4. プリンターを選択して右クリックする。

  5. 接続を選択(Windows NT4/200xでは おそらくそれはインストールであろう)。

新しいプリンター(Sambaサーバー上でprinternameという名前の)が ローカルのプリンターフォルダー中に現れるはずである (スタート -> 設定 -> コントロールパネル -> プリンターとFAX で確認)。

おそらくは、印刷テストページを出力しようとしているだろう。全部終わった後、プリンターの プロパティを開き、全般タブ上に、これを行うためのボタンがある。 しかし、やってみると"印刷テストページを印刷できませんでした"という エラーメッセージが表示される。これは、そのドライバーに対して有効なデバイスモードセット がないか、プリンタードライバーデータセットが引き続き不完全状態という理由 による。

有効なデバイスモードを、ドライバーのために設定する必要がある。 それがどういう意味かはこれから説明する。

新しいプリンターに対するデバイスモードの設定

Windows NT/200x/XPクライアントからプリンターが完璧に使えるようにするには、以下の作業が 必要である:

  • 有効なデバイスモードは、プリンター用のドライバーによって生成 される(紙のサイズ、方向と両面印刷の設定などを定義)。

  • ドライバーによって生成されるプリンタードライバーデータの完全なセット。

これらのどれかが不完全だと、クライアントはせいぜい最適な出力以下しか作成できない。最悪の 場合、プリンターから読めないゴミが出力されたり、何も出なかったりするか、印刷時にエラー メッセージが出る。Sambaは名前つきの値と、すべての印刷に関連する情報をその内部TDB データベースファイル(ntprinters.tdb, ntdrivers.tdb, printing.tdb,と ntforms.tdb)に格納する。

デバイスモードとプリンタードライバーデータのセットはすべてのプリントキュープロパティの ための基本的な設定の集合体であり、賢明な方法で初期化される。デバイスモードとプリンター ドライバーデータは、印刷サーバー(Sambaホスト)上で健全な値に初期化されるべきであり、 そして、クライアントは直接それらを使い始めることが出来る。どのように初期の健全な 値を設定したらよいだろうか?これは、以下の節で説明されるように、あるNT (か200x/XPクライアント)からドライバーをリモートでアクセスすることで行える。

有効なデバイスモードはprinter adminかrootによってのみ初期化できる (理由は明白であろう)ことに気がつくこと。デバイスモードはプリンタードライバープログラムそれ 自身を実行することのみで正しく設定できる。SambaはこのWin32プラットフォームドライバー プログラムを実行できないので、この設定は初期状態ではNULLになる(クライアントが使うためには 有効な設定ではない)。幸いなことに、ほとんどのドライバーは、APWの助けかrpcclientで [print$]にアップロードされた時、必要であれば、自動的にプリンター ドライバーデータを生成する。

最初の有効なデバイスモードの生成と設定は、しかし、Sambaサーバー上にそれをクライアントから 設定するには若干のトリックを必要とする。最も簡単な方法は、サーバーのプリンター上のページの 方向を単純に変更することである。これは求められる効果を起こすために、クライアント上で プリンタードライバープログラムを実行することで十分であり、Sambaサーバーに新しいデバイスモードを 戻す。これを行うためには、Windowsクライアントから、ネイティブなWindows NT/200x/XPプリンター プロパティを、下記のようにして使うことが出来る:

Procedure 21.1. プリンタードライバー設定の初期化手続き

  1. ネットワークコンピュータをブラウズする。

  2. Sambaサーバーを見つける。

  3. SambaサーバーのプリンターとFAXフォルダーを開く。

  4. 問い合わせ中の共有プリンターを選択する。

  5. プリンター上で右クリックする(最後の節の説明に従っているならすでにここにいるはずである)。

  6. コンテキストメニューの下部にあるプロパティを選択する(もっと上に 引き続き接続エントリを表示しているなら、直近の節で説明 したように、ドライバーのインストールを完了するためにそれをクリックする必要がある)。

  7. 詳細タブに移動し、印刷の定義をクリックする。

  8. ページの設定をからに変更する(そして戻す)。

  9. 変更が実際に効果を引き起こすように、ページ方向の変更の確定を確実に行う。

  10. そこに居る間、他のクライアントにおけるドライバーインストール時に適用される、 印刷の既定値を設定してもよい。

この手続きは、クライアントプラットフォーム上でプリンタードライバープログラムを動かし、 正しいデバイスモードをSambaにフィードバックし、そして、それをTDBファイルに格納する。 一度ドライバーがクライアント上にインストールされると、もしもSambaのprinter admin ユーザーであれば、localプリンターフォルダーに アクセスすることによって、類似したステップを行うことも出来る。ここから、印刷作業は 期待した通りに動作する。

Sambaには、プリンターのための既定値のデバイスモードを生成するための、サービスレベルの default devmodeという名前のパラメーターがある。ある種のドライバー 機能は既定値のプロパティの値でうまく機能する。その他はクライアントのスプーラサービス をクラッシュするかもしれない。そのたえm、このパラメーターの使用には注意が必要である。 プリンターに対する有効なデバイスモードをクライアントに作成させることと、使用している サーバーにそれを格納することは、常時よりよい方法である。

追加のクライアントドライバーインストール

各追加ドライバーは、今説明してきたことと同じ方法でインストールできる。 ネットワークコンピュータをブラウズし、Sambaサーバー上の プリンターアイコンを開き、プリンターを右クリックし、 接続を選択する。一度これが完了すると(数秒以上はかからない が、ネットワークに依存するので、分単位でかかるときもある)、クライアント ワークステーションの、ローカルのプリンターとFAXフォルダー 中に新しいプリンターが現れる。

Windows 200x/XP Professionalワークステーション上で以下のコマンドを使うことによって、 ローカルのプリンターとFAXフォルダーを開くことが出来る。

rundll32 shell32.dll,SHHelpShortcuts_RunDLL PrintersFolder

一方Windows NT 4.0ワークステーションでは以下のように行う:

rundll32 shell32.dll,Control_RunDLL MAIN.CPL @2

DOS プロンプトウィンドウ内か、スタートメニュー 中のコマンドを指定して実行のどちらかで入力できる。

常時最初のクライアントからの接続はrootかprinter adminで行う

Sambaサーバー上にドライバーをインストール後(その[print$]共有中に)、 常時最初のクライアントインストールを正しく完了させねばならない。クライアントから printer adminとして、まさしくその最初の接続を確立することを 習慣づけるようにすること。これは、以下のように行う:

  • 最初の有効なデバイスモードが実際に初期化される(詳細な説明は 新しいプリンター上のデバイスモードの設定を参照)。

  • 今後のすべてのクライアントインストールのための、使用しているプリンターの既定値の プリンター設定は期待するようになる。

上の方向を横に変更し、適用をクリックし、再度戻すことでこれを行う。 次に、他の設定を変更する(たとえば、常時 A4を使っているときに、 紙のサイズをレターに既定値を変更したくないであろう?既定値として 両面印刷にプリンターを設定したいかもしれないなど)。

Sambaプリンターにrootとして接続するためには、以下のコマンドをWindows 200x/XPのDOS プロンプトから実行する:

C:\> runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /p /t3 /n 
	\\SAMBA-SERVER\printername"

rootのSambaパスワードを入力し、しばらく待ち、 印刷の既定値をクリックし、すべてのクライアントで使われる既定値と すべきジョブオプションを設定する。代替として、printer adminの 設定中のメンバーの中の名前をrootの代わりとして使うことが出来る。

これで、他のすべてのユーザーは同じ方法でドライバーのダウンロードとインストールが (ポイントアンドプリントを使って)出来るようになり、既定値も 同じように設定される。もしも、このステップに失敗したら、ユーザーからたくさんの 問い合わせが来ることになるが、たくさんおしゃべりが出来て楽しいことになるだろう。

その他のテクニック

ドライバーはインストールされた。クライアントによるポイントアンドプリントインストールは 準備ができた。最初のクライアントマシンでダウンロードして使ってみてもよいが、ちょっと 待ってほしい。その前に、有用だと思われる、ちょっとした助言とこつをここで伝授する。 たとえば、前の節で助言したような、プリンターに既定値を設定しなかったとする。利用者は 多くの問題に不満を言うだろう(たとえば、各ジョブにレターからA4への紙のサイズの 変更を必要とし、それが格納できないなど)。

クライアントドライバーのための既定値の印刷操作の設定

最後の文は、若干のユーザーと管理者には複雑な気持ちになるかもしれない。何時間もかけて 苦労したのに、設定をセーブできると思ったらそれが出来なかった。それはやった人の 問題ではない。混乱する点は、プリンター名上で右クリックをした時にポップアップされる複数の タブを持つダイアログ中でプロパティを選択したとき、同一である ように見える2つのダイアログが現れ、それぞれは3つの異なった方法でプリンターのオプション 設定を手助けすると言ってくるということである。これの完璧な答えは、Sambaの既定値の ドライバー設定FAQにある:

Windows 200x/XP上ですべてのユーザーで既定値のプリンターオプションを 設定しセーブできない。なぜ? どのようにそれを行っている?操作を間違っているのではないか(確かにそれを見つけるのは簡単 ではないが)。すべてを設定するダイアログを起動するのに3つのやり方がある。すべての3つの ダイアログは同じように見えるが、そのうちの1つが意図したものである。すべてのユーザーのために AdministratorかPrint Administratorでこれを行う必要がある。XP Professionalでどのように これを再現したかは以下の通り:

  1. 最初の間違った方法:

    1. Open the Printers folder.

    2. プリンター(cupshost上のリモートプリンター)を右クリックし、 コンテキストメニューの印刷のプリファレンス...を選択する。

    3. しっかりとこのダイアログを見て、どのように見えるかを覚えておくこと。

  2. 2番目の間違った方法:

    1. プリンターフォルダーを開く。

    2. プリンター(cupshost上のリモートプリンター) を右クリックし、コンテキストメニューの プロパティ

      を選択する。
    3. 全般タブをクリックする。

    4. 印刷のプリファレンス... ボタンをクリックする。

    5. 新しいダイアログが開く。このダイアログを開いたままにして 親のダイアログに戻る。

  3. 3番目の正しい方法(これを最初に行うべきであり、そのあと上記で説明した2番目の方法の ステップ1と2を行う):

    1. 詳細タブをクリックする (もしもすべてが灰色で選択できないならば、十分な 権限を持つユーザーでログインしていない)。

    2. 印刷の既定値ボタンを クリックする。

    3. 2つの新しいタブ上のどれかで、 詳細ボタンをクリックする。

    4. 新しいダイアログが開く。これを他と比較する。これらは B.5からのものとA.3からのものと比較したときに同じか?

2つの設定ダイアログで何らかの違いがあっただろうか?そうではないはずであろう。しかし、 最後のもののみ、ステップC.1からC.6までの処理は、新しいユーザーのために既定値となる、 任意の設定を恒常的に保存する。もしも全クライアントに同じ既定値を設定したいならば、 クライアントがドライバーをダウンロードする前に(上記のAまたはBの手順に従うことで、 クライアントはユーザー毎の既定値を後で設定出来る)、管理者 (printer admin)としてそれらのステップを行う必要がある。 Windows 200x/XPはユーザー毎の既定値設定が出来、その管理者はそれら固有の設定を行う前に それを提供する。同一に見えるダイアログの親は、そのウィンドウ名が微妙に違っている。 1つはサーバーBar上のプリンターFoo用の既定値の印刷値 (これが必要なもの)と呼ばれ、もう1つは、 サーバーBar上のプリンターFooの用の印刷設定 と呼ばれる。最後のものは、プリンターを右クリックし、印刷設定... を選択した時に現れるものである。これは、Windows NTの時代に使うことを教わったものであり、 Windows 200x/XPはで同じように試すのはとても自然である。同じように見えるものに到達する 異なったパスがあるとは夢にも思わないだろうが、機能は異なり、すべてのユーザーに既定値を 設定するダイアログである。

Tip

(Windows 200x/XP上で)このコマンドを動かしてみる(正しい権限を持つユーザーで):

rundll32 printui.dll,PrintUIEntry /p /t3 /n\\SAMBA-SERVER\printersharename

印刷の既定値ボタン(必要としているもの)があるタブを見るには以下のコマンドを実行する:

rundll32 printui.dll,PrintUIEntry /p /t0 /n\\SAMBA-SERVER\printersharename

印刷のプリファレンスボタンを持つタブを見るには (システム全体の既定値を設定しない)、DOSプロンプト内でコマンドを実行するか、 スタート -> 実行を選択する。

大量のプリンターのサポート

昨今のSamba 開発フェーズにおいて浮かび上がった問題は、さまざまな種類のプリンターに関して ドライバーのダウンロードサポートが必要なことである。Windows NT の APW(Add Printer Wizard) を使うやり方は(控えめに言っても)筋が良いとはいえない。一人でクリック祭りをやりながら プリンターのインストールをやりつつ反復性緊張症候群(RSS)の苦痛をを味わいたくなければ、 非会話的なスクリプトについて検討する必要があるだろう。

複数のプリンターが同じドライバーを使う場合、rpcclient setdriverコマンドは インストールされたキューに結合されたドライバーを設定するために使える。もしもドライバーが [print$]で一度更新され、印刷用TDBファイルに登録されると、 複数の印刷キューによって使うことができる。この場合、すべてのキューに対して (adddriverを繰り返し実行する必要なしに) rpcclientsetprinterサブコマンドを繰り返す必要が ある。以下はどのようにこれを達成するかの例である:

root# rpcclient SAMBA-CUPS -U root%secret -c 'enumdrivers'
 cmd = enumdrivers
 
 [Windows NT x86]
 Printer Driver Info 1:
   Driver Name: [infotec  IS 2075 PCL 6]
 
 Printer Driver Info 1:
   Driver Name: [DANKA InfoStream]
 
 Printer Driver Info 1:
   Driver Name: [Heidelberg Digimaster 9110 (PS)]
 
 Printer Driver Info 1:
   Driver Name: [dm9110]

 Printer Driver Info 1:
   Driver Name: [mydrivername]

 [....]

root# rpcclient SAMBA-CUPS -U root%secret -c 'enumprinters'
 cmd = enumprinters
   flags:[0x800000]
   name:[\\SAMBA-CUPS\dm9110]
   description:[\\SAMBA-CUPS\dm9110,,110ppm HiVolume DANKA Stuttgart]
   comment:[110 ppm HiVolume DANKA Stuttgart]
 [....]

root# rpcclient SAMBA-CUPS -U root%secret -c \
  'setdriver dm9110 "Heidelberg Digimaster 9110 (PS)"'
 cmd = setdriver dm9110 Heidelberg Digimaster 9110 (PPD)
 Successfully set dm9110 to driver Heidelberg Digimaster 9110 (PS).

root# rpcclient SAMBA-CUPS -U root%secret -c 'enumprinters'
 cmd = enumprinters
   flags:[0x800000]
   name:[\\SAMBA-CUPS\dm9110]
   description:[\\SAMBA-CUPS\dm9110,Heidelberg Digimaster 9110 (PS),\
     110ppm HiVolume DANKA Stuttgart]
   comment:[110ppm HiVolume DANKA Stuttgart]
 [....]

root# rpcclient SAMBA-CUPS -U root%secret -c 'setdriver dm9110 mydrivername'
 cmd = setdriver dm9110 mydrivername
 Successfully set dm9110 to mydrivername.

root# rpcclient SAMBA-CUPS -U root%secret -c 'enumprinters'
 cmd = enumprinters
   flags:[0x800000]
   name:[\\SAMBA-CUPS\dm9110]
   description:[\\SAMBA-CUPS\dm9110,mydrivername,\
     110ppm HiVolume DANKA Stuttgart]
   comment:[110ppm HiVolume DANKA Stuttgart]
 [....]

(説明フィールドの2つのカンマの間に)ドライバーが一覧表示される、空の文字列がある dm9110プリンターが表示される最初のenumprinters 呼び出しを認識するのは簡単ではないかもしれない。setdriver コマンドの成功後、すべてはうまくいく。

Windows NT APWによる新しいプリンターの追加

既定値では、Sambaはsmb.conf中で定義されているすべてのプリンター共有を、 プリンターフォルダーに表示する。また、このフォルダー中にWindows NTの プリンター追加ウィザードアイコンも配置される。APWは下記の条件の時にのみ表示される:

  • 接続したユーザーは管理者権限つきでOpenPrinterEx(\\server)を 正常に実行できる(すなわち、root又はprinter admin)。

    Tip

    Windows 200x/XP DOSプロント内で下記を試してみる:

    runas /netonly /user:root rundll32 printui.dll,PrintUIEntry /p /t0 /n \\SAMBA-SERVER\printersharename

    印刷のプリファレンスをクリックする。

  • ... は下記の設定を含む show add printer wizard = yes (既定値) default)。

APWではいろいろなことが出来る:

  • 新しいドライバーをSambaの[print$]共有にアップロードする。

  • 存在している印刷キューに(ただしまだドライバーがない)アップロードされたドライバーを関連づける。

  • 存在する印刷キューに対して、以前にアップロードされたものと、現在使っているドライバーを、交換する。

  • Sambaホストに、完全な形で新しいプリンターを追加する(動作する add printer commandと組み合わせる場合のみ。 プリンターフォルダーからエントリを削除するための delete printer commandも提供してもよい)。

最後のもの(プリンターの追加)はその前のものよりもより多くの努力を必要とする。Sambaサーバーに 正しくプリンターを追加するのにAPWを使うためには、add printer command に値が定義されている必要がある。プログラムホックは、正しくUNIX印刷システム(すなわち /etc/printcap/etc/cups/printers.confか 他の適切なファイル)と、必要であればsmb.confにプリンターを追加しなければならない。

クライアントからAPWを使うとき、名前が付いたプリンター共有が存在しない場合、smbdは add printer commandを実行し、新しいプリンター共有を配置する ために、再度検索する。もしも共有がやはり定義されていないのであれば、クライアントに "アクセスが拒否されました"が返る。ユーザーが接続している 状態においてのadd printer commandの実行は、rootアカウント の必要はない。map to guest = bad userは 間違った権限で書き込みが出来なくなる接続をしてしまうだろう。 smbstatusコマンドを使ってこのことを検査すべきである。

エラーメッセージ: 異なった名前で接続できない

間違った認証情報で接続してしまった場合、すべてのエクスプローラー画面を閉じ、リブート する以外に、この状況を解決する方法はない。

  • net use \\SAMBA-SERVER\sharename /user:rootを使うと以下の エラーメッセージが表示される: サーバーか共有リソースへの、複数の接続か、同じユーザーによっていくつかの ユーザー名を使う事は許可されない。特にサーバー、共有リソースへのすべての接続を 切断し再度試してみる。

  • ネットワークドライブへの割り当て-> \\SAMBASERVER\\print$->z:へのすべての 試みは、以下のようなメッセージがしつこく表示される: このネットワークフォルダーは現在異なった認証情報(ユーザー名とパスワード)の元で 接続されている。異なったユーザー名とパスワードで再度接続するために、この ネットワーク共有への接続まず初めに切断する。

そのためすべての接続をクローズする。そして再実行する。そうすると同じメッセージが出る。 smbstatusを使ってSamba側でチェックを行う。するといくつか接続 されているのが分かる。それらをkillする。そうしてもクライアントは同じメッセージを出す。 デバッグレベルを上げて、再接続してsmbd.logをチェックする。ログ中に1行ではない、 いくつかのエラーメッセージがある事が分かる。何らかの接続があったかどうかを考えて見始める。 接続するときの状況を見るため、wiresharkかtcpdumpを走らせてみる。結果はこうなる: たくさんのデータがネットワーク上に出ている。Windowsは引き続きエラーメッセージを表示して いる。エクスプローラーのウィンドウをクローズして、再度起動する。再度接続すると今回は うまくいった!Windowsは接続情報をどこかにキャッシュしているように見え、それは最新状態に していない(不幸な場合、エラーメッセージを除去するためにリブートの必要があるかもしれない)。

クライアントからサーバーへのすべての接続を強制的に終了する最も簡単な方法は以下を実行する:

C:\>  net use * /delete

これは、マップされたドライバーすべても切断し、要求に応じて新しい接続が出来るようにする。

ドライバーファイルを集めるときに気をつけること

特定のドライバーに帰属するファイルについて注意するときにはきわめて注意深くする必要がある。 ドライバーバージョン0(Windows 9x/Me用で[print$]/WIN/0/ に入るもの)とドライバーバージョン2(Windows NTのカーネルモード ドライバーで、[print$]/W32X86/2/に入るもので、Windows 200x/XPでも 使われる)と、ドライバーバージョン3(非カーネルモードドライバーで、 [print$]/W32X86/3/に入るもので、Windows NTでは使われない)のための ファイルを混同してはならない。これら異なったドライバーのバージョンは同じ名前のファイルを 含んでいるが実際には全く異なることがとても多い。Sambaからenumdrivers コマンドで、大小文字が混じったか、小文字のみで表示されている間、もしもそれらをWindows エクスプローラー(%WINDOWS%\system32\spool\drivers\W32X86\内にある)で 見る時、大文字で名前を見ることになるので、とてもこれらを混同しやすくなる。もしも、 rpcclientとサブコマンドを使い、手動でそれらをインストールした場合、 何のエラーメッセージもなしに成功する。その後、クライアント上にインストールしようと したとき、このサーバーはプリンターに対する適切なドライバーを持っていない というエラーメッセージを受け取ることになる。

以下は例である。しっかりと数多くのファイルに対して、その名前と綴りを確認し、バージョン2と 3の構成において、その違いを見いだすことが求められる。注意:バージョン0には40の 依存するファイルがあるので、紙面節約のためにそれらは削除してある:

root# rpcclient -U 'Administrator%secret' -c 'enumdrivers 3' 10.160.50.8 

 Printer Driver Info 3:
         Version: [3]
         Driver Name: [Canon iR8500 PS3]
         Architecture: [Windows NT x86]
         Driver Path: [\\10.160.50.8\print$\W32X86\3\cns3g.dll]
         Datafile: [\\10.160.50.8\print$\W32X86\3\iR8500sg.xpd]
         Configfile: [\\10.160.50.8\print$\W32X86\3\cns3gui.dll]
         Helpfile: [\\10.160.50.8\print$\W32X86\3\cns3g.hlp]
 
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aucplmNT.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\ucs32p.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\tnl32.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aussdrv.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cnspdc.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aussapi.dat]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cns3407.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\CnS3G.cnt]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\NBAPI.DLL]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\NBIPC.DLL]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcview.exe]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcdspl.exe]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcedit.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcqm.exe]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcspl.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cfine32.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcr407.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\Cpcqm407.hlp]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcqm407.cnt]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cns3ggr.dll]
 
         Monitorname: []
         Defaultdatatype: []

 Printer Driver Info 3:
         Version: [2]
         Driver Name: [Canon iR5000-6000 PS3]
         Architecture: [Windows NT x86]
         Driver Path: [\\10.160.50.8\print$\W32X86\2\cns3g.dll]
         Datafile: [\\10.160.50.8\print$\W32X86\2\IR5000sg.xpd]
         Configfile: [\\10.160.50.8\print$\W32X86\2\cns3gui.dll]
         Helpfile: [\\10.160.50.8\print$\W32X86\2\cns3g.hlp]
 
         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\AUCPLMNT.DLL]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\aussdrv.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cnspdc.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\aussapi.dat]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cns3407.dll]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\CnS3G.cnt]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\NBAPI.DLL]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\NBIPC.DLL]
         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cns3gum.dll]
 
         Monitorname: [CPCA Language Monitor2]
         Defaultdatatype: []

もしもバージョン 2ファイルとバージョン 3ファイルを異なった テキストファイルに書き込み、その結果を比較すると以下のようになる:

root# sdiff 2-files 3-files


 cns3g.dll                     cns3g.dll
 iR8500sg.xpd                  iR8500sg.xpd
 cns3gui.dll                   cns3gui.dll
 cns3g.hlp                     cns3g.hlp
 AUCPLMNT.DLL                | aucplmNT.dll
                             > ucs32p.dll
                             > tnl32.dll
 aussdrv.dll                   aussdrv.dll
 cnspdc.dll                    cnspdc.dll
 aussapi.dat                   aussapi.dat
 cns3407.dll                   cns3407.dll
 CnS3G.cnt                     CnS3G.cnt
 NBAPI.DLL                     NBAPI.DLL
 NBIPC.DLL                     NBIPC.DLL
 cns3gum.dll                 | cpcview.exe
                             > cpcdspl.exe 
                             > cpcqm.exe
                             > cpcspl.dll
                             > cfine32.dll
                             > cpcr407.dll
                             > Cpcqm407.hlp
                             > cpcqm407.cnt
                             > cns3ggr.dll

だまされてはいけない!各バージョン用の、同一の名前のドライバーファイルは、サイズを 比較して分かるように、その内容が異なっているかもしれない:

root# for i in cns3g.hlp cns3gui.dll cns3g.dll; do                  \
           smbclient //10.160.50.8/print\$ -U 'Administrator%xxxx' \
           -c "cd W32X86/3; dir $i; cd .. ; cd 2; dir $i";      \
		   done

  CNS3G.HLP               A   122981  Thu May 30 02:31:00 2002
  CNS3G.HLP               A    99948  Thu May 30 02:31:00 2002

  CNS3GUI.DLL             A  1805824  Thu May 30 02:31:00 2002
  CNS3GUI.DLL             A  1785344  Thu May 30 02:31:00 2002

  CNS3G.DLL               A  1145088  Thu May 30 02:31:00 2002
  CNS3G.DLL               A    15872  Thu May 30 02:31:00 2002

多くの例では、上記の例よりももっと違っている。結論:各ドライバーバージョン用の正しいドライバー ファイルを注意深く選択しなければならない。名前だけに頼っても、異なったドライバー バージョンに属するファイルを交換してもいけない。

Sambaとプリンターポート

Windows NT/2000印刷サーバーは各プリンターに対してポートを結びつける。これらは通常、 LPT1:COM1:FILE: のような形式である。Sambaもプリンターに結びついたポートという概念をサポートせねば ならない。既定値では、システム上Sambaプリンターポートという名前の1つの プリンターポートのみが存在する。Sambaは印刷するために、ポートのようなものは 実際に必要はしていない。むしろ、これはWindowsクライアントの要求である。この情報を要求する 時、有効なポートについて告知されることを強く要求する。それ以外だとエラーメッセージを表示 する。そのため、SambaはWindowsクライアントに支障がないよう、ポート情報を偽装する。

Sambaは内部的に同等のプリンタープーリングという概念をサポートして いない。プリンタープーリングは論理プリンターを複数のポートに、ロードバランシングか フェイルオーバーのように割り当てるものである。

もしも何らかの理由か、他の理由で(Sambaでそういうことが出来るか、ユーザーと管理者は知る べきではないが)複数のポートを定義する要望がある場合、システム上のポートの一覧を生成する 外部プログラムを定義するために使えるenumports commandを設定する。

共通クライアントドライバーの間違った設定の防止

印刷はうまくいっているが、まだ問題がある。ほとんどのジョブの印刷はうまくいくが、 いくつかは全く印刷できない。いくつかのジョブはうまくいっていないように見えるフォントの 問題を抱えている。いくつかのジョブは速やかに印刷するが、いくつかはとても遅い。それら 全部について触れることは出来ないが、 CUPSによる印刷の章の 間違ったPostscriptドライバー設定の防止クライアント上の危険なPostscriptドライバー設定の防止 の短い節を読むことを推奨する。

Imprintsツールセット

ImprintsツールセットはWindows NT APWの同等品をUNIXで提供する。完全な情報は、Imprints のソースディストリビューションを含むドキュメントがある、 ImprintsのWebサイトを参照して ほしい。この節は、Imprintsの機能について簡単な紹介を提供するのみ行う。

不幸にも、Imprintsツールセットはもはやメンテナンスされていない。2000年12月から プロジェクトは新しいメンテナを必要としている。持つべきスキルのうち最も重要なものは PerlのコーディングとSambaで使うMS-RPCベースの印刷についての興味である。もしも ボランティアを希望するならば、Sambaテクニカルメーリングリストで希望を調整してほしい。 ツールセットはいまだに便利であるが、使うために準備されているパッケージは古いプリンター モジュールに対してのもののみである。Imprintsが持つべきであるならば、より更新された プリンタードライバーのパッケージが必要である。Imprintsにツールセットに関する情報は Imprintsホームページから 得ることが出来る。

Imprintsとは何か?

Imprintsは以下をサポートするためのツールの集合体である:

  • Windows NTと 95/98プリンタードライバーパッケージに関連する集中した情報のリポジトリを提供する。

  • Imprintsプリンタードライバーパッケージを作成するためのツールを提供する。

  • 中央のインターネット(又はイントラネット)Imprintsサーバーリポジトリからプリンタードライバーを 得、リモートのSambaとWindows NT印刷サーバー上にそれをインストールする事を提供する。

プリンタードライバーパッケージの作成

プリンタードライバーパッケージの作成手順はこのドキュメントの範囲外である(より詳細は、Sambaの ディストリビューションに含まれているImprints.txtを参照)。簡単に言うと、Imprintsドライバー パッケージは、ドライバーファイル、関連するINFファイルとクライアントがインストールするのに 必要な制御ファイルを含む、gzipされたtar形式ファイルである。

Imprintsサーバー

Imprintsサーバーは、実際には、標準HTTPメカニズム経由で問い合わせを受けることが出来る データベースサーバーである。データベース中の各プリンターエントリは、実際にダウンロード するパッケージを示すURLに関連づけられている。各パッケージは、実際にダウンロードした ものが、Imprintsデータベース中で参照されるものかどうかを検査できるよう、GnuPGを使って デジタル署名されている。このセキュリティ検査を無効にしないことを強く推奨する。

クライアントのインストール

Imprintsクライアントに関連するさらなる情報は、Imprintsソースパッケージ中にある、 Imprints-Client-HOWTO.psという文書ファイルに書いてある。 Imprintsクライアントインストールは以下の2つの形式がある:

  • コマンドラインPerlスクリプト一式。

  • コマンドラインPerlスクリプトへのGTK+ベースのグラフィカルインタフェース

(両方の形式による)クライアントのインストールは、リモートSambaとWindows NTプリントサーバー 上へのダウンロードとドライバーのインストールという意味と同じような、既存のプリンターモデル名 の一致リストのための、Imprintsデータベースサーバーに問い合わせる手段を提供する。

基本的なインストール手順は4つのステップがあり、Perlコードはsmbclientとrpcclientを包み こんでいる。

  • 与えられたドライバーがサポートする各アーキテクチャに対して:

    1. rpcclient: リモートサーバー上の適切なアップロードディレクトリを取得する。

    2. smbclient: ドライバーファイルをアップロードする。

    3. rpcclient: AddPrinterDriver() MS-RPCを発行する。

  • rpcclient: 実際にプリンターの作成を行うためにAddPrinterEx() MS-RPCを発行する。

Imprintsツールセットを実装するときに発生した問題の1つは、数多くサポートされている クライアントアーキテクチャ間での名前空間の問題であった。例えば、Windows NTには Apple LaserWriter II NTX v51.8という名前のドライバーを含んでいるが、 Windows 95はこのドライバーの対応するバージョンApple LaserWriter II NTX を呼び出す。

問題は、プリンターに対してどんなクライアントドライバーをアップロードするかということを どのようにして知るかと言うことである。抜け目がない読者は、Windows NTのプリンター プロパティのダイアログのみが、そのプリンタードライバー名に空白を含んでいることを覚えて いるだろう。下記のWindows NT 4.0システムレジストリを簡単に見てみると、

HKLM\System\CurrentControlSet\Control\Print\Environment

これは、Windows NTが常時 NTドライバー名を使うことを明白にしている。これは、Windows NTが 少なくともWindows NTバージョンのプリンタードライバーが存在することを常時要求しているので 問題はない。Sambaは内部的にはそれを要求しない。そのため、 すでにインストールされていないのに、なぜNTドライバー名を使うことが出来るのか? という疑問が生じるだろう。

この限界を回避する方法は、すべてのImprintsドライバーパッケージがIntel Windows NTと95/98 プリンタードライバーを含み、そのNTドライバーが最初にインストールされることを要求することである。

ユーザーによるインストールなしにネットワークプリンターを追加する

以下のMS Knowledgeベースの記事は、Windows 2000クライアントを扱う必要がある場合に何らかの 手助けになるかもしれない。 ユーザーによる操作なしで Windows にプリンターを追加する方法 (Microsoft KB 189105(日本語))。 これは又Windows XP Professionalクライアントにも適用できる。この節で示すアイデアの概要は、 ネットワークとローカルプリンターとそのドライバーをインストールするために適用できるコマンド ライン手法を説明するこの記事によって触発されたものである。これは、ログオンスクリプトと 統合すると最も便利である。コマンドプロンプト(DOSプロンプト)で 以下のようにタイプすることにより、どのようなオプションが有効かを見ることができる:

rundll32 printui.dll,PrintUIEntry /?

すべての有効なコマンドラインスイッチを表示するウィンドウがポップアップする。 大規模な 例題リストも提供される。これは、Windows 200x/XPのみである。Windows NT上では動作 しない。Windows NTはそれぞれねリソースキット内である種の他のツールをおそらく 持っている。各行が実際に何をするかについての簡単な説明がある、クライアントログオン スクリプトが含んでも良いかもしれないものについての助言は以下の通り(これはSamba 経由で200x/XP Windowsクライアントがプリンターにアクセスする場合に動作し、さらに、 Windowsベースのプリンターでも同様である)。

rundll32 printui.dll,PrintUIEntry /dn /n "\\cupsserver\infotec2105-IPDS" /q
rundll32 printui.dll,PrintUIEntry /in /n "\\cupsserver\infotec2105-PS"
rundll32 printui.dll,PrintUIEntry /y /n "\\cupsserver\infotec2105-PS"

コマンドラインパラメーターで使われるパラメーターの一覧である:

/dn

ネットワークプリンターを削除する。

/q

表示を抑制する。

/n

プリンターに名前を付ける。

/in

ネットワークプリンター接続を追加する。

/y

プリンターを既定値のプリンターにする。

  • 1行目ではinfotec2105-IPDSという以前に存在していた可能性の あるネットワークプリンターを削除する(CUPSに変換された、サーバーから削除されたLPRngの ネイティブなWindowsドライバーで使われていた)。終わりにある/q は、ポップアップする確認あるいはエラーダイアログボックスを抑制する。これらは ユーザーログオンについては提供されない。

  • 2行目では、新しいプリンターinfotec2105-PS(実際には同じ物理 デバイスであるが、新しいCUPS印刷システムによって動作し、CUPS/Adobe PSドライバー と関連づけられる)を追加する。プリンターとそのドライバーはユーザーのログインに先立って 追加されねばならない(すなわち、この章の前の方で説明した手順か、 cupsaddsmbを動かすことによって)。ドライバーはユーザーがログイン しようとしているときに、クライアントPCに自動的にダウンロードされる。

  • 3行目では、この新しいネットワークプリンターを既定値のプリンターに設定する(この方法を 使っていくつかのプリンターが存在するかもしれなく、また、そのうちのいくつかは同じ ようにローカルであってもよいので、既定値のプリンターを決める事が必要となる)。 既定値のプリンターの選択は、もちろん、異なったユーザーでは異なっても良い。

2番目の行は、もしもプリンターinfotec2105-PSがすでに cupsserver上のプリントキューで動作していて、もしも プリンタードライバーがSambaのドライバーリポジトリである[print$] 中に、すでにきちんとアップロード(APW, smbclient/rpcclientcupsaddsmb経由で) されている場合にのみ動作する。バージョン3.0より前のある種のSambaのバージョンでは、 プリンターインストール後とドライバーアップロード後にsmbdの再起動を要求する。そうでないと、 スクリプト(かその他のルライアンとドライバーダウンロード)は失敗する。

ログオンスクリプトからの、インストールされたネットワークプリンターの存在をテストする簡単な 方法は無いので、わざわざ調べる必要はない。ユーザーログイン時に毎回インストールの削除/ 再インストールが出来るようにしておくこと。それはとても短時間である(1から2秒くらい)。

ほかにこの件に関する有用な情報は以下の通り:

  • 全部のユーザーログイン時に自動的に、任意のプリンター既定値の設定変更を適切に設定する。

  • 異なったワークステーションからドメインにユーザーがローミングでログイン出来るようにする。

各ユーザー毎にネットワークプリンターがインストールされるので、これにより、インストールの 最新性を保持する作業をより単純化する。ログイン時に数秒余計にかけることはほとんど 目立たないだろう。プリンターは、クライアントからユーザーが介入する必要性なしにサーバー上で 集中して追加、変更と削除ができる(ログインスクリプトは最新性を保持する必要はある)。

addprinterコマンド

addprinterコマンドはSambaによって実行されるシェルスクリプトか プログラムとして設定できる。これはSambaプリントサーバーに対してクライアントからAPWを 走らせることによって起動される。APWはユーザーにいくつかのフィールドを埋めることを 要求する(それはたとえばプリンター名、使用するドライバー、コメント、ポートモニターなど)。 これらのパラメーターはAPWによってSamba上に渡される。もしも、addprinterコマンドが 新しいプリンターを作成できるように(旧式のシステム上で、適切なprintcapエントリを書くか、 より新しいシステム上でlpadminコマンドを実行することによって)と、 それに関連する共有を作成するように設計されていた場合、APWはSamba上とUNIX印刷 システム上に、結果として新しいプリンターを作る!

旧式の印刷システムの、Sambaへの移行

基本的なNT形式のプリンタードライバー管理は2.2.xリリースから3.0ではほとんど変更はなかった (小さな改善はたくさん適用されたが)。特に、設定中で廃止されるパラメーターを使うのをやめる、 前述の助言に従うならば、移行はとても簡単である。既存の2.0.x設定か、Samba 2.2で Windows 9x/Me形式の印刷形式を継続したいのであれば、それはもっと努力が必要となる。 適切なリリースノートとSamba-2.2.xのHOWTO文書を読んでほしい。以下のいくつかの方法に 沿うことが出来る。移行のための可能なシナリオは以下の通り:

  • 新しい Windows NTプリンターとドライバーサポートについて学習し、使う必要がある。以前 使っていたパラメーターprinter driver file, printer driverprinter driver location はもはやサポートされない。

  • もしもWindows NTプリンタードライバーサポートを利用したいのであれば、新しい設定の ために、Windows 9x/Meドライバーを新しいものへ移行する必要がある。

  • 存在するprinters.defファイル(削除されたパラメーター printer driver file中で指定されているもの)はもはやSamba-3 では動作しないので、smbdは[print$]中とTDBファイル中の 追加の設定だけで、プリンターのためのWindows 9x/Meドライバーファイルを捜そうとする。 もしもそれが失敗すると、(2.2.xが使うように)printers.def (とすべての関連するパラメーター)を使うようにはならない。 make_printerdefツールは削除され、これに関する下位互換性はない。

  • 使用しているSambaホスト上のプリンター用の [print$]共有中にWindows 9x/Meドライバーをインストールする 必要がある。ドライバーファイルは[print$]WIN40/0サブディレクトリ中に格納され、その他の設定と情報は印刷 関連のTDBファイル中に格納される。

  • もしも、存在するprinters.defファイルを新しい設定中に移行 したいならば、現在唯一の解は、NTドライバーと9x/Meドライバーをインストールするために、 Windows NT APWを使うことである。これはsmbclientとrpcclientを使うスクリプトで 行える。その例は、 Imprints のWebサイト上にあるImprintsクライアントインストールを参照。また、 CUPS 印刷環境中のrpcclientの使用法についての 議論も参照のこと。

Active DirectoryかLDAPへのプリンター情報の公開

この件に関しては、 リモートとローカル管理Netコマンドでも 触れられている。もしもこの機能に関しての文書の更新をボランティアとして手助けしてくれる のであれば、John H. Terpstraに連絡を してほしい。

よくあるエラー

rootパスワードを指定したが、アクセスできない

UNIXシステムで有効な(とほとんどの場合、/etc/shadowというファイルに 1方向ハッシュ形式として格納される)rootパスワードと、Samba認証時に使うパスワードと混同 しないこと。SambaはUNIXパスワードを知らない。Sambaリソースへのrootアクセスは最初に作成 されなければならないSamba用のrootアカウントを必要とする。これは以下のように、 smbpasswdを使って行える:

root#  smbpasswd -a root
New SMB password: secret
Retype new SMB password: secret

印刷ジョブはスプールディレクトリに入ったが、その後なくなった

存在するUNIX印刷システムスプールディレクトリをSambaスプールディレクトリに使っては ならない。それは、簡単で場所を節約できるように見えるが、これは問題を引き起こす。 2つは分離せねばならない。UNIX/Linuxシステムプリントスプールディレクトリ(すなわち /var/spool/cups)は通常cupslpのような非特権ユーザーによって所有される。さらに追加で、 スプールディレクトリのパーミッションは、通常所有者とグループに対して制約されて いる。別の言い方をすると、Sambaスプールディレクトリは全員に対して書き込み可能で、 一時スプールファイルの所有者のみがファイルを変更したり削除できるようにする、 't'ビットを設定すべきである。

UNIX/Linuxホスト上で使う印刷スプールシステムのタイプに依存するので、スプール管理 アプリが見つける、管理されているジョブキューの一部でないファイルは削除される。 これは、ジョブが(Sambaによって)このディレクトリ中にスプールされて消えてしまう現象の 説明になるだろう。

Chapter 22. CUPS印刷環境のサポート

Kurt Pfeifle

Danka Deutschland GmbH

Ciprian Vizitiu

drawings 

Jelmer R. Vernooij

drawings 
The Samba Team

(27 Jan 2004)

Table of Contents

概要
機能と利便性
Overview
基本的なCUPSサポート設定
libcups.soを使ったsmbdとのリンク
CUPSを使う簡単なsmb.confの設定
より複雑なCUPS smb.conf設定
高度な設定
集中スプール対ピアツーピア印刷
直接印刷機能:Windowsクライアント上のベンダドライバー
Windowsクライアントドライバーのインストール
application/octet-streamのためのraw印刷を明示的に有効にする
ドライバーアップロード手法
Postscriptドライバーダウンロードを使う高度に賢い印刷
Windows上でのGDI、UNIX上でのPostScript
Windowsドライバー、GDIとEMF
UNIX印刷ファイル変換とGUIの基礎
PostScriptとGhostscript
Ghostscript: 非Postscriptプリンターに対するソフトウェアRIP
PostScriptプリンター定義(PPD)の仕様
Windows形式のベンダPPDの使用
非PostScriptプリンターのためにCUPSはPPDを使う
CUPSフィルタリングアーキテクチャ
MIMEタイプとCUPSフィルタ
MIMEタイプ変換ルール
フィルタリングの概要
Prefilters
pstops
pstoraster
imagetops と imagetoraster
rasterto [プリンター固有]
CUPSバックエンド
cupsomatic/foomaticの役割
完全な図解
mime.convs
Raw印刷
application/octet-stream 印刷
非PostScriptプリンターのためのPostScriptプリンター記述
cupsomatic/foomatic-ripネイティブなCUPS印刷
フィルタリングチェインの例
CUPSドライバー/PPDの提供元
インタフェーススクリプトを伴う印刷
ネットワーク印刷(Windowsのみ)
WindowsクライアントからNT印刷サーバーへ
クライアント上でのドライバーの実行
サーバー上でのドライバーの実行
ネットワーク印刷(WindowsクライアントとUNIX/Samba印刷サーバー)
WindowsクライアントからCUPS/Samba印刷サーバーへ
Sambaによるジョブファイルの受け取りとCUPSへの引き渡し
ネットワーク PostScript RIP
UNIX上の、非PSプリンターのためのPPD
Windows上の非PostScriptプリンターのためのPPD
CUPSクライアントとしてのWindowsターミナルサーバー (WTS)
カーネルモードでのプリンタードライバーの実行は多くの問題を引き起こす
Workarounds Impose Heavy Limitations
CUPS: A Magical Stone?
カーネルモードでもPostScriptドライバーは大きな問題はない
ドライバーダウンロードを行うためのCUPSの設定
cupsaddsmb: 不明なユーティリティ
cupsaddsmb用のsmb.confの準備
Windows NT/200x/XP用のCUPSPostScript Driver
異なったドライバーファイルの認識
ドライバーファイルの入手
Windows NT/200x/XP用のESP Print Pro PostScriptドライバー
考慮すべき警告
WindowsのCUPS PostScriptドライバー対Adobeドライバー
cupsaddsmbの実行(Quiet Mode)
詳細な結果を表示するcupsaddsmbの実行
cupsaddsmbについて理解する
もしもcupsaddsmbが正しく終了した場合、どのように認識するか
Samba PDCににおけるcupsaddsmb
cupsaddsmbフローチャート
クライアント上でのPostScriptドライバーのインストール
クライアント上での危険なPostScriptドライバー設定を防止する
rpcclientを使ったPostScriptドライバーファイルの手動インストール
rpcclientマニュアルページのチェック
rpcclientマニュアルページの理解
Producing an Example by Querying a Windows Box
adddriverとsetdriverを完了させるための要求事項
15ステップでの手動ドライバーインストール
トラブルシューティング再考
印刷関連の*.tdbファイル
Trivial Database Files
バイナリ形式
*.tdbファイルの喪失
tdbbackupの使用
Linuxprinting.orgからのCUPSプリントドライバー
foomatic-rip と Foomaticの説明
foomatic-ripとFoomatic PPDのダウンロードとインストール
CUPSによるページの課金
Quotasの設定
正しいあるいは不正な課金
Windowsクライアント用のAdobeとCUPS PostScriptドライバー
page_logファイルの形式
存在する欠点
将来の構想
他のアカウントツール
追加の材料
CUPSスプールフィルタの自動削除または保存
CUPS構成の設定の説明
準備
手動の設定
Windowsに接続された印刷へのCUPSからの印刷
より詳細なCUPSフィルタリングチェーン
よくあるエラー
Windows 9x/Meクライアントがドライバーをインストール出来ない
cupsaddsmbが、無限にrootパスワードを問い合わせてくる
cupsaddsmbrpcclient addriverがエラーを出す
cupsaddsmbのエラー
クライアントがSambaプリンターに接続できない
Windows 200x/Xpからの新しいアカウント再接続のトラブル
間違ったユーザーでSambaサーバーに接続されるのを防ぐ
AdobeドライバーからCUPSドライバーにアップグレードする
PDCであるSambaサーバー上でcupsaddsmbが使えない
削除されたWindows 200xプリンタードライバーが引き続き表示されている
Windows 200x/XP ローカルセキュリティポリシー
Administratorはすべてのローカルユーザーに対してプリンターをインストールできない
NTクライアント上での印刷の変更、機能の通知
Windows XP SP1
Windows 200x/XP上ですべてのユーザーが印刷オプションを設定出来ない
Windowsクライアント上でのドライバー設定における、多くに共通する失敗
cupsaddsmbが、新しくインストールしたプリンターで動かない
/var/spool/samba/のアクセス許可が、再起動後毎回リセットされる
lpという名前の印刷キューが印刷ジョブを間違って扱ってしまう
cupsaddsmbに対するAdobe PostScriptドライバーファイルの位置
CUPS印刷プロセスの概要

概要

機能と利便性

共通UNIX印刷システム(CUPS)は 現在非常に一般的になってきている。すべての主要なLinuxディストリビューションは 現在既定値の印刷システムとしてこれと導入している。ただ、残念ながら、これは まだ非常に取っつきづらいツールである。ほとんどの場合、これはちゃんと動く。 多くの人は、これが動いている間は、その中身を覗きたくなく、それを ブラックボックスとして扱う傾向がある。しかし、ひとたび 小さな問題が発生すると、どこからデバッグしていいかということを見つける 困難が生じる。CUPSに関連したより多量の情報もある、 旧式の印刷サポートも参照のこと。

CUPSは固有で強力な機能を持っている。その基本機能は容易に把握でき、 かつそれらは新しい。これは他のものと違い、より現代的な印刷システムであり、 この新しいシステムで印刷することに関する以前の知識を適用しないことが最も良い。 むしろ、最初からCUPSを理解することをすべきである。この文書はCUPSの完全な理解 を手助けする。まず基本的な点から最初に始めよう。

Overview

CUPSは印刷スプールシステムというもの以上である。これは、新しいインターネット印刷 プロトコル(IPP)に従う完全な印刷管理システムである。IPPは産業製品であり、 ネットワーク印刷に関するInternet Engineering Task Force (IETF)標準である。 この機能の多くはWebブラウザー(CUPS印刷サーバーにアクセスするプラットフォーム非依存の アクセスを提供する)経由でリモート(またはローカル)から管理することが出来る。さらに 追加で、伝統的なコマンド行といくつかのより新しいGUIインタフェースを持っている (GUIインタフェースはサードパーティによって開発され、たとえば、KDEのoverwhelming KDEPrintなどである)。

CUPSは、smartプリンター(すなわち、CUPSがプリンターに対して要求 された時にファイル形式の変換を行う)と同じように、rawプリンター すなわち、印刷ファイル形式を変換しない)の作成が出来る。多くの手段で、Microsoft Windows 印刷関しシステム同じような機能がCUPSにはある。もちろん、CUPSの推進者ならば、 CUPSの方がもっと良いと言うだろう!多くの場合、Samba経由でMicrosoft Windows印刷 クライアントとの間でCUPSがインタフェースを取るための設定方法を説明しよう。

基本的なCUPSサポート設定

Samba-3.0(2.2.xから使える)でのCUPSを使った印刷環境の、最も基本的なsmb.confのセットアップは printing = cupsprintcap = cupsという2つのパラメーターを必要とする。 CUPSはprintcapファイルを必要としない。しかし、cupsd.conf設定ファイルは、 サードパーティアプリケーション(例えばPrintcap /etc/printcapPrintcapFormat BSD)に便利なように、どのように、CUPSによって 自動的に作成され、管理されるファイルを制御する2つの関連するディレクトリを知っている。 旧式のプログラムはしばしばprintcapファイルに含まれているプリンター名が存在することを 要求するので、そうでないと印刷を拒否してしまう。CUPSがprintcapファイルを作成して管理する ようにしておくこと。詳細は、man cupsd.confと、 CUPS Webサイトにある、CUPSサーバーそれ自身が提供する、関連する貴重な文書のようなCUPS関連の 文書を参照のこと。

libcups.soを使ったsmbdとのリンク

SambaはCUPSと特別な関係がある。SambaはCUPSライブラリサポート機能を有効にして コンパイルできる。最も最新のバージョンでは、このサポートを有効にしている。 既定値では、CUPSはsmbdとその他のSambaバイナリにリンクされる。もちろん、 libcups.soをSambaにリンクしなくてもCUPSを使う事が できるが、要求されるあるいはサポートされる設定にいくつかの違いがある。

Sambaがlibcupsとリンクされ、コンパイルされた時、 printcap = cupsは、プリンター一覧の表示、 ジョブの投稿、キューの問い合わせなどにCUPS APIを使う。それ以外は、印刷のために、 これらの操作を、-orawオプションを付加して、System Vの コマンドにマップする。Linuxシステムでは、smbdが、libcupsライブラリにリンク されているかを、lddユーティリティを使う事で知ることが出来る (lddは他のOSプラットフォーム上には無いかもしれないか、 その機能は別のコマンドによって行われるかもしれない):

root# ldd `which smbd`
libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000)
libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
[....]

libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000) 行は、このバージョンのSambaがCUPSサポートするようにコンパイルされていることを 示している。もしもこの場合で、printing = cupsが設定されている場合、 他のsmb.conf中にある、手動で設定した印刷関係のコマンドは無視される。 これは重要な点なので覚えておくこと!

Tip

何らかの理由で、固有の印刷コマンドを設定するために、 printing = sysvを設定することにより、これを行える ようにする事が必要である。しかし、CUPSとSambaを密に統合する利便性のすべてを 失うことになる。これを行う場合、以下のように、印刷システムコマンドを手動で設定しなければ ならない。 (最も重要: print command; other commands are lppause command, lpresume command, lpq command, lprm command, queuepause command and queue resume command).

CUPSを使う簡単なsmb.confの設定

最も簡単な印刷関連のsmb.confファイル に、基本的なCUPSサポートを有効にする、最も簡単な印刷関連のsmb.conf設定を 要約する:

Example 22.1. 最も簡単な印刷関連のsmb.confファイル

[global]
load printers = yes
printing = cups
printcap name = cups
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
guest ok = yes
writable = no
printable = yes
printer admin = root, @ntadmins, @smbprintadm

これはCUPSに対する基本的な印刷設定に必要なもののすべてである。Windowsクライアント から投稿されたすべてのグラフィック、PDFとPostscriptファイルは印刷できる。 しかし、ほとんどのWindowsユーザーは、GUIアプリケーションを開かないで、印刷する ファイルの種類を送る方法を知らない。Windowsクライアントはインストールされた ローカルのプリンタードライバーを持つ傾向があり、GUIアプリケーションの印刷ボタンは、 プリンタードライバーを開始する。ユーザーは滅多にコマンド行からファイルを送らない。 UNIXクライアントとは違い、グラフィック、テキストあるいはPDFファイルを直接 スプーラに送らない。通常、アプリケーションのネイティブな形式と印刷データ ストリームの間でホックされたprinter driverを使うGUI アプリケーションから排他的に印刷を行う。もしもバックエンドプリンターが Postscriptデバイスでない場合、印刷データストリームはバイナリで、 対象のプリンターのみが対象である。この問題が引き起こすこととそれを防ぐことを 学ぶために、この先を読み続けること。

より複雑なCUPS smb.conf設定

1台のプリンター用にグローバルなCUPS設定を上書きする例 は、smb.conf用の、やや複雑な印刷関連設定である。これはすべてのプリンターに対して 一般的なCUPS印刷サポートを有効にするが、1台だけ設定が異なるプリンター共有を定義する。

Example 22.2. 1台のプリンター用にグローバルなCUPS設定を上書きする

[global]
printing = cups
printcap name = cups
load printers = yes
[printers]
comment = All Printers
path = /var/spool/samba
guest ok = yes
writable = no
printable = yes
printer admin = root, @ntadmins, @smbprintadm
[special_printer]
comment = A special printer with his own settings
path = /var/spool/samba-special
printing = sysv
printcap = lpstat
print command = echo "NEW: `date`: printfile %f" >> /tmp/smbprn.log ; echo " `date`: p-%p s-%s f-%f" >> /tmp/smbprn.log ; echo " `date`: j-%j J-%J z-%z c-%c" >> /tmp/smbprn.log ; rm %f
guest ok = no
writable = no
printable = yes
printer admin = kurt
hosts deny = 0.0.0.0
hosts allow = turbo_xp, 10.160.50.23, 10.160.51.60

この特別な共有は、テスト目的専用である。これは印刷ジョブをファイルに書かない。 これは、ジョブパラメーターをSambaが認識する/tmp/smbprn.log ファイルに記録し、ジョブファイルを削除する。さらに、この共有の printer adminkurtで (@ntadminsグループではなくて)、ゲストアクセスは許可されず、共有は ネットワークコンピュータに公開されず(そのため、これが共有であることを知っておく 必要がある)、3つのホストのみからアクセスできる。その共有に対して、CUPSが起動し、 印刷ジョブ上で通信をすることを防ぐために、 printing = sysvprintcap = lpstatを設定する必要がある。

高度な設定

すべての設定オプションを確認する前に、いくつかの点について明確にする。 ネットワーク印刷は、きちんと計画されて、正しくセットアップされている 必要がある。このことは頻繁には発生しない。旧来のシステムや 小さな業務用LAN環境では、しばしばデザインと良い保守が存在していない。

集中スプール対ピアツーピア印刷

多くの小規模オフィスや家庭用ネットワークでは、計画がひどい、より大きな環境と 同じように、各クライアントがネットワークプリンターへ直接アクセス出来るように なっている。これは一般的には悪いアイデアである。他のクライアントのジョブが 印刷しているときに、あるクライアントのアクセスを頻繁にブロックしてしまう。 ジョブが終了するのを待っている間、最初のクライアントのアプリケーションは フリーズしてしまうかもしれない。同様に、数多くのジョブが印刷しているとき、 それぞれが異なったページをまぜこぜにしてしまうという苦情もしばしば聞く。 よりよいコンセプトは、プリントサーバーを使うことである。これは、すべてのジョブを 集中したシステムに一本化し、即時に反応し、複数の並列したクライアントから ジョブを受け取り、正しい順序でプリンターに転送する。

直接印刷機能:Windowsクライアント上のベンダドライバー

ほとんどの現代的に設定されたUNIX印刷サーバーは、本当に単純なセットアップを意味する、 SambaのWindowsクライアントのために振る舞う。それらの唯一の業務は、Sambaによって すべてのジョブが扱われる直接スプーリングを管理することである。 この試みは、Windowsクライアントが、印刷デバイスに送られる準備が出来た印刷ジョブ ファイルを準備することが期待されるということである。この場合、ネイティブな (ベンダが供給した)Windowsプリンタードライバーは、各、およびすべてのクライアントで、 対象デバイスのものをインストールする必要がある。

同様に現代的な、簡単な方法で、CUPS、SambaとWindowsクライアントを設定することは 可能である。CUPSプリンターが直接印刷モード状態で設定されているならば、完全に 印刷ジョブ(ファイル)を描画することは、Sambaクライアントの責任である。ファイルは プリンターに直接配信するのに適した形式で送られる必要がある。クライアントはこれを 行うために、ベンダが提供したドライバーを動作させる必要がある。この場合、CUPSは 何ら印刷ファイル形式変換を行わない。

可能な、最も簡単な印刷設定は、直接印刷(raw print-through)である。これは、 Windowsクライアントに物理的に結合されているようにプリンターをインストールする 事によって行える。次に、それをrawネットワーク印刷キューにリダイレクトする。 この手続きは、以下の手順によって行えるだろう:

Procedure 22.1. 直接CUPS印刷サポートのための設定手順

  1. /etc/cups/mime.typesの、ファイルの最後あたりにある 下記の行のコメントを外す:

    #application/octet-...
    

  2. /etc/cups/mime.convsに対しても同様に行う。

  3. Webインタフェースを使ってrawプリンターを追加する。ブラウザーで http://localhost:631をクリックする。 Administrationに入り、プロンプトに従ってプリンターを追加する。 ドライバーをこれにインストールしてはならない。Rawを選択する。 Raw Queueというキュー名を選択する。

  4. smb.confファイル中の[printers]セクションに use client driver = Yesを追加し、 [global]セクション中に、 printing = CUPSprintcap = CUPSを追加する。

  5. ローカルプリンターのようにプリンターをインストールし、結果、印刷先が LPT1:となる。

  6. Detailタブ下の設定を編集し、上記で設定したrawプリンター キューを指し示すlocal portを作成する。例: \\server\raw_q。ここで、raw_q という名前はCUPS環境中で印刷キューに割り当てた名前である。

Windowsクライアントドライバーのインストール

Windowsクライアント上のプリンタードライバーは2つの機能的に異なった方法でインストール できる:

  • 手動で各クライアント上にドライバーを1つずつインストールする。 これは旧式のLanMan形式印刷環境を必要とし、 \\sambaserver\printershareタイプの接続を使う。

  • プリントサーバー(Samba)上でドライバー(後でダウンロードするための)の準備と配信を 行う。これは、プリンターに最初にアクセスするとき、半自動的にドライバーを入手して インストールするポイントアンドプリントをクライアントが使う ことが出来るようになる。この方法を使うと、NT/200x/XPクライアントは、 SPOOLSS/MS-RPCタイプの印刷呼び出しを使う。

二番目の方法は、管理コストの削減と、偶然異なったバージョンのドライバーが使われる ことを防ぐのに、最初のものを使うよりも推奨される。

application/octet-streamのためのraw印刷を明示的に有効にする

もしも最初のオプション(ドライバーはクライアントサイド上でインストールされる)を使う 場合、注意すべき設定が1つある:CUPSに対して、手の込んだ(バイナリ)ファイル形式 であるraw印刷を許可するように設定する。rawモード印刷を動かす ための、正しい設定する必要があるCUPSファイルは以下の通り:

  • /etc/cups/mime.types

  • /etc/cups/mime.convs

両者はRAMモード操作を許可するためにコメントアウトしなければならないエントリ (それぞれのファイルの最後の部分)を含む。/etc/cups/mime.types 中では下記の行が存在するようにする:

application/octet-stream

/etc/cups/mime.convsでは、この行が存在するようにする:

application/octet-stream   application/vnd.cups-raw   0   - 

もしも、2つのファイルが、Windowsクライアントからの印刷に対して正しく設定されて いない場合、恐ろしいUnable to convert file 0 というメッセージが、が、CUPSのerror_logファイル中に現れる だろう。

Note

mime.convsmime.typesファイルを raw印刷を行うことだけを 許可するように編集する。

背景.  CUPSは、伝統的な印刷システムが既定値では印刷デバイスに手の込んだ(おそらく バイナリ)のデータを、ユーザーに送ることを認めていないと比べて、より セキュリティに気づいている印刷システムである。これは、プリンターに対して、 少なくとも大量の紙とインクを無駄にすることとなる、 サービス不能攻撃を引き起こす不正な使い方を簡単に行える。 不明なデータはCUPSによって、 MIME type: application/octet-streamとタグ付けられ、 プリンターに送ることを許可されない。既定値では、他の(既知の)MIMEタイプである rawのみを送ることが出来る。rawを送ることは、 CUPSがそれらを変換せず、何もさわらないでプリンターに渡すことを意味する。

これが、ベンダドライバーをローカルにインストールしたWindowsクライアントによって 準備されたrawファイルをCUPS/Sambaの協調印刷で行うときに知っておく 必要があることのすべてである。もしもより詳細なCUPS/Samba印刷についての背景 情報について興味がないならば、この章の残りの部分を読み飛ばせばよいだろう。

ドライバーアップロード手法

この節では、プリンタードライバーをアップロードする、3つのなじみやすい方法に、 さらに新しいもの1つについて説明する。

もしも、MS-RPCタイプの印刷を使いたいならば、最初にSambaサーバー上に ([print$]共有)ドライバーをアップロードしなければならない。 Sambaホスト上からプリンタードライバーを配信する方法(結果、Windowsクライアントは ポイントアンドプリント経由でダウンロードしそれを利用できる) についての議論は、この資料の 旧式の印刷 の章を参照のこと。 以下は、Sambaサーバー上にクライアントドライバーを準備するための3つの方法への 説明又は参照である:

  • GUIであるAdd Printer Wizardを使う Windowsクライアントからのアップロード方法。

  • コマンドラインのsmbclient/rpcclientを使う UNIXワークステーションからのアップロード方法。

  • Imprintsツールセットを使う方法。

これらの3つの方法は、CUPSに対して同じように適用される。 cupsaddsmbユーティリティは最新で、CUPSを使っている場合、 WindowsドライバーをSamba中に起き、提供するより便利な方法である。

cupsaddsmbは、この章の後の方でより詳細に説明される。しかし、 まず初めにCUPSフィルタリングシステムを説明し、WindowsとUNIXの印刷アーキテクチャの 違いを比較する。

Postscriptドライバーダウンロードを使う高度に賢い印刷

dumpプリントサーバーをセットアップする方法は分かっているが、それは すなわち、プリントジョブをrawでスプールするサーバーは、印刷データを 変更しないということである。

よりか指向違法方でCUPSをセットアップする必要があるかもしれない。その理由は いろいろとある:

  • もしかしたら、あなたの上司は月次の印刷統計報告を希望しているだろう。 すなわち、どのプリンターがどのくらいページを印刷したか?、印刷における平均的な 時間ピークはどのくらいか?、どの部署がどのくらい印刷したか?

  • もしかしたらプリントquotaシステムを設定したかと聞かれるだろう: ユーザーが、一定期間内での制限より超えたジョブを印刷出来ないという。

  • もしかしたら以前のネットワーク印刷の設定はひどい状態で、 一から再構成しなければならないだろう。

  • もしかしたらNTkernelモードで動作するあまりデバッグ されていないプリンタードライバーに起因するブルースクリーンを、とても たくさん体験しているだろう?

これらのゴールはraw印刷サーバーによっては成し遂げることが出来ない。それらの要求に auサーバーを構築するためには、最初にどのようにCUPSが動作するかと、どのように それらの機能を有効にするかを学ぶ必要がある。

以下では、WindowsとUNIX印刷環境における、いくつかの基本的なコンセプトの 比較をまず行い、次に、CUPSフィルタリングシステムについて、どのように動作するか、 どのように微調整できるかの説明を行う。

Windows上でのGDI、UNIX上でのPostScript

ネットワーク印刷は最も複雑でエラーが発生しがちであり、ユーザーや管理者が 遭遇しがちである日々の作業の1つである。これはすべてのOSプラットフォーム上で 真実であり、そうなる理由がある。

プリンターに任意のファイルフォーマットを送り込み、それが印刷されることを期待する ことはできない。ファイルフォーマット変換を行う必要がある。問題は、すべての メーカとプリンタータイプに共通の、共通標準印刷ファイルフォーマットがないという ことである。Postscript(Adobeの商標)とその拡張であるPCL(HPの商標)はページ記述言語 (PDL)として使われていることにより、ほぼ公式な標準として開発されて いる。しかし、多くのメーカは引き続き固有のものを使っている (それらの理由は、プリンター内蔵のPostscriptインタプリタの、受け入れられないような ライセンス費用などである)。

Windowsドライバー、GDIとEMF

WindowsOSでは、フォーマット変換ジョブはプリンタードライバーによって行われる。 Microsoft Windows OSプラットフォーム上ではすべてのアプリケーションプログラマは、 それらの基盤となるOSそれ自身の一部分、あるいは一区画として、自由に使える 組み込みのAPI、グラフィカルデバイスインタフェース(GDI)を使える。このGDIコアは 絵、フォントと文書を画面上に描画するのと同様に 紙の上に(印刷)する、すべてのWindowsプログラムにある1つの 共通基盤として使える。そのため、プリンタードライバー開発者はよく定義されたGDI出力を 固有のドライバー入力として標準化できる。WYSIWYG(What You See Is What You Get)の 実現は、スクリーン上のグラフィックプリミティブが紙上の描画オブジェクトと同じ ようで、同じソースから来るために、相対的に容易である。このソース、すなわちGDIは、 しばしば拡張メタファイル(EMF)と呼ばれるファイルフォーマットを生成する。EMFは プリンタードライバーによって処理され、プリンター固有のファイルフォーマットに変換される。

Note

Microsoft Windows中のGDI基盤に対して、Appleは紙と画面出力を、その(BSDUNIXベース なのだがご存じだろうか?)Mac OS XとDarwinオペレーティングシステムという 同じ基盤上に置くことを選んだ。Appleのコアグラフィックエンジン は、すべての表示作業にPDF派生のものを使う。

ローカルプリンターに対するWindowsの印刷中の例は、 ローカルWindows印刷を図示している。

Figure 22.1. ローカルプリンターに対するWindowsの印刷

ローカルプリンターに対するWindowsの印刷

UNIX印刷ファイル変換とGUIの基礎

UNIXとLinuxでは、OSカーネルかX(画面表示)サーバー中に、構築された、類似のレイヤは ない。すべてのアプリケーションはそれ自身でその印刷出力を作成することに責任が ある。幸い、大部分がPostscriptを使い、それを何らかの共通基盤としている。 また、悪いことに、同じ文書を画面上に表示することとどのようにそれを紙に 印刷するかを行う、非常にたくさんの(そして何ら共通項がない)方法がある。 これは、数10年前にさかのぼってみると、グラフィカルユーザーインタフェースのための UNIX 基盤とプロトコルを設計したX.orgの前身は、幾人かがその時点で要求したように、 紙出力についての責任を取るのを拒否し、それ自身を 画面表示のみに制限した(何年か後、Xprint プロジェクトが開発中で、Xのフレームワーク中に、PostscriptとPCLドライバーを含む 印刷サポートを構築することを試みたが、まだ完成していない)。この、余り好ましくない 遺産は、使用しているシステムの、種々のfontディレクトリ中で、今も 見ることができる。X表示用と印刷用に使うフォントが分かれている。

背景.  Postscriptプログラミング言語はAdobeの開発物であるが、その仕様は 広範囲に公開されている。その能力は、その強力なグラフィカルオブジェクト (フォント、シェープ、パターン、行、曲線、と点)を記述する能力、その属性 (色、線の幅)とそれらを操作する(拡大縮小、変形、回転、移動)ことによっている。 その公開された仕様により、能力がある誰でも、固有のPostscriptインタプリタ実装を 作成でき、画面あるいは紙状にPostscriptファイルを表示するのに使える。 ほとんどのグラフィック出力デバイスは ラスタイメージピクセル(ペンプロッタは特筆すべき例外)というコンセプトを基盤と している。もちろん、テキスト形式でPostscriptファイルを見ることもでき、 ラスタライザによって解釈されるに必要な言語命令であるPostscriptコードを読む ことも出来る。ラスタライザは、ビューワプログラムによって画面上で表示されるか、 プリンターによって印刷されるかする、ピクセルイメージを生成する。

PostScriptとGhostscript

UNIXは紙への印刷と画面上への表示についての共通基盤が欠けている。UNIXの、好ましく ない遺産にもかかわらず、自由に使えるPostscriptプリンターを持っている場合、基本的な 印刷はかなり簡単である。その理由は、それらのデバイスは、ラスタイメージプロセッサ (RIP)と呼ばれる内蔵PostScript言語インタプリタを持っているという (それにより、他のタイプのプリンターよりも値段が高い)ことである。それに向けて PostScriptを送り込むと、印刷したページを出力する。RIPは紙の上で見る事ができる、 ビットマップの絵にPostScript描画コマンドを変換するすべての大変な仕事をこなし、 プリンターによってそれを処理してしまう。これは、Windows上からPostScript印刷を 行うのと何ら違いはない。

Note

一般的なUNIXプログラムと印刷システムが、PostScriptを使っている間は、主にPPDを 認識していない。PPDはPostScriptプリンター記述ファイルである。これは プリンターがサポートしているすべてのオプションを指定し、制御する事を可能にする。 そのオプションとは、たとえば、両面印刷、ステープル留めと穴空けである。そのため、 WindowsかAppleユーザーとは違って、たくさんのサポートされたデバイスとジョブ オプションを、UNIXユーザーは長い時間選択できなかった。しかし、今では、CUPSがある。 PostScriptプリンターによる印刷で図示されているように。

Figure 22.2. PostScript Printerによる印刷

PostScript Printerによる印刷

しかしながら、それ以外のタイプのプリンターもある。それらはどのようにPostscriptを 印刷するかが分からない。それらは、しばしばメーカ固有のPDLを使う。それらに対して 印刷を行う事の注文はもっと多い。利用しているUNIXアプリケーションはほとんどの 場合、Postscriptを生成し、それらのデバイスはPostscriptを理解しないので、 それに対してデータを送る前に、ホスト上で使用しているプリンターに合わせた印刷 ファイルのフォーマット変換を行う必要がある。

Ghostscript: 非Postscriptプリンターに対するソフトウェアRIP

ここからGhostscriptの説明を始める。Ghostscriptは、UNIXプラットフォームで 使われている、伝統的な(そしてとても強力な)Postscriptインタプリタである。 これはソフトウェアによるRIPであり、ソフトウェアファイルフォーマットと同様、 非常に広範囲のハードウェアデバイスへの、たくさんのファイル変換を行う能力がある。 Ghostscript技術とドライバーは非PostscriptハードウェアでPostscript印刷を実行 できるようにするものである。これについては 非Postscriptプリンターに対するRIPとしてのGhostscript に説明がある。

Figure 22.3. 非Postscriptプリンターに対するRIPとしてのGhostscript

非Postscriptプリンターに対するRIPとしてのGhostscript

Tip

使用しているGhostscriptバージョンの内蔵デバイスすべてを確認する ために、gs -hコマンドを使う。もしも、使用しているGhostscriptの コマンド行に-sDEVICE=png256というパラメーターを指定した ならば、入力をPNGファイルに変換するように、Ghostscriptに指定する。コマンド行上の deviceの名前指定は、入力をどのように描画するかを正確に Ghostscriptに指示するのに最も重要な単一パラメーターである。新しいGhostscriptの バージョンは、現在artofcode LCCにおいて、通常かなり間隔を空けてリリースされる。 通常最初はAFPLライセンスで提供されるが、次のAFPLバージョンが リリースされると、すぐにGNU GPLライセンスで再リリースされる。GNU Ghostscript はおそらくほとんどのSambaシステム上にインストールされているバージョンである。 しかし、いくつかの違いがある。 そのため、ESP Ghostscriptは、たくさんのバグ修正、追加のデバイスと改善がある、 GNU Ghostscriptの拡張として開発されている。これは、CUPS, Gutenprint, MandrakeSoft, SuSE, Red Hatと Debianからの開発者によって一緒に保守されている。それには cupsデバイス(CUPSから非PSプリンターに印刷する基本部分)を含む。

PostScriptプリンター定義(PPD)の仕様

Postscriptの本質がデバイス非依存の方式でページレイアウトを表現するための PDLである間は、実世界での印刷上部は常時デバイス固有の機能を持ったハードウェア 上で最終的に出力される。ハードウェアの違いに気を遣うことと、機能改善を図るため、 Adobeは文法とPostscriptプリンター定義(PPD)ファイルのファイルフォーマットを定義 してきた。すべてのPostscriptプリンターはそれらのファイルの1つを同梱して出荷されて いる。

PPDは、そのプリンターに割り当てられた一般的および特別な機能についてのすべての情報を 含んでいる。扱える異なった解像度は何か?両面印刷ユニットがあるか?ペーパートレイは いくつあるか?メディアのタイプとサイズは何が使えるか?それぞれの要素について、 プリンターに送られる特別なコマンド文字列を、それを有効にするために指定する事が 出来る(ほとんどの場合、Postscriptファイル中に)。

PPDからの情報はプリンタードライバーによって考慮されることを意味する。そのため、 与えられたプリンターのための、Windows PostScriptドライバーの一部としてインストール されるものはプリンターのPPDである。それが意味をなす場合、PPD機能は、印刷 オプションをユーザーに選択されるために表示される、ドライバーのユーザーインタフェース ダイアログ中で提供される。最後に、ユーザーの選択は、ドライバーによって作成された PostScriptファイル中に(特別なPostScript、PJL、JCLあるいはベンダ固有のコマンド 形式として)何らかの形で書かれる。

Warning

特定の印刷ジョブ出力を行うために、デバイス固有のコマンドを含んで作成された 特定のマシン上のPostScriptファイルは期待通りには印刷出来ないかもしれなく、 すべてのモデル上で印刷可能ではないかもしれない。それはソフトウェアによる 追加処理に適さないかもしれない(すなわち、PDF抽出プログラムによって)。

Windows形式のベンダPPDの使用

CUPSはそのPostScriptモデルのための、開発元によって供給された、すべての仕様に 従っているPPDを扱うことが出来る。もしもベンダがマニュアルとパンフレットに 使用しているOSについての言及がなかったとしても、それらを安全に信用できる: もしも、Windows NTバージョンのPPDを入手したならば、CUPS中で変更なしに利用でき、 その結果、Windows NTユーザーが出来るように使用するプリンターのすべての能力に アクセスできる。

Tip

オンラインでどのようなPPDの仕様遵守状態を確認するためには、 http://www.cups.org/testppd.php に行き、PPDをアップロードする。すぐにその結果を見ることができる。バージョン 1.1.19以降のすべてのバージョンのCUPSは、よりずっと厳しい内蔵PPD解析と検査 コードが有効になっている。印刷トラブルが起きたら、このオンラインリソースを 最初に調べる場所としてほしい。

Warning

実際のPostScriptプリンターのためには、Linuxprinting.orgからの FoomaticcupsomaticPPDを 使ってはならない。それらのデバイスには、オリジナルの ベンダが提供したPPDが常時最初の選択肢となる。

Tip

もしも、特定のデバイスに対するオリジナルのベンダ提供PPDを捜していて、LAN上の NT4マシン(あるいは他の任意のWindowsマシン)がインストールされているPostScript プリンターを持っている場合、すべてのプリンタードライバーが格納されているWindows ディレクトリにアクセスするために、 smbclient //NT4-box/print\$ -U usernameを使用する。 最初に、捜しているPPDのために、W32X86/2サブディレクトリを 捜してみる。

非PostScriptプリンターのためにCUPSはPPDを使う

CUPSは非PostScriptプリンターを扱うために、特別に作成されたPPDをも使う。それらの PPDは通常ベンダから供給されない(そして、同じモデル名のPostScriptプリンター用の PPDファイルを使うことが出来ず、非PostScriptバージョンが動くことを期待することも 同じである)。非PostScriptプリンターに対してPPDがどのように適用されるかを知るため には、最初にCUPSフィルタリングとファイルフォーマット変換アーキテクチャについて 深く言及する必要がある。引き続き読み続けること。

CUPSフィルタリングアーキテクチャ

CUPSフィルタリングシステムの中核は、Ghostscriptによっている。Ghostscriptを追加する事で、 CUPSはそれ自身固有のフィルタ以外のいくつかを使う。あなた自身(あるいはベンダ)はさらに フィルタを追加しても良い。CUPSはすべてのデータファイルフォーマットを種々のMIMEタイプの ラベル配下で取り扱う。入力された各印刷ファイルは、最初に行われる自動タイプわけに基づいて 扱われる。自動タイプわけにより、MIMEタイプが決定する。与えられたMIMEタイプは、選択された対象 プリンターに、0またはそれ以上の、フィルタリングチェーンが自動的に(暗黙のうちに)設定される。 この節では、どのようにMIMEタイプ認識と変換ルールが相互に作用するかについて説明する。 それらは、与えられた入力データフォーマットに対する、動作させるフィルタリングチェーンを 自動的に設定するために、CUPSによって使われる。

もしもCUPSがネイティブにビットマップにPostScriptファイルをラスタライズするならば、 それは以下の2つのステージで行われる:

  • 最初のステージでは、cupsという名前のGhostscriptデバイスを使い (これは、バージョン1.15以降)、CUPS rasterと呼ばれる一般的な ラスタ形式を生成する。

  • 第二のステージでは、標準的なCUPSラスタをデバイス固有のラスタに変換する、 ラスタドライバーを使う。

使用するGhostscriptのバージョンがcupsデバイスをコンパイルしてあるように しておくこと(これはgs -h |grep cupsで調べられる。それ以外だと、 CUPS CUPS error_logファイルにUnable to convert file 0 というエラーメッセージが表示されるだろう。使用しているGhostscript中にデバイスとして cupsが含まれるようにするには、GNU Ghostscriptにパッチを当てて再コンパイル するか、 ESP Ghostscriptを 使う必要がある。良い代替はESP Ghostscriptである。これはCUPSサポートだけではなく、 300もの他のデバイス(GNU Ghostscriptがおおよそ180くらいしかサポートしないのに対して)を サポートする。この広範囲なデバイスサポートがあるという理由で、ESC Ghostscriptは 非CUPSスプーラ用の、最初の選択肢としても使える。すべてのスプーラに対して、 Linuxprinting.orgによって現在は推奨されている。

CUPSプリンターは外部レンダリングパスを使うように設定しても良い。最も共通的なものは、 Linuxprinting.orgからの Foomatic/cupsomaticコンセプトによって提供されるものである。これは古いGhostscript を用いて、すべてを1ステップで処理する。これはcupsデバイスを使わないが、 その他の多くを使う。しかし、Foomatic/cupsomaticの使用にもかかわらず、最も良い解と 広範囲のプリンターモデルのサポートはESC Ghostscriptによって提供される (Foomatic/cupsomaticについての詳細、現在foomatic-ripと 呼ばれている、特に新しいバージョンについては、以下を参照)。

MIMEタイプとCUPSフィルタ

CUPSは/etc/cups/mime.types(と、同じディレクトリ中にある、 すべての*.typesファイル)を起動時に読み込む。これらの ファイルはCUPSがそのautotyping機能を動かしているときに適用されるMIMEタイプ 認識ルールを含む。ルールの文法はmime.typesのマニュアル ページとmime.typesファイルそれ自身のコメントセクションに 記述されている。簡単なルールは以下の通りである:

application/pdf         pdf string(0,%PDF)

これは、もしファイル名に.pdfという拡張子が付いているか、 あるいは、マジック文字列%PDFがファイルそれ自身の先頭の 正しいところ(開始時点からオフセット0)にある場合、それはPDFファイルである (application/pdf)。その他のルールは以下の通り:

application/postscript  ai eps ps string(0,%!) string(0,<04>%!)

もしも、ファイル名が.ai, .eps, .psという拡張子のどれかを持つか、ファイルそれ自身が %!<04>%!という文字列の どれかで始まるならば、それは一般的なPostScriptファイルである (application/postscript)。

Warning

使用するシステムが、/etc/cups/ディレクトリ中のどれかを 使うかもしれない、他のmime.typesファイルと混同しないこと。

Note

CUPS中の2つの似たようなMIMEタイプとの間で、重要な違いがある。1つは application/postscriptで、もう一つは application/vnd.cups-postscriptである。 application/postscriptがデバイス非依存を意味するので、 ファイルのジョブオプションは引き続きPSファイルの内容の外側にあり、CUPSによって コマンドラインか環境変数中に埋め込まれ、 application/vnd.cups-postscriptは、PostScriptそれ自身 中に埋め込まれるジョブオプションがあるかもしれない(適用可能ならば)。一般的な PostScript(application/postscript)の、デバイス固有の バージョン(application/vnd.cups-postscript)への変換は、 CUPSのpstopsフィルタの責任である。pstopsは変換を行う ためにPPD中に含まれる情報を使う。

CUPSはASCIIテキスト,HP-GL, PDF, PostScript, DVIと多くの画像イメージ形式 (GIF, PNG, TIFF, JPEG, Photo-CD, SUN-Raster,PNM, PBM, SGI-RGBやその他)と それらに関連したMIMEタイプとそのフィルタを扱うことが出来る。

MIMEタイプ変換ルール

CUPSは/etc/cups/mime.convs(と、同じディレクトリ中にある、 その他の*.convsというファイルも)を起動時に読み込む。 それらのファイルには入力MIMEタイプ、出力MIMEタイプ、入力タイプから出力を生成 できるフォーマット変換フィルタとその変換に関連する仮想のコストを意味する行を 含む。その1つの例は以下のようになる:

application/pdf         application/postscript   33   pdftops

これは、pdftopsフィルタが入力として application/pdfを取り、出力として application/postscriptを生成する。この操作の仮想コストは 33 CUPS-$である。次のフィルタはより高価で、66 CUPS-$かかる:

application/vnd.hp-HPGL application/postscript   66   hpgltops

これは、HP-GLプロッタファイルをPostScriptへ変換処理する hpgltopsである。

application/octet-stream

さらに2つの例である:

application/x-shell     application/postscript   33    texttops
text/plain              application/postscript   33    texttops

最後の2つの例はapplication/x-shell上と同じように text/plainで動作するtexttops フィルタを意味する(ヒント:この違いは、texttopsの 特筆すべき機能の文法のために必要とされる)。

フィルタリングの概要

mime.convsという名前の、よりたくさんの組み合わせがある。 しかし、あらかじめ定義してあるもの以外を使うことに制限はない。好みの、CUPS フレームワークに対する任意のフィルタを追加できる。それは最小限の要求に適合 するか、させねばならない。もしも、ある種の効果的なフィルタを見つける(か書くか) 場合、CUPSの要求が要求するものに従い、適切な行をmime.typesmime.convsに書く。そうするとCUPS内部でシームレスに動作する。

フィルタの要求

フィルタに対するCUPSの要求は単純である。入力としてファイル名か 標準入力を取り、標準出力に出力する。 これはまた下記の引数を持つ:

printer

プリンターキューの名前(通常これは動かすフィルタの名前である)。

job

印刷するジョブのジョブID値(数字)。

user

オリジナルのユーザー名属性からの文字列。

title

ジョブ名属性からの文字列。

copies

コピー数属性からの数値。

options

ジョブのオプション。

filename

(オプション)印刷を要求するファイル(もしも指定されなければ、 フィルタは標準入力からのデータ供給を 仮定する)。ほとんどの場合、CUPSで動作するようにさせるための 存在するフィルタを囲む単純なラッパプログラムを書くことは 簡単である。

Prefilters

以前に説明したように、PostScriptは、任意のUNIXベースの印刷システムにおいて 中核となるファイル形式である。PostScriptから、非PostScriptプリンターに送る ためのラスタデータを、CUPSは生成する。

しかし、印刷するためにサポートされた非PSフォーマットのどれかを送る時に何が起きる のだろうか?次にCUPSはPostScriptを最初に生成するために、それらの入力上で prefiltersを動かす。これは、ASCIIテキスト,PDF, DVI,かHP-GLから PostScriptを生成するためのprefilterである。それらのフィルタからの出力は常時 application/postscriptというMIMEタイプである (これは任意のデバイス固有のオプションはCUPSによってまだPostScriptに埋め込まれて おらず、呼ばれる次のフィルタはpstopsであることを意味する)。その出力は常時 application/vnd.cups-postscriptというMIMEタイプである (application/postscriptではない)場合、プリントオプションはすでにファイルに 埋め込まれている事を意味する。これは、 PostScriptを整形するためのCUPS内のprefiltering で説明されている。

Figure 22.4. PostScriptを整形するためのCUPS内のprefiltering

PostScriptを整形するためのCUPS内のprefiltering

pstops

pstopsは、application/postscriptapplication/vnd.cups-postscriptに変換するために使われる フィルタである。以前に説明したように、このフィルタはすべてのデバイス固有の印刷 オプション(両面印刷やstanpingと穴あけなどをプリンターに指示するコマンド)を、 PostScriptファイル中に挿入する。その例は、 デバイス固有印刷オプションの追加に例示されている。

Figure 22.5. デバイス固有印刷オプションの追加

デバイス固有印刷オプションの追加

これがすべてではない。これにより行われるその他の処理は以下の通り:

  • 印刷ページ範囲を指定する(すなわち、3, 6, 8-11, 16と19-21 か、偶数ページのみ印刷することを選べる)。

  • 1枚に2枚あるいはそれ以上のページを配置する(数値-up 機能と呼ばれる)。

  • /var/log/cups/page_logに、 課金情報を記録するための、ジョブのページ数をカウントする。

pstoraster

pstorasterはCUPSフィルタリングシステムの中核である。 これは、ラスタライズ処理の最初のステージに対して責任がある。その入力は application/vnd.cups-postscriptというMIMEタイプである。その出力は、 application/vnd.cups-rasterである。この出力形式はまだ印刷可能にはなっていない。 その目的は、デバイス固有印刷データの生成を有効にする、より特殊化した ラスタデバイスのための汎用入力形式として提供することである。 これについては、 PostScriptから中間ラスタ形式への変換ダイアグラム を参照のこと。

Figure 22.6. PostScriptから中間ラスタ形式への変換ダイアグラム

PostScriptから中間ラスタ形式への変換ダイアグラム

CUPSラスタは強力な機能を持つ汎用ラスタフォーマットである。これは、ページ単位 情報、色のプロファイルなど、下位のラスタドライバーで使われるものを含むことが 出来る。そのMIMEタイプはIANAに登録されていてその仕様はもちろん完全に公開されて いる。それを作るのはとても簡単で、選択したものに対応すべきプリンターモデル用に、 LinuxとUNIXラスタドライバーを製造元が作成するために、費用がかからないように 設計されている。CUPSは常時ラスタライズする最初のステージに注意を払っているので、 ベンダはGhostscript互換について注意を払う必要はない(実際、CUPSラスタドライバーの 開発の資金調達を行っている、1つ以上のベンダが現在存在する)。これは、 Ghostscriptを使うCUPSラスタ生成の図解 に図示している。

Figure 22.7. Ghostscriptを使うCUPSラスタ生成の図解

Ghostscriptを使うCUPSラスタ生成の図解

バージョン1.1.15より前のCUPSバージョンでは、バイナリ(あるいはソースコードで)、 pstorasterという名前の独立フィルタを提供していた。 pstorasterはGNU Ghostscript 5.50由来で、代替インストール 可能で、競合なしにGNUあるいはAFPL Ghostscriptパッケージに追加される。

バージョン1.1.15以降、この機能は変更された。このフィルタの機能は、Ghostscriptに 統合された(現在はGNU Ghostscript バージョン 7.05をベースとしている)。 pstorasterフィルタは現在-sDEVICE=cups パラメーターを付けたgsを呼び出す単純なシェルスクリプトである。 もしも、gs -h |grep cupsを実行したときにGhostscriptがエラーに なるならば、印刷は出来ないので、Ghostscriptをアップデートする必要がある。

imagetops と imagetoraster

prefiltersについての節において、イメージ形式からPostScriptを生成するprefilter について言及した。imagetorasterフィルタは中間PostScript ステージなしにイメージからラスタに直接変換するために使われる。これは以前に 言及したprefilterよりもより頻繁に使われる。イメージファイルのフィルタリングに ついての要約フローチャートは イメージ形式をCUPSラスタ形式に変換する流れである。

Figure 22.8. イメージ形式をCUPSラスタ形式に変換する流れ

イメージ形式をCUPSラスタ形式に変換する流れ

rasterto [プリンター固有]

CUPSはCUPSラスタを処理するための非常に数多くのラスタドライバーを提供している。 筆者の環境では、/usr/lib/cups/filter/配下に rastertoalps,rastertobj, rastertoepson,rastertoescp, rastertopcl,rastertoturboprint, rastertoapdk,rastertodymo, rastertoescp, rastertohprastertoprinterがあった。これよりドライバーの数が少なくても 心配することはない。上記のいくつかはCUPSに対する商用アドオンであり (rastertoturboprintのような)、その他 (rastertoprinterのような)は、可能な限りCUPSと協調する ことを望んでいるサードパーティドライバー開発プロジェクトに由来する (たとえばGutenprint)。 ラスタからプリンター固有形式への変換図 を参照。

Figure 22.9. ラスタからプリンター固有形式への変換図

ラスタからプリンター固有形式への変換図

CUPSバックエンド

CUPSフィルタリングチェーンについての最後の部分はバックエンドである。 バックエンドは、最終的なデバイスに印刷可能なファイルを送るための、特別な プログラムである。ネットワーク経由でと、すべてのローカルなインタフェースに 印刷ジョブを送るための、任意の異なった分離されたバックエンドプログラムが ある。すべてのCUPS印刷キューは、それに関連づけられているCUPS device-URIを持つ必要がある。device URIは、その送付先にジョブを 送るときに使われる、バックエンドをエンコードする方法である。以下で一覧表示 されているもので分かるように、ネットワークdevice URLは記述の中に2つの スラッシュ(斜線)を使い、ローカルdevice URLは1つのみを使う。ローカル インタフェース名は、OSがLinux以外の場合、筆者の例では非常に自由度があっても よいことを心にとめておくこと:

usb

このバックエンドはUSB接続のプリンターに印刷ファイルを送る。使用する CUPS device URIの例は以下の通り。 usb:/dev/usb/lp0

serial

このバックエンドはシリアル接続したプリンターに印刷ファイルを送る。使用する CUPS device URIの例は以下の通り。 serial:/dev/ttyS0?baud=11500

parallel

このバックエンドはパラレルポートに接続したプリンターに印刷ファイルを送る。使用する CUPS device URIの例は以下の通り。 parallel:/dev/lp0

SCSI

このバックエンドはSCSIインタフェースに接続されたプリンターに印刷ファイルを送る。使用する CUPS device URIの例は以下の通り。 scsi:/dev/sr1

lpd

このバックエンドはLPR/LPDで接続されたネットワークプリンターに印刷ファイルを送る。使用する CUPS device URIの例は以下の通り。 lpd://remote_host_name/remote_queue_name

AppSocket/HP JetDirect

このバックエンドはAppSocket(別名JetDirect)で接続されたネットワークプリンターに 印刷ファイルを送る。使用するCUPS device URIの例は以下の通り。 socket://10.11.12.13:9100

ipp

このバックエンドはIPPで接続されたネットワークプリンター(か他のCUPSサーバー)に 印刷ファイルを送る。使用するCUPS device URIの例は以下の通り。 ipp:://192.193.194.195/ipp (多くのHPプリンター用)と ipp://remote_cups_server/printers/remote_printer_name

http

このバックエンドはHTTPで接続されたプリンターにファイルを送る (http:// CUPSバックエンドはipp://バックエンドの単なるシンボリックリンクである)。 CUPS device URIの例は以下の通り。 http:://192.193.194.195:631/ipp (多くのHPプリンター用)と http://remote_cups_server:631/printers/remote_printer_name

smb

このバックエンドはWindowsホストによって共有されているプリンターに印刷ファイルを送る。 CUPS device URIの例は以下の通り。

smb://workgroup/server/printersharename
smb://server/printersharename
smb://username:password@workgroup/server/printersharename
smb://username:password@server/printersharename

The smb:// backendはSambaユーティリティsmbspool (CUPSによって提供されていない)へのシンボリックリンクである。もしも CUPSバックエンドディレクトリ中にシンボリックリンクがない場合、root ユーザーになって、 ln -s `which smbspool' /usr/lib/cups/backend/smb を実行してこれを作ること。

CUPS印刷システムに対して任意の変更又は拡張の必要性がある場合、シェル又はPerl スクリプトで固有のバックエンドを書くことは簡単である。印刷ジョブをメールとして (mailto:/バックエンド経由で)送る、PDFに変換する (pdfgen:/バックエンド経由で)、あるいは/dev/nullに ダンプするというような特別なプリンターを作成したいというような 希望が理由としてあげられる(実際、システム全体での既定値のプリンターとして、 devnull:/バックエンドに接続するプリンターを用意している)。とても多くの人が、 プリンターを指定しないでジョブを送信したり、スクリプトとプログラムがプリンターを 指定しない。システム全体での既定値はジョブを削除し、$USERに、 正しいプリンター名を常時指定するようにという丁寧なメールを送る)。

説明したバックエンドすべて以外が使用しているシステム上にあるか、利用可能に (ハードウェア設定に依存する)なっていてもよい。すべての有効なCUPSバックエンドを 調べる1つの方法はlpinfoとして提供されている。これを -vを付けて付こうと、すべての有効なバックエンドを下記のように 表示する:

	$ lpinfo -v
	

cupsomatic/foomaticの役割

cupsomaticフィルタはCUPSをインストールするときに最も広く 使われているだろう。これらはCUPS開発者によって開発されたものではないということを 明確にする必要がある。これらはCUPSに対するサードパーティアドオンである。これらは CUPSのためにジョブをレンダリングする従来のGhostscriptデバイスを使う。 問題が発生したときの調査時にはその違いを知っておく必要がある。ここでは1ステージで すべてのレンダリングプロセスがGhostscript内部で、対象のプリンターに適したデバイスを 使って行われる。cupsomaticは、Linuxprinting.orgにある Foomaticプリンタードライバーデータベースから生成されたPPDを使う。

You can recognize these PPDs from the line calling the cupsomatic filter:

*cupsFilter: "application/vnd.cups-postscript  0  cupsomatic"

PPDファイルの最初の40かそのあたりで、この行を見つけるかもしれない。 もしも、そのような、インストールされたPPDがあるならば、プリンターは foomaticの名前部分にfoomaticが 表示されたCUPS Webインタフェース中で表示される。 cupsomaticは、選択されたPPDとプリントジョブに与えられた コマンドラインオプションから自動的に構成された、すべての複雑なコマンドライン オプションを付けたGhostscriptを実行させるPerlスクリプトである。

しかし、cupsomaticは現在廃止されている。そのPPD(特に 最初に生成したものは、そこで引き続き頻繁に使用される)は、Adobeの仕様に適合して いない。Windowsクライアントにポイントアンドプリントでそれらを ダウンロード仕様とするときに困難に遭遇するかもしれない。よりよい、かつ 強力な解決方法は現在提供されている。それは、foomatic-rip と呼ばれる。CUPSでフィルタとしてfoomatic-ripを使うために、 似たようだが異なった行を持つ、新しいタイプのPPDが必要である:

*cupsFilter: "application/vnd.cups-postscript  0  foomatic-rip"

Linuxprinting.orgにあるPPD生成エンジンは修正された。新しいPPDはAdobeの仕様に 従っている。これらは異なった品質レベル(高解像度の写真、通常の色、グレースケールと ドラフトモード)をシングルクリックで、5つまたはそれ以上の異なった選択(メディア タイプ、解像度、インク種別とディザリングアルゴリズム)を要求できる新しい方法を 提供する。ビルトインされた固有のサイズのメディアサポートもある。ジョブの中間で、 ページ毎に印刷オプションを切り替えることのサポートもある。さらに、最もすばらしい ことは、新しいfoomatic-ripは、印刷時にPPDを使うための アクセスに対するサポートを、すべての旧式なスプーラ(LPRng,BSD-LPD, PDQ, PPRなど) に対してもシームレスに動作するということである。

完全な図解

すべてのフィルタの概要とどのようにそれらが関連するかを知りたい場合、 パズルの完全な図解はこの章の最後にある。

mime.convs

CUPSは与えられたMIMEタイプとインストールされたすべてのプリンターに対する可能な すべてのフィルタリングチェーンパスを自動構築する。しかし、どのようにして 優先するものや特定の選択肢を決めるのであろうか(2つ以上の、同じターゲット プリンターに対するフィルタリングチェーンが存在するような場合があるだろう)? 簡単である。mime-convファイルの3番目のカラム中にある数字に気がついたかも しれない。それはこのフィルタに割り当てられている仮想コストを表現している。 すべての可能なフィルタリングチェーンは全体のフィルタコスト として集計される。CUPSは最もコストの小さいルートを選ぶ。

Tip

cupsd.conf中でFilterLimit 1000を 設定すると、仮想フィルタコストが合計1000を消費するより多く、フィルタが同時に動く ことを許可しない。これは適切なFilterLimit値を設定することにより CUPSサーバーの負荷を制限する効率的な方法である。200というFilterLimitの値はおおよそ 一度に1つのジョブを許可し、FilterLimitを1000にするとおおよそ最大5つのジョブが 同時に動作する。

Raw印刷

CUPSに対して任意のrawファイルを印刷(ほとんど)させることが出来る。 rawはフィルタされないことを意味する。CUPSは、プリンターがそれを理解 できる時に、思い悩まずにそのままプリンターに対してファイルを送る。 ユーザーは賢明なデータ形式のみをそれらに送る事について注意を払う必要がある。raw 形式の印刷は、もしも-o rawオプションが コマンド行上で指定されたときにどのキューにおいても発生する。任意のPPDを単に関連 づけない事によってrawのみのキューを設定することも出来る。以下のように行う:

$ lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E

これは、rawprinterというsocketプロトコル (別名HP JetDirect)経由で接続してポート9100のIPアドレス 11.12.1.3.14のデバイスに接続するように設定する(もしもこのコマンド行に -P /path/to/PPDを付けたPPDを追加したならば、 通常の印刷キューとしてインストールされる。

CUPSは、もしもキューに関連づけられるPPDを見いだせない場合、自動的に各ジョブを rawと見なしてキューに送るように扱う。しかし、CUPSは既知の MIMEタイプ(CUPSが持つmime.typesファイルで定義されている)のみを送り、それ以外は 拒否する。

application/octet-stream 印刷

/etc/cups/mime.typesファイル中にルールがない任意のMIME タイプは、unknownかapplication/octet-streamと 見なされ、送信されない。既定値で不明なMIMEタイプの印刷をCUPSが拒否するので、 Windowsクライアント由来の印刷ジョブが印刷されないということを経験するかも しれない。以下のようなエラーメッセージがCUPSログファイル中に見つかるかもしれない:

Unable to convert file 0 to printable format for job

application/octet-streamの印刷を有効にするためには、以下の 2つのファイルを編集する:

  • /etc/cups/mime.convs

  • /etc/cups/mime.types

両方ともapplication/octet-streamのためのrawモード操作を 有効にするためにコメントアウトしなければならないエントリ(それぞれのファイルの 最後の所)を含む。下記の行が/etc/cups/mime.typesに存在する ようにすること:

application/octet-stream

自動タイプルールセットが指定されていないこの行は、他の行で application/octet-streamのメンバーが自動タイプされていない 限り、全てのファイルを作成する。/etc/cups/mime.convs中では 以下のような行になる:

application/octet-stream   application/vnd.cups-raw   0   -

この行はCUPSに、application/octet-stream上で (-で示される、何もしない)Null Filter を使うことを指示し、application/vnd.cups-rawとして 結果をタグづける。この最後の部分は、プリンターに接続しファイルを送信するための バックエンドに向けてCUPSスケジューラがいつでも今あるファイルを引き渡せるように している。

Note

mime.convsmime.typesファイルの編集は raw印刷を強制せず、それを 許可するのみである。

Background.  そのCUPSは従来のものよりセキュリティに気を払っている印刷システムで、既定値では、 印刷デバイスに対して手の込んだ(おそらくバイナリ)データを送ることを誰にも許可して いない(これは、使用しているプリンターに対してサービス不能攻撃をかける不正使用が 簡単にでき、少なくとも大量の紙とインクが無駄になることが発生する)。 不明なデータはCUPSによって、MIMEタイプ application/octet-streamと見なされる。 raw形式でデータを送ることができる場合、 それらのMIMEタイプは、CUPSとそれによって許可された、既知のもののどれかでなければ ならない。/etc/cups/mime.typesというファイルはCUPSが どのようにMIMEタイプを認識するかの規則を定義する。 /etc/cups/mime.convsというファイルはどのファイル変換 フィルタがそのMIMEタイプに適用されるかを定義する。

非PostScriptプリンターのためのPostScriptプリンター記述

オリジナルのPPDはPostScriptプリンターのみに使われることを意図していた。それらは ジョブファイルを処理する、RIPのためのデバイス固有のコマンドと設定を送るための 手助けとなる。CUPSはPPDに対するこのスコープを拡張し、非PostScriptプリンターにも カバーするようにした。これが標準化されたファイル形式のために、これを行うのは 難しくない。その方法は論理的でもある:CUPSはPostScriptを取り扱い、ジョブファイルを 処理するためにPostScript RIP(Ghostscript)を使う。唯一の違いはPostScriptプリンターは RIPを内蔵していて、その他のタイプのプリンターはホストコンピュータ上でGhostscript のRIPを動かすと言うことである。

非PostScriptプリンターに対するPPDはCUPS固有のいくつかの行を持っている。最も 重要なものは下記と似たようなものである:

*cupsFilter: application/vnd.cups-raster  66   rastertoprinter

これが CUPS フィルタリングの最後の難所のひとつである。この行では、CUPSデーモンに 対して、rastertoprinterを最後のフィルタとして使うように 設定している。このフィルタは application/vnd.cups-raster というMIMEタイプのファイルが入力の際に用いられることになる。CUPSは指定されたMIME タイプを最終的な出力とするようなフィルタのチェインを自動的に生成する。 次にこれは指定されたrastertoprinterフィルタのための入力と なる。最後のフィルタが処理を終えた後(rastertoprinterは Gutenprintフィルタである)、ファイルは、出力デバイスに送信を行うバックエンドに 送られる。

CUPSが提供しているPPDは数少ないが、プリンターモデルは数多くある。異なった紙の トレイや指定されたモデルがサポートしているよりもより大きなマージンを取ることが 出来ないかもしれない。要約は表21.1“CUPSに同梱されているPPD”を参照。

Table 22.1. CUPSに同梱されているPPD

PPDファイルプリンタータイプ
deskjet.ppd古いHP inkjetプリンターとその互換
deskjet2.ppd新しいHP inkjetプリンターとその互換
dymo.ppdlabelプリンター
epson9.ppdエプソン9-ピンインパクトプリンターとその互換
epson24.ppdエプソン 24-ピンインパクトプリンターとその互換
okidata9.ppdOkidata 9-ピンインパクトプリンターとその互換
okidat24.ppdOkidata 24-ピンインパクトプリンターとその互換
stcolor.ppd古いエプソン Stylusカラープリンター
stcolor2.ppd新しいエプソン Stylusカラープリンター
stphoto.ppd古いエプソン Stylus Photoプリンター
stphoto2.ppd新しいエプソン Stylus Photoプリンター
laserjet.ppdすべての PCL プリンター

cupsomatic/foomatic-ripネイティブなCUPS印刷

ネイティブなCUPSラスタライズ作業は2つのステップに分かれている:

  • 最初のものは、pstorasterステップである。これは、 ESP Ghostscript 7.05.xからの特別なCUPSデバイスを、そのツールとして使う。

  • 二番目のものはrasterdriverステップである。これは、 種々のデバイス固有のフィルタを使う。このステップに対して良い品質をもつ フィルタを提供するいくつかのベンダがある。それらのいくつかはフリー ソフトウェアであり、いくつかはシェアウェアであり、いくつかは商用製品である。

しばしばこれは、その他の方法よりもより良い品質のものを生成する(そして、 いくつかのより優位な点がある)。これについては cupsomatic/foomaticの処理対ネイティブなCUPSの図 に図解がある。

Figure 22.10. cupsomatic/foomaticの処理対ネイティブなCUPSの図

cupsomatic/foomaticの処理対ネイティブなCUPSの図

1つの他の方法は、cupsomatic/foomatic-ripによるものである。 cupsomaticは、決してCUPS開発者によって 作られたものではないということに注意。これは、印刷環境に 対する独立した貢献であり、Linuxprinting.orgの人々によって作られたものである。 [6] cupsomaticはもはや開発、メンテナンス、サポートされいない。 これは現在 foomatic-ripによって置き換えられている。 foomatic-ripは古いcupsomaticの アイデアを完全に書き換えたものであるが、とても改善され、他の(非CUPS)スプーラに 対して汎用化されている。 foomatic-ripへのアップグレードは、 特にもしも最新バージョンのCUPSにアップグレードするならば強く推奨される。

古いcupsomaticのように、(新しい)Linuxprinting.orgが使う 現代的なGhostscript印刷処理からのfoomatic-ripは、すべてを 単一のステップで行う。従ってそれはGhostscript中に組み込まれる他のすべての デバイスに依存する。他のスプーラでのGhostscriptのレンダリングと同じくらい 品質は良い(あるいは悪い)。優位点は、この方法は、より最新のCUPSによる方法によって (まだ)サポートされていない、たくさんのプリンターモデルをサポートするということで ある。

もちろん、あるシステムで並列に両方の手法を使うことが出来(もしも異なったキューを 設定するならば1つのプリンターに対しても)、どれが一番うまく動作するかを見いだせる。

cupsomaticは印刷ファイルを application/vnd.cups-postscriptステージ後に捕まえ、 システム全体でインストールされたGhostscriptである、CUPS-externalを通してそれを 横取りする。その結果、印刷ファイルはpstorasterフィルタ をバイパスする(さらにCUPSラスタドライバーrastertosomethingも バイパスする)。Gostscriptがラスタライズ処理を終えた後、 cupsomaticはレンダリングされたファイルディレクトリをCUPS バックエンドに渡す。 cupsomatic/foomaticの処理対ネイティブなCUPS にはネイティブなCUPSレンダリングとFoomatic/cupsomatic手法の 違いについて図解している。

フィルタリングチェインの例

以下は、CUPSの動作を図解するための、よくあるフィルタリングチェインの例である。

HP JetDirect接続のPostScriptプリンターにPDFファイルを印刷しようとしていることを 仮定するが、ページ3-5,7と11-13のみを印刷したく、更にそれを2アップ両面印刷にしたいとする:

  • 使用する印刷オプション(要求されたページの選択、2アップ、両面印刷) は、コマンドライン上でCUPSに渡される。

  • (完全な)PDFファイルがCUPSに送られ、 application/pdfとして自動タイプされる。

  • その結果ファイルはPostScript MIMEタイプである application/postscript(ここでのプレビューは引き続き オリジナルのPDFファイルのすべてのページを表示する)を生成する pdftopsprefilterに、最初に渡さねばならない。

  • ファイルは次にコマンドラインオプションを適用する pstopsフィルタに渡される:これはページ2-5,7と11-13を 選択し、1枚のページ上に2つのページという合成されたレイアウトを 作成し、正しい両面印刷コマンド(プリンターのPPD中で定義されている) を、新しいPostScriptファイルに挿入する。ファイルはこの時点でPostScript MIME タイプapplication/vnd.cups-postscriptとなる。

  • ファイルは、プリンターにジョブを転送する ソケットバックエンドに送られる。

フィルタリングチェーンの結果は以下の PDFからソケットへのチェーンの模式図のようになる。

Figure 22.11. PDFからソケットへのチェーン

PDFからソケットへのチェーン

CUPSstphoto2.ppdをインストールした、USB接続の Epson Stylus Photo Printerに同じフィルタで印刷したいと仮定しよう。最初の いくつかのフィルタリングステージはおおよそ同じである:

  • 印刷オプション(要求されたページの選択、2アップ、両面印刷)は、 コマンドラインでCUPSに渡される。

  • (完全な)PDFファイルはCUPSに送られて、 application/pdfと自動タイプされる。

  • ファイルは、最初に、 PostScript MIMEタイプapplication/postscriptを 生成するpdftopsprefilterに渡されなければならない (ここでのプレビューは引き続きオリジナルのPDFのすべてのページを表示する)。

  • ファイルは次にコマンドラインオプションを適用するpstops フィルタに送られる。ここでページ2-5,7と11-13を選択し、 一枚の紙の上に2ページを合成し、正しい両面印刷 コマンド(おっと、このプリンターとPPDは両面印刷をサポートしていないので、 このオプションは無視される)を新しいPostScriptファイルに挿入する。 ファイルはこの時点でPostScript MIMEタイプ application/vnd.cups-postscriptとなる。

  • ファイルは次にpstorasterステージに送られ、MIME タイプがapplication/cups-rasterとなる。

  • 最後に、rastertoepsonフィルタは、その処理を行い (プリンターのPPD中で示されるように)、プリンター固有のラスタデータを生成し、 ユーザーが選択した任意の印刷オプションを、印刷データストリーム中に 埋め込む。

  • ファイルは、ジョブをプリンターに転送するusb バックエンドに送られる。

フィルタリングチェーンの結果は PDFからUSBチェーンへの模式図のようになる。

Figure 22.12. PDFからUSBチェーン

PDFからUSBチェーン

CUPSドライバー/PPDの提供元

インターネット上でたくさんのCUPS-PPDファイルを(それに適したフィルタと一緒に)、 たくさんの言語環境で、1000以上の非PostScriptモデル用をサポートしているものを 見つけることが出来る。

  • ESP PrintPro (商用、自由ではない)は、3000以上のPPDをパッケージしていて、 Linux, Mac OS X, IBM-AIX,HP-UX, Sun-Solaris, SGI-IRIX, Compaq Tru64, Digital UNIXと他の商用UNIX上での外部ドライバーとして使える (これは、CUPS開発者それ自身で書かれていて、その売り上げは 開発者を食べさせるという形で、将来のCUPS開発費用を助ける)。

  • Gutenprint Project (GPL、フリーソフトウェア)は140ほどのPPDを提供し(おおよそ400のプリンターを サポートしていて、多くは写真品質出力を提供する)、Gutenprint CUPS ドライバーと共に使われる。

  • TurboPrint (シェアウェア、自由ではない)は、とても良い品質で、おおよそ、プリンターの数と 同じくらいのサポートがある。

  • OMNI (LGPL、自由)は、IBMによって作られたパッケージで、現在400以上のプリンター サポートを含み、IBM OS/2のノウハウの遺産をLinux上に移植している (CUPSサポートは現在β状態である)。

  • HPIJS (BSD系のライセンス、自由) は、おおよそ150のHP製プリンターをサポートし、優れた印刷品質をも提供する (現在Foomaticパス経由でのみ有効)。

  • Foomatic/cupsomatic (LGPL、自由)は、Linuxprinting.orgからのもので、(Omni、GunenprintとHPIJS を含む)世界中に知られているほとんどすべての各Ghostscriptフィルタ用の PPDを提供する。

インタフェーススクリプトを伴う印刷

CUPSはまたSystemV AT&T印刷システムからとして知られている interface scriptsの使用もサポートしている。それらはしばしば PCL印刷ジョブを生成するアプリケーションから、PCLプリンターにおいて使われる。 interface scriptsはプリンターモデルに特化している。これらはPostScriptプリンターの ためのPPDと同様の役割を持っている。interface scriptsは、たとえば、もしも ユーザーが特定のペーパートレイを選択したか、紙の方向を変更したかA3用紙を しようするような場合、印刷データストリーム中に要求されたESCシーケンスを 追加してもよい。interface scriptsはLinux領域ではほとんど知られていない。 HP-UXプラットフォームでは、もう少し使われている。動作する任意の interface scriptsをCUPS上で一緒に使うことも可能である。以下のように、 -iを使ってインストールする:

root# lpadmin -p pclprinter -v socket://11.12.13.14:9100 \
          -i /path/to/interface-script

interface scriptsは多くの人にとって未知の動物かもしれない。 しかし、これは、CUPSと共に使うことで、ある特定の印刷キューに対する、固有の、 専用として記述した、フィルタリングスクリプトやプログラムを組み込む最も簡単な 方法を提供する(現代的なinterface scriptsの使い方に関するいくつかの情報は、 http://playground.sun.com/printing/documentation/interface.htmlにある)。

ネットワーク印刷(Windowsのみ)

ネットワーク印刷は多くの分野をカバーしている。Windowsクライアントのために印刷するとき Samba上で何が起こるかを正確に理解するために、まず初めに、Windows NTサーバーと共に使う Windowsクライアントという、Windowsのみの設定を見てみよう。

WindowsクライアントからNT印刷サーバーへ

WindowsクライアントからNTベースの印刷サーバーへの印刷は、2つのオプションがある。 それらは以下の2つである:

  • ドライバーをローカルに実行し、GDI出力(EMF)を、使用している プリンターに対するプリンター固有の形式に描画する。

  • プリンター固有の出力に描画するためにドライバーが実行されたときに、 GDI出力(EMF)をサーバーに送る。

両方の印刷パスは クライアント上での印刷ドライバーの実行サーバー上での印刷ドライバーの実行という フローチャートで図示されている。

クライアント上でのドライバーの実行

最初の場合、印刷サーバーはraw形式でファイルをスプールせねばならない。これはジョブファイルに さわらず、何らの方法での変換もしないことを意味する。これは、現代的なUNIXベースの印刷 サーバーが同じように行えることでもあり、NT印刷サーバーよりもよりよいパフォーマンスとより 信頼性がある。これは、おそらくほとんどのSamba管理者が慣れ親しんでいるものである。この 設定の1つの利点は、このスプールのみの印刷サーバーが、UNIX用のドライバーがない 場合にも使えるかもしれないと言うことである。これは、有効なWindowsクライアントドライバーが あり、クライアントにインストールされていれば十分である。これは クライアント上での印刷ドライバーの実行ダイアグラム で図示されている。

Figure 22.13. クライアント上での印刷ドライバーの実行

クライアント上での印刷ドライバーの実行

サーバー上でのドライバーの実行

他のパスはサーバー上でプリンタードライバーを実行する。クライアントはサーバーにEMF形式で印刷 ファイルを送る。サーバーはPostScript, PCL, ESC/Pか他のドライバーを、EMFファイルをプリンター 固有の言語に変換するために使う。同じ事はUNIX上ではできない。現在、プリンターが理解できる ものに、UNIXサーバー上でWindowsクライアントのGDI出力を変換するプログラムか手法はない。 これはサーバー上での印刷ドライバーの実行ダイアグラムで 図示されている。

Figure 22.14. Print Driver Execution on the Server.

Print Driver Execution on the Server.

しかし、似たようなものはCUPSで可能なので、引き続き読むこと。

ネットワーク印刷(WindowsクライアントとUNIX/Samba印刷サーバー)

UNIX印刷サーバーがそのプラットフォーム上でWin32プログラムコードを 実行できないので、絵は若干異なる。しかしながら、 これは、それほど選択権を制限するものではない。それどころか、他では不可能な 印刷機能を実装することができるかもしれない。

WindowsクライアントからCUPS/Samba印刷サーバーへ

Windowsネットワーク印刷クライアントに対する、CUPSの強力な機能の利点をどのように 利用するかを示す簡単なレシピである:

  • WindowsクライアントにPostScriptをCUPSサーバーに送らせる。

  • CUPSサーバーにPostScriptをドライバー固有のラスタフォーマットに変換させる。

これは、クライアントにPostScriptドライバー(プリンターが非PostScriptモデルであっても。CUPS サーバー上でのドライバーがあることも要求する)を使うことを要求する。

最初に、Samba経由でのCUPSベースの印刷を有効にするため、以下のオプションをsmb.conf ファイルの[global]セクションに設定すべきである:

printing = cups
printcap = cups

これらのパラメーターが指定されると、smb.conf中の(Sambaそれ自身と同様)、すべての手動設定 した印刷ディレクティブ(たとえばprint commandlppause command)は無視される。その代わりSambaは、SambaがCUPS ライブラリ(libcups)をサポートするようにコンパイルされているとき、CUPS APIを通してCUPSと 直接やりとりする。他の印刷コマンドが設定されていない場合、印刷は、-orawオプションを 自動的に付けてパススルーする、System VAT&Tコマンドセットを 使う(もし、コンパイル時にCUPSサポートをするようしたSambaサーバーで動作するよう、個別に 定義した印刷コマンドを使いたい場合、単に classicalprinting = sysvを使う)。これは CUPS/Sambaサーバー経由での印刷ダイアグラムで図示されている。

Figure 22.15. CUPS/Sambaサーバー経由での印刷

CUPS/Sambaサーバー経由での印刷

Sambaによるジョブファイルの受け取りとCUPSへの引き渡し

Sambaはそれ固有のスプールディレクトリ (path = /var/spool/sambaに類似したもので設定される) を、smb.conf[printers][printername] セクション中で使わなければならない。 Sambaは固有スプール空間にジョブを受け取り、CUPSのスプールディレクトリ(CUPSのスプール ディレクトリは、既定値がRequestRoot /var/spool/cupsである、 RequestRootディレクティブ行で設定される)中に渡す。 CUPSはそのスプールディレクトリのアクセス権限を検査し、毎回の再起動に備えて適切な値に それをリセットする。 SambaとCUPSで共通のスプール空間を使う例は滅多に見たことがなく、何週間もこの 問題と苦闘してきた。

WindowsユーザーはSambaでのみ認証する(構成されるどんな手段でも)。もしもSambaがCUPSと同じ ホストで動作しているならば、印刷においてはlocalhostのみ許可しなければ ならない。もしも異なったマシンで動作しているならば、CUPSで印刷できるように、Samba ホストがアクセス権を得られるようにしておかねばならない。

ネットワーク PostScript RIP

この節では、クライアントがCUPS-PPDと一緒にPostScriptドライバーを使うようにさせる、サーバーの 設定上でのCUPSフィルタの使い方について議論する。

PPDはすべての印刷デバイスオプションを制御できる。もしも、固有のPostScriptプリンターを 持っているならば、すなわちこれらは通常開発元によって提供される。PPDファイルは 、つねに、Microsoft WindowsまたはApple Mac OSシステム上でのPostScriptプリンタードライバーの コンポーネントである。それらはユーザーが選択できる印刷オプション、適切なPostScriptへの マッピング、対象プリンター用のPCLあるいはPJLコマンドを含むASCIIファイルである。プリンター ドライバーGUIダイアログはこれらのオプションをその場でユーザーが選択できる、 ボタンとドロップダウンリストに変換する。

CUPSは、何らの変換なしに、任意のWindows(NTが推奨される)PostScriptドライバーからのPPD ファイルロードでき、それらのオプションを扱える。印刷オプションのためのWebブラウザー インタフェース (http://localhost:631/printers/ を選択し、そこにあるConfigure Printerボタンをクリック)か、 コマンドラインインタフェース(man lpoptionsか、システム上にあるならば、 lphelpを参照)がある。これらはユーザーへのPPDオプションを提供出来る Linux/UNIX上のGUIフロントエンドとは若干異なる。PPDオプションは通常、実際ののPostScript プリンター上のPostScript RIPによって評価される事を意味する。

UNIX上の、非PSプリンターのためのPPD

CUPSはそのPPDの使用にあたっては実際のPostScriptプリンターだけにに制限 されない。CUPS開発者は非PostScriptプリンターに対してもCUPS-PPDを使って有効なデバイスと ドライバーオプションを記述するPPDコンセプトの範囲を拡張した。

CUPSは完全なPostScriptインタプリタ(RIP)を含んでいるため、これは合理的である。RIPは GhostScriptをベースにしている。これはクライアントからすべてのPostScript(と更に追加で、 その他のファイル形式)を受け取り処理できる。すべてのCUPS-PPDは、キーワード *cupsFilterで始まる追加の行を含んでいると非PostScriptプリンターに ギアを切り替える。この行はCUPS印刷システムに、受け取ったPostScriptを解釈するための プリンター固有のフィルタを使うように告げる。そのため、そのプリンターに対してPostScript RIP として振る舞うことが出来るため、そのクライアントに対してPostScriptデバイスとしてその すべてのプリンターを見せるようにし、受け取ったPostScriptコードを適切なラスタ印刷形式に 処理する。

Windows上の非PostScriptプリンターのためのPPD

Windowsクライアントでは中核のPostScript ドライバー に加えて CUPS-PPD も利用可能である。(ただし現在は CUPS PostScript Driver for Windows NT/200x/XP が推奨されている。これを使うと、制 限付きながら Adobe のドライバーが利用できる)。CUPS-PPD を使う場合、 他のスプーラではできない機能のいくつかを CUPS が利用できるよう になる。

  • 統一した方法で、すべてのクライアントプラットフォームから、ネットワーク対応の 印刷ファイルを扱うPostScript RIPとして振る舞う。

  • すべてのファイルがpstopフィルタを通し、その結果page_logに 記録されるため、CUPSの集中アカウント件請求サーバーとして振る舞う。 注意:これは、常時定義毎にフィルタなしが存在するため、 raw印刷ジョブでは該当しない。

  • たくさんの異なった対象プリンターがあっても、クライアントが、単一のPostScript ドライバーに集約することが出来るようになる。

Windowsクライアント上のCUPS PPDを使うと、すべての印刷ジョブ設定をUNIXクライアントが 出来るように制御する事が出来るようになる。

CUPSクライアントとしてのWindowsターミナルサーバー (WTS)

この設定は、WTS環境で大きな問題を体験している人にとって、特別な興味を引くかもしれない。 WTSはしばしば、そのクライアントの数多くのプリンターモデルを動かすために、多数の非PostScript プリンタードライバーをインストールする必要がある。これはしばしば非常に不安定性を増大させる。

カーネルモードでのプリンタードライバーの実行は多くの問題を引き起こす

カーネルモードで動作するWindows NTプリンタードライバーは、ドライバーが安定せず、 よくテストされていない場合には、システムの安定性にとって高いリスクとなる。そして、できの 悪いドライバーはたくさんあるのである!特に、悪名高いものは、ジョブの終了時にサウンドカード 経由でユーザーに通知を行う追加のサウンドモジュールが動くものを持っているPCLドライバーが例で ある。通常使っていて、ブルースクリーンをこれが出してしまうと言うことを言う 必要があるだろうか?

PostScriptドライバーは一般的によくテストされている。カーネルモードで動作したとしても、 それらが何かの問題を引き起こすことは知られていない。これは2つの異なったPostScript ドライバーが現在存在しているという事によるのかもしれない。1つはAdobeのものであり、もう1つは Microsoftのものである。両方ともよくテストされ、Windows上で想像できるように安定している。 CUPSドライバーはマイクロソフトのもの由来である。

Workarounds Impose Heavy Limitations

回避方法として、サイト管理者は、WTS上にインストールされる許可されたドライバーを、1つの 汎用PCLと1つのPostScriptドライバーだけに制限するという方針を選んだ。しかしこれは、 クライアントが使う事が出来るたくさんの印刷オプションを制限することになる。 異なったドライバーによって制御される場合、そのデバイスはより良い動作が出来るはずが、 しばしば、1つの標準ペーパトレイでの単純な印刷よりも複雑なことが出来なくなる!

CUPS: A Magical Stone?

PostScriptドライバーを使い、CUPS-PPDを有効にすることは、すべてのこれらの欠点を解決する とてもエレガントな方法に見える。これらは使用するWindows OSバージョンに依存する、最大3つの 異なったドライバー、すなわちAdobe、MicrosoftとCUPS PostScriptドライバーが現在有効である。 WTS上で大きな安定性の問題を引き起こすことは、上記3つのどれも知られていない(たとえ、 たくさんの異なったPPDを使ったとしても)。クライアントは(再度)ペーパトレイ、両面印刷や その他の設定を選択できる。しかし、確かな代価もある:そのクライアントに対して、CUPSサーバーは PostScript RIPとして振る舞い、raw スプールデバイスとして振る舞うよりも よりCPUとメモリを必要とする。更に、この設定は、最初のフィードバックがとても有望ではあるが、 広範囲にはテストされていない。

カーネルモードでもPostScriptドライバーは大きな問題はない

より新しいW200xとに同梱されているXPプリンタードライバーでは、Windows NTとは異なり、カーネル モードでは動作しない。ただし、両OS共に、引き続き、カーネルモードで動作するドライバーを 使う事は可能である(端的に言って、サブディレクトリW32X86中の 2にあるドライバーが、古いものかだと思って良いだろう)。 以前に説明したように、AdobeのものはMicrosoft PostScriptドライバーのように安定している。 CUPSドライバーはMicrosoftベースである。これは次のような理由による。Visual Studioの ライセンスを持つ人が無償で使える、Windows NT用のMicrosoftのDDK(Device Development Kit)は、 Microsoftがライセンスを持つドライバーのソースコードが含まれる。Visual Studioのライセンスを 持つ人は、自分が作るドライバーの開発作業に、そのコードを使用し、変更する事が許可されている。 CUPSではこのように開発されている。しかし、Microsoftのライセンスは、(DDKの部分を含む) ソースコード全体を公開することは許可していない。しかし、CUPSは、GPL配下で差分を リリースしている。そのため、もしもMS DDK for Windows NTのライセンスを 持っていれば、差分コードを使い、ドライバーを自分自身で調べる事が出来る。

ドライバーダウンロードを行うためのCUPSの設定

前に説明したように、ダウンロードのためにSambaサーバー上でクライアントプリンタードライバーを 準備するためと、Windowsワークステーションの利便性のためのポイントアンドプリントのための、 すべての以前に知られている方法も、CUPS上で動作する。これらの方法は 旧式の印刷サポートで説明されている。実際は、 これは真のSambaビジネスで、Samba-Windowsクライアントの連携にのみ関連している。

cupsaddsmb: 不明なユーティリティ

cupsaddsmbユーティリティ(現在すべてのCUPSバージョンに同梱)は、 Sambaの[print$]共有中に、プリンタードライバーを転送する別の解で ある。思い出してほしいのは、この共有は、クライアントが、ドライバーが配布されると期待 し、ダウンロードとインストールのためにセットアップする場所であるということである。 これは、とても簡単に、任意の(か全部の)インストールされたCUPSプリンターの共有が出来るように なる。cupsaddsmbは、Adobe PostScriptドライバーを、最近開発された Windows NT/200x/XP用のCUPS PostScriptドライバーと同様に使うことが出来る。 cupsaddsmbは、ベンダプリンタードライバーと一緒に 動作することはできず、そのマニュアルページ中に名前がある ドライバーと同じもののみ動作する。

CUPSプリンタードライバーはCUPSダウンロードサイトにある。そのパッケージ名は cups-samba-[version].tar.gzである。これには以下のような数多くの 利点があるので、Adobeドライバーよりも好まれる:

  • より正確なページ印刷情報をサポートする。

  • すべてのプリンターで、バナーページとページラベルをサポートする。

  • 数多くのジョブのIPP属性の設定をサポートする (たとえば、ジョブの優先度、ページラベルとジョブの費用請求など)

しかし、現在Windows NT,2000とXPのみがCUPSドライバーによってサポートされている。もしも、 Windows95、98とMEクライアントのサポートが必要ならば、Adobe Driverのそれぞれの部分を 入手する事も必要である。

cupsaddsmb用のsmb.confの準備

cupsaddsmbを走らせる前に、 cupsaddsmb使用のためのsmb.confで示されるように、 smb.confを設定する必要がある。

Example 22.3. cupsaddsmb使用のためのsmb.conf

[global]
load printers = yes
printing = cups
printcap name = cups
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
# setting depends on your requirements
guest ok = yes
writable = no
printable = yes
printer admin = root
[print$]
comment = Printer Drivers
path = /etc/samba/drivers
browseable = yes
guest ok = no
read only = yes
write list = root, @smbprintadm

Windows NT/200x/XP用のCUPSPostScript Driver

CUPSユーザーは http://www.cups.org/software.html から正確に同じパッケージを入手できる。これは、CUPSベースのソフトウェアファイルから 分離されたパッケージで、CUPS 1.1.x Windows NT/200x/XP Printer Driver for Samba (tar.gz,192k) とタグづけられている。ダウンロードするファイル名はcups-samba-1.1.x.tar.gz である。tar.gzファイルを解凍後、以下のファイルが展開される:

root# tar xvzf cups-samba-1.1.19.tar.gz
cups-samba.install
cups-samba.license
cups-samba.readme
cups-samba.remove
cups-samba.ss

これらはESPメタパッケージャソフトウェアEPMでパッケージ化されている。 *.install*.removeファイルは簡単なシェル スクリプトで、*.ssのtarファイルを展開したものである (*.ssは、tarによって回答できる、tarアーカイブ 以外の何者でもない)。次に、これは内容物を/usr/share/cups/drivers/に 置く。この内容物は以下のファイルを含む:

root# tar tv cups-samba.ss
cupsdrvr.dll
cupsui.dll
cups.hlp  

cups-samba.installシェルスクリプトは簡単に扱える:

root# ./cups-samba.install
[....]
Installing software...
Updating file permissions...
Running post-install commands...
Installation is complete.       

スクリプトは/usr/share/cups/drivers/ディレクトリ中に ドライバーファイルを自動的に置く:

root# cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/

Warning

バグのために、ある最近のCUPSリリースでは、cups.hlpドライバーファイルを /usr/share/cups/drivers/の代わりに /usr/share/drivers/中に置いてしまう。これを直すためには、 手動で正しい場所にファイルをコピー/移動する(./cups-samba.install スクリプト実行後)。

この新しいCUPS PostScriptドライバーは現在バイナリのみである。しかし、無料で使える。 (まだ)完全なソースコードは提供されていない。その理由は、Microsoft DDKの手助けを得て Microsoft Visual Studio 6でコンパイルしつつ、開発されているからである。ドライバー開発者は フリーソフトウェアとしてソースコード全体を配布する許可を得ていない。しかし、CUPS開発者は GPL配下でソースコードの差分をリリースしているので、Visual StudioとDDK のライセンスを持つ人は誰でも自分自身でコンパイルすることが出来る。

異なったドライバーファイルの認識

CUPSドライバーは古いWindows 95/98/Meをサポートせず、Windows NT/2000/XPクライアントのみサポートする。

Windows NT, 2000と XPは以下でサポートされる:

  • cups.hlp

  • cupsdrvr.dll

  • cupsui.dll

古いWindows 95/98/MeのためのAdobeドライバーはWindows NT/2000/XPクライアントと 同じように提供されている。ファイルの組み合わせは異なったプラットフォームでは 異なる。

Windows 95, 98と MEは以下でサポートされる:

  • ADFONTS.MFM

  • ADOBEPS4.DRV

  • ADOBEPS4.HLP

  • DEFPRTR2.PPD

  • ICONLIB.DLL

  • PSMON.DLL

Windows NT, 2000, と XPは以下でサポートされる:

  • ADOBEPS5.DLL

  • ADOBEPSU.DLL

  • ADOBEPSU.HLP

Note

もしも、Windows NT/2000/XPサポート用の、AdobeドライバーファイルとCUPSドライバーファイルの 両方がサーバー上に現在インストールされているならば、Adobeファイルは無視されCUPSファイルが 使われる。もしも理由がなんであれ、Adobeのみのドライバーを使いたいと思うのであれば、3つの CUPSドライバーをどこかに移動すること。Windows 9x/Meクライアントはどんな場合にもAdobeの ドライバーを使う。

ドライバーファイルの入手

Adobeドライバーファイルの入手は、多くのユーザーにとって予想外に難しいように見える。それらは Adobe Webサイトに1つのファイルとして見えているわけではなく、自己解凍か自動インストールを 行うWindows-.exeファイルを見つけるのも難しい。おそらく内蔵されたネイティブな インストーラを使用しなければならず、クライアント上で一回はインストールプロセスを動かす ことが必要である。これは、クライアント上ローカルにドライバー(と1つの汎用PostScriptプリンター) をインストールする。それらがインストールされた後、汎用PostScriptプリンターを共有する。 この作業後、クライアントの[print$]共有は、CUPSホストから smbclientで入手可能なAdobeファイルを保持する。

Windows NT/200x/XP用のESP Print Pro PostScriptドライバー

ESP Print ProソフトウェアのユーザーはAdobe PostScriptドライバーの代替として、ESCプリント ドライバーパッケージをインストールすることが出来る。これを行うために、 Easy Software Webサイトで、ESC Print Proソフトウェアの通常のダウンロード領域からドライバーファイルを 検索できる。Download Printer Drivers for ESP Print Pro 4.x 領域の間でSAMBAと名前が付いたリンクを探し、パッケージをダウンロード する。一度インストールすると、Printer Manager GUI中の中のメニューの、 Export Driver...を選択して、プリンターを単にハイライトさせる ことによって任意のドライバーを準備できる。もちろん、ドライバーファイルを扱うために、 あらかじめ準備されたSambaが必要である。すなわち、[print$] 共有を設定することなどである。ESP Print ProパッケージにはWindows 95/98/Me クライアントファミリ用の(ライセンスされた)Adobeドライバー一式と同様にCUPSドライバー ファイルが含まれている。

考慮すべき警告

一度インストールスクリプト(と、/usr/share/cups/drivers/への cups.hlpファイルの手動での移動)を実行すると、ドライバーはSambaの [print$]共有(これはしばしば /etc/samba/drivers/にマップされ、WIN40W32X86という枝を持つサブディレクトリを含む)中に、ドライバーが 配置できるようになる。これは、cupsaddsmbを動かすことによって 行える(CUPSリリース1.1.16以降ではman cupsaddsmbも参照)。

Tip

smbpasswdを動かしてrootをsmbpasswdファイル中に格納する必要が あるかもしれない。もしも、全体の手順を最初に動かすときに、これは、特に重要であり、 Windowsドメインコンピュータでのシングルサインオン用にすべてが 設定されている環境中では動かない。

いったんドライバーファイルが[print$]共有に置かれ、初期化 されると、それらはダウンロード可能になり、Windows NT/200x/XPクライアントによって インストールされる。

Note

Windows 9x/MeクライアントはCUPS PostScriptドライバーでは動かない。それらには 前述の通り、ADOBE*.*ドライバーを使うことが引き続き必要である。

Note

もしも、/usr/share/cups/drivers/ディレクトリ中に以前の インストールによるADOBE*.*ドライバーファイルが引き続きあるならば、 それは無害である。

Note

使用しているWindowsクライアントが、Adobe PostScriptドライバー用の古い ADOBE*.*ファイルがインストールされていると、新しい Windows NT/200x/XP用のCUPS PostScriptドライバーのダウンロードとインストールは最初に失敗する。 最初にクライアントから古いドライバーを消し去る必要がある。もしも、プリンターを再インストール しようとしたときのために、ドライバーファイルはクライアントによって引き続き保存され、 再利用されることによりプリンターを削除するだけでは十分ではない。 クライアント上のAdobeドライバーファイルを完全に取り除くためには、まず プリンターフォルダーを開き(おそらく スタート -> 設定 -> コントロールパネル ->プリンター)、 フォルダーの背景を右クリックし、ドライバータブを選択する。 一覧表示上で削除したいドライバーを選択し、削除ボタンをクリックする。 これは1つも特定のドライバーを使うプリンターが残っていないときに動作する。まず初めに プリンターフォルダー中でこのドライバーを使うすべてのプリンターを 削除する必要がある。これを行うには管理者権限が必要である。

Note

一度クライアントにCUPS PostScriptドライバーをダウンロードすると、 旧式の印刷サポートで説明したような手続きで、 すべてのプリンターを簡単に切り替えることが出来る。 プリンターのプロパティダイアログを動かすことか、 setdriverサブコマンドを指定したrpcclient を使うことのどちらかで、存在するプリンターのドライバーを切り替えられる。

WindowsのCUPS PostScriptドライバー対Adobeドライバー

CUPSとAdobe PostScriptドライバーの比較に興味があるだろうか?我々の目的のために、 Are you interested in a comparison between the CUPS and the Adobe PostScript drivers? For our purposes, these are the most important items that weigh in favor of CUPS:

  • Adobe EULAに縛られない。

  • ADOBE*.*ドライバーファイルをダウンロードできる所はどこか? という質問に縛られない。

  • Adobe ドライバー(sれに関連するプリンターのPPD要求において)はしばしば印刷ファイルの メイン部分の先頭にPJLヘッダーを置く。そのため、印刷ファイルは %!PSの代わりに<1B>%-12345X<escape>%-12345Xで始まる。これはCUPSデーモンが入力 ファイルを印刷可能なファイルと自動タイプすることをさせるようにし、 pstopsフィルタ経由で初期化しない(もう少し技術的に言うと、 これは一般的なMIMEタイプ application/postscriptと見なされないが、より特別な MIMEタイプである application/cups.vnd-postscriptとみなす)ので、 /var/log/cups/page_log中におけるページの計数は正確な ページ数を受け取れない。その代わりに標準的な設定では、ダミーのページ数 1が記録される。

  • Adobeドライバーは、それによって生成するPostScriptを間違って 設定するいくつかのオプションがある (CUPSがそれを処理することが出来ないようにしてしまう、 Optimize for Speedを、 Optimize for Portabilityの代わりに、うっかりして 設定してしまう)。

  • WindowsクライアントによるCUPSサーバーへのCUPS PostScriptドライバーの 出力は、汎用MIMEタイプapplication/postscriptとして 自動タイプされ、CUPS pstopsフィルタに渡され、会計と quota目的のためにpage_log中に正しいページ数を記録する。

  • CUPS PostScriptドライバーは、Windows NT/200x/XPクライアントによる、追加の標準(IPP) 印刷オプションを送信することをサポートする。そのような追加印刷オプションは、 CUPS標準バナーページ(かカスタムなもので、ドライバーは ダウンロード時点でインストールされるべき)と名前を付けられ、CUPSページラベル オプションを使い、ジョブのプライオリティを設定し、(将来、追加の便利な IPPジョブ属性をサポートするオプションで)印刷予定時間を設定する。

  • CUPS PostScriptドライバーは、PostScriptファイルの先頭に、新しい *cupsJobTicketコメントの挿入をサポートする (これは、将来、すべての種類のCUPS上での便利な拡張のために使われるが、 これがコメントとして扱われ、単に無視されるため、任意の他の アプリケーションのじゃまをしない)。

  • CUPS PostScriptドライバーは、近々リリースされる、 Windows NT/200x/XP用の完全なCUPS IPPクライアントの心臓部である (おそらく最初のCUPS 1.2のβリリースと一緒に)。

cupsaddsmbの実行(Quiet Mode)

cupsaddsmbコマンドは、必要とされるファイルを [print$]共有にコピーする。さらに追加で、このプリンターに関連 づけられているPPDは、/etc/cups/ppd/から [print$]にコピーされる。これらファイルはポイントアンドプリント 経由でWindowsクライアントのインストールの都合のために待機している。コマンドを 正しく実行できる前に、Sambaに対して認証を行っておく必要がある。小さなネットワーク 環境では、おそらくユーザーレベルのセキュリティ (security = user)を使っているだろう。

以下は、正しく動くcupsaddsmbコマンドの例である:

root# cupsaddsmb -U root infotec_IS2027
Password for root required to access localhost via Samba: ['secret']

すべてのプリンターとドライバーを共有するために、プリンター名の代わりに -aパラメーターを使う。cupsaddsmbがプリンタードライバーを Sambaにエクスポートしてから、CUPSドライバーに関連づけられているキュー のみ動作することは明白になるべきである。

詳細な結果を表示するcupsaddsmbの実行

おそらく何が起きているかを見たいのだと思う。より詳細な出力は、-v パラメーターを使う。可読性向上のために下記の出力には手を入れてある。 すべての行末の\は手動で入れてあり、そのほかにインデントもしている:

root# cupsaddsmb -U root -v infotec_2105
Password for root required to access localhost via GANDALF:
Running command: smbclient //localhost/print\$ -N -U'root%secret' \
    -c 'mkdir W32X86; \
    put /var/spool/cups/tmp/3e98bf2d333b5 W32X86/infotec_2105.ppd; \
	put /usr/share/cups/drivers/cupsdrvr.dll W32X86/cupsdrvr.dll; \
    put /usr/share/cups/drivers/cupsui.dll W32X86/cupsui.dll; \
    put /usr/share/cups/drivers/cups.hlp W32X86/cups.hlp'
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
putting file /var/spool/cups/tmp/3e98bf2d333b5 as \W32X86/infotec_2105.ppd
putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll
putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll
putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp
  
Running command: rpcclient localhost -N -U'root%secret' 
   -c 'adddriver "Windows NT x86"   \
   "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \
    RAW:NULL"'
cmd = adddriver "Windows NT x86" \
   "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \
	RAW:NULL"
Printer Driver infotec_2105 successfully installed.
  
Running command: smbclient //localhost/print\$ -N -U'root%secret' \
-c 'mkdir WIN40; \
    put /var/spool/cups/tmp/3e98bf2d333b5 WIN40/infotec_2105.PPD; \
	put /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM;   \
    put /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV; \
    put /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP; \
    put /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD; \
	put /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL; \
	put /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;'
  added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
  Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
  NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
  putting file /var/spool/cups/tmp/3e98bf2d333b5 as \WIN40/infotec_2105.PPD
  putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM
  putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV
  putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP
  putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD
  putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL
  putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL
  
  Running command: rpcclient localhost -N -U'root%secret' \
   -c 'adddriver "Windows 4.0"      \
   "infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL:ADOBEPS4.HLP: \
   PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL, \
    ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
	cmd = adddriver "Windows 4.0" "infotec_2105:ADOBEPS4.DRV:\
	infotec_2105.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,\
	infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,\
	ICONLIB.DLL"
  Printer Driver infotec_2105 successfully installed.
  
  Running command: rpcclient localhost -N -U'root%secret'  \
   -c 'setdriver infotec_2105 infotec_2105'
  cmd = setdriver infotec_2105 infotec_2105
  Successfully set infotec_2105 to driver infotec_2105.

Warning

出力結果上ではSambaアカウントのためのrootパスワードが表示されている。

もし、しっかり見た場合、ネットワーク上で暗号化されていないrootパスワードが転送されて いることを発見するはずなので、注意するように。また、もしもさらによく見てみると、 出力中にNT_STATUS_OBJECT_NAME_COLLISIONというようなエラーメッセージを見つけるだろう。 これは、WIN40とW32X36というディレクトリが(以前のドライバーインストールにより) すでに[print$]というドライバーダウンロード共有中に存在 している時に発生する。これらは問題のないエラーメッセージである。

cupsaddsmbについて理解する

何が起きたのか?cupsaddsmbは何をしたのか?手順には5つのステージがある:

  1. IPP経由でCUPSサーバーを呼び出し、その名前のプリンター用のドライバーファイルとPPDファイルを要求する。

  2. ローカルのTEMPDIR中(cupsd.confで定義されている)に、 ファイルを一時的に格納する。

  3. smbclient経由でSambaサーバーの[print$]共有に 接続し、共有のWIN40(Windows 9x/Me用)とW32X86(Windows NT/200x/XP用)サブディレクトリ 中にファイルを書き込む。

  4. rpcclient経由でSambaサーバーに接続し、正しいパラメーターでadddriver コマンドを実行する。

  5. rpcclient経由でSambaサーバーにもう一度接続し、setdriverコマンドを実行する。

Note

1番目のリモートホストとしてSambaホストを、2番目のリモートホストとしてCUPSホストを指定する ためのパラメーターを付けてcupsaddsmbユーティリティを実行できる。 特に、もしもより深く理解したい場合、何が起きたかをより明快にするためにテストしてみるのは 良いことである(実際には、ほとんどの人はCUPSとSambaサーバーを同じホストで動作させている):

root# cupsaddsmb -H sambaserver -h cupsserver -v printer

もしもcupsaddsmbが正しく終了した場合、どのように認識するか

もしもユーティリティがすべてのフィールドで正しく終わった場合、常時検査を しなければならない。少なくとも出力中の、以下の3つの メッセージをチェックする必要がある:

  1. Printer Driver infotec_2105 successfully installed. # (for the W32X86 == Windows NT/200x/XP architecture).

  2. Printer Driver infotec_2105 successfully installed. # (for the WIN40 == Windows 9x/Me architecture).

  3. Successfully set [printerXPZ] to driver [printerXYZ].

これらのメッセージはおそらく一般的な出力中では簡単に認識できない。もしも (ダウンロードのための、すべての有効なプリンタードライバーを 準備しようとする)-aオプションを付けてcupsaddsmbを 動かした場合、もしも個々のプリンタードライバーに、正しくにインストールすることに関して 問題がある場合、失敗するかもしれない。出力のリダイレクトは、結果を解析することを 手助けする。

もしも下記のメッセージが出た場合:

SetPrinter call failed!
result was WERR_ACCESS_DENIED

これは、このプリンターに対してuse client driver = yes という設定がされているかもしれないということを意味する。この設定をnoに すると、この問題が解決する。smb.confマニュアルページ中の、 use client driverについての説明を参照のこと。

Note

もしも、verboseモードでcupsaddsmbを動かしていないと、何らかの診断 出力を得るのは不可能である。そのため、既定値であるquietモードを使わないことを強く 推奨する。quietモードを使うと、発生するかもしれない何らかの問題を隠してしまうだろう。

Samba PDCににおけるcupsaddsmb

Samba PDC上で動かすために、標準のcupsaddsmbコマンドは動かないのか? 認証のためにパスワードを繰り返し聞かれ、コマンドは全く起動しないのか?以下にある応用の どれかを試してみてほしい:

root# cupsaddsmb -U MIDEARTH\\root -v printername
root# cupsaddsmb -H SAURON -U MIDEARTH\\root -v printername
root# cupsaddsmb -H SAURON -U MIDEARTH\\root -h cups-server -v printername

(2つのバックスラッシュに注意:最初のものは二番目のものに対するescapeである)。

cupsaddsmbフローチャート

cupsaddsmbフローチャートは、cupaddsmbの 処理手順、コマンドフローとデータフローを示すチャートである。再度注意:cupsaddsmbは raw印刷キューと一緒に動かないし、そういうことを意図してもいない!

Figure 22.16. cupsaddsmbのフローチャート

cupsaddsmbのフローチャート

クライアント上でのPostScriptドライバーのインストール

cupsaddsmbの完了後、ドライバーは、クライアントから使えるようになる。 以下は、ポイントアンドプリント経由でダウンロードしインストールするために行わなければ ならない手順である。Windowsクライアントから、CUPS/Sambaサーバーをブラウズする:

  • ネットワークコンピュータ中のSambaのプリンター共有を開く

  • 問い合わせ(question)中のプリンターを右クリックする

  • 開いたコンテキストメニューから下記を選択する インストール... あるいは 接続... (使用しているWindowsのバージョンに依存する)

数秒後、クライアントのローカルプリンター フォルダー中に新しいプリンターが現れる。Windows XP上では、 Sambaサーバー上のプリンター名という名前が付けられている (現在多くの場合kde-bitshop上のinfotec_2105のようになる)。もしもMicrosoft Wordのような アプリケーションから、テストと最初のジョブを送りたい場合、有効なプリンター一覧の ドロップダウンリスト中に、\\SambaServer\PrinterNameという エントリで新しいプリンターが現れる。

cupsaddsmbはCUPSバージョン1.1.15以上とSamba バージョン2.2.4以降でのみ 確実に動作する。もしも動かない場合か、クライアントへの自動プリンターダウンロードが成功 しないばあい、クライアント上でAdobe PostScriptドライバーのtop ofのCUPSプリンターPPDを手動で インストールトーすすることができる。次に、UNCタイプの接続のために、クライアントの プリンターキューをSambaプリンター共有に指定する: cupsaddsmb will only reliably work with CUPS version 1.1.15 or higher and with Samba version 2.2.4, or later. If it does not work, or if the automatic printer driver download to the clients does not succeed, you can still manually install the CUPS printer PPD on top of the Adobe PostScript driver on clients. Then point the client's printer queue to the Samba printer share for a UNC type of connection:

C:\> net use lpt1: \\sambaserver\printershare /user:ntadmin

これは、CUPSでネットワークされたPostScript RIP機能を使用することが出来るようになる (ユーザーntadminはプリンター共有にアクセスするための必要な権限を持つ 有効なSambaユーザーである必要がある)。これは、従来からのLanManによる方法(MS-RPCを使わない) でプリンターの接続を設定する。

クライアント上での危険なPostScriptドライバー設定を防止する

印刷が動作するが、まだ問題があるとする。ほとんどのジョブは正しく印刷するが、いくつかは 全く印刷できない。いくつかのジョブは、とても良いとは見えないフォントの問題を抱えている。 いくつかのジョブは速やかに処理されるが、いくつかはとても遅い。これらの問題の多くは、 いくつかのガイドラインに従うことで、劇的に軽減できるか、完全になくなる。思い出して ほしいが、もしも使用している印刷デバイスがPostScriptが有効でない場合、 使用しているクライアントドライバーの設定が生成する出力を使って、CUPSホスト上での Ghostscriptインストールを取り扱ているはずである。以下のようにうまく処理するようにする:

  • Optimize for Speedという設定のPostScript出力オプションを抑制する。その代わりに Optimize for Portabilityを使用する(Adobe PostScriptドライバー)。

  • Page Independenceを使わない:設定なしにする。その代わりに、Page Independence: YES とする(CUPS PostScriptドライバー)。

  • 推奨はTrue Typeフォントダウンロードオプション:Native True Type over Automatic and Outline である。なんとしてもBitmapを避けるべきである(Adobe PostScriptドライバー)。

  • True Typeフォントを選択する:Download as Softfont into Printer over the default Replace by Device Font (Adobeにおいては、各国のフォントは、出力を得るためにそれを戻す必要があるかもしれない。

  • 時には、PostScript言語レベルを選択することが出来る:問題が発生した場合は 3のかわりに2を試してみる(Adobeにおいては、最新のESP Ghostscriptパッケージは レベル3のPostScriptをとてもうまく扱える)。

  • PostScriptエラーハンドラーにYesと答える(Adobe)。

rpcclientを使ったPostScriptドライバーファイルの手動インストール

もちろん、1つずつ、cupsaddsmbという便利なユーティリティ中に埋め込まれているすべての コマンドを動かすことと、アップロードと、将来のクライアントダウンロードのためにドライバー ファイルを準備することは出来る。

  1. Sambaを準備する(そこにあるべきプリンターの名前を使うCUPSプリントキュー。 ドライバーを提供している。)

  2. [print$]にファイルをコピー。

  3. rpcclient adddriverを動かす (サポートしたい各クライアントアーキテクチャ毎に)。

  4. Run rpcclient setdriver.

今これを行おうとしよう。最初に、最初の案を得るために、rpcclientの マニュアルを読む。印刷に関連するすべてのサブコマンドを見る: enumprinters,enumdrivers, enumports, adddriversetdriverは最も興味があるものである。 rpcclientはMS-RPCプロトコルの重要な一部を実装している。 これをWindows NT(か200x/XP)に問い合わせ(とコマンド)を行うのにも使える。MS-RPCは Windowsクライアントによって使われ、とりわけ、ポイントアンドプリント機能に適合する ために使われる。Sambaは今、同様にこれをまねることが出来る。

rpcclientマニュアルページのチェック

最初に、rpcclientマニュアルページをチェックしよう。 個々には2つの読むべきな文節がある:

adddriver <arch> <config>は、サーバー上でプリンタードライバー 情報をインストールするために、AddPrinterDriver()RPCを実行する。 ドライバーファイルはgetdriverdirによって返されるディレクトリ中に すでに存在すべきである。archが取れる値は getdriverdirコマンドのものと同じである。config パラメーターは以下のように定義される:

Long Printer Name:\
Driver File Name:\
Data File Name:\
Config File Name:\
Help File Name:\
Language Monitor Name:\
Default Data Type:\
Comma Separated list of Files

任意の空白のフィールドはNULLという文字列を入力すべきである。

Sambaはプリントモニターというコンセプトをサポートする必要がないので、通信のために双方向 リンクを使うことが出来るドライバーがあるローカルプリンターのためにのみそれらは適用される。 このフィールドはNULLにすべきである。リモートNT印刷サーバー上で、ドライバーに 対する印刷モニターはドライバーを追加する前にすでにインストールされていなければならない。 そうしないと、RPCは失敗する。

setdriver <printername> <drivername>は、インストール されたプリンターに関連するプリンタードライバーをアップロードするために、 SetPrinter()コマンドを実行する。プリンタードライバーはプリンターサーバー 上にあらかじめ正しくインストールされている必要がある。

インストールされたプリンターとドライバーの一覧を得るための、 enumprintersenumdriversコマンドも 参照のこと。

rpcclientマニュアルページの理解

正確なフォーマットはマニュアルページによって明快にはならないので、 空白を含むパラメーターを扱う必要がある。以下は、それに対するもう少しわかりやすい説明で ある。ここではコマンドを改行し、改行は\で示している。通常、改行なしに 1行でコマンドを記述するだろう: The exact format isn't made too clear by the man page, since you have to deal with some parameters containing spaces. Here is a better description for it. We have line-broken the command and indicated the breaks with \. Usually you would type the command in one line without the line breaks:

adddriver "Architecture" \
   "LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\
   LanguageMonitorFile:DataType:ListOfFiles,Comma-separated"

マニュアルページが示すものは、実際に存在する3つのコロンで分離されたフィールド中の、 単純な<config>キーワードである。最後のフィールドは、 複数の(あまり尋常でない場合では、異なった20のもの)ファイルである。これは、最初は 混乱するように見えるかもしれない。LongPrinterNameとマニュアルページが 呼んでいるものは、実際ではドライバー名と呼ばれるべきである。これは 自由に名前を付けられ、後でrpcclient ... setdriverコマンド中で この名前を使える。実用的な理由で、多くはプリンターと同じ名前をドライバーに付ける。 What the man pages denote as a simple <config> keyword in reality consists of eight colon-separated fields. The last field may take multiple (in some very insane cases, even 20 different additional) files. This might sound confusing at first. What the man pages call the LongPrinterName in reality should be called the Driver Name. You can name it anything you want, as long as you use this name later in the rpcclient ... setdriver command. For practical reasons, many name the driver the same as the printer.

これは全く単純ではない。どのファイルがドライバーファイルをどうやったら分かるか、 各データファイル, 構成ファイル, ヘルプファイルLanguage Monitorファイルの場合は?という質問があるだろう。答えのために、 共有プリンターを持つWindows NTがそれらのファイルをどのように提供しているかを見てみるのも よいかもしれない。覚えておいてほしいが、この全体の手続きはネットワーク上でWindows コンピュータが発生させたトラフィックをモニターすることによってSambaチームにより開発 されねばならなかったと言うことである。Windowsマシンに切り替えて、UNIX ワークステーションからうまくアクセスしても良い。それが何を送っているかを見るために、 rpcclientで問い合わせてもよく、より明快にするために、マニュアル ページの理解を試みても良い。 It isn't simple at all. I hear you asking: How do I know which files are Driver File, Data File, Config File, Help File and Language Monitor File in each case? For an answer, you may want to have a look at how a Windows NT box with a shared printer presents the files to us. Remember that this whole procedure has to be developed by the Samba Team by listening to the traffic caused by Windows computers on the wire. We may as well turn to a Windows box now and access it from a UNIX workstation. We will query it with rpcclient to see what it tells us and try to understand the man page more clearly.

Producing an Example by Querying a Windows Box

We could run rpcclient with a getdriver or a getprinter subcommand (in level 3 verbosity) against it. Just sit down at a UNIX or Linux workstation with the Samba utilities installed, then type the following command:

root# rpcclient -U'user%secret' NT-SERVER -c 'getdriver printername 3'

結果から、どれがどれであるか明快になるべきである。以下はインストールの例である:

root# rpcclient -U'Danka%xxxx' W200xSERVER \
    -c'getdriver "DANKA InfoStream Virtual Printer" 3'
    cmd = getdriver "DANKA InfoStream Virtual Printer" 3

 [Windows NT x86]
 Printer Driver Info 3:
         Version: [2]
         Driver Name: [DANKA InfoStream]
         Architecture: [Windows NT x86]
         Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.DLL]
         Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\INFOSTRM.PPD]
         Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRPTUI.DLL]
         Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.HLP]
 
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
 
         Monitorname: []
         Defaultdatatype: []

いくつかのプリンタードライバーはDependentfilesというラベルで、 追加のファイルを一覧表示し、それらは最後のフィールドである ListOfFiles,Comma-separated中に押し込まれる。CUPS PostScript ドライバー用には、それらは不要で(Adobe PostScriptドライバーも)、それゆえ、フィールドには NULLが入るだろう。 Some printer drivers list additional files under the label Dependentfiles, and these would go into the last field ListOfFiles,Comma-separated. For the CUPS PostScript drivers, we do not need any (nor would we for the Adobe PostScript driver); therefore, the field will get a NULL entry.

adddriverとsetdriverを完了させるための要求事項

マニュアルページから(と上記のcupsaddsmbの引用された出力から)、 手動でのアップロードとドライバーファイルの初期化を成功させるために、一定の状態を用意 する必要があることが明確になる。2つのrpcclientサブコマンド (adddriversetdriver)は、成功させるために、 以下の前提条件を準備する必要がある:

  • printer adminかroot(これはNTの Printer Operatorsグループではないがsmb.conf[global]セクションで定義されている printer adminグループ)で接続する。

  • 要求されたドライバーを\\SAMBA\print$\w32x86\\SAMBA\print$\win40に、適切にすべてコピーする。 これらは、その後最終的に02という サブディレクトリで終わる。現時点では、それらをそこに 置いてはならない。それらは自動的に adddriverサブコマンドによって使われる(もしも共有中にドライバー ファイルを置くために、smbclientコマンドを使うならば、 $をエスケープする必要があることに注意。たとえば、 smbclient //sambaserver/print\$ -U root.)。 Copy all required driver files to \\SAMBA\print$\w32x86 and \\SAMBA\print$\win40 as appropriate. They will end up in the 0 respective 2 subdirectories later. For now, do not put them there; they'll be automatically used by the adddriver subcommand. (If you use smbclient to put the driver files into the share, note that you need to escape the $: smbclient //sambaserver/print\$ -U root.)

  • 接続しているユーザーは[print$]共有に 書き込みとサブディレクトリの作成が出来ねばならない。

  • Windowsクライアント用に設定しようとしているプリンターは、 CUPSによってすでにインストールされている必要がある。

  • CUPSプリンターはSambaによって認識されねばならない:さもないと、 setdriverサブコマンドは、NT_STATUS_UNSUCCESSFULというエラーで 失敗する。Sambaによってプリンターが認識されているかを調べるには、 rpcclientenumprintersサブコマンドを 使うことが出来る。長く存在しているバグが、各smbdプロセスがSIGHUPを受け取るか、 再起動するまで、プリンター一覧の適切な更新を阻害している。ごく最近CUPSプリンターを 作成して問題が発生した場合、Sambaを再起動することを覚えておいてほしい。

15ステップでの手動ドライバーインストール

すべての要求されたコマンドを実行して、手動で、プリンタードライバーをインストールしてみる。 最初、これは複雑なプロセスなように見えるという理由で、手順を1つずつ、やらなければ ならない、単一のアクションアイテム毎に説明する。 We are going to install a printer driver now by manually executing all required commands. Because this may seem a rather complicated process at first, we go through the procedure step by step, explaining every single action item as it comes up.

Procedure 22.2. 手動でのドライバーインストール

  1. CUPS上でのプリンターのインストール

    	root# lpadmin -p mysmbtstprn -v socket://10.160.51.131:9100 -E \
    				-P canonIR85.ppd
    	

    これは、CUPSシステムにmysmbtstprnという名前のプリンターを インストールする。プリンターはソケット(JetDirectかDirect TCP/IPとして知られる) 接続経由で接続される。このステップはrootで行う必要がある。

  2. (オプション)Sambaによってプリンターが認識されているかを調べる。

    root# rpcclient -Uroot%xxxx -c 'enumprinters' localhost \
      | grep -C2 mysmbtstprn
    flags:[0x800000]
    name:[\\kde-bitshop\mysmbtstprn]
    description:[\\kde-bitshop\mysmbtstprn,,mysmbtstprn]
    comment:[mysmbtstprn]
    

    これは、一覧中にプリンターを表示する。層でなければ、Sambaデーモン(smbd)をいったん 止めて再起動するか、HUPシグナルを送る:

    root# kill -HUP `pidof smbd`
    

    再度チェックする。成功するまでトラブルシュートを繰り返し行う。 description行中に、2つのカンマの間に空白の フィールドがあることに注意。すでに1つ存在していれば、ドライバー名はここに現れる。 このステップと、この後のステップのほとんどのために、rootのSambaでのパスワード (smbpasswdコマンドによって設定される)を知っておく必要がある。 代わりに、[print$]に対してsmb.conf中で write listとして定義されているユーザーからの1つで認証する事が出来る。

  3. (オプション)プリンターに対するドライバーをSambaが認識しているかを調べる。

    root# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2'\
     localhost | grep driver 
    
    drivername:[]
    
    root# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' \
     localhost | grep -C4 driv
    
    servername:[\\kde-bitshop]
    printername:[\\kde-bitshop\mysmbtstprn]
    sharename:[mysmbtstprn]
    portname:[Samba Printer Port]
    drivername:[]
    comment:[mysmbtstprn]
    location:[]
    sepfile:[]
    printprocessor:[winprint]
     
    root# rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost
     result was WERR_UNKNOWN_PRINTER_DRIVER
    

    上記で示されている3つのコマンドのどれもドライバーを表示しない。 このステップはこの条件をデモンストレーションする目的で行われた。このステージにおける プリンターへの接続の試みは、 The server does not have the required printer driver installed. という行を表示する。

  4. すべての要求されたドライバーファイルをSambaの[print$]に置く。

    root# smbclient //localhost/print\$ -U 'root%xxxx' \
    	-c 'cd W32X86; \
    	put /etc/cups/ppd/mysmbtstprn.ppd mysmbtstprn.PPD; \ 
    	put /usr/share/cups/drivers/cupsui.dll cupsui.dll; \
    	put /usr/share/cups/drivers/cupsdrvr.dll cupsdrvr.dll; \
    	put /usr/share/cups/drivers/cups.hlp cups.hlp'
    

    (このコマンドは、単一の長い行で入力すべきである\によって示される 改行と行末は可読性向上のために挿入されている)。このステップは、次のものを成功 させるために必要とされる。これは、ドライバーファイルを物理的に [print$]共有中に存在させるようにする。しかし、それらを Sambaはまだドライバーファイルとして扱えないので、クライアントはまだそれらをインストール できない。クライアントがドライバーについて問い合わせると、引き続き not installed hereというメッセージが表示される。

  5. 現在どこにドライバーファイルがあるかを検査する。

    root# ls -l /etc/samba/drivers/W32X86/
    total 669
    drwxr-sr-x    2 root     ntadmin       532 May 25 23:08 2
    drwxr-sr-x    2 root     ntadmin       670 May 16 03:15 3
    -rwxr--r--    1 root     ntadmin     14234 May 25 23:21 cups.hlp
    -rwxr--r--    1 root     ntadmin    278380 May 25 23:21 cupsdrvr.dll
    -rwxr--r--    1 root     ntadmin    215848 May 25 23:21 cupsui.dll
    -rwxr--r--    1 root     ntadmin    169458 May 25 23:21 mysmbtstprn.PPD
    

    ドライバーファイルは現在[print$]rootとする W32X86アーキテクチャにある。

  6. Sambaにそれらがドライバーファイルであると告げる(adddriver)。

    root# rpcclient -Uroot%xxxx -c 'adddriver "Windows NT x86" \
    	"mydrivername:cupsdrvr.dll:mysmbtstprn.PPD: \
      cupsui.dll:cups.hlp:NULL:RAW:NULL"' \
      localhost
    Printer Driver mydrivername successfully installed.
    

    これが失敗してもこのステップを繰り返すことはできない。これは単なるtypoの結果であったと しても失敗する。それは、たいていの場合、ドライバーファイルの一部を2 サブディレクトリ中に移動してしまっただろう。もしもこのステップが失敗したならば、 このステップを再度実行する前に、4番目のステップに戻り、繰り返す必要がある。この ステップ中で、ドライバーの名前を選択する必要がある。プリンターの名前として使うものと同じ 名前を使うことはよい方法である。しかし、大量にインストールする場合、明確に異なった 名前の、数多くのプリンターに対するドライバーを使っても良い。そのため、ドライバーの名前は 決定されない。

  7. 現在ドライバーファイルがどこにあるかを調べる。

    root# ls -l /etc/samba/drivers/W32X86/
    total 1
    drwxr-sr-x    2 root     ntadmin       532 May 25 23:22 2
    drwxr-sr-x    2 root     ntadmin       670 May 16 03:15 3
    
    root# ls -l /etc/samba/drivers/W32X86/2
    total 5039
    [....]
    -rwxr--r--    1 root     ntadmin     14234 May 25 23:21 cups.hlp
    -rwxr--r--    1 root     ntadmin    278380 May 13 13:53 cupsdrvr.dll
    -rwxr--r--    1 root     ntadmin    215848 May 13 13:53 cupsui.dll
    -rwxr--r--    1 root     ntadmin    169458 May 25 23:21 mysmbtstprn.PPD
    

    どのようにステップ6が適切なサブディレクトリ中にドライバーファイルを移動したかに注目。 ステップ5の後の状態と今の状態を比較する。

  8. (オプション)Sambaが現時点でドライバーを認識しているかを確認する。

    root# rpcclient -Uroot%xxxx -c 'enumdrivers 3' \
    	localhost | grep -B2 -A5 mydrivername
    Printer Driver Info 3:
    Version: [2]
    Driver Name: [mydrivername]
    Architecture: [Windows NT x86]
    Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll]
    Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD]
    Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll]
    Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp]
    

    思い出してほしいが、このコマンドはステップ6で選択したドライバーの名前を検索する。 このコマンドは次のステップに行く前に成功しなければならない。

  9. どのプリンターがこのドライバーファイルを使うかをSambaに告げる(setdriver)。

    root# rpcclient -Uroot%xxxx -c 'setdriver mysmbtstprn mydrivername' \
    	localhost
    Successfully set mysmbtstprn to driver mydrivername
    

    任意のプリンター名(プリンターキュー)を任意のドライバーに結合できるので、これは同じドライバーを 使う数多くのキューを設定するのに便利な方法である。これを成功させるために、setdriver コマンドに対する以前のステップのすべてを繰り返す必要はない。やらなければならない唯一の 準備は、enumdriversがドライバーを見つけられねばならないと言うことと、 enumprintersがプリンターを見つけられねばならないと言うことである。

  10. (オプション)この結合をSambaが認識しているかを調べる。

    root# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \
      | grep driver
    drivername:[mydrivername]
     
    root# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \
      | grep -C4 driv
    servername:[\\kde-bitshop]
    printername:[\\kde-bitshop\mysmbtstprn]
    sharename:[mysmbtstprn]
    portname:[Done]
    drivername:[mydrivername]
    comment:[mysmbtstprn]
    location:[]
    sepfile:[]
    printprocessor:[winprint]
     
    root# rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost
    [Windows NT x86]
    Printer Driver Info 3:
         Version: [2]
         Driver Name: [mydrivername]
         Architecture: [Windows NT x86]
         Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll]
         Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD]
         Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll]
         Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp]
         Monitorname: []
         Defaultdatatype: [RAW]
         Monitorname: []
         Defaultdatatype: [RAW]
     
    root# rpcclient -Uroot%xxxx -c 'enumprinters' localhost \
    	| grep mysmbtstprn
         name:[\\kde-bitshop\mysmbtstprn]
         description:[\\kde-bitshop\mysmbtstprn,mydrivername,mysmbtstprn]
         comment:[mysmbtstprn]
    
    

    ステップ2と3からの結果とこの結果を比較する。上記のコマンドの1つ1つはインストールされた ドライバーを表示する。たとえenumprintersコマンドが description行上のドライバーを一覧表示するとしても。

  11. (オプション)正しいデバイスモードにドライバーを修正する

    クライアント上にドライバーをどのようにインストールするかについては確実に知っている はずである。特にWindowsに慣れていない場合、簡単なやり方がある: ネットワークコンピュータをブラウズし、Sambaサーバーを選び、共有を捜す。 すべての共有されたSambaプリンターが見えるはずである。質問(question)中の1つを ダブルクリックする。ドライバーが得られてインストールされて、ネットワーク接続が 設定される。別の方法は、プリンターとFAXフォルダーを開き、 質問(question)中のプリンターを右クリックし、接続又は インストールを選択する。その結果、クライアントのローカルの プリンターとFAXフォルダー中に新しいプリンターが現れ、それには Sambahostname上のprintersharenameのような何らかの名前が 付いている。

    このステップをSambaのprinter admin(smb.conf中で定義)として実行することは重要である。 これをWindows XP上で行う別の手法がある。これは、DOSプロンプト内で、 以下のようにコマンドラインを使う(要求された時に、rootのsmbpassordを入力する):

    C:\> runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry \
    	/in /n \\sambaserver\mysmbtstprn"
    

    任意のプリンターの設定を一回変更し、 (縦方向横方向になど) 適用をクリックし、設定を元に戻す。

  12. クライアント上でプリンターをインストールする(ポイントアンドプリント)。

    C:\> rundll32 printui.dll,PrintUIEntry /in /n "\\sambaserver\mysmbtstprn"
    

    もしもこれが動かない場合、[print$]共有のアクセス許可問題かもしれない。

  13. (オプション)テストページを印刷する。

    C:\> rundll32 printui.dll,PrintUIEntry /p /n "\\sambaserver\mysmbtstprn"
    

    次に5回[タブ]を入力し、[ENTER]を二回入力し、[TAB]を1回、そして再度[ENTER]を入力し プリンターの所に行く。

  14. (推奨)テストページを調査する。

    今は、プリンターのインストールについてすべてを知っていて、そこに書いてあることを読む必要は ない。額縁にこれを入れて、"初めてRPCCLIENTでインストールしたプリンター"というタイトルを 付けて壁に貼ろう。でも、やはり捨てるよね。 Hmmm. Just kidding! By now you know everything about printer installations and you do not need to read a word. Just put it in a frame and bolt it to the wall with the heading "MY FIRST RPCCLIENT-INSTALLED PRINTER" why not just throw it away!

  15. (義務)飛び上がって成功を喜ぼう。

    root# echo "Cheeeeerioooooo! Success..." >> /var/log/samba/log.smbd
    

トラブルシューティング再考

もしもSambaが、キューがそこにないと考えた場合、setdriverコマンドは失敗する。 インストールが成功すると以下の頼もしいメッセージが表示される:

Printer Driver ABC successfully installed.

この後、adddriver部分の手続きが続く。しかし、以下のような 期待はずれのメッセージが出るかもしれない: result was NT_STATUS_UNSUCCESSFUL

CUPS中のキューを見ることができるだけでは十分ではないので、 lpstat -p ir85wmコマンドを使う。最も最近のSambaのバージョンでは、 適切なキュー一覧の更新を妨害するというバグがある。Sambaを再起動するか、すべてのsmbd プロセスにHUPを送るまで、新しくインストールしたCUPSプリンターの認識に失敗する。なぜSambaが setdriverコマンドを正しく実行しないかという理由がこれかと言うことを 検証するために、Sambaがプリンターを認識しているかを調べる:

root# rpcclient transmeta -N -U'root%xxxx' -c 'enumprinters 0'|grep ir85wm
        printername:[ir85wm]

別のコマンドでのやり方もある:

root# rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm' 
        cmd = getprinter ir85wm
        flags:[0x800000]
        name:[\\transmeta\ir85wm]
        description:[\\transmeta\ir85wm,ir85wm,DPD]
        comment:[CUPS PostScript-Treiber for Windows NT/200x/XP]

所で、上記のコマンドに、さらにいくつかを使うことが出来、もちろん、 リモートのWindows NT印刷サーバーにもインストールできる!

印刷関連の*.tdbファイル

すべてのSambaをインストールした環境にある、tdbという拡張子を持った、一連のファイル は謎であろう。それらは、 connections.tdb, printing.tdb, share_info.tdb, ntdrivers.tdb, unexpected.tdb, brlock.tdb, locking.tdb, ntforms.tdb, messages.tdb , ntprinters.tdb, sessionid.tdb, とsecrets.tdbである。これらの目的はなんであるか?

Trivial Database Files

Windows NT(印刷)サーバーは、Windowsレジストリ中にエントリを格納することによって、その クライアントに対して、その作業を提供するのに必要なすべての情報を記録する。クライアントの 問い合わせはレジストリを読み取ることによって回答が行われ、Administratorかユーザーの 構成設定はレジストリ中に書き込むことで保存される。SambaとUNIXは明らかにこのような レジストリを持っていない。Sambaはその代わりに、一連の*.tdbファイルに すべてのクライアントに関連する情報を保存する(TDBはtrivial data baseの省略形である)。 これらはたいてい/var/lib/samba//var/lock/samba/にある。印刷関連のファイルは、 ntprinters.tdb, printing.tdb, ntforms.tdbntdrivers.tdbである。

バイナリ形式

*.tdbは人間に可読なファイルではない。それらはバイナリ形式である。 なぜASCIIでないのか?と質問するかもしれない。 結局の所、ASCII設定ファイルは、便利でUNIXでの伝統である。 Sambaチームによって、デザインがこうなった理由は、主に性能である。Sambaは高速で動作する 必要がある。ある環境では数千にもなる、各クライアントの接続毎に分離された smbdプロセスが動く。これらのいくつかは、 同じ時間に同じ*.tdbファイルをそれら smbdプロセスが書き込みアクセスをする必要があるかもしれない。 Sambaの*.tdbファイル形式は、これを提供できる。多くのsmbd プロセスは同じ時間に同じ*.tdbファイルに書き込みができる。 これは純粋なASCIIファイルでは不可能である。

*.tdbファイルの喪失

すべての*.tdbファイルはすべての読み取りと書き込みアクセス間で 整合性を保持することはとても重要である。しかし、これらのファイルが 壊れることがあるかもしれない(書き込み処理中に、 kill -9 `pidof smbd'を実行すると、ダメージを与えることになる。 そのほか、急な電源断など)。このようなトラブルの場合、古い印刷関係の *.tdbファイルを削除するのが唯一の解である。その後、その時点で *.tdbファイルをバックアップから戻さない限り、すべての印刷関連の 設定を再作成する必要がある。

tdbbackupの使用

Sambaは、システム中にある*.tdbファイルをバックアップする、 rootユーザーを手助けする小さなユーティリティを同梱している。もしも引数なしでそれを 動かすと、以下のメッセージが表示される:

root# tdbbackup
 Usage: tdbbackup [options] <fname...>
 
 Version:3.0a
   -h            this help message
   -s suffix     set the backup suffix
   -v            verify mode (restore if corrupt)

以下はprinting.tdbファイルをどのようにバックアップするかの例である:

root# ls
.              browse.dat     locking.tdb     ntdrivers.tdb printing.tdb
..             share_info.tdb connections.tdb messages.tdb  ntforms.tdb
printing.tdbkp unexpected.tdb brlock.tdb      gmon.out      namelist.debug  
ntprinters.tdb sessionid.tdb
 
root# tdbbackup -s .bak printing.tdb
 printing.tdb : 135 records
 
root# ls -l printing.tdb*
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb.bak

Linuxprinting.orgからのCUPSプリントドライバー

CUPSはHP LaserJetタイプのプリンターに対する良いサポートがある。以下のように汎用ドライバーを インストールできる:

root# lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -m laserjet.ppd

-mスイッチは、CUPSが通常/usr/share/cups/model 中に格納する、まだインストールされていないPPDのための標準リポジトリから laserjet.ppdを検索する。代替として、 -P /path/to/your.ppdを使っても良い。

しかし、汎用laserjet.ppdは、各LaserJet五巻も出るの各特別な オプションをサポートしない。すべてのモデルの、一連の最小の共通項が 構成要素である。もしもある理由で、商用のESP Print Pro ドライバーに対してお金を払わなければ ならない場合、最初に見に行く所は、 Linuxprinting Webサイト上にあるデータベースにすべきである。Linuxprinting.orgは、各プリンターに対して 使える最適のドライバーがどれか、ということについて、優れた推奨情報を提供している。 そのデータベースは、foomatic-ripユーティリティの主要な著者でもある、 MandrakesoftのTill Kamppeterの精力的な仕事によって、現在保持されている。

Note

前者のcupsomaticコンセプトは現在新しい優れたものにより置き換えられ、 より強力な foomatic-ripが提供されている。 cupsomaticはもはやメンテナンスされていない。新しいデータベースへの URLは Foomatic-3.0 である。もしもfoomatic-ripにアップグレードする場合、Foomaticで制御 されるプリンター用の、新しい形式のPPDもアップグレードすることも忘れないこと。 foomatic-ripは古いcupsomaticで生成したPPDでは動かない。新しい形式の PPDはAdobe PPDの仕様と100%互換である。これらはまたSambaとcupsaddnmbユーティリティに よってWindowsクライアントのためにドライバーを提供するために、代わりに使われる!

foomatic-rip と Foomaticの説明

最近、ほとんどのLinuxディストリビューションは、(すべてのUNIXとMac OS XとDarwinでも動く) 印刷関連のソフトウェアを作成するために、 Linuxprinting.orgからのユーティリティに 頼っている。このサイトからのユーティリティは、サポートしているすべてのモデル、すべての スプーラ、すべてのOSとすべてのパッケージ形式(それらがないので)に対して、ドライバーとPPDの 簡単な更新が出来る、エンドユーザーにとてもわかりやすいインタフェースを持っている。その 歴史は、数年前にさかのぼる。

最近、Foomaticは、対応プリンターモデルが 1,000を超えるという 驚くべきマイルストーンに到達した。Linuxprinting.orgは、プリンタードライバー、サポートする モデルと、Foomatic データベース中で有効な種々のドライバー/プリンターの組み合わせに対するオプションについての、 すべての重要な要素を保持している。現在、そのデータベース中には、 245のドライバーが存在 する。多くのドライバーは種々のモデルをサポートし、多くのモデルは、異なったドライバーで 動作するかもしれない。これはあなたが選択するものである!

690の完璧なプリンター

現在、690ものドライバーが完全に動作することが分かっている:181はほとんど 完全で、96は 部分的に完全で、46は文鎮(paperweight)である(???)。 これらの大半は、非PostScriptモデルであり(PostScriptプリンターは、CUPSによって、 固有の製造元が提供したWindows PPDを使うことによって、完璧にサポートされる)、多機能 デバイスは、GNU/Linux配下で、スキャンとコピーとFAXが出来ないならば、決して完全に 動くとは見なされないということを心にとめておいておくこと。これは本当に驚くべき 結果である!3年前、数は500以下であり、その時点でのLinuxかUNIX印刷は、現在の品質には 到達していなかった。 At present, there are 690 devices dubbed as working perfectly: 181 are mostly perfect, 96 are partially perfect, and 46 are paperweights. Keeping in mind that most of these are non-PostScript models (PostScript printers are automatically supported by CUPS to perfection by using their own manufacturer-provided Windows PPD), and that a multifunctional device never qualifies as working perfectly if it does not also scan and copy and fax under GNU/Linux then this is a truly astonishing achievement! Three years ago the number was not more than 500, and Linux or UNIX printing at the time wasn't anywhere near the quality it is today.

どのように印刷HOWTOが始まったか

数年前、Grant Taylorが作業を開始した。 現在のLinuxprinting.orgの大元は、彼が書いた最初の Linux Printing HOWTO である。多数のLinuxユーザーと管理者に、この複雑で繊細な設定の最初のステップをガイドする ために提供された、この文書の関連プロジェクトとして(科学者にとって、印刷とは 紙の基盤の上に、インクかトナーの微片による明白なパターンによる構造化した堆積物を 付けたものである)、その時点でのLinux印刷を補う、ハードウェアとドライバーについての 情報集積を行う小さなPostgresデータベースの構築を開始した。このデータベースは、現在に おける、Foomaticの、ツールとデータの集合体のコアコンポーネントになった。その途中で、データを XML表記に変更した。

Foomaticの奇妙な名前

なぜこんな奇妙な名前なのか?2000年の春頃に、これが軌道に乗ったときに、 CUPSは現在よりもかなり知名度が亡く、ほとんどのシステムはLPD、LPRng、か、あるいはPDQを 印刷に使用していた。CUPSはごくわずかの汎用ドライバー(100くらいの少数の異なったプリンター モデルにのみ対応)しか提供できていなかった。デバイス固有のオプションのサポートも出来て いなかった。CUPSは固有の組み込みラスタライズフィルタ(Ghostscript由来の pstoraster)も提供していた。他方、CUPSは、標準化され、きちんと 定義されているPPDファイルを使って、すべての印刷オプションの制御を きちんとサポート出来た。さらに、CUPSは簡単に拡張できるように設計されていた。

Taylorはすでに、より多くのプリンターと、それと共に動くGhostscriptドライバーに ついて、良くできた動作状況一覧を、彼のデータベース中に用意していた。彼のアイデアは、 データベース情報からPPDを作成するためと、CUPSで動作する標準Ghostscriptドライバーを生成する ために、それがうまく動くことを検証することであった。また、それは一石数鳥でもあった:

  • これは、CUPSで有効な現在と将来のすべてのGhostscript フィルタ開発を行う。

  • CUPSユーザーにたくさんの追加プリンターモデルを有効にさせる (しばしば、伝統的なGhostscriptによる印刷は、1つのみが有効であるという理由で)

  • これは、Ghostscriptフィルタを使う事を望んでいる(あるいは 必要としている)ユーザーに、すべての詳細CUPSオプションを提供する(Web インタフェース、GUIドライバーの組み合わせで)

cupsomatic, pdqomatic, lpdomatic, directomatic

CUPSは cupsomatic という名前が付いた、簡単に作成されたフィルタスクリプトを経由して動作する。cupsomaticは Ghostscript経由でprintflieを動かし、必要とされる、どちらかというと複雑なコマンドラインを 自動的に構築する。これは、それが動くようにするために、CUPSシステム中にコピーされる必要が ある。cupsomatic制御がGhostscript病がプロセスを制御する方法を構築するために、CUPS-PPDが 必要である。このPPDはデータベースの内容から直接生成される。CUPSとそれぞれの プリンター/フィルタの組み合わせのために、CUPS-O-Maticという名前の、他のPerlスクリプトが PPDを生成する。これが動作した後、Taylorは2つの他のスプーラのために、類似のことを数日で 実装した。config-generatorスクリプトのために選ばれた名前は、(PDQ用には) PDQ-O-Matic と(推測したとおり、LPD用に) LPD-O-Matic であった。ここでの構成はPPDを使用しなかったが、他のスプーラ固有のファイルは使った。

その年の夏の終わり頃に、Till Kamppeterは 作業をデータベース中に格納し始めた。Kamppeterはその印刷システムをCUPSに変更するために、 新たにMandrakesoftに雇われ、その後 FLTKベースの XPP(CUPS lpコマンドに対するGUI フロントエンド)が出来た。彼は、大量の新しい情報と新しいプリンターを追加した。また、 PPR (ppromatic経由), GNUlpr,と LPRng (存在するlpdomatic経由両方)と スプーラなしの印刷 (directomatic) のような他のスプーラに対するサポートも開発した。

そのため、あなたの質問に答えるために、Foomaticは、 *omaticスクリプトに隠れたコードとデータをすべて上書きする汎用の 名前である。Foomaticは、バージョン2.0.xまで、CUPS用のLinuxprinting.orgのPPDに結合する (ひどい)Perlデータ構造を要求していた。異なったプリンター設定ファイルのように、すべての スプーラに対して異なった*omaticスクリプトがある。

すばらしい統一の達成

これは、Foomatic バージョン 2.9(β)中と安定版3.0としてリリースされたもので すべて変更された。これは現在、すべての*omaticスクリプトの集合として到達して、さらにこれは foomatic-rip と呼ばれている。foomatcic-rip はすべての異なったスプーラと同様によって使われ、それがPPD (オリジナルPostScriptプリンターのPPDとLinuxprinting.orgが作成したもの両方)を読むことが 出来るという理由で、すべてのサポートされているスプーラは突然自由にPPDの機能を使えるように なる。ユーザーはシステムにfoomatic-ripを組み込む必要があるだけである。ユーザー用に、 改良されたメディア対湯とソースのサポートがある。それは、紙のサイズとトレイが簡単に設定 できるものである。

また、新しい世代のLinuxprinting.org PPDは、もはやPerlデータ構造を含まない。もしも、 あなたがディストリビューションメンテナで、以前のバージョンのFoomaticを使用している のであれば、..................しかし、 新しい foomatic-db-engine 経由で新しいバージョンのPPDセットを生成することを覚えておいてほしい! 個々のユーザーは、Foomaticチュートリアル中で概要が説明されている 以下のステップ か、この章によって、使用しているモデルのための、特定の、新しい単一PPDを生成することが 必要である。この新しい開発版は全く驚くべきものである。 Also, the new generation of Linuxprinting.org PPDs no longer contains Perl data structures. If you are a distro maintainer and have used the previous version of Foomatic, you may want to give the new one a spin, but remember to generate a new-version set of PPDs via the new foomatic-db-engine!. Individual users just need to generate a single new PPD specific to their model by following the steps outlined in the Foomatic tutorial or in this chapter. This new development is truly amazing.

foomatic-ripは、異なった文法、オプション、デバイスの選択、あるいは異なる各プリンター またはスプーラのためのフィルタを使うGhostscriptを動かすために必要な、とても巧妙な ラッパーである。同時に、これはプリントキューに関連づけられているPPDを読み、ユーザーの 選択に従って、印刷ジョブを変更する。これを一緒にすると、Adobeのspecに対し、新しい Foomatic PPDは100%準拠となる(ここ怪しい)。Foomaticのコンセプトにおける、いくつかの 革新的な特徴は、ユーザーを驚かせるだろう。これは、多くのプリンターに対する、個別の 紙サイズのサポートや同じジョブ内での、異なったペーパトレイを使う印刷のサポート ができる(両方の場合において、Windowsベースのベンダプリンタードライバーがこれをサポート していなかったとしても)。 foomatic-rip is a very clever wrapper around the need to run Ghostscript with a different syntax, options, device selections, and/or filters for each different printer or spooler. At the same time, it can read the PPD associated with a print queue and modify the print job according to the user selections. Together with this comes the 100% compliance of the new Foomatic PPDs with the Adobe spec. Some innovative features of the Foomatic concept may surprise users. It will support custom paper sizes for many printers and will support printing on media drawn from different paper trays within the same job (in both cases, even where there is no support for this from Windows-based vendor printer drivers).

ドライバー開発の外側

ほとんどのドライバー開発それ自身は、Linuxprinting.org中では発生しない。ドライバーは独立した メンテナによって書かれる。Linuxprinting.orgはすべての情報を蓄え、そのデータベース中に 格納するだけである。さらに、今知られている、任意の最新式(あるいは旧来の)印刷システム 中にたくさんのドライバーを統合する、Foomaticという糊も提供する。

異なったドライバー開発グループについて話すと、仕事のほとんどは、それらのプロジェクトに おいて、現在ほとんど終わっている:

  • Omni IBMによるフリーソフトウェアプロジェクトで、良くできたOS/2時代のプリンター ドライバーの知識を、Linux/UNIXに対する、最新の、モジュラーなユニバーサルドライバー アーキテクチャに変換することを試みている(今だβ)。これは現在437モデルを サポートしている。

  • HPIJS HPによるフリーソフトウェアプロジェクトで、自分自身のモデルの領域における サポートを提供する(とても自然ではあるが、ほとんどの場合の印刷は、完璧なもので、 真の写真品質も提供している)。これは現在369モデルをサポートしている。

  • Gutenprint フリーソフトウェアの取り組みであり、(CUPSの主要開発者としても知られている) Michael Sweetによって開始され、現在驚異的な写真レベルの品質に到達した Robert Krawitzによって指揮されている(多くのエプソンユーザーは、その品質は、 Microsoftプラットフォーム向けのEpsonによって提供されたベンダドライバーよりも 良いと断言している)。現在522モデルをサポートしている。

フォーラム、ダウンロード、チュートリアル、HOWTO(Mac OS Xと商用UNIX用も)

Linuxprinting.orgは現在プリンタードライバーのダウンロードを行うためのとりまとめ窓口である。 プリンター情報を探し、 チュートリアル か、プリンターの問題について、よく知られている フォーラムで解決してみよう。 このフォーラムは、GNU/Linuxユーザーに限ったものではなく、 商用UNIXシステムの管理者も ここに来ていて、相対的に新しい Mac OS Xフォーラム は、ここ数週間で最も利用度の高いフォーラムの一つである。

Linuxprinting.orgとGhostscriptを囲むFoomaticドライバーラッパはすべての重要な ディストリビューション上で印刷のための標準ツール(tool-chain)である。それらのほとんどは、 基盤としてCUPSを使っている。ここ数年の間、ほとんどのプリンターに関するデータは、 Kamppeterによって追加され、多くの追加コードが、SuSE、Red Hat、Conectiva、Debianや その他の技術者から寄贈された。ベンダ中立はFoomaticプロジェクトの重要なゴールである。 MandrakeとConectivaは統合されて現在Mandrivaと呼ばれている。

Note

MandrakesoftのTill Kamppeterは彼の空き時間にLinuxprinting.orgとFoomaticをメンテナンス するという優れた仕事を行っている。そのため、それをしばしば使うのであれば、 あなたが感謝しているという事を送ってほしい。

Foomaticデータベースが生成したPPD

Foomaticデータベースはそれ自身だけで驚くべき工夫の1つである。プリンターとドライバー情報を 保存しているだけではなく、その内部XMLベースのデータベースから、その場でPPDファイルを 生成できる。それらPPDがAdobe仕様のPPDにモデル化される間、Linuxprinting.org/Foomatic-PPDは 普通ではPostScriptプリンターを制御できない。それらは、Eposn Stylus inkjet、HP Photosmart、 あるいは持っているプリンター上で鳴らすことや吹くことが出来る、すべてのベルと笛を 記述するのに使われる。その主要仕掛けは小さな追加の1行であり、PPDの仕様によって予測された ものではなく、*cupsFilterというキーワードで始まる。これはCUPS デーモンに、どのようにPostScript印刷ファイルを処理するかを告げる(旧形式のFoomatic-PPDは cupsomaticフィルタスクリプトと名前が付けられ、新しい形式のPPDはfoomatic-ripと呼ばれる)。 このフィルタスクリプトはホストシステム上でGhostscriptを呼び出し(推奨する別バージョンは ESP Ghostscript)、レンダリング作業を行う。foomatic-ripは、 PostScriptジョブを、対象デバイス用のラスタフォーマットに変換する、Ghostscriptから 問い合わせを行う、フィルタか内部デバイス設定がどれかを知っている。この、 非PostScriptプリンターのオプションを記述するPPDの使用法は、CUPS開発者の発明である。 その結果は簡単である。GUIツール (すばらしいKDEのkprinter か、GNOMEのgtklp xppとCUPSのWebサイト) はPPDを読み取り、その情報を直感的な面ふー選択として、ユーザーに対し、有効な設定を 提供するための情報として使う。

foomatic-ripとFoomatic PPDのダウンロードとインストール

以下はfoomati-ripで制御される、CUPSでのLaserJet 4Plus互換プリンターインストール手順である (SuSE、UnitedLinuxとMandrakeにおける最新ディストリビューションではFoomatic-PPDの完全な パッケージとfoomatic-ripユーティリティを同梱している。 Linuxprinting.orgに直接行くと最新のドライバー/PPDファイルを入手できる)。

  • inuxprinting.orgのプリンター一覧ページ をブラウザーで開く。

  • データベース 中の完全なプリンター一覧をチェックする。

  • 使用しているモデルを選択しそのリンクをクリックする。

  • このモデルに対して動作可能なすべてのドライバーの一覧ページが表示される (すべてのプリンターに、必ず1つ推奨ドライバーがある。まず初めにそれを試す)。

  • この例の場合(HP LaserJet 4 Plus)、 HP-LaserJet 4 Plus という既定値のドライバーになる。

  • 推奨ドライバーはljet4である。

  • いくつかのリンクがここで提供されている。Linuxprinting.orgに 不慣れならば、それらすべてを見てみるべきである。

  • ljet4 に対するデータベースページへのリンクがある。ドライバーのページ上には、種々の有効な スプーラでそのドライバーをどのように使うかについての重要かつ詳細な情報がある。

  • 他のリンクは、ドライバーの著者のホームページを示しているだろう。

  • CUPS に関するセットアップ手順のヒントを提供する重要なリンクがある: PDQ; LPD, LPRng, と GNUlpr); 同様にPPR またはspoolerless printing.

  • このリンク経由でブラウザー中でPPDを閲覧できる: http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1

  • 最も重要なことは、 PPD を生成しダウンロードできると言うことである。

  • PPDは使用するモデルとドライバーが使うときに必要なすべての情報を 含む。一度インストールすると、これはユーザーに対して透過的に動作する。その後は Webベースのメニューか、印刷ダイアログGUIか、コマンドラインから、解像度、 紙のサイズなどのみを指定する必要がある。

  • もしもドライバー ページ で作業を終わるならば、PPD-O-MaticオンラインPPDジェネレータ プログラムを使う選択が出来る。

  • 正確なモデルを選択し、DownloadDisplay PPD fileのどちらかをチェックし、 Generate PPD fileをクリックする。

  • もしもブラウザービューからPPDファイルをセーブした場合、 カットアンドペーストは使わないこと(行末やタブ情報を欠落する可能性があるため、 PPDファイルが壊れてしまう可能性が高くなる)。代わりに、 ブラウザーメニュー中のファイル名を指定して保存を 使う(WebページからのDownloadオプションを使うのが 最も良い)。

  • 各ドライバーページ上にある、他の興味深い部分は、 Show execution detailsである。もしも使用している プリンターモデルを指定し、そのボタンをクリックすると、完全なGhostscript コマンドラインが表示され、そのドライバーとプリンターモデルの組み合わせに対して 有効なすべてのオプションをエミュレートする。これは それを行うことでGhostscriptを学ぶ優れた方法である。 また、忌々しい印刷スクリプトのための、優れたコマンドラインを再構築することを 必要とするすべての経験者のための、優れた一覧表(cheat sheet)でもある。 しかし、それは正確な文法を思い出すことはできない。

  • 時々、Linuxprinting.orgを見ている間に、ハードディスクの /path/to/my-printer.ppdのような、適当な位置にPPDを セーブする(CUPS Webインタフェースの助けを借りて使用しているプリンターを インストールすることを好むならば、PPDを /usr/share/cups/model/というパスにセーブし、 cupsdを再起動する)。

  • 次に、以下のようなコマンドラインでプリンターをインストールする:

    	root# lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E \
    		-P path/to/my-printer.ppd
    	
  • Linuxprinting.orgからの、新しい形式のFoomatic-PPDs 用には、foomatic-ripと呼ばれる特別なCUPSフィルタも必要である。

  • foomatic-rip Perlスクリプトそれ自身もいくつか興味深い 読み物 を作る。なぜならば、Kamppeterによるインラインコメントによってよく文書化されて いるからである(非Perlハッカーが、それを読むことで印刷について多少勉強できる)。

  • /usr/lib/cups/filter/foomatic-ripか 他の$pathのどちらかにfoomatic-ripを保存する(そして、それを誰でも実行できる ようにするのを忘れないこと)。繰り返すが、コピーアンドペーストでセーブしない こと。適切なリンクを使うか、ブラウザー中の ファイル名を指定して保存を使うこと。

  • もしも固有の$PATHにfoomatic-ripを保存したならば、シンボリックリンクを作る:

    	root# cd /usr/lib/cups/filter/ ; ln -s `which foomatic-rip'
    	

    CUPSはcupsdを再起動後起動時に有効なこの新しいフィルタを検索する。

一度Foomatic PPDで設定された印刷キューに印刷すると、CUPSは適切なコマンドを挿入し、 結果のPostScriptファイル中にコメントを挿入する。foomatic-ripはそれを読み、それらに 対して処理を行うことが出来、さらに、ジョブファイル中に埋め込まれている、特別にエンコード されたFoomaticコメントのいくつかを使う。それらは順に(ユーザーにとっては透過的に) どのように結果のラスタデータを見えるようにすべきかと、どのプリンターコマンドを、 データストリーム中に埋め込むかを、正確に、プリンタードライバーに指示する、複雑なGhostscript コマンドを組み立てるのに使われる。以下が必要である:

  • foomatic+なにか PPD しかし、 CUPSで印刷するためには、これだけでは不十分である(これは単に 1つの重要な要素である)。

  • /usr/lib/cups/filters/中の foomatic-ripフィルタスクリプト(Perl)。

  • foomatic-ripを動かすためのPerl

  • 使用しているプリンターが受け取れる形に適合したラスタデータを 生成するためのGhostscript(これが主要な仕事を行うため、PPD/foomatic-ripの組で 制御される)

  • Ghostscriptは(ドライバー/モデルに依存するが)使用しているモデルに 対する選択されたドライバーを表す特定のデバイスに対するサポートを 含んでいなければならない(gs -hによって 確認できる)。

CUPSによるページの課金

しばしば、日、週、月単位に、一定のページ数かデータ量を超えて、Sambaユーザー(すなわち Windowsクライアント)が、印刷が出来ないようにする、印刷quotaに関連する質問がある。 この機能は、使用している実際の印刷サブシステムに依存する。Sambaはクライアントから 常にジョブファイルを受け取り(フィルタされるか否か、この印刷 サブシステムに渡す。

もちろん、使用している人固有のスクリプトで、これをハックすることは出来る。しかし、 CUPSがある。CUPSは、ジョブのサイズやページ数やその両方をベースとできるquotaを サポートし、それを行いたいときにはいつでも橋渡しをすることが出来る。

Quotasの設定

CUPSで印刷quotaをrootがどのように設定するかのコマンド例であり、存在するプリンターが quotaprinterであることを仮定している:

root# lpadmin -p quotaprinter -o job-quota-period=604800 \
	-o job-k-limit=1024 -o job-page-limit=100

これは個々ののユーザーに対して、604800秒(=一週間)で、100ページまたはデータが1024KBでの 制限を行う(どちらか小さい方)。

正しいあるいは不正な課金

CUPSで正しく計測するために、印刷ファイルはCUPSpstopsフィルタに送られる必要がある; そうでない場合、ダミーのカウント1を使う。いくつかの印刷ファイルは それに送られないが(例えば画像ファイル)、それらはほとんど1ページのジョブである。 これはまた、それらのファイルをraw(すなわちそれらに何も変更をせず、 フィルタリングもしない)すぷーすする、クライアントコンピュータとCUPS/Samba上で動いている、 対象プリンター用のプロプラエティなドライバーは、1ページとして計測するということでもある!

課金を行える機会を得るために、それらのクライアントからPostScriptで送る必要がある (すなわち、そこでPostScriptドライバーを動かす)。もしも、プリンターが非PostScriptモデル ならば、対象のプリンター用に印刷可能な形式にファイルを変換するためのジョブを、CUPSで 行わせる必要がある。Linuxprinting.orgにはドライバーの リストがある。

Windowsクライアント用のAdobeとCUPS PostScriptドライバー

CUPS 1.1.16より前は、Windowsクライアント上でAdobe PostScriptドライバーを使うことが出来る のみであった。このドライバーの出力は、CUPS/Sambaサイド上のpstops フィルタに常時渡されるわけではなく、そのため、正しく計測出来なかった(その理由は、 それがしばしば使用されるPPDに依存するからであり、CUPSにpstopsを スキップさせる真のPostScriptの直前にPJL-ヘッダーが書かれ、直接pstoraster ステージに行くからである)。

CUPS 1.1.16とそれ以降のリリースから、Windows NT/200x/XPクライアント用のCUPS PostScript ドライバーを使うことが出来る(これはcups-samba-1.1.16.tar.gzという パッケージとしてhttp://www.cups.org/のダウンロード領域中に タグされている)。これはWindows 9x/Meクライアントでは動かないが 以下は保証される:

  • PJL-ヘッダーを書かない。

  • 固有の意味を持つドライバーPPD中に名前があるすべての PJL-オプションを、引き続き読み取りサポートする。

  • CUPS/Sambaサーバー上のpstopsフィルタに ファイルが渡される。

  • 印刷ファイルのページカウントが正しくなる。

この組み合わせによる設定についてのより詳細は、cupsaddsmbのマニュアル ページで読むことが出来る(これはCUPSがインストールされている所でのみに存在し1.1.16 以降で有効である)。

page_logファイルの形式

ジョブの各ページに対するpage_log中のCUPSログの項目は以下の通り:

  • プリンター名(Printer name)

  • ユーザー名(User name)

  • ジョブID(Job ID)

  • 印刷時間(Time of printing)

  • ページ数(Page number)

  • 印刷部数(Number of copies)

  • 課金情報文字列(A billing information string) (オプション)

  • ジョブを送り出したホスト(The host that sent the job) (バージョン1.1.19以降)

以下は項目を含む形式の図示を行うための、CUPSサーバーのpage_logファイル から抜き出したものである:

tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13
Dig9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33

これはジョブID401で、tec_IS2027上で ユーザーkurtによって印刷され、64ページのジョブで三部印刷され、 #marketingに請求が行き、IPアドレス10.160.50.13. から送られた。次のジョブはIDが402であり、ユーザー bossによって、10.160.51.33というIP アドレスから送られ、1ページ、440部印刷され、finance-depに 請求が行った。

存在する欠点

何か問題か欠点がこのquotaシステムにあるだろうか?

  • The ones named above (プリンターハードウェアが壊れたなどの場合に 間違ってジョブが記録される)。

  • 実際、CUPSは、物理的にプリンターデバイスから出て行った紙の代わりに ソフトウェアで処理されたジョブのページをカウントする (すなわち、RIPを使って)。そのため、もしも1000ページ印刷中に五枚目でジャムが 発生し、ジョブがプリンターによって中断した場合、そのジョブに対しては1000ページ 印刷していると引き続き表示される。

  • すべてのquotaはすべてのユーザーに対して同じであり(事務員よりも 管理者の方により大きなquotaを割り当てるような自由度がない)、グループの サポートもない。

  • 現在のバランス(current balance??)と、現在のquotaに関する 使い切った分を読む方法がない。

  • quotaが100で99まで使ったユーザーは、まだ1000ページのジョブを 送信し印刷できる。

  • quotaの制限に引っかかっりジョブが拒否されたユーザーは、 CUPSからclient-error-not-possibleという意味のあるメッセージを 受け取れない。

将来の構想

これは現在使えるものの中で最も優れたシステムであり、CUPS 1.2にむけて大量の改善が 行われている:

  • ページカウントはバックエンドに移行する(それらはプリンターと 直接通信し、実際の印刷処理に計数が同期する)。そのため、5枚目でジャムが発生した 場合、カウントを中断する)

  • quotaはより自由度が向上する。

  • おそらく前もって、使用しているアカウントについてユーザーが 問い合わせる機能をサポートする。

  • おそらく、このトピックの周辺にあるような他のツールのいくつかを サポートするだろう。

他のアカウントツール

使用できる他のアカウントツールは以下のものが含まれる:PrintAnalyzer, pyKota, printbill, LogReport。 これらのツールについての詳細はググること。

追加の材料

PPDを使わない、それに関係する印刷キューは、 rawプリンターで、スプーラが受け取ったすべてのファイルはそのまま直接 送られる。例外は、パススルー機能を有効とすることが必要とされる application/octet-streamファイルタイプである。raw キューはフィルタリングを全く行わない。それはCUPSバックエンドに直接送られる。この バックエンドはデバイスにデータを送る事に責任がある(device URIとして、 例えばlpd://, socket://, smb://, ipp://, http://, parallel:/, serial:/, usb:/ など)。

cupsomatic/FoomaticはネイティブなCUPSドライバーではなく、CUPSには 同梱されない。これらはLinuxprinting.orgで開発されたサードパーティアドオンである。 同様に、すべてのモデルで、CUPS経由でも動くようにさせる、優れたハックであり( 伝統的なスプーラで、Ghostscriptドライバー/フィルタによって動作する)、他のスプーラでの 品質と(良くも悪くも)同じである。cupsomaticは、単なる媒体 である。すなわち、通常ネイティブなCUPSpstorasterフィルタが 起動される、CUPSフィルタリングチェーン中のそのステージで、Ghostscriptコマンドラインを 実行する。cupsomaticpstorasterを バイパスし、CUPSからの印刷ファイルを横取りし、Ghostscriptにリダイレクトする。CUPSは、 関連するcupsomatic/foomatic-PPDが以下のように指定するのでこれを許可する:

*cupsFilter:  "application/vnd.cups-postscript 0 cupsomatic"

この行は、かつてMIMEタイプ application/vnd.cups-postscriptにうまく変換した cupsomaticに対してファイルを扱わせることをCUPSに指示する。 この変換は、その場で、/etc/cups/mime.types中の変更に一致する、 application/octet-streamに自動タイプされた Windowsから来たジョブに対しては起こらない。

CUPSは、関連するフィルタリング機能を含め、広範囲に設定が出来、自由度が高い。 いくつかの状況に置ける他の問題は、/etc/cups/mime.typesに 以下のようなエントリがある場合である:

application/postscript           application/vnd.cups-raw  0  -
application/vnd.cups-postscript  application/vnd.cups-raw  0  -

これは、すべてのPostScriptファイルをフィルタされないようにする(というよりは、 -で指定された仮想のnullfilterに渡す)。これは、 PostScriptプリンターのみに便利である。もしも、非PostScriptプリンターにPostScriptコードを 印刷したい場合(ASCCテキスト印刷のサポートを提供している)、以下のエントリは便利である:

*/*           application/vnd.cups-raw  0  -

そして、さらなる処理をせずにすべてのファイルを効率的に バックエンドに送るだろう。

以下のエントリを使用しても良い:

application/vnd.cups-postscript application/vnd.cups-raw 0 \
	my_PJL_stripping_filter

PostScriptを解析する(シェルスクリプトであり得る) my_PJL_stripping_filterを書き、望まないPJLを取り除く 必要があるかもしれない。これはCUPSフィルタデザインに従う必要がある(主に、printername, job-id,username, jobtitle, copies, print optionsと可能ならばファイル名 パラメーターを受け渡す)。これは/usr/lib/cups/filters/中に 誰でも実行できるようにインストールされ、MIMEタイプ application/vnd.cups-postscriptが来た場合には、 CUPSによって呼び出される。

CUPSは-o job-hold-until=indefiniteを扱える。これは、キュー中に ジョブを保存しておく。プリンター操作者によって手動で解放されるときにのみ印刷される。 これは、誰も直接アクセスできないいくつかの大きなマシン上で、数百人のユーザーのジョブを、 少数のオペレータが管理する、多くの集中印刷センタからの要求である(これは、ダイレクト メール発送のためなどに要求される10000ページのジョブを動かす前に、オペレータが 適切な紙を設置する必要がしばしばある場合など)。

CUPSスプールフィルタの自動削除または保存

Sambaは2つのスプールディレクトリ経由で印刷ファイルを渡す。1つはSambaによって管理される 入力ディレクトリである(smb.conf中の[printers]セクション中の path = /var/spool/sambaディレクティブで設定される)。 もう1つは、UNIX印刷システムのスプールディレクトリである。CUPS用には、通常それは /var/spool/cups/であり、cupsd.conf中の ディレクティブRequestRoot /var/spool/cupsによって設定される。

CUPS構成の設定の説明

CUPS設定ファイルcupsd.conf中で設定される、いくつかの 重要なパラメーターは以下の通り:

PreserveJobHistory Yes

これは、cupsdに、いくつかのジョブの詳細を保存させる(すなわち、c12345,c12346の ように、旧形式であるBSD-LPD制御ファイルのような同等のジョブとして処理し、 CUPSスプールディレクトリ中のファイルに)。既定値はYesに 設定される。

PreserveJobFiles Yes

これは、ジョブファイルそれ自身をcupsdが保存するようにさせる(d12345,d12346 などで、CUPSスプールディレクトリ中にファイルされる)。CUPSの既定値は Noである。

MaxJobs 500

このディレクティブは、メモリ中に保持されるジョブの最大数を制御する。この 制限値にジョブが到達すると、新しいもののために、最も古いものが自動的にシステム からパージされる。もしも既存のすべてのジョブが、引き続きペンディングか アクティブならば、新しいジョブは拒否される。値を0に設定するとこの機能が無効に なる。既定値の設定は0である。

(MaxJobsPerUserMaxJobsPerPrinterという 追加の設定もある)。

準備

すべてをきちんと動くようにするために、以下の3つを行う必要がある:

  • libcupsを指定してSambaのsmbdをコンパイルする (Linuxではldd `which smbd'を動かすことで確認)。

  • Sambaのsmb.confprinting = cups を設定する。

  • Sambaのsmb.confprintcap = cups も設定する。

Note

この場合、他の手動で設定する印刷関係のコマンド( print command, lpq command, lprm command, lppause command, と lpresume commandのようなもの)は無視され、通常印刷に関しては なんの影響も与えなくなる。

手動の設定

すべてを手動で行いたいならば、printing = cupsprinting = bsdに置き換える。そうすると手動で設定した コマンドが動作し(テストはしていないが)、 print command = lp -d %P %s; rm %sが期待通りの 事を行うだろう。

Windowsに接続された印刷へのCUPSからの印刷

時々、SambaからWindowsに接続されたプリンター 印刷をするにはどうしたらいいか、という質問が来ることがある。通常Windowsホストから プリンターへのローカル接続はUSBまたはパラレルケーブルで行われるが、これはSambaにとっては 重要ではない。ここから、Windowsホストに対してSMB接続でオープンする事のみが必要である。 もちろん、プリンターはまず共有されねばならない。今まで学習してきたように、CUPSはプリンターや 他のサービスと通信するバックエンドを使える。Windowsで共有された プリンターと通信するには、(驚くべき事だが)smbバックエンドを使う必要が ある。まずsmbファイルをそこで捜す必要がある。それは smbspoolへのシンボリックリンクであり、ファイルは存在して実行可能で なければならない:

root# ls -l /usr/lib/cups/backend/
total 253
drwxr-xr-x    3 root   root     720 Apr 30 19:04 .
drwxr-xr-x    6 root   root     125 Dec 19 17:13 ..
-rwxr-xr-x    1 root   root   10692 Feb 16 21:29 canon
-rwxr-xr-x    1 root   root   10692 Feb 16 21:29 epson
lrwxrwxrwx    1 root   root       3 Apr 17 22:50 http -> ipp
-rwxr-xr-x    1 root   root   17316 Apr 17 22:50 ipp
-rwxr-xr-x    1 root   root   15420 Apr 20 17:01 lpd
-rwxr-xr-x    1 root   root    8656 Apr 20 17:01 parallel
-rwxr-xr-x    1 root   root    2162 Mar 31 23:15 pdfdistiller
lrwxrwxrwx    1 root   root      25 Apr 30 19:04 ptal -> /usr/sbin/ptal-cups
-rwxr-xr-x    1 root   root    6284 Apr 20 17:01 scsi
lrwxrwxrwx    1 root   root      17 Apr  2 03:11 smb -> /usr/bin/smbspool
-rwxr-xr-x    1 root   root    7912 Apr 20 17:01 socket
-rwxr-xr-x    1 root   root    9012 Apr 20 17:01 usb

root# ls -l `which smbspool`
-rwxr-xr-x    1 root   root  563245 Dec 28 14:49 /usr/bin/smbspool

もしもシンボリックリンクがなければそれを作成する:

root# ln -s `which smbspool` /usr/lib/cups/backend/smb

smbspoolは、CUPS関係者のMike Sweetによって書かれた。これは、Sambaに 同梱されている。これはまた、CUPS以外の印刷サブシステムで使われ、Windowsプリンター共有の ためにジョブをスプールする。CUPS上でwinprinterプリンターを 設定するためには、そのためのドライバーが必要である。本質的に、これは、プリンターが理解できる (Windowsホストは、送ったファイルを形式変換する能力はない)ファイル形式用に、CUPS/Samba ホスト上で、印刷データを変換することを意味する。これはまた、使用しているSamba/CUPS ホストに直接繋がっている場合、プリンターに対して印刷出来るべきであると言うことを意味する。 トラブルシューティングのために、一連の手続きのその部分が順番になっている場合、 これが、何をすべきかを決定すべきかということである。次に、Windowsホストに対する 接続/認証を修正することなどを行う。

バックエンドがCUPSのsmbを使うプリンターをインストールするために、 以下のコマンドを使う:

root# lpadmin -p winprinter -v smb://WINDOWSNETBIOSNAME/printersharename \
  -P /path/to/PPD

PPDは、そのターゲットモデルのために、印刷データを生成するために、直接CUPSを管理する必要が ある。PostScriptプリンターのためには、Windows NT PostScriptドライバーを使うPPDを使う。しかし、 パスワードがないとプリンターにアクセスできない場合、一体何が出来るだろうか?あるいは、もしも プリンターのホストが他のワークグループのだった場合は?これには以下の方策がある: 以下のように、smb://デバイスURIの一部として、要求されたパラメーターを 含めることが出来る:

  • smb://WORKGROUP/WINDOWSNETBIOSNAME/printersharename

  • smb://username:password@WORKGROUP/WINDOWSNETBIOSNAME/printersharename

  • smb://username:password@WINDOWSNETBIOSNAME/printersharename

ログファイルに書かれる前に、ユーザー名とパスワードが削除されたとしても、デバイスURLは Sambaサーバー上のプロセス一覧で見えてしまうことに注意(すなわち、誰かが、Linux上で ps -auxコマンドを使うと)。これは、本質的に脆弱性のあるオプション である。しかし、これが唯一の解である。パスワードを保護したい場合、これを使わないこと。 パスワードを要求しないプリンターの共有の方が優れている!印刷は、NetBIOS名前解決が起動し、 動作している時にのみ動く。これはCUPSの機能であり、smbdを動かす必要はないことに注意。

より詳細なCUPSフィルタリングチェーン

フィルタリングチェーン1cupsomaticを使うフィルタリングチェーン中のダイアグラムは、 どのようにCUPSが印刷ジョブを扱うかを示している。

Figure 22.17. フィルタリングチェーン1

フィルタリングチェーン1

Figure 22.18. cupsomaticを使うフィルタリングチェーン

cupsomaticを使うフィルタリングチェーン

よくあるエラー

Windows 9x/Meクライアントがドライバーをインストール出来ない

Windows 9x/Me用クライアント用には、最大8文字までのプリンター名を必要とする (あるいは、8文字に3文字の拡張子)。そうでないと、 Sambaからそれらをダウンロードするときに、ドライバーファイルが転送できない。

cupsaddsmbが、無限にrootパスワードを問い合わせてくる

security = userを設定したか? Sambaアカウントのrootとしてsmbpasswdを使ったか? アカウントを作成するために、smbpasswd -a rootを使い、 最初の質問にパスワードを入れる。あるいは、Enterを二回入力することで、 ループを終了する(パスワードを入力しないで)。

もしも、エラーがTree connect failed: NT_STATUS_BAD_NETWORK_NAME ならば、/etc/samba/driversディレクトリを作成するのを忘れている。

cupsaddsmbrpcclient addriverがエラーを出す

もしもcupsaddsmbrpcclient addriverが、 WERR_BAD_PASSWORDというエラーメッセージを出す場合は、 the previous common errorを参照すること。

cupsaddsmbのエラー

cupsaddsmbを使うと、PPDが存在する間、 No PPD file for printer...というメッセージが出る。 この問題の理由は?

CUPS上でプリンター共有を有効にしていないだろうか?これは、 cupsaddsmbが動いているホストからのアクセスを拒否する、 CUPSサーバーのcupsd.conf中に、 <Location /printers>....</Location> があるということである。cupsaddsmbをリモートで使っているか、 -hパラメーターを付けて: cupsaddsmb -H sambaserver -h cupsserver -v printername として使っている場合、これは問題となりえる

cupsd.conf中のTempDir ディレクティブが正しい値に設定されているだろうか?またそれは書き込み可能だろうか?

クライアントがSambaプリンターに接続できない

Sambaの観点からどのユーザーであるかを、smbstatusを 使って調べる。[print$]共有に対して書き込み許可が あるだろうか?

Windows 200x/Xpからの新しいアカウント再接続のトラブル

ひとたび間違ったユーザー(たとえば、map to guest = bad user を設定した場合、しばしば発生するnobodyなど)で接続すると、Windows エクスプローラーは異なったユーザーで再度接続する試みを受け付けない。Sambaに対しては全くデータ 転送が出来ないが、Sambaがアクセスを拒否したと考えられる不可解なメッセージが表示され 続ける。有効な接続の状態をsmbstatusで確認すること。そして、当該の プロセス(PID)をKillする。まだ再接続は出来なく、接続しようとすると、 You can't connect with a second account from the same machine というメッセージがすぐに出る。再説俗を試みても、、まだ1バイトもSambaには届かない (ログを見ること。etherealを使う)。Windows上のすべてのエクスプローラーを 閉じる。 これは確立した接続としてメモリ中にキャッシュされたものを、Windowsに 捨てさせる。次に正しいユーザーで接続する。一番良い方法は、DOSターミナルウィンドウを 使い、最初に net use z: \\GANDALF\print$ /user:rootを行う。 異なったアカウントで接続されたと言うことを、smbstatusで確認する。 この後、プリンターフォルダーを開き(Sambaサーバー上の ネットワークコンピュータで)、質問中のプリンター上で右クリックし、 接続....を選択する。

間違ったユーザーでSambaサーバーに接続されるのを防ぐ

nobodyとして接続されていることをsmbstatus で確認するが、 本当はrootかprinter adminにしたい。これは、おそらく、正しくないユーザー名(たぶん 何らかのミス)を指定した時に、黙ってguest accountとする、 map to guest = bad userのせいであろう。 これを防ぐためには、map to guestを取り除く。

AdobeドライバーからCUPSドライバーにアップグレードする

この情報は、Microsoft Windows NT/200x/XPクライアント上で、AdobeドライバーからCUPSドライバーに アップグレードした時、それに関連した問題の体験を、メーリングリスト上に投稿されたもの によっている。

最初に、すべての古い、Adobeが使っているプリンターを削除する。次に、すべとの古い Adobeドライバーを削除する(Windows 200x/XP上では、プリンターフォルダーの 背景部分で右クリックし、Server Properties...を選択し、 ドライバータブを選択し、ここで削除する)。

PDCであるSambaサーバー上でcupsaddsmbが使えない

そのままのrootユーザー名を使っていないか?以下の方法を 試してみよう: cupsaddsmb -U DOMAINNAME\\root -v printername> (2つのバックスラッシュ:最初のものは二番目のものをエスケープ する事に注意)。

削除されたWindows 200xプリンタードライバーが引き続き表示されている

クライアント上のプリンターの削除は、ドライバーも一緒に削除はしない (それを確かめるために、プリンターフォルダーの白い背景部分で 右クリックし、サーバーのプロパティを選択し、 ドライバータブをクリックする)。これら同じ古いドライバーは、 同じ名前でプリンターをインストールする時に再度使われる。もしも、新しいドライバーに アップデートしたい場合は、古いものを最初に削除する。削除は、同じドライバーを使う他の プリンターが無い場合にのみ可能である。

Windows 200x/XP ローカルセキュリティポリシー

ローカルセキュリティポリシーは、未署名のドライバーのインストールを許可しないようにも できる。ローカルセキュリティポリシーは全くプリンタードライバーの インストールを許可しないようにしてもよい。

Administratorはすべてのローカルユーザーに対してプリンターをインストールできない

Windows XPはユーザー単位にSMBプリンターを扱うことが出来る。 これは、すべてのユーザーは自分自身でプリンターをインストールする必要があることを意味する。 すべてのユーザーに対してプリンターを有効にするためには、Windows XPにおける内蔵IPP クライアントの機能を使う事になるかもしれない。 http://cupsserver:631/printers/printernameという印刷パスで プリンターを追加する。これについては引き続き調査中である。おそらく、すべてのユーザーに対して 自動的にプリンターのインストールが出来るログオンスクリプトかもしれない。

NTクライアント上での印刷の変更、機能の通知

印刷の変更のために、NT++クライアント上でその機能に通知する。これらは 最初にサーバーサービスを動かす必要がある(XP中では File & Print Sharing for MS Networksに名前が変わっている)。

Windows XP SP1

Windows XP SP1では、ポイントアンドプリントの制限ポリシーが導入された(この制限は、 AdministratorPower Userグループのユーザーには適用されない)。 グループポリシーオブジェクトエディター中で、 ユーザーの設定 -> 管理テンプレート -> コントロールパネル -> プリンターに 行く。ポリシーは自動的に有効に設定され、 ユーザーはそのフォレスト中のマシンに対してのみポイントアンドプリントが 使える。おそらく、無効か、ドライバーのダウンロードをSambaから出来るように、 ユーザーはそれらのサーバーに対してのみポイントアンドプリントが使える それを変更する必要がある。

Windows 200x/XP上ですべてのユーザーが印刷オプションを設定出来ない

何をしているのだろうか?間違っているに違いない(しかし、これを発見するのは容易では ない)。すべてを設定するように見えるダイアログを表示するための、 3つの異なった方法がある。それら3つのダイアログは、同じように見える が、そのうちの1つのみが意図しているものである。これをすべてのユーザーに対して行うために、 AdministratorかPrint Administratorである必要がある。XP上でどのようにやるかは以下の通り:

  1. 最初の間違った方法:

    1. Printersフォルダーを開く。

    2. プリンター(cupshost上のremoteprinter) を右クリックし、コンテキストメニュー 印刷のプリファレンスを選択する。

    3. 細かくこのダイアログを見、なりが見えるかを覚えておく。

  2. 二番目の間違った方法:

    1. プリンターフォルダーを開く

    2. プリンター(cupshost上のremoteprinter) を右クリックし、コンテキストメニュープロパティ を選択する。

    3. 全般タブをクリックする。

    4. 印刷のプリファレンスボタンを クリックする。

    5. 新しいダイアログが開く。このダイアログを開いたままにし、 親のダイアログに戻る。

  3. 三番目の正しい方法:

    1. プリンターフォルダーを開く。

    2. プリンター(cupshost上のremoteprinter) を右クリックし、コンテキストメニュープロパティ を選択する。

    3. 詳細タブをクリックする (もしもすべてが灰色になっていて入力できないならば、 十分な権限を持つユーザーとしてログインしていない)。

    4. プリンターの既定値ボタンを クリックする

    5. 2つの新しいタブのどちらかで、 詳細ボタンをクリックする。

    6. 新しいダイアログが開く。これを、 B.5 または "A.3"で同様のものと比べてみる。

違いがわかるだろうか?私にはわからない。しかし、C.1. から C.6.の手順で 到達した最後のもののみ、任意の設定を恒久的に保存し、新しいユーザーの既定値となる。もしも、 すべてのユーザーに同じ既定値を設定したいならば、これらのステップを as Administrator(smb.conf中でprinter admin であるもの)で、クライアントが、(クライアントが、以下の手順Aまたは B)によって、各固有の、ユーザー単位の既定値を 設定出来る)ドライバーをダウンロードする前に行う必要がある。

Windowsクライアント上でのドライバー設定における、多くに共通する失敗

Optimize for Speedを使わずに、代わりに、 Optimize for Portabilityを使う(Adobe PSドライバーの場合)。 Page Independence: Noを使わない。常時、 Page Independence: Yesを使う(Windows NT/200x/XP用の、 Microsoft PDドライバーとCUPS PSドライバー)。もしもフォントに問題がある場合には、 Download as Softfont into printerを使う(Adobe PS ドライバーの場合)。TrueType Download Optionsオプション用に、 Outlineを選択する。もしも、非PSプリンターでトラブルがあるか、 選択できる場合はPostScript Level 2を使う。

cupsaddsmbが、新しくインストールしたプリンターで動かない

以下と同様: cupsaddsmbの最後のコマンドが完全に終わっていない。もしも、 cmd = setdriver printername printernameの結果が NT_STATUS_UNSUCCESSFULの場合、おそらくプリンターがまだSambaによって認識されていない。 ネットワークコンピュータ中に表示されているだろうか? rpcclient hostname -c `enumprinters'で表示されるだろうか? smbdを再起動(か、smbstatusで一覧表示されるすべてのプロセスに対して kill -HUPを行う)し、再度試してみる。

/var/spool/samba/のアクセス許可が、再起動後毎回リセットされる

同じ位置へのCUPSスプールディレクトリの設定で、以前に何か問題が起きなかったか? (cupsd.conf中のRequestRoot /var/spool/samba/か、 その逆:[printers]セクション中で、 /var/spool/cups/path>として設定しているか)? これらは異なってなければならないcupsd.conf 中のRequestRoot /var/spool/cups/smb.conf[printers]セクション中の path = /var/spool/sambaを設定する。それ以外は、 cupsdは再起動後毎回そのスプールディレクトリのアクセス許可を整理するので、印刷は確実に うまくいかない。

lpという名前の印刷キューが印刷ジョブを間違って扱ってしまう

この場合、lpという名前の印刷キューが、間欠的にジョブを取りこぼし、 送られたものとは完全に違うものを出力する。

プリンターに対してlpという名前を付けるのは好ましくない。これは、伝統的な UNIXにおける既定値のプリンターである。CUPSは暗黙のクラスを自動的に作成する事を行うように 設定されているかもしれない。これは、デバイスをプールするために同じ名前のすべてのプリンターを グループ化するためと、ラウンドロビン方式でジョブのロードバランスを取るということである。 誰かがlpという名前のプリンターを持っている場合にもこれがあり得る。その人の ジョブを受け取り、無意識にその人のデバイスに自分のジョブを送っているかもしれない。 プリンター名に対して厳密の制御をするためには、巨大なネットワーク環境において起こるかも しれない事に対する、より良い制御を行う、BrowseShortNames Noを 設定する。

cupsaddsmbに対するAdobe PostScriptドライバーファイルの位置

共有されたPostScriptプリンターを持つWindowsマシンに繋ぐために、smbclient を、 smbclient //windowsbox/print\$ -U guest のように使う。W32X86/2サブディレクトリに移動でき、 mget ADOBE*し、あるいはWIN40/0で、同じ事をやる。 他のオプションは、Adobe Webサイトから*.exeをダウンロードする。

CUPS印刷プロセスの概要

CUPS印刷プロセスの完全な概要は、 CUPS印刷のダイアグラム概要にある。

Figure 22.19. CUPS印刷のダイアグラム概要

CUPS印刷のダイアグラム概要

Chapter 23. スタッカブルVFSモジュール

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Tim Potter

Samba Team

Simo Sorce

original vfs_skel README 

Alexander Bokovoy

original vfs_netatalk docs 

Stefan Metzmacher

Update for multiple modules 

Ed Riddle

original shadow_copy docs 

機能と利便性

Samba-3から、スタッカブルVFS(バーチャルファイルシステム)モジュールがサポートされる。 SambaはUNIXファイルシステムへのアクセスリクエストの一つ一つを、ロードされた VFSモジュールに渡す。この章は、Sambaのソースに附属のモジュールについて説明すると同時に、 一部の外部モジュールについても言及する。

議論

異なるシステムでは異なる方法で共用ライブラリーをコンパイルしリンクするので、これらの モジュールが、プラットフォームディストリビューションのバイナリSambaパッケージと共に 供給されない場合、モジュールをコンパイルするのが困難になるかもしれない。これらの モジュールは、GNU/Linux及びIRIXに関してテスト済みである。

VFS モジュールを使用するには、以下の例に類似した共有を作成すること。重要なパラメーターは、 一つ以上のVFSモジュールを名前順に一覧表示できるvfs objects パラメーターである。例えば、ファイルへのアクセスをすべてログに取り、削除されたファイルを ゴミ箱に入れるには、VFSモジュールを使うsmb.confの例を 参照のこと:

Example 23.1. VFSモジュールを使うsmb.confの例

[audit]
comment = Audited /data directory
path = /data
vfs objects = audit recycle
writeable = yes
browseable = yes

モジュールは指定された順に使用される。例えば、ウィルススキャナモジュールとごみ箱 モジュールを両方使用したいとする。この場合、ファイルに関して他のアクションが 取られる前に、最初にウィルスを検知するよう、ウィルススキャナモジュールを最初の モジュールとし、このモジュールが最初に動くようにすべきである。 The modules are used in the order in which they are specified. Let's say that you want to both have a virus scanner module and a recycle bin module. It is wise to put the virus scanner module as the first one so that it is the first to get run and may detect a virus immediately, before any action is performed on that file. vfs objects = vscan-clamav recycle

SambaはSambaをインストールしたサーバーのrootディレクトリ中の/lib からいくつかのモジュールをロードしようとする(通常は /usr/lib/samba/vfs/usr/local/samba/lib/vfs)。

いくつかのモジュールは同じ共有に対して二度使用できる。これは 複数のVFSモジュールを使用するsmb.confの例の ような設定で可能となる。

Example 23.2. 複数のVFSモジュールを使用するsmb.confの例

[test]
comment = VFS TEST
path = /data
writeable = yes
browseable = yes
vfs objects = example:example1 example example:test
example1: parameter = 1
example: parameter = 5
test: parameter = 7


含まれるモジュール

audit

syslog機能へのファイルアクセスを監査するシンプルなモジュールである。 以下の操作のログが取られる:

  • share

  • connect/disconnect

  • directory opens/create/remove

  • file open/close/rename/unlink/chmod

default_quota

このモジュールは、Samba-3サーバー上で格納される既定値のquota値を、Windowsのエクスプローラーの GUI画面で設定できるようにする。この試みはLinuxファイルシステムでユーザーとグループに対する quotaを格納する場合のみだが、それは既定値を持たない。

Sambaは既定値としてNO_LIMITをquotaの既定値として返し、それは更新できない。このモジュールを 使うと、ユーザーに対するquotaレコード中でWindowsクライアントに表示される既定値のquota値を 格納できる。既定値では、通常quota制限がrootには適用されないため、rootユーザーが既定値として 利用される。

このモジュールにはsmb.confファイル中で2つのパラメーターを設定する。おのおのの既定値の プレフィックスはdefault_quotaである。これは、以下のようにして、 vfs modulesパラメーター中でモジュールをロードしたときに上書きできる:

vfs objects = default_quota:myprefix

default_quotasモジュールに対して指定することが出来るパラメーターのエントリは以下の通り:

myprefix:uid

既定値のユーザーquotaを格納するために使われるquotaレコードのためのuidを 指定する整数値。

既定値は0(ルートユーザー)。使用例は以下の通り:

vfs objects = default_quota
default_quota:	uid = 65534

上記の例ではmyprefixが省略され、そのため、既定値の プレフィックスはモジュールの名前になる。myprefix パラメーターが指定されると、上記は以下のように書き換えられる:

vfs objects = default_quota:myprefix
myprefix:	uid = 65534

myprefix:uid nolimit

既定値のquota値がユーザーのレコードとしても表示される場合か、 NO_LIMITが、prefix:uidパラメーターに よって指定されたユーザーとしてWindowsクライアントに表示される場合、この パラメーターは論理値となる。

既定値はyesである(NO_LIMITが表示される)。使用例は以下の通り:

vfs objects = default_quota:myprefix
myprefix:	uid nolimit = no

myprefix:gid

このパラメーターはprefix>:uidと同じように整数値を引数と して取るが、グループquotaであるところが違う。注意:グループquotaはWindows エクスプローラーではサポートされていない。

既定値は0である(rootグループ)。使用例は以下の通り:

vfs objects = default_quota
default_quota:	gid = 65534

myprefix:gid nolimit

このパラメーターは、prefix>:uid nolimitと同じように 真理値を取るが、グループquotaであることが違う。注意:グループquotaは Windowsエクスプローラーではサポートされていない。

既定値はyes(NO_LIMITが表示される)。使用例は以下の通り:

vfs objects = default_quota
default_quota:	uid nolimit = no

複数のパラメーターを組み合わせた使用例は以下の通り:

...
vfs objects = default_quota:quotasettings
quotasettings:	uid nolimit = no
quotasettings:	gid = 65534
quotasettings:	gid nolimit = no
...

extd_audit

このモジュールは上記のauditモジュールとほぼ同じで あるが、監査ログをsyslogとsmbdのログファイルに送る 事が異なる。このモジュールのlog levelsmb.confファイル中で設定する。

有効な設定と記録される情報を下記のテーブル中に示す。

Table 23.1. 拡張監査ログの情報内容

ログレベルログ内容 - ファイルとディレクトリ操作
0ディレクトリの作成、削除、Unlink
1ディレクトリのオープン/改名、ファイル名の変更、パーミッション/ACLの変更
2ファイルのオープン&クローズ
10最大のデバッグレベル

監査の設定

この監査ツールはたいていの人が容易に認知するよりもより自由度が高い。 有用なログ情報を記録するためのいくつかの方法がある。

  • すべてのトランザクションを記録するためにsyslogが使える。 これは、smb.confファイル中に syslog = 0を設定することで無効に出来る。

  • xがログレベルであるlog level = 0 vfs:xsmb.confファイル中に設定することによりすべてのロードされた VFSモジュールに対して既定値のログファイル (log.smbd)をログの出力として使える。これは、 ログレベルで指定された、VFSモジュールの動作のすべてのログが 有効になっているが、通常のログは無効にする。

  • ユーザー単位、クライアントマシン単位などで詳細なログを取れる。 これは、log fileの特別な設定方法と 上記を一緒にすることを要求する。

    ユーザー単位とマシン単位の詳細なログの例は、 log file = /var/log/samba/%U.%m.log のようにして行う。

監査情報は、しばしば長い期間保存する必要はある。ログファイルがローテート されないように、smb.confファイル中でmax log size = 0 を設定するのは必須である。

fake_perms

このモジュールは、(UNIX配下のSambaサーバーで)移動プロファイルのファイルと ディレクトリを読み込み専用に設定することができるようにするために作成 された。 このモジュールは、プロファイル共有にインストールされている場合、 プロファイルのファイルとディレクトリが書き込み可能であると、クライアントに 通知する。これにより、クライアントがログアウトまたはシャットダウンした 時に、ファイルを上書きしなくなるが、クライアントのニーズは充足する。

recycle

ゴミ箱と同様のモジュールである。 使用すると、unlinkシステムコールを 横取り、ファイルを削除する代わりにゴミ箱ディレクトリに移動する。 これはWindowsコンピュータにおけるゴミ箱の機能と 同じである。

ごみ箱は、Windows エクスプローラー のネットワークファイルシステム(共有)のビューにも、マッピングされたドライブの いずれのビューにも表示されない。その代わりに、.recycle というディレクトリが、初めてファイルを削除したときと recycle:repositoryが設定されていないときに自動的に 作成される。もし、recycle:repositoryが設定されている 場合、作成されるディレクトリはrecycle:repositoryに 依存する。ユーザーはごみ箱からファイルを取り戻すことが出来る。もしも、 recycle:keeptreeが指定されていた場合、 削除されたファイルは、ファイルが削除された元の場所と同一のパスから、 見つけることができる。

recycleがサポートするオプションは以下の通り:

recycle:repository

削除されたファイルの移動先であるディレクトリのパス。

recycle:directory_mode

recycleディレクトリに設定したい8進のモードを指定する。 もしも存在しないか、最初にファイルが削除された時、 このモードでrecycleディレクトリが作成される。 もしも、recycle:subdir_modeが 設定されていない場合、それらのモードはサブディレクトリ にも適用される。もしも、 directory_modeが設定されて いない場合、既定値として0700が使われる。

recycle:subdir_mode

recycleディレクトリのサブディレクトリに設定したい 8進のモードを指定する。このモードでサブディレクトリ が作成される。もしも、 recycle:subdir_modeが 設定されていない場合、サブディレクトリのモードは directory_modeのモードで 作成される。

recycle:keeptree

ディレクトリ構造を維持するか、あるいは削除された ファイルはゴミ箱に別に保存するかを指定する。

recycle:versions

このオプションを設定すると、同名の二つのファイルが削除 されたとき、 二つとも別のファイルとしてゴミ箱に保存する。 より新しい方の削除ファイルは、 Copy #x of filename という名称で保存される。

recycle:touch

ファイルがごみ箱に移されたときに、ファイルのアクセス 日付を変更するかどうかを指定する。

recycle:touch_mtime

ファイルがごみ箱に移されたときに、ファイルの最終変更 時刻を変更するかどうかを指定する

recycle:maxsize

このパラメーターで指定したバイト数より大きいファイルは、 ごみ箱に入れない。

recycle:exclude

ごみ箱に入れないで、普通に削除するべきファイルをリストする。

recycle:exclude_dir

ディレクトリのリストを指定する。これらのディレクトリから ファイルが削除されると、ごみ箱には入れずに、普通に削除する。

recycle:noversions

recycle:versionsの反対である(*や?のワイルドカードもサポート) する。recycle:versionsが有効な時に 便利である。

netatalk

netatalkモジュールは、Sambaとnetatalkのファイル共有サービスの共存を やり易くする。

従前のnetatalkモジュールと比較した長所は以下の通り:

  • .AppleDouble フォークの作成を気にかけず、ただ同期を取る。

  • smb.conf中の共有の「隠し(hide)」または「拒否(veto)」 リスト中に.AppleDoubleのアイテムを含まないとき、自動的に追加される。

shadow_copy

Warning

これはバックアップでも、アーカイブでも、バージョンコントロールソリューションでもない!

SambaかWindowsサーバーでは、shadow_copyはエンドユーザーツールとしてのみ設計されて いる。バックアップやアーカイブソリューションの機能強化や置き換えにはならず、 そのように考えてはいけない。更に、バージョンコントロール機能が必要な場合には、 バージョンコントロールシステムを入れること。これは警告である。

shadow_copyモジュールはMicrosoftシャドーコピーサービスに似た機能を提供する。 適切に設定された場合、Sambaの共有上で、Microsoftシャドーコピークライアントが "シャドーコピー"を見えるようにする。シャドーコピークライアントのインストール が必要である。Microsoftシャドーコピークライアントは ここ から入手できる。Windows XPより前のクライアントには追加の要求があることに注意。 この機能はWindows XPより前のバージョンではテストされていない。Microsoftシャドーコピー に関するより詳細な情報は、 Microsoftのサイト を参照のこと。

shadow_copy VFSモジュールはLVM1、LVM2かEVMSのような、ある種の論理ボリューム マネージャ(LVM)でセットアップしたものがベースのファイルシステムを要求する。 LVMの設定はこの文書の範囲外である。しかし、例としてのみ この機能をテストするために行う手順の概要を示す。使いたいとしているLVMの 実装が使用対象に対して準備されているかを確かめる必要がある。十分にテストは されなければならない。

以下は、LVMとEVMSに対するよく使われる情報源である:

Shadow Copy のセットアップ

これを書いている時点では、十分なテストは終わっていない。シャドーコピーVFS モジュールを、製品環境では展開していないが、概念の照明としてはより多く、 特定のシナリオでテストした。シナリオはXFSファイルシステムとLVM1を使う Debian Sarge上のSamba-3サーバーで改良された。ここで提示されたすべてのコンポーネント に関して、十分な評価をしないでソリューションとして使うことは推奨しない。 すなわち、以下は動作させたまでの基本的な概要である。

  1. インストールされたOS.  テストを行うにあたっては、 Debian Sarge (すなわちテスト版)をXFSファイルシステム上で使用した。OSの設定は、 この文書の範囲外である。Sambaが動作するOSがあるものと仮定する。

  2. Sambaのインストールと設定.  この件についてはこのHOWTOのインストールの章 を参照のこと。ドメインコントローラーかメンバーファイルサーバーであることは重要では ないが、Samba 3.0.3かそれ以降のサーバーが動作していることを仮定する。

  3. LVMのインストールと設定.  クライアントに対してシャドーコピーを有効にする前に、シャドーコピーを 作っておく必要がある。これはファイルシステムのスナップショットのような 事を行う事でできる。スナップショットはLVMのような、論理ボリューム マネージャでの一般的な機能であり、まずこれを最初に設定する必要がある。

    以下は、Debianユーザーにとっては最も手助けとなる例である。繰り返すが、 これは"testing"または"Sarge"を使ってテストしている。

    • まだ入れていないのであれば、lvm10とdevfsdパッケージをインストールする。 Debianシステム上では、devfsファイル名を要求するdevfsとlvm1が相互に 影響するので警告が出る。 apt-get update && apt-get install lvm10 devfsd xfsprogs を実行してこの例のためのトリックを行う。

    • 次にボリュームを作成する。そしてボリュームにパーティションを作成する 必要がある。好みのパーティション作成ツールを使うこと(たとえば、 Linuxのfdisk、cfdiskなど)。パーティションタイプは"Linux LVM"を 表す 0x8eに設定すべきである。この例では/dev/hdb1を使う。

      LVMパーティション(タイプ0x8e)が出来ると、LVMボリュームを作成するための 一連のコマンドを実行出来る。いくつかのディスクとパーティションを 使うことが出来るが、この例では一つのみを使う。 modprobe lvm-modのようにしてカーネルモジュールを ロードしてもよく、また、(/etc/modulesに追加 することによって)起動時にロードするように、rebootしても良い。

    • pvcreate /dev/hdb1で物理ボリュームを作成する。

    • vgcreate shadowvol /dev/hdb1でボリュームグループを作成し、/dev/hda1に追加する。

      vgdisplayを使ってボリュームグループについての情報を見る事ができる。

    • この時点でlvcreate -L400M -nsh_test shadowvolのようにして、論理ボリュームを作成できる。

      これは、shadowvolとして作成したボリュームグループ内に、400MBの、 "sh_test"という論理ボリュームを作成する。すべてがうまくいくと、 /dev/shadowvol中にそれらを見る事ができる。

    • この時点でsh_testという論理ボリュームを mkfs.xfs /dev/shadowvol/sh_test というコマンドでフォーマットできる準備が出来た。

      選択した任意のファイルシステムで論理ボリュームをフォーマット できるが、ファイルシステムのフリーズ、リサイズや拡張のような LVMの便利な追加機能を使えるようにしておくこと。

      これで、シャドーコピーVFSモジュールを使えるLVMボリュームが 準備できた。

    • 以下のようにしてディレクトリを準備する必要がある。 Now we need to prepare the directory with something like

      root#  mkdir -p /data/shadow_share
      

      あるいは、シャドーコピーが有効になったSamba共有の希望する名前を 指定する。その上で使えるように、パーミッションの設定をきちんと 行う事。もしも、わからなければ、 chmod 777 /data/shadow_shareを使い、うまく 動いてからパーミッションをきつくする。

    • mount /dev/shadowvol/sh_test /data/shadow_share のようにしてLVMボリュームをマウントする。

      システム起動時にこのパーティションをマウントできるよう、 /etc/fstabを編集しても良い。

  4. シャドーコピーVFSモジュールのインストールと設定.  最後に実際のシャドーコピーVFSモジュールを設定する。シャドーコピーVFS モジュールはSamba 3.0.3以降で有効である。smb.confの設定はとても標準的 である。以下はシャドーコピーVFSモジュールを使う共有定義の例である:

    Example 23.3. シャドーコピーVFSを使う共有

    [shadow_share]
    comment = Shadow Copy Enabled Share
    path = /data/shadow_share
    vfs objects = shadow_copy
    writeable = yes
    browseable = yes

  5. スナップショットの作成とシャドーコピーとしての有効化.  シャドーコピーを閲覧できる前に、それを作成してマウントする必要がある。 これは、cronジョブとして動作するスクリプトで行うのが最も良い。この特定の 解決方法に、LVMスナップショットを閲覧するのにシャドーコピーVFSモジュールが 使える。これらのスナップショットはモジュールによっては作成されない。また、 モジュールによって有効化もされない。このモジュールは、有効になったスナップ ショットを閲覧する事を、シャドーコピーが有効になったクライアントに対して 行う。

    以下はスナップショットの作成とマウントを行う単純なスクリプトである:

    #!/bin/bash
    # This is a test, this is only a test
    SNAPNAME=`date +%Y.%m.%d-%H.%M.%S`
    xfs_freeze -f /data/shadow_share/
    lvcreate -L10M -s -n $SNAPNAME /dev/shadowvol/sh_test
    xfs_freeze -u /data/shadow_share/
    mkdir /data/shadow_share/@GMT-$SNAPNAME
    mount /dev/shadowvol/$SNAPNAME \
           /data/shadow_share/@GMT-$SNAPNAME -onouuid,ro
    

    このスクリプトはリブート時にスナップショットの再マウントのような事は扱わないことに注意。

  6. クライアントからのテスト.  テストのために、 MicrosoftのWebサイト からシャドーコピークライアントを入手し、インストールする必要がある (訳注:URLは日本語版に差し替え済み)。これはXPクライアントでのみテストして いるので、他のXP以前のクライアントでは結果が異なる可能性がある。一度 XPクライアントにインストール後、指定したファイルかshadow_shareの 空白部分で右クリックすると、"プロパティ"が表示される。何か変更があると、 プロパティウィンドウの中に"以前のバージョン"が表示される。

他で入手可能なVFSモジュール

この節では、投稿されてはいるが、SambaCVSツリー(訳注:現在はgit)には何らかの理由(例えば、 管理者が独自のCVSツリーを持つ方が管理しやすいなどの理由)で、現行のものには含まれない、 各種のVFSモジュールを紹介する。

ここで言及したからと言って、そのモジュールの安定性や機能性の良し悪しを示唆したとは解釈しないこと。

DatabaseFS

URL: Taylors University DatabaeFS

By Eric Lorimer.

私は、かなり完成された読み込み専用のファイルシステムを実現する VFS モジュールを作成した。 これは、異なるデータベースを使用するための、モジュール式あるいは一般的な方式のファイル システムとしてデータベースからの情報を表示する(元々は、アーティスト歌詞といったディレクトリでMP3ファイルを整理するために設計されたもので ある。これを私は、学生名簿データベースに応用した)。ディレクトリ構造はデータベース自身に 保存されており、その表を確認するプログラムが走りますが、それ以外に、データベース構造に 関して何らかの推定をすることはしない。

フィードバックを歓迎する。コメント、提案、パッチ、その他何でも送ってほしい。他に何の 役にも立たなくても、最低、誰かが仮想ファイルシステムを作成したい場合に役に立つことを 願っている。

vscan

URL: Open Anti-Virus vscan

Samba-vscan は、Sambaが使う共有化のファイルのための、オンアクセスアンチウィルス機能を提供する、 コンセプト実証(POC)モジュールである。samba-vscan は、各種のウィルス・スキャナーをサポートし、 Rainer Linkがメンテナンスを行っている。

vscan-clamav

Sambaユーザーは何の問題もなくSerNetからのRPMを使っている。OpenLDAP Linuxユーザーも とても良い結果が得られるvscanスキャナを使っている。これは全体を通して書き込みの パフォーマンスに影響がある。

以下のような共有セクションはvscan-clamavを設定したい人のための良いガイドである:

[share]
vfs objects = vscan-clamav
vscan-clamav: config-file = /etc/samba/vscan-clamav.conf

以下のvscan-clamav.confファイルの例は、完全に動作可能なものの 手助けになるかもしれない:

<title>VFS: Vscan ClamAV制御ファイル</title>
#
# /etc/samba/vscan-clamav.conf
#

[samba-vscan]
; run-time configuration for vscan-samba using
; clamd
; all options are set to default values

; do not scan files larger than X bytes. If set to 0 (default),
; this feature is disable (i.e. all files are scanned)
max file size = 10485760

; log all file access (yes/no). If set to yes, every access will
; be logged. If set to no (default), only access to infected files
; will be logged
verbose file logging = no

; if set to yes (default), a file will be scanned while opening
scan on open = yes
; if set to yes, a file will be scanned while closing (default is yes)
scan on close = yes

; if communication to clamd fails, should access to file denied?
; (default: yes)
deny access on error = no

; if daemon failes with a minor error (corruption, etc.),
; should access to file denied?
; (default: yes)
deny access on minor error = no

; send a warning message via Windows Messenger service
; when virus is found?
; (default: yes)
send warning message = yes

; what to do with an infected file
; quarantine: try to move to quantine directory
; delete:     delete infected file
; nothing:    do nothing (default)
infected file action = quarantine

; where to put infected files - you really want to change this!
quarantine directory  = /opt/clamav/quarantine
; prefix for files in quarantine
quarantine prefix = vir-

; as Windows tries to open a file multiple time in a (very) short time
; of period, samba-vscan use a last recently used file mechanism to avoid
; multiple scans of a file. This setting specified the maximum number of
; elements of the last recently used file list. (default: 100)
max lru files entries = 100

; an entry is invalidad after lru file entry lifetime (in seconds).
; (Default: 5)
lru file entry lifetime = 5

; exclude files from being scanned based on the MIME-type! Semi-colon
; seperated list (default: empty list). Use this with care!
exclude file types =

; socket name of clamd (default: /var/run/clamd). Setting will be ignored if
; libclamav is used
clamd socket name = /tmp/clamd

; limits, if vscan-clamav was build for using the clamav library (libclamav)
; instead of clamd

; maximum number of files in archive (default: 1000)
libclamav max files in archive = 1000

; maximum archived file size, in bytes (default: 10 MB)
libclamav max archived file size = 5242880

; maximum recursion level (default: 5)
libclamav max recursion level = 5

もちろん、これを動作させるためにclamデーモンを走らせることは必要である。これはClamAVを 使うための動作例である。ClamAVの説明には追加の設定例が提供されている。それは、システム 内の/usr/share/doc/ディレクトリ配下に配置されている。いくつかの例は 他の使用可能なウィルススキャナをターゲットにもしている。

Chapter 24. Winbind: ドメインアカウントの使用

Tim Potter

Andrew Tridgell

Samba Team

Naag Mummaneni

Notes for Solaris 

John Trostel

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

June 15, 2005

機能と利便性

UNIXとMicrosoft Windows NTを統合化されたログオンで統合することは、長い間 異機種間コンピューティング環境において聖杯と考えられてきた。

もう一つ、この機能がなければ、UNIXとMicrosoft Windowsネットワークの相互運用性が 著しく限定されるというものがある。UNIXシステム全般に渡ってファイル共有を 可能にし、ドメインユーザーとグループの所有者を整合性のある形で割り当てられる 機構がなければならない。

winbindは、Sambaシステム中で、統一されたログオンの 問題を解決するコンポーネントである。Winbind は、Microsoft RPC コール、 Pluggable Authentication Modules (PAM)、Name Service SwitchのUNIXの実装を 使用して、Windows NTのドメインユーザーがUNIXマシン上のUNIXユーザーとして動作 できるようにする。この章は、Winbindシステムについて、その機能、設定の仕方、 及び内部的にどのように動いているのかを説明する。

Winbind は、三つの別々の機能を提供する。

  • ユーザーの本人確認情報の認証(PAM経由)。これは、Windows NT4ドメインか (Sambaドメインも含む)Active Directoryドメインからユーザーとグループ アカウントを使ってUNIX/Linuxシステムにログオンすることを可能にする。

  • IDの解決(NSS経由)。これは、winbindが使われなかった時の既定値である。

  • Winbindは、winbind_idmap.tdbと呼ばれるデータベースを維持し、その中に、 UNIX UID/GIDとNT SID間のマッピング情報を格納する。このマッピングは、 ローカルUID/GIDを持たないユーザーまたはグループにのみ使用する。 idmap uid/gid の範囲から割り当てられ、NTのSIDにマッピングされた UID/GIDが格納される。idmap backendldap:ldap://hostname[:389]に指定されている場合、 ローカルのマッピングを使用する代わりに、Winbindは、この情報をLDAP データベースから取得する。

Note

もしもwinbinddが実行中ではないとき、smbd (winbinddを呼び出す方)は、代替手段として純粋にローカルな /etc/passwd/etc/groupからの情報を 使用することにし、動的マッピングは使用しない。OSでNSSが有効になっている場合、 ユーザーとグループ情報の解決はNSS経由で行われる。

Figure 24.1. Winbind Idmap

Winbind Idmap

はじめに

UNIXとMicrosoft Windows NTでは、ユーザー及びグループ情報の見せ方のモデルも、 それを実行するために使用している技術も異なるのは周知の事実である。これが、 二つのシステムを統合して、満足の行く運用をすることを困難にしてきた。

これに対してよく行われる解決策は、UNIXとWindowsの両システム上に全く同名の ユーザーアカウントを作成し、Sambaを使用して、両システム間のファイルサービスと 印刷サービスを提供するというやり方であった。ただし、この解決策は、双方の マシンにユーザーを追加したり削除したりする作業が面倒でパスワードも2セット 持たなければならず、その両方がUNIXとWindowsシステム間の同期のずれの問題に つながり、ユーザーの混乱を招くという、完璧には程遠いものである。

UNIX マシンのための統一されたログオンという問題を、次のように三つの 構成要素に分けることができる:

  • Windows NTのユーザー及びグループ情報を取得する。

  • Windows NT ユーザーを認証する。

  • Windows NT ユーザーのためにパスワードを変更する。

理想的には、統一されたログオンという問題の解決方法は、UNIXマシン上に情報を複製する ことなく、上記の問題を全て満足させ、しかも、 ユーザーやグループ情報をどちらの システムで維持しても、システム管理者の仕事を増やさないというものであってほしい。 Winbind システムは、統一されたログオンという問題の三つの構成要素を簡単に優雅に こなすソリューションを提供するものである。 problem.

Winbindが提供するもの

Winbindは、UNIXとWindows NTのアカウント管理を、UNIXマシンがNTドメインの完全な メンバーになることを可能にすることによって統一する。一旦これを行えば、UNIX マシンは、NTユーザーやグループをあたかもネイティブなUNIXユーザーや グループであるかのように見ることができるようなり、UNIXのみの環境でNIS+を使用 するのとほぼ同様に、NTドメインを使用することができるようになる。

その結果、UNIX マシン上のプログラムのいずれかが、OSにユーザー名やグループ名の検索を 依頼すると、指定されたドメインを担当する NT のドメインコントローラーにその検索を 依頼することにより、問い合わせは解決する。Winbind は低レベル(Cライブラリ内の NSS名前解決モジュール経由)でOSに繋がるので、NT ドメインコントローラーへの上記の リダイレクションは、完全に透過である。

UNIXマシンのユーザーは、ネイティブのUNIX名を使用するのと同様に、 NTユーザー名とグループ名を使用することができる。ユーザーはファイルをchownして、 NTドメインユーザーの所有に変えることもでき、UNIXマシンにログインしてドメイン ユーザーとしてUNIXのX Window Systemセッションを実行することもできる。

Winbindが使用されていることが明らかにわかるところは、ユーザー及びグループの名前が DOMAIN\userDOMAIN\groupの形を取ると いう点だけである。これは、Winbind が、信頼関係のあるドメインに参照するの特定の 検索について、ドメインコントローラーへのリダイレクト決めるために必要である。

さらに、Winbind は、PAMシステムのhookとしての認証サービスを提供し、NTドメインを 経由して、PAM対応のあらゆるアプリケーションに対して認証を行う。この機能は、一カ所 (ドメインコントローラー上)に全てのパスワードが格納されるため、システム間の パスワード同期の問題を解消する。

対象となるユーザー

NTベースのドメイン基盤がすでにあり、それにUNIX ワークステーションか サーバーを組み入れたいという要望のある組織がWinbindの対象となる。Winbind より、このような組織は別個のアカウント基盤を管理する必要なく、UNIX ワークステーションを展開することができる。これは、NTベースの組織にUNIX ワークステーションを展開するための間接費を大幅に軽減する。

Winbind のもう一つの興味深い使用方法は、UNIXベースの装置の中心部分に 使用することである。Microsoftベースのネットワークにファイルサービスと 印刷サービスを提供する装置は、Winbindを使用することで、ドメインに シームレスに統合される。

外部のSIDの取り扱い

外部のSID(foreign SID)という単語は、特定の環境に依存しない 反応としてしばしば見受けられる。以下はSambaメーリングリスト上で起きたやりとりを 書化したものである。これは、winbindの使用に関連してしばしば現れる混乱の良い例で ある。

事実:Winbindはローカルドメインの一部でないワークステーションを使うユーザーを 扱う必要がある。

対応:なぜ?私はwinbindなしで長い間ドメインに所属していないワークステーション をSambaとともに使っている。winbindは他のSamba/Windows PDCによって制御される ドメイン中のメンバーサーバーとしてのSamba用ではないかと思う。

もしも、SambaサーバーがローカルSambaドメイン以外のドメインからアクセスされる か、もしも、ローカルドメインメンバーでないマシンからアクセスされる場合、winbindは Sambaドメインのメンバーであるユーザーから分離された外部のユーザーの識別情報を保持する めの割り当てられた領域からUIDとGIDを割り当てる。

これは、winbindは、ドメインメンバーとドメイン非メンバーのワークステーションがある、 単一のSambaPDCがローカルネットワーク上にある場合に甚だしく有用である。もしも、 winbindが使われないと、ドメインのメンバーでないWindowsワークステーション上の georgeというユーザーはPDCとして動作しているSambaサーバーのアカウントデータベース 中のgeorgeと呼ばれるユーザーのファイルにアクセスできる。winbindが使われると、 既定値の状態は、ローカルユーザーのgeorgeがDOMAIN\georgeというアカウントとして 扱われ、外部(ドメインのメンバーでない)アカウントは、おのおの別のSIDを持つために MACHINE\georgeとして扱われる。

Winbindの動き方

Winbindシステムは、クライアント/サーバーアーキテクチャを想定し設計されたもので ある。長時間走り続けるwinbinddデーモンがUNIXドメイン ソケット上でリクエストが来るのを待つ。これらのリクエストは、NSS及びPAM クライアントにより生成され、順番に処理される。

Winbind を実装するのに使用されている技術を以下に詳述する。

Microsoft Remote Procedure Calls

過去数年間、Sambaチームの多くのメンバーが、Microsoftリモートプロシージャ コール(MSRPC)システムの各側面を解明しようと努力してきた。このシステムは、 リモート管理、ユーザー認証、印刷スプーリングを含むWindows NTマシン間の ネットワーク関連操作の大半に使用されている。当初、Sambaへのプライマリ ドメインコントローラー(PDC)機能の実装を支援するために 着手した作業で あったが、結果としてそれ以外の目的に使用できる一連のコードを得ることが できた。

winbind はドメインユーザーとグループを列挙し、個々のユーザーやグループの詳細 情報を取得するために、各種のMSRPC コールを使用する。他のMSRPC コールは、 NTドメインユーザーを認証し、ユーザーのパスワードを変更するために使用できる。 Windows PDCに、直接ユーザー及びグループ情報を問い合わせることで、Winbindは、 NTのアカウント情報をUNIXユーザー名とグループ名にマッピングする。

Microsoft Active Directoryサービス

2001年後半より、SambaはNT4のRPC サービスではなく、ネイティブモード のプロトコルを使用して、Microsoft Windows 2000とやり取りする機能を持つ ようになった。LDAP及びKerberosを使用し、winbindを走らせている ドメイン メンバーは、Windows 200xクライアントの世界で行われるのと全く同じように、 ユーザーとグループを列挙でき、そうすることによってより効率的で効果的な winbind の実装を提供する。

Name Service Switch

Name Service SwitchまたはNSSは、多くのUNIX OSに存在する機能である。 これは、ホスト名、メールの別名、ユーザー情報などのシステム情報を、異なる ソースから解決することを可能にする。例えば、スタンドアロンのUNIXワーク ステーションは、ローカルのファイルシステムに格納されている一連のフラット ファイルからシステム情報を解決できる。ネットワークに繋がったワーク ステーションは、最初にローカルファイルからシステム情報を解決しようとし、 次にユーザー情報についてNISデータベースに問い合わせるか、あるいは、ホスト名 情報についてDNS サーバーに聞くことができる。

UNIXユーザー名とグループの解決の際、NSSのAPIは、winbind が自分をシステム 情報のソースとして見せることを可能にする。winbindは、このインタフェースと MSRPCコールを使用して、Windows NTサーバーから取得した情報を使用して、 アカウント列挙の新しいソースを提供する。標準のUNIXライブラリコールを 利用して、winbind を走らせているUNIXマシン上でユーザーとグループを列挙させ、 NTドメインのみならず、信頼関係のあるいずれのドメインでもその全ユーザーと グループを、あたかも、ローカルユーザーやグループのように見ることができる。

NSSの基本制御ファイルは/etc/nsswitch.confである。 UNIXアプリケーションが検索を行うと、Cライブラリは要求されたサービス タイプに一致する列を/etc/nsswitch.confの中で探す。 例えば、ユーザー名またはグループ名の検索の場合、passwdの サービスタイプが使用される。設定の中のこの列が、そのサービスのどの 実装が、どういう順番で試行されるべきか指定している。もし、passwdの 設定列が以下のようになっている場合:

passwd: files example

Cライブラリは、最初に/lib/libnss_files.soと呼ばれる モジュールをロードし、次に/lib/libnss_example.so モジュールをロードする。Cライブラリはこれらのモジュールを順番に動的 ロードし、モジュール内の解決機能を呼んでリクエストを解決しようとする。 要求が解決されると、Cライブラリ は、その結果をアプリケーションに返す。

このNSSインタフェースは、OSへのフックのための、Winbindへの簡単なしくみを 提供する。必要な手続きは、/lib/の中に libnss_winbind.soを書き、次に適切な場所で /etc/nsswitch.confwinbindを追加 するだけである。これで、Cライブラリは、Winbindを呼んでユーザー名や グループ名を解決できるようになる。

Pluggable Authentication Modules

PAMは、認証と認証技術を抽象化するものである。PAMモジュールを使用すると、 異なるシステムアプリケーション用にそれぞれ異なる認証方法を指定でき、 しかも、これらのアプリーケーションを再コンパイルする必要はない。 PAM はまた、特別なポリシーを認証に実装するためにも有用である。例えば、 システム管理者は、ローカルなパスワードファイルに格納されたユーザーからは コンソールログインのみを許可し、NISデータベースから解決されるユーザーに ついては、ネットワーク経由のログインを許可することができる。

Winbind は、認証管理とパスワード管理のPAMインタフェースを使用して、 Windows NTユーザーをUNIXシステムに統合する。これにより、 Windows NT ユーザーはUNIXマシンにログインでき、適切なPDCの認証を受けることが できるようになる。このようなユーザーはパスワードの変更もできる上、 その変更内容をPDCに直に反映させることができる。

PAMは、認証を必要とするサービスごとに、/etc/pam.d/の ディレクトリに管理ファイルを設けて設定する。アプリケーションが認証要求を 出すと、Cライブラリ内のPAMコードが、認証を行うために、どのモジュールを どの順番でロードするべきかを決定するためにこの管理ファイルを検索する。 このインタフェースにより、Winbindに新しい認証サービスを追加することが 簡単になる。必要な手順は、/lib/security/pam_winbind.soモジュールをコピーすることと、 Winbind 経由の認証を可能にするために、関連するサービスのPAM管理ファイルを 更新することである。詳細は、 PAMベースの分散型認証のPAMの説明を参照のこと。

ユーザーとグループIDの割り当て

Windows NT/200xでユーザーまたはグループが作成されると、数字で構成される 相対ID(RID)を割り当てられる。これは、UNIXとは幾分異なる。UNIXでは、 ユーザーIDに使用される数字の範囲と、グループIDに使用される数字の範囲が 別々になっている。RIDをUNIXのIDに変換する、またはその逆を行うのが Winbindの仕事である。Winbindを設定する際、UNIXユーザーIDのスペースの 一部とUNIX グループIDのスペースの一部を、Windows NTのユーザーと グループを格納する場所である。Windows NTユーザーが最初に解決されるとき、 上記の範囲の中から次の空き番号をUNIX上のIDとして割り当てる。この 同じプロセスがWindows NTグループに対しても適用される。こうして一定の 時間が経つと、全てのWindows NTユーザーとグループはWinbindにより、対応 するUNIXユーザーIDとグループIDへマッピングされることになる。

このマッピングの結果は、tdbのデータベース内のIDマッピングデータベースに 一貫して格納されていく。これにより、RIDが一貫した方法でUNIXのIDに マッピングされていくことを確保している。

結果のキャッシュ保存

Active Directoryシステムは、数多くのユーザー名やグループ名の検索を発行 する。 これらの検索に係るネットワークの負担を軽減するため、Winbindは、 NTドメインコントローラーから供給されるSAM シーケンス番号に基づいて、 キャッシュに保存する。PDCから返されたユーザー情報やグループ情報は、 同じくPDCから返されたシーケンス番号と一緒に、Winbindによってキャッシュに 保存される。ユーザー情報やグループ情報が変更される度に、Windows NTは シーケンス番号を増やす。キャッシュに保存されたエントリが満了になる ときに、シーケンス番号をPDC からリクエストし、キャッシュのエントリの シーケンス番号と比較する。番号が一致しないときは、キャッシュに保存された 情報を捨て、PDCから直接更新情報をもらうように更新を行う。

インストールと設定

はじめに

この節では、Winbindを入手して使えるようにするまでの手順を説明する。WinbindはNTまたは Windows 200xの PDCを通して、Windowsのドメインユーザーにtelnetやftpのような通常のサービス と、Sambaの各種サービスのためのアクセス制御と認証管理の機能を提供することができる。

  • どうして、これをやるべきなのか?

    これにより、Samba管理者がドメインメンバーの認証のために、Windows NT/200x PDCの認証機構を 頼れるようになる。Windows NT/200xユーザーは、Sambaサーバー上に別のアカウントを持つ必要が なくなる。

  • この文書は誰が読むべきものか?

    この文書はシステム管理者のためのものである。この文書は、Sambaをファイルサーバー上に実装する 予定であり、既存のWindows NT/200xユーザーを、PDCからSambaサーバーへ(比較的簡単に)統合したい 場合のものである。

用件

現在使用しているSamba設定ファイルがあるなら、バックアップを取ること!。 使用中のシステムが既にPAMを使用しているなら、 /etc/pam.dディレクトリの内容をバックアップすること!。 起動ディスクをまだ作成していないのなら今すぐに作ること!

PAM設定ファイルを間違って修正すると、使用中のマシンにログインするのがほとんど不可能に なってしまうことがある。このため、うまくいかない時にはマシンをシングルユーザーモードで 立ち上げ、/etc/pam.dを元の状態に戻せるようにすること。

Samba-3の最新バージョンには、正常に機能する winbindd daemonが含まれている。ソースコードを ダウンロードする手順については、 Samba Webページか 最寄のSamba ミラーサイトにある説明を参照のこと。

ドメインユーザーがSambaの共有やファイルにアクセスできるようにし、また使用するマシンが 提供するその他のサービスにもアクセスできるようにするには、PAMを使用するマシン上で正しく 設定しなければならない。Winbindモジュールをコンパイルするには、PAM開発ライブラリを インストールすべきである。 PAMのウェブサイトを参照のこと。

テスト

開始する前に、使用しているサーバー上で走っている全てのSamba関連のデーモンを止めておくことを 推奨する。動いているかもしれないsmbdnmbd、及びwinbinddの全プロセスを停止する。 PAMを使用するには、PAMを認識するサービスが使用するPAMモジュール、複数のPAMライブラリ、及び PAMのための/usr/doc/usr/manのエントリを含む、 /etc/pam.dのディレクトリ構造を提供する、標準PAM パッケージを持って いることを確認する。WinbindをSamba内で構築する際、pam-devel パッケージをインストールして いると、よりうまくいく。このパッケージには、PAMを認識するアプリケーションをコンパイルする のに必要なヘッダーファイルが含まれる。

nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する

PAMは、最新世代のUNIX/Linuxシステムの標準コンポーネントである。しかし、残念ながら PAM対応のSambaを構築するのに必要なpam-develライブラリをインストール しているシステムは数が限られている。また、Samba-3はWinbindファイルを使用中のシステム上の 正しい位置に自動インストールするかもしれない。そこでこれ以上先に進む前に、以下に説明する 設定が本当に必要かどうか確認すること。もしかしたら、 /etc/nsswitch.confの設定だけで済むかもしれない。

winbindd daemonをnsswitch経由で走らせるために必要なライブラリを正しい場所にコピー しなければならない:

root# cp ../samba/source/nsswitch/libnss_winbind.so /lib

また、以下のシンボリック・リンクを作成することが必要である:

root# ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2

さらに、Sun Solarisの場合は以下が必要である:

root# ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1
root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1
root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2

次に、rootになって、winbindd daemonからユーザーやグループのエントリが見えるように、 /etc/nsswitch.confを編集する。たとえば/etc/nsswitch.conf ファイルを以下のように編集する:

passwd:     files winbind
shadow:     files
group:      files winbind

winbindd daemonが必要とするライブラリは、次回システムが再起動する とき、自動的にldconfigのキャッシュに入るが、手動で以下を行う方が 早い(それに、再起動する必要もない):

root# /sbin/ldconfig -v | grep winbind

これにより、winbinddがlibnss_winbindを使える状態になり、 dynamic link loaderによって使われる現在の検索パスを返す。ldconfig コマンドの出力にgrepフィルタを適用することで、このライブラリが 本当にdynamic link loaderによって認識されるかの確証を確認できる。

Sun Solarisのダイナミックリンクローダー管理ツールはcrleと呼ばれる。 このツールは元々のOS環境の一部として提供されていないライブラリファイルを含む ディレクトリを検索するよう指示するために必要である。以下の例は、ダイナミックリンク ローダーの検索パスに、どのようにして/usr/local/libディレクトリを 追加するために使うかを示す:

root#  crle -u -l /usr/lib:/usr/local/lib

引数なしで実行した場合、crleは現在のダイナミックリンクローダーの 設定を表示する。それは以下の通り:

root#  crle

Configuration file [version 4]: /var/ld/ld.config
  Default Library Path (ELF):   /lib:/usr/lib:/usr/local/lib
  Trusted Directories (ELF):    /lib/secure:/usr/lib/secure  (system default)

Command line:
  crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib

これから、/usr/local/libディレクトリは、オブジェクトモジュールの 依存関係を満足させるために、ダイナミックリンクライブラリの検索中に含まれていることが わかる。

AIXにおけるNSS Winbind

(この節はAIXを動作させている人にのみ関係する。)

Winbind AIX識別モジュールは、Sambaソースのnsswitchディレクトリ内に libnss_winbind.soとして構築される。このファイルは、 /usr/lib/securityにコピーでき、AIXの名前変換から、WINBIND という名前にするべきであると指示してくる。次の節では、以下のようにして、

WINBIND:
        program = /usr/lib/security/WINBIND
        options = authonly

/usr/lib/security/methods.cfgが追加できるようなる。このモジュールは 識別のみサポートするが、標準のWinbind PAMモジュールを認証に使用して成功した例が報告されて いる。ローダブルな認証モジュール設定の際には、システムにログオンできない状態になって しまうこともあり得るので、慎重に行なうこと。AIX認証モジュールAPIに関する詳細情報は、 AIXのための、 Loadable Authentication Module Programming Interfaceで記述されている、 Kernel Extensions and Device Support Programming Concepts for AIX という文書にある。モジュールの管理に関するさらなる情報は、 System Management Guide: Operating System and Devicesにある。

smb.confの設定

winbinddの動作を制御するために、smb.confファイルにいくつかのパラメーターを設定する必要が ある。これについては、winbindd(8)マニュアルページに、より詳細に説明されている。 以下のWinbind設定のためのsmb.confによるsmb.confは、 [global]セクションの中の必要なエントリーも含むように変更したものである。

Example 24.1. Winbind設定のためのsmb.conf

[global]
# DOMAIN\username のように、ドメインとユーザー名を '\'を挟んで分ける。
winbind separator = \
# ドメインユーザーには、10000から20000のUIDを使用する。
idmap uid = 10000-20000
# ドメイングループには、10000から20000のGIDを使用する。
idmap gid = 10000-20000
# winbindユーザーとグループの列挙を可能にする。
winbind enum users = yes
winbind enum groups = yes
# winbind ユーザーに本当のシェルを与える(telnetアクセスを持つ場合のみ必要)
template homedir = /home/winnt/%D/%U
template shell = /bin/bash

SambaサーバーをPDCドメインに参加させる

ドメインセキュリティに関与するすべてのマシンはドメインのメンバーであるべきである。 これはPDCとすべてのBDCにも適用される。

ドメインへの参加手続きは、net rpc joinコマンドを使って行う。この 手続きは、MS DCE RPC経由で登録された(通常はPDC)ドメインコントローラーと通信を行う。これは、 もちろん、smbdプロセスが対象のドメインコントローラー上で動作 していなければならないということである。それ自身のドメインに参加できるように、一時的に PDCとしてSambaを起動することは、そのために必要である。

PDCという名前のPDCで、ドメイン中で管理者権限を持つドメイン ユーザーがAdministratorである時、以下のコマンドを入力し、 Sambaサーバーをドメインに参加させる。

Note

ドメインにマシンを参加させる前に、対象のドメインコントローラー(通常はPDC)でSambaが 動作しているかを確認し、ポート137/udp, 135/tcp, 139/tcp, と 445/tcpが開いているかを 確認する(もしもPDCがSambaかWindows Server 2Kxの場合)。

net rpc join機能の使用方法は以下の通り:

root# /usr/local/samba/bin/net rpc join -S PDC -U Administrator

このコマンドへの正しい解答は、Joined the domainDOMAIN である。ここで、DOMAINは対象のドメイン名である。

winbindddaemonの開始とテスト

最終的には、Sambaのその他の部分が立ち上がるときに、自動的にwinbindd daemonを呼び出す ように、Sambaの起動スクリプトを変更したいと思うかもしれないが、Winbind部分だけを最初に テストしておくことは可能である。Winbind のサービスを立ち上げるには、以下のコマンドを rootとして入力する:

root# /usr/local/samba/sbin/winbindd

winbindd実行ファイルの位置への適切なパスを使用すること。

Note

上記は、/usr/local/sambaのディレクトリツリーの中にSamba を インストールしたと仮定している。使用するシステム上でwinbinddが別の 所にある場合は、Sambaファイルの位置を探す必要がある。

心配性な人の場合、daemonが本当に動いているかは以下で確認出来る。

root# ps -ae | grep winbindd

このコマンドは、daemonが動いているなら、以下のような結果を返してくるはずである。

3025 ?        00:00:00 winbindd

次に、本当のテスト用に、PDC上にあるユーザー情報を取得する:

root# /usr/local/samba/bin/wbinfo -u

これは、PDC上のWindowsユーザー情報に入っているユーザーの一覧をエコーバックするはずである。 例えば、以下のような結果が表示される:

CEO\Administrator
CEO\burdell
CEO\Guest
CEO\jt-ad
CEO\krbtgt
CEO\TsInternetUser

もちろん、ドメイン名はCEOで、winbind separator\である。

同様にPDCからグループ情報を取得することができる:

root# /usr/local/samba/bin/wbinfo -g
CEO\Domain Admins
CEO\Domain Users
CEO\Domain Guests
CEO\Domain Computers
CEO\Domain Controllers
CEO\Cert Publishers
CEO\Schema Admins
CEO\Enterprise Admins
CEO\Group Policy Creator Owners

ここで、getentコマンドを使用して、ローカルとPDCの両方からユーザーと グループの統合された一覧を表示させることができる。以下のコマンドを入力する:

root# getent passwd

/etc/passwdのような、ドメインユーザーの新しいUID、GID、 ホームディレクトリ及び既定値のシェルが表示される一覧が出てくるはずである。

グループについても同様に以下のコマンドを実行できる:

root# getent group

init.d起動スクリプトの修正

Linux

winbindd daemonはsmbdnmbd daemonが動き出してから起動する必要がある。これを 行うには起動スクリプトを書き換える。それは、Red Hat Linuxでは /etc/init.d/sambaにあり、Debian Linuxでは /etc/init.d/sambaにある。これらのdaemonを正しい順序で走らせる ためのコマンドをスクリプトに加える。たとえば、起動スクリプトの例としては、 smbd, nmbd, と winbinddを直接/usr/local/samba/binディレクトリ から起動する。このスクリプト中のstart関数は以下の通り:

start() {
        KIND="SMB"
        echo -n $"Starting $KIND services: "
        daemon /usr/local/samba/bin/smbd $SMBDOPTIONS
        RETVAL=$?
        echo
        KIND="NMB"
        echo -n $"Starting $KIND services: "
        daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS
        RETVAL2=$?
        echo
        KIND="Winbind"
        echo -n $"Starting $KIND services: "
        daemon /usr/local/samba/sbin/winbindd
        RETVAL3=$?
        echo
        [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \
		touch /var/lock/subsys/smb || RETVAL=1
        return $RETVAL
}

winbindd をデュアル・デーモン・モードで走らせたい場合は、上記例の中の:

        daemon /usr/local/samba/sbin/winbindd

の列を、以下に変える:

        daemon /usr/local/samba/sbin/winbindd -D

.

stop関数は、サービスを停止するために以下のように起動に対応するエントリを持つ:

stop() {
        KIND="SMB"
        echo -n $"Shutting down $KIND services: "
        killproc smbd
        RETVAL=$?
        echo
        KIND="NMB"
        echo -n $"Shutting down $KIND services: "
        killproc nmbd
        RETVAL2=$?
        echo
        KIND="Winbind"
        echo -n $"Shutting down $KIND services: "
        killproc winbindd
        RETVAL3=$?
        [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \
		 rm -f /var/lock/subsys/smb
        echo ""
        return $RETVAL
}
Solaris

WinbindはSolaris 9では動作しない。 see Solaris 9でのWinbindの節を参照のこと。 for details.

Solarisでは、/etc/init.d/samba.server起動スクリプトを変更する必要が ある。また、通常は smbd と nmbdのみを起動するが、winbinddも起動すべきである。Sambaが /usr/local/samba/binにインストールされている場合、このファイルには 以下のようなものを含むことが出来る:

	##
	## samba.server
	##

	if [ ! -d /usr/bin ]
	then                    # /usr がマウントされていない
		exit
	fi

	killproc() {            # 名前指定でプロセスを停止
		pid=`/usr/bin/ps -e |
		     /usr/bin/grep -w $1 |
		     /usr/bin/sed -e 's/^  *//' -e 's/ .*//'`
		[ "$pid" != "" ] && kill $pid
	}

	# Sambaサーバーに必要な起動/停止プロセス

	case "$1" in

	'start')
	#
	# 使用環境(パス、ワークグループ、ホスト)に合わせて以下を編集すること
	#
	echo Starting SMBD
	   /usr/local/samba/bin/smbd -D -s \
		/usr/local/samba/smb.conf

	echo Starting NMBD
	   /usr/local/samba/bin/nmbd -D -l \
		/usr/local/samba/var/log -s /usr/local/samba/smb.conf

	echo Starting Winbind Daemon
	   /usr/local/samba/sbin/winbindd
	   ;;

	'stop')
	   killproc nmbd
	   killproc smbd
	   killproc winbindd
	   ;;

	*)
	   echo "Usage: /etc/init.d/samba.server { start | stop }"
	   ;;
	esac

繰り返すが、Winbindをデュアルdaemonモードで動かしたい場合、上記の:

/usr/local/samba/sbin/winbindd

の部分を、下記に変える:

/usr/local/samba/sbin/winbindd -D

再起動

この時点でsmbd, nmbd, と winbindd daemonを再起動すると、まるでローカルユーザーで あるかのように、Sambaサーバーにドメインメンバーとして接続できるはずである。

WinbindとPAMの設定

ここまで来たということは、winbinddとSambaが一緒に動作している状態に なったと言うことである。Winbindを使用して、他のサービスに認証を提供できるようにしたい 場合は、この先を読み進めること。PAMの設定ファイルを、この手順の中で変更する必要が出て くる(現在使っている/etc/pam.dファイルのバックアップを取っていない ならば、今行うこと)。

他のサービスでwinbinddを使用するためのPAM モジュールが必要になる。このモジュールは、 以下のコマンドで、../sourceディレクトリから ../source/nsswitchディレクトリにコンパイルされる:

root# make nsswitch/pam_winbind.so

pam_winbind.soファイルは、他のPAMセキュリティモジュールのある 場所にコピーしなければならない。Red Hat システムでは、/lib/security というディレクトリである。Solaris では、PAMセキュリティモジュールは、 /usr/lib/securityに入る。

root# cp ../samba/source/nsswitch/pam_winbind.so /lib/security

Linux/FreeBSD固有のPAM設定

/etc/pam.d/sambaファイルは変更する必要がない。このファイルはそのまま残す:

auth    required  /lib/security/pam_stack.so service=system-auth
account required  /lib/security/pam_stack.so service=system-auth

Winbindを認証サービスに使用できるように手を加えたその他のサービスは、コンソール上の通常 ログイン(またはターミナルセッション)、telnetログイン、それにftpサービスである。これらの サービスを有効にするには、まず、/etc/xinetd.d(または /etc/inetd.conf)の中のエントリを変更する必要があるかも知れない。 Red Hat Linux 7.1以降のバージョンは、新しい xinetd.d 構造を使用しており、この場合、 /etc/xinetd.d/telnet/etc/xinetd.d/wu-ftp の中の文字列を

	enable = no

から

	enable = yes

に変更する必要がある。

ftpサービスを動作させるためには、既にサーバー上に存在するドメインユーザーのために、個別に ディレクトリを用意するか、ホームディレクトリを全ドメインユーザー用の汎用ディレクトリに 変更する必要がある。これらは、smb.conftemplate homedir グローバルエントリで簡単に設定できる。

Note

template homedir中のディレクトリは、自動的には生成されない! pam_mkhomedirか、あらかじめ当該ユーザーに対してディレクトリを作成しておくようにして、 固有のホームディレクトリを使ってUNIXにログインできるようにすること。

/etc/pam.d/ftpファイルは、/etc/pam.d/samba ファイルと似たような形で、Winbindのftpアクセスを許可するように変更できる。変更後の /etc/pam.d/ftpファイルは以下の通り:

auth       required     /lib/security/pam_listfile.so item=user sense=deny \
	 file=/etc/ftpusers onerr=succeed
auth       sufficient   /lib/security/pam_winbind.so
auth       required     /lib/security/pam_stack.so service=system-auth
auth       required     /lib/security/pam_shells.so
account    sufficient   /lib/security/pam_winbind.so
account    required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

/etc/pam.d/loginファイルもほぼ同様に変更できる。以下のようになる:

auth       required     /lib/security/pam_securetty.so
auth       sufficient   /lib/security/pam_winbind.so
auth       sufficient   /lib/security/pam_unix.so use_first_pass
auth       required     /lib/security/pam_stack.so service=system-auth
auth       required     /lib/security/pam_nologin.so
account    sufficient   /lib/security/pam_winbind.so
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth
session    optional     /lib/security/pam_console.so

この場合、前述のように

auth sufficient /lib/security/pam_winbind.so

を追加するが、それに加え

required pam_securetty.so

を加えることにより、ネットワーク上からのrootのログインを不許可とした。また、

sufficient /lib/security/pam_unix.so use_first_pass

行をwinbind.so行の後に加え、パスワードからのプロンプトが二重表示される 問題を解消した。

Solaris固有の設定

/etc/pam.confの変更が必要である。ドメインユーザーがローカルにも telnetでもログオンできるように変更する。以下が変更内容である。pam.conf を要件に沿ってカスタマイズしてもよいが、最悪の場合、システムがほとんど起動不能になることが あるので、変更内容に十分自信がある場合のみ変更すること。

#
#ident "@(#)pam.conf 1.14 99/09/16 SMI"
#
# Copyright (c) 1996-1999, Sun Microsystems, Inc.
# All Rights Reserved.
#
# PAMの設定
#
# 認証管理
#
login   auth required   /usr/lib/security/pam_winbind.so
login auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
login auth required  /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass
#
rlogin  auth sufficient /usr/lib/security/pam_winbind.so
rlogin  auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1
rlogin auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
#
dtlogin auth sufficient /usr/lib/security/pam_winbind.so
dtlogin auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
#
rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1
other   auth sufficient /usr/lib/security/pam_winbind.so
other auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass
#
# アカウント管理
#
login   account sufficient      /usr/lib/security/pam_winbind.so
login account requisite /usr/lib/security/$ISA/pam_roles.so.1
login account required /usr/lib/security/$ISA/pam_unix.so.1
#
dtlogin account sufficient      /usr/lib/security/pam_winbind.so
dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1
dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1
#
other   account sufficient      /usr/lib/security/pam_winbind.so
other account requisite /usr/lib/security/$ISA/pam_roles.so.1
other account required /usr/lib/security/$ISA/pam_unix.so.1
#
# セッション管理
#
other session required /usr/lib/security/$ISA/pam_unix.so.1
#
# パスワード管理
#
#other   password sufficient     /usr/lib/security/pam_winbind.so
other password required /usr/lib/security/$ISA/pam_unix.so.1
dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1
#
# Kerberos V5 認証のサポート(Kerberosを使用するにはアンコメントすること)
#
#rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
#login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
#dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
#other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
#dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1
#other account optional /usr/lib/security/$ISA/pam_krb5.so.1
#other session optional /usr/lib/security/$ISA/pam_krb5.so.1
#other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass

さらに、winbind.so行の後にtry_first_pass 行を追加することで、パスワードからのプロンプトが二重表示される問題を解消する。

Sambaを再起動して、pam.confで設定したアプリケーションから接続してみる。

結論

Winbindシステムは、NSSとPAM及び適切なMicrosoft RPCコールを使用することで、UNIXシステム 上のMicrosoft Windows NTドメインユーザーのシームレスな統合を可能にした。その結果、UNIXと NTの混在するネットワークを運用する管理コストの大幅削減が実現さた。

よくあるエラー

Winbindは、現在のリリース版には、幾つかの制約があり、これは将来の リリースで克服していきたいと考えている:

  • Winbindは、現行では、他のOSへの移植は可能だが、Linux、Solaris、AIX、 及びIRIXのOSでのみ使用可能である。このような移植を実現するには、移植先の OSのCライブラリが、NSSとPAMシステムをサポートしていることが要件となる。 NSSとPAMがUNIXベンダの間でサポートを得るようになってきたので、この二つの サポートは以前より一般的に見られるようになった。

  • Windows NT RIDからUNIX IDへのマッピングは、 アルゴリズムで決められる のではなく、マッピングされていないユーザーとグループをWinbindが目にした 順番に番号を振っていく。そのため、RIDとUNIX IDのマッピング情報を持つ ファイルが不良になったり壊れたりした場合、前と同じマッピングを再現 することは難しいかもしれない。

  • 現行では、Winbind PAMのモジュールは、Windows NTユーザーに対して設定される ワークステーションのログオン時間などの制約を考慮しておらず、PDC が強制 するものと想定している。

NSCDの問題に関する警告

Warning

いかなる状況でもwinbinddが動作しているシステム上で nscdを動かさないこと。

もしもnscdがUNIX/Linuxシステム上で動いている時、NSSWITCHが 正しく設定されていても、ファイルとディレクトリの管理のために、ドメインユーザーと グループを解決することはできない。

Winbindがユーザーとグループを解決しない

smb.confファイルは正しく設定した。 idmap uid = 12000idmap gid = 3000-3500を設定し、 winbindを走らせている。以下を行うとすべてうまく行く。

root# wbinfo -u
MIDEARTH\maryo
MIDEARTH\jackb
MIDEARTH\ameds
...
MIDEARTH\root

root# wbinfo -g
MIDEARTH\Domain Users
MIDEARTH\Domain Admins
MIDEARTH\Domain Guests
...
MIDEARTH\Accounts

root# getent passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/bash
...
maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false

ところが、以下のコマンドは失敗する:

root# chown maryo a_file
chown: `maryo': invalid user

気が変になりそうなのだが何がいけないのだろう?

前記の問題と同じである。使用しているシステムは、恐らくnscdを動作させて いるのだろう。システムを再起動ではなく一旦シャットダウンすれば、その後では、問題は解消して いるだろう。

Chapter 25. 詳細なネットワーク管理

John H. Terpstra

Samba Team

June 15 2005

この章では、ネットワークリソースアクセス制御を改善するためと、ユーザー環境を自動化する ためと、使用時の作業をより簡単にすることをしたいと思っているネットワーク管理者のための とても重要な周辺機器についての問題を記述する。

機能と利便性

しばしば、作業中のネットワーク環境とより理解しているものの違いは、すべてをより協調させる 小分けの観点で最もよく測れる。すべてのネットワークソリューションの 重要な部分は、リモートからMicrosoft Windowsワークステーションを管理すること、リモートで Sambaサーバーにアクセスすること、より信頼出来るネットワーク操作の場面において手助けとなる 他の保守作業と同様の、カスタマイズしたログオンスクリプトを提供することである。

この章では、それらの各領域についての情報を提供する。それらはここにあり、他の章にはなく、 そのため、参照が容易である。

リモートサーバー管理

どのようにしてユーザーマネージャとサーバーマネージャを手に入れたらよいのか?

NT4 サーバーを購入する必要がないので、どのようにしてユーザー マネージャとサーバーマネージャを手に入れたらよいのか?

Microsoftは、Windows 9x/Meシステム上でインストールするための、 Nexus.exeと呼ばれるバージョンのツールを配布している。ツールセット には、以下が含まれている:

  • サーバーマネージャ

  • ドメイン用のユーザーマネージャ

  • イベントビューワ

Microsoftの Nexus から書庫ファイルをダウンロードする。

ドメインとサーバーマネージャ用の、Windows NT 4.0バージョン用の ユーザーマネージャは、Microsoftの via ftpにある。

リモートデスクトップ管理

自由に使えるものから、費用がかかるものまでの間で、数多くのリモートデスクトップ管理 ソリューションが存在する。黙ってみていてはいけない。最も費用がかかるソリューションは えてして最も効果的なものである。どの場合も、使用しているネットワーク環境で、どれが 最も良いツールかを、自分で結論づける必要がある。

NoMachine.Comによるリモート管理

以下の情報はSambaメーリングリストに、2003年4月3日 23:33:50(UTC+00:00)に投稿 されたものである。以下は若干修正(プライバシーの理由で投稿者の詳細を省略)して ある。完全な答えは、削除したいくつかのコメントを考慮して再構成してある。

PDCとしてネットワーク上で動いている、優れたなLinux/Sambaサーバーがある。 これに、ユーザーが外部からシステムにログイン出来るようにして、家や他の 国からデスクトップ状態を使えるようにする、リモートデスクトップ機能を 追加したい。

これを達成する方法はあるだろうか?Windowsターミナルサーバーが必要だろうか? それを設定する必要があり、それはドメインのメンバーか、BDCあるいはPDCになる のだろうか?コンピュータがドメイン中にいる場合でも、Microsoft Windows XPを リモートログインにするようなhackはあるだろうか?

提供された回答: NoMachineから 提供されている新しいNXソフトウェアを申し込む。

これは、VNC/RFBとrdesktop/RDBをその中に取り込んでいる、簡単に使える、 リモートXプロトコルを実装しているが、今まで使ったことがあるかもしれない 他のものよりもパフォーマンスがよい。

リモートXは別に新しいものではないが、これが成し遂げたものは、遅いmodem/ISDN 接続上でも十分に使えるくらいのスピードを出す、新しい圧縮方法とキャッシング 技術である。

イタリアで(公開の)Red Hatマシンに対して、負荷の高いインターネット接続で、 KDE konquerorのサムネイルプレビューを有効にして、マウスを載せると その時点でポップアップするようにしてテストしてみた。その内側(リモートX)の セッションで、Windows XPマシンへののrdesktopセッションを起動した。パフォーマンスを 測ってみたところ、最初に631750ポイントというスコアが出た。

NXは、TightVNC, rdesktopやromete Xという、その時点までに使っていた他の 純粋な接続方法のどれよりも、ローカルLANよりも良いパフォーマンスを 出す。2つのノードを直接クロス接続するよりも速い。

リモートXアプリケーションから手元のマシンに対して、音を再生することも出来、 (イタリアにあるKDEセッションで動いている)NXウィンドウからMozillaメールソフトに コピーアンドペーストをする事も出来た。このソフトはとてもよく 動いている!

リモートコンピューティングに一時的な興味のみあるどなたにも、 NXを使って 見る事をお勧めする。

無料で使えるクライアントソフトウェアをダウンロードし(Red Hat、SuSE、Debianと Windows用がある)、起動し5分間使える(この時testdrive.nomachine.com上に実際の UNIXアカウントを割り当てるために、アカウントデータを送る必要がある)。

計画されている要点では、クラスターのノードとしてNXアプリケーションサーバーを 動かせるようになり、単にNXセッションをローカルに起動し、透過的に アプリケーションを動かせる(アプリケーションが他のNXノードで動いていたとしても、 同じウィンドウで表示されるために、最初のログインで使われていたのと同じように 動く。また、フルスクリーンでも動作でき、そのすぐにリモートログインしていることを 全く忘れてしまうだろう)。

最後に最も良いことを:すべての主要な圧縮とキャッシュ技術はGPLのもとでリリース され、何かに組み込もうと思う人誰にもそのソースコードが公開されている!これらの 技術はちゃんと動くが、コマンドラインのみから起動する(そして、完全に動作する リモートXセッションを起動し動かすために使うにはとても不便である)。

質問に対する回答は以下の通り:

  • ターミナルサーバーをインストールする必要はない。XPはRDPのサポートを内蔵している。

  • NXはCitrixよりも安価であり対抗できうる性能があり、おそらくより速い。

  • XPをハックする必要はない。それはちゃんと動く。

  • 透過的にリモートからXPマシンにログイン出来(そして、ドメインに対する認証が 必要だとしても、接続時に何かを変更する必要はない)。

  • NXの主要な技術はすべてオープンソースでGPLでリリースされている。 (とても不便だが)無料で、コマンドラインで使う事が出来るが、お金を出せば、 便利な(商用の)NX GUIフロントエンドを買うことが出来る。

  • そのようなフロントエンドに対する、OSS/Free Softwareでの実装に、NoMachineは 自分自身に対する競合を意味しているのにもかかわらず、力を貸し、手助けを している(このような主旨を、LTSP、KDEとGNOME開発メーリングリストにも表明 している)。

ThinLincを使うリモート管理

リモートアクセスに対する他の解は、CendioによるThinLincである。

ThxnLincは、LinuxとSolarisベースで使える、SSH、TightVNC、NFSとPulseAudioのような 標準プロトコルをベースとしたターミナルサーバーである。

ThinLincは、LAN環境において組織におけるシンクライアント運用にも、狭帯域においても 使えるリモートから仕事をする人がセキュアなリモートアクセスを行うのにも使える。 ThinLincは、単一の同時アクセスするユーザーに対して自由に使える。

プロダクトはWindowsターミナルサーバーかCitrix環境のフロントエンドとしても、 Windows XPマシンのフロントエンドとしても使え、sshプロトコル経由で接続時の安全性を 確保している。クライアントはLinux(数多くのシンクライアント端末と同様すべてのLinux ディストリビューションをサポート)とWindows用がある。JavaベースのWebクライアントも 提供されている。

ThinLincはCendioのデモシステムに接続することで評価が出来る。下記を参照。 Cendio's web サイト testdrive センタ。

Cendiaは以下を含む、いくつかのオープンソースプロジェクトにおける主要な貢献者である。 TightVNC, PulseAudio , unfsd, Pythonrdesktop.

ネットワークログオンスクリプトの魔法

固有のネットワーク設定環境を作成するための、いくつかの機会がある。

  • ログオンスクリプトなし。

  • すべてのユーザーに適用される、単純な汎用ログオンスクリプト。

  • ユーザー単位あるいはグループ単位の属性に適用する条件付きログオンスクリプトの使用。

  • 固有のログオンスクリプトを作るための、NETLOGON共有に対する アクセス上の、Sambaのpreexecとpostexec機能を使用し、それを実行。

  • kixStartのようなツールのユーザー。

Sambaソースコードの中には2つのログオンスクリプト生成/実行ツールが含まれている。 examplesディレクトリのgenlogonntlogonサブディレクトリを参照。

以下のリストはgenlogonディレクトリからのものである。

これは、genlogon.plファイルである:

	#!/usr/bin/perl
	#
	# genlogon.pl
	#
	# Perl script to generate user logon scripts on the fly, when users
	# connect from a Windows client. This script should be called from 
	# smb.conf with the %U, %G and %L parameters. I.e:
	#
	#       root preexec = genlogon.pl %U %G %L
	#
	# The script generated will perform
	# the following:
	#
	# 1. Log the user connection to /var/log/samba/netlogon.log
	# 2. Set the PC's time to the Linux server time (which is maintained
	#    daily to the National Institute of Standards Atomic clock on the
	#    internet.
	# 3. Connect the user's home drive to H: (H for Home).
	# 4. Connect common drives that everyone uses.
	# 5. Connect group-specific drives for certain user groups.
	# 6. Connect user-specific drives for certain users.
	# 7. Connect network printers.

	# Log client connection
	#($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
	($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
	open LOG, ">>/var/log/samba/netlogon.log";
	print LOG "$mon/$mday/$year $hour:$min:$sec";
	print LOG " - User $ARGV[0] logged into $ARGV[1]\n";
	close LOG;

	# Start generating logon script
	open LOGON, ">/shared/netlogon/$ARGV[0].bat";
	print LOGON "\@ECHO OFF\r\n";

	# Connect shares just use by Software Development group
	if ($ARGV[1] eq "SOFTDEV" || $ARGV[0] eq "softdev")
	{
		print LOGON "NET USE M: \\\\$ARGV[2]\\SOURCE\r\n";
	}

	# Connect shares just use by Technical Support staff
	if ($ARGV[1] eq "SUPPORT" || $ARGV[0] eq "support")
	{
		print LOGON "NET USE S: \\\\$ARGV[2]\\SUPPORT\r\n";
	}

	# Connect shares just used by Administration staff
	If ($ARGV[1] eq "ADMIN" || $ARGV[0] eq "admin")
	{
		print LOGON "NET USE L: \\\\$ARGV[2]\\ADMIN\r\n";
		print LOGON "NET USE K: \\\\$ARGV[2]\\MKTING\r\n";
	}

	# Now connect Printers. We handle just two or three users a little
	# differently, because they are the exceptions that have desktop
	# printers on LPT1: - all other user's go to the LaserJet on the
	# server.
	if ($ARGV[0] eq 'jim'
	    || $ARGV[0] eq 'yvonne')
	{
		print LOGON "NET USE LPT2: \\\\$ARGV[2]\\LJET3\r\n";
		print LOGON "NET USE LPT3: \\\\$ARGV[2]\\FAXQ\r\n";
	}
	else
	{
		print LOGON "NET USE LPT1: \\\\$ARGV[2]\\LJET3\r\n";
		print LOGON "NET USE LPT3: \\\\$ARGV[2]\\FAXQ\r\n";
	}

	# All done! Close the output file.
	close LOGON;

これらは、より精巧か、有用なログイン処理システムがそれらのサイトを確認する事を期待している:

ユーザーの干渉なしにプリンターを追加する

プリンターは以下を使用することで、ログオンスクリプト処理中に自動的に追加することが出来る:

C:\> rundll32 printui.dll,PrintUIEntry /?

ユーザーによる操作なしで Windowsにプリンターを追加する方法 を参照のこと。

ログオン接続の制限

時々、Samba共有リソースへの同時接続の数を制限することが必要な場合がある。 たとえば、ユーザー毎に1つのネットワークログインのみを、サイトが許可したいような 場合である。

Sambaのpreexec scriptパラメーターはユーザー単位に1つの接続 のみを許可するのに使える。この方法は完全に安全性があるわけではなく、副作用が あるかもしれない。以下の寄贈された方法はより良い解を誰かに思いつかさせて、 提供を促すかもしれない。

これは、Windowsクライアントが、実際にそうである間、共有をもう使っていないと 見える場合に、自動再接続機能を使って、アイドル状態の接続を切ってしまうことが 出来るという理由で完全な解ではない。そうだったとしても、これは、 preexec scriptパラメーターの使用の原理的なデモである。

以下の共有設定は“Script to Enforce Single Resource Logon”中で示されるスクリプトの使用をデモする。

[myshare]
	...
	preexec script = /sbin/PermitSingleLogon.sh
	preexec close = Yes
	...

Example 25.1. Script to Enforce Single Resource Logon

#!/bin/bash

IFS="-"
RESULT=$(smbstatus -S -u $1 2> /dev/null | awk 'NF \
        > 6 {print $1}' | sort | uniq -d)

if [ "X${RESULT}" == X  ]; then
  exit 0
else
  exit 1
fi

Chapter 26. システムとアカウントポリシー

John H. Terpstra

Samba Team

April 3 2003

この章では、Sambaメーリングリストの投稿者による、個人的な経験と知識に由来する知識の 現状について要約する。投稿された情報を再構築する前に、すべての効果に、与えられた情報 を検証することが行われた。この検証を通じては、追加の情報はカバーされていないので、 それも提供している。

機能と利便性

Microsoft Windows NT 3.5が発表された時、ホットな新しい話題は、ユーザーとグループに対する グループポリシーの実装であった。次にMicrosoft Windows NT4が来て、いくつかのサイトがこの 機能を適用し始めた。どうやって知ったかって?数多くのドジな(あるいは 間違った)管理者はそれを行い、解決のために助けを求めたからである。

Windows 2000とActive Directoryがリリースを待っている間、管理者はグループポリシーは すばらしいというメッセージを聞かされ続けた。グループポリシーにより管理コストの低減が 可能となり、確かに利用者にとってありがたい点もある。しかし、Windows 200xの Active Directory と GPO によるユーザーとコンピュータ管理機能の活用は遅々として 進まなかった。これは、2000年から2001年にかけてのSambaメーリングリストにおける 過去ログにおいて、GPOに関連した投稿や、GPOをSambaの環境でどのように複製するのかと いった投稿がほとんどなかったことからも明らかであった。

トラフィック量から判断すると、2002年中盤以降は、GPO は多くのサイトでデプロイメント(運用) の一部として普通に用いられるようになった。 本章では、ユーザーのデスクトップとネットワーク上のクライアントワークステーションの 自動制御を可能とするために用いることが可能な、テクニックと方法についておさらいする (記載する)。

システムポリシーの作成と運用

Microsoft Windowsプラットフォーム配下、特にMicrosoft NT4とMicrosoft Windows 95の リリースに従ったものは、ドメインコントローラーのNETLOGON共有中に配置できるタイプの ファイルを作成することが可能である。クライアントがネットワークにログオンすると、 このファイルは読み取られ、その内容で、クライアントマシンのレジストリの変更を開始する。 このファイルはユーザー、ユーザーのグループかマシンに影響するレジストリを変更させる ことを許可する。

Microsoft Windows 9x/Meようには、このファイルはConfig.POLと しなければならず、ポリシーエディターとしてよく知られている poledit.exeというツールを使って作成できる。ポリシーエディターは Windows 98インストール用CD-ROMで提供されているが、Microsoft Windows Meでは提供 されなくなった。Microsoft Windowsネットワーク管理者からのコメントによると、 これはMicrosoft Windows Me リソースキットに含まれるようになったとのこと。

Microsoft Windows NT4サーバー製品には、 スタート -> プログラム -> 管理ツール配下に システムポリシーエディターが含まれている。 Microsoft Windows NT4とその後のクライアント用に、このファイルは NTConfig.POLという名前にしなければならない。

Microsoft Windows 2000からは、Microsoft管理コンソールすなわちMMCが新たに導入された。 このツールは、ネットワークアクセスとセキュリティ管理方法に対して、永遠に 止めることのないマイクロソフト社の歩みの中から生まれた新しい潮流である。 マイクロソフト社の新製品や新技術が登場するたびに、以前の常識が覆され、複雑化したツールと 方法が新たに生み出されるように見える。 マイクロソフト社の立場からすると、MMCは進歩である。しかし、機能の進歩には 大きな代償が伴っているのだ。

ネットワークとシステムポリシーの設定に着手する前に、 Implementing Profiles and Policies in Windows NT 4.0 という、MicrosoftのWebサイトで提供されている文書を読むことを強く推奨する(訳注:現存しない)。 これらは、四で理解すべきである、古いものに対する大量の追加文書である。 グループポリシーをMicrosoftのWebサイト上で探してみること。

以下で説明するものは、いくつかの有用な注意事項に関する短い議論である。ここで提供される 情報は不完全であることを警告する。

Windows 9x/ME ポリシー

Windows 9x/Meは以下でWindows 98のグループポリシーエディターを使ってグループ プロファイルを作成する必要があるとする。これはオリジナルの完全なWindows 98 インストールCD-ROM配下のtools\reskit\netadmin\poledit ディレクトリ中にある。プログラムの追加と削除機能を使ってこれをインストールし、 次に、Have Diskをクリックする。

ユーザーポリシーまたはマイドキュメントなどの位置を指定する ポリシーファイルを作成するために、グループポリシーエディターを使う。次に、 [NETLOGON]共有のrootに配置する必要がある、 Config.POLというファイルにこれらの設定をセーブする。 もしもWindows98がSambaドメインにログオンするように設定されていたならば、これは 自動的にこのファイルを読み、ログオンしようとするマシンの、Windows 9x/Me レジストリを更新する。

さらなる詳細はWindows98リソースキットの文書中で説明されている。

もしも、正しい手順を踏まない場合、時々Windows 9x/Meはレジストリの正当性を検査し、 各Windows 9x/Meマシンに格納されているレジストリのバックアップコピーから、その 設定をリストアする。そのため、時々、オリジナルの設定に戻ってしまうと言うことに 気がつくだろう。

グループポリシーを適用するために、Windows 9x/Me用のグループポリシーハンドラーを インストールする。Windows 98 CD-ROMの \tools\reskit\netadmin\poleditを参照。 grouppol.infをダブルクリックして、Windows 9x/Meにグループ ポリシーをインストールする。不幸にも、これはグループポリシーを使うWindows 98/Me マシンすべてで行う必要がある。

Windows NT4形式のポリシーファイル

ntconfig.polを作成あるいは編集するために、NT4サーバーには 同梱されているが、NTワークステーションには含まれていない、 poledit.exeというNTサーバーポリシーエディターを使う必要がある。 NT4ワークステーションにもポリシーエディターはあるが、ドメインポリシーを作成する のには適していない。さらに、Windows 95のポリシーエディターはNT4ワークステーション あるいはサーバーにインストールできるが、NTクライアントではこれは動作しない。 しかし、NTサーバーからのファイルはNT4ワークステーション上でも問題なく動く。

poledit.exe, common.admwinnt.admを必要とする。2つの*.adm ファイルをc:\winnt\infに配置するのは、プログラムが他の場所を 指定されない限り既定値で探しに行く場所であるので、都合がよい。このディレクトリは 通常hiddenである。

Windows NTポリシーエディターは、Windows NT4.0のサービスパック3(とそれ以降)にも 同梱されている。servicepackname /xを使ってファイルを 解凍する。たとえばサービスパック6aではNt4sp6ai.exe /x である。ポリシーエディターpoledit.exeと関連するテンプレート ファイル (*.adm)が解凍される。office97用のテンプレートファイルとポリシーエディターの コピーをダウンロードすることも可能である。他の場所としては、Microsoftから ダウンロードできるZero Administration Kitがあげられる。

腐ったレジストリ

NT4形式ベースのポリシーの変更で、大量の設定は自動的にユーザーのログオフでは 戻されない。NTConfig.POLファイル中にある設定は クライアントマシンのレジストリに適用され、細かな項目がたくさんある HKEY_LOCAL_MACHINEキーへの適用は、明示的に戻されない限りそのままになる。 これは入れ墨として知られている。これはその下部に対して重大な影響を及ぼす 事が可能となり、管理者は後々そのマシンのを管理する能力を失わないように、 とても注意しなければならない。

Microsoft Windows 200x/XP Professionalのポリシー

Windows NTpシステムポリシーは、NT4形式のドメイン中のメンバーである、ユーザー、 グループとコンピュータ(クライアントワークステーション)に指定するレジストリ パラメーターの設定が出来る。このようなポリシーファイルはMicrosoft Windows 200x/XP でも動作する。

Microsoft Windows 2000では、最近新たにNT4形式のポリシーと比べて上位互換の機能を 提供する、形式のグループポリシーを導入した。もちろん、ポリシーを作るツールは 異なり、それを実装するメカニズムはもっと改良されている。

古いNT4形式のレジストリベースポリシーは、Microsoft Windows 2000/XP GPO中では 管理用テンプレート(Administrative Templates)として 知られている。前者は種々のセキュリティ設定の設定機能、インターネット エクスプローラーの設定の強制、ユーザーデスクトップ(スタートメニュー中に現れる メニュー項目に設定されるのと同じようなマイドキュメント ファイルの配置を含む)の変更と外観の切り替え(redirect)を含む。 追加の新しい機能は、特定のWindowsアプリケーションソフトを特定のユーザー/グループに 有効化する事を行うことである。

思い出してほしいが、NT4のポリシーファイルはNTConfig.POL という名前で、ドメインコントローラー上のNETLOGON共有のルートに格納される。Windows NT4 ユーザーはユーザー名とパスワードを入力し、ログオンを行うドメイン名を選択する。ログオン プロセス処理の間、クライアントマシンは、認証サーバー上のNETLOGON共有から NTConfig.POLを読み、このファイル中にある設定に従い、ローカルの レジストリ値を変更する。

Windows 200x GPOは機能がたくさんある。これらは、NETLOGON共有には格納されないが、 一部はActive Directoryそれ自身にWindows200x ポリシーファイルとして格納され、 残りはSYSVOLフォルダーと呼ばれる共有(かつ複製される)ボリューム中に格納される。 このフォルダーはすべてのActive Directoryドメインコントローラー上に存在する。 Active Directoryそれ自身に格納される部分は、グループポリシーコンテナ(GPC)と 呼ばれ、SYSVOLと呼ばれる複製された共有中に格納されるものは、グループポリシー テンプレート(GPT)として知られる。

NT4クライアントでは、ポリシーファイルは読み取られるが、各ユーザーがネットワークに ログオンする時のみ実行される。Microsoft Windows 200xポリシーは、もっと 複雑である。GPOはクライアントマシン起動時(マシン固有の部分)で処理、 適用され、ユーザーがネットワークにログオンする時、ユーザー個別の部分が適用される。 Microsoft Windows 200x形式のポリシー管理では、各マシンあるいはユーザーは、 限りなく多くの、同時に適用可能な(かつ、適用される)ポリシーセット(GPO)の適用を 受けるかもしれない。NT4形式のポリシーファイルでは、これと同様の能力をもつものは 存在しない。

Windows 200x/XPポリシーの管理

システムポリシーエディターというツールを使う代わりに、 通常はPoledit(バイナリファイルはpoledit.exe)を使い、 以下のように、 Microsoftマネジメントコンソール(MMC) スナップインを使って、GPOsの作成と管理を行う:

  1. Windows 200x/XPメニューから スタート->プログラム->管理ツールとたどり、 Active Directoryユーザーとコンピュータ というMMCスナップインを選択する。

  2. 管理したいドメインまたはorganizational unit (OU)を選択し、次に、 そのオブジェクトのコンテキストメニューを開くために右クリックし、 プロパティを選択する。

  3. グループポリシータブ上で左クリックし、次に、 新規タブ上で左クリックする。作成したい新しいポリシーの名前を 入力する。

  4. 編集タブで左クリックし、GPOを作成するために 必要なステップを開始する。

すべてのポリシー設定オプションはポリシー管理テンプレートを使用する ことによって制御される。NT4と同様Windows 200xでも、これらのファイルは 拡張子として.admを使う。しかしながら、.admファイルはNT4とWindows 200x 間で相互交換可能ではないことに注意。後者は拡張された定義を行えるような たくさんの新しい機能を導入している。どのように.admファイルをプログラム するかについて説明することは、この文書の範囲外である。それについては、 使用しているMicrosoft Windowsの、特定のバージョンに対する Microsoft Windowsリソースキットを参照のこと。

Note

Microsoft Windows 2000リソースキットには、gpolmig.exe というツールが入っている。このツールはNT4のNTConfig.POL ファイルをWindows 200x形式のGPOに変換するのに使える。どのようにこの強力な ツールを使うかについては十分に注意すること。特定の使用に関する情報については、 リソースキットのマニュアルを参照してほしい。

固有のシステムポリシーテンプレート

過去一年にわたって、Windows システムポリシーのための固有のテンプレートの 作成に関するいくつかの議論があった。Sambaメーリングリスト上での最近の 通知は言及に値する。

Mike Petersenは彼が作成したテンプレートファイルの有効性を通知した。この 固有のシステムポリシーエディターテンプレートは、SambaのようなSMBサーバーから Microsoft Windows ワークステーションを問題なく制御することができる。 このテンプレートは、いくつかのネットワーク上でテストされたが、 もしも、それらのポリシーについて何らかの問題を見つけたか、追加のポリシーに 関する何らかの案があったとしたら、mgpeter@pcc-services.comまでメールを 送って教えてほしい。このテンプレートはWindows XP用の数多くのポリシーを 含み、業務用の環境ではもっとよく動くようになっている。

さらなる情報については、 Petersen Computer Consulting Webサイトを参照してほしい。テンプレートファイルへの ダウンロードリンクがある。

アカウント/ユーザーポリシーの管理

ポリシーは、特定のユーザーの設定か、ユーザーのグループの設定を定義できる。結果のポリシー ファイルには、ポリシーファイルを使う、すべてのユーザー、グループとコンピュータ用の レジストリ設定が含まれる。各ユーザー、グループあるいはコンピュータ用にポリシーファイルを 分けることは不要である。

もしも、認証されたドメインコントローラーから自動的にダウンロードされるポリシーファイルを 作成したら、NTConfig.POLと名前を付けるべきである。システム管理者には ポリシーファイルの改名オプションがあり、Windows NTベースのワークステーションを 変更することで、マニュアルパス経由でポリシーファイルのするためにコンピュータを制御する。 手動でレジストリを変更するか、システムポリシーエディターを塚'ってこれを行うことが出来る。 これは、各マシンがその固有のポリシーファイルを持つようなローカルパスでも問題ないが、 もしも、すべてのマシンに対して変更が必要であれば、各ワークステーションに対して個別に 行わなければならない。

Windows NT4/200x/XPマシンがネットワークにログオンするとき、クライアントは、 NTConfig.POLファイルが存在するかどうかを、認証するドメイン コントローラー上のNETLOGON共有中で捜す。もしも存在するならば、それをダウンロードし、 解析し、レジストリのユーザー部分に適用する。

Microsoft Windows Active DirectoryドメインにログオンするMicrosoft Windows 200x/XP クライアントはActive Directoryそれ自身に定義され格納されるGPOを使って、さらに ポリシーの設定を要求するかもしれない。ADのGPOを使う最も重要な利点は、 レジストリを汚染する効果がない言うことである。 これはNTConfig.POL(NT4)形式のポリシー更新の使用と比較して 考慮すべき利点である。

さらに追加で、ユーザープロファイルと結合して動作する方法で、システムあるいは グループポリシー経由で、設定あるいは強制されるかもしれないアクセス制御の 追加においてMicrosoft Windows NT4/200x/XP下のユーザー管理環境は、ユーザー単位の アカウント制限が手cきょうされるのと同様に、ドメイン単位でもできる。 よく使われる共通の制限は以下のものがある:

  • ログオン時間

  • パスワードのエージング

  • 特定のマシンからのログオンのみ許可

  • アカウントタイプ(ローカルまたはグローバル)

  • ユーザーの権限

Samba-3.0.20は、まだMicrosoft Windows NT4/200x/XPで共通なすべてのアカウント制御を実装 していない。Microsoft Windows NTp用のドメインユーザーマネージャを使って多くの制御を 設定する間、パスワード満了機能のみが現在使える。現時点で残りの制御の大半は、実際の 制御を提供するように、完了されるかもしれないダミーのルーチンである。NT4ドメイン ユーザーマネージャを使うかNTConfig.POL中でパラメーターが 設定できることから、誤解してはいけない。

管理ツール

グループポリシーを作成するか管理しようと思っている人は誰でも、いくつかのツールについて 慣れておく必要がある。以下の節では、余りメンテナンスをしないユーザー環境を作成するための 手助けとなる、主要なツールについて説明する。

SambaのEditregツールセット

editregと呼ばれる新しいツールが開発中である。このツールは、 ユーザーとグループプロファイル中に格納される(NTUser.DATと 呼ばれる)レジストリファイルを編集するのに使える。NTConfig.POL ファイルはNTUser.DATファイルと同じ構造を持ち、このツールを 使って編集できる。editregは、NTConfig.POL ファイルをテキスト形式でセーブすることが出来るように意図し、拡張された機能を含む 新しいNTConfig.POLファイルを構築する事を出来るように作成されて いる。この機能を実現するのは困難であることは分かっているので、もしもこの機能が 実現しなくとも驚かないでほしい。公に使える機能は、このツールの正式版がリリースされた 時に公開される。

Windows NT4/200x

Microsoft Windows環境からこれらのタイプの制御を設定するために使えるかもしれない ツールは、NT4ドメインユーザーマネージャ、NT4システムおよびグループポリシーエディター、 およびレジストリエディター(regedit32.exe)である。Microsoft Windows 200x/XP配下では これは、MMCに対して適切なスナップイン、レジストリエディター、および、 もしかするとNT4システムとグループポリシーエディターを使って行える。

Samba PDC

Sambaドメインコントローラーでは、ユーザーアカウントとポリシー情報の管理のための 以下の新しいツールが含まれている: With a Samba domain controller, the new tools for managing user account and policy information include: smbpasswd, pdbedit, net, と rpcclient。 管理者はこれらのツールのマニュアルページを読み、使用法に慣れるべきである。

システムスタートアップとログオン処理の概要

以下は、システムの処理の順番と、システムの再起動とユーザーログオンの一部として処理される、 処理の順番を説明する試みである:

  1. ネットワークが起動し、次にリモートプロシジャーコールシステムサービス(RPCSS)と multiple universal naming convention provider (MUP)が起動する。

  2. Active Directory を使う場合、GPOの整列された一覧がダウンロードされて適用される。 リストは以下のGPOを含んでいても余韻

    • ディレクトリ中のマシンの配置を適用(Apply to the location of machines in a directory)。

    • 設定が変更されたときのみ適用(Apply only when settings have changed)。

    • 適用範囲の設定に依存:local,site,domain,organizational unitなど。

    どのデスクトップユーザーインタフェースも、上記が処理されるまで提供されない。

  3. スタートアップスクリプトの実行(既定値ではhiddenとsynchronous)。

  4. ログオンを行うためのキーボード操作(Ctrl-Alt-Del)。

  5. ユーザーの認証情報が検証され、ユーザープロファイルがロードされる(ポリシー設定に依存)。

  6. ユーザーGPOの整列された一覧を入手する。一覧の内容は、以下の点で何が含まれているかに依存する:

    • ユーザーがドメインのメンバーか、結果、特別なポリシーの適用を受けるか?

    • Loopback enablement, and the state of the loopback policy (併合または置換)。

    • Active Directoryそれ自身の位置

    • GPOの一覧が変更されたか?もしも変更されていないならば、処理は不要である。

  7. Active Directoryからのユーザーポリシーが適用される。注意:いくつか種類がある。

  8. ログオンスクリプトが動く。Windows 200xとActive Directoryから新規に、ログオン スクリプトはGPOをベースにして得られるかもしれない(hiddenとsynchronouslyに実行)。 NT4形式のログオンスクリプトは通常のウィンドウで動作する。

  9. GPOから決定されたユーザーインタフェースが提供される。注意:Sambaドメイン中では (NT4ドメインのように)、マシン(システム)ポリシーは起動時に適用される。 ユーザーポリシーはログオン時に適用される。

よくあるエラー

ポリシーに関連する問題は、診断するのがとても難しく、さらに修正するのがもっと難しい 可能性がある。以下の項目は、基本的な問題のみを示している。

ポリシーが動かない

Config.POLファイルを作成し、NETLOGON 共有に置いた。が、Windows XP Proマシンでは、それが見えていないような感じで、何ら 違いがなかった。Windows 98では正しく動作したが、Windows XP Proにアップグレードして からはもはや動かなくなった。何かヒントはないか?

ポリシーファイルはWindows 9x/MeとMicrosoft Windows NT4/200x/XPベースのプラットフォーム の間では互換性がない。NTConfig.POLというファイルをNT4の グループポリシーエディターで作成する必要があり、そうすると、Microsoft Windows XP Pro クライアント用の正しい形式になる。

Chapter 27. デスクトッププロファイルの管理

John H. Terpstra

Samba Team

April 3 2003

その特長と利点

移動プロファイルは一部の人にとっては恐れられており、 これを忌み嫌う人もいないではないが、また多くの人に愛されてもいる。 これを天の恵みだと考えている管理者もいる。

ユーザーが使用するマシンを毎回変えるような環境であっても、ローミング プロファイルを使えば管理者は常に同じユーザーデスクトップ環境を提供できる。 この章では移動プロファイルの構成と管理の手法に関する多くの情報を 提供する。

移動プロファイルはある種、楽園のように聞こえる人もいるかも しれないが、その他の人々にとっては、これは現実の、そして目に見える 問題でもある。特に、接続状態が安定しないモバイルコンピューティング 機器を利用するユーザーは、純粋なローカルプロファイルを使うケースが 多いであろう。この章では Samba の管理者がこのような状況に対処する ための手助けになるような情報を提供する。

移動プロファイル

Warning

移動プロファイルのサポートは、Windows 9x/Me と Windows NT4/200x でそれぞれ異なる。

移動プロファイルの構成方法について論じるのに先立って、 Windows 9x/Me と Windows NT4/200x クライアントが、それぞれどのように これらの機能を実装しているのかを知ることもまた有用であろう。

Windows 9x/Me クライアントは NetUserGetInfo リクエストをサーバーに送り、 ユーザープロファイルの場所を取得する。しかしながら、その応答の中には 分割されたプロファイルの位置を保持するためのフィールドを格納する領域はなく、 単にそのユーザーの home 共有が渡されるだけである。つまり、Windows 9x/Me のプロファイルでは、プロファイルをユーザーのホームディレクトリーに格納する ことしかできない。

Windows NT4/200x クライアントは NetSAMLogon RPC リクエストを送る。 これには多くのフィールドがあり、分割されたユーザープロファイルの位置を表す 情報も含まれている。

プロファイル処理のための Samba の設定

この章では MS Windows クライアントのプロファイルサポートのための Samba の設定について解説する。

NT4/200x のユーザープロファイル

たとえば、Windows NT4/200x をサポートする場合、以下の設定を smb.conf ファイルの [global] セクションに書けばよい。

logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath

これは一般に以下のような実装を表している:

logon path = \\%L\Profiles\%U

ここで%Lは Samba サーバーの名前に置き換えられ、 %Uはユーザー名に置き換えられる。

このオプションのデフォルトは \\%N\%U\profile すなわち \\sambaserver\username\profile である。 \\%N\%U サービスは [homes] サービスにより 自動的に生成される。Samba サーバー経由でプロファイルを使う場合は、 logon path で指定された共有をブラウズ可能にしておかなければならない。 %L%N の違いや %U%u の違いについては smb.conf の man ページを参照してほしい。

Note

MS Windows NT/200x クライアントは、時々ログオン完了後もサーバーへの コネクションを切断しないことがある。プロファイルの共有パスには メタサービス名である homes を使用しない 方がよいだろう。

Windows 9x/Me ユーザープロファイル

Windows 9x/Me クライアントをサポートするには、 logon homeパラメーターを使用すること。 Sambaが修正され、logon homeパラメーターを信頼 するnet use /homeも動作するようになった。

logon home パラメーターを指定すると Windows 9x/Me のプロファイルの格納位置はユーザーのホームディレクトリーに制限される。 しかし待って欲しい。実はこれは裏技的なやり方である。smb.conf ファイルの [global] セクションに

logon home = \\%L\%U\.profiles

を記載すると、Windows 9x/Me クライアントはちゃんと自分のプロファイルを ホームディレクトリー配下の .profiles という隠し ディレクトリーに正しく保存するようになる。

これだけではなく、net use /home は Windows 9x/Me における機能のためにもなる。これはホームディレクトリーにあるすべての ディレクトリーを削除し、サーバーと共有部分のみを使用する。すなわち、 あたかも logon home\\%L\%U を指定したように振舞う。

Windows Windows 9x/Me と NT4/200x のユーザープロファイルの混在

logon homelogon path 両方のパラメーターをセットすると、Windows 9x と Windows NT クライアントの 両方をサポートできるようになる。たとえば、

logon home = \\%L\%U\.profiles
logon path = \\%L\profiles\%U

Windows 9x/Me と NT4 およびそれより新しいプロファイルは、同じ位置に 格納するべきではない。なぜなら、Windows NT4 とそれ以降のクライアントは プロファイルが混在した環境で問題を起こすからである。

移動プロファイルサポートを無効にする

しばしば行われる質問として、強制的にローカルプロファイルにするには? どうやったら移動プロファイルを無効にできるか? といったものがある。

これには、3つのやり方がある:

smb.conf において

logon home = および logon path = を適用すると、すべてのクライアントがローカルプロファイルを使うようになる。

これらのパラメーターへの引数はブランクのままにしておかなければならない。 空の値を設定する場合でも = 記号は必要である。

MS Windows レジストリ:

マイクロソフト管理コンソール(MMC)の gpedit.msc を使って、その Windows XP マシンがローカルプロファイルだけを使う ようにする。もちろんこれはレジストリの設定を変更する。 オプションへのフルパスは以下の通り:

ローカル・コンピュータ・ポリシー\
	コンピュータの構成\
		管理用テンプレート\
			システム\
				ユーザープロファイル\

無効: ローカルユーザープロファイルのみを許可する
無効: 移動プロファイルへの変更をサーバーに伝達しない

プロファイルタイプの変更:

スタートメニューのマイコンピュータ・アイコンで右クリックし、 プロパティの詳細設定タブを開く。 ユーザープロファイルの設定で変更したいプロファイルを 選んで「種類の変更」をクリックし、移動プロファイルローカルプロファイルに変更する。

特定バージョンの MS Windows において、どのレジストリキーを変更すれば 強制的にローカルプロファイルになるのかは、MS Windows レジストリガイドを 参照のこと。

Note

ローカルプロファイルを移動プロファイルに、もしくはその逆方向に変換する方法は、 稼働中の MS Windows のバージョンに大きく依存する。バージョン固有の情報に ついては MS Windows リソースキットを参照してほしい。

Windows クライアントのプロファイル設定に関する情報

Windows 9x/Me のプロファイル設定

ユーザーが最初に Windows 9x にログインすると、user.DAT ファイルが生成される。 その中には スタートメニュー, デスクトップ, プログラム, 近くのコンピュータ というフォルダーが入る。 二度目以降のログイン時は、これらのディレクトリーとその中身が マージされて c:\windows\profiles\ユーザー名 に格納される。 これらにはそれぞれ最新の情報が入る。 ここで、プロファイルフォルダー内のショートカットを常に大文字で見せるために [global] オプションを、それぞれ preserve case = yes, short preserve case = yes, and case sensitive = no のように設定する必要がある。

user.DAT ファイルにはそれぞれのユーザーの設定項目が 入っている。これらの設定を強制したい場合は、それぞれの user.DAT ファイルを user.MAN にリネームし、さらにこれらのファイルを書き込み禁止にしておく。

  1. Windows 9x/Me マシンでは、コントロールパネル -> パスワード に入って ユーザー・プロファイルタブを選ぶ。 要求する移動設定のレベルを選択してOK を押すが、 ここではコンピュータのリブートを行わない。

  2. Windows 9x/Me マシンでは、コントロールパネル -> ネットワーク -> マイクロソフトネットワークのクライアント -> Preferencesに行き、 NTドメインにログオンを選択する。 そしてプライマリログオン(通常のログオン方法?)が マイクロソフトネットワークのクライアント になっていることを確認してOK を押す。 ここでコンピュータをリブートする。

Windows 9x/Me では、プロファイルはプライマリ・ログオンからダウンロードされる。 プライマリ・ログオンがノベルネットワーク用クライアント になっている場合、プロファイルとログオンスクリプトは使用中のノベルサーバー からダウンロードされる。プライマリ・ログオンがWindows ログオン になっている場合、プロファイルは移動プロファイルの考え方から少しはずれて ローカルマシンの からロードされる。

マイクロソフトネットワークのログインダイアログには [ユーザー名, パスワード]だけに代わって [ユーザー名, パスワード, ドメイン]が表示されている ことにお気づきだろうか?ここで Samba サーバーのドメイン名、および ユーザー名、パスワードを入力する。なお、Samba サーバーの代わりに 存在することがわかっているドメイン名を入力してもよい。その場合、 そのドメインによってユーザー認証が行われ、さらにそのドメインの ログオンサーバーがサポートしていれば、プロファイルがそのサーバーから ダウンロードされる。

そのユーザーの正当性が確認されると、Windows 9x/Me マシンは このユーザーは過去に一度もログインされていません を表示し、このユーザーの設定情報を保存しますか? と聞いてくるのでYesで答える。

Windows 9x/Me のデスクトップが起動したら、Samba サーバー上の logon path にあるディレクトリーの中に デスクトップ, スタートメニュー, プログラム, 近くのコンピュータNethood フォルダー群が作られていることがわかるだろう。

これらのフォルダーはクライアント上でローカルでキャッシュされ、 (事前にリードオンリーに設定しておかない限り)ユーザーのログオフ時に更新される。 ユーザーがさらにフォルダーやショートカットを作ると、クライアントはこれらを すでにダウンロード済みのプロファイルの中身とマージして、それらの中から 最新のフォルダーやショートカットを選択する。

Samba サーバー上のフォルダー/ファイルをリードオンリーにしていた場合、 Windows 9x/Me はログオンやログアウト時にローカルとリモートの プロファイルをマージしようとしてエラーが発生する。基本的に Windows 9x/Me でエラーが出たら、Samba サーバー上のプロファイルディレクトリーで、 UNIX 側のファイルのパーミッションや所有者の権限をチェックしてみてほしい。

ユーザープロファイルの生成で失敗する場合、そのユーザーのローカルデスクトップの キャッシュを後述の要領でリセットしてやるとよい。このユーザーが次回ログオンした時、 今回はじめてログオンした旨のメッセージが表示される。

  1. [ユーザー名, パスワード, ドメイン] ダイアログでログオンする代わりに エスケープを押す。

  2. regedit.exe を起動して以下のエントリを探す:

    HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList

    ここに各ユーザーの ProfilePath があるので(このキーの内容は c:\windows\profiles\ユーザー名と同様である)、この中で 該当するユーザーの ProfilePath キーを削除する。

  3. レジストリエディターを終了する。

  4. c:\windows ディレクトリー配下から当該ユーザーの パスワードチェインファイル .PWL を見つけ、これを削除する。

  5. Windows 9x/Me クライアントをログオフする。

  6. プロファイルパスの中身(前述の logon path を参照)を確認し、ユーザーの user.DAT または user.MAN を、必要であればバックアップを取ってから 削除する。

Warning

ProfilePath(おそらく c:\windows\profiles\username)の一覧にあるディレクトリーの 中身を削除する前に、各ユーザーのデスクトップやスタートメニューに重要なファイルが ないかどうかを確認しておく。ProfilePath ディレクトリーの 中身を(必要であればバックアップを取ってから)削除する。

これで、各ユーザーのプロファイルディレクトリーにある(それぞれが リードオンリーでかつ隠しファイル、システムファイルである)ローカルの user.DAT, desktop, nethood, start menu, programs といったフォルダーが削除される。

八方手を尽くしてもだめなら、Samba のログレベルを 3 から 10 まで増やしてみて、 さらに ethereal や netmon.exe といったコマンドでパケット をキャプチャしてエラーメッセージ等を捕捉してみる。

Windows NT4/200x サーバーへのアクセス権を持っている場合は、まず Windows NT4/200x サーバー上で移動プロファイルや netlogon の設定を行う。 その後 Windows NT4/200x サーバーが吐きだすパケットを解析して、 Samba のトレース結果と照合し、何が違うのかを調べてみる。

Windows NT4 workstation

ユーザーが最初に Windows NT workstation にログインした時、NTuser.DAT というプロファイルが生成される。プロファイルの場所は logon path パラメーターで指定できる。

現在は、NT プロファイルを利用可能にするための logon drive というパラメーターもある。 これは H: もしくは他のドライブ名に向けておき、 また logon home パラメーターと組み合わせて使用する。

NT4 プロファイルのエントリはファイルではなくディレクトリーである。 プロファイルに関する NT のヘルプによれば、.PDS という拡張子を持つ ディレクトリーが同時に作られるらしい。ログイン時、当該ユーザーは完全な プロファイルパス(および、.PDS 拡張子を持つディレクトリーが作られる のでそれも)を作るための書き込み権が必要である。

Windows NT4 では、プロファイルディレクトリーに Windows 9x/Me で作られる デスクトップ, ネットワークコンピュータ, スタートメニュー, プログラム 以外に アプリケーションデータ フォルダーが作られる。 プロファイル自体は NTuser.DAT ファイルに格納される。 .PDS ディレクトリには何も書き込まれないようで、現時点でここの目的は謎である。

システム コントロール パネル を使って ローカルプロファイルを Samba サーバーにコピーすることができる (プロファイルに関する NT のヘルプを参照のこと:さらに、これで システム コントロール パネルの中で 正確な位置を確認することもできる)。NT のヘルプによれば、残りの NTuser.DAT から NTuser.MAN は、 プロファイルを強制するためのものであるらしい。

プロファイル名の大文字小文字は重要である。このファイル名は NTuser.DAT、強制用ファイルであれば NTuser.MAN でなければならない。

Windows 2000/XP Professional

まずローカルプロファイルを MS Windows ワークステーション上で 以下のようにドメインプロファイルに変換しなければならない:

  1. ローカルのワークステーション管理者 としてログイン

  2. マイコンピュータアイコンで 右クリックしてプロパティを選択

  3. ユーザープロファイルタブをクリック

  4. 変換したいプロファイルを選択(一回クリック)

  5. コピー先ボタンをクリック

  6. 使用を許可するユーザー/グループ ボックスの変更ボタンをクリック

  7. マシン名の一覧が出る場所をクリック。 ここをクリックすると選択ボックスが開くので、プロファイルを アクセス可能にするべきドメインをクリック。

    Note

    ログオンボックスが表示された場合はそこでログオンする。 たとえば DOMAIN\root に パスワード:mypassword で接続する。

  8. プロファイルを誰でも使えるようにする場合は Everyone を選択

  9. OKを押すと選択ボックスが閉じる

  10. これで OK を押すと、 指定した場所にプロファイルが作られる

これで Samba の profiles ツールから編集可能な プロファイルの作成ができた。

Note

Windows NT/200x では、必須プロファイルを使うとメールデータとして MS Exchange のストレージを使うことしかできなくなり、またこれは デスクトッププロファイルからは除外される。これにより、 デスクトッププロファイルを使用不可にできない。

Windows XP サービスパック 1

Windows XP (もしくは Windows XP サービスパック 1 のみ?)では セキュリティーチェックが追加された。これは Active Directory のグループポリシー経由で無効にできる。このポリシーは、以下の 手順で呼び出せる:

コンピュータの設定\
  管理用テンプレート\
    システム\
      ユーザープロファイル\
        移動プロファイルフォルダーのユーザー所有権を確認しない

これは 有効 にしておく

新しいバージョンの Samba には Active Directory と似たような 仕組みがあるだろうか?もしあるなら、前述の手順に従って このポリシーを設定できるだろう。

Samba ではグループポリシーが設定できないようでも、各マシンで ローカルに設定することは可能である。もしこの作業を行いたければ 以下のようにすればよい:

  1. XP workstation に管理者権限でログインする

  2. スタート -> 名前を指定して実行をクリック

  3. mmcとタイプする

  4. OKをクリック

  5. マイクロソフト管理コンソールが起動する

  6. ファイル -> スナップインの追加と削除 -> 追加をクリック

  7. グループポリシーをダブルクリック

  8. 完了 -> 閉じるをクリック

  9. OKをクリック

  10. コンソールルート ウィンドウで ローカルコンピュータポリシー -> コンピュータの構成 -> 管理用テンプレート -> システム -> ユーザープロファイルを展開

  11. 移動プロファイルフォルダーのユーザー所有権を確認しない をダブルクリック

  12. 有効を選択

  13. OKをクリック

  14. コンソール全体を閉じる。設定を保存する必要はない (「保存」は変更したポリシーのことでではなく、コンソール設定の ことを指している)

  15. リブート

User Profile Hive Cleanup Service

終了時に、移動プロファイルのキャッシュされたローカルコピーを強制削除する 設定になっているにも関わらず、それらが消されないという状況がありうる。 このような現象に対処するために、特別なサービスが作られた。 Windows NT4/2000/XP Professional と Windows 2003 には UPHClean (User Profile Hive Cleanup) という アプリケーションをサービスとしてインストールできる。

UPHClean のソフトウェアパッケージは the User Profile Hive Cleanup Service[7]というWebサイトからダウンロードできる。

Windows 9x/Me と NT4/200x/XP ワークステーション間でプロファイルを共有する

Windows の異なったバージョン間でデスクトップを共有することは推奨されない。 デスクトッププロファイル領域は未だ進化の途上であり、新しいバージョンの Windows プロファイルで追加された機能は、それまでのバージョンの動作を 阻害する。新旧のプロファイルを混在させるべきではないより大きな理由は、 古いバージョンの Windows をログオフする際、古いフォーマットを持つ プロファイルの中身が新しいバージョンに属する情報を上書きしてしまい、 結果的にユーザーが新しいバージョンの Windows でログオンし直した際に必要な プロファイル情報が失われてしまうからである。

Windows 9x/Me とスタートメニューやデスクトップを共有させたい場合は、 プロファイルの共通領域を指定してやらなければならない。smb.conf で 同じにしなければならないパラメーターは logon pathlogon homeである。

これらが正しく設定されていれば、同じプロファイルディレクトリの中に別々の user.DATNTuser.DAT ファイルが見えるはずである。

Windows NT4/200x サーバーから Samba にプロファイルを移行する

ユーザープロファイルの位置に関しては、どこのパスを指定してもよい。つまり プロファイルを保存する場所は、その SMB サーバーが暗号化パスワードを サポートしている限り、Samba サーバーでもそれ以外のその SMBサーバー でもかまわない。

Windows NT4 のプロファイル管理ツール

残念なことに、現在のリソースキットの情報は Windows NT4/200x に特化 したものとなっている。各プラットフォームに対応したリソースキットの 存在が望まれる。

クイックガイド

Procedure 27.1. プロファイルの移行手順

  1. NT4 のドメインコントローラーの マイコンピュータで右クリックして プロパティユーザープロファイル タブを選ぶ

  2. 移行したいユーザープロファイルを選んでクリック

    Note

    ここでご紹介するのはゆるやかな移行 方法である。プロファイルをコピーしてグループプロファイルを作成し、 このプロファイルへのアクセス権を Everyone ユーザーに与える。Samba ドメインが NT4 の PDC と信頼関係を結んでいない 場合は、単にこれだけでよい。

  3. コピー先ボタンをクリック

  4. プロファイルのコピー先ボックスで、 c:\temp\foobarのように新しいパスを追加する

  5. 使用を許可するユーザー/グループ ボックスの変更をクリック

  6. グループEveryoneをクリックし、 OKをクリック。これでユーザーを選択 ボックスが閉じられる

  7. これでOKをクリック

全てのプロファイル移行について、以下の手順に従う。

補足事項

NT4 ドメイン側の SID を取得するには net rpc infoコマンドが使える。詳細は The Net Command Chapter, Other Miscellaneous Operations を参照されたい。

moveuser.exe

Windows 200x のリソースキットには moveuser.exe が含まれる。moveuser.exe はあるプロファイルの セキュリティをあるユーザーから別のユーザーに変更する。これにより アカウントのドメインを変更したりユーザー名を変更したりできる。

このコマンドは Samba のprofilesコマンドの ようなものである。

SID の取得

Windows NT Server 4.0 のリソースキットに含まれる GetSID.exeを使って SID を取得できる。

Windows NT 4.0 ではローカルプロファイルの情報はレジストリキー HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList配下に格納される。

ProfileList キー配下には、現在このコンピュータにログオンしている ユーザーが、SID をサブキー名として格納されている。 (ローカルにキャッシュされているプロファイルから移動したいユーザーの プロファイル情報を見つけるには、GetSID.exe ユーティリティーでこのユーザーの SID を見つければよい)。 適切なユーザーのサブキーの中に ProfileImagePath という名前の文字列値があるはずである。

必須プロファイル

必須プロファイルとは、ユーザーが上書きできないプロファイルのことである。 ユーザーセッションが有効の間、デスクトップ環境の変更が可能である。 しかしながら、ユーザーがログアウトするとすべての変更内容は失われてしまう。 ユーザーにデスクトップ環境を変更させたくない場合は、この設定をポリシー 設定を通して行うことができる。 System and Account Policies を参照のこと。

Note

どのような状況においてもプロファイルディレクトリー(もしくはそのファイル) をリードオンリーにはできない。なぜならそのプロファイルが使用できなく なってしまうからである。ただし UNIX ファイルシステム配下であれば プロファイルをリードオンリーにできなくもない。この場合、 fake-permissions VFS モジュールを使用する必要がある。 これは Windows NT/200x/XP クライアントに対して、そのユーザーのプロファイルに 書き込み権があるようにふるまう。 fake_perms VFS module を参照のこと。

Windows NT4/200x/XP では、必須プロファイルを作るのに Windows NT4/200x サーバーから Samba へのプロファイルの移行にあるような手順が使える。 グループプロファイルを必須プロファイルに変換するには、単に コピー先にプロファイルにNTUser.DATファイルを 入れ、それをNTUser.MANにリネームすればよい。

Windows 9x/Me の場合はUser.DATファイルを User.MANにリネームすることで必須プロファイルを 作成できる。

グループプロファイルの作成と管理

多くの組織は部署に分かれている。ひとつの部署内のユーザーは同じデスクトップ アプリケーションや同じデスクトップレイアウトを要求することが多いので、 部署単位で管理できるといろいろと都合のよいことが多い。 Windows NT4/200x/XP では、グループプロファイルが利用できる。 グループプロファイルは、まずテンプレート(例示)ユーザーを使って作られる。 その後、後述のプロファイル移行ツールを使ってそのユーザーグループから グループプロファイルに対する必要なアクセス権が設定される。

次のステップはもっと重要である。グループプロファイルを (ユーザーマネージャーを使って)各ユーザーにユーザー単位で 割り当てるのではなく、そのグループ自体を更新されたプロファイルに 割り当てるのである。

Note

グループプロファイルには注意すること。個人プロファイルをすでに持っている グループのメンバーがユーザーである場合、その結果は2つを統合(マージ) したものとなる。

Windows ユーザーのデフォルトプロファイル

Windows 9x/Me および NT4/200x/XP では、プロファイルが存在しないユーザー についてはデフォルトプロファイルを使用する。デフォルトプロファイルが Windows workstation 上にあるとわかっている場合、およびデフォルト プロファイルを作るパスを示すレジストリキーがわかっている場合、使用する デフォルトプロファイルをこのサイト用に最適化されたものに変更できる。 これは管理上重要な利点である。

MS Windows 9x/Me

Windows 9x/Me でユーザーごとのデフォルトプロファイルを有効にするには、 Windows 98 システムポリシーエディター を使うか、またはレジストリを直接変更する。

Windows 9x/Me でユーザーごとのデフォルトプロファイルを有効にするには システムポリシーエディターを起動し、 ファイル -> レジストリを開く を選択する。次にローカルコンピュータアイコンを クリックし、Windows 98 システムをクリックして 「有効」ボックスのユーザープロファイルを選択する。 レジストリの変更を保存するのを忘れないこと。

レジストリを直接変更するには レジストリーエディター (regedit.exe) を起動し、 HKEY_LOCAL_MACHINE\Network\Logonハイブを選択する。 ここでUser Profilesキーのところに DWORD を追加する。 ユーザープロファイルを有効にするには 1 を、無効にするには 0 をセットする。

Windows 9x/Me におけるユーザープロファイルの取り扱い

ユーザーが Windows 9x/Me マシンにログオンすると、そのユーザーに関する 既存のエントリを処置するのにローカルプロファイルのパス HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProfileList がチェックされる。

レジストリのこの位置にユーザーのエントリがある場合、Windows 9x/Me は ユーザープロファイルのキャッシュされたバージョンをローカルでチェックする。 Windows 9x/Me では、さらにサーバー上にあるユーザーのホームディレクトリー (場所が変更されている場合は指定されたディレクトリー)にある(かもしれない) ユーザープロファイルもチェックする。プロファイルがどちらにもある場合は、 新しい方が使われる。プロファイルがサーバー上にあるがローカルマシン上には ない場合は、サーバー上のプロファイルをダウンロードして使用する。ユーザー プロファイルがローカルマシン上のみにある場合は、そのコピーが使われる。

ユーザープロファイルがこれらのどちらにもない場合は、Windows 9x/Me マシン のデフォルトユーザープロファイルが使われ、ログインしているユーザーの新しく 作られたディレクトリにこのプロファイルのコピーが作られる。ログオフの際、 ユーザーが行った変更がすべてこのユーザーのローカルプロファイルに書きこまれる。 このユーザーが移動プロファイルを使っている場合、変更内容はサーバー上ある このユーザーのプロファイルに書きこまれる。

MS Windows NT4 Workstation

Windows NT4 の場合、デフォルトユーザープロファイルは %SystemRoot%\Profiles から読みこまれる。 インストール時のデフォルト設定では、ここは C:\Windows NT\Profilesとなる。 クリーンインストール後におけるこのディレクトリの中身は Administrator, All Users, Default Userという3つのディレクトリから構成される。

All Users ディレクトリにはシステムユーザーすべてで 共通で使われるメニュー設定が入る。Default User ディレクトリには、各ユーザーが自分で選択したり作成したりした プロファイル設定に依存する、カスタマイズ可能なメニューエントリが入る。

新しいユーザーが最初に Windows NT4 のマシンにログオンする際、以下を元に 新しいプロファイルが作られる。

  • All Users の設定

  • Default User(デフォルトの NTUser.DAT ファイルを含む)の設定

あるユーザーがマイクロソフトのセキュリティードメインのメンバーである Windows NT4 マシンにログオンする際は、プロファイルの扱いに関して以下の 手順を踏む:

  1. ログオンプロセスを通して得られるユーザーのアカウント情報には、その ユーザーのデスクトッププロファイルの場所も入っている。プロファイルの パスはマシンのローカルにある場合もあるし、ネットワーク共有の中かも しれない。プロファイルがユーザーアカウントから得られたパスの位置に ある場合、このプロファイルは %SystemRoot%\Profiles\%USERNAME% という位置にコピーされる。そしてこのプロファイルの内容は、 %SystemRoot%\Profilesにある All Usersプロファイルの設定を継承する。

  2. ユーザーアカウントがプロファイルへのパスを持っているが、そこに プロファイルが存在しない場合、Default User プロファイルが参照され、それを元にして新しいプロファイルが %SystemRoot%\Profiles\%USERNAME% に作られる。

  3. 認証サーバー(ログオンサーバー)上の NETLOGON 共有内にポリシー ファイル(NTConfig.POL)がある場合、その内容は NTUser.DATに適用され、最終的にはレジストリの HKEY_CURRENT_USER部分に適用される。

  4. ユーザーがログアウトする際、そのプロファイルが移動プロファイルで あれば、指定されたプロファイルの場所に書き出される。その後 HKEY_CURRENT_USERの内容から NTuser.DATファイルが再度作成される。つまり、 次回のログイン時には NETLOGON 共有内に NTConfig.POLが存在するべきではなく、そのひとつ 前のNTConfig.POL がプロファイル内にあれば、 それが有効になる。この効果はタトゥーイング(入れ墨)と呼ばれる。

Windows NT4 のプロファイルのタイプはローカル移動のどちらかである。ローカルプロファイルは %SystemRoot%\Profiles\%USERNAME%に置かれる。 以下のレジストリキーを作っておかない限り、移動プロファイルも同様に 残ったままとなる。

HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\Windows NT\CurrentVersion\
winlogon\"DeleteRoamingCache"=dword:0000000

このケースでは、 (%SystemRoot%\Profiles\%USERNAME%にある) ローカルのコピーは、ログアウト時に削除される。

Windows NT4 では後述のレジストリキーを変更することで、 マイドキュメントといった共有リソースのデフォルト 位置をネットワーク共有上にリダイレクトすることができる。これらの変更は システムポリシーエディターを使って行える。これを GUI 上で行いたい 場合は、ポリシーエディターで自分自身のテンプレート拡張を作る必要がある かもしれない。別の方法としては、まずデフォルトのユーザープロファイル を作成し、そのユーザーでログインしてからregedt32 でキー設定の編集を行う。

あるフォルダーをデフォルトのユーザープロファイルとしたい場合のレジストリ ハイブキーは、Windows NT4 の場合以下で制御できる:

HKEY_CURRENT_USER
	\Software
		\Microsoft
			\Windows
				\CurrentVersion
					\Explorer
						\User Shell Folders

前述のハイブキーには自動的に管理されるフォルダーがある。デフォルトの エントリはthe next tableにある。

Table 27.1. User Shell Folder レジストリキーのデフォルト値

名前デフォルト値
AppData%USERPROFILE%\Application Data
Desktop%USERPROFILE%\Desktop
Favorites%USERPROFILE%\Favorites
NetHood%USERPROFILE%\NetHood
PrintHood%USERPROFILE%\PrintHood
Programs%USERPROFILE%\Start Menu\Programs
Recent%USERPROFILE%\Recent
SendTo%USERPROFILE%\SendTo
Start Menu %USERPROFILE%\Start Menu
Startup%USERPROFILE%\Start Menu\Programs\Startup

デフォルトプロファイルの場所の設定を含むレジストリキー:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\
User Shell Folders

デフォルトのエントリは デフォルトのプロファイル設定用のレジストリキー にある。

Table 27.2. デフォルトのプロファイル設定用のレジストリキー

Common Desktop%SystemRoot%\Profiles\All Users\Desktop
Common Programs%SystemRoot%\Profiles\All Users\Programs
Common Start Menu%SystemRoot%\Profiles\All Users\Start Menu
Common Startup%SystemRoot%\Profiles\All Users\Start Menu\Programs\Startup

MS Windows 200x/XP

Note

Windows XP Home Edition ではユーザーごとのデフォルトプロファイルは 使われず、ドメインセキュリティにも参加できず、NT/ADS スタイルの ドメインにもログインできないので、プロファイル情報は自分自身で持って おくしかない。デフォルトプロファイルを設定できるといろいろと便利なので、 ドメインログオン処理に参加できるような上位レベルの Windows クライアント では、管理者がグローバルのデフォルトプロファイルを事前に作っておき、 グループポリシーオブジェクト(GPO)を経由してそれらを強制的に適用する という仕組みを備えている。

新しいユーザーが最初に Windows 200x/XP マシンにログインすると、 デフォルトプロファイルは C:\Documents and Settings\Default User から読みこまれる。システム管理者が必要に応じてこの中身を変更していても、 Windows 200x/XP は喜んでその指示に従う。これは最善の処置とは とても言えるものではない。なぜなら、このデフォルトプロファイルを すべての Windows 200x/XP クライアントマシンにコピーして回らなければ ならないからである。

Windows 200x/XP がドメインレベルのセキュリティに参加する際、 デフォルトのユーザープロファイルが見つからなければ、クライアントは デフォルトプロファイルを探すために認証サーバーの NETLOGON 共有を 見に行く。ここで Windows の元々の動きとしては、まず %LOGONSERVER%\NETLOGON\Default User を見に行き、もしこのディレクトリがあればこの配下のファイルが クライアント側のC:\Documents and Settings\ 直下にある現在 Windows にログイン中のユーザー名にコピーされる。

Note

一方 Samba 側の動きとしては、このパスは smb.conf[NETLOGON] 共有に読み替えられる。 このディレクトリはこの共有の直下にDefault User という名前で作っておかなければならない。

この場所にデフォルトプロファイルが存在しない場合、Windows 200x/XP はローカルのデフォルトプロファイルを使用する。

ログアウトの際、ユーザーのデスクトッププロファイルはそのユーザーに 関連するレジストリ設定で指定された場所に格納される。(Samba では 自動的に行われるが)ログイン処理の際に特定のポリシーが作られ もしくは渡されない場合、ユーザーのプロファイルはローカルマシンの C:\Documents and Settings\%USERNAME% パス配下にのみ書きこまれる。

デフォルトの振る舞いを変更したい場合は、以下の3つの方法を使えばよい:

  • ローカルマシンのレジストリキーを手作業で変更し、NETLOGON 共有の 直下に新しいデフォルトプロファイルを置く。保守でいっせいに行う 必要があるので、この方法はお勧めしない。

  • この振る舞いを指定した NT4 スタイルの NTConfig.POL ファイルを 作成し、それを新しいデフォルトプロファイルと共に NETLOGON 共有の直下に置く。

  • これを Active Directory を通して行うように強制する GPO を 作成し、新しいデフォルトプロファイルを NETLOGON に置く。

Windows 200x/XP において、デフォルトユーザープロファイルの一部 となるフォルダーに関する振る舞いに影響を与えるレジストリのハイブ キーは以下のエントリーである:

HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Explorer\User Shell Folders\

このハイブキーには自動的に管理されるフォルダーのリストが含まれる。 デフォルトのエントリーは 次の表にある。

Table 27.3. デフォルトユーザープロファイルへのパスのデフォルト値 を持つレジストリエントリー

名前デフォルト値
AppData%USERPROFILE%\Application Data
Cache%USERPROFILE%\Local Settings\Temporary Internet Files
Cookies%USERPROFILE%\Cookies
Desktop%USERPROFILE%\Desktop
Favorites%USERPROFILE%\Favorites
History%USERPROFILE%\Local Settings\History
Local AppData%USERPROFILE%\Local Settings\Application Data
Local Settings%USERPROFILE%\Local Settings
My Pictures%USERPROFILE%\My Documents\My Pictures
NetHood%USERPROFILE%\NetHood
Personal%USERPROFILE%\My Documents
PrintHood%USERPROFILE%\PrintHood
Programs%USERPROFILE%\Start Menu\Programs
Recent%USERPROFILE%\Recent
SendTo%USERPROFILE%\SendTo
Start Menu%USERPROFILE%\Start Menu
Startup%USERPROFILE%\Start Menu\Programs\Startup
Templates%USERPROFILE%\Templates

値がセットされていない、Defaultと呼ばれるエントリーもある。 デフォルトのえんとりーの型はREG_SZである。 これ以外の全ての型はREG_EXPAND_SZである。

全てのフォルダーがネットワークサーバー上の特定の場所に格納されて いる場合、移動プロファイルを処理するスピードには大きな違いが出る。 つまり、ログインやログアウトのたびに Outlook の PST ファイルを ネットワークの向こうに書き出す必要はないということだ。

これをネットワーク上の場所にするには、以下の例に従えばよい:

%LOGONSERVER%\%USERNAME%\Default Folders

これにより、フォルダーはユーザーのホームディレクトリーにある Default Foldersという名前のディレクトリー 配下に格納される。また以下の書式で指定してもよい:

\\SambaServer\FolderShare\%USERNAME%

この場合、デフォルトフォルダーは SambaServerという名前のサーバー上にある FolderShareという名前の共有の下の、 Linux/UNIX ファイルシステムによって Windows ユーザーの名前を つけられたディレクトリーに格納される。

いったんデフォルトプロファイルの共有を作ったら、その中に移行する ユーザーのプロファイルを(デフォルト値であれカスタマイズしたもの であれ)を置かなければならないことに注意して 欲しい。

Windows 200x/XP のプロファイルはローカル または移動のいずれかである。移動プロファイルは 以下のレジストリキーが作られていない限りローカルにキャッシュされる:

HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\
Windows NT\CurrentVersion\winlogon\"DeleteRoamingCache"=
dword:00000001

この設定をすると、ログアウト時にローカルのキャッシュは削除される ようになる。

よくあるエラー

Samba のメーリングリストで質問があった典型的なエラーや問題、 質問内容を以下に示す。

少人数のユーザーやグループのための移動プロファイルの設定

Samba-2.2.x では、移動プロファイルをサポートするか否かという 選択肢しかない。これはグローバル設定である。デフォルトでは 移動プロファイルを持つことになっており、デフォルトのパスは ユーザーのホームディレクトリー配下にある。

グローバルで無効にすると、誰も移動プロファイルを持てなくなる。 移動プロファイル自身は有効にするが、これを特定のマシンにしか 適用させたくない場合は、移動プロファイルサポートをしたくない 個々のマシンにおいて、これを無効にする設定をレジストリに書き 込んでやらなければならない。

Samba-3 では、グローバル設定を smb.conf に書いておき、 各ユーザーごとの設定を(Windows NT4/200x の)ドメインユーザー マネージャで上書きすることができる。

どのケースにおいても、各ユーザーごとにひとつのプロファイルしか 持てない。このプロファイルは以下のいずれかになる:

  • そのユーザー固有のプロファイル

  • 必須プロファイル(ユーザーは変更できない)

  • グループプロファイル (実際は必須となる すなわち変更不可)

移動プロファイルを使えない

あるユーザーからの要求: 移動プロファイルを実装して欲しくない。 各ユーザーにローカルプロファイルだけを与えたい。 私はこのエラーでひどく損害を受けた。 この2日間、あらゆることを試してみた。 Google を検索したりもしてみたが、役に立つ情報はなかった。 助けてください。

選択肢としては、以下のようになるだろう:

ローカルプロファイル

ログアウト時に「ローカルの」プロファイルを 自動で消すようなレジストリキーがないことがわかっている。

移動プロファイル

ユーザーがネットワークにログオンすると、中央に格納された プロファイルがワークステーションにコピーされてローカルの プロファイルが作られる。このローカルプロファイルは、 レジストリキーが変更されてログアウト時の自動削除が有効に ならない限りは永続的になる(ワークステーションのディスク 上に残る)。

移動プロファイルの選択をする場合:

個人の移動プロファイル

一般的には中央の(もしくは便宜上ローカルにある) サーバー上のプロファイル用共有に格納されている。

ワークステーションはプロファイルのローカルコピーを キャッシュ(格納)する。このキャッシュされたコピーは、 次回のログイン時にプロファイルがダウンロードできなかった 場合に使用される。

グループプロファイル

これらは中央のプロファイルサーバーから読み込まれる。

必須プロファイル

必須プロファイルはユーザー用としてだけではなく、 そのユーザーが属するすべてのグループのためにも作られる。 必須プロファイルを通常のユーザーが変更することはできない。 これを変更したり再構成したりできるのは、システム管理者に限られる。

Windows NT4/200x/XP のプロファイルは、そのサイズが最低 130KB から 巨大なサイズまで変動する。プロファイルの中の多くを占めるのは、往々 にして Outlook の PST ファイルであり、これはギガバイトレベルまで 膨らむこともある。(好ましい状態で運用されている環境における) 平均的な移動プロファイルのサイズは、計画段階では 2MB 程度であると 考えればよいだろう。きちんと管理されていない環境では、プロファイルが 2GB まで膨れ上がったのを見たことがある。こうなるとログオンに1時間 くらいもかかってユーザーからの不満が出るかもしれないが、おおかた くだらないごみファイルをため込んでいるのであろう。

この議論のポイントは、移動プロファイルを使って変更できる設定とできない 設定をうまくコントロールしてやれば、問題の少ないサイト運用ができる ということである。

PST 問題に対するマイクロソフトの回答は、すべての電子メールを MS Exchange Server バックエンドに格納するべき、というものである。 これを使えば PST ファイルが必要なくなる。

ローカルプロファイルの意味するところは:

  • それぞれのマシンが多くのユーザーによって使用されるなら、ローカル プロファイルを格納するために多くのディスク領域が必要になる。

  • ユーザーがログインするそれぞれのワークステーションにはそれぞれの プロファイルが格納されている。これらはマシン間で全く別物に なっているかもしれない。

一方、移動プロファイルの意味するところは:

  • ネットワーク管理者は、全ユーザーのデスクトップ 環境をコントロールできる。

  • 移動プロファイルを使うと、ネットワーク管理の オーバーヘッドを劇的に削減できる。

  • 長時間のスパンで考えれば、ユーザーが問題に直面する 危険性が減るだろう。

デフォルトプロファイルを変更する

クライアントがドメインコントローラーにログオンする際、クライアントは ダウンロードするべきプロファイルを検索する。我々はデフォルト プロファイルをどこに置くべきだろうか?

まず Samba サーバーはドメインコントローラーとして構成する必要がある。 そのためには smb.conf に以下の設定を行う:

security = user
os level = 32 (or more)
domain logons = Yes

次に [netlogon] が必須で、ここは全ユーザーが 読めるようになっていなければならない。ここに既存のプリンターやドライブ の割り当てをするためのログオンスクリプトを追加しておくのもよいだろう。 ワークステーションの時刻をログオンサーバーと自動的に同期させる 仕組みもある(これもやっておくことが好ましい)。

Note

ローカルワークステーションのキャッシュ(=ディスク領域)から移動 プロファイルを自動検出させるには、 グループポリシーエディターを使って NTConfig.POLと呼ばれるファイルを作成し、 この中で適切な設定を行っておく。このファイルは netlogon共有の直下に置いておかなければ ならない。

Windows クライアントはドメインのメンバーである必要がある。 ワークグループのマシンではネットワークログオンが使えないので ドメインプロファイルによる運用はできない。

移動プロファイル用に smb.conf に追加する項目:

logon path = \\%N\profiles\%U
# Default logon drive is Z:
logon drive = H:
# This requires a PROFILES share that is world writable.

移動プロファイルと NT4 スタイルのドメインポリシーのデバッグ

移動プロファイルとドメインポリシーは USERENV.DLL により実装されている。この DLL をデバッグしてログインプロセスを解析 するためのやり方は、Microsoft Knowledge Base の 221833154120 という記事に解説がある。



Chapter 28. PAM ベースの分散型認証

John H. Terpstra

Samba Team

Stephen Langasek

May 31, 2003

この章は、何らかの PAM が利用できる UNIX/Linux システムに対して Winbind ベースの認証を導入する際の助けになるだろう。Winbind を使うと、いずれかの Windows NT ドメイン、Windows 200x の Active Directory ベースのドメイン、 そして Samba ベースのドメイン環境において、ユーザーレベルのアプリケーション アクセス認証を利用できるようになる。また、あなたの Samba 環境の設定に 対する適切な PAM ベースのローカルホストアクセス制御にも役立つ。

PAM 経由の Winbind の設定方法を知ることに加え、さらに一般的な PAM 管理 の可能性と、特に pam_smbpass.so のようなツールを 導入して便利に使う方法も学ぶことができるだろう。

Note

Winbind を使うのは、PAM 構成を単独で行うよりも敷居が高い。Winbind に関する より詳細な情報については Winbind: ドメインアカウントを使う を参照されたい。

その機能と利点

現在、多くの UNIX システム(例:Oracle(Sun)Solaris)や xxxxBSDファミリーおよび Linux では、着脱可能な認証モジュール(PAM)機能を使って全ての認証、承認処理、 リソースの制御サービスを提供している。PAM の導入以前は、システムパスワード データベース(/etc/passwd)以外のものを使おうとするなら、 セキュリティサービスを提供するすべてのプログラムそれぞれに対して代替手段 を準備する必要がある。つまり、login, passwd, chown といったものの代替手段 を別途用意しなければならないということである。

PAM を使うと、これらのセキュリティプログラムを、これらが依存する認証/ 承認インフラから切り離すことができる。PAM を構成するには、 /etc/pam.conf という1つのファイルを適切に変更する (Solaris)か、または/etc/pam.d配下にある個別の制御 ファイルを編集する。

PAM が有効になっている UNIX/Linux システムでは、動的なロードができる適切な ライブラリモジュールが利用できるようになっていれば、システムでさまざまな 認証バックエンドを使うように構成するのは簡単である。それらのバックエンドは システムでローカルに閉じていてもよいし、リモートサーバー上で集約されていてもよい。

PAM サポートモジュールで使えるもの:

/etc/passwd

これらの PAM モジュールは標準の UNIX ユーザーデータベースを利用する。 最も有名なものは、pam_unix.so, pam_unix2.so, pam_pwdb.so, pam_userdb.soと呼ばれるものである。

Kerberos

pam_krb5.so モジュールを使うと、ケルベロス準拠の あらゆるサーバーを使える。このツールは MIT Kerberos, Heimdal Kerberos, そしておそらく(もし有効であれば)Microsoft Active Directory にアクセス するのにも使える。

LDAP

pam_ldap.so モジュールを使うと、LDAP v2 もしくは v3 準拠のあらゆるバックエンドサーバーを使える。よく使われる LDAP バックエンド サーバーには OpenLDAP v2.0 and v2.1, Sun ONE iDentity server, Novell eDirectory server, Microsoft Active Directory がある。

NetWare Bindery

pam_ncp_auth.so モジュールを使うと、バインダリ(Bindery)が 有効な NetWare コアプロトコルベースのサーバーによる認証を利用できるようになる。

SMB Password

pam_smbpass.so と呼ばれるモジュールを使うと、Samba の smb.conf ファイルで設定された passdb バックエンドのユーザー認証を利用 できるようになる。

SMB Server

pam_smb_auth.so モジュールは、オリジナルの MS Windows ネットワーク認証のためのツールである。Winbind モジュールがリリース されている現在、このモジュールはすでに多少古臭くなってしまっている。

Winbind

pam_winbind.so モジュールは、Samba は MS Windows の ドメインコントローラーからの認証情報を取得できるようにするものである。 これにより、PAM が有効なアプリケーションに対して認証されたユーザーへの アクセス権を与えるのが簡単になる。

RADIUS

PAM RADIUS (Remote Access Dial-In User Service) と呼ばれる認証モジュールがある。 ほとんどのケースでは、管理者がこのツールのソースコードを持ってきて自分自身で インストールを行う必要がある。RADIUS プロトコルは多くのルータやターミナル サーバーで使われているプロトコルである。

上記のうち、pam_smbpasswd.sopam_winbind.so モジュールは、Samba 自身が提供するものである。

いったんこれらのモジュールを設定してしまえば、広範囲にまたがるネットワーク 帯域や PAM を利用した効率的な認証サービスを提供するような分散 Samba ドメイン コントローラーの利用においても、高い柔軟性を得ることができる。つまり、単一の ユーザーアカウントデータベースを使って、中央集中的な管理や保守の行き届いた 分散認証を実現できるのである。

技術的な議論

システム管理者が自分のシステム上のアプリケーションにアクセス権を付与する際、 PAM はかなり柔軟に設定できるように設計されている。PAM によって制御される システムセキュリティのためのローカル設定には、単一ファイル /etc/pam.conf/etc/pam.d/ ディレクトリーの2つがある。

PAM 設定のための文法

この章では、これらのファイルで記述するエントリに関する正しい文法、および 一般的なオプションについて解説する。設定ファイルにおける PAM 特有の トークンでは、大文字小文字の区別を行わない。ただし、モジュールのパス については大文字小文字を区別する。なぜなら、これらはファイルの名前を 示すものであり、大文字小文字を区別するような一般的なファイルシステム の性質に影響を受けるからである。与えられたモジュールに渡すための 引数が大文字小文字を区別するかどうかは、それぞれのモジュールで規定 されている。

後述の設定行に加え、システム管理者の便宜のために2つの特殊文字がある: # から行末まではコメントとみなされる。またモジュールを 指定する行については \ で改行をエスケープすることで、 次の行にまたがることができる。

PAM の認証モジュール(ダイナミックリンクされたライブラリファイル)が 既定値の位置にある場合は、そのパスを明示する必要はない。Linux の場合、 既定値の位置は /lib/security となる。モジュールが 既定値位置以外にある場合は

auth  required  /other_path/pam_strange_module.so

のようにパスを明示しなければならない。

/etc/pam.d にあるエントリーの構造

このセクションの残りの部分は、Linux-PAM プロジェクトのドキュメントから の引用である。PAM に関する詳細は the Official Linux-PAM home page を参照のこと。

/etc/pam.conf ファイル中の一般的な設定行は、 以下の書式で記述する:

サービス名  モジュールタイプ  制御フラグ  モジュールパス  引数

これら各トークンの意味について解説する。Linux-PAM を構成するための2番目 のやり方(最近はむしろこちらの方が多いようだが)は、 /etc/pam.d/ ディレクトリーの中身を介するという方法 である。それぞれのトークンの意味するところを解説した後、この方法について 述べることにする。

サービス名

このエントリに関連付けられるサービスの名前。ftpd, rlogind, su のように、サービス名は アプリケーションにつけられた伝統的な名前であることが多い。

既定値の認証メカニズムを定義するために予約されている、特別な名前もある。 これは OTHER と呼ばれるが、大文字小文字は固定されて いない。名前付きサービスに特化したモジュールがある場合、 OTHERエントリーは無視される事に注意。

モジュールタイプ

(現時点では)以下の通り4つのタイプのモジュールがある。

  • auth: このモジュールタイプは、ユーザーを認証 するにあたって2つの側面がある。まず、アプリケーションに対して パスワード問い合わせの指示を行うか、または別の手段を使って、操作 しているユーザーが誰なのかを特定する。次に、このモジュールはその 資格認定から承認という性質を通して(/etc/groups ファイルとは独立した形で)グループの会員資格やその他の特権に関する 許可を与えることができる。

  • account: このモジュールは、認証をベースとしない アカウント管理を行う。よくある利用法としては、利用時間帯、現時点で利用 可能なシステムリソース(最大ユーザー数)、またはユーザーがログインした場所 などをベースとした、サービスへのアクセスの制限や許可が挙げられる。 たとえば root ログインの許可は、コンソールからのみに制限 されているかもしれない。

  • session: このモジュールは、主に対象のユーザーが サービスを割り当てられる前後に行われるべきことに関連付けられる。 たとえばそのユーザーに関する何らかのデータ交換をする際のオープン/クローズ 情報のログを取ったり、ディレクトリをマウントすることなどが挙げられる。

  • password: この最後のモジュールタイプは、そのユーザーに 関連する認証トークンを更新するために必要なものである。典型的には、 チャレンジ/レスポンス 認証を行う (auth) モジュールタイプがある。

制御フラグ

制御フラグは、関連するモジュールの成功/失敗に対して PAM ライブラリがどう対応するのかを指示するのに使われる。PAM モジュール群は スタック化(同じタイプのモジュール群を次々に重ねること)できるので、 制御フラグがそれぞれのモジュールの相対的な重要度を決定する。 アプリケーションは /etc/pam.conf ファイルにある モジュールについて、個々の成功や失敗に影響されない。その代わり、 Linux-PAM ライブラリからの成功や失敗の応答のサマリを受け取る。 これらのモジュールは、/etc/pam.conf に記述 されている順に実行される。つまり前の方にあるエントリは後ろの方の ものより先に実行される。Linux-PAM v0.60 の場合、制御フラグは2つの 文法のうちのいずれかで定義できる。

制御フラグについてのシンプルな(かつ従来の)文法では、特定のモジュール の成功や失敗について、それらを通知するための重大度を単一のキーワードで 指定する。キーワードには required, requisite, sufficient, optional の4種類ある。

Linux-PAM ライブラリでは以下の方式でこれらのキーワードを 解釈する。

  • required:このモジュールタイプ機能が成功するためには このモジュールが成功することが必須である。ただしこのモジュールが失敗 した場合でも、(同じモジュールタイプを持つ)残りのすべてのモジュールの 実行が完了するまでは、失敗したことはユーザーには通知されない。

  • requisite: required と似ているが、このモジュール が失敗を返したとき制御が直接アプリケーションに戻されるところが異なる。 その戻り値は、失敗したモジュールのうち最初に required もしくは requisite 指定されていたものに関連付けられる。安全でない媒体を通してユーザーが パスワードを入力するような可能性がある場合、このフラグはその状況を排除 するために使える。そのような可能性が残っていると、システム上の有効な アカウントの情報を攻撃者に知らせてしまうようなことにつながりかねない。 このような可能性があると、共用ホスト環境で慎重に扱うべきパスワードを 公開してしまうようなゆゆしき環境において、一方的に不利になるだろう。

  • sufficient: このモジュールが成功すると、Linux-PAM ライブラリがこのモジュールタイプについてその目的を達成したものとするのに sufficient(十分である)とみなされる。 これまでに要求されたモジュールのうち失敗したものがない場合、このタイプに 関してスタックされたモジュールは、これ以上起動されない (この場合、この後に続くモジュールは起動されない)。 ただし、このモジュールが失敗しても、このモジュールタイプレベルで成功した アプリケーションについては致命的エラーとはみなされない。

  • optional: この制御フラグは、その名前が示して いるように、そのモジュールの成功/失敗が、そのユーザーアプリケーション がサービスを提供できるかどうかを決めるものではないことを示す。一般に、 そのモジュールスタック全体が成功か失敗かを決定する際、Linux-PAM はこのようなモジュールを考慮しない。しかしながら、それ以前もしくは それ以降のどのモジュールも明確に成功か失敗かを示さない場合、この モジュールがアプリケーションへの応答の性質を決めることがある。 後者のひとつの例として、他のモジュールが PAM_IGNORE のようなものを 返した場合が挙げられる。

ユーザーを認証する方法について、その文法が複雑に(新しく)なれば なるほど、管理者はより詳しく記述し、より細かく制御できるように なるものである。この制御フラグの書式は、以下のように 値=アクション トークンの並びが 大括弧で区切られたものである:

[値1=アクション1 値2=アクション2 ...]

ここで、値1 は以下の戻り値のいずれかである:

success; open_err; symbol_err; service_err; system_err; buf_err;
perm_denied; auth_err; cred_insufficient; authinfo_unavail;
user_unknown; maxtries; new_authtok_reqd; acct_expired; session_err;
cred_unavail; cred_expired; cred_err; no_module_data; conv_err;
authtok_err; authtok_recover_err; authtok_lock_busy;
authtok_disable_aging; try_again; ignore; abort; authtok_expired;
module_unknown; bad_item;default.

最後のdefaultは、明示的に定義されない戻り値に対する 動作を規定するのに使える。

アクション1 には正の整数かまたは以下のトークン のいずれかを指定する: ignore; ok; done; bad; die; reset. 正の整数 J がアクションとして指定された場合、現在のモジュールタイプについて 続く J 個のモジュールをスキップする。この方法により、管理者は異なった実行 パスを持つ多くのスタックされたモジュールを、適度に洗練された方法で組み合わせる ことができる。個々のモジュールの反応によって、どのパスにあるものが適用されるかが 決定される。

  • ignore: モジュールスタックに対して使われると、その モジュールの戻り値は、アプリケーションが受け取るリターンコードには影響しない。

  • bad: このアクションが指定されると、戻り値はモジュールの 失敗を表しているとみなされる。このモジュールがスタックの中で最初に失敗すると、 その戻り値はスタック全体の値として使われる。

  • die: bad と同じだが、さらにモジュールスタックが終了 して即時に PAM がアプリケーションに結果を返す。

  • ok: この戻り値をモジュールスタック全体の戻り値 として直接返すべきだと管理者が考えていることを PAM に教える。つまり、 このスタックの直前の状態が戻り値 PAM_SUCCESS を返すことになっていた 場合は、モジュールの戻り値がこの値を上書きする。もしスタックの直前の 状態が特定のモジュールの失敗を表す何らかの値を保持している場合は、 この ok値はその値を上書きしない。

  • done: ok と同じだが、 モジュールスタックを終了させて PAM の制御を即時にアプリケーションに 戻すという副作用があるところが異なる。

  • reset: モジュールスタックの状態を保持するメモリ をクリアし、次のスタックモジュールから実行を再開する。

required; requisite; sufficient; optional はそれぞれ [...] という構文をもつという意味では同等の、以下の表現を 備えている:

  • required[success=ok new_authtok_reqd=ok ignore=ignore default=bad] と同等。

  • requisite[success=ok new_authtok_reqd=ok ignore=ignore default=die] と同等。

  • sufficient[success=done new_authtok_reqd=done default=ignore] と同等。

  • optional[success=ok new_authtok_reqd=ok default=ignore] と同等である。

この新しい書式が持つパワーの感触をつかむために、これで何ができる のかを体験してみるとよいだろう。Linux-PAM-0.63 ではクライアント・ プラグイン・エージェントの概念が導入された。これにより、PAM では クライアント・サーバー・アプリケーションに対して、トランスポート・ プロトコルの継承を利用したマシン間の認証を可能にしている。 [ ... value=action ... ] という制御用構文 により、アプリケーションがそれに準拠するクライアントに対して バイナリ・プロンプトのサポートを構成できるようになっている。ただし レガシーアプリケーションの場合は柔軟に代替認証モードにフェイル オーバーできる。

module-path

動的ローダブルオブジェクトファイルのパス名 - 差し替え可能な モジュールそのもの。モジュールパスの最初の文字が / の場合、それは絶対パスであるとみなされる。 そうでない場合、与えられたモジュールパスは既定値のモジュール パスである /lib/security の後ろに付加される (ただし前述の注意事項を参照のこと)。

引数は、起動時にモジュールに渡されるトークンのリストであり、典型的な Linux のシェルコマンドへの引数と同様である。一般的に、有効な引数は オプションであり、与えられたモジュール固有のものであることが多い。 無効な引数はモジュールによって無視される。しかしながら、無効な引数に 出会った場合、そのモジュールは syslog(3) に対してエラーメッセージを 出力しなければならない。共通的なオプションについては次の節を 参照して欲しい。

引数の中に空白を含める場合は引数全体を大括弧 [] で括るようにする。 次に例を示す:

squid auth required pam_mysql.so user=passwd_query passwd=mada \
db=eminence [query=select user_name from internet_service where \
user_name=%u and password=PASSWORD(%p) and service=web_proxy]

この書式を使う場合は文字列の中に [ 文字を含んでもよい。 また文字列の中に ] 文字を含める場合は、引数の解析が 正しく行えるように \[ を使うべきである。すなわち以下の ようになる。

[..[..\]..]    -->   ..[..]..

設定ファイルの中でひとつでも書式が正しくない行があれば、(エラーが 起こって)認証処理は失敗すると思った方がよい。対応するエラーは syslog(3) への呼び出しを通してシステムのログファイルに書き込まれる。

システム設定の例

以下は設定ファイル /etc/pam.d/loginの例である。 この例ではすべてのオプションがコメント状態をはずされて(=有効になって)おり、 おそらくこのままでは使い物にならないだろう。というのは、ログインプロセス が成功するまでに多くの条件が積み重なっているからである。 pam_pwdb.so の呼び出しを除き、原則的にはすべての 条件をコメントアウトして無効にすることができる。

PAM: オリジナルのログイン設定

#%PAM-1.0
# The PAM configuration file for the login service
#
auth         required    pam_securetty.so
auth         required    pam_nologin.so
# auth       required    pam_dialup.so
# auth       optional    pam_mail.so
auth         required    pam_pwdb.so shadow md5
# account    requisite   pam_time.so
account      required    pam_pwdb.so
session      required    pam_pwdb.so
# session    optional    pam_lastlog.so
# password   required    pam_cracklib.so retry=3
password     required    pam_pwdb.so shadow md5

PAM: pam_smbpass を使ったログイン

PAM では交換式モジュールが利用できる。サンプルシステムでは 以下のものが利用可能:

$/bin/ls /lib/security

pam_access.so    pam_ftp.so          pam_limits.so     
pam_ncp_auth.so  pam_rhosts_auth.so  pam_stress.so     
pam_cracklib.so  pam_group.so        pam_listfile.so   
pam_nologin.so   pam_rootok.so       pam_tally.so      
pam_deny.so      pam_issue.so        pam_mail.so       
pam_permit.so    pam_securetty.so    pam_time.so       
pam_dialup.so    pam_lastlog.so      pam_mkhomedir.so  
pam_pwdb.so      pam_shells.so       pam_unix.so       
pam_env.so       pam_ldap.so         pam_motd.so       
pam_radius.so    pam_smbpass.so      pam_unix_acct.so  
pam_wheel.so     pam_unix_auth.so    pam_unix_passwd.so
pam_userdb.so    pam_warn.so         pam_unix_session.so

以下のログインプログラムの例では、システムパスワードデータベース (/etc/passwd, /etc/shadow, /etc/group) を使う pam_pwdb.sopam_smbpass.so で置き換えている。 後者では Microsoft MD4 暗号化パスワードハッシュを含む Samba のデータベースを使う。このデータベースは使用している UNIX/Linux システムの実装により /usr/local/samba/private/smbpasswd, /etc/samba/smbpasswd, /etc/samba.d/smbpasswd のいずれかに格納される。pam_smbpass.so モジュールは Samba 2.2.1 以降で提供される。このモジュールを コンパイルしたい場合は、Samba の configure スクリプト実行時に --with-pam_smbpass オプションを指定する。pam_smbpass モジュールに関する詳細については Samba ソースの配布物の source/pam_smbpass ディレクトリにある ドキュメントを参照して欲しい。

#%PAM-1.0
# The PAM configuration file for the login service
#
auth        required    pam_smbpass.so nodelay
account     required    pam_smbpass.so nodelay
session     required    pam_smbpass.so nodelay
password    required    pam_smbpass.so nodelay

以下に、ある Linux システムにおける PAM の設定ファイルを示す。 既定値の設定では pam_pwdb.so を使う。

#%PAM-1.0
# The PAM configuration file for the samba service
#
auth       required     pam_pwdb.so nullok nodelay shadow audit
account    required     pam_pwdb.so audit nodelay
session    required     pam_pwdb.so nodelay
password   required     pam_pwdb.so shadow md5

以下の例では、基本的な Samba 認証であっても smbpasswd データベースを使うようになっている。 このような設定を行った場合、passwd プログラムに 対しても影響を及ぼす。つまり、smbpasswd の パスワードを passwd コマンドで変更できるようになる:

#%PAM-1.0
# The PAM configuration file for the samba service
#
auth       required     pam_smbpass.so nodelay
account    required     pam_pwdb.so audit nodelay
session    required     pam_pwdb.so nodelay
password   required     pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf

Note

PAM では階層的な(スタックされた)認証の仕組みを提供している。 たとえば、ある PAM モジュールが受け取った情報を、PAM スタックの 次のモジュールに渡すことができる。PAM に関する特定の機能の詳細については、 お使いのシステムに特化したドキュメントを参照して欲しい。 さらにいくつかの Lunux の実装では、すべての認証を中心となる単一のファイルで 設定できる pam_stack.so と呼ばれるモジュールが 提供されている。 pam_stack.so 方式は管理者の手間を軽減 してくれるので、熱心なファンもいる。 もっとも、環境によってもいろんな問題があるわけであり、前述のどの方式を 取るにしてもそれぞれのトレードオフがある。より有益な情報を探すために、 PAM のドキュメントをあたってみるのもよいだろう。

smb.conf の PAM 設定

obey pam restrictions と呼ばれる smb.conf のオプションがある。このオプションに関する SWAT のヘルプを以下に示す:

Samba が PAM サポート (--with-pam) 付きでコンパイル されている場合、Samba が PAM の account および session 管理 ディレクティブに従うかどうかをこのパラメーターで 制御できる。 PAM を使うが認証は平文のみで、かつどの account/session 管理も 無視するというのが既定値の動作である。 encrypt passwords = yes の場合、Samba は常に認証については PAM を無視する。その理由は、 SMB パスワード暗号を使う場合に必要なチャレンジ/レスポンス方式の 認証メカニズムを PAM モジュールが サポートしていないからである。

既定値:obey pam restrictions = no

winbindd.soを使った遠隔 CIFS 認証

どんな OS であっても、その OS 自身がアクセス可能なユーザー証明情報が (どこからか)提供されていることを前提としている。UNIX ではユーザー 識別子(UID)だけでなくグループ識別子(GID)も必要となる。これらはいずれも 単純な整数値であり、/etc/passwd といったパスワード バックエンドより取得する。

Windows NT サーバーでは、ユーザーとグループは相対ID(RID)に割り当て られている。これらはユーザーやグループが作られる際、ドメイン毎に 一意となる。Windows NT のユーザーやグループを UNIX のユーザーやグループ に変換するためには、RID と UNIX のユーザー/グループの ID を マッピングする必要がある。これが winbind が行う仕事のひとつである。

winbind のユーザーとグループはサーバーから解決要求が出され、ユーザーと グループの ID が指定された範囲内で割り当てられる。クライアントが ユーザーとグループを列挙するコマンドを実行すると、すぐに既存の全 ユーザーとグループがマッピングされ、割り当て処理が先着順に行われる。 割り当てられた UNIX ID は Samba の lock ディレクトリ配下のデータベース ファイルに保持されて記憶される。

これにより、目先が利く管理者なら、pam_smbpass.sowinbindd と、ldap のような 分散型の passdb backend との 組み合わせにより、(Linux のような)PAM を意識したプログラムや アプリケーションからも使うことのできる、中央集権型で管理された分散型の ユーザー/パスワードデータベースが使えるようになるということが理解 できるだろう。このお膳立てにより、広範囲のネットワーク認証のトラフィック が削減できるという限りにおいては、マイクロソフトのActive Directory Service (ADS)に比較して、特に強力な優位性を持てる。

Warning

UNIX の ID データベースに対応する RID はユーザーとグループのマッピング が格納されているファイルにのみ存在し、winbindd によって格納される。このファイルが削除されていたり壊れていたりする場合、 winbindd はどのユーザーやグループが Windows NT のユーザーやグループの RID と対応するのかを決定できなくなる。

pam_smbpass.so を使ったパスワードの同期

pam_smbpass は PAM モジュールのひとつであり、 システム上で smbpasswd (Sambaのパスワード) データベースと UNIX のパスワードファイルとの同期を取るために 使われる。PAM は Solaris, HPUX, Linux などの UNIX オペレーティングシステム 上でサポートされている API であり、認証メカニズムに対する標準的な インターフェースを提供する。

このモジュールはローカルにある smbpasswd ユーザー データベースを使って認証する。リモートの SMB サーバーで認証したり、 システム上の SUID root されたバイナリの存在を調べたいという向きには、 pam_winbind の方を使うことをお勧めする。

このモジュールで認識されるオプションについては、 次のテーブルを参照して欲しい。

Table 28.1. pam_smbpassで認識されるオプション

debug より多くのデバッグ情報を出力する
audit debugと似ているが、認識できないユーザー名も表示する
use_first_pass ユーザーにパスワード入力を求めない。 パスワードは PAM_ 項目から持ってくる
try_first_pass 直前の PAM モジュールからパスワードの取得を試みる。 取得できなければユーザーからの入力を求める。
use_authtok try_first_pass に似ているが、 (パスワードモジュールだけをスタックさせるための) 新しい PAM_AUTHTOK が事前にセットされていなければ『失敗する』
not_set_pass このモジュールで使われたパスワードを他のモジュールに流用させない
nodelay 認証の失敗までに最大1秒の遅延を挟まない
nullok パスワードなしを認める
nonull パスワードなしを認めない。これは Samba の設定に優先する。
migrate auth コンテキストでのみ意味を持つ。 成功した認証で使われたパスワードを使って smbpasswd ファイルを更新する。
smbconf=ファイル名smb.conf ファイルへの別のパスを指定する


Linux の /etc/pam.d/ 形式のファイル構造で pam_smbpass.so を使うときの例を以下に示す。 このツールを別のプラットフォームに実装したいと思っている方は、 適当に読み替えてみてほしい。

パスワードの同期設定

以下の PAM 設定例では、/etc/passwd (/etc/shadow) が変更されたときに、pam_smbpass を利用して private/smbpasswdが連動して変更されるようにしている。 これはパスワードの有効期限が切れたときに(sshのような) アプリケーションがパスワードを変更するような場合に便利である。

#%PAM-1.0
# password-sync
#
auth       requisite    pam_nologin.so
auth       required     pam_unix.so
account    required     pam_unix.so
password   requisite    pam_cracklib.so retry=3
password   requisite    pam_unix.so shadow md5 use_authtok try_first_pass
password   required     pam_smbpass.so nullok use_authtok try_first_pass
session    required     pam_unix.so

パスワード移行のための設定

以下は pam_smbpass を使って平文から Samba 用の暗号化パスワードに移行するための PAM 設定である。 他のメソッドと違い、この方法なら一度も Samba の共有に接続 したことがなくても使える:パスワードを移行すれば、ユーザーが ftp で接続したり、ssh でログインしてメールを取り出したりする場合などにも使える。

#%PAM-1.0
# password-migration
#
auth       requisite   pam_nologin.so
# pam_smbpass is called IF pam_unix succeeds.
auth       requisite   pam_unix.so
auth       optional    pam_smbpass.so migrate
account    required    pam_unix.so
password   requisite   pam_cracklib.so retry=3
password   requisite   pam_unix.so shadow md5 use_authtok try_first_pass
password   optional    pam_smbpass.so nullok use_authtok try_first_pass
session    required    pam_unix.so

従来のパスワード設定

以下の例は、従来の smbpasswd 利用時のための PAM 設定である。private/smbpasswd 全体が 投入され、SMB パスワードが存在しなかったり UNIX のパスワードと 合致しない場合はエラーと見なされる。

#%PAM-1.0
# password-mature
#
auth       requisite    pam_nologin.so
auth       required     pam_unix.so
account    required     pam_unix.so
password   requisite    pam_cracklib.so retry=3
password   requisite    pam_unix.so shadow md5 use_authtok try_first_pass
password   required     pam_smbpass.so use_authtok use_first_pass
session    required     pam_unix.so

Kerberosパスワード統合設定

以下の PAM 設定例は、pam_krb5 といっしょに 使われる pam_smbpass を示している。 これは Samba PDC 上で、かつそれがkerberos realmのメンバーで ある場合に有用である。

#%PAM-1.0
# kdc-pdc
#
auth       requisite   pam_nologin.so
auth       requisite   pam_krb5.so
auth       optional    pam_smbpass.so migrate
account    required    pam_krb5.so
password   requisite   pam_cracklib.so retry=3
password   optional    pam_smbpass.so nullok use_authtok try_first_pass
password   required    pam_krb5.so use_authtok try_first_pass
session    required    pam_krb5.so

よくあるエラー

PAM は割と扱いづらく、設定エラーを引き起こしやすい。以下に Samba のメーリングリストで見かけたいくつかのケースを紹介する。

pam_winbind の問題

あるユーザーからPAM の設定で以下の問題が起こった との報告があった:

auth required /lib/security/pam_securetty.so
auth sufficient /lib/security/pam_winbind.so
auth sufficient /lib/security/pam_unix.so use_first_pass nullok
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_winbind.so
password required /lib/security/pam_stack.so service=system-auth

[ctrl][alt][F1]で新しくコンソールを開くと、私の ID pitie ではログインできない。ユーザー scienceu\pitie でやってみたが、それでもだめだった。

この問題は pam_stack.so service=system-authがある 時に発生する。このファイルに入っている多くの設定には、 すでに実行中ものが二重に入っていることがよくある。 authaccount から pam_stack の行をコメントアウト したらどうなるかやってみてくれ。それで動くなら、 /etc/pam.d/system-auth ファイルを見て、 その中で本当に必要な行だけを /etc/pam.d/login ファイルにコピーすればいい。別のやり方として、もしすべての サービスで winbind を動かしてもいいなら、 /etc/pam.d/system-auth に winbind 固有の 設定を追加してもいい。

Winbind がユーザーとグループを解決してくれない

僕の smb.conf は正しく設定されている。 idmap uid = 12000idmap gid = 3000-3500 を指定しているし winbind も動いている。 以下のコマンドはちゃんと動いている。

root# wbinfo -u
MIDEARTH\maryo
MIDEARTH\jackb
MIDEARTH\ameds
...
MIDEARTH\root

root# wbinfo -g
MIDEARTH\Domain Users
MIDEARTH\Domain Admins
MIDEARTH\Domain Guests
...
MIDEARTH\Accounts

root# getent passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/bash
...
maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false

しかし、このコマンドが失敗する:

root# chown maryo a_file
chown: 'maryo': invalid user

一体どうなってんの?何か間違ってる?

名前キャッシュデーモンである nscd が動いてる んじゃないかな?そいつを終わらせて、起動しないようにしてくれ。 それでうまくいくと思うよ。

Chapter 29. Microsoft Windows ネットワークへのSambaの統合

John H. Terpstra

Samba Team

(Jan 01 2001)

この章ではNetBIOS over TCP/IPの名前からIPアドレスを解決する事について取り扱う。もしも、 使用しているWindowsクライアントがNetBIOS over TCP/IPを使うように設定されていない場合、 この章は使用している環境には適用されない。もしも使用している設定が、NetBIOS over TCP/IPを 使うのであれば、この章はネットワークの問題を解決するのに手助けとなるだろう。

Note

NetBIOS over TCP/IPはNetBEUIとは関係ない。NetBEUIはNetBIOS over Logical Link Control(LLC) である。最近のネットワークでは、NetBIOSを動かさないことを強く推奨している。また、 NetBEUI over TCP/IPというようなものはない。そのようなプロトコルは、全く完全に 誤解である。

機能と利便性

多くのMicrosoft Windows ネットワーク管理者は、UNIX/Linux OS中で実装されているような 基本的なTCP/IPネットワーキングに一度も出会ったことはない。同じく、多くのUNIXとLinux 管理者は、Microsoft Windows TCP/IPベースのネットワークの複雑さ(とそれに対する願望 は無いかもしれない)に出会ったことがない。

この章では、各OS環境において、どのように、名前がIPアドレスに解決されるかについての 基本について、簡単に紹介する。

背景情報

Microsoft Windows 2000から、Microsoft Windows ネットワークをNetBIOS over TCP/IPなしで 動かすことが可能になった。NetBIOS over TCP/IPは、NetBIOS名前解決にUDPポート137を、 NetBIOSセッションサービスにTCPのポート139を使う。NetBIOS over TCP/IPが、Microsoft Windows 2000とそれ以降のクライアントで無効になると、TCPポート445のみが使われ、 UDPポート137とTCPポート139は使われなくなる。

Note

Windows 2000かそれ以降のクライアントを使うとき、もしも NetBIOS over TCP/IPが無効になって いない場合、クライアントはUDPポート137(NetBIOSネームサービスであり、Windows Internet Name serviceあるいはWINSとしても知られている)とTCPポート445(実際のファイルと印刷データの 転送)を使う。

NetBIOS over TCP/IPが無効の場合、DNSの使用が基本である。現在ほとんどの、 NetBIOS over TCP/IPを無効にした環境では、Microsoft Active Directoryサービス(ADS)を 使っている。ADSは サービスリソースレコード(SRV RR)と増分ゾーン転送(IXFR)を使う、ダイナミックDNSを要求 する。 ADSと同時にDHCPを使うことは、クライアントワークステーションネットワーク設定上で 集中制御管理を行う手段として推奨される。

純粋なUNIX/Linux環境中での名前解決

この節が対象としている重要な設定ファイルは以下の通り:

  • /etc/hosts

  • /etc/resolv.conf

  • /etc/host.conf

  • /etc/nsswitch.conf

/etc/hosts

このファイルは静的なIPアドレスと名前の一覧を含んでいる。

127.0.0.1	localhost localhost.localdomain
192.168.1.1	bigbox.quenya.org	bigbox	alias4box

/etc/hostsの目的は、名前解決メカニズムを提供することであり、 ユーザーはIPアドレスを覚えなくても済むようになる。

物理的なネットワーク転送レイヤ上で送られたネットワークパケットは、IPアドレスを 使うのではなく、メディアアクセスコントロールアドレス、あるいはMACアドレス を使って通信を行う。IPアドレスは、現在32ビット長で、通常ドット(あるいは ピリオド)で分割された4つの十進数で表現される。 たとえば、168.192.1.1である。

MACアドレスは48ビット(あるいは6バイト)であり、通常2桁の16進数をコロン で分離して表現される。たとえば 40:8e:0a:12:34:56.である。

すべてのネットワークインタフェースはMACアドレスを持たねばならない。MACアドレス に対して1つ以上のIPアドレスを割り当てることができる。IPアドレスとMACアドレスの間に 何らの関係はない。そのようなすべての割り当ては、任意、あるいは自由に行える。 最も基本的なレベルでは、すべてのネットワーク津心は、MACアドレスを使って行われる。 MACアドレスがグローバルに一意で、一般的に、特定のインタフェースに固定されている ので、IPアドレスの割り当てはネットワーク管理の視点から意味をなす。1つ以上のIP アドレスをMACアドレス毎に割り当てられる。1つのアドレスはプライマリIPアドレスで ある必要がある。これは、アドレス解決プロトコル(ARP)の問い合わせで 帰ってくるアドレスである。

ユーザーあるいはプロセスが他のマシンと通信したい場合、プロトコルは、 マシン名あるいはホスト名が、TCP/IP設定制御ファイルで 制御される方法で、IPアドレスに解決されるように実装されている。 /etc/hostsはそのようなファイルの1つである。

送信先のインタフェースのIPアドレスが決まったとき、ARP/RARPと呼ばれるプロトコルが、 対象インタフェースのMACアドレスを識別するのに使われるARPは、すべて1であるMACアドレスを 使って、ローカルネットワークセグメント上のすべてのインタフェースに対してUDPを使って 送信する、ブロードキャストベースの方法である。ネットワークインタフェースは2つのMAC アドレスのみに返信する。そのインタフェース固有のアドレスと、ff:ff:ff:ff:ff:ffという アドレスである。ARP要求からの返信パケットにはMACアドレスと各インタフェースのプライマリ IPアドレスが含まれている。

/etc/hostsファイルはすべてのUNIX/Linux TCP/IPインストールの 基本であり、最低でも、localhostとローカルネットワークインタフェースの IPアドレスとローカルマシン上のプライマリ名を含んでいる。このファイルは、 名前解決方法の出発点となる。つまり、その他の名前解決機構を利用する前に、 基本的な名前解決は行われている。

/etc/resolv.conf

このファイルで名前解決ライブラリを指定する:

  • マシンが存在するドメインの名前

  • 完全に一意でないホスト名をIPアドレスに解決しようとする時に 自動的に検索されるべき任意のドメイン名。

  • 名前解決検索を実行するのに問い合わせされる、有効なドメイン ネームサーバーのIP仇レスか名前。

/etc/host.conf

/etc/host.confは、/etc/resolv.conf中で 設定できるようにするための主要な手段である。これはきわめて重要な設定ファイルである。 このファイルは名前解決が処理されるかもしれない順序を制御する。通常の構造は 以下の通り:

order hosts,bind
multi on

両方のアドレスが返されるべきである。詳細については、 host.confマニュアルページを参照のこと。

/etc/nsswitch.conf

このふぁいるは実際の名前解決先を制御する。ファイルは通常以下のようにリゾルバー オブジェクト指定を記述する:

# /etc/nsswitch.conf
#
# Name Service Switch 設定ファイル
#

passwd:		compat
# Alternative entries for password authentication are:
# passwd:	compat files nis ldap winbind
shadow:		compat
group:		compat

hosts:		files nis dns
# Alternative entries for host name resolution are:
# hosts:	files dns nis nis+ hesiod db compat ldap wins
networks:	nis files dns

ethers:		nis files
protocols:	nis files
rpc:		nis files
services:	nis files

もちろん、それらの各メカニズムは、適切な機能かサービスを正しく設定する 事を要求する。

ネットワーク要求/メッセージを送ることが必要にならない限り、TCP/IPネットワークは 何もデータを送らないことに注意すべきである。すべてのTCP/IP通信は、必要時にのみ 通信を行うという原則を仮定している。

バージョン 2.2.0から、Sambaはname service switch機構用の拡張のために、Linuxをサポート するようになり、Linuxクライアントは、Microsoft Windows NetBIOSの名前解決機能を使える ようになった。この機能を使うためには、Sambaはmakeコマンドで適切な引数を付けてコンパイル する必要がある(すなわち、make nsswitch/libnss_wins.so)。 次に名前解決ライブラリを/libディレクトリにインストールし、 winsパラメーターを、/etc/nsswitch.confファイル 中のhosts:行に追加する必要がある。この時点で、 SambaサーバーとMicrosoft Windowsマシンが存在するワークグループ内にいる、 どこかのMicrosoft Windowsマシンに対してNetBIOSマシン名でping出来る。

Microsoft Windowsネットワーク内でのような名前解決

Microsoft Windowsネットワークは、各マシンに割り当てられた名前をベースにしている。 これは、コンピュータ名,マシン名, ネットワーキング名,NetBIOS名あるいはSMB名 という、種々の(そして矛盾した)名前で呼ばれている。すべての単語は、ワークグループか ドメイン名の名前にも適用できるNetBIOS名を除いて同じものを意味する。 ワークグループドメインという単語は、実際、どのマシンが 関連づけられているかという、単なる名前である。すべてのNetBIOS名はきっかり16文字である。 16番目の文字は予約されている。登録されたNetBIOS名のサービスレベル情報を指定する 1バイトとして使われる。そのため、NetBIOSマシン名は、クライアント/サーバーによって 提供される各サービスタイプで登録される。

一意なNetBIOS名グループ名の表は、典型的なNetBIOS 名前/サービスタイプ登録一覧である。

Table 29.1. 一意なNetBIOS名

MACHINENAME<00>MACHINENAME上でサーバーサービスが動いている
MACHINENAME<03>一般的なマシン名(NetBIOS名)
MACHINENAME<20>LanManサーバーサービスがMACHINENAMEで動いている
WORKGROUP<1b>ドメインマスターブラウザー

Table 29.2. Group Names

WORKGROUP<03>WORKGROUPのすべてのメンバーによって登録された一般的な名前
WORKGROUP<1c>ドメインコントローラー/ネットログオンサーバー
WORKGROUP<1d>ローカルマスターブラウザー
WORKGROUP<1e>ブラウザー選定サービス

すべてのNetBIOSマシンは、それに固有の名前を 一意なNetBIOS名グループ名単位で登録することに注意すべきである。 これは、システム管理者が、/etc/hosts中か、DNSデータベース中で、 各IPアドレスに割り当てられる名前を決める伝統的な決め方をするTCP/IPでの流儀と 大きく異なる。

明確な説明の中の、1つの重要なポイントに注意すべきである。 /etc/hostsファイルとDNSレコードは、それが必要かもしれない サービスのタイプを見つけることに、Microsoft Windowsクライアントが依存する、 NetBIOS名前情報を提供しない。これの例は、Microsoft Windowsクライアントが ドメインログオンサーバーを捜そうとする時に起こる事である。クライアントは 名前タイプ*<1C>を登録しているすべてのマシンを列挙するために (NetBIOSブロードキャスト経由で)検索を実行することによって、このサービスと、この サービスを提供しているサーバーのIPアドレスを捜す。次にログオン要求は、IPアドレスの 一覧として返された各IPアドレスに送られる。どれかのマシンが最初に応答すると、 次にそのマシンがログオンサービスを提供することになる。

Microsoft Windows ネットワークのセキュリティアーキテクチャを示している付加的な意味を 持っているので、ワークグループおよびドメインという 名前は、まったくもって紛らわしい。ワークグループという単語は、 ネットワーク環境の基本原則がピアツーピア構造になっている事を示している。 ワークグループにおいては、すべてのマシンは、自分自身のセキュリティについて責任があり、 一般的にそのセキュリティは、パスワードの使用で制限される(共有レベルのセキュリティ として知られている)。ピアツーピアのネットワークを使うほとんどの場合、自分自身の マシンを制御するユーザーは単に全くセキュリティを持たないように(訳注:共有しないように) するだろう。ワークグループ環境でもユーザーレベルのセキュリティを使うことは可能で、 その場合、ユーザー名と対応するパスワードを使うことを要求する。

Microsoft Windowsネットワークは、ローカルとリモートマシンすべてでのメッセージ通信用の マシン名を使うために、前もって決定される。使われるプロトコルは、 Server Message Block (SMB)と呼ばれ、これはNetBIOSプロトコル (Network Basic Input/Output System)を使って実装される。NetBIOSはLLC (Logical Link Control)プロトコルを使ってカプセル化される。 この場合、結果のプロトコルはNetBEUI(Network Basic Extended User Interface)と呼ばれる。 NetBIOSは、Novell NetWareによって使われるIPX(Internetworking Packet Exchange)上でも 動作できる。また、TCP/IPプロトコル上でも動作でき、この場合、結果の プロトコルは、NBTあるいはNetBT、すなわちNetBIOS over TCP/IPと呼ばれる。

Microsoft Windows マシンは、たくさんの複雑な名前解決メカニズムを使う。主にTCP/IP で接続するので、このデモはその領域にのみ限っている。

NetBIOSネームキャッシュ

すべてのMicrosoft Windowsマシンは、おおよそ過去10分から15分の間に通信したすべての 外部マシンのNetBIOS名とIPアドレスを格納する、メモリ中のバッファーを使う。設定された すべての名前解決機構を使って行うよりも、ローカルキャッシュからマシンのIPアドレスを 得る方がより効率的である。

もしも、ローカル名前キャッシュにその名前があるマシンが、キャッシュ上で満了になり 削除される前にシャットダウンした場合、そのマシンへメッセージ交換を行おうとすると、 そのマシンはタイムアウトするだろう。その名前がキャッシュにあるので、名前解決は 成功するが、マシンは反応しない。これは、ユーザーにとって不満を感じさせるが、これは プロトコルの特性である。

NetBIOS名前キャッシュの検査を行うMicrosoft Windows ユーティリティは、 nbtstatである。Sambaにおける同等品はnmblookupである。

LMHOSTSファイル

このファイルは通常Microsoft Windows NT 4.0かWindows 200x/XPのディレクトリ %SystemRoot%\SYSTEM32\DRIVERS\ETCにあり、IPアドレスとマシン名が 対になったものを含む。LMHOSTSファイルはNetBIOS名からIPアドレスへの マッピングを行う。

典型的なものは以下の通り:

# Copyright (c) 1998 Microsoft Corp.
#
# This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
# over TCP/IP) stack for Windows98
#
# This file contains the mappings of IP addresses to NT computer names
# (NetBIOS) names. Each entry should be kept on an individual line.
# The IP address should be placed in the first column followed by the
# corresponding computer name. The address and the computer name
# should be separated by at least one space or tab. The "#" character
# is generally used to denote the start of a comment (see the exceptions
# below).
#
# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
# files and offers the following extensions:
#
#      #PRE
#      #DOM:<domain>
#      #INCLUDE <filename>
#      #BEGIN_ALTERNATE
#      #END_ALTERNATE
#      \0xnn (non-printing character support)
#
# Following any entry in the file with the characters "#PRE" will cause
# the entry to be preloaded into the name cache. By default, entries are
# not preloaded, but are parsed only after dynamic name resolution fails.
#
# Following an entry with the "#DOM:<domain>" tag will associate the
# entry with the domain specified by <domain>. This effects how the
# browser and logon services behave in TCP/IP environments. To preload
# the host name associated with #DOM entry, it is necessary to also add a
# #PRE to the line. The <domain> is always pre-loaded although it will not
# be shown when the name cache is viewed.
#
# Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT)
# software to seek the specified <filename> and parse it as if it were
# local. <filename> is generally a UNC-based name, allowing a
# centralized lmhosts file to be maintained on a server.
# It is ALWAYS necessary to provide a mapping for the IP address of the
# server prior to the #INCLUDE. This mapping must use the #PRE directive.
# In addition the share "public" in the example below must be in the
# LanMan Server list of "NullSessionShares" in order for client machines to
# be able to read the lmhosts file successfully. This key is under
# \machine\system\currentcontrolset\services\lanmanserver\
# parameters\nullsessionshares
# in the registry. Simply add "public" to the list found there.
#
# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
# statements to be grouped together. Any single successful include
# will cause the group to succeed.
#
# Finally, non-printing characters can be embedded in mappings by
# first surrounding the NetBIOS name in quotations, then using the
# \0xnn notation to specify a hex value for a non-printing character.
#
# The following example illustrates all of these extensions:
#
# 102.54.94.97     rhino     #PRE #DOM:networking  #net group's DC
# 102.54.94.102    "appname  \0x14"       #special app server
# 102.54.94.123    popular   #PRE         #source server
# 102.54.94.117    localsrv  #PRE         #needed for the include
#
# #BEGIN_ALTERNATE
# #INCLUDE \\localsrv\public\lmhosts
# #INCLUDE \\rhino\public\lmhosts
# #END_ALTERNATE
#
# In the above example, the "appname" server contains a special
# character in its name, the "popular" and "localsrv" server names are
# pre-loaded, and the "rhino" server name is specified so it can be used
# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
# system is unavailable.
#
# Note that the whole file is parsed including comments on each lookup,
# so keeping the number of comments to a minimum will improve performance.
# Therefore it is not advisable to simply add lmhosts file entries onto the
# end of this file.

HOSTSファイル

このファイルは、通常Microsoft Windows NT 4.0あるいはWindows 200x/XPの ディレクトリ%SystemRoot%\SYSTEM32\DRIVERS\ETC中にあり、 IPアドレスとIPホスト名が対になったものを含む。これは、名前解決機構として 使うことが出来るが、どのようにTCP/IP環境が設定されたかに依存する。このファイルは UNIX/Linuxでの/etc/hostsファイルと同じ使い方である。

DNSによる検索

この機能は、ネットワーク設定機能中のTCP/IPに関する設定の中で設定できる。 もしもこれが有効になると、どのようにNetBIOSノードタイプパラメーターが設定 されたかに正確に依存して決まる、選択された名前解決シーケンスが後に続く。 ノードタイプ0は、NetBIOS名前キャッシュ中で名前検索をしても見つからなかった場合、 NetBIOSブロードキャスト(UDP上のブロードキャスト)が使われる。もしも、失敗した場合、 次にDNS、HOSTSとLMHOSTSが使われる。もしもノードタイプが8ならば、DNS,HOSTS,LMHOSTS の検索から結果を得る前に、NetBIOSユニキャスト(UDPユニキャストで)がWINSサーバーに 送られるか、ブロードキャスト検索が使われる。 This capability is configured in the TCP/IP setup area in the network configuration facility. If enabled, an elaborate name resolution sequence is followed, the precise nature of which is dependent on how the NetBIOS Node Type parameter is configured. A Node Type of 0 means that NetBIOS broadcast (over UDP broadcast) is used if the name that is the subject of a name lookup is not found in the NetBIOS name cache. If that fails, then DNS, HOSTS, and LMHOSTS are checked. If set to Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the WINS server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast lookup is used.

WINSによる検索

WINS(Windows Internet Name Server)サービスはrfc1001/1002で定義されたNBNS (NetBIOSネームサーバー)と同等のものである。WINSサーバーは、もしもTCP/IP設定で、 少なくとも1つのWINSサーバーのIPアドレスを指定したとき、Windows クライアントによって 登録される名前とIPアドレスを格納する。

SambaをWINSサーバーサーバーとして設定するには、以下のパラメーターをsmb.conf ファイルに追加する必要がある:

wins support = Yes

SambaをWINSサーバーを使うように設定するためには、以下のパラメーターをsmb.conf ファイルに追加する必要がある:

wins support = No
wins server = xxx.xxx.xxx.xxx

ここで、xxx.xxx.xxx.xxxは、WINSサーバーのIPアドレスである。

SambaをWINSサーバーとして設定するための情報は、 ネットワークブラウジングを参照のこと。

よくあるエラー

TCP/IPネットワーク設定の問題は、すべてのネットワーク管理者が遅かれ早かれ直面する。 原因は、キーボード入力の問題から、単純なケアレスミスまで多様である。もちろん、 誰もが常時不注意であるというわけではない!

片方向しかpingが届かない

WindowsからSambaサーバーにpingが出来るが、SambaサーバーからWindowsにpingが できない。

WindowsマシンはIPアドレスが192.168.1.2で、ネットマスクが255.255.255.0であり、 Sambaサーバー(Linux)はIPアドレスが192.168.1.130で、ネットマスクが 255.255.255.128である。マシンはローカルネットワーク上にあり、その他の外部 接続はない。

整合していないネットマスクのため、Windowsマシンは、ネットワーク192.168.1.0/24上に いて、Sambaサーバーはネットワーク192.168.1.128/25にいる。 これは論理的に異なったネットワークである。

ネットワーク接続がとても遅い

遅いネットワークという共通の問題には以下がある:

  • クライアントがDNSを使うように設定されていて、DNSサーバーがダウンしている。

  • クライアントがリモートのDNSサーバーサーバーを使うように設定されているが、 リモート接続がダウンしている。

  • クライアントがWINSサーバーを使うように設定されているが、 WINSサーバーがない。

  • クライアントがWINSサーバーを使うように設定されていないが、 WINSサーバーがある。

  • ファイアウォールがDNSかWINSトラフィックを制限している。

Sambaサーバー名前変更の問題

Sambaサーバーの名前が変わり、Sambaが再起動した後、Sambaサーバーへ、新しい 名前で、Microsoft Windows NT4ワークステーションからpingが出来ない。しかし、 古い名前でのpingは引き続き出来るなぜ?

この説明から、以下の3つが明白となる:

  • WINSが使われていないブロードキャストベースの名前解決のみ使われている。

  • Sambaサーバーが改名されて再起動したのが10分か15分前以内である。

  • 古いSambaサーバー名が、まだMicrosoft Windows NT4 ワークステーション 上のNetBIOS名前キャッシュ中にある。

Microsoft Windows NT4マシン上のNetBIOS名前キャッシュ中に、どの名前が存在して いるかを調べるには、cmdシェルを開き、以下を行う:

C:\> nbtstat -n

              NetBIOS Local Name Table

   Name                 Type          Status
------------------------------------------------
FRODO            <03>  UNIQUE      Registered
ADMINISTRATOR     <03>  UNIQUE      Registered
FRODO            <00>  UNIQUE      Registered
SARDON           <00>  GROUP       Registered
FRODO            <20>  UNIQUE      Registered
FRODO            <1F>  UNIQUE      Registered


C:\> nbtstat -c

             NetBIOS Remote Cache Name Table

   Name                 Type       Host Address     Life [sec]
--------------------------------------------------------------
GANDALF	<20>  UNIQUE      192.168.1.1          240

C:\> 

この例では、GANDALFがSambaサーバーでFRODO が、Microsoft Windows NT4 ワークステーションである。 最初の行は、ローカル名前テーブルの内容を示していて(すなわち、Microsoft Windows ワークステーションとして識別される)、2行目はNetBIOS名前キャッシュ中に あるNetBIOS名を示している。 名前キャッシュ中にはこのワークステーションの名前として知られているリモートマシン を含んでいる。

Chapter 30. ユニコード/文字セット

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

たかはし もとのぶ

日本語サポート 

25 March 2003

機能と利便性

どんな技術もいつかは成熟する。ここ10年間に焦点を当てたときに、成熟度が大きく 前進した領域のひとつが、どこでもだれでもコンピュータを利用できるようにする ための技術である。もっとも、常にそうだったわけではない。実際、ソフトウェアを 開発する際には、作成した国でのみ使うことを想定して開発されるのが当たり前だった のはさほど昔のことではない。

すべてのコンピュータユーザーに自国の言語サポートを提供するために使われたすべての労力、 Openi18n organizationの労力は、 特記に値する。 Of all the effort that has been brought to bear on providing native language support for all computer users, the efforts of the Openi18n organization is deserving of special mention.

Samba-2.xは、codepagesと呼ばれる単一のロケール機構をサポート していた。Samba-3では真に国際的な、ファイルと印刷共有プラットフォームとして 予定されていた。

文字セットとユニコードとは何か

コンピュータは数字で通信する。テキストにおいては、各数字は対応する文字に変換される。 特定の数に割り当てられた意味は、使用する文字セット(charset)に 依存する。

文字セットは数字から文字への変換のために使われる表として見る事ができる。 すべてのコンピュータが同じ文字セット(ドイツのウムラウト、日本の文字セットなど)を 使うわけではない。American Standard Code for Information Interchange (ASCII) エンコーディングシステムは、現在まで、コンピュータによって使われる基本の文字 エンコーディング体系となっていた。これは、256文字を含む文字セットを使用する。 このモードのエンコーディングを使うと、各文字は正確に1バイトとなる。

ASCIIエンコーディングが取るよりも、少なくとも2倍の、より多くの記憶容量を必要とする、 拡張文字をサポートする文字セットもある。そのような文字セットは、考えられるすべての 文字よりも多い256 * 256 = 65536文字を含むことが出来る。これらは、 1つの文字を格納するために、1バイトより多く使うという理由で、マルチバイト文字セットと 呼ばれる。

ある標準化されたマルチバイト文字セットエンコーディング機構は、 ユニコードである。 マルチバイト文字セットを使う大きな利点は、それを使うだけで済むと言うことである。 通信時に、2つのコンピュータが尾内文字セットを使うようにする必要はない。

古いWindowsクライアントはMicrosoftによるコードページという 単一バイト文字セットを使っている。しかし、SMB/CIFSプロトコル中で使われるために 調停される文字セットではサポートされていない。そのため、より古いクライアントと通信 する時、同じ文字セットを使うようにしなければならない。より新しいクライアント (Windows NT、200x、XP)では、ユニコードを使って通信する。

Sambaと文字セット

Samba-3では、Sambaはユニコードで通信できる。内部的には、Sambaは3つの文字セットを 認識する。

unix charset

これは使用しているOSによって内部的に使われる文字セットである。 既定値はUTF-8で、ほとんどのシステムに適しており、 すべての言語中のすべての文字をカバーする。以前のSambaリリースにおける 既定値は、クライアントのエンコーディングでファイル名を保存するための ものであった。たとえば、CP850は西ヨーロッパ各国用である。

display charset

これは、画面上でメッセージを表示するためにSambaが使う 文字セットである。これは一般的にunix charsetと 同じにすべきである。

dos charset

これは、DOSとWindows 9x/Meクライアントと通信する時に Sambaが使う文字セットである。より新しいクライアントすべてとはユニコードで 通信する。既定値は、インストールした、使用するシステム上の文字セットに 依存する。使用するすシステム上での既定値が何かと言うことは、 testparm -v | grep "dos charset"を実行して 調べられる。

古い名前からの変換

以前のSambaバージョンは、何らの文字セット変換を行わないので、ファイル名中の文字セットは、 通常UNIX文字セットでは正しくならない。DOS/Windowsクライアントによって使われるローカル 文字セット専用である。

Bjoern Jackeは、convmvという、 1つのコマンドですべてのディレクトリ構造を異なった文字セットに変換できるユーティリティを 作成した。

日本語の文字セット

日本語の文字セットを設定するのはかなり難しい。それは以下のような理由による:

  • Windows文字セットはオリジナルの日本工業標準(JIS X 0208)から拡張された ものであり、標準化されていない。これは、正確に標準にそった実装は、 Windows文字セット全部をサポート出来ないと言うことである。

  • 主に歴史的な理由により、日本においては複数のエンコーディング方法があり、 おのおのは、互いに完全に互換ではない。主要なエンコーディング方法は2つ ある。1つはWindowsといくつかのUNIXで使われるシフトJIS系列である。 もう1つはEUC-JP系列であり、ほとんどのUNIXとLinuxで使われている。さらに、 Sambaは以前に、CAPとHEXという、CAP/NetAtalkと日本語ファイル名を使えない UNIXとの互換性を確保するための、固有なエンコーディング方法を提供して いた。EUC-JP系列のいくつかの実装は、完全なWindows文字セットをサポート できない。

  • ユニコードと旧来の日本語文字セットとの間での変換テーブルは いくつかある。ある1つはWindowsと互換であり、そのほかはユニコード コンソーシアムのものをベースにしたものであり、ほかには複数のものを まぜた実装がある。ユニコードコンソーシアムは、公式にはユニコードと 他の旧来の文字セットとの間での変換テーブルを定義していないので、 それは標準にはなり得ない。

  • iconv()内で有効な文字セットと変換テーブルは、利用できるiconv ライブラリに依存する。その次に、日本語のロケール名は異なったシステム上 では異なっているかもしれない。これは、文字セットパラメーターの値は、 使用しているiconv()の実装に依存するというということである。

    2バイトの固定的なUCS-2エンコーディングがWindows内部で使われているが、 シフトJIS系列のエンコーディングは、英語環境でASCIIエンコーディングが 使われているように日本語環境で通常使われている。

基本的なパラメーターの設定

dos charsetdisplay charsetは ロケールと互換のある文字セットとWindows上で使われているエンコーディング方法に 設定すべきである。これは通常CP932であるが、時々違う名前を使う。

unix charsetはシフトJIS系列、EUC-JP系列、あるいは UTF-8系列に設定できる。UTF-8は常時利用可能であるが、他のロケールとそれ自身の 名前の有効性は使用するシステム依存である。

さらに追加すると、Samba 2.2系列において、coding system = CAP と設定したのと同じ事を行うvfs capモジュールを使うことによって、 シフトJIS系列をunix charsetパラメーターの値として 使うことを考慮することが出来る。

unix charsetをどこに設定するかは難しい質問である。 以下は特定の値を使う場合の詳細、利点、欠点の一覧である。

シフトJIS系列

シフトJIS系列は日本語のWindows上で標準として使われている Shift_JISと同等なロケールを意味する。 Shift_JISの場合は、たとえば、もしも 日本語のファイル名に0x8ba4 と 0x974c(4バイトの日本語文字列で、 share(訳注:共有)と .txtが含まれていてSamba上にWindowsから書き込み された場合、UNIX上のファイル名は 0x8ba4, 0x974c, .txt(8バイトのバイナリ文字列) となり、これはWindowsのものと同じである。

シフトJIS系列が、いくつかの商用ベースのUNIX、たとえば hp-uxとAIXで、日本語のロケールで使われている(しかし、 EUC-JPロケール系列を使うことも可能である)。それらのプラット フォーム上でシフトJISを使うと、Windowsから作成された 日本語のファイル名はUNIX上でも参照できる。

もしも、使用しているUNIXがすでにシフトJISで動いていて、Windowsから 書かれる日本語ファイル名を使う事が必要なユーザーには、シフトJIS系列 は最適の選択である。しかし、不正なファイル名が表示されるか、 非ASCIIファイル名を扱えないコマンドがファイル名を処理するときに アボートするかもしれない。そして、ファイル名中に、注意して 扱わなければならない\ (0x5c)があるときは特に である。UNIX上でWindowsから書かれたファイル名をさわらないのが 最も安全である。

ほとんどの日本語化されたフリーソフトウェアは実際EUC-JPのみで 動作する。日本語化されたフリーソフトウエアがシフトJISで動くかを 検証するのはよい習慣である。

EUC-JP系列

EUC-JP系列は、日本でのUNIX(EUCには日本語以外の言語、たとえば EUC-KRの仕様も含む)で広く使われているEUC-JPという業界標準と同等の ロケールを意味する。EUC-JP系列の場合、例えば、もしも、日本語の ファイル名に0x8ba4と0x974cと.txtを含むものが、 Samba上でWindowsから書かれた場合、UNIX上のファイル名は、 0xb6a6, 0xcdad,.txtとなる(8バイトのバイナリ文字列)。

EUC-JPは通常オープンソースのUNIX、Linuxと振りと商用ベースのUNIX、 Solaris、IRIXとTru64 UNIXで日本語ロケールとして使われている (しかし、SolarisではシフトJISとUTF-8を使うことも出来、Tru64 UNIX ではシフトJISも使うことが出来る)。EUC-JP系列を使うためには、 Windowsから作成された日本語ファイル名の大半は、UNIX上でも参照 できる。また、ほとんどの日本語化されたフリーソフトウェアも ほとんどがEUC-JPのみで動作する。

UNIX上で日本語のファイル名を使うときにはEUC-JP系列を選択する 事を推奨する。

\ (0x5c)のように注意深く扱わなければならない文字が 無いにもかかわらず、不正なファイル名が表示されることもあり、 非ASCIIファイル名を扱えないいくつかのコマンドはファイル名の 処理中にアボートするかもしれない。

さらに、もしも、異なる、インストールされたlibiconvを使ってSambaを 構築した場合、eucJP-msロケールがlibiconv中に含まれ、OSに 含まれているEUC-JP系列とは非互換かもしれない。この場合、 ファイル名に非互換の文字を使うことを防止する必要があるかもしれない。

UTF-8

UTF-8は、ユニコードコンソーシアムによって定義された国際標準である UTF-8と同じロケールであることを意味する。UTF-8中では、 文字は1から3バイトで記述される。日本語 では、ほとんどの文字は3バイトとなる。WindowsのシフトJISでは、 日本語を表現する文字が、1か2バイトなので、UTF-8の文字列長は、 オリジナルのシフトJISの文字列の1.5倍である。UTF-8の場合、 たとえばSamba上に、Windowsから書かれるファイル名が、 0x8ba4と0x974cと.txtの場合、UNIX上のファイル名は、 0xe585, 0xb1e6, 0x9c89, .txt(10バイトのバイナリ 文字列)となる。

iconv()が有効でないシステムか、iconv()のロケールがWindowsと 非互換のものの場合、UTF-8は唯一の有効なロケールである。

日本においてはUTF-8を既定値のロケールとしているシステムはない。

何らかの不正なファイル名が表示されるかもしれず、非ASCII ファイル名を扱えないコマンドがあるかもしれない。特に、 ファイル名に注意深く扱わなければならない \ (0x5c)をファイル名に持つ場合は、UNIX上で、 Windowsから書かれたファイル名に触れない方が無難である。

さらに追加すると、Sambaに直接関係してはいないが、 一般的にUNIX上で使われているiconv()機能と、WindowsやJavaの ような他のプラットフォーム上で使われている機能との間では、 微妙な違いがあり、そのためシフトJISとユニコードのUTF-8との 間での変換は注意深くかつ、プロセスで関連する制限の認識を して行わなければならないという点で関連性がある。

Mac OS Xはそのファイル名のエンコード方式としてUTF-8を使用しているが、 それはSambaが扱えない拡張されたUTF-8仕様を使っているので、Mac OS X では、UTF-8ロケールは無効である。

Shift_JIS系列 + vfs_cap (CAPエンコーディング)

CAPエンコーディングは、Macintosh用のファイルサーバーソフトウェア であるCAPとNetAtalkで使われる仕様である。CAPエンコーディングの 場合、たとえば、もしもSamba上に、Windowsから書かれる日本語の ファイル名に、0x8ba4と0x974cと.txtが含まれている 場合、UNIX上のファイル名は:8b:a4:97L.txt (14バイトのASCII文字列)となる。

CAPエンコーディングでは、ASCII文字として表現できないもの (0x80以上)は、:xx形式でエンコードされる。 ファイル名中に\(0x5c)を含むものは注意深く扱う 必要があるが、非ASCIIファイル名を扱えないシステム中でも、 ファイル名が不正になることはない。

CAPエンコーディングのとても大きな利点は、CAPあるいはNetAtalkでの エンコーディングと互換があるということである。これらは、それぞれ Columbia Appletalk ProtocolとNetAtalkオープンソースソフトウェア プロジェクトである。これらのソフトウェアアプリケーションが、 CAPエンコーディングでUNIX上にファイル名を書き込むので、もしも、 SambaとNetAtalkの両方でディレクトリが共有される場合、非ASCII ファイル名を使わないようにCAPを使って、ファイル名が不正になる ことを防ぐ必要がある。

しかし、最近、NetAtalkはファイル名をEUC-JP(すなわち、日本の オリジナルなVine Linux)でファイル名を書き込むように、いくつかの システムではパッチが当てられた。この場合、CAPエンコーディングの 代わりに、EUC-JP系列を選ばなければならない。

vfs_cap それ自身は、非ASCII文字を扱えないシステムか、NetAtalkと ファイルを共有するシステムのための、非シフトJIS系列のロケールの ために有効である。

Samba-3でCAPエンコーディングを使うためには、unix charset パラメーターと、 the VFS CAP smb.conf file のようなVFSを使うべきである。 To use CAP encoding on Samba-3, you should use the unix charset parameter and VFS as in VFS CAPを使うsmb.confファイル

Example 30.1. VFS CAP

[global]
# the locale name "CP932" may be different
dos charset = CP932
unix charset = CP932
[cap-share]
vfs option = cap

もしも、GNU libiconvをunix charsetに使うならば、CP932を設定 である。この設定を使う場合、cap-share共有中の ファイル名はCAPエンコーディングで書かれる。

個別の実装

個別の実装に関する追加情報は以下の通り:

GNU libiconv

日本語を正しく取り扱うために、libiconv-1.8に libiconv-1.8-cp932-patch.diff.gz というパッチを適用すべきである。

パッチを当てたlibiconv-1.8を使うことで、以下の設定が有効になる:

dos charset = CP932
unix charset = CP932 / eucJP-ms / UTF-8
		|       |
		|       +-- EUC-JP系列
		+-- Shift_JIS系列
display charset = CP932

他の日本語ロケール(たとえば、Shift_JISとEUC-JP)は、Windowsとの 互換性が欠如しているため、使うべきではない。

GNU glibc

日本語を正しく取り扱うために、glibc-2.2.5/2.3.1/2.3.2に patch のパッチを適用すべきであり、そうでない場合は、パッチがマージ された、glibc-2.3.3以降を使うべきである。

上記のglibcを使うことで、以下の設定が有効になる:

dos charset = CP932
unix charset = CP932 / eucJP-ms / UTF-8
display charset = CP932

他の日本語ロケール(たとえば、Shift_JISとEUC-JP)は、Windowsとの 互換性が欠如しているため、使うべきではない。

Samba-2.2系列からの移行

Samba 2.2系列以前では、coding systemパラメーターが使われていた。Samba 2.xの 既定値のcodepageは code page 850であった。Samba-3系列では、これは unix charsetに置き換えられた。 Samba-2.2とSamba-3中の日本語文字セット には、Samba-2.2系列からSamba-3系列へ移行するときのマッピングテーブルを示している。

Table 30.1. Samba-2.2とSamba-3中の日本語文字セット

Samba-2.2 Coding SystemSamba-3 unix charset
SJISShift_JIS系列
EUCEUC-JP系列
EUC3[a]EUC-JP系列
CAPShift_JIS系列 + VFS
HEX現状では存在しない
UTF8UTF-8
UTF8-Mac[b]現状では存在しない
その他なし

[a] Samba日本語版のみに存在

[b] Samba日本語版のみに存在


よくあるエラー

CP850.so が見つからない

SambaがCP850.soファイルがないというエラーを出す。

CP850はdos charsetの既定値である。 dos charsetは使用しているDOSクライアントにょって 使われるコードページに変換するのに使われる。もしも、DOSクライアントが ないのであれば、このメッセージを無視しても安全である。

CP850は使用しているローカルなiconvの実装によってサポートされている。 必要とするすべてのパッケージがインストールされているかを確認すること。 もしもソースからSambaをコンパイルした場合、configureにおいてiconvを 見つけたかを確認すること。これは、configureが 実行された的に生成されるconfig.logファイルを チェックすることで行える。

Chapter 31. バックアップテクニック

John H. Terpstra

Samba Team

特徴と利点

Samba プロジェクトは 10 才を超えている。 Samba の歴史の初期のころ、 UNIX の管理者はその重要な実装者であった。 UNIX 管理者は UNIX システムツール を使って UNIX システムファイルをバックアップしている。 過去 4 年間にわたって増加している Microsoft ネットワーク管理者は、 Samba に 興味を持っている。 このことは、 Samba メーリングリスト上のバックアップについての質問に反映され ている。

バックアップ手段についての議論

Microsoft Windows トレーニングコースで議論されている間、 親 UNIX 派の代表一人が Windows NT4 が UNIX に比べ限定されていることを 指摘してクラスを驚かせた。 彼は UNIX をメカノセット (訳注:組立玩具。穴が空いた様々な形をした板を、 ボルトとナットで組み合わせて様々な形を作る) に例えた。シンプル、効率的、 で、組み合わせれば、望まれるいかなる成果への到達性がある、無限の道具 である。

Windows ネットワーク擁護者の一人が反論した。 もしメカノセットを望むなら購入しただろう。 しかし、複雑な単独のツールが、彼女のような人たちによってより好まれる。 求められる以上のことを行うが、明らかな用途と意図によってなされるためだ。

ここにある情報は、あるがままでかつ適合性や適切さの推奨をしているものではないこと に注意すること。ネットワーク管理者は、どんなバックアップソリューションを構築す る前にも、無償か商用のソフトウェアのいずれも相当な注意による調査を実行することが 奨励される。

あなたが参照したいと思うだろう有用な Web サイトを最近偶然見つけた。 場所は www.allmerchants.comである。

以下の3つのフリーソフトウェアプロジェクトもまた考えてみる価値があるだろう。

BackupPC

BackupPC バージョン 2.0.0 は SourceForge で リリースされている。新しい機能は rsync/rsyncd のサポートと CGI インタフェースの国際 化 (英語、フランス語、スペイン語とドイツ語を含む) を含む。

BackupPC は Linux 、 UNIX と Windows PC とラップトップからサーバーまで をバックアップするための Perl ベースのハイパフォーマンスパッケージで ある。 BackupPC は高度な設定が可能でインストールと保守が簡単である。 クライアントデータを引き出すために (smbclient を通して) SMB 、 tar over rsh/ssh 、または rsync/rsyncd が使用される。

ディスクと RAID システムのコストの減少によって、サーバーのローカルディスク やネットワークストレージに多数のマシンのバックアップを行うことが実用的、 効果的になった。 BackupPC はこれを行う。

重要な特徴は、同一ファイルのプーリング (サーバーのディスクスペースの多大 なる倹約) 、圧縮、そしてバックアップのブラウズとリストアができ る包括的な CGI インタフェースである。

BackupPC は GNU GPL ライセンスで配布されるフリーソフトウェアである。 BackupPC サーバーが Linux/UNIX/freenix で動作する。またクライアントは Linux 、 UNIX 、 Windows 9x/Me/200x/XP と Mac OSX でテストされた。

Rsync

rsync は、ファイルやディレクトリツリーを効率的にコ ピーする柔軟なプログラムである。

rsync は、どのファイルをコピーするのか、どのよ うに転送するかを設定するための多数のオプションがある。 rsync は ftp, http, scp 、または rcp の 代替として使われるかもしれない。

rsync リモートアップデートプロトコルによって、 rsync は 2 つのファイル の差分のみをネットワークを通して転送することができる。 rsync パッケージに同梱されているテクニカルレポートに説明されている効 率的なチェックサム検索アルゴリズムを利用している。

rsync のその他の特徴

  • リンク、デバイスファイル、所有者、グループ、パーミッション のコピーをサポート。

  • GNU tar に似た exclude と exclude-from オプション。

  • CVS がするように同じファイルを無視する CVS exclude モード。

  • 透過的なリモートシェルの利用。 rsh と ssh を含む。

  • root 権限を要求しない。

  • 待ち時間による損失を最小化するためにファイル転送のパイプライン化。

  • 匿名または認証された rsync サーバーのサポート (ミラーリング に理想的)。

Amanda

Amanda (the Advanced Maryland Automatic Network Disk Archiver) は、 複数のホストを単一の大きな容量のテープドライブへバックアップするための 単一のマスターバックアップサーバーを LAN 管理者がセットアップできる バックアップシステムである。 Amanda はシステム付属の dump と GNU tar を両方または片方を使い、様々な バージョンの UNIX が稼働する多数のワークステーションをバックアップする ことができる。最新のバージョンでは Samba を使って Microsoft Windows ホ ストをバックアップすることも可能である。

Amanda に関するさらなる情報は、 www.amanda.org/ サイト を参照すること。

BOBS: Browseable Online Backup System

Browseable Online Backup System (BOBS) は一揃いのオンラインバックアッ プシステムである。 大きなディスクをバックアップを格納するために利用する。 Web ブラウザーを 利用してファイルをブラウズすることができる。 AppleDouble とアイコンファイルのような特殊なファイルを取り扱うことができる。

BOBS のホームページは bobs.sourceforge.net である。

Chapter 32. 高可用性

John H. Terpstra

Samba Team

Jeremy Allison

Samba Team

機能と利便性

ネットワーク管理者は、しばしばファイルと印刷サービスの可用性について関心を持っている。 ネットワークユーザーは、きわめて重要な、責任ある仕事を遂行するのに依存するサービスに 対して、厳しい態度をとりがちである。

コンピュータルームにある以下の標語が、スタッフに自らの責任を思い起こさせるのであった。 それは以下のようなものであった:

すべての人間は過ちを犯すものである。大小を問わず、我々は絶えず過ちを犯している。 機会も同様に故障するものである。コンピュータは人によって管理される機械であり、 故障の結果は悲惨なものとなりうる。管理者の責任は、故障に対処し、故障を予測し、 人知の及ぶ限り、かつ経済的に合理的な範囲でその可能性を抹消することに他ならない。 あなたの行動は、問題の一部となるか、それとも解決の一部となるか。

もしも、計画的、生産的な方法で障害に対処するのであれば、まず最初に問題を理解する 必要がある。それがこの章の目的である。

以下の議論には障害に対抗するためにネットワーク基盤をどのように展開すべきかについての ポイントとなる情報も含まれている。ただし、ここでの目的は、高可用性に関する長大な論文を 発表することではない。そのため、高可用性を提供するソリューションの具体的な実例は提示 していない。Samba を含む CIFS/SMB 技術を展開する際に適用するための、高可用性に関する 最新の知識とノウハウの紹介を主眼に置いた詳細なドキュメントの作成に誰か が挑戦してくれることを期待して、ここでの記述は概論に留める判断を行っている。

技術的な議論

以下の要約は、2003年4月に、ドイツのゲッティンンゲンで行われた、SambaXP 2003 カンファレンスで、Jeremy Allisonによって行われた発表の一部である。 素材となる情報は、幾つか追加されているが、それらを以下の構成に まとめあげたのは、Jeremy ならではである。

最終目的

すべてのクラスターリング技術は以下の1つあるいはそれ以上を達成することを目的としている:

  • コンピュータの能力を最大限使えること。

  • より高速なプロトコル実行を行うこと。

  • 無停止サービスを提供すること。

  • 単一障害点を避けること。

  • 資源を最も効果的に使うこと。

クラスター化されたファイルサーバーは理想的に以下の属性を有している:

  • すべてのクライアントはどのサーバーにも透過的に接続できる。

  • サーバーが故障するとクライアントは透過的に他のサーバーに再接続できる。

  • すべてのサーバーは、同じファイル群を提供する。

  • すべてのファイルの変更は、すべてのサーバーで直接行われるように見える。

    • 分散ファイルシステムが必要。

  • より多くのサーバーやディスクを追加することで、無限に拡張できる。

これがなぜ難しいか?

簡単に言うと、問題は状態(state)にある。

  • すべてのTCP/IP接続はステート情報に依存する。

    TCP接続はパケットシーケンス番号を持っている。このシーケンス 番号は、シームレスなTCPフェールオーバーを引き起こすために、 クラスター中で、すべてのマシン上で動的に更新される必要がある。

  • CIFS/SMB(Windowsネットワークプロトコル)はTCP接続を使用している。

    これは、基本的な設計の見地から、フェイルオーバーは真剣に考慮 されていない事を意味する。

    • すべての現在のSMBクラスターはフェールオーバーソリューション である。これらは再接続するクライアントに 頼っている。これは、サーバーのフェールオーバーを提供するが、 クライアントはサーバーの故障のために情報を失う可能性がある。

  • サーバーはクライアント接続に関するステート情報を保存する。

    • CIFS/SMBには多くのステートがある。

    • すべてのファイルのオープンは、共有モードを チェックするために他のオープンしているファイルと比較する。

最先端の状況

1つの名前と1つのIPアドレスを持つ単一のサーバーのように、ファイルサーバーの クラスターを見せるためにすることは可能で、クライアントから受信した TCPデータストリームはフロントエンドの仮想サーバーによって処理される必要が ある。このサーバーはSMBプロトコルレイヤレベルで、入力したパケットを分割し、 次に、クラスター中の異なったサーバーにSMBパケットを中継する。

印刷とユーザー検索要求を扱うためには、すべてのIPC$接続とRPC呼び出しを1台の サーバーに振り分けるしかない。RPC印刷ハンドルは、異なったIPC$ セッションで共有される。これをクラスターを構成するサーバー間で 分割するのは難しい!

概念的に、他のすべてのサーバーはファイルサービスのみ提供する。これは 集中させるよりも簡単な問題である。

SMBリクエストの分割

SMBリクエストを分割する事は、SMBステート情報を知っていることが要求され、そのすべては フロントエンドの仮想サーバーによって保持されねばならない。 これは解決するのには複雑で難しい問題である。

Windows XPとその後継は、その意味を変更し、そのため、ステート情報 (vuid,tid,fid)は操作が成功するために一致しなければならない。これは、 以前よりも物事を単純にし、前へ進むためのよい一歩である。

SMBリクエストは、それに対応するサーバーにvuidによって送られる。 このソリューションを作り出すコードは現在存在しない。この問題は、 Samba中で、Windows 2000ターミナルサーバーからの複数のリクエストからの リクエストを正しく処理する問題と、概念的に似ている。

直接クライアントにサーバープールを提示することで開始するという 1つの可能性がある。これは、分割ステップを省略できる。

分散ファイルシステムの試み

UNIXとLinux用に、たくさんの分散ファイルシステムがある。

SMB文法を認識することを、ずっと心にとめている間は、我々のクラスターの バックエンドに多くが適用できる(共有モード、ロックとoplock問題は特に)。 一般的な自由に使える分散ファイルシステムには以下がある: Many could be adopted to backend our cluster, so long as awareness of SMB semantics is kept in mind (share modes, locking, and oplock issues in particular). Common free distributed file systems include:

  • NFS

  • AFS

  • OpenGFS

  • Lustre

サーバープール(クラスター)は、もしもすべてのSMB文法がそのプール内で実行出来るならば、 任意の分散ファイルシステムを使える。

分散ファイルシステム上の限定的な制約

クラスター化されたサーバーが純粋なSMBサービスを提供するとき、oplockの 処理は、バックエンドのファイルシステムプールに渡す必要性はなく、 サーバープール内で完結してもよい。

他方、サーバープールがNFSや他のファイルサービスをも提供する場合、 SMBサービスと相互運用できるように、oplockを認識する実装は基本である。 これは、現在有意義な挑戦である。これの相互運用性の提供に失敗すると、 Microsoft Windows クライアントのユーザーによってはっきりと気がつく 明確な性能の低下をもたらす。

最後に、すべてのステート情報は、サーバープール間で共有されるべきである。

サーバープールの通信

ほとんどのバックエンドファイルシステムは、POSIXファイルシステムを サポートしている。これは、SMB文法をファイルシステム中で使うことを 困難にしている。POSIXのロック機構は、SMBのロック機構とは異なる 属性と文法である。

サーバープール中のすべてのsmbdプロセスはごく短時間に 通信しなければならない。このため、Sambaが使う現在の tdbファイル構造はネットワーク間で使うのには 適していない。クラスター化されたsmbdは何らかの、 他のものを使う必要がある。

サーバープール通信の要求

サーバープール内の高速サーバー間通信は、完全に機能するシステムのために あらかじめ必要な機能である。これを可能にするものは以下のものがある:

  • 商用の共有メモリバス(例:MyrinetまたはSCI [scalable coherent interface])。 これはとても価格が高い。

  • ギガビットイーサネット(現在簡単に使える)。

  • 生のイーサネットフレーミング(TCPとUDPのオーバーヘッドをバイパス)。

これらの機能を有効化する効果の有無を計るパフォーマンス指標はまだ確立していない。

Sambaに対する変更要求

Sambaは、透過的なフィルオーバークラスターが出来るように、高速サーバー間接続システムで 動くように、明確に修正する必要がある。

影響を受けると思われるSamba内の特定の機能は以下の通り:

  • データベースのロック、oplockの通知と共有モードデータベース。

  • 何をもって「障害」とみなすかを定義する必要がある。Sambaは Windowsと同様に動作する。oplockが失敗を通知すると、ファイル オープン要求は許可されるが、これはクラスター環境では潜在的な 危険性がある。サーバー間プールの障害という意味は、どのように 位置づけるべきか、またこうした機能をどのように実装すべきか。

  • これはポイントツーポイントロックマネージャを使って実装すべきか、 あるいは、マルチキャスト手法を使って行うべきだろうか?

簡単なソリューション

フェイルオーバーサーバーにエクスポートされたファイルシステム内で異なった機能を 扱えるようにすることは、分散ロッキングプロトコルを要求する問題をなくす。

もしも、ペアの中で1つのサーバーのみアクティブである場合、高速サーバー間通信の必要性は 無くなる。この場合、新しいものを開発する代わりに、既存の高可用性ソリューションが 使える。これはかなりのコストがかかる単純なソリューションである。 そのコストとは、より複雑なファイル名空間を管理する必要があるということである。 単一のファイルシステムではないため、管理者はすべてのサービスがどこに配置されて いるかを覚えておかなければならない。複雑さは、扱うのが容易ではない。

仮想サーバーは、バックエンドサーバーに要求をリダイレクトする ため、引き続き必要である。バックエンドファイル空間の完全性は管理者の責任である。

高可用性サーバー製品

フェイルオーバーサーバーはリソースのフェイルオーバーを扱うために通信する必要がある。 これは高可用性サービスでは基本である。専用のハートビートを使うことは、 フェイルオーバープロセスで、ある種の自立性を導入する、一般的な技術である。 これは、しばしは専用のリンク(LANまたはシリアル通信)上で行われる。

多くのフェイルオーバーソリューション(Red HatクラスターマネージャとMicrosoft Wolfpack のような)はフェイルオーバー通信のためにファイバチャネルディスクストレージアレイ をSCSIで共有して使える。Sambaに対するRed Hat高可用性ソリューションについての 情報は、 www.redhat.com で得られる。

Linux高可用性プロジェクトは、高可用性Sambaファイルサーバーソリューションを構築 したいならば、考慮するに値するリソースである。 www.linux-ha.org/にある ホームページを見てほしい。

フロントエンドサーバーの複雑性は、すべてのネットワーククライアントに対して、 サービスの継続性を同時に提供する間、バックエンドの障害をうまく扱わなければ ならないという理由で、高可用性に対する挑戦の余地がある。

MS-DFS: 貧者のクラスター

MS-DFSリンクは異なったバックエンドサーバーにクライアントをリダイレクトするのに 使われる。これはMicrosoftによってすでに導入された何かで、ネットワーククライアントに 複雑性を増やしてしまう。MS-DFSは単純な、ファイルレベルでさえ動作する、継続的な ファイルシステム名前空間という幻影を作成する。

とりわけ、管理の複雑さを犠牲にすると、分散システム(仮のクラスター)は既存のSambaの 機能を使うことで作成できる。

結論

  • 透過的なSMBクラスターは作るのが難しい!

  • クライアントフェイルオーバーは現在出来る最も良いものである。

  • 実用的で管理が楽な高可用性透過的クラスターソリューションを可能にする前には、 たくさんの作業が必要である。

  • MS-DFSは単一の透過的クラスターという幻想を作るのことができる。

Chapter 33. 大きなディレクトリの取扱い

Jeremy Allison

Samba Team

John H. Terpstra

Samba Team

March 5, 2005

1ディレクトリあたり10 万またはそれ以上のファイルを 必要とするアプリケーションを、バージョン 3 系の Sambaで利用すること には問題があり、それによって発生するパフォーマンス劣化を経験しているサイトがあ る。 Samba 3.0.12以降ではその解決策を実装している。

要求されている最新のリストだけを読むようにディレクトリの取扱いを修正した ことが鍵だった。 これとは違い、古い (Samba 3.0.11 までの) 振る舞いでは、 事前にディレクトリをすべてメモリへ読み込んでから名前を小出しにしていた。 通常では、これは とても奇妙な削除動作を持つ OS/2 アプリケーションを誤動作させる だろう。しかし、 Samba 4 (ありがとう Tridge) から流用したロジックにより、 3.0.12 の最新のコードでは、これを正しく取り扱う。

ディレクトリあたりに多数のファイルを必要とするアプリケーションを、パフォーマン スへ著しい影響を与えないように、セットアップするために以下の手順を実施する。

最初に、ディレクトリ中のファイルをすべて大文字または小文字 好きな方 (すでにすべてのファイルが大文字になっていたため大文字を私は選んだ) のどちらか のみに正規化する。 そして、このアプリケーションのために新しくおあつらえ向きの 共有を以下のように作成する。

[bigshare]
path = /data/manyfilesdir
read only = no
case sensitive = True
default case = upper
preserve case = no
short preserve case = no

もちろん、あなた自身固有のパスと設定を使うこと。そして、ケースオプションはディレク トリのすべてのファイルに適合するように設定すること。 パスは、アプリケーションが必要とする大きなディレクトリを指さなければならない。 そのディレクトリとそれ以下のすべてのディレクトリの下に作られる新し いファイルはすべて smbd によって大文字に強制される。しかし smbd はもはや名前 のために走査する必要がなくなる。大文字で存在しなければまったく存在しないこと がわかるため。

極意は実に case sensitive = True 行にある。 これは、 smbd にその名前の大小文字が混在したバージョンを走査する必要が絶対 にないことを告げる。だから、アプリケーションが FOO と呼ば れるファイルを要求した場合、 stat コールにて見つからなかったら、 smbd は直ちに file not found を返却する。違うケースのバージョンを走査することはない。 その他の xxx case xxx 行は、 smbd によって作成される ファイルが一貫したケースに強制することでこれが機能するようにしている。

smb.conf のこのセクションに付随して path 配下のすべ てのファイルとディレクトリは大文字でなければならないことを忘れないこと。 何故ならこの設定では、 smbd は小文字のファイル名を見つけることができなくなる からである。 このパラメーターは、問題のある振る舞いの (多数のエントリをもつディレクトリを使用 する) アプリケーションにへ提供する共有にのみ設定が許されているので、これらは 共有ごとになされることに注意すること 残りの smbd 共有は、影響を 受ける必要はない。

以上の設定は、大きなディレクトリを処理する際にsmbd をずっと速くさせる。私の テストケースでは 10 万を超えるファイルで smbd は今やとても効率的に処理する。

Chapter 34. 詳細設定のテクニック

John H. Terpstra

Samba Team

June 30, 2005

この本の最初の版のリリース以来、Samba以外の事についてネットワーク管理者の手助けとなる かもしれない設定テクニックのよりよい資料について、繰り返し要求があった。一部の ユーザーは、include = file-nameパラメーターの使い方に 関連する文書を提供した。

2004年の中頃に始まったが、1つのマシン上で複数のSambaサーバーをホスティングする 機能について、関心が高まってきた。1つのサーバー上複数のSambaサーバーの振る舞いを ホスティングする事への興味も増えてきた。

テクニカルレビューワからのフィードバックによりこの章を含める必要が出た。 そのため、今まで十分に言及してこなかった質問への答えををここに記す。さらに、 この章を充実させる、利用者からの追加は歓迎する。ここで提供されているものは、 まったくもって、小さなとっかかりである。

単一のSambaサーバー上で複数のサーバーをホスト出来る方法はいくつもある。複数のサーバー ホスティングは1つのマシン上で複数のドメインをホストする事を可能にする。そのような 各マシンは独立していて、他に影響を与えずに、起動/停止ができる。

時には、各サーバーが固有のセキュリティモードを持つ、複数のサーバーをホスティングする ことが好ましいことがある。例えば、一般的な匿名印刷サーバーのように、単一のUNIX/Linux ホストはドメインメンバーサーバー(DMS)になれる。この場合、ドメインメンバーマシンとドメイン ユーザーはDMSにアクセスでき、さらにゲストユーザーでさえも、一般的な印刷サーバーにアクセス できる。他の、汎用(匿名)サーバーをホスティングするのに便利かもしれないシチュエーションの 例としては、CDROMサーバーのホスティングがある。

いくつかの環境では、固有のリソースを持つ、特定のユーザーかグループのみからアクセス可能な、 分離されたサーバーを持つ必要が規定されている。これは、Sambaが多数の物理的なサーバーを、 1つのSambaサーバーに置き換えられる、単純で、とても効果的な方法の1つである。

実装

複数のサーバーのホスティング

複数のサーバーホスティングの使用は、それぞれ個別の設定ファイルを持っている、複数の分離 されたSambaインスタンスを動かす必要がある。この方法は、各nmbd, smbdwinbindd のインスタンスは、完全に分離されたTDBファイルへの書き込みアクセスが出来なければならない という理由で、とても複雑である。nmbd, smbdwinbinddが使うTDBファイルを分離 させる事は、ホスティングを行う各Sambaを再コンパイルすることで、各Sambaが、固有のTDB ファイルに対する既定値のディレクトリを持つか、nmbd, smbdwinbinddの 各インスタンスが、それらの固有のsmb.conf設定ファイルで起動するようにしなければ ならない、smb.confファイルを設定することで可能となる。

各インスタンスは固有のIPアドレス(独立したIPアドレスはIPエイリアスで行える)で操作される べきである。nmbd, smbdwinbinddの各インスタンスは、その固有IPソケットのみを リッスンすべきである。これはsocket addressパラメーターを使うことに よって、安全に出来る。Sambaサーバーの各インスタンスは固有のSIDも持つべきであり、これは、 サーバーは互いに独立で、分離されていることを意味する。

複数サーバーホスティングのユーザーはそれほど特異ではなく、プロセス管理と起動時それぞれの 場面において、注意深い設定を要求する。注意深く設定しなければならない、smb.conf パラメーターは以下を含む: private dir, pid directory,lock directory, interfaces, bind interfaces only, netbios name, workgroup, socket address

複数のSambaサーバーを作成する事を選択した人は、Sambaソースコードを読解でき、必要に応じて それを変更出来る能力を持つべきである。このモードの配置は、この文書の範囲を超えていると 考えられる。しかし、もしも誰かがより包括的な文書を寄贈してくれるのであれば、喜んでそれを レビューし、もしもそれが適切であれば、この章のこの節を拡張するだろう。そのような文書が 有効になるまで、単一ホスト上での複数Sambaサーバーのホスティングは、Sambaチームによって、 Samba-3ではサポートされないとみなされる。

複数仮想サーバーの性質(Personalities)

Sambaは、固有の設定を持つ、複数の仮想サーバーをホスティングできる能力がある。 これは、すべてのホスティングされる、個別設定に共通なsmb.confファイルの設定で達成 される。各(仮想)サーバーの個別設定は、固有のnetbios aliasで ホスティングされ、おのおのは、固有の異なった[global]セクションを 持つ。各サーバーはサービスとメタサービスのために固有のセクションを持っても良い。

複数の仮想サーバーをホスティングするとき、おのおのには個別設定が出来、おのおのは 異なったワークグループにいる。プライマリサーバーのみ、ドメインメンバーかドメインコントローラーに なれる。個別設定は、動作しているsecurityモードと、使っている netbios aliasesとそれに対して定義された workgroupの組み合わせによって定義される。

この設定スタイルは、NetBIOS名を使うか、NetBIOS名なしのTCPサービスのSMBを使う事が出来る。 もしもNetBIOSモード(最も一般的な方法)で動かす場合、パラメーター smb ports = 139はプライマリのsmb.confファイル中に 指定すべきである。それを間違うと、SambaはTCPポート445で動作することになり、 最も良い場合で問題のある動作、最悪の場合は、プライマリのsmb.confファイルで指定された 機能を得ることができるのみである。TCPポート139のみを使うNetBIOS over TCP/IPの使用は、 %Lマクロの使用が完全に有効になる事を意味する。もしも smb ports = 139が指定されていない場合(既定値では 445 139)か、もしもこのパラメーターの値が 139 445の時は、%Lは無効である。

各サーバーの個別設定で、ポート445を使う(NetBIOSなしのSMBポート)複数のサーバーを ホスティングするのは可能で、この場合、(IPアドレスによって)分離されたサーバーを識別する ために、%iが使える。おのおのは固有のsecurity モードを持つ。仮想サーバーを作成するために、interfacesbind interfaces onlynetbios nameに 追加する必要があるかもしれない。この方法は、TCPポート139のみを使うNetBIOS名を使うよりも より複雑であると考えられる。

スタンドアロンでユーザーモードのセキュリティで動くSambaと置き換え対象の、 読み取り専用Windows 95ファイルサーバーからなる例題環境を考えてみよう。新しいPCでWindows 95 マシンを置き換える代わりに、Sambaサーバー上でホスティングされる読み取り専用匿名ファイル サーバーとしてこのサーバーを追加することが可能である。以下はそれに必要ないくつかのパラメーター である:

Sambaサーバーの名前はELASTICで、そのワークグループ名はROBINSNESTである。 CDROMサーバーの名前はCDSERVERで、そのワークグループ名はARTSDEPT である。出来うる実装は以下の通り:

マスターサーバーに対するsmb.confファイルはElasticのsmb.confファイルである。 このファイルは/etc/samba中に置かれる。nmbdsmbd デーモンのみが 必要である。サーバーを起動すると、Windowsのネットワークコンピュータ中の、ワークグループ ROBINSNEST配下にELASTICが現れる。もしも、このサーバーに アクセスするWindowsクライアントがまたワークグループROBINSNEST中にいて、 より信頼性の高いブラウジングを行わさせるのに、これは便利である。

Example 34.1. Elasticのsmb.confファイル

# Globalパラメーター
[global]
workgroup = ROBINSNEST
netbios name = ELASTIC
netbios aliases = CDSERVER
smb ports = 139
printcap name = cups
disable spoolss = Yes
show add printer wizard = No
printing = cups
include = /etc/samba/smb-%L.conf
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[office]
comment = Data
path = /data
read only = No
[printers]
comment = All Printers
path = /var/spool/samba
create mask = 0600
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = No

CDROMサーバーの設定ファイルはCDROMサーバーのsmb-cdserver.confファイル である。このファイルはsmb-cdserver.confという名前で、 /etc/sambaディレクトリに置かれる。ワークグループ ARTSDEPT中にいるマシンはサーバーを自由にブラウズできる。

Example 34.2. CDROMサーバーのsmb-cdserver.confファイル

# Globalパラメーター
[global]
workgroup = ARTSDEPT
netbios name = CDSERVER
map to guest = Bad User
guest ok = Yes
[carousel]
comment = CDROM Share
path = /export/cddata
read only = Yes
guest ok = Yes

2つのサーバーは異なったりソースを持ち、分離されたワークグループ内にいる。サーバー ELASTICは、そのホストサーバー上に適切なアカウントを持つユーザーから のみアクセスできる。すべてのユーザーは、/export/cddata ディレクトリ中に格納されるCDROMデータにアクセスできる。ファイルシステムのアクセス許可は、 その他ユーザーがディレクトリとその内容に対して読み取り専用アクセスを 設定すべきである。ファイルはrootが所有できる(nobodyアカウント以外の任意のユーザーでも)。

複数の仮想サーバーホスティング

この例では、要求されていることは、MIDEARTHというドメインに対する プライマリドメインコントローラーに対するものである。PDCはMERLIN である。その他のマシンとしてSAURONが必要とされている。各マシンは それぞれ固有の共有のみ持つ。両マシンは同じドメイン/ワークグループに属している。

マスターのsmb.confファイルはマスターのsmb.conf ファイルのグローバルセクション である。各サーバーの共有情報を指定する2つのファイルは、 smb-merlin.confファイルの共有セクションsmb-sauron.confファイルの共有セクションである。3つの ファイルはすべて/etc/sambaディレクトリに置かれる。

Example 34.3. マスターのsmb.conf ファイルのグローバルセクション

# グローバルパラメーター
[global]
workgroup = MIDEARTH
netbios name = MERLIN
netbios aliases = SAURON
passdb backend = tdbsam
smb ports = 139
syslog = 0
printcap name = CUPS
show add printer wizard = No
add user script = /usr/sbin/useradd -m '%u'
delete user script = /usr/sbin/userdel -r '%u'
add group script = /usr/sbin/groupadd '%g'
delete group script = /usr/sbin/groupdel '%g'
add user to group script = /usr/sbin/usermod -G '%g' '%u'
add machine script = /usr/sbin/useradd -s /bin/false -d /var/lib/nobody '%u'
logon script = scripts\login.bat
logon path =
logon drive = X:
domain logons = Yes
preferred master = Yes
wins support = Yes
printing = CUPS
include = /etc/samba/smb-%L.conf

Example 34.4. smb-merlin.confファイルの共有セクション

# グローバルパラメーター
[global]
workgroup = MIDEARTH
netbios name = MERLIN
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[office]
comment = Data
path = /data
read only = No
[netlogon]
comment = NETLOGON
path = /var/lib/samba/netlogon
read only = Yes
browseable = No
[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
use client driver = Yes
browseable = No

Example 34.5. smb-sauron.confファイルの共有セクション

# グローバルパラメーター
[global]
workgroup = MIDEARTH
netbios name = SAURON
[www]
comment = Web Pages
path = /srv/www/htdocs
read only = No

Part IV. マイグレーションとアップグレード

Chapter 35. Sambaのアップデートとアップグレード

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Gerald (Jerry) Carter

Samba Team

August 16, 2007

この章では、3.xシリーズのリリースの間に行われた変更の詳細な記録を提供する。この時点で、 このシリーズはGNU GPLバージョン2でライセンスされる3.0.xとGNU GPLバージョン3でライセンス される Samba 3.2.xシリーズがある。

アップデート要求の要点

Sambaは常時発展しているソフトウェアで、リリース間で明確な違いがある時もある。それらの 変更点のいくつかは、公式のMicrosoftパッチとアップデートによるセキュリティか機能の更新の 結果、Microsoft Windows ネットワーククライアントによって使われるプロトコルの変更の結果に よってもたらされる。特に、Sambaそれ自身の内部操作に影響するものについては、Sambaは そのような変更に追従しなければならない。

使用しているSambaのバージョンに、明確に言及している、以下のどのような節をも参照して ほしい。一般的に、新しいリリースに適用されるすべての変更は、それ以降のリリースにも 適用される。例えば、Samba3.0.23における変更は、3.0.25を含むそのあとすべての新しい リリースに適用される。Samba 3.2.xは3.2.0固有の変更が適用される前に、Samba 3.0.25から オリジナルが分割された。3.0.xシリーズの機能が特に無効にされていないのならば、 3.2.xシリーズの動作は、それ以前のパターンに沿うと推測できる。

Samba-3.0.xからSamba-3.2.0へのアップグレード

Samba-2.xからSamba-3.0.25へのアップグレード

この章では、主に、Samba-3.0.25とSamba-2.2.8a間での違いについて取り扱う。 それは、設定パラメーターが変更された点と、2.2.xから3.0.25への簡単なガイドを 提供する。

お手軽移行ガイド

Samba-3.0.25の既定値の動作は、おおよそSamba-2.2.xと同じであるべきである。smb.conf ファイル中に新しいパラメーターpassdb backendが定義されていない 場合の既定値の動作は、encrypt passwords = Yessmbpasswdデータベースを使う、Samba-2.2.xの既定値の動作と同じに なる。

なぜ、動作がおおよそSamba-2.2.xと同じであるべきであると言うのか? なぜならば、Samba-3.0.25は、結果として異なったプロトコルコードパスを取るかもしれない ネイティブなユニコードをサポートするような、新しいプロトコルを使うことが出来るからである。 そのような環境における新しい動作は、古いものとは正確に同じではない。うれしいことに、 ドメインとマシンSIDはアップグレードにおいて保存される。

もしも、Samba-2.2.xがLDAPを使っていて、LDAPデータベースを更新する時間がないならば、 smb.confファイル中でpassdb backend = ldapsam_compat を指定する。その他の点に関しては、動作は多かれ少なかれ同じであるべきである。 その後、Samba-3互換のLDAPバックエンドに切り替える時間があるとき、pdbedit を使って古いLDAPデータベースを新しいものに移行することは可能である。 The pdbeditコマンドを参照のこと。

Samba-3.xシリーズにおける新しい機能

Samba-3.2.xシリーズにおける新しい機能

Samba-3.0.xにおける新しい機能

新機能のうち代表的なものは以下の通り:

  1. Active Directoryのサポート。このリリースはメンバーサーバーとしてADS realmに参加でき、 LDAP/Kerberosを使ってユーザーの認証が出来る。

  2. ユニコードのサポート。Sambaはネットワーク上でUnicodeを使えるようになり、 マルチバイトとユニコード文字セットを扱うための、よりよい基盤を内部にもつ ようになった。

  3. 新しい認証システム。内部の認証システムはほとんど書き換えられた。変更の多くは 内部的なものであるが、新しい認証システムはとても自由に設定できる。

  4. 新しい、ファイル名の短縮システム。ファイル名短縮システムは完全に書き換えられた。 内部データベースは、恒久的に短縮マップを格納する。

  5. 新しいnetコマンド。新しいnetコマンドが追加された。 Windows中のnetコマンドと幾分似ている。結局、たくさんある他の ユーティリティ(たとえばsmbpasswd)をnet中のサブコマンドで 置き換えることを計画している。

  6. Sambaはネットワーク上でNT形式のstatus32コードで通信できるようになった。 これはかなりエラーハンドリングを改善する。

  7. よりよいWindows 200x/XP印刷サポート。Active Directory中にプリンター属性を 公開することを含む。

  8. 新しい、passdbバックエンドと文字セット用の、ローダブルRPCモジュール。

  9. よりパフォーマンスを改善するために、既定値で、winbinddデーモンの二重化をサポート。

  10. Windows NT 4.0ドメインからSambaドメインへ、管理ユーザー、グループとドメインSIDの 移行サポート。

  11. Windows NT 4.0ドメインコントローラーとの信頼関係の確立のサポート。

  12. SIDからUID/GIDマッピングをLDAPディレクトリに格納する事による、 分散Winbindアーキテクチャの新規サポート。

  13. Samba文書構造の大規模な更新。

  14. 既定値のWindows 2003セキュリティ設定との互換を取るために、サーバーと クライアントにおけるSMB署名の完全なサポート。

さらに多くの改良がある!

設定パラメーターの変更

この節には、Samba-2.2.xシリーズからSamba-3.0.25を含むまでのsmb.confの変更の 簡単な一覧がある。

新規、あるいは変更されたパラメーターについての完全な説明は、smb.conf(5)のマニュアル ページを参照のこと。

Sambaのアップデートあるいはアップグレードをするときはいつでも、Sambaの配布セット の一部である、WHATSNEW.txtというファイルを読むことを強く推奨する。 このファイルは、Sambaのwebサイトの、 右側のカラム、Current Stable Releaseの下で、Release Notesを クリックして入手してもよい。

削除されたパラメーター

アルファベット順で、以下はSamba-2.2.xから3.0.35で削除されたパラメーターの一覧である。

  • admin log

  • alternate permissions

  • character set

  • client codepage

  • code page directory

  • coding system

  • domain admin group

  • domain guest group

  • enable rid algorithm

  • enable svcctl

  • force unknown acl user

  • hosts equiv

  • ldap filter

  • min password length

  • nt smb support

  • post script

  • printer admin

  • printer driver

  • printer driver file

  • printer driver location

  • read size

  • source environment

  • status

  • strip dot

  • total print jobs

  • unicode

  • use rhosts

  • valid chars

  • vfs options

  • winbind enable local accounts

  • winbind max idle children

  • wins partners

新しいパラメーター

以下の新しいパラメーターは、Samba 3.0.25までにリリースされたものである(機能毎にグルーピング:)

リモート管理

  • abort shutdown script

  • shutdown script

ユーザーとグループアカウント管理

  • add group script

  • add machine script

  • add user to group script

  • algorithmic rid base

  • delete group script

  • delete user from group script

  • passdb backend

  • rename user script

  • set primary group script

  • username map script

認証

  • auth methods

  • ldap password sync

  • passdb expand explicit

  • realm

プロトコルオプション

  • add port command

  • afs token lifetime

  • client lanman auth

  • client NTLMv2 auth

  • client schannel

  • client signing

  • client use spnego

  • defer sharing violations

  • disable netbios

  • dmapi support

  • enable privileges

  • use kerberos keytab

  • log nt token command

  • ntlm auth

  • paranoid server security

  • sendfile

  • server schannel

  • server signing

  • smb ports

  • svcctl list

  • use spnego

ファイルサービス

  • allocation roundup size

  • acl check permissions

  • acl group control

  • acl map full control

  • aio read size

  • aio write size

  • dfree cache time

  • dfree command

  • ea support

  • enable asu support

  • fam change notify

  • force unknown acl user

  • get quota command

  • hide special files

  • hide unwriteable files

  • inherit owner

  • hostname lookups

  • kernel change notify

  • mangle prefix

  • map acl inherit

  • map read only

  • max stat cache size

  • msdfs proxy

  • open files database hash size

  • set quota command

  • store dos attributes

  • use sendfile

  • usershare allow guests

  • usershare max shares

  • usershare owner only

  • usershare path

  • usershare prefix allow list

  • usershare prefix deny list

  • usershare template share

  • vfs objects

印刷

  • cups options

  • cups server

  • force printername

  • iprint server

  • max reported print jobs

  • printcap cache time

ユニコードと文字セット

  • display charset

  • dos charset

  • UNIX charset

SIDからUID/GIDへのマッピング

  • idmap backend

  • idmap gid

  • idmap uid

  • username map script

  • winbind nss info

  • winbind offline logon

  • winbind refresh tickets

  • winbind trusted domains only

  • template primary group

LDAP

  • ldap delete dn

  • ldap group suffix

  • ldap idmap suffix

  • ldap machine suffix

  • ldap passwd sync

  • ldap replication sleep

  • ldap timeout

  • ldap user suffix

一般的な設定

  • eventlog list

  • preload modules

  • reset on zero vc

  • privatedir

変更されたパラメーター(動作が変わったもの)

  • acl group control (新しい既定値は No, 廃止されるパラメーター)

  • change notify timeout (スコープが変更)

  • dos filemode (既定値で無効に)

  • dos filetimes (既定値で有効に)

  • enable asu support (既定値で無効に)

  • enable privileges (既定値で有効に)

  • encrypt passwords (既定値で有効に)

  • host msdfs (既定値で有効に)

  • mangling method (既定値でhash2を設定)

  • map to guest

  • only user (廃止)

  • passwd chat

  • passwd program

  • password server

  • restrict anonymous (整数値)

  • security (新しくadsが追加)

  • strict locking (既定値でautoに)

  • winbind cache time (5分に増加)

  • winbind enum groups (既定値で無効に)

  • winbind enum users (既定値で無効に)

  • winbind nested groups (既定値で有効に)

  • winbind uid (idmap uidのために廃止に)

  • winbind gid (idmap gidのために廃止に)

  • winbindd nss info

  • write cache (廃止)

新しい機能

Samba-2.2.xシリーズからの主要な動作の変更点は、この節に記述してある。現在の Sambaリリースのサポート期間中に行われた変更に関連する詳細情報を得るためには、 各Sambaリリースに同梱されるWHATSNEW.txtを参照してほしい。

TDBデータファイル

インストール、第一章, 第一章に、Samba-3データファイルに関連する、 その配置とサーバー移行、アップデートとアップグレードにおいて保持しなければ ならない情報があるので、参照してほしい。

Samba-3にアップグレードする前に、存在している${lock directory}/*tdbをバックアップ する事を忘れないでほしい。もしも必要ならば、Sambaはオープンされているように データベースをアップグレードする。Samba-3から2.2へのダウングレードか、 最新版のSamba-3より前のバージョンへの変更は、サポートされない手順である。

古いSamba-2.2.xのtdbファイルは次のテーブル で説明されている。

Table 35.1. Samba-2.2.xのTDBファイルの説明

名前説明バックアップ必要?
account_policyユーザーポリシーの設定yes
brlockバイトレンジファイルロック情報no
connections

クライアント接続情報

no
locking一時ファイルロックデータno
messages

smbdによって生成されたメッセージの一時的な記憶場所

no
ntdrivers

プリンター毎のドライバー情報を格納

yes
ntforms

プリンター毎のフォーム情報を格納

yes
ntprinters

プリンター毎のdevmode設定情報を格納

yes
printing/*.tdb

印刷サービス毎に作成されたlpqコマンドからのキャッシュされた出力

no
registry

読み取り専用のSambaレジストリスケルトンで、winreg RPC経由で種々の データベーステーブルをエクスポートする機能を提供する。

no
sessionid

その他のセッション情報のための一時的なキャッシュ。

no
share_info共有のACL設定。yes
unexpected

どのプロセスもリッスンしていないパケットの受信用。

no
winbindd_cache

NT4かADSドメインから受信した識別情報のキャッシュ。

yes
winbindd_idmap

SIDからUNIXのUID/GIDへの新しいIDマップテーブル。

yes

動作の変更点

以下の問題はSamba-2.2とSamba-3の間で、特定のインストール状態におけるSambaの動作の 変更点として知られている。

  1. 操作がWindowsドメインのメンバーの場合、Samba-2.2は、もしもUIDがgetpwnam() 呼び出し経由で得られなかった場合、guest accountに、リモート DCによって認証された任意のユーザーをマップする。Samba-3は、 NT_STATUS_LOGON_FAILUREというエラーメッセージで接続を 拒否する。Samba-2.2の動作を再度確立するための現時点での回避策はない。

  2. Samba-2.2で制御されたドメインにマシンを追加するとき、 add user scriptはマシン信頼アカウントのUNIX識別子を 作成するのに使われる。Samba-3では新しい add machine scriptという、この目的のために指定しなければ ならないスクリプトを導入している。Samba-3は、 add machine scriptがない場合に、 add user scriptを使うように切り替える事はしない。

passdbバックエンドと認証

Samba-3に移動するときにSamba管理者が知っておくべきいくつかの新しい変更が ある。

  1. 暗号化されたパスワードは、Windowsクライアントをそのまま使える事との 相互運用性を向上させるために、既定値で有効になった。これは、(a) Sambaアカウントは各ユーザー毎に作成する必要があるか、(b) encrypt passwords = noを明示的に smb.conf中で定義する 必要があるということである。

  2. ネイティブなWindows Kerberos 5とLDAPプロトコルを使う、Active Directory ドメインとの統合のための、新しいsecurity = ads オプションの包含。

Samba-3は、認証方法を複数設定できる機能(auth methods) と、アカウント格納バックエンドを複数設定できる機能(訳注:現在は無効) (passdb backend)がある。詳細は、smb.confマニュアル ページとアカウント情報データベースを参照して ほしい。両方のパラメーターが妥当な既定値を仮定している間、Sambaの動作を実際に どの値が正しくさせているかを理解する必要があることはありえる。

smbpasswdの特定の機能は、新しいsmbpasswd ユーティリティ、netツールと新しいpdbedit ユーティリティの間で分割された。詳細は、それぞれのマニュアルページを参照のこと。

LDAP

この節では、Samba/LDAP統合に影響する新しい機能の概要を説明する。

新しいスキーマ

新しいオブジェクトクラス(sambaSamAccount)が古いsambaAccountを置き換える ために導入された。この変更は、他のベンダからの属性を破壊するのを防ぐための、 属性の変更を支援する。LDIFファイルを新しいスキーマに変更するための変換 スクリプトがexamples/LDAP/convertSambaAccountにある。

例:

		$ ldapsearch .... -LLL -b "ou=people,dc=..." > old.ldif
		$ convertSambaAccount --sid <DOM SID> --input old.ldif --output new.ldif
		

<DOM SID>は以下を、Samba PDC上で、rootで動かすことで入手できる。

$ net getlocalsid <DOMAINNAME>

Samba-2.x下では、ドメインSIDは以下を実行することで得られる:

$ smbpasswd -S <DOMAINNAME>

古いsambaAccountスキーマは、 ldapsam_compatpassdb バックエンドを指定することで 引き続き使っても良い。しかし、sambaAccountと関連する属性はスキーマ ファイルの歴史的セクションに移動済みで、もしも必要な場合、使う前に コメントアウトしなければならない。sambaAccount に対するSamba-2.2オブジェクトクラスの定義は、Samba-3の samba.schemaファイル中では変更されていない。

他の新しいオブジェクトクラスとそれが使うものは以下の通り:

  • sambaDomain 必要に応じて ユーザーとグループのRIDを割り当てるために使われるドメイン情報。 もしもidmap UID/GIDの範囲が設定され、ldapsam passdbバックエンドが選択された場合、属性は ldap suffixディレクトリエントリ中に、 自動的に追加される。

  • sambaGroupMapping は、posixGroupとWindowsのグループ/SID との間で関連づけを行うためのオブジェクト。これらのエントリは ldap group suffix中に格納され、 net groupmapコマンドによって管理される。

  • sambaUNIXIdPool ldap idmap suffixエントリ中に自動的に作成され、 次に有効なidmap UIDidmap GID を格納している。

  • sambaIdmapEntry SIDとUNIXのUID/GID間でのマッピングを格納するオブジェクト。 これらのオブジェクトは必要に応じてidmap ldapモジュールにより 作成される。

検索のための新しいサフィックス

以下の新しいsmb.confパラメーターは、 passdb backend = ldapsam://...が指定された時に 特定のLDAPクエリを指示するのを支援するために追加された。

  • ldap suffix ユーザーとコンピュータアカウントを検索するのに使用。

  • ldap user suffix ユーザーアカウントを格納するのに使用。

  • ldap machine suffix マシン信頼アカウントを格納するのに使用。

  • ldap group suffix posixGroup/sambaGroupMappingエントリの位置。

  • ldap idmap suffix sambaIdmapEntryオブジェクトの位置。

もしも、ldap suffixが定義されていた場合、これは残りの subsuffixパラメーターに追加される。この場合、smb.conf中のサフィックスの 記述順序は重要である。常時、他のものよりも前に、 ldap suffixを記述すること。

Sambaのsmb.conf解析の制限により、引用符でドメイン名を囲ってはいけない。

IdMap LDAPサポート

Samba-3はidmapサブシステムにもLDAPバックエンドをサポートしている。以下の オプションは、Sambaにidmapテーブルを、ディレクトリサーバー onteroseの ou=Idmap,dc=quenya,dc=org部分に格納する事を指示する。

[global]
...
idmap backend = ldap:ldap://onterose/
ldap idmap suffix = ou=Idmap
idmap uid = 40000-50000
idmap gid = 40000-50000

この設定では、UID/GID名前空間を複数のサーバー上で共有するWinbindの利用が 出来るようになり、Samba-2.2で存在していた、NFSとの相互運用の問題を 解決する。

Chapter 36. NT4 PDC からSamba-3 PDCへの移行

John H. Terpstra

Samba Team

April 3, 2003

これは、NT4ドメイン制御からSamba-3ベースのドメイン制御に移行する事を手助けするための、 大まかなガイドである。

計画と開始方法

ITの世界では、しばしば、すべての問題は、貧弱な計画のために発生すると言われている。 この言葉の結果として、予期され、計画される問題はすべてではない。さらに言うと、 計画が良いと、ほとんどの、致命的なタイプの状況を予想できると言うことである。 In the IT world there is often a saying that all problems are encountered because of poor planning. The corollary to this saying is that not all problems can be anticipated and planned for. Then again, good planning will anticipate most show-stopper-type situations.

Microsoft Windows NT4ドメイン制御からSamba-3ドメイン制御環境への移行を考えている場合、 詳細な移行プランを作成すべきである。そこで、ここでは、移行を進めるために手助けとなる、 いくつかの点について説明する。

目的

多くの組織における重要な目的は、可能な限り副作用がないように、Microsoft Windows NT4 からSamba-3ドメイン制御に移行を行うことである。移行手順において体験する挑戦の1つは、 新しい環境でも状態がそのまま残っているという、説得力のある状態の提供であろう。 オープンソース技術を導入する人は、最初にトラブルの徴候があったときに、Microsoftベースの プラットフォームソリューションに戻せ、という圧力を体験するだろう。

Samba-3が制御しているネットワークに移行を試みる前に、可能な限り、周りすべてから、 変更に対する、承認を得る努力を行うようにする。なぜ組織において 変更が重要であるかを正確に理解しておくこと。変更を行う動機付けの例としては以下がある:

  • ネットワーク管理の容易性向上。

  • ユーザーレベルでのよりすぐれた機能の提供。

  • ネットワーク運用コストの低減。

  • MicrosoftによるNT4サポート終了によって引き起こされるexposureの低減。

  • Avoid MS License 6 implications.

  • 組織がMicrosoftに依存する事の低減。

Samba-3はMicrosoft Windows NT4ではないことを、誰でもが知っておくようにすること。 Samba-3はMicrosoft Windows NT4とも、それに対して利点を提供する事とも異なる、代替 ソリューションを提供する。Samba-3は、Microsoft NT4からMicrosoft Windows 2000と その後継(Active Directoryサービスを使う/使わないのどちらでも)への移行における、 本質的な価値として紹介している多くの機能を持っていないことを認識すること。

Samba-3が提供できていないはどのようなものがあるだろうか?

  • Active Directoryサーバー

  • グループポリシーオブジェクト(Active Directory中の)。

  • マシンポリシーオブジェクト。

  • Active Directory中のログオンスクリプト

  • Active Directory中のソフトウェアアプリケーションとアクセス制御。

Samba-3の機能で提供していないものと、使用しているサイトでとても大きな関心があるかも しれないものは以下の通り:

  • より少ない所有コスト。

  • Global availability of support with no strings attached.

  • UNIX/Linuxシステム単位で1つ以上のSMB/CIFSサーバーを動作できる)。

  • その場その場でのログオンスクリプトの作成。

  • その場その場でのポリシーファイルの作成。

  • より優れた安定性、信頼性、パフォーマンスと可用性。

  • SSH接続経由よる操作性。

  • バックエンド認証技術を自由に選べる(tdbsam,ldapsam)。

  • 完全なシングルサインオン技術の実装機能。

  • 絶対的に小さい広域ネットワークのバンド幅を要求するための分散認証技術機能。

Microsoft Windows NT4からSamba-3へのネットワーク移行の前に、すべての必要な要素を考慮する。 変更についてユーザーを教育し、そうすることでユーザーに受け入れられるようになり、必要な仕事の 障害にならないようにすべきである。以下の節では、移行を成功させるための要素について説明 している。

ドメインレイアウト

Samba-3はドメインコントローラー、バックアップドメインコントローラー(おそらく、最も 広くセカンダリコントローラーと呼ばれる)、ドメインメンバー、あるいはスタンドアロンサーバーとして 設定できる。Windowsネットワークセキュリティドメインコンテキストは、実装の前に、 sized(?)と、よく調査を行うべきである。バックアップドメインコントローラー(BDC)と同様、 プライマリドメインコントローラー(PDC)を配置するため、特別な注意を払う必要がある。 Samba-3がMicrosoftの技術とは違う1つの方法は、もしもLDAP認証バックエンドを使うことを 選択した場合、同じデータベースをいくつかの異なったドメインで使うことが出来るという ことである。複雑な組織において、それは、同時に多数のドメインをサポートできる、 分散可能な(1つのマスターサーバーと複数のスレーブサーバー)単一のLDAPデータベースにできる。 Samba-3 can be configured as a domain controller, a backup domain controller (probably best called a secondary controller), a domain member, or a standalone server. The Windows network security domain context should be sized and scoped before implementation. Particular attention needs to be paid to the location of the Primary Domain Controller (PDC) as well as backup controllers (BDCs). One way in which Samba-3 differs from Microsoft technology is that if one chooses to use an LDAP authentication backend, then the same database can be used by several different domains. In a complex organization, there can be a single LDAP database, which itself can be distributed (have a master server and multiple slave servers) that can simultaneously serve multiple domains.

デザインの観点から、1台のサーバーあたりのユーザー数はドメインあたりのサーバーの数と同様、 サーバーの能力とネットワークのバンド幅を考慮に入れて、スケーリングすべきである。

物理的なネットワークセグメントはいくつかのドメインを収容しているかもしれない。おのおのは、 複数のネットワークセグメントにまたがっているかもしれない。ドメインがルーテイングされた セグメントにまたがっている場合、ネットワークの設計とレイアウトのパフォーマンス評価を テストし考慮する。複数のルーティングされたネットワークセグメントをサポートするように 設計された、中央に位置するドメインコントローラーは、パフォーマンスが悪いという問題を 引き起こすかもしれない。リモートセグメントとPDC間のレスポンスタイム(pingのタイミング)を 調べること。もしもそれが長い(100msよりも大きい)場合、ローカルでの認証を提供する ために、リモートセグメント上にBDCを配置し、制御サーバーにアクセスする。

サーバーの共有とディレクトリのレイアウト

足を付けずには破ることの出来ない、効果的なネットワーク設計のための基本原則がある。 最も重要なルールは:よく制御されたネットワークおのおのにおいて、単純さを確保すること。 基盤のすべての部分は、管理可能にしなければならない。それをより複雑にすると、 システムをセキュアに保つことと機能を確保することの要求は増大するだろう。

どのようにデータを共有しなければならないかという性質について、心にとめておくこと。 物理ディスクスペースレイアウトは注意深く考えられるべきである。いくつかのデータは バックアップが必要である。ディスクレイアウトを単純にすると、バックアップの必要性を 記録するのはより容易になるだろう。どのメディアが必要を満たすかについて見極めること。 テープ、CD-ROMあるいはDVD-ROMや他のオフラインストレージシステムを考慮する。最小限の メンテナンスを計画し、実現の用意をする。設計の中に危険な点を残さないこと。とりわけ、 バックアップすることを忘れてはならない。バックアップし、テストし、すべてのバックアップを 検証する。ディザスタリカバリプランを作成し、それが動くかを検証する。

データアクセス制御の必要性を付与するために、ユーザーはグループ化されるべきである。 ファイルとディレクトリアクセスは、グループパーミッション経由で最もよく制御でき、 グループ制御のディレクトリ上にスティッキービットを使うと、Sambaの 共有ユーザーからのファイルアクセス時の不満を十分に防止するかもしれない。

未経験のネットワーク管理者は、しばしば、ファイル、ディレクトリ、共有に対して、共有内の 定義と同じようにアクセス制御を設定するための、手が込んだ技術を適用しようとする。 設計と実装は単純にすること、そして、広範囲に設計を文書化すること。他の誰かが作成した 文書を監査するようにすること。後継者が理解できないような、複雑な文書を作らないこと。 覚えておいてほしいのは、複雑な設計と、実装を使うジョブのセキュリティは、新参の管理者が 結び目のほぐし方を学ぶように、利用者に対して、運用障害と運用停止をもたらすかも しれない。アクセス制御は簡単かつ効果的にして、obtuse complexityによって中断されることの 無いようにする。 Inexperienced network administrators often attempt elaborate techniques to set access controls on files, directories, shares, as well as in share definitions. Keep your design and implementation simple and document your design extensively. Have others audit your documentation. Do not create a complex mess that your successor will not understand. Remember, job security through complex design and implementation may cause loss of operations and downtime to users as the new administrator learns to untangle your knots. Keep access controls simple and effective, and make sure that users will never be interrupted by obtuse complexity.

ログオンスクリプト

ログオンスクリプトは、すべてのユーザーが必要に応じて共有とプリンターへの接続を得る事を 保証する事を手助けするものである。

ログオンスクリプトは、動的に作成でき、動作させるすべてのコマンドは、そのユーザーが持つ 権限と権利が指定される。優先する制御の設定は、グループメンバーシップを使って設定 すべきであり、グループ情報は、カスタムログオンスクリプトを作成するために使われ、 それは、NETLOGON共有に対する root preexecパラメーターを使う。

いくつかのサイトでは、制御されたユーザー環境を確立するために、kixstart のようなツールを使っている。この場合、ログオンスクリプトプロセス制御のために、Google検索を 行ってもよい。実際、ログインスクリプト経由で、ユーザーが介入することなしに、 プリンターを追加する方法について記述しているMicrosoft Knowledge Baseの記事KB189105の使用法 を調査してもよい。

プロファイルの移行/作成

ユーザーとグループのプロファイルは、デスクトッププロファイル管理という節で説明されている ツールを使って移行できる。

プロファイルはSamba-3ツールprofilesを使って管理しても良い。このツールは、 Samba-3ドメインのSIDに変更される、NTuser.DATプロファイルファイル中に 格納されるMicrosoft Windows NT形式のセキュリティ識別子(SID)を扱える。

ユーザーとグループアカウント

Microsoft Windows NT4ドメインからSamba-3に、すべてのアカウント設定を移行することは 可能である。ユーザーとグループアカウントを移行する前に、Microsoft Windows NT4ドメインに 存在しているグループをSamba-3中に作成することと、それを適切なUNIX/Linuxグループにマップ することを強く推奨する。以下の単純な助言に従い、すべてのユーザーと グループの属性は、無事に移行すべきである。

移行プロセスの手順

おおよその移行プロセスは以下の通りである。

  • 移行対象の、ユーザー、グループ、ポリシーとプロファイルを持つNT4 PDCがあるとする。

  • Samba-3はnetlogon共有、プロフィル共有やその他を持つドメインコントローラーとして 設定してある。smb.confファイルをBDCとして機能するように、 domain master = No と設定する。

Procedure 36.1. アカウント移行プロセス

  1. NT4 サーバーマネージャを使い、Sambaサーバーを古いNT4ドメイン中でBDCに設定する。 Samba must not be running.

  2. net rpc join -S NT4PDC -w DOMNAME -U Administrator%passwd

  3. net rpc vampire -S NT4PDC -U administrator%passwd

  4. pdbedit -L

    注意: ユーザーは移行できただろうか?

  5. 次に、各UNIXグループをNTグループに割り当てる: initGroups.shとして下記のテキストをコピーし、スクリプトに しておくと便利である。)

    #!/bin/bash
    #### Keep this as a shell script for future re-use
    			
    # First assign well known domain global groups
    net groupmap add ntgroup="Domain Admins" unixgroup=root rid=512 type=d
    net groupmap add ntgroup="Domain Users"  unixgroup=users rid=513 type=d
    net groupmap add ntgroup="Domain Guests" unixgroup=nobody rid=514 type=d
    
    # Now for our added domain global groups
    net groupmap add ntgroup="Designers" unixgroup=designers type=d
    net groupmap add ntgroup="Engineers" unixgroup=engineers type=d
    net groupmap add ntgroup="QA Team"   unixgroup=qateam    type=d
    

  6. net groupmap list

    すべてのグループが認識されたかを確認する。

すべてのプロファイルの移行と、すべてのポリシファイルの移行。

移行オプション

Microsoft Windows NT4ドメイン制御からSambaベースのソリューションへの移行を行いたい サイトは、一般的に3つの基本的なカテゴリに適合する。 以下のテーブルは、その例を表示する。

Table 36.1. 3つの主要なサイトのタイプ

ユーザー数説明
< 50

特段の手間暇を掛けずに単純な移行をしたい。

50 - 250

新しい機能を追加したい。いくつかの、組織内の複雑制を管理することが出来る。

> 250

ソリューション/実装は規模に対応しなければならない。 複雑な要求がある。組織間の調整。ほとんどの領域での専門的な知識。


うまくいくための計画

Microsoft Windows NT4からSamba-3へ移行したいサイトには、3つの基本的な選択肢がある。

  • 単純な移行 (丸ごと取り替え)。

  • アップグレードする移行(統合の一種でありえる)。

  • 完全な再設計 (完全に新しいソリューション)。

終了間際の問題を最小にするには:

  • 十分な時間の確保。

  • パニックを防ぐ。

  • すべての仮定のテスト。

  • ワークステーションの展開を含む、完全に提供されるプログラムのテスト。

以下のテーブルは、与えられた、予想される 移行のタイプの移行の選択肢を一覧表示する。

Table 36.2. 移行方式による相違点の詳細

単純移行アップグレード再設計

最低限のOS固有機能の使用

NT4の機能を新しいホストOSの機能に変更

NT4の機能を改善し、管理能力を強化

NT4からSamba-3にすべてのアカウントを移行

コピーと改善

認証システム(データベースの配置とアクセス)

最低限の操作上の変更

漸進的な改良

デスクトップ管理手法

最小限の移行時間

ユーザーへのインパクトを最小化

デスクトップ/ユーザーの制御を改善

運用停止を伴う移行作業

最大限の機能を利用

管理性、拡張性、保全性、可用性に対する必要性の識別

Samba-3の統合は、ユーザーが有効な時に移行し、次に、制御を変更(スワップアウト) Integrate Samba-3, then migrate while users are active, then change of control (swap out)

管理操作が少ないことを有効に利用


Samba-3実装の選択

認証データベース/バックエンド

Samba-3は外部の認証バックエンドを使える:

  • Winbind (他のSambaかNT4/200xサーバー)。

  • 外部サーバーはActive DirectoryかNT4ドメインを使える。

  • ホームディレクトリの自動作成を行うために、pam_mkhomedir.soが使える。

  • Samba-3はローカル認証バックエンドとして: smbpasswd, tdbsam, ldapsamが使える。

アクセス制御が出来る場所

Sambaは以下の場所でアクセス制御を設定できる:

  • 共有それ自身では共有ACLを使う。

  • ファイルシステム上ではファイルとディレクトリ上でUNIXのパーミッションを使う。

    注意:POLIX ACLは、ファイルシステム中でも有効に出来る。

  • Sambaの共有パラメーターも使えるが苦肉の策以外、推奨しない。

ポリシー(移行または新しいものの作成)

レジストリの変更時には、十分に用心すること;正しいツールを使い、恒久的に 変更点が保存される、NT4形式のNTConfig.POLファイルを 経由して変更が行われることに注意。

  • グループポリシーエディターを使用(NT4)

  • 入れ墨効果(tattoo effect)に注意。

ユーザーとグループプロファイル

プラットフォーム固有の場合では、ローカルから、ローミングプロファイル変更するために、 プラットフォームのツールを使う。SIDを変更するために新しいプロファイルツールが 使える(NTUser.DAT)。

ログオンスクリプト

それがどのように動くかは分かっている。

ユーザーとグループの、UNIX/Linuxへのマッピング

ユーザーとグループマッピングコードは新しくなった。Samba-2.2.xからSamba-3に 移行することになれているネットワーク管理者は、多くの問題を体験した。 新しいパスワードバックエンドの動作と、新しいグループマッピング機能について 記述している章を注意深く学習すること。

  • username map機能が必要になるかもしれない。

  • net groupmapでNT4グループをUNIXグループにつなぐ。

  • ユーザー設定を設定/変更するためにpdbeditを使う。

    LDAPバックエンドに移行するとき、初期LDAPデータベースをLDIFにダンプ、 編集し、次にLDAPに再ロードするのは容易である。

OS固有のスクリプト/プログラムが必要になるかもしれない

すべてのOSはそれ固有の習慣がある。設計者の体験と、予期されない副作用があるかもしれない 事をベースにする技術的な議論の結果がある。Windowsネットワーク管理者が引っかかる制限には 以下のものがある:

  • ユーザーの追加/削除: OSによる名前のサイズ制限に注意 (Linuxは8文字まで, NT4は254文字まで)。

  • マシンの追加/削除: ドメインメンバーのみに適用される (注意:マシン名は16文字までに制限される)。

  • NT4グループからUNIXグループへ接続するためにnet groupmapを使用。

  • グループの追加/削除:OSによるサイズと特性の制限に注意。 Linuxは16文字まで、空白不可、大文字不可(groupadd)。

移行ツール

ドメイン制御(NT4形式)プロファイル、ポリシー、アクセス制御、セキュリティ

  • Samba: net, rpcclient, smbpasswd, pdbedit, profiles

  • Windows: NT4 ドメインユーザーマネージャ, サーバーマネージャ(NEXUS)

Chapter 37. SWAT: Samba Web 管理ツール

John H. Terpstra

Samba Team

April 21, 2003

SWATの有用性に関連しては、数多くの様々な意見がある。完璧な設定ツールを作ろうとする 試みはとても大変な事なのにもかかわらず、個人的な興味の対象として存在している。 SWATはSambaをWebベースで設定するためのツールである。これは、Sambaを簡単に設定する ための手助けとなりえるウィザードであり、場面に応じて各smb.confパラメーターの ヘルプをWebベースで表示し、現在の接続状況をモニターリングする機能を提供し、ネットワーク 全体の、Microsoft Windowsネットワークパスワード管理ができる。

機能と利便性

SWATはSambaシステムの一部である。基本となるプログラム名はswatであり、 これはinetdのようなスーパーデーモンによって起動される。詳細は 説明の節を参照のこと。

SWATは特定のバージョンのSambaによってサポートされる、パラメーターを使うために、 Sambaコンポーネント全体を使う。Samba外部のツールとユーティリティとは異なり、 SWATは常時Sambaパラメーターが変更されることに追従している。SWATは各設定パラメーターに 対して、場面に応じて、マニュアルページのエントリから、直接 ヘルプを提供する。

ネットワーク管理者の何人かは、設定ファイル中にシステムの説明を書き込むことは良いアイデア だと思っている人もいるが、そういう人にとって、SWATは常にひどいツールである。SWATは、 何らかの中間的な形式でも、設定ファイルに格納しない。というよりは、パラメーターの設定のみを 書き込む。SWATがsmb.confファイルをディスクに書き込むときには、既定値の設定以外の パラメーターのみを書き込む。結果、パラメーターと同じように、すべてのコメントは保持されず、 smb.confファイル中から無くなってしまう。おまけに、パラメーターは内部での順番に 書き戻される。

Note

SWATを使う前には、 SWATは、書き込んだであろうすべてのコメントを削除した、完全に 最適化されたファイルで、smb.confファイルを完全に置き換え、ファイルには既定値の設定以外の 設定のみが書かれる。

ガイドラインと技術的なTips

この節では、どのようにSWATが動くかせるかという仕掛けの背景にある、秘密の闇を明らかにする 事と、どのようにセキュアに出来るかということと、どのように国際化のサポートを解決するか という事を説明する。

SWATインストールの有効か

SWAT操作のためにホストシステムを設定する試みの前にやるべきである、ごく最初のステップは、 それがインストールされているかを調べることである。これは、ある人にとっては取るに足らない ことに見えるかもしれないが、いくつかのLinuxディストリビューションでは、 ディストリビューションメディア上で、SWATを含む、インストール可能なバイナリパッケージを 提供しているにもかかわらず、SWATを既定値ではインストールしていない。

SWATがインストールされていることを確認したら、すべてのサポートしているテキストとWeb ファイルと同じように、インストールされているバイナリswatファイルを 有効化することが必要である。過去、多くのOSディストリビューションが、 swatバイナリ実行形式ファイルがインストールされているのにも かかわらず、サポートに必要なファイルを含めることに失敗している。

最後に、SWATが完全にインストールされたと思ったら、使用しているOSプラットフォームで 使われているinetd系スーパーデーモン(inetdかxinetd)用の制御ファイルで、SWATが 有効になっているかを調べてほしい。

SWATファイルの配置

SWATがインストールされたかを検証するため、最初に、システム上のswat バイナリファイルを捜す。それはおそらく以下のディレクトリ配下にあるだろう:

/usr/local/samba/bin 既定値のSambaでの位置
/usr/sbin ほとんどのLinuxシステムでの既定値の位置
/opt/samba/bin

実際の位置はOSベンダの選択か、Sambaをコンパイルしてインストールした管理者の決定によって 大きく変わる。

swatバイナリファイルを見つけるために使う方法にはいろいろある。 以下の方法を使うと便利である。

もしも、swatが現在のOSサーチパス中にあるならば、それを見つけるのは 簡単である。以下のように、swatが、どのようなコマンドラインオプションを 持っているかを調べてみればよい:

frodo:~ # swat -?
Usage: swat [OPTION...]
  -a, --disable-authentication         Disable authentication (demo mode)

Help options:
  -?, --help                           Show this help message
  --usage                              Display brief usage message

Common samba options:
  -d, --debuglevel=DEBUGLEVEL          Set debug level
  -s, --configfile=CONFIGFILE          Use alternative configuration file
  -l, --log-basename=LOGFILEBASE       Basename for log/debug files
  -V, --version                        Print version

SWATサポートファイルの配置

swatがサーチパス中に見つかったならば、ファイルがどこに 配置されているかを識別するのは簡単である。これを行う簡単な別解は以下の通り:

frodo:~ # whereis swat
swat: /usr/sbin/swat /usr/share/man/man8/swat.8.gz

もしも上記による調査で、swatバイナリを見つけるのに失敗したら、 他の方法が必要である。以下が使える:

frodo:/ # find / -name swat -print
/etc/xinetd.d/swat
/usr/sbin/swat
/usr/share/samba/swat
frodo:/ #

この一覧は、このサーバーにインストールされているinetd系スーパーデーモン xinetdの制御ファイルを表示している。SWATバイナリファイルの位置は /usr/sbin/swatであり、それがサポートしているファイルはディレクトリ /usr/share/samba/swat配下にあることを表示している。

次に、swatが使うサポートファイルがどこにあるかを調べる。これは 以下のやり方で行う:

frodo:/ # strings /usr/sbin/swat | grep "/swat"
/swat/
...
/usr/share/samba/swat
frodo:/ #

この一覧の中にある/usr/share/samba/swat/エントリは、サポートファイルの 位置である。このディレクトリ配下にサポートファイルが存在しているかを調べるべきである。 以下は一覧の例である:

jht@frodo:/> find /usr/share/samba/swat -print
/usr/share/samba/swat
/usr/share/samba/swat/help
/usr/share/samba/swat/lang
/usr/share/samba/swat/lang/ja
/usr/share/samba/swat/lang/ja/help
/usr/share/samba/swat/lang/ja/help/welcome.html
/usr/share/samba/swat/lang/ja/images
/usr/share/samba/swat/lang/ja/images/home.gif
...
/usr/share/samba/swat/lang/ja/include
/usr/share/samba/swat/lang/ja/include/header.nocss.html
...
/usr/share/samba/swat/lang/tr
/usr/share/samba/swat/lang/tr/help
/usr/share/samba/swat/lang/tr/help/welcome.html
/usr/share/samba/swat/lang/tr/images
/usr/share/samba/swat/lang/tr/images/home.gif
...
/usr/share/samba/swat/lang/tr/include
/usr/share/samba/swat/lang/tr/include/header.html
/usr/share/samba/swat/using_samba
...
/usr/share/samba/swat/images
/usr/share/samba/swat/images/home.gif
...
/usr/share/samba/swat/include
/usr/share/samba/swat/include/footer.html
/usr/share/samba/swat/include/header.html
jht@frodo:/>

もしも必要とされるファイルが内ならば、SWATを使う前に、それらを入手してインストールする 必要がある。

SWATを使用できるように有効化する

SWATはネットワークスーパーデーモン経由で動くようにインストールすべきである。 使用しているUNIX/Linuxシステムが持っているものに依存するので、 inetdxinetdベースのシステムのどちらかを使う。

ネットワークスーパーデーモンの機能と配置はOSの実装により変わる。制御ファイルは /etc/inetd.confかディレクトリ/etc/[x]inet[d].dか 同様の位置に置くことが可能である。

古い形式のファイルに対する制御エントリは以下の通り:

	# swat is the Samba Web Administration Tool
	swat stream tcp nowait.400 root /usr/sbin/swat swat

新しい形式でのxintd用制御ファイルは以下の通り:

# default: off
# description: SWAT is the Samba Web Admin Tool. Use swat \
#              to configure your Samba server. To use SWAT, \
#              connect to port 901 with your favorite web browser.
service swat
{
	port    = 901
	socket_type     = stream
	wait    = no
	only_from = localhost
	user    = root
	server  = /usr/sbin/swat
	log_on_failure  += USERID
	disable = no
}

上記の中で、disableの既定値の設定はyesである。 これは、SWATが無効になっていることを意味する。SWATを有効にするには、上記のように、 このパラメーターをnoに設定する。

上記の例は両方ともswatバイナリがディレクトリ /usr/sbinに配置されていることを仮定している。上記に補足すると、 SWATは他の制御情報と同じように、自身のヘルプファイルをそこからロードするディレクトリ アクセス点として使う。多くのLinuxシステムにおけるこのための既定値の位置は、 /usr/share/samba/swatである。Sambaが使う既定値の位置は、 /usr/local/samba/swatである。

SWATへアクセスするとログオンを要求される。もしも非rootユーザーでSWATにログオンすると、 パスワード変更機能へのアクセスと同じように、一定の設定範囲にのみアクセスが許可される。 非rootユーザーが見えるボタンは、HOMESTATUSVIEWPASSWORDである。この場合に変更 可能なページはPASSWORDだけである。

rootユーザーでSWATにログオンすると、完全な修正、更新権限を得られる。 表示されるものは、HOME, GLOBALS, SHARES, PRINTERS, WIZARD, STATUS, VIEWPASSWORDである。

SSLを使うSWATのセキュア化

多くの人が、Sambaをリモートから安全に管理することが出来るために、どのように SSLを使うSWATを設定するかについて問い合わせしている。以下はMarkus Kriegerの 好意による、そのやりかたである。

SWAT設定の変更点は以下のようになる:

  1. OpenSSLをインストールする。

  2. 証明書(ertificate)とプライベートキーを生成する。

    root# /usr/bin/openssl req -new -x509 -days 365 -nodes -config \
    	/usr/share/doc/packages/stunnel/stunnel.cnf \
    	-out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem
    
  3. [x]inetdからSWATエントリを削除する。

  4. stunnelを起動する。

    root# stunnel -p /etc/stunnel/stunnel.pem -d 901 \
    	 -l /usr/local/samba/bin/swat swat 
    

その後、単純に、URL https://myhost:901 を使ってSWATにアクセスし、証明書を受け付け、SSL接続を確立する。

SWAT国際化サポートの有効化

SWATは、使用しているWebブラウザーの言語設定に一致するように、そのメッセージを表示するよう 設定できる。これは、HTTPリクエストのAccept-LanguageヘッダーでSWATに通知される。

この機能を有効にするには以下のように行う:

  • 適切なmsgファイルを、Sambaのsource/po ディレクトリから、$LIBDIRにインストールする。

  • ブラウザーの言語設定を設定する。

msgファイルの名前はブラウザーによって送られる言語IDと同じである。 例えば、英語はen、日本語はja、 フランス語はfrである。

メッセージのいくつかが気に入らないか、使用しているロケール用のmsg ファイルがない場合、単にen.msgファイルを、 使用している言語の ID.msgファイル用のディレクトリにコピーし、各 msgstrに適切な文字列を埋める。例えば、it.msgを イタリア語のmsgファイルにするには、以下のようにする:

msgid "Set Default"
msgstr "Imposta Default"

以下同様である。もしも間違いを見つけたか、新しいmsgファイルを作成 したならば、連絡いただければ、次のSambaリリース中に入れることを考えます。 msgファイルはUTF-8でエンコードされるべきである。

もしも有効にした場合、この機能とdisplay charsetがブラウザーの 設定と一致していなかった場合、SWATは不正なメッセージを表示するかもしれないことに注意。 将来のSambaのバージョンでは、SWATは常時UTF-8でエンコードされたメッセージを表示する だろう。そうなれば、これをsmb.confファイルのパラメーターとして設定する必要はなくなる。

概要と簡単な紹介

SWATはSambaの設定に使え、Windowsネットワークの問題を解決するために便利な文書のように、 この本(ドキュメント)の内容のような、重要な参考資料への便利なリンクを得られる、 便利なツールである。

SWAT ホームページ

SWATタイトルページは最新のSamba文書を参照する機能を提供する。オライリーの Using Sambaという本と同様、Samba3-HOWTO(この文書)のように、 Sambaの各コンポーネントのマニュアルページはこのページからアクセス可能である。

Sambaの設定を検証したい管理者は、診断ツールのマニュアルページから有益な情報を得ても良い。 それらはSWATホームページからも入手可能である。診断ツールのうち、このページで言及されて いないが、特に便利なものは ethereal(訳注:今は wireshark)である。

Warning

SWATはデモモードで動かすように設定できる。これは、認証なしにSWATを 動かし、完全な管理機能が使えてしまうため推奨しない。このモードでは、root特権で通常の 操作をするようにsmb.confを変更できる。SWATでこの機能を使うためのオプションは、 -aフラグである。 これを動作中の環境で使ってはならない

全体(Global)の設定

グローバル(GLOBALS)ボタンは、smb.conf中のグローバルパラメーターの 設定が出来るページを表示する。パラメーターによって2レベルの画面がある:

  • 基本 共通設定オプションを表示する。

  • 詳細 より複雑な環境で必要な設定オプションを表示する。

基本編集機能から他に変更するには、詳細 ボタンをクリックする。ラジオボタンをクリックすることで行っても良い。次に、 変更ボタンをクリックする。

パラメーターをどこか変更した後は、他の場所に移る前に、変更 ボタンを押すようにすること。そうしないと変更結果は失われる。

Note

SWATは場面に応じたヘルプを提供する。各パラメーターが何であるかを調べるには、単に、 設定パラメーターの左にあるヘルプリンクをクリックする。

共有設定

現在設定されている共有の操作は、単に共有の選択共有の削除ボタンの間にあるプルダウンボタンをクリックし、 操作したい共有を選択する。設定を編集するには、 共有の選択ボタンをクリックする。共有を削除するには、 単に共有の削除ボタンをクリックする。

新しい共有を作るためには、共有の作成ボタンの隣に行き、 テキストフィールドに作成する共有の名前を入力し、次に 共有の作成ボタンをクリックする。

プリンター設定

現在設定されているプリンターの操作は、単にプリンターの選択プリンターの削除ボタンの間にあるプルダウンボタンをクリックし、 操作したいプリンターを選択する。設定を編集するには、 プリンター選択ボタンをクリックする。共有を削除するには、単に、 プリンターの削除ボタンをクリックする。

新しいプリンターを作るためには、プリンターの作成ボタンの隣に行き、 テキストフィールドに作成する共有の名前を入力し、次に プリンターの作成ボタンをクリックする。

SWATウィザード

SWATウィザードの目的は、Microsoft系をよく知っているネットワーク管理者が、最小の手間で Sambaを設定することである。

ウィザードページは、完全に最適化した形式でsmb.confファイルを再書き込みするツールである。 これは、Commitボタンを押したときにも起きる。2つの違いは、 Rewriteボタンは今まで行った変更を無視するのに対し、 Commitボタンは今まで行ったすべての変更を反映するということである。

Editボタンでは、動作するSambaサーバーを作成するために必要と思われる 最小限のオプションの編集(設定)ができる。

最後に、SambaサーバーがWINSサーバー、WINSクライアントとして参加、あるいはWINSサポートなし の、どれかタイプかに設定出来ることを決める、限定されたオプションが用意されている。 あるボタンをクリックすることで、ユーザーのホームディレクトリの表示(あるいは表示中止)を 選択できる。

ステータスページ

ステータスページは現的な目的で提供される。最初に、これはSambaデーモンの制御を行う。 Sambaサーバー環境下で作成できるデーモンは、smbd, nmbdwinbinddである。

デーモンは、個別、あるいは全体をまとめたグループで制御できる。さらに、自動的に 画面のリフレッシュを行うタイミングを設定しても良い。Microsoft Windowsクライアントが Sambaとやりとりをするように、新しいsmbdプロセスは継続して起動される。自動画面 リフレッシュ機能は、最小の効果で変更の状態を追従できる。

最後に、ステータスページはロックされたかもしれないファイルを解放するために、特定の smbdクライアント接続を終了する事に使うことも出来る。

表示(View)ページ

表示(View)ページは、最適化されたsmb.confを閲覧するためと、もしもマゾヒストな 場合、すべてのグローバル設定パラメーターとその値を見ることもできる。

パスワード変更ページ

パスワード変更ページは、ローカルマシン上のMicrosoft Windows ネットワークユーザーの、 作成、変更、無効化と再有効化ができる便利なツールである。ユーザーアカウントのローカル パスワードを変更するのにもこのツールを使える。

非rootユーザーでログオンした場合、新しい(二度打ちする)パスワードと同様古いパスワードも 入力しなければならない。rootでログオンした場合、新しいパスワード のみが必要である。

このツールのよくある使い方は、リモートのMicrosoft Windowsサーバー群に対してユーザーパスワードを 変更するということである。

Part V. トラブルシューティング

Chapter 38. Sambaチェックリスト

Andrew Tridgell

Samba Team

Jelmer R. Vernooij

The Samba Team

Dan Shearer

Samba Team

Wed Jan 15

概要

この章には、Sambaサーバーの検証が行えるテストの一覧が含まれている。また、それらの手順の どこかで失敗した問題を起こす可能性の高いものが何かと言うことについても説明している。 もしも、すべてのテストをパスしたら、おそらく正しく動いているだろう。

すべてのテストを示された順で行うべきである。後のテストが、前のテストで確認された 機能のみを使うように、テストを注意深く選ぶようにしてある。しかし、最初のエラーで 止まってはならない:テストの継続が、問題の解決を手助けするという事例があったからで ある。

もしも、It does not work,というタイトルでメールをSambaメーリングリストの どこかに送り、このテスト手順に従わないならば、メールが無視されても驚いてはいけない。

前提条件

すべてのテストにおいて、SambaサーバーはBIGSERVERで、PCクライアントがACLIENTで、両者とも TESTGROUPというワークグループに属していることを仮定する。

手続きは、他のクライアントのタイプと同様である。

smb.conf中の有効な共有名も分かっているものとする。ここでの例における共有の名前は tmpである。これは、次の例 で示される行を追加することで、このようなtmp共有を追加できる。

Example 38.1. [tmp]共有のためのsmb.conf

[tmp]
comment = temporary files
path = /tmp
read only = yes

Note

これらのテストはバージョン3.0.0以降のSambaシステムを仮定する。以前のバージョンでは いくつかのコマンドは存在しない。

受け取ったエラーメッセージに注意をはらってほしい。もしもエラーメッセージが、使用している サーバーが調子が悪いという事を報告しているのであれば、まず初めに使用しているIPを名前解決 する方式が正しく設定されているかどうかをチェックすべきである。実際に存在している ネームサーバーを、/etc/resolv.confが正しく指し示しているようにする こと。

また、もしも、名前解決用のDNSサーバーアクセスが出来ないならば、smb.confdns proxy = noが設定されているかをチェックする。 これをチェックする最も良い方法は、testparm smb.confである。

別のターミナルコンソール(X中で複数のターミナルを使うには、ctrl-alt-F1からF6を使用)で、 tail -F log_file_nameを使うことで、テストの間ログファイルをモニターする のは便利である。適切なログファイルは(既定値によるインストールでは)、 /usr/local/samba/varにある。また、マシンからの接続ログは、ここか、 /var/log/sambaか、あるいは smb.confファイル中でロギングを指定した場合には、それに依存する場所にある。

もしも、それらのテスト中にsmb.confファイルを変更したならば、smbdnmbdの再起動を 忘れないこと。

テスト

Procedure 38.1. 使用しているSambaサーバーの診断

  1. smb.confファイルを格納しているディレクトリ中で、testparm smb.confを 実行する。もしも何らかのエラーが発生した場合、そのsmb.confの設定には間違いがある。

    Note

    使用しているsmb.confファイルは、/etc/samba/usr/local/samba/libにあってもよい。

  2. PCからping BIGSERVERコマンドを動かし、UNIXマシンから ping ACLIENTを動かす。正常な応答がない場合、TCP/IP層の設定が うまくいっていない。

    PC上でpingを動かす場合には、DOS プロンプトを起動する必要がある。

    もしも、host not foundか同様なメッセージが 表示されたならば、DNSソフトウェアか/etc/hostsファイルが正しく 設定されていない。もしもDNSを使っている場合、/etc/resolv.confに、 正しい、最新のエントリがあるかどうかをチェックする。DNSエントリなしにSambaをサーバーと クライアントとして動作させることは可能であるが、この後のテストでは、正しいエントリが あると仮定している。

    pingが失敗するかもしれない他の理由としては、使用しているホスト上でファイアウォール ソフトウェアが動作している場合である。ワークステーションからの問い合わせに対して ルールをゆるめる必要がありえ、それはおそらく、他のサブネットからのアクセスを許可する ことであろう(Linux上では、これは、ipchainsiptablesという、適切なファイアウォール管理コマンドによって行える)。

    Note

    最新のUNIXディストリビューションでは、既定値でipchains/iptablesをインストールしている。 これは、しばしばよく見落とされる問題である。

    もしも、テスト中にシステム中どのようなファイアウォールルールが存在しているかを調べたい 場合、単純にiptables -L -vか、あるいは ipchainsベースのファイアウォールを使っている場合には、 ipchains -L -vを入力する。

    以下は、Sambaが有効になっていない外部向けのイーサネットインタフェース(eth1)とSambaが 有効になっている内部向けの(プライベートネットワーク)インタフェース(eth0)を持つ、 システムからの結果例である。

    frodo:~ # iptables -L -v
    Chain INPUT (policy DROP 98496 packets, 12M bytes)
     pkts bytes target     prot opt in     out     source     destination
     187K  109M ACCEPT     all  --  lo     any     anywhere   anywhere
     892K  125M ACCEPT     all  --  eth0   any     anywhere   anywhere
    1399K 1380M ACCEPT     all  --  eth1   any     anywhere   anywhere  \
    					state RELATED,ESTABLISHED
    
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source     destination
     978K 1177M ACCEPT     all  --  eth1   eth0    anywhere   anywhere \
    					state RELATED,ESTABLISHED
     658K   40M ACCEPT     all  --  eth0   eth1    anywhere   anywhere
        0     0 LOG        all  --  any    any     anywhere   anywhere \
    					LOG level warning
    
    Chain OUTPUT (policy ACCEPT 2875K packets, 1508M bytes)
     pkts bytes target     prot opt in     out     source     destination
    
    Chain reject_func (0 references)
     pkts bytes target     prot opt in     out     source     destination
    

  3. UNIXマシン上でsmbclient -L BIGSERVERを動かす。 これで有効な共有の一覧が得られる。

    もしもbad passwordという文字列があるエラーメッセージが表示されたら、 不正なhosts allowhosts denyvalid users行がsmb.confにあるか、ゲストアカウントが無効に なっている。testparmでゲストアカウントが何かを調べ、一時的に hosts allow, hosts deny, valid users, かinvalid users行を 削除してみる。

    もしも、connection refusedというメッセージが帰ってきたら、 smbdサーバーが動いていないかもしれない。もしも inetd.conf経由で動作するようにしていたら、おそらくこのファイルの 編集が間違っている。もしもdaemonとして動作するようにしていたら、動作しているかを調べ、 netstat -aを使ってnetbios-ssnポートがLISTEN中かを確認する。

    Note

    ある種のUNIX/Linuxシステムでは、inetdの代わりに xinetdを使っている。ネットワークスーパーデーモンの、 特定のシステム実装についての、制御ファイルの位置の説明文書を調べること。

    もしも、session request failedというメッセージが表示されたならば、 サーバーは接続を拒否している。もしもYour server software is being unfriendly というメッセージが表示されたならば、それはおそらくsmbdに対するコマンドラインオプションを 間違えているか、smbdの初期起動時に同様の致命的な問題がある。testparmで設定ファイル (smb.conf)の文法と、ログとロックファイルを保持する種々のディレクトリもチェックする。

    セッション要求を拒否するか、断るかもしれない数多くの理由がある。それらは、 次の例で示されているsmb.confファイルのエントリ によって発生する。

    Example 38.2. 特定のサブネットからのみ接続を受け付ける設定例

    [globals]
    hosts deny = ALL
    hosts allow = xxx.xxx.xxx.xxx/yy
    interfaces = eth0
    bind interfaces only = Yes

    特定のサブネットからのみ接続を受け付ける設定例では、 ループバックアダプターアドレス 127.0.0.1へ自動的に変換される任意のセッション要求は 許可されない。この問題を解決するためには、以下の例で 示されているような行に変更する。

    Example 38.3. 特定のサブネットとローカルホストから接続を許可する例

    [globals]
    hosts deny = ALL
    hosts allow = xxx.xxx.xxx.xxx/yy 127.
    interfaces = eth0 lo

    他の、よくある2つのエラーの例は、Samba(すでにinetd経由で smbdが動いている)か、DECのPathworksのような、ポート139上で 何かがすでに動いているものである。デーモンでsmbdを動かす前に inetd.confファイルをチェックすること。そうすれば 多くのトラブルを防げる!

    さらに、このテストが失敗する、他のあり得そうな例としては、サブネットマスクか ブロードキャストアドレスの設定が不正な場合である。ネットワークインタフェースの IPアドレス、ブロードキャスト、サブネットマスクが正しいかと、それらが log.nmbdファイル中に正しくSambaが記録しているかを確認すること。

  4. nmblookup -B BIGSERVER __SAMBA__コマンドを動かす。 使用しているSambaサーバーのIPアドレスが表示されるはずである。

    そうでない場合、nmbdが駄々しくインストールされていない。inetd.conf 経由で動かしている場合はそこを、あるいはデーモンが動いていてUDPポート137をリッスン しているかどうかをチェックする。

    ある1つのよくある問題は、多くのinetdの実装が、コマンドライン上に多数のパラメーターを使えない というものである。もしもこの場合、正しいパラメーターを含む1行のみのスクリプトを作成し、 それをinetdから起動する。

  5. nmblookup -B ACLIENT `*'を起動する。

    PCのIPアドレスが表示されるはずである。もしもそうでなければ、PC上のクライアント ソフトウェアの設定が間違っているか、開始していないか、PCの名前が間違っているか である。

    もしもACLIENTがDNS経由で名前解決できない場合、上記のテストで、クライアントのIP アドレスを使用してみる。

  6. nmblookup -d 2 `*'コマンドを動かす。

    この時点では前述のテストと同じ事を試みるが、既定値のブロードキャストアドレスに、 ブロードキャスト経由で行う。それをリッスンしているSambaは短時間にすべての応答を 受け取れないかもしれないが、ネットワーク上にある、たくさんのNetBIOS/TCP/IPホストが、 これに応答する。いくつかのホストからの、 got a positive name query responseメッセージを受け取るはずである。

    もしも、上記のテストのような結果が得られないのであれば、nmblookupが、その自動 メカニズムによる、使用しているブロードキャストアドレスを正しく入手できていない。 この場合、使用するIPアドレス、ブロードキャストとサブネットマスクを、 smb.conf中のinterfacesオプションに、手動で設定する ことをやってみるべきである。

    もしも、使用しているPCとサーバーが同じサブネットにない場合、そのPCのサブネットの ブロードキャストアドレスを指定する-Bオプションを使う必要がある。

    このテストは、サブネットマスクとブロードキャストアドレスが間違っている場合、おそらく 失敗する(3つ前の注意(Note)を参照)。

  7. smbclient //BIGSERVER/TMPコマンドを動かす。パスワード要求が来る はずである。UNIXマシンにログインするアカウントのパスワードを入力する。もしも他の アカウントで、テストを行いたいならば、コマンドラインの最後の所に、 -U accountnameオプションを追加する。 たとえば、 smbclient //bigserver/tmp -Ujohndoeである。

    Note

    以下のように、ユーザー名に引き続いてパスワードを指定することも出来る: smbclient //bigserver/tmp -Ujohndoe%secret.

    パスワードを入力すると、smb>プロンプトが出るはずである。もしも そうでなければ、エラーメッセージが表示される。もしもそれが invalid network nameであれば、サービス tmpsmb.conf中で正しく設定されていない。

    bad passwordという表示がされたならば、 あり得そうな原因は以下の通り:

    1. shadowパスワード(かその他のパスワードシステム)を使っているが、smbd中で それをサポートするようにコンパイルされていない。

    2. 使用しているvalid usersの設定が間違っている。

    3. 大文字小文字を混ぜたパスワードを使っているが、十分に大きなレベルを password levelオプションで有効にしていない。

    4. smb.conf中のpath行が間違っている。testparmで 検査すること。

    5. パスワード暗号化を有効にしているが、SambaユーザーにUNIXユーザーをマップしていない。 smbpasswd -a usernameを実行する。

    接続後、コマンドdir, get,put などが使えるようになっているはずである。どう入力するかを調べるために、 help commandを入力する。dirコマンドを入力した 時に、空きディスクスペースが正しいかを、特にチェックすべきである。

  8. PC上で、net view \\BIGSERVERコマンドを入力する。これは、DOSウィンドウ 内で入力する必要がある。サーバー上で有効な共有一覧が表示されるべきである。

    network name not foundか似たようなエラーが表示された場合、NetBIOS 名前解決が動作していない。これは通常nmbdの問題である。これを解決 するために、以下のどれかを行う(どれか1つを選ぶのみでよい):

    1. nmbdのインストールを修正する。

    2. PC上のTCP/IP設定中にある「詳細設定」においてwinsタブ中に BIGSERVERのIPアドレスを追加する。

    3. TCP/IP設定中にある「詳細設定」においてDNS経由での名前解決を有効にする。

    4. PC上のlmhostsファイルにBIGSERVERを追加する。

    もしも、invalid network namebad password error,というメッセージが表示された ならば、smbclient -Lテストでのと同じ修正を行う。特に、 hosts allow行(マニュアルページを参照)が正しいかを確認すること。

    また、ワークステーションがSambaサーバーに接続を要求するとき、Windowsマシンにログオンしている 名前を使うという事実を見落とさないこと。Sambaサーバー上で存在しているアカウントと正確に 同じ名前とパスワードにする必要がある。

    もしもspecified computer is not receiving requests か、同等のエラーが表示されたならば、おそらくTCP経由でホストに接続できないことを 意味する。TCPラッパーがホスト上で動いているかを調べ、そうであれば、クライアント (かサブネット等)のエントリをhosts.allowに追加する。

  9. net use x: \\BIGSERVER\TMPを実行する。パスワード要求が来るはずである。 次に、command completed successfullyメッセージが表示 されるはずである。そうでない場合、PC上のソフトウェアが正しくインストールされていないか、 smb.confが間違っている。smb.conf中のhosts allowと他の 設定行が正しいかを確認する。

    サーバーが、どのユーザー名で接続するかを見いだせないという事もあり得る。この問題かどうかを 見るためには、smb.conf中の[tmp]セクションに user = username行を追加する。ここで、 usernameは、入力するパスワードに対応するものである。 もしもこれで修正されるならば、ユーザー名マッピングオプションが必要となるかもしれない。

    クライアントが暗号化パスワードのみを送り、smb.conf中で encrypt passwords = noが設定されているという 場合もあるかもしれない。これを修正するためには、設定を`yes'に変更する。

  10. ワークグループの名前がtestgroupである、SambaサーバーとWindows PCが 属している所でnmblookup -M testgroupを 実行する。そのワークグループにおけるマスターブラウザーのIPアドレスが表示されるはずである。

    そうでない場合、選択プロセスが失敗している。ただ単に遅れているのかもしれないので しばらく待ち、再度試してみる。それでも失敗した場合、smb.conf中にある ブラウジングオプションを調べてみる。起動時に選択(election)が行われるように、 preferred master = yesを書いておくこと。

  11. ファイルマネージャから、サーバーをブラウジングしてみる。ローカルワークグループ (かsmb.conf中で指定したもの)のブラウズリスト中にSambaサーバーが現れるはずである。 サーバーの名前をダブルクリックし、共有の一覧が得られるべきである。もしも、 invalid passwordというエラーが表示されたならば、おそらくWindows NTが 動作していて、それがユーザーレベルのセキュリティモードで動作していて暗号化パスワードを 扱えない状態になっていてサーバーのブラウジングを拒否している。この場合、 security = serverpassword server = Windows_NT_Machineのどちらかを smb.confファイル中に設定するか、encrypt passwordsyesに設定するようにする。

Chapter 39. Sambaの問題の調査と解決方法

Gerald (Jerry) Carter

Samba Team

Jelmer R. Vernooij

The Samba Team

David Bannon

Samba Team

Dan Shearer

Samba Team

8 Apr 2003

メーリングリスト、RFCやドキュメントのような形で、数多くの情報源が存在している。Sambaの 配布物に由来するドキュメントには、ブラウジングのような一般的なSMBのトピックについての 良い説明が含まれている。

診断ツール

SMBネットワーキングにおいて、特定の問題について、何が原因かと言うことが、簡単に 分からないことがよくある。Sambaそれ自身はむしろ役立つ情報を提供するが、いくつかの 例では、snifferを使った方がよいかもしれない。snifferは LANをモニターし、そこに送信されているデータを解析し、画面上に表示するプログラムである。

Sambaそれ自身によるデバッグ

問題をデバッグするための最も良い診断ツールの1つは、Sambaそれ自身である。動作するときの、 debug levelを、smbdnmbd両方に指定する、 -d オプションが使える。smbd, nmbdsmb.confの マニュアルページに、デバッギングオプションに関連するより詳細な情報があるので参照すること。 debug level(log level)は1(既定値)から10までを指定できる(100はパスワードデバッグ用)。

別の、デバッギングに便利な方法は、gcc -g フラグ付きでSambaをコンパイル することである。これは、バイナリ中にデバッグ情報を埋め込み、動作中の smbd/nmbdプロセスにgdbがアタッチできるようにする。 NTワークステーション向けに、あるsmbdプロセスにgdbを アタッチするためには、最初にワークステーションとの接続を確立する。 LsaEnumTrustedDomainsを生成するのに、ctrl-alt-deleteを 押し、ドメインログオン画面を表示すれば(少なくとも、最初にドメインに参加しておく) 十分である。その後、ワークステーションは開いているコネクションを維持し、smbdプロセスが 走り出す(短い、smbdのアイドルタイムアウトを設定していないと仮定する)。 ctrl-alt-deleteを押してからパスワードを実際に入力するまでの間に、 gdbをアタッチでき、そのあと継続できる。

調べてみる価値のある便利なSambaのコマンドのいくつかは以下の通り:

$ testparm | more
$ smbclient -L //{サーバーのnetbios名}

Tcpdump

TcpdumpはSMBをサポートした最初の UNIX上でのsnifferである。これはコマンドラインユーティリティで、現在、そのSMB サポートは、etherealtetherealよりは 若干遅れている。

Ethereal

Etherealは、GUIのsnifferで、UNIX(Gtk) とWindows両方で使える。EtherealのSMBサポートはとても良い。etherealの 使用法の詳細は、良くできているEthereal User Guideを読むこと。

Figure 39.1. キャプチャの開始

キャプチャの開始

ポート137,138,139,445をリッスン。例えば、キャプチャの開始 画面であるように、port 137, port 138,port 139,か port 445を フィルタとして使う。

tetherealという名前のコンソールバージョンのecherealもある。

Figure 39.2. Etherealメインデータウィンドウ

Etherealメインデータウィンドウ

Windowsのネットワークモニター

Microsoft Windows NT上での同等品は、ネットワークモニター(Netmonとして知られる)が、 Microsoft Developer Network CD、Windows NTサーバーインストールCDとSMSのCD中ににある。 SMSに同梱されているnetmonは任意の2つのコンピュータ間のパケットをダンプできる(すなわち、 ネットワークインタフェースをpromiscuousモードにする)。NTサーバーインストールCDに同梱 されているものは、ローカルのNTマシンに直接来るネットワークトラフィックとローカルな サブネットのブロードキャストのみモニターできる。etherealはnetmon形式のファイルを読み書き 出来る事に注意。

NTワークステーション上へのネットワークモニターのインストール

NTワークステーション上へのインストールには、多くの手順が必要である。以下は、 Microsoft Windows Workstation 4.0上にMicrosoft Windows NT Server 4.0から持ってきた Netmon V4.00.349をインストールする手順である。この手順はNetmonの、他の Windows NTバージョンからのものと同等である。Microsoft Windows NT Server 4.0 インストールCDとWorkstation 4.0のインストールCDの両方が必要である。

最初に、以下のようにして、NTサーバー上にネットワークモニターツールとエージェント をインストールする必要がある:

  • スタート->設定->コントロールパネル-> ネットワーク->サービス->追加 を表示する。

  • ネットワークモニターツールとエージェントを選択し、OKを クリックする。

  • ネットワークコントロールパネル上のOKをクリックする。

  • 要求されたならば、Microsoft NT Server 4.0のインストールCDを挿入する。

この時点で、Netmonファイルは%SYSTEMROOT%\System32\netmon\*.*に 存在すべきである。Netmonがパケットダンプを解析するために必要なDLLを含む parsers\と、captures\という2つのサブ ディレクトリも同様に存在する。

NT ワークステーション上にNetmonをインストールするためには、ワークステーションインストール CDかr、ネットワークモニターエージェントを最初にインストールする必要がある。

  • スタート->設定-> コントロールパネル->ネットワーク-> サービス->追加を表示する。

  • ネットワークモニターエージェントを選択し、 OKをクリックする。

  • ネットワークコントロールパネル上のOKを クリックする。

  • 要求されたならば、Windows NT Workstation 4.0インストールCDを挿入する。

そうすると、ワークステーション上の%SYSTEMROOT%\System32\netmonに、 NTサーバー上の%SYSTEMROOT%\System32\netmonからファイルをコピーし、 使用しているサイトに適切と見なされるアクセス許可を設定する。NetmonをNTマシン上で 動作させるには、管理者権限が必要である。

Windows 9x/Meへのネットワークモニターのインストール

NetmonをWindows 9x/Meにインストールするためには、Windows 9x/Me CD (\admin\nettools\netmon)からネットワークモニターエージェントを インストールする。どのようにこれを行うかについて情報が必要であれば、CD上のNetmon ドライバーファイルと一緒にreadmeファイルが用意されている。Netmonインストール先から ファイルをコピーする。

参考となる外部情報(URL)

メーリングリストにからの助言

Sambaに関連した数多くのメーリングリストがある。 http://samba.orgに移動し、 最も近いミラーサーバーを選択し、Supportをクリックする。次に、 Samba-related mailing listsをクリックする。

Samba TNGに関連する質問は、 http://www.samba-tng.org/にある。 メインストリームのSambaメーリングリストには、Samba-TNGに関連する質問を投稿しない こと。

メーリングリストのどれかに投稿したいのであれば、以下のガイドラインをよく読んでほしい:

  • いつも覚えておいてほしいのは、開発者はボランティアであるということである。 ある時点までに特定の機能を作る事について、開発者はお金をもらっているわけでも、 保証しているわけでもない。どの予定も希望的観測であり、それ以上の ものではない。

  • 常時、どのバージョンのSambaを使っていて、それが動いているOSが何かと言うことを 説明すること。使用しているsmb.confの適切なセクションを、少なくともPDCサポートに 影響する[global]中のオプションは提示すること。

  • バージョンについては、もしもCVS(訳注:現在はgit)経由でSambaを 入手したならば、最後にチェックアウトした日付を提示すること。

  • 質問を明確に、手短にするよう心がけること。とても長い、複雑な 質問は、それが完全に読まれる前に捨てられてしまう!HTMLエンコードして投稿しないこと。 メーリングリストを購読しているほとんどの人は、それを読まないで捨ててしまう。

  • もしも、不在時に、ただいま留守にしております というような気の利いたメッセージを返しているのであれば、メーリングリストに 返信しないように設定すること。メーリングリストへの自動応答は、このような ネット上での好まれない対応に応対しなければならない、何千もの人々をいらつかせて しまう。

  • クロスポストしないこと。どのメーリングリストが最適かを調べて投稿し、何が 起きたかを確かめてみること。samba-ntdomとsamba-technical両方に投稿しないこと。 多くの人は、1つ以上のメーリングリストに参加していて、2回以上同じ記事を 見るといらだってくる。他のメーリングリストで、記事を取り扱った方がよいと 考えている誰かは、しばしばその投稿記事を転送してくれている。

  • おおよそ20でログレベルが設定されて記録されたログファイルを 部分的に含めても良い。ログ全体を送ってはならないが、 エラーメッセージが分かるためのひとまとまりの部分ならばよい。

  • もしも、完全なNetmonトレース(開始からエラー時点まで)が あるならば、同じように*.CAPファイルを投稿しても良いだろう。

  • メールにドキュメントを添付する前に熟考すること。投稿記事 本体中に適切な部分を貼り付けることを考えること。Sambaメーリングリストは とても多くの人に配信している。使用しているsmb.confのコピーが、すべての 人に必要だろうか?

メーリングリストからの脱退方法

Sambaメーリングリストから脱退するには、参加申し込みをしたと同じページ、 http://lists.samba.org の最も近いミラーに行き、Supportをクリックし、 Samba-related mailing listsをクリックする。

脱退方法についてメーリングリストに投稿しないこと。(何らかの理由で処理がうまく 行かなかった場合を除いて)上記のアドレスのみを参照すべきである。

Chapter 40. バグの報告

John H. Terpstra

Samba Team

Jelmer R. Vernooij

The Samba Team

Andrew Tridgell

Samba Team

27 June 1997

概要

SambaのBugzilla機能を使って バグを報告し、また、報告を投稿する前に、この章を読んでほしい。また、 もしも、リリース間での変更があるかと、同様にある時点でバグ報告機能を 変更したかもしれないことを調べてほしい。

自分自身で出来るだけバグを追い詰めてほしい。Sambaは、ボランティアで時間、技術、労力を 提供している自主的なグループによって保守されている。問い合わせに対応しきれないメールを 受け取っているので、早く修正できる形で、開発者にわかりやすいバグ報告を 送ってもらえると、返事とバグ修正の機会が大きくなる。

もしも、comp.protocols.smbニュースグループか、メーリングリストに投稿した 場合、それを開発者が読むと思ってはいけない。もしも、問題がバグではなくて、 設定の問題だと推測したならば、手助けできる人がたくさんいるSambaメーリング リストに送った方がよい。

http://samba.org/samba/の、 Samba Webページ上で便利にアクセスできる、最近のメーリングリストアーカイブを見る事を 好むかもしれない。

一般的な情報

バグレポートを投稿する前に、エラーに対する設定を確認する。設定を間違えていると いう明確なメッセージをログファイルの中でサポートする。正しい文法になっているか、 設定ファイルをtestparmでチェックする。

Sambaチェックリストを見てみたか?これはとても 重要である。

もしも、バグレポートの中にログファイルを含めるならば、その時点でクライアント上で 何をしたかということを正確に、その結果が何であるかを正確に注釈を付けること。

デバッグレベル

もしも、バグが、サーバーとしてSambaの正しくない動作を何かしているならば (例えばファイルのオープンを断るなど)、ログファイルがとても便利に使えるだろう。 現象にもよるが、ログレベル3から10の間が、適切に問題を表示するかもしれない。 より大きなレベルはより詳細な結果が得られるが、とてもたくさんのディスクを 消費する。

debug levelを設定するには、smb.conf中でlog levelを指定する。 また、特定のマシンだけログレベルを大きくし、各マシン毎に分離すると便利である。 これを行うには、smb.conf中に以下の行を追加する:

log level = 10
log file = /usr/local/samba/lib/log.%m
include = /usr/local/samba/lib/smb.conf.%m

かつ、希望するコマンドを含むsmb.confを、新たに /usr/local/samba/lib/smb.conf.machineとして 作成する。例えば、log levelは便利に使えるだろう。 これはまた、異なったセキュリティシステム、プロトコルレベルなどを1つのマシン上で 体験することもできる。

smb.confのエントリlog levelは、古いバージョンのSambaで 使われていたパラメーターdebuglevelと同義語であり、 smb.confファイルの下位互換性のためにそのまま残っている。

log levelの値を大きくすると、きわめて大量のデバッグ情報を 記録することになる。多くのデバッグ作業において、この値を3より 大きくする必要はないだろう。値を10にすると、ほとんどすべての バグが記録されるが、大きなログデータ領域を準備する必要がある。

デバッグ固有の操作

Samba-3.xはすべての操作に対する詳細なログが書かれるログファイル中で、 必要のない項目を外して特定の機能コンポーネントだけをデバッグ(ロギング)する ことができる。これを行うための設定例は以下の通り:

log level = 0 tdb:3 passdb:5 auth:4 vfs:2
max log size = 0
log file = /var/log/samba/%U.%m.log

これは、上記で示されている値毎に各機能単位にデバッグクラス(ログレベル)を 渡すために詳細なレベルを拡張している。log level0という最初の値は、特定の機能単位に対するデバッグクラスを 除き、すべての不必要なデバッグ出力を抑止する。 デバッグ単位の表は、Sambaが処理している各SMB 操作をとても正確に分析するのに使うことが出来るかもしれない。

Table 40.1. デバッグ単位

機能名機能名
allpassdb
tdbsam
printdriversauth
lanmanwinbind
smbvfs
rpc_parseidmap
rpc_srvquota
rpc_cliacls

内部エラー

もしも、ログファイル中に、INTERNAL ERRORという メッセージがあったら、これはSambaが動作中に予期しないシグナルを受け取ったことを意味する。 これはおそらくセグメンテーションフォルトで、多くの場合Sambaのバグである(ハードウェア の故障かシステムソフトゥエアのバグを除く)。

メッセージがsmbd由来であれば、smbが受け取った最後のSMBメッセージを詳細に説明する メッセージがおそらくあるだろう。この情報は、問題を解析するのにしばしば便利であるので、 バグレポートの中に一緒に入れてほしい。

もしも可能ならば、どのように問題を再現するかについての詳細も説明してほしい。 適度に詳細を記述してほしい。

Sambaログファイルが保存されているディレクトリのcorefilesサブ ディレクトリにコアファイルが存在する場合があるかもしれない。このファイルは、 バグを追跡するのに最も便利なものである。これを利用するには以下のようにする:

$ gdb smbd core

smbdとcoreに対する適切なパスを追加すると、gdbはそれらを扱えることが出来る。 もしもgdbを用意していないならば、dbxを試してみること。 デバッガー内でwhereコマンドを使うと、どこで問題が発生したかの トレースが得られる。これをレポートに含める。

もしも、何らかのアセンブラ言語について知っているならば、どこで問題が発生したか を(もしもそれがライブラリルーチン内ならば、それを呼び出しているルーチンを 逆アセンブルする)、disassで逆アセンブルし、そのコードの周辺を 調べることで、正確にどこで現象が起きたかを調べてみる。アセンブラ言語について 知らなくても、逆アセンブル結果をバグレポートに含めることは解析に役に立つ。

稼働中のプロセスへのアタッチ

不幸にも、いくつかのUNIX(特に最近のLinuxカーネルのいくつか)は、タスクがUIDを 変えたとき(smbdはしばしばこれを行う)コアファイルの作成を抑制する。 このような種類のシステムでデバッグするには、まず、 smbstatusPIDを得、 次に、gdb smbd PID を使って、稼働中のプロセスにアタッチしてみる。次に、c を使って処理を続行し、クライアントを使ってコアダンプを起こさせる。 デバッガーはフォルトを受け取り、どこでそれが起こったかを表示する。

時には、Samba Teamに問題を修正してもらうために、クラッシュした操作からの十分な情報を キャプチャすることを可能とさせるために、デバッグシンボルを持つSambaバイナリファイルを 構築する必要がある。

-gオプションを付けてコンパイルすると、シンボルが埋め込まれる。 以下の行を、smb.confファイルのグローバルセクションに追加する:

panic action = "/bin/sleep 90000"

これにより任意のパニックをキャッチできる。もしも、smbdが 固まってしまったように見えたら、sleepしているプロセスを捜す。もしも存在せず、 空回りしてるように見えたら、空回りしているように見えるプロセスのPIDを調べ、 以下のように入力する:

root#  gdb /usr/local/samba/sbin/smbd

次に、attach `pid'(pidは空回りしているプロセス)を行い、次に コールパス中のどこにsmbdがいるかを見るためにbtを入力して バックトレースを取る。

パッチ

最も良い形のバグレポートは、修正を含むものである!もしも、パッチを送って もらえるのであれば、使用しているdiffがサポートしているのであれば、 diff -uで差分を取ってほしい。そうでない場合、 diff -c4を使ってほしい。オリジナルのソースに対する diffを取るようにすることと、正確にどのバージョンを使用しているかを知らせて ほしい。

Chapter 41. TDB ファイルの管理

John H. Terpstra

Samba Team

2008年5月28日

特徴と利点

Samba は軽量なデータベース Trivial Database (tdb) を利用する。一時的や 永続的なデータをそこに格納する。 一部の tdb ファイルは Samba を再起動する前に破棄できるが、その他は Samba の設定や振る舞いにとって重要な情報を格納するために利用される。 Samba のインストールについてよりよい管理を摸索している 管理者の助けとなるように下記の情報は提供される。

OSとともに商用ディストリビューションにSambaをパッケージする場合とアプライアン スの場合、十分に注意するとよいだろう。 tdb ファイルは破損することがあるため定 期的にバックアップするべきである。適切なタイミングはシステムシャットダウン(バ ックアップ)とスタートアップ(バックアップからのレストア)である。

Table 41.1. Samba の Trivial Database ファイル

ファイル名要保存説明
account_policy.tdb

たとえばパスワード有効期限などのようなNT アカウントポリシー 設定など。

brlock.tdb不要

バイトレンジロック。

browse.dat不要

ブラウズリスト - 自動的に再構築される。

connections.tdb不要

各共有への接続。最大接続数までに制限するためなどに利用される。

gencache.tdb不要

汎用のキャッシュ用データベース。

group_mapping.tdb

グループマッピング情報を格納する。LDAP バックエンドを利用する際には使わない。

lang_en.tdb

使用する言語のエンコーディング情報を格納する。

locking.tdb不要

共有モードと oplock 情報を格納する。

login_cache.tdb不要

パスワードの失敗のログを保管する。

messages.tdb不要

Samba 内部メッセージングの追跡に使用する。

netsamlogon_cache.tdb

ドメインメンバーからのリクエストnet_samlogon() からのユーザー net_info_3 構造体のキャッシュ。

ntdrivers.tdb

インストールされたプリンタードライバー情報を格納する。

ntforms.tdb

インストールされたプリンターのフォーム情報を格納する。

ntprinters.tdb

インストールされたプリンター情報を格納する。

printing ディレクトリ

キャッシュされた lpq 出力のプリントキュー毎の tdb ファイルを含むディレクトリ。

registry.tdb

Windows レジストリスケルトン(regedit.exeを経由して接続)。

sessionid.tdb不要

utmp = yes機能をサポートするためのセッション情 報。

share_info.tdb

共有レベルの ACL 構成設定を格納する。ACLの既定値は 全員 - フルコントロールである。

unexpected.tdb不要

発信リクエストとは異なるポートへ返信する Windows クライアントを サポートするため予期せぬパケットのキュー。

winbindd_cache.tdb不要

Winbind のユーザーリストのキャッシュ。

winbindd_idmap.tdb

Winbind の ローカル IDMAP データベース。

wins.dat不要

wins support = yesがセットされている間だけ 利用される WINS データベース。再起動するたびに再構築または更新 される。

wins.tdb

全ての WINS データのための作業用の永続的なストレージ。smb.conf ファイルの中で wins support = yes がセット されている時だけ利用される。 注意: 手動で構成されたすべての WINS エントリを保有する。手動設定は net ユーティリティを使用して行うことができる。

secrets.tdb

この tdb ファイルは内部設定を格納する、例えば machine/domain SID、 LDAPと共に使われる秘密パスワード、machine 秘密トークンなど。 これは安全な場所に格納される必須ファイルである。ベンダーはこの ファイルを様々なフォルダーに配置する。smbd -bで、 使用するシステムでの配置を確認すること。

schannel_store.tdb

SMB 署名と共に利用されるセキュア channel アクセストークン情報を格 納する。

passdb.tdb

tdbsamパスワードバックエンドを利用する場合、Samba の SAM アカウン ト情報を格納する。


TDB ファイルの管理

tdbbackup ユーティリティは samba の tdb ファイルをバック アップすることに使うツールである。 Samba の起動の前または正常稼働中に tdb ファイルの完全性を診断することにも 利用することができる。 ファイルにダメージを見つけると以前のバックアップを探す。ダメージを受けた tdb ファイルのバックアップファイルがリストアされる。 tdbbackupユーティリティは、いつでも安全に実行できる。 Samba が実行中であっても、どんな時でも tdb ファイルの完全性が確認できるよう に設計された。

Samba サーバー上では Samba のスタートアップスクリプトの一部分としてすべての tdb ファ イルをバックアップすることが推奨される。 以下のコマンドシンタックスが利用できる:

myserver# > cd /var/lib/samba
myserver@ > tdbbackup *.tdb

既定の拡張子は.bakである。 tdbbackup -s 'new_extension' *.tdbとスタートアップスクリ プトで実行することで他の拡張子を指定することができる。

Part VI. Reference Section

Table of Contents

42. Sambaのコンパイル方法
Subversion経由でのSambaソースコードへのアクセス
概要
samba.orgへのSubversionアクセス
rsyncとftp経由によるSambaソースへのアクセス
SambaのPGP署名の検証
バイナリの構築
Active Directoryサポートを伴うSambaのコンパイル
smbd nmbdwinbinddの起動
inetd.confからの起動
もう一つの方法: smbdをデーモンとして起動する
43. 移植性
HPUX
SCO UNIX
DNIX
Red Hat Linux
AIX: シーケンシャル先読み
Solaris
ロックの改善
Solaris9上の Winbind
44. Samba と他の CIFS クライアント
Macintoshクライアント
OS2 Client
OS/2 Warp Connect または OS/2 Warp 4の設定
他のOS/2バージョンでの設定
OS/2クライアント用のプリンタードライバーのダウンロード
Windows for Workgroups
Microsoftからの最新版 TCP/IPスタック
パスワード変更後に.pwlファイルの削除
Windows for Workgroupsにおけるパスワードの取り扱い方法の設定
パスワードにおける大文字小文字の区別
既定値のプロトコルとしてTCP/IPの使用
処理速度の改善
Windows 95/98
処理速度の改善
Windows 2000 サービスパック 2
Windows NT 3.1
45. Sambaパフォーマンスチューニング
比較
ソケットオプション
読み取りサイズ
Max Xmit
ログレベル
Read Raw
Write Raw
ログインが遅い
クライアントのチューニング
Linuxカーネルを変更した事によるSambaパフォーマンス問題
壊れたtdbファイル
Sambaのパフォーマンスがとても悪い
46. LDAPとトランスポート層のセキュリティ
概要
設定
認証局の作成
サーバー証明書の生成
証明書のインストール
評価
トラブルシューティング
47. Samba サポート
無償サポート
商用サポート
48. DNSとDHCP設定ガイド
機能と利便性
設定例
ダイナミックDNS
DHCPサーバー

Chapter 42. Sambaのコンパイル方法

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Andrew Tridgell

Samba Team

22 May 2001

18 March 2003

June 2005

Samba Web siteからSambaソースファイルを 入手できる。開発バージョンのSambaは、Subversionかrsyncを使って 入手できる(訳注:現在はgit)。

Subversion経由でのSambaソースコードへのアクセス

概要

(訳注:この節は現在古くなっている) Sambaは公開された環境で開発されている。開発者はSubversionを使って、新しい ソースコードをcheckin(commitとしても知られる) する。Sambaの種々のSubversionブランチはこの章で説明される手順で匿名 Subversion経由でアクセスできる。

この章は、Samba Webサイトにある手順を変更したものである。

samba.orgへのSubversionアクセス

samba.orgのマシンはSamba,rsync,distcc, ccacheとjitterbugを含むいくつかのパッケージの ソースコードへアクセスできるSubversionリポジトリに自由にアクセスできるサーバーを動かして いる。このホスト上のSubversionサーバーにアクセスするには2つの方法がある。

ViewCVS経由のアクセス

お好みのWWWブラウザー経由でソースコードにアクセスできる。これにより、リポジトリの 個別のファイルの内容、リビジョン履歴、特定のファイルに対するコミットログに アクセスできる。リポジトリ上の任意の2つのバージョン間での差分表示を得ることもできる。

http://viewcvs.samba.org/ を使うこと。

Subversion経由でのアクセス

通常のSubversionクライアント経由でソースコードにアクセスすることもできる。そうすると、 リポジトリに対してより多くの制御ができ、完全なソースコードツリーをチェックアウトでき、 通常のSubversionコマンド経由で最新版に追従できる。もしもあなたが開発者であれば、 これは好ましいアクセス方法であり、通常のブラウザーは好ましくない。

SubversionでSambaのソースをダウンロードできるように、するためには、Subversion クライアントが必要である。使用しているディストリビューションに入っているかもしれないし、 そうでなければ、 http://subversion.tigris.org/ からソースをダウンロードできる。

匿名Subversion経由でアクセスするためには、以下のステップを使う。

Procedure 42.1. Subversionを使うSambaの検索

  1. 最新のSubversionのコピーをインストールする。必要なものすべては、 Subversionクライアントバイナリのコピーである。

  2. 以下のコマンドを動かす

    	svn co svn://svnanon.samba.org/samba/trunk samba.
    	

    これは、最新のSambaソースコード(通常次のメジャーリリースになるブランチ)を含む、 sambaと呼ばれるディレクトリを作成する。これは現在 3.1開発ツリーに連動している。

    trunk以外のSubversionブランチは、チェックアウトするときに、branches/BRANCH_NAME というURLによって得られる。ブランチ名の一覧は、Samba Webサイトの Developmentのページから得られる。最新の3.0リリースコードを得たい という共通の要求がある。これは以下のコマンドを使うことによってできる:

    	svn co svn://svnanon.samba.org/samba/branches/SAMBA_3_0 samba_3.
    	

  3. 最新のコードの変更にマージしたい場合は、Sambaディレクトリ内で以下のコマンドを使う:

    	svn update
    	

rsyncとftp経由によるSambaソースへのアクセス

pserver.samba.orgも、 pserver というSambaのサイトの所から、Subversionツリーのほとんどの部分のパックされてない コピーをエクスポートでき、また、 rsync という、Sambaの匿名rsyncサーバー経由でも同じようにできる。ftpよりはrsyncの方が、 rsyncはデータを圧縮転送できるのでお勧めであり、また、抜けているデータのみを 転送出来るという、部分更新が出来て、オーバーヘッドが少ないという点でもお勧めで ある。rsyncについてのより詳細な情報は、 the rsync home page を参照のこと。

アンパックされたツリーの欠点は、Subversionのように、ローカルな変更の自動マージを サポートしないと言うことである。rsyncによるアクセスは、 初期導入に最も便利である。

SambaのPGP署名の検証

インストールする前に、任意のソースファイルのPGP署名を検証することを強く推奨する。 ミラーサイトからダウンロードしていないとしても、PGP署名の検証は、標準的な習慣と すべきである。多くの人は現在PGPの代替としてGNU GPGツールを使っている。GPGは PGPの代わりとして使える。

そんなわけで、以下のようにしてファイルをダウンロードする:

$ wget http://us1.samba.org/samba/ftp/samba-3.0.20.tar.asc
$ wget http://us1.samba.org/samba/ftp/samba-pubkey.asc

最初のファイルはSambaソースファイルのPGP署名である。もう1つはSambaの公開PGPキーそれ自身 である。以下のようにしてPGPキーをインポートする:

$ gpg --import samba-pubkey.asc

そして、Sambaソースコードの正当性を以下のようにして検査する:

$ gzip -d samba-3.0.20.tar.gz
$ gpg --verify samba-3.0.20.tar.asc

もしも、Good signature from Samba Distribution Verification Key..., というようなメッセージが表示されたならば、すべて問題はない。信頼性の関係についての 警告は無視して良い。以下のような表示が出たら問題である:

gpg: BAD signature from Samba Distribution Verification Key

バイナリの構築

tar形式のソースコードを展開後、次のステップは、使用しているOSプラットフォームに Sambaが適合するように、設定(configuration)を行う。もしもソースディレクトリが configureスクリプトを含んでいないのであれば、以降を行う ために、構築作業が必要である。configureスクリプトの構築はautoconfの正しい バージョンが必要である。ど必要とされるバージョンのautoconfがある場合、 以下を実行して生成されるスクリプトでconfigureスクリプトを生成できる。

root#  cd samba-3.0.20/source
root#  ./autogen.sh

バイナリを構築するためには、ソースディレクトリ中で、 ./configureプログラムを動かす。これは、使用している OS用にSambaを自動的に設定する。もしも特別な要求があるならば、最初に 以下のように起動しても良いだろう:

root# ./configure --help

これは、どのような特別なオプションが有効に出来るかの一覧を表示する。その後、 必要な任意の引数を付けて、./configureを実行する:

root# ./configure [... arguments ...]

以下を実行して、バイナリを生成する:

root#  make

一度コンパイルが成功すると、以下のようなコマンドを実行することで、 バイナリとマニュアルページをインストールできる:

root#  make install

ある人は、バイナリファイルとマニュアルページを分離してインストールすることを 好んでいる。もしもそうしたいのであれば、以下を実行することで、バイナリファイルを インストールできる:

root#  make installbin

マニュアルページは以下のコマンドでインストールできる:

root#  make installman

もしも、以前のバージョンからアップグレードするのであれば、古いバージョンの バイナリは.oldという拡張子を付けて改名される。 以下を実行することで、前のバージョンに戻ることが出来る:

root#  make revert

上記を見て分かるとおり、Sambaの構築とインストールは災難を引き起こす事はない!

Active Directoryサポートを伴うSambaのコンパイル

ADSをサポートするようにSambaをコンパイルするためには、以下のものをシステムに インストールする必要がある:

  • MIT あるいは Heimdal Kerberos開発ライブラリ (ソース、あるいはパッケージからのどちらかからインストール)

  • OpenLDAP開発ライブラリ。

もしも、使用しているKerberosライブラリが標準でない位置にあるならば、 以下のconfigure オプションを追加するのを忘れないこと。 --with-krb5=DIR.

configrue を実行後、生成されたinclude/config.hが、 以下のような行を含んでいるかを確認する:

#define HAVE_KRB5 1
#define HAVE_LDAP 1

もしもそうでない場合、configureはインストールされているKRB5ライブラリか LDAPライブラリを見つけるのに失敗している。なぜそうなったかを config.logをみて確認して修正する。

Debian用の、必要とされるパッケージのインストール

Debianでは、以下のパッケージのインストールが必要である:

  • libkrb5-dev

  • krb5-user

Red Hat Linux用の、必要とされるパッケージのインストール

Red Hat Linuxでは、少なくとも:

  • krb5-workstation (for kinit)

  • krb5-libs (for linking with)

  • krb5-devel (because you are compiling from source)

を標準開発環境に追加する必要があることを意味する。

もしも、使用しているシステム上にこれらのファイルがインストールされて いないならば、どこにそれらがあるかをインストールCDでチェックすべきであり、 使用しているツールにあわせてインストールする。もしもどのツールが使っている かが分からない場合は、Red Hat Linuxのドキュメントを参照すること。

SuSE Linuxパッケージでの要求

SuSE Linuxはバイナリパッケージを構築する事が出来るのに必要とされるだろうHeimdal パッケージをインストールする。使用しているシステム上に、開発ライブラリが インストールされているかを調べるべきである。

SuSE Linux のSamba RPMはKerberosをサポートする。SuSE Linux固有の設定に関連する 情報は、使用しているSuSE Linuxシステムのドキュメントを参照して欲しい。さらに、 SuSEは使用可能な機能を最大限提供するように、Sambaパッケージのメンテナンスをとても 頻繁に行っている。使用可能な、SuSEが提供しているパッケージの使用について考慮 すべきである。

smbd nmbdwinbinddの起動

smbd, winbinddnmbdの起動を、デーモンかinetd からの起動のどちらかにするかを選ぶ必要がある。両方同時に行ってはいけない! inetdによって必要時に起動するように、 inetd.confにそれらを記述するか、コマンドラインか、 /etc/rc.localに記述することで、デーモンとして起動できる。 コマンドラインオプションの詳細についてはマニュアルを参照のこと。どのユーザーで Sambaを起動する必要があることについての部分を注意深く読むこと。ほとんどの場合、 rootで起動する必要がある。

推奨される、デーモンによる方法を使ってsmbdnmbdを開始することの利点は、 最初の接続要求時に、若干より迅速に反応すると言うことである。

inetd.confからの起動

Note

以下は、もしもNIS、NIS+あるいはLDAPが分散されたサービスマップを 使っている場合は異なる。

/etc/servicesを見る。ポート139/tcpに何が定義されて いるだろうか?もしも何も定義されていないならば、以下のように行を追加する:

netbios-ssn     139/tcp

137/udpに対して、以下のようなエントリを同様に追加する:

netbios-ns	137/udp

次に、/etc/inetd.confを編集し、以下のように2行追加する:

netbios-ssn stream tcp nowait root /usr/local/samba/sbin/smbd smbd 
netbios-ns dgram udp wait root /usr/local/samba/sbin/nmbd nmbd 

/etc/inetd.confの正しい文法はUNIX毎に異なる。ガイドの inetd.conf中の他の項目を参照すること。

いくつかのディストリビューションはinetdの代わりにxinetdを使っている。 設定情報についてはxinetdのマニュアルを参照すること。

Note

いくつかのUNIXではすでに/etc/services中に netbios_ns(下線に注意)のようなエントリが存在している。整合性を取るために、 /etc/services/etc/inetd.confを 編集する必要がある。

Note

多くのシステムでは、使用しているネットワークインタフェースのIPアドレスと ネットマスクを指定するために、 smb.conf中で interfacesオプションを使う必要があるかもしれない。 使用しているネットワークでの、ブロードキャストが何であるかを知らないのであれば、 rootでifconfigを起動する。nmbdは実行時にそれを 決めようとするが、ある種のUNIXでは失敗する。

Warning

多くのUNIXは、inetd.conf中で、コマンドライン上におおよそ 5つのパラメーターのみを受け付ける。これは、オプションと引数間でスペースが使えない という事を意味するので、そうしたくなければ、スクリプトを使い、 inetd経由でスクリプトを起動する。

おそらく以下のようにHUPを送ることで、inetdを 再起動する:

root# killall -HUP inetd

もう一つの方法: smbdをデーモンとして起動する

サービスをデーモンとして起動するには、startsmbという、 下記のようなスクリプトを作成すべきである。

#!/bin/sh
/usr/local/samba/sbin/smbd -D
/usr/local/samba/sbin/winbindd -D
/usr/local/samba/sbin/nmbd -D

chmod +x startsmbでこれを実行可能にする。

手動か、/etc/rc.localからstartsmbを 実行することが出来る。

これを停止するには、プロセスnmbdsmbdにkillシグナルを送る。

Note

もしも、SVR4形式のinitシステムを使っているならば、そのシステムにSambaを 適合するように、examples/svr4-startupスクリプトを みてやってもよいだろう。

Red Hat LinuxでのSambaの起動

Red Hat Linuxは標準的なインストール状態ではすべてのSambaコンポーネントが 常時含まれるわけではない。そのためRed Hat Linuxのバージョンによっては、 インストールCDROMメディアにあったとしても、winbindユーティリティをインストール しない。システム上にwinbinddがあるかをチェックすること:

root#  ls /usr/sbin/winbindd
/usr/sbin/winbindd

これは、適切なRPMパッケージがインストールされていることを意味する。以下の応答は、 インストールされていない場合である:

/bin/ls: /usr/sbin/winbind: No such file or directory

この場合、winbinddを使うつもりであるならば、インストールが 必要である。samba-winbind RPMをCDROMインストールメディアから捜し、以下の Red Hatガイドラインに従ってインストールする。

Sambaの起動の手順の概要を以下で説明する。Sambaを起動する前に、Sambaの smb.confをきちんと設定しておくこと。設定後、以下のようにしてSambaを 起動する:

root#  service smb start
root#  service winbind start

このステップで nmbd, smbdwinbinddを起動する。

システムが再起動したときに、自動的にこれらのサービスが再起動するようにするには、 以下を実行する:

root#  chkconfig smb on
root#  chkconfig winbind on

Sambaは毎再帰同時に自動的に起動するようになる。

Novell SUSE LinuxにおけるSambaの起動

Novell SuSE Linux 製品は自動的にすべての基本的なSambaコンポーネントを既定値の インストール作業でインストールする。smb.confファイルを設定後、以下を行う 事でSambaを起動する:

root#  rcnmb start
root#  rcsmb start
root#  rcwinbind start

以下のコマンドを実行後、Sambaはシステム再起動後に自動的に起動する:

root#  chkconfig nmb on
root#  chkconfig smb on
root#  chkconfig winbind on

これで、Sambaサーバーはシステム再起動後に自動的に起動する。

Chapter 43. 移植性

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Samba は広い範囲のプラットフォームで機能する。しかし、すべてのプラットフォー ムの提供するインタフェースが常に互換性があるとは限らない。 この章は Samba のコンパイルと利用についてプラットフォームに特化した情報を含む。

HPUX

(歴史的な理由により)HPでは、補助グループの実装が非標準である。 グループファイルには/etc/group/etc/logingroupの2つがある。 システムは、UIDから番号(訳注:GIDのことか)を前者のファイルを使用して割り当てるが、 initgroups()は後者を参照する。 コツを知っている大抵のシステム管理者は、シンボリックリンク /etc/group/etc/logingroup へ張る (ここに記述することができない愚鈍な理由でハードリンクでは機能しない)。 initgroups()は、/etc/logingroupの中で所属しているグループ に不正なIDがあればエラーを出す。 ここで言う不正なIDとは [0..UID_MAX]の範囲を超えた場合 であり、HP-UX のUID_MAXは現在のところ60000である (訳注:HPのページで見る限り、現在は2147483647)。 この範囲は、-2 と 65534 を除外している。これは通常 nobodyの GIDである。

もしこの問題に遭遇した場合、initgroups()に失敗するプログラムを実行している ユーザーが、許可された範囲外の GID のグループユーザーでないことを確認すること。

このことは、HPのマニュアルページ setgroup(2)とpasswd(4)に記述されている。

HP-UXでは、gccまたはHP ANSIコンパイラを利用しなければならない。 HP-UXに付属する無償のコンパイラは ANSI に準拠していないためSambaをコンパイ ルできない。

SCO UNIX

もし古いバージョンのSCO UNIXを稼働させているのなら、Sambaを正常に 機能させるためには、TCP/IPの重要なパッチを入手する必要があるだろう。 そのパッチがないと、Sambaを利用している際に転送データが破損する。

必要とするパッチは UOD385 Connection Drivers SLSである。 SCOftp.sco.com から ディレクトリSLSの中にある、ファイル uod385a.Z と uod385a.ltr.Z が当該のものである。

ここで提供される情報は、SCO UNIXの古いバージョンを参照している。 もしより新しいSCO UNIX のバイナリが必要ならば、インストール可能なパッケージを 入手するためSCOに連絡すること。 インストールするバイナリのためプラットフォームが最新であることも、SCOで確認 しなければならない。 これは、インストール作業にてデータ破損を避けるために重要なことである。 SCO UNIX製品用にSambaをビルドする場合、 Samba のソースに大幅なパッチが 必要となるかもしれない。 SCO から直接バイナリパッケージを入手する方がとても容易である。

DNIX

DNIX は seteuid() と setegid() に問題がある。これらのルーチンはSambaが正しく 機能するために必要である。しかし、それらはいくつかの理由によりDNIX の Cライブラリ から抜け落ちている。

この理由により、Sambaはincludes.hのDNIXセクションにて、既定値でNO_EIDマクロを 定義している。この問題について、限られた方法ではなんとか機能する。しかし理想からは 程遠く、いくつかの事柄はまだ正しく機能しないだろう。

この問題を正しく解決するため、以下の2つの関数をアセンブルする必要がある。 そしてそれらをCライブラリに加えるか、Sambaにリンクすること。 以下のコードを setegid.s の中に記述する。

        .globl  _setegid
_setegid:
        moveq   #47,d0
        movl    #100,a0
        moveq   #1,d1
        movl    4(sp),a1
        trap    #9
        bccs    1$
        jmp     cerror
1$:
        clrl    d0
        rts

以下を seteuid.s の中に記述すること。

        .globl  _seteuid
_seteuid:
        moveq   #47,d0
        movl    #100,a0
        moveq   #0,d1
        movl    4(sp),a1
        trap    #9
        bccs    1$
        jmp     cerror
1$:
        clrl    d0
        rts

ファイル作成後、これを以下のようにアセンブルする。

$ as seteuid.s
$ as setegid.s

その結果、seteuid.o と setegid.o が作成される。

次に、SambaのMakefileにて、DNIXセクションの中のLIBSM行にそれらを加える。 LIBSM行は、以下のものに多少似た形になるだろう。

LIBSM = setegid.o seteuid.o -ln

次に、includes.h の DNIX セクションから

#define NO_EID

の行を削除する。

Red Hat Linux

Red Hat Linuxのいくつかのバージョンでは、既定値を指定してインストールする間に、 以下のようなエントリを /etc/hosts に追加する。

127.0.0.1 loopback "hostname"."domainname"

これは Samba にループバックインタフェースへループバックすることを引き起こす。 結果として、 Samba は他の PC と正常に通信することに失敗する。 ひいてはマスターブラウズリストの保有者とマスターブラウザー が誰なのか正常にネゴシエートすることも失敗するだろう。

修正措置: 127.0.0.1 で始まる行の中で "loopback" という語の後のエントリを削除する。

AIX: シーケンシャル先読み

シーケンシャル先読みを無効にすると、相対的に高度なマルチプログラミング (多数の smbd プロセスや他の負荷との混合)、充分でない物理メモリ、またはより遅い ディスク技術がある場合に、Sambaの効率を著しく改善できる。 これらは AIX に高いウエイト値の原因となる。 シーケンシャル先読みを無効にすることは、またシステム上の他の負荷に対して反作用 を及ぼすことがあるため、他のアプリケーションへのインパクトを評価する必要がある。

IBMによって提供される既定値の利用が推奨される。しかし多数のウエイトタイム を経験した場合、以下のコマンドで先読みを無効にすることを試すこと。

AIX 5.1 とそれ以前: vmtune -r 0

AIX 5.2 とそれ以降の jfs ファイルシステム: ioo -o minpgahead=0

AIX 5.2 とそれ以降の jfs2 ファイルシステム: ioo -o j2_minPageReadAhead=0

もし、jfsとjfs2ファイルシステムが同一ホスト上に混合する場合、単純に 双方のiooコマンドを利用する。

Solaris

ロックの改善

Solaris上でSambaを稼働させて、F_SETLKW64/fcntlにまつわる問題を経験 している人たちがいる。 ビルトインのファイルロック機構はスケーラブルではなかった。 プロセスがファイルのロックを試行するループへ入り込むまで、効率が低下するだろう。 それは、ロックを試行し、失敗し、そして再び試行する。 ロックする試みは、許可が与えられる前に失敗する。 目に見える兆候は CPU を一握りのプロセスが占有することであり、もしもそれらが 信頼されるのであれば、F_SETLKW64 のループから抜け出せなくなるだろう。

このバグを修正するために必要な最新のパッチを Sun のサポートに確認すること。 Solaris 2.6 向けのパッチリビジョンは 105181-34 、 Solaris 8 向けは 108528-19 、 Solaris 9 向けは 112233-04 である。 パッチをインストールした後、 Samba を再び構成しリビルドすることを推奨する。

この件について報告した Joe Meslovich に感謝する。

Solaris9上の Winbind

Solaris 9 のnsswitchは、Winbind NSS モジュールの利用を拒絶する。 この振る舞いは、 112960-14 というSUNによるパッチにて修正されている。

Chapter 44. Samba と他の CIFS クライアント

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Dan Shearer

Samba Team

Jim McDonough

OS/2 

5 Mar 2001

この章では、クライアント固有の情報について記述している。

Macintoshクライアント

もちろん対応している。Thursbyは、 DAVEという CIFS client/serverを提供している。これはWindows 95、Windows NT/200x/XPとSambaに対して、 互換性についてテストされている。これを書いている時点で、DAVEはバージョン 5.1である。 この製品についての情報はThursbyのWebサイトを参照してほしい。

ある種のUNIXといくつかの商用のものに対する、2つのAppleTalkの自由な実装を含む代替品が ある。これらの製品はMacintocth上で追加のサポートなしに、Macintoshユーザーにネイティブな ファイルサービスと印刷サービスを動かすことが出来る。2つの自由な実装は、 NetatalkCAPである。 SambaがMicrosoft Windows ユーザーに対してサービスを提供するのに対し、それらの パッケージははMacのユーザーにサービスを提供する。これらのパッケージ、Sambaと Linux(と他のUNIXベースのシステム)についての詳細は、 http://www.eats.com/linux_mac_win.html. を参照のこと。

Macintoshの新しいバージョン (Mac OS X) はSambaが含まれる

OS2 Client

OS/2 Warp Connect または OS/2 Warp 4の設定

基本的に以下の3つのコンポーネントが必要である:

  • The File and Print Client (IBM peer)

  • TCP/IP (Internet support)

  • The NetBIOS over TCP/IP driver (TCPBEUI)

Warpマニュアル中で説明されているblankシステム上に、ベースOSと共に 最初の2つを一緒にインストールする。もしもWarpがすでにインストールされて いるが、ネットワークサポートを使いたいならば、System Setup フォルダー中のSelective Install for Networkingオブジェクトを 使うこと。

マニュアルに書いていない、オンラインのドキュメントにもほとんど 書いていない、NetBIOS over TCP/IPを追加する。 MPTS.EXEを開始し、OKをクリックし、 Configure LAPSをクリックし、 Protocols中の IBM OS/2 NETBIOS OVER TCP/IPをクリックする。 この行は次にCurrent Configurationに移動する。 この行を選択し、Change numberをクリックし、 値を0から1に増やす。この設定を保存する。

もしも、Sambaサーバーがローカルサブネット上にない場合、 Names ListにそれらのサーバーのIP名とアドレスを 追加するか、WINSサーバー(IBMとRFCの用語ではNetBIOS Nameserver)を指定する 事も可能である。Warp Connectでは、Warp 4と同じレベルにするために、 IBM Peerに対するアップデートをダウンロードする 必要があるかもしれない。IBM OS/2 Warp Webページを参照のこと。

他のOS/2バージョンでの設定

この節では、OS/2 Warp 3(Connectでない)、OS/2 1.2、1.3、 あるいは2.xの設定について記述する。

ftp://ftp.microsoft.com/BusSys/Clients/LANMAN.OS2/にある、 OS/2用の、自由に使えるMicrosoft LAN Manager 2.2cクライアントを使うことが できる。nutshellで、OS/2 ブートパーティションのrootディレクトリ中にある \OS2VERファイルを編集し、クライアントインストールの 前に、以下の行を追加する:

		20=setup.exe
		20=netwksta.sys
		20=netvdd.sys
		

また、バグだらけなので同梱されているNE2000ドライバーを使ってはならない。 その代わりに、 ftp://ftp.cdrom.com/pub/os2/network/ndis/からNE2000かNS2000 ドライバーをダウンロードする。

OS/2クライアント用のプリンタードライバーのダウンロード

誰でもが書き込み可能な、[PRINTDRV]という 共有を作成する。そこに使用しているOS/2ドライバーファイルをコピーする。 .EA_ファイルは引き続き分離しなければならないので、 オリジナルのインストールファイルを使う必要があり、OS/2システムからの インストールされたドライバーをコピーしてはいけない。

そのプリンターに対し、NTドライバーを最初にインストールする。次に、 使用しているsmb.confに、パラメーター os2 driver map を追加する。次に、filenameで指定されるファイル中に、 以下のようにNTドライバー名をOS/2ドライバー名にマップするように記述する:

nt driver name = os2 driver name.device name, e.g.,

HP LaserJet 5L = LASERJET.HP LaserJet 5L

このファイル中にマップされた複数のドライバーを定義できる。

もしも、OS/2ドライバー名のみを指定し、デバイス名を指定しない場合、 ドライバーを最初にダウンロードするときには、実際にファイルをダウンロード するが、OS/2クライアントは、ドライバーが有効でないと表示する。2回目に ダウンロードするときには動く。これは、マッピングにデバイス名を追加する ことにより簡単に解決し、その後、最初のダウンロード要求で動くようになる。

Windows for Workgroups

Microsoftからの最新版 TCP/IPスタック

もしもWindows for Workgroupsを使うのであれば、Microsoftから最新のTCP/IPスタックを 使う。古いTCP/IPスタックにはたくさんのバグがある。

MicrosoftはそのTCP/IP 32ビットVxDドライバーの増分更新を公開している。最新のリリースは、 ftp.microsoft.comの/Softlib/MSLFILES/TCP32B.EXEにある。そこには 修正された問題について説明してあるupdate.txtがある。そこには更新された WINSOCK.DLL, TELNET.EXE, WSOCK.386, VNBT.386, WSTCP.386, TRACERT.EXE, NETSTAT.EXE,NBTSTAT.EXEファイルがある。

このパッチについての詳細情報は、 Knowledge Base article 99891 にある。

パスワード変更後に.pwlファイルの削除

Windows for Workgroupsは、パスワード管理の出来が悪い。UNIXマシンかPCのどちらかで パスワードを変更した時、最も安全にするにはWindowsディレクトリ中の.pwlファイルを 削除することである。PCはそのファイルが見つからないと警告を出すが、間もなく、 新しいパスワードが入力できるようになる。

もしもこれをしないと、新しいものを入れても、Windows for Workgroupsは古いパスワードを 記憶してそれを使うようになるかもしれない。

しばしばWindows for Workgroupsはダイアログボックス中で入力したパスワードを完全に無視する。

Windows for Workgroupsにおけるパスワードの取り扱い方法の設定

WFS 3.11ディスクセットの最後のディスク(8枚目)に、admincfg.exeという プログラムがある。これをインストールするためには、 EXPAND A:\ADMINCFG.EX_ C:\WINDOWS\ADMINCFG.EXEと入力する。 次に、Program ManagerNew経由でアイコンを 追加する。このプログラムは、どのようにWFWがパスワードを扱うか、パスワードのキャッシュを 無効にするなどを、security = user用に制御する。

パスワードにおける大文字小文字の区別

Windows for Workgroupsはサーバーに送る前にパスワードをすべて大文字にする。しかし、 UNIXのパスワードは大文字小文字を区別する。チェックするときにどの文字をSambaが大文字と して試すべきかを指定するための、password level上の smb.conf情報をチェックすること。

既定値のプロトコルとしてTCP/IPの使用

印刷キューの通知をサポートするために、Windows for Workgroups下でTCP/IPを 既定値のプロトコルとして使う事が必要である。もしもNetBEUIを既定値のままにすると、 あるシステム上では印刷キューの通知がうまくいかない。これはおそらく Windows for Workgroupsのバグであろう。

処理速度の改善

ある人によると、Windows for Workgroupsの中にあるSYSTEM.INIファイルの [MSTCP]セクション中にDefaultRcvWindowの 設定を3072にすると、速度が大幅に改善したと報告している。

実際にDefaultRcvWindowについて実験してみたら、より大きな値(16384かそれ以上)の値を使うと より処理速度が改善した。他の人は、3072より大きな値は、かえって大幅にスピードが落ちると 報告している。ある人の報告では、3072から8192間での間で、30の倍数の時にスピードが落ちる というものもあった。

Windows 95/98

Windows 95 OEM SR2を使う場合、以下のアップデートはSambaを使う時に推奨される。 処理速度の改善中で説明した変更は、アップデートを インストールした後に影響するだろう。

ここで説明しているものよりもたくさんのアップデートがある。Windows 95の特定のバージョン 用に現在用意されているアップデートについて、MicrosoftのWebサイトを参照すること。

Kernel Update: KRNLUPD.EXE
Ping Fix: PINGUPD.EXE
RPC Update: RPCRTUPD.EXE
TCP/IP Update: VIPUPD.EXE
Redirector Update: VRDRUPD.EXE

また、もしもMS Outlookを使っている場合、 OLEUPD.EXEの修正をインストールする事が望ましい。この修正は、 Outlookを終了する時に長い時間かかっていることを改善するかもしれず、ネットワーク コンピュータサービスにアクセスする時に目に見える改善がわかるかもしれない。

処理速度の改善

Windows 95 TCP/IPレジストリの設定を修正するとより良いパフォーマンスが得られる。 インターネットから入手したMTUSPEED.exeというプログラムを 使っている。自由に使えるこの手のタイプのユーティリティは数多くある。

Windows 2000 サービスパック 2

Windows 2000 SP2には数多くの不満な点があり、その1つは、Windowsドメイン中で Windows 2000 SP2クライアントに対してユーザープロファイルをホスティングするために、 Sambaサーバーを使う時にのみ現れる。これは、Sambaがドメインのメンバーであることを 仮定するが、もしもそうでない場合にたぶんおそらく現れるだろう。

Windows 2000 SP2クライアントに正しくプロファイルを提供するために(PDCとして 動作していない場合)、Sambaはローミングプロファイルを格納するファイル共有のために、 nt acl support = noを設定しなければならない。 もしもこれが行われていない場合、Windows 2000 SP2クライアントはプロファイルにアクセス 出来ないと、警告を出し(Access Denied)、その複数のコピーをディスク上に作成する (DOMAIN.user.001,DOMAIN.user.002など)。このオプションについては、smb.confの マニュアルページを参照のこと。また、nt acl support パラメーターが、Samba 2.2.2より前のリリースでは、正式にはグローバルパラメーターであった 事にも注意。

以下の例は、最低限のプロファイル共有を提供する。

Example 44.1. 最低限のプロファイル共有

[profile]
path = /export/profile
create mask = 0600
directory mask = 0700
nt acl support = no
read only = no

このバグの原因は、Windows 200x SP2クライアントが、SambaサーバーのSIDを含むプロファイルの ためのセキュリティディスクリプタをコピーする事によるものである。クライアントは、 Samba\userのSIDを比較し、DOMAIN\userに割り当てられたものと違うと理解する。そのため、 access deniedメッセージが表示される。

nt acl supportが無効になっている場合、SambaはWindows 200x クライアントに、プロファイルに対する既定値のACLを設定させる、 QuerySecurityDescriptor trans2呼び出しのレスポンスを送信する。この既定値の ACLは以下を含む:

DOMAIN\user フルコントロール>

Note

このバグはドメインユーザー用に、Sambaホスト上でアカウントを作成するために、 Winbindを使う時には起こらない。

Windows NT 3.1

もしも、Windows NT 3.1ワークステーションでルータ越しに通信をする時に 問題が起きたならば、 this\ Microsoft Knowledge Base article:を読むこと。

Chapter 45. Sambaパフォーマンスチューニング

Paul Cochrane

Dundee Limb Fitting Centre

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

比較

SamvaサーバーはクライアントとTCP通信を使用しているため、パフォーマンスを上げるには 同じプロトコルを使用しているプログラムと比べてみるべきである。最も簡単に入手できる TCPを使用したファイル転送プログラムは、FTPもしくは他のTCPベースのSMBサーバーである。

もしNTやWindows Workgroups serverに対して実験してみたいなら、クライアントかサーバーの TCP以外は無効にする必要がある。 そうしないとNetBEUIのようなまったく違うプロトコルが使われ、比較は意味がない。

通常、SambaプラットフォームがFTPと同じぐらいの理論上の転送速度で動作することが解る だろう。速度はそのシステムの環境次第だが、NFSよりかは相当早い。

何人かは、SambaとNovell、NFS又はWindows NTとの間での比較を行った。そのうちの いくつかの場合は、Sambaの動作は一番よく、ほかの場合は一番悪かった。最も 大きな要素は、Samba対他のシステムではなく、種々のシステムで使用しているハードウェアと ドライバーであると推測している。同じようなハードウェアで、Sambahaは他のシステムと、 速度の点において競合できうる。

ソケットオプション

いくつかのオプションは、SambaのようなTCPベースのサーバーのパフォーマンスに 大きな影響を与える。

Sambaが使うソケットオプションは、-Oをコマンド行に指定するか、 smb.conf ファイルに記述できる。

smb.conf のマニュアルページのsocket optionsに、 どのように記述するか、推奨は何かがが書いてある。

ソケットオプションを正しく設定すれば大きくパフォーマンスを改善できるが、 間違って設定すると同じくらいパフォーマンスが悪くなる。正しい設定は、 使用するネットワークにとても依存する。

TCP_NODELAYは多くのネットワークにおいて、単独で大きな違いを引き起こす。 多くの人々がsocket options = TCP_NODELAYを 追加することで、Sambaのreadパフォーマンスを2倍にしたと報告している。 MicrosoftのTCP/IPスタックがTCP ACKを送るのが遅いためだというのが一番良い説明だろう。

socket options = SO_RCVBUF=8192 をsmb.confの中に書き込む ことで、Sambaのループバックアダプター(IP Address 127.0.0.1)のパフォーマンスが ひどく下がるという報告がある。socket optionsを設定する前に、 サーバー上で定量的に計測することを強く推奨する。

読み取りサイズ

read sizeオプションは、ディスクのR/WとネットワークのR/Wの 同時動作に影響する。 いくつかのSMBコマンド(currently SMBwrite, SMBwriteXとSMBreadbraw)で転送されている データ量がこの値より大きかったとき、サーバーはネットワークからそのパケットを受け取る前に データを書き込む。もしくは、SMBreadrawコマンドの場合、全てのデータをディスクから 読む前にネットワークに書き込む。

この並列動作は、ディスクアクセスとネットワークアクセスがほぼ同じ速度の場合に 最も効果があり、どちらか片方がとても早い場合にはあまり効果がない。

既定値は16384である。最適値を決めるために多少試験してみたが、最適値はシステム間で非常に 大きく違うようである。65536以上の値には意味が無く、不必要にメモリを割り当ててしまう。

Max Xmit

起動時にクライアントとサーバーとの間で、ほぼすべてのコマンドサイズを制限する、 maximum transmit値の調停を行う。 sambaが調停する最大値をsmb.confmax xmit オプションを使うことで設定できる。 これはSambaが受け取るSMBリクエストの最大値であり、クライアントが受け取る 最大値ではない。クライアントのmaximum受信サイズはクライアントからSambaに 送られ、Sambaはその値を信頼する。

既定値では65536バイトに設定されているが、より小さい値の方がよいという場合もありうる。 2048より小さい値にすると、重大な問題を引き起こす可能性がある。殆どの場合、 既定値が最適である。

ログレベル

debug levelとして設定できるログレベルを2より大きくすると、 大幅にパフォーマンスが低下する。 これはサーバーが各操作後ににログをフラッシュし、それがとても時間がかかるためである。

Read Raw

read raw操作は、最適化された、レイテンシの小さい、 ファイル読み取り操作の為に設計されている。サーバーはそれをサポートしなくてもよいが、 Sambaはread rawサポートをオプションとしていて、 規定値では有効になっている。

ある場合、クライアントはread rawをうまく扱えず、 従来の読み取り操作を使うよりも、それを使うことで実際にはパフォーマンスが落ちる こととなり、そのため、read raw = noを 試して、ネットワーク上で何が起きるかを観察しても良い。それはパフォーマンスを 下げるか上げるか、あるいは何も起きないかもしれない。テストすることで真実が わかる。

Write Raw

write raw操作は、最適化された、レイテンシの小さい、 ファイル読み取り操作の為に設計されている。サーバーはそれをサポートしなくてもよいが、 Sambaはread rawサポートをオプションとしていて、 規定値では有効になっている。

多くの場合、write rawをパラメーターを変更しようとした場合、 変更すると通常よりも速度が遅くなる。

ログインが遅い

ログインが遅い場合は、多くの場合パスワードチェックのためである。 最も小さい実用的なpassword levelは、これを改善する。

クライアントのチューニング

大抵の場合、スピードの問題はクライアントに原因がある。(Windows for Workgroupsのような) クライアントはたいていの場合、TCPパフォーマンスをより改善できる。 Sambaとその他のCIFSクライアント中の、 各種クライアントについての節をチェックすること。

Linuxカーネルを変更した事によるSambaパフォーマンス問題

あるユーザーがメーリングリストに次のように発言した。

私はGentooの上でSamba 2.2.8aを動かしています。 最近私はカーネルのバージョンをlinux-2.4.19-gentoo-r10から linux-2.4.20-wolk4.0sに変更しました。すると、Sambaの パフォーマンスに問題が生じました。多くの人々はおそらく 普通のソース(kernel)に移行しろ!」と言うでしょう。 もちろん私は試しましたが、上手くいきませんでした。 私は100MBのLANと2台のコンピュータ(LinuxとWindows2000)を使っています。 LinuxサーバーでDivxファイルの入ったフォルダーを共有し、クライアント(Windows2000)で LAN経由で再生していました。2.4.19カーネルにする前は全てが上手く動いていましたが、 現在では動画は固まって止まってしまいます。サーバーからWindowsへファイルを移動させようと しましたが、それもとても遅いです。

それに対してこのような返答があった。

mii-toolを持ってきて、NIC上の全二重の設定をチェックするとよいでしょう。 私はこれはデータリンク層の問題で、アプリケーション層の問題ではないと思います。 また、ifconfigを動かし、そのフレーミングエラー、コリジョン、その他を調べ、 ethenetが問題ないのかを見ましょう。

壊れたtdbファイル

我々のSambaPDCサーバーは、3年間の間問題なく500以上のユーザー[Windows NT/XP]で3TBのデータを ホスティングしていました。現在ではすべての共有がとても遅いです。親プロセスのsmbdは 継続してプロセスを起動していて、(通常なら平均で250なのに)1600以上のSMDBプロセスが 起動しています。これによってSUN E3500が2回壊れています。 幾たびもの調査の後、rm /var/locks/*.tdbを実行することにしました。 その結果、再び良好に動作しました。

質問:*.tdbファイルを最良の状態に保持する何らかの方法はあるので しょうか?あるいは、どのようにしたら、素早く破壊状態を検出できるのでしょうか?

答え: はい、nmdbの停止と起動のたびにtdbbackupを 実行してください。

質問:さらに言及したいこととして、サービスのレイテンシは削除前より かなり遅くなったように見えます。最高速度を保持する良いアイデアはありませんか?

答え:はい、同じ質問が前にありました。

Sambaのパフォーマンスがとても悪い

MYOB Premier操作とそのデータファイルへのアクセスにおいて、とても不可解な徴候を 経験したと、あるサイトは報告した。そのファイルへのいくつかの操作で40秒から45秒の 時間がかかった。

Windowsクライアント上でプリンターモニタープログラムを走らせたところ、この問題が発生した。 ログから、1秒ごとに休止状態が発生していることが分かりました。

モニターソフトウエアを止めたところ、ネットワーク速度が普通(早い状態に)戻りました。 再びモニターソフトウエアを起動させたところ、再び遅くなりました。 プリンターはCanon LBP-810で and the relevant task wassomething like CAPON (not sure on spelling). モニターソフトウエアは、クライアントが印刷中、"印刷中"を表示している。

Windowsのクリーンインストールと、他のソフトを何度も段階的にインストールすることによって、 発見した。

この話の教訓:すべてをチェックしなさい(他のソフトウェアも含めて)!

Chapter 46. LDAPとトランスポート層のセキュリティ

Gavin Henry

Suretec Systems Limited, UK

July 8, 2005

概要

現在に至るまで、ACLのような、いくつかの高度な機能を含む、 OpenLDAP™の簡単な設定について議論してきた。 しかし、ネットワーク上の通信が引き続き平文であるという現状には対応しない。 これが、Transport Layer Security (TLS)が導入された 理由である。

OpenLDAP™クライアントとサーバーは、 RFC 2830(訳注:現在は RFC 4513が最新) Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security. による、完全性と機密性を提供するため、Transport Layer Security (TLS)を使う 能力がある。

TLSはX.509証明書を使う。すべてのサーバーは有効な証明書を持つ必要があるが、 クライアント証明書はあってもなくてもよい。ここではサーバー証明書のみを 議論の対象とする。

Tip

サーバー証明書のDNはサーバーの名前を指定するCN属性を使う必要があり、CNは、サーバーの、 完全に記述されたドメイン名(FQDN)を引き継ぐ必要がある。追加の別名と ワイルドカードは、subjectAltName証明書エクステンションに存在しても よい。サーバー証明書の名前についてのより詳細については、 RFC2830にある。

これについては次の節で詳細に説明する。

設定

これから重要なところを説明する。

認証局の作成

適切な証明書を作成するために、固有の認証局(CA)を立てる必要がある。 [8] これは必要であり、そうすると、サーバー証明書に署名できる。

これに対しては、ほとんどのLinux® ディストリビューションに含まれているOpenSSL [9] を使うことになる。

TLSは多くの種類のサーバーによって使われるが、その手続きは、 [10] ここで説明されていて、OpenLDAP に特化している。

Note

以下の例におけるCommon Name (CN)は、使用しているLDAPサーバーの 完全に記述されたドメイン名(FQDN)でなければならない

最初に認証局(CA)を生成する必要がある:


root#  mkdir myCA

そのディレクトリに移動する:


root#  cd myCA

Now generate the CA:[11]


root#  /usr/share/ssl/misc/CA.pl -newca
CA certificate filename (or enter to create)
  
Making CA certificate ...
Generating a 1024 bit RSA private key
.......................++++++
.............................++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Some-State]:NSW
Locality Name (eg, city) []:Sydney
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Abmas
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:ldap.abmas.biz
Email Address []:support@abmas.biz

注意すべき点がいくつかある。

  1. サーバーの証明書に署名するのに必要なので、 パスワードを覚えておく必要がある

  2. Common Name (CN)は使用しているLDAPサーバーの 完全に記述されたドメイン名(FQDN)でなければならない

サーバー証明書の生成

次にサーバー証明書を生成する必要がある:


root#  openssl req -new -nodes -keyout newreq.pem -out newreq.pem
Generating a 1024 bit RSA private key
.............++++++
........................................................++++++
writing new private key to 'newreq.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Some-State]:NSW
Locality Name (eg, city) []:Sydney
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Abmas
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:ldap.abmas.biz
Email Address []:support@abmas.biz
  
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

繰り返すが、ここでもいくつか注意すべき事がある。

  1. パスワードを入力すべきではない

  2. Common Name (CN)は使用しているLDAPサーバーの 完全に記述されたドメイン名(FQDN)でなければならない

次に新しい認証局(CA)の証明書に署名する:


root#  /usr/share/ssl/misc/CA.pl -sign
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
	Not Before: Mar  6 18:22:26 2005 EDT
	Not After : Mar  6 18:22:26 2006 EDT
Subject:
	countryName               = AU
	stateOrProvinceName       = NSW
	localityName              = Sydney
	organizationName          = Abmas
	organizationalUnitName    = IT
	commonName                = ldap.abmas.biz
	emailAddress              = support@abmas.biz
X509v3 extensions:
	X509v3 Basic Constraints:
	    CA:FALSE
	Netscape Comment:
	    OpenSSL Generated Certificate
	X509v3 Subject Key Identifier:
	    F7:84:87:25:C4:E8:46:6D:0F:47:27:91:F0:16:E0:86:6A:EE:A3:CE
	X509v3 Authority Key Identifier:
	    keyid:27:44:63:3A:CB:09:DC:B1:FF:32:CC:93:23:A4:F1:B4:D5:F0:7E:CC
	    DirName:/C=AU/ST=NSW/L=Sydney/O=Abmas/OU=IT/
						CN=ldap.abmas.biz/emailAddress=support@abmas.biz
	    serial:00

Certificate is to be certified until Mar  6 18:22:26 2006 EDT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem

これでサーバー証明書の生成が完了する。

証明書のインストール

次に、正しい設定ディレクトリ中に証明書をコピーする必要があり、その後同時に改名して (利便性のために)、所有権を変更し、最後にアクセス許可を与える:


root#  cp demoCA/cacert.pem /etc/openldap/
root#  cp newcert.pem /etc/openldap/servercrt.pem
root#  cp newreq.pem /etc/openldap/serverkey.pem
root#  chown ldap.ldap /etc/openldap/*.pem
root#  chmod 640 /etc/openldap/cacert.pem;
root#  chmod 600 /etc/openldap/serverkey.pem

次に、これらのファイル位置情報を、以下のようにして、slapd.conf の、database定義の前のどこかに追加する必要がある:


TLSCertificateFile /etc/openldap/servercrt.pem
TLSCertificateKeyFile /etc/openldap/serverkey.pem
TLSCACertificateFile /etc/openldap/cacert.pem

以下は、ldap.confでの定義である: ldap.conf


TLS_CACERT /etc/openldap/cacert.pem

これですべてである。次にthe section called “評価”を行う。

評価

ここは簡単な部分である。サーバーを再起動する:


root#  /etc/init.d/ldap restart
Stopping slapd:                                            [  OK  ]
Checking configuration files for slapd: config file testing succeeded
Starting slapd:                                            [  OK  ]

次に、ldapsearchを使い、-ZZオプションを使って [12] 匿名検索で評価する:


root#  ldapsearch -x -b "dc=ldap,dc=abmas,dc=biz" \
        -H 'ldap://ldap.abmas.biz:389' -ZZ

以下のように、サーバーを再起動する前と結果は同じであるべきである:


root#  ldapsearch -x -b "dc=ldap,dc=abmas,dc=biz" \
    -H 'ldap://ldap.abmas.biz:389' -ZZ

# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# abmas.biz
dn: dc=ldap,dc=abmas,dc=biz
objectClass: dcObject
objectClass: organization
o: Abmas
dc: abmas

# Manager, ldap.abmas.biz
dn: cn=Manager,dc=ldap,dc=abmas,dc=biz
objectClass: organizationalRole
cn: Manager

# ABMAS, abmas.biz
dn: sambaDomainName=ABMAS,dc=ldap,dc=abmas,dc=biz
sambaDomainName: ABMAS
sambaSID: S-1-5-21-238355452-1056757430-1592208922
sambaAlgorithmicRidBase: 1000
objectClass: sambaDomain
sambaNextUserRid: 67109862
sambaNextGroupRid: 67109863

何か問題が起きた場合は、the section called “トラブルシューティング”を読んでみてほしい。

トラブルシューティング

TLSを設定しているときに最もよくあるエラーは、何回も説明したように、 the section called “サーバー証明書の生成”で入力したCommon Name (CN)が、 使用しているLDAPサーバーの、完全に記述されたドメイン名(FQDN)でないという ものである。

他のエラーとしては、ldapsearchコマンドのどこかでタイプミスしたとか、 servercrt.pemcacert.pemに間違ったアクセス 許可を設定しているかである。the section called “証明書のインストール”単位に chmod 640で設定すべきである。

それ以外は、ldapのログファイルを読むか、OpenLDAPメーリングリストに参加するのが最も良い方法 である。



[8] しかし、作成したサーバー証明書は、たとえば、 ThawteVeriSignのような、有料または CAcert経由の、無料のものを使って、 適切なCAによって署名されるようにできる。

[9] 固有の認証局(CA)を作ることの不都合な点は、商用のものがそうであるように、 証明書がクライアントによって自動的に認識されないということである。

[10] 一番確かなところからの情報は、 http://www.openssl.org/docs/HOWTO/ のmain OpenSSLサイトを参照のこと。

[11] Your CA.pl or CA.sh might not be in the same location as mine is, you can find it by using the locate command, i.e., locate CA.pl. If the command complains about the database being too old, run updatedb as root to update it.

[12] man ldapsearchを参照

第47章 Samba サポート

IT業界におけるもっとも回答が難しい質問のひとつがサポートとは何か である。この質問を受けた人々はイライラし、その回答を受けた人々も大 抵同じくらいイライラするだろう。

サポートにつきものであるもっともイライラする象徴的な状況は、Linux ユーザーが インターネットサービスプロバイダーに電話したときに(解決策を探そうと、問題に ついて耳を傾けるかわりに)「ああ、Linuxですか。Linux はサポートして おりません。」と、素っ気なく返答された場合だ。これは私が経験したこ とであり、似た状況はIT業界の至る所で起きている。あるビジネスにとってただ相 手にしたくない顧客がいくらか存在するということを私たちに知らせることをこの ような回答は意図している。私たちは拒否されたことに激しい痛みを感じるだろう。

サポートについて深く考える一つの方法は、状況のいかんにかかわらず、正しい回 答、正しい場所、正しいタイミングによって構成されるという見方をすることであ る。苦労、混乱、不便、生産性の低下、不確実性そして実在するリスクまたは知覚 リスクを取り除くことがサポートのすべてである。

ある事実が、オープンソースソフトウェアを採用する駆動力の一つになっている。 おそらく多くのITビジネスが提供しているサービスは、顧客の期待にそえられない か、その他の理由により十分でなかった。

ITユーザーまたは消費者が期待する最初の経験のときのニーズを満たす必要性を認 めて、この章では問題解決に関する不愉快な経験を避けるのに役立つ情報を提供す る。

オープンソースの分野ではサポートに2つの選択肢がある。無償サポートと有償(商 用)サポートである。

無償サポート

無償サポートは、友人、同僚、ユーザーグループ、メーリングリスト、対話的な ヘルプファシリティーから得られる。対話的なヘルプファシリティーの一例にユ ーザー同士での支援の場所を設けるIRC(Internet relay chat)チャネルがある。

Samba プロジェクトではSamba をデプロイする方法を議論するメーリング リストを維持してきた。Samba メーリングリストへの参加申し込みについ ての情報は、 Samba ウェブサイト にある。無償で利用できる、ユーザーの貢献による 公共のメーリングリストのサポートは samba リスト と呼ばれている。リストへの email アドレスは mail:samba@samba.orgである。Samba IRCチャネルについての情 報は Samba IRC ウェブページにある。

一般的なルールとして、Samba チームメンバーに直接無償のサポートを求 めて連絡をするのはお粗末な作法である。Samba チームのアクティブなメ ンバーのほとんどは、要件を満たすことが立証された問題をサポートする ために大変長い時間働いている。Samba チームのメンバーは対価を受けと ることで、直接メールや電話でのサポートの連絡を受けている。何人かの Samba チームメンバーは、実際に有償の 専門的な Samba サポートを提供 している。

Samba のバグに遭遇した場合、大抵において解決するもっとも早い方法は レポートを投稿する ことである。すべてのレポートは責任あるコードメインテナーにアクショ ンを起こさせるためにメールされる。レポートがよく書かれていたり、そ の問題が深刻であれば、より早く扱われるだろう。一方では、メインテナ ーがレポートされたバグを再現できない場合は、却下されると思われる。 再現できるほど十分な情報を提供することはレポートする人の責任である。

無償サポートでは、要求された期限の中では解決策を提供できないことが あることを承知している。他方で問題が理解しにくく、問題を切り分ける たりひいては解決をするのに必要な経験に欠けているような場合がある。 そういう場合は有償サポートを購入することが賢明だろう。

商用サポート

Samba サイトにてありふれて見られるサービス指向の基本的なサポートが 以下の6つである。

  • ネットワーク設計の補助

  • スタッフトレーニング

  • Samba ネットワークの配置と導入の補助

  • Samba 設定の優先的な電話やメールによる補助

  • トラブルシューティングと診断の補助

  • 品質が保証され、インストールする準備ができ ている (ready-to-install) Samba バイナリパッケージの提供

Samba の専門的なサポートを提供する会社についての情報は、Google 検索 や、Samba Support ウェブページでも入手できる。Samba チームへ商用サポ ートの提供を知らせた会社は、国別で整列されたリストに載せている。リ ストの記載について重複が認められているが、保証は提供されない。サポ ート会社の選定や会社とその従業員は要求されることを提供することが出 来るということに納得することは利用者次第である。

Samba チームのポリシーは、すべてのサポート会社を等しく扱うことと好 みを提示しないこと。結果として商用サポートを提供している Samba チー ムのメンバーもその他と一緒くたにされている。地元の会社から必要なサ ービスを得るように奨励する。オープンソースムーブメントはプロの団体 です。 だから、できることをして地元の企業が成功するのを助けて欲しい。

オープンソースソフトウェアのサポートはいかなる品質、費用、場所でも 得ることができる。世界中で180社以上が Samba のサポートを提供してい る。Samba がサポートされないソフトウェアという誤った信念に苦しむ理 由はない。 Samba はサポートされている。

Chapter 48. DNSとDHCP設定ガイド

John H. Terpstra

Samba Team

機能と利便性

UNIXの領域においては、 Domain Name System (DNS) と Dynamic Host Configuration Protocol (DHCP) と同じくらいたくさんの論争が起こる主題はない。 DNSとDHCPの特定の実装に賛成、反対する意見の一部は有効である。 There are few subjects in the UNIX world that might raise as much contention as Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP). Not all opinions held for or against particular implementations of DNS and DHCP are valid.

多くの情報技術を利用する人が、携帯性と利用の自由を要求する現代に、我々は生きている。 Microsoft Windows ユーザーは特に、使用しているノートPCをネットワークに繋げば、 ちゃんと動く事を期待している。

UNIX管理者はpoint。Microsoft Windowsの領域における多くの標準的な習慣が、セキュリティの 観点からは悪い習慣上で最も良い境界にある(???)。Microsoft Windows ネットワーク プロトコルは、ネットワーク上に、ワークステーションそれ自身を登録する機能を用意している。 Windows 2000のActive DirectoryはDNS名前空間に、UNIX管理者が困惑するような、エントリを 登録する。世界は変わってしまったのである! UNIX administrators have a point. Many of the normative practices in the Microsoft Windows world at best border on bad practice from a security perspective. Microsoft Windows networking protocols allow workstations to arbitrarily register themselves on a network. Windows 2000 Active Directory registers entries in the DNS namespace that are equally perplexing to UNIX administrators. Welcome to the new world!

この章の目的は、Microsoft Windows 2000 サーバー製品中でのものと互換性のある、動的サービスを 提供するために、Internet Software Consortium (ISC) のDNSとDHCPサーバーの設定をデモすること である。

この章では、DNSとDHCPサーバーの両方に対する、動く設定ファイルの例を提供する以上のものでは ない。例は、このドキュメント中のどこかで使われている設定例に一致するものを使う。

この章では、明示的にチュートリアルでも、全体として、この文書の意図と範囲を超えているので、 DNSとDHCPのリファレンスガイドの代替品を提供しない。DNSまたはDHCPについてのより詳細な 参考情報を知りたいのであれば、ISCのWebサイト http://www.isc.orgを参照のこと。 書籍として情報が欲しいのであれば、 オライリー のWebサイトに行って、DNSの本の情報を、また、 BIND9.NETというWebサイトを 見てみると良い。 書籍情報は以下の通り:

  1. DNS and BIND, By Cricket Liu, Paul Albitz, ISBN: 1-56592-010-4(訳注:日本語訳あり)

  2. DNS & Bind Cookbook, By Cricket Liu, ISBN: 0-596-00410-9

  3. The DHCP Handbook (2nd Edition), By: Ralph Droms, Ted Lemon, ISBN 0-672-32327-3

設定例

DNSは、インターネットにとっては、生活における水のようなものである。ほとんどすべての 情報リソース(ホスト名)はDNSを通してそのIPアドレスに解決される。Windowsネットワークは DNSの複雑さを防ぐために、かなりいろいろな事をやっていたが、結局DNSの勝ちであった。 DNSの代わりとしてWindows Internet Name Service (WINS) がある。 NetBIOS networking over the TCP/IPプロトコルの悪い点は、情報技術ネットワークの 複雑さと規模が発展していく時に、管理できなくなる、平坦で階層構造のない名前空間の ような拡張性の問題が明らかとなっていることである。

WINSはMicrosoftによるRFC1001/1002 NetBIOS Name Service (NBNS)の実装である。これは、 NetBIOSクライアント(Microsoft Windowsマシンのような)に、マシンに与えられたIPアドレスと 一緒に管理者かユーザーが選べる任意のマシン名を解決することができる。WINSを使うと、 ネットワーククライアントマシンは、マシン名をそのIPアドレスに解決できる。

NetBIOSネットワークファミリの制限に対する代替のための要求は、最終的に、Microsoftが DNSとActive Directoryを使うように追い込んだ。Microsoftの新しい実装は、NetBIOS ネットワークにおいて、WINSが使われる方法と同様のやり方で、DNSを使うことを試みている。 WINSとMicrosoft DNSの両方は、動的な名前登録に頼っている。

Microsoft Windows クライアントは起動時にDNSサーバーに対して動的な名前登録を行うことが できる。その代わりに、ワークステーションのIPアドレスを割り当てるところにDNSが使われる 場面において、クライアントが、IPアドレスの貸出を受け取ったら直ちに、DHCPサーバーによって そのホスト名とIPアドレスを登録することが出来る。最後に、Microsoft DNSは、Microsoft WINS 経由でホスト名を解決できる。

以下の設定は、単純な、セキュリティを考慮していないDNSサーバーと、DNSの設定にあわせた 単純なDHCPサーバーの例を提示している。

ダイナミックDNS

DNS設定の例は、ネットワーク 192.168.1.0/25のIPアドレス範囲中のプライベート ネットワーク用である。プライベートなネットワークアドレス空間はRFC1918に 説明がある。

このネットワークは安全なファイアウォールの内側に位置していることを仮定している。 以下のファイルはISC BINDバージョン9用である。BINDは Berkeley Internet Name Daemonの略である。

マスター設定ファイル/etc/named.confは、この後使用する すべての設定ファイルの位置を決める。このファイルの位置と名前は、OSの一部である 起動スクリプト内で指定されている。

# Quenya.Org の設定ファイル

acl mynet {
	192.168.1.0/24;
	127.0.0.1;
};

options {

	directory "/var/named";
	listen-on-v6 { any; };
	notify no;
	forward first;
	forwarders {
		192.168.1.1;
		};
	auth-nxdomain yes;
	multiple-cnames yes;
	listen-on {
		mynet;
		};
};

# The following three zone definitions do not need any modification.
# The first one defines localhost while the second defines the
# reverse lookup for localhost. The last zone "." is the
# definition of the root name servers.

zone "localhost" in {
	type master;
	file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
	type master;
	file "127.0.0.zone";
};

zone "." in {
	type hint;
	file "root.hint";
};

# You can insert further zone records for your own domains below.

zone "quenya.org" {
	type master;
	file "/var/named/quenya.org.hosts";
	allow-query {
		mynet;
		};
	allow-transfer {
		mynet;
		};
	allow-update {
		mynet;
		};
	};

zone "1.168.192.in-addr.arpa" {
	type master;
	file "/var/named/192.168.1.0.rev";
	allow-query {
		mynet;
	};
	allow-transfer {
		mynet;
	};
	allow-update {
		mynet;
	};
};

以下のファイルはすべて/var/namedというディレクトリにある。 これは/var/named/localhost.zoneファイルである:

$TTL 1W
@               IN SOA  @   root (
				42              ; serial (d. adams)
				2D              ; refresh
				4H              ; retry
				6W              ; expiry
				1W )            ; minimum

		IN NS           @
		IN A            127.0.0.1
	

/var/named/127.0.0.zoneファイルである:

$TTL 1W
@               IN SOA          localhost.  root.localhost. (
				42              ; serial (d. adams)
				2D              ; refresh
				4H              ; retry
				6W              ; expiry
				1W )            ; minimum

				IN NS           localhost.
1               IN PTR          localhost.

/var/named/quenya.org.hostファイルである:

$ORIGIN .
$TTL 38400      ; 10 hours 40 minutes
quenya.org      IN SOA  marvel.quenya.org. root.quenya.org. (
				2003021832 ; serial
				10800      ; refresh (3 hours)
				3600       ; retry (1 hour)
				604800     ; expire (1 week)
				38400      ; minimum (10 hours 40 minutes)
				)
			NS      marvel.quenya.org.
			MX      10 mail.quenya.org.
$ORIGIN quenya.org.
frodo                   A       192.168.1.1
marvel                  A       192.168.1.2
;
mail                    CNAME   marvel
www                     CNAME   marvel

/var/named/192.168.1.0.revファイルである:

$ORIGIN .
$TTL 38400      ; 10 hours 40 minutes
1.168.192.in-addr.arpa  IN SOA  marvel.quenya.org. root.quenya.org. (
				2003021824 ; serial
				10800      ; refresh (3 hours)
				3600       ; retry (1 hour)
				604800     ; expire (1 week)
				38400      ; minimum (10 hours 40 minutes)
				)
			NS      marvel.quenya.org.
$ORIGIN 1.168.192.in-addr.arpa.
1                       PTR     frodo.quenya.org.
2                       PTR     marvel.quenya.org.

ここで示された設定ファイルは完全に動くシステムからコピーしたものである。すべての 動的に登録されるエントリは削除されている。それらのファイルに対してはさらに、 BINDバージョン9が、.jnlという拡張子を持つファイルである、 各動的登録ファイルを作成する。構成ファイルと作成された.jnl ファイルを編集したり、不正に変更してはならない。

DHCPサーバー

以下のファイルはISC DHCPサーバー バージョン3で使われる。ファイルは、 /etc/dhcpd.confにある:

ddns-updates on;
ddns-domainname "quenya.org";
option ntp-servers 192.168.1.2;
ddns-update-style ad-hoc;
allow unknown-clients;
default-lease-time 86400;
max-lease-time 172800;

option domain-name "quenya.org";
option domain-name-servers 192.168.1.2;
option netbios-name-servers 192.168.1.2;
option netbios-dd-server 192.168.1.2;
option netbios-node-type 8;

subnet 192.168.1.0 netmask 255.255.255.0 {
	range dynamic-bootp 192.168.1.60 192.168.1.254;
	option subnet-mask 255.255.255.0;
	option routers 192.168.1.2;
	allow unknown-clients;
}

この例では、192.168.1.1と192.168.1.59のIPアドレス範囲は固定IPアドレス (よくhard-wiredと呼ばれる)のために予約されている。 192.168.1.60から192.168.1.254の間のアドレスは動的な割り当てに使われる。

Appendix A.  GNU General Public License version 3

Version 3, 29 June 2007

Copyright © 2007 Free Software Foundation, Inc. http://fsf.org/

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Preamble

The GNU General Public License is a free, copyleft license for software and other kinds of works.

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program—to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.

For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software. For both users’ and authors’ sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users’ freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.

Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.

The precise terms and conditions for copying, distribution and modification follow.

TERMS AND CONDITIONS

0. Definitions.

“This License” refers to version 3 of the GNU General Public License.

“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.

“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

A “covered work” means either the unmodified Program or a work based on the Program.

To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.

To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.

1. Source Code.

The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

The Corresponding Source for a work in source code form is that same work.

2. Basic Permissions.

All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.

Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.

3. Protecting Users’ Legal Rights From Anti-Circumvention Law.

No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work’s users, your or third parties’ legal rights to forbid circumvention of technological measures.

4. Conveying Verbatim Copies.

You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

5. Conveying Modified Source Versions.

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

  1. The work must carry prominent notices stating that you modified it, and giving a relevant date.

  2. The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.

  3. You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

  4. If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

  1. Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.

  2. Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.

  3. Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.

  4. Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

  5. Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.

A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.

A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.

Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.

7. Additional Terms.

“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

  1. Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or

  2. Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or

  3. Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or

  4. Limiting the use for publicity purposes of names of licensors or authors of the material; or

  5. Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or

  6. Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.

8. Termination.

You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.

9. Acceptance Not Required for Having Copies.

You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.

10. Automatic Licensing of Downstream Recipients.

Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.

An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party’s predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.

11. Patents.

A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor’s “contributor version”.

A contributor’s “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.

Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.

In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.

If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient’s use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.

If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.

A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.

12. No Surrender of Others’ Freedom.

If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.

13. Use with the GNU Affero General Public License.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.

14. Revised Versions of this License.

The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.

If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

17. Interpretation of Sections 15 and 16.

If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.

END OF TERMS AND CONDITIONS

How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.

one line to give the program’s name and a brief idea of what it does.
Copyright (C) year name of author

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see http://www.gnu.org/licenses/.
  

Also add information on how to contact you by electronic and paper mail.

If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:

program Copyright (C) year name of author
This program comes with ABSOLUTELY NO WARRANTY; for details type ‘show w’.
This is free software, and you are welcome to redistribute it
under certain conditions; type ‘show c’ for details.
  

The hypothetical commands ‘show w’ and ‘show c’ should show the appropriate parts of the General Public License. Of course, your program’s commands might be different; for a GUI interface, you would use an “about box”.

You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see http://www.gnu.org/licenses/.

The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read http://www.gnu.org/philosophy/why-not-lgpl.html.

用語集

アクセスコントロールリスト

A detailed list of permissions granted to users or groups with respect to file and network resource access. See “ファイル、ディレクトリと共有のアクセス制御”, for details.

Active Directory Service

A service unique to Microsoft Windows 200x servers that provides a centrally managed directory for management of user identities and computer objects, as well as the permissions each user or computer may be granted to access distributed network resources. ADS uses Kerberos-based authentication and LDAP over Kerberos for directory access.

Common Internet File System

The new name for SMB. Microsoft renamed the SMB protocol to CIFS during the Internet hype in the nineties. At about the time that the SMB protocol was renamed to CIFS, an additional dialect of the SMB protocol was in development. The need for the deployment of the NetBIOS layer was also removed, thus paving the way for use of the SMB protocol natively over TCP/IP (known as NetBIOS-less SMB or naked TCP transport).

Common UNIX Printing System

A recent implementation of a high capability printing system for UNIX developed by http://www.easysw.com/. The design objective of CUPS was to provide a rich print processing system that has built-in intelligence capable of correctly rendering (processing) a file that is submitted for printing even if it was formatted for an entirely different printer.

Domain Master Browser

The domain master browser maintains a list of all the servers that have announced their services within a given workgroup or NT domain. See “ワークグループのブラウジングの設定” for details.

Domain Name Service

A protocol by which computer hostnames may be resolved to the matching IP address/es. DNS is implemented by the Berkeley Internet Name Daemon. There exists a recent version of DNS that allows dynamic name registration by network clients or by a DHCP server. This recent protocol is known as dynamic DNS (DDNS).

Dynamic Host Configuration Protocol

A protocol that was based on the BOOTP protocol that may be used to dynamically assign an IP address, from a reserved pool of addresses, to a network client or device. Additionally, DHCP may assign all network configuration settings and may be used to register a computer name and its address with a dynamic DNS server.

Extended Meta-file Format

An intermediate file format used by Microsoft Windows-based servers and clients. EMF files may be rendered into a page description language by a print processor.

Graphical Device Interface

Device-independent format for printing used by Microsoft Windows. It is quite similar to what PostScript is for UNIX. Printing jobs are first generated in GDI and then converted to a device-specific format. See “Windows上でのGDI、UNIX上でのPostScript” for details.

Group IDentifier

The UNIX system group identifier; on older systems, a 32-bit unsigned integer, and on newer systems an unsigned 64-bit integer. The GID is used in UNIX-like operating systems for all group-level access control.

Internet Print Protocol

An IETF standard for network printing. CUPS implements IPP.

Key Distribution Center

The Kerberos authentication protocol makes use of security keys (also called a ticket) by which access to network resources is controlled. The issuing of Kerberos tickets is effected by a KDC.

NetBIOS Extended User Interface

Very simple network protocol invented by IBM and Microsoft. It is used to do NetBIOS over Ethernet with low overhead. NetBEUI is a nonroutable protocol.

Network Basic Input/Output System

NetBIOS is a simple application programming interface (API) invented in the 1980s that allows programs to send data to certain network names. NetBIOS is always run over another network protocol such as IPX/SPX, TCP/IP, or Logical Link Control (LLC). NetBIOS run over LLC is best known as NetBEUI (NetBIOS Extended User Interface a complete misnomer!).

NetBT

Protocol for transporting NetBIOS frames over TCP/IP. Uses ports 137, 138, and 139. NetBT is a fully routable protocol.

Local Master Browser

The local master browser maintains a list of all servers that have announced themselves within a given workgroup or NT domain on a particular broadcast-isolated subnet. See “ワークグループのブラウジングの設定” for details.

Printer Command Language

A printer page description language that was developed by Hewlett-Packard and is in common use today.

Portable Document Format

A highly compressed document format, based on PostScript, used as a document distribution format that is supported by Web browsers as well as many applications. Adobe also distributes an application called Acrobat, which is a PDF reader.

Page Description Language

A language for describing the layout and contents of a printed page. The best-known PDLs are Adobe PostScript and Hewlett-Packard PCL (Printer Control Language), both of which are used to control laser printers.

PostScript Printer Description

PPDs specify and control options supported by PostScript printers, such as duplexing, stapling, and DPI. See also “PostScriptとGhostscript”. PPD files can be read by printing applications to enable correct PostScript page layout for a particular PostScript printer.

Remote Procedure Call

RPCs are a means for executing network operations. The RPC protocol is independent of transport protocols. RPC does not try to implement any kind of reliability and the application that uses RPCs must be aware of the type of transport protocol underneath RPC. An RPC is like a programmatic jump subroutine over a network. RPCs used in the UNIX environment are specified in RFC 1050. RPC is a powerful technique for constructing distributed, client-server based applications. It is based on extending the notion of conventional, or local procedure calling, so that the called procedure need not exist in the same address space as the calling procedure. The two processes may be on the same system, or they may be on different systems with a network connecting them. By using RPC, programmers of distributed applications avoid the details of the interface with the network. The transport independence of RPC isolates the application from the physical and logical elements of the data communications mechanism and allows the application to use a variety of transports.

Server Message Block

SMB was the original name of the protocol `spoken' by Samba. It was invented in the 1980s by IBM and adopted and extended further by Microsoft. Microsoft renamed the protocol to CIFS during the Internet hype in the 1990s.

User IDentifier

The UNIX system user identifier; on older systems a 32-bit unsigned integer, and on newer systems, an unsigned 64-bit integer. The UID is used in UNIX-like operating systems for all user-level access control.

Universal Naming Convention

A syntax for specifying the location of network resources (such as file shares). The UNC syntax was developed in the early days of MS DOS 3.x and is used internally by the SMB protocol.

Index

Symbols

"Printers" フォルダー, 考慮すべき警告
"プリンター"フォルダー, クライアント上でのPostScriptドライバーのインストール, 15ステップでの手動ドライバーインストール
$, マシン信頼アカウントの手動作成
%iマクロ, 複数仮想サーバーの性質(Personalities)
%L, 複数仮想サーバーの性質(Personalities)
%PDF, MIMEタイプとCUPSフィルタ
%SystemRoot%\System32\config, Microsoft Windows NT4スタイルのドメイン制御
../source/nsswitch, WinbindとPAMの設定
.ai, MIMEタイプとCUPSフィルタ
.AppleDouble, netatalk
.eps, MIMEタイプとCUPSフィルタ
.pdf, MIMEタイプとCUPSフィルタ
.PDS 拡張子, Windows NT4 workstation
.profiles, Windows 9x/Me ユーザープロファイル
.ps, MIMEタイプとCUPSフィルタ
.recycle, recycle
/bin/false, 設定例, User Rights and Privileges
/dev/null, User Rights and Privileges
/dev/shadowvol, Shadow Copy のセットアップ
/etc/cups/, MIMEタイプとCUPSフィルタ
/etc/cups/mime.convs, 直接印刷機能:Windowsクライアント上のベンダドライバー, application/octet-streamのための“raw”印刷を明示的に有効にする, MIMEタイプ変換ルール, application/octet-stream 印刷
/etc/cups/mime.types, 直接印刷機能:Windowsクライアント上のベンダドライバー, application/octet-streamのための“raw”印刷を明示的に有効にする, application/octet-stream 印刷
/etc/fstab, Shadow Copy のセットアップ
/etc/group, 共有レベルのセキュリティ, 議論, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, smb.confにグループを追加するスクリプト例, ドメインメンバーサーバーかドメインメンバークライアント, [global]セクション, 機能と利便性, HPUX
/etc/groups, /etc/pam.d にあるエントリーの構造
/etc/host.conf, 純粋なUNIX/Linux環境中での名前解決, /etc/host.conf
/etc/hosts, /etc/krb5.confの設定, どのようにブラウジングは機能するか, 純粋なUNIX/Linux環境中での名前解決, /etc/hosts, Microsoft Windowsネットワーク内でのような名前解決, テスト
/etc/hosts>, /etc/hosts
/etc/inetd.conf, Linux/FreeBSD固有のPAM設定, inetd.confからの起動
/etc/init.d/samba, Samba-3でNT4形式でのドメインに参加する, Linux
/etc/init.d/samba.server, Solaris
/etc/init.d/smb, Linux
/etc/krb5.conf, /etc/krb5.confの設定, よくあるエラー, ADSドメイン, Winbindを使ったIDMAPデータのLDAPへの格納
/etc/ldap.conf, Winbindを使ったIDMAPデータのLDAPへの格納, RFC2307bis Schema拡張を使ったADSからのIDMAPとNSSに対するLDAPの使用
/etc/logingroup, HPUX
/etc/mime.conv, 集中印刷サーバー
/etc/mime.types, 集中印刷サーバー
/etc/nsswitch.conf, ドメインメンバーサーバーかドメインメンバークライアント, NT4形式のドメイン(Sambaドメインを含む), IDMAP_RIDを使うWinbind, RFC2307bis Schema拡張を使ったADSからのIDMAPとNSSに対するLDAPの使用, Name Service Switch, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する, 純粋なUNIX/Linux環境中での名前解決, /etc/nsswitch.conf
/etc/openldap/slapd.conf, プライマリドメインコントローラー
/etc/openldap/sldap.conf, アカウントとグループの管理
/etc/pam.conf, Solaris固有の設定, その機能と利点, 技術的な議論, /etc/pam.d にあるエントリーの構造
/etc/pam.d, 用件, テスト, WinbindとPAMの設定, その機能と利点
/etc/pam.d/, Pluggable Authentication Modules, 技術的な議論
/etc/pam.d/ftp, Linux/FreeBSD固有のPAM設定
/etc/pam.d/login, Linux/FreeBSD固有のPAM設定
/etc/pam.d/samba, Linux/FreeBSD固有のPAM設定
/etc/passwd, 共有レベルのセキュリティ, 設定例, “$”マシン名中に$を含められない, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, マシン信頼アカウントの手動作成, Windows 200x/XP Professionalクライアント, マシンのドメインへの追加に失敗する, 背景, 参照用文書サーバー, 集中印刷サーバー, 下位互換性のあるバックエンド, 平文, RFC 2307 posixAccountとの関係とスキーマ, 3.0.11より前のバージョンのみに適用, ドメインメンバーサーバーかドメインメンバークライアント, 信頼されるドメインとしてのSamba, 機能と利便性, winbindddaemonの開始とテスト, その機能と利点
/etc/printcap, 基本的なCUPSサポート設定
/etc/resolv.conf, 純粋なUNIX/Linux環境中での名前解決, 前提条件, テスト
/etc/samba, 複数仮想サーバーの性質(Personalities), 複数の仮想サーバーホスティング, テスト
/etc/samba/scripts, Sambaサーバーからのワークステーション上のネストされたグループの管理
/etc/samba/secrets.tdb, Samba-3でNT4形式でのドメインに参加する
/etc/samba/smb.conf, Sambaの設定 (smb.conf)
/etc/samba/smbpasswd, 平文
/etc/samba/smbusers, ユーザーのマッピング
/etc/shadow, 背景, 下位互換性のあるバックエンド
/etc/smbpasswd, 平文
/etc/ssl/certs/slapd.pem, LDAP設定の注意
/etc/xinetd.d, Linux/FreeBSD固有のPAM設定
/etc/xinetd.d/telnet, Linux/FreeBSD固有のPAM設定
/export, 参照用文書サーバー
/lib/libnss_example.so, Name Service Switch
/lib/libnss_files.so, Name Service Switch
/lib/security, WinbindとPAMの設定, PAM 設定のための文法
/lib/security/, Pluggable Authentication Modules
/opt/samba/bin, SWATファイルの配置
/tmp, ファイルとディレクトリのアクセス制御
/usr/bin/openssl, SSLを使うSWATのセキュア化
/usr/lib/samba/vfs, 議論
/usr/lib/security, AIXにおけるNSS Winbind, WinbindとPAMの設定
/usr/lib/security/methods.cfg, AIXにおけるNSS Winbind
/usr/local/lib, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
/usr/local/samba, winbindddaemonの開始とテスト
/usr/local/samba/bin, Linux, Solaris, SWATファイルの配置
/usr/local/samba/lib, テスト
/usr/local/samba/lib/vfs, 議論
/usr/local/samba/private/secrets.tdb, Samba-3でNT4形式でのドメインに参加する
/usr/local/samba/swat, SWATを使用できるように有効化する
/usr/local/samba/var, 共有のアクセス制御, 前提条件
/usr/local/samba/var/locks, 静的なWINSエントリ
/usr/sbin, SWATファイルの配置, SWATを使用できるように有効化する
/usr/share/samba/swat, SWATを使用できるように有効化する
/var/locks/*.tdb, 壊れたtdbファイル
/var/log/samba, 前提条件
/var/run/samba, 静的なWINSエントリ
/var/spool/cups/, CUPSスプールフィルタの自動削除または保存
/var/spool/samba, 集中印刷サーバー, CUPSスプールフィルタの自動削除または保存
1つ以上のプロトコル, Windowsのネットワークプロトコル
250ユーザー制限, tdbsam
2アップ, フィルタリングチェインの例
3.0.11, 管理者のドメインSID
4,500ユーザーアカウント, tdbsam
4294967295, ドメイン間の信頼関係
8.3形式のファイル名, Microsoft Windows NTFSとUNIXファイルシステムとの比較
\\%L\%U\.profiles, Windows 9x/Me ユーザープロファイル
\\SERVER, 問題の解決方法
_kerberos.REALM.NAME, /etc/krb5.confの設定
_kerberos._udp, 注意
_ldap._tcp, 注意
_ldap._tcp.pdc._msdcs.quenya.org, NetBIOS Over TCP/IPが無効
すでに存在する(already exists), マシンをドメインに追加し直すことができない
すべてのバックアップの検証, サーバーの共有とディレクトリのレイアウト
とても大きな間違い, よくあるエラー
どこでもコンピューティング, 機能と利便性
どこにも保存されない, 暗号化されたパスワードの長所
ようこそ, ドメインへの参加: Windows 2000/XP Professional
よく制御されたネットワーク, サーバーの共有とディレクトリのレイアウト
よく知られたRID, 管理者のドメインSID
よく知られているRID, 既定値のユーザー、グループと相対識別子
アイデンティティ管理, ドメインメンバーサーバー
集中化, シングルサインオンとドメインセキュリティ
アカウント, 機能と利便性, Windows 200x/XP Professionalクライアント, はじめに
データベース, ドメインセキュリティモード(ユーザーレベルのセキュリティ)
バックエンド, 機能と利便性
バックエンド, 機能と利便性
アカウントのインポート/エクスポート, pdbeditツール
アカウントの削除, アカウントの削除
アカウントアクセス制御, 新しいアカウント格納システム
アカウントセキュリティ, pdbeditツール
アカウントデータベース, パスワードバックエンド
アカウントバックエンド, アカウント情報データベース
アカウントフラグ, ユーザーとマシンアカウントの表示, アカウントフラグ管理
アカウントポリシー, ドメイン制御の準備, pdbeditツール
アカウント制御, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, アカウント/ユーザーポリシーの管理
アカウント制限, アカウント/ユーザーポリシーの管理
アカウント名, ドメインメンバーサーバーかドメインメンバークライアント, User Rights and Privileges, 信頼されるドメインとしてのSamba
アカウント属性, プライマリドメインコントローラー
アカウント情報, Microsoft Windows NT4スタイルのドメイン制御, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, RFC 2307 posixAccountとの関係とスキーマ, UNIXとWindowsのユーザー管理
アカウント情報データベース, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング
アカウント格納バックエンド, passdbバックエンドと認証
アカウント管理, pdbeditツール, プライマリドメインコントローラー
アカウント設定の移行, ユーザーとグループアカウント
アクセスの権利, 信頼関係に関する背景情報
アクセスの許可, ホストベースの保護の使用
アクセスコントロールリスト, ファイル、ディレクトリと共有のアクセス制御
アクセスポリシー, ドメインアカウントポリシー管理
アクセス制御, 機能と利便性, シングルサインオンとドメインセキュリティ, 機能と利便性, 背景, ドメインログオンの設定: Windows 9x/Me, LDAPに関するコメント, pdbeditツール, WindowsグループからUNIXグループへのマッピング, 機能と利便性, ディレクトリとファイルの削除操作からの保護, 共有のアクセス制御, 詳細なネットワーク管理, 目的
アクセス制御の必要性, サーバーの共有とディレクトリのレイアウト
アクセス制御エントリ (see ACE)
アクセス拒否, IPC$ 共有ベースの拒否の使用
アクセス権, 機能と利便性, 概要
アクセス認証, 分散マシン上の共通のUID/GIDマッピング
アップロード, Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー
アップロードされたドライバー, [global]セクション
アプライアンス, 対象となるユーザー
アプリケーションサーバー, 機能と利便性
アーキテクチャ, LDAPに関するコメント
イベントビューワ, リモートサーバー管理
インタフェース, Microsoft Windows XP Professional, インタフェース保護の使用
インタフェースベースの除外, 機能と利便性
インターネット, ホストベースの保護の使用, インタフェース保護の使用
インターネットプロトコル TCP/IP, Microsoft Windows Me
インフラストラクチャ, LDAPに関するコメント
イーサネットアダプター, インタフェース保護の使用
ウィルススキャナ, 議論
エクスポートされたファイルシステム, 簡単なソリューション
エラーメッセージ, ADSドメイン, adddriverを付けたprinter driver filesの実行, 前提条件
エンコード, サーバー設定のテスト
エンタープライズ, smbpasswd: 暗号化したパスワードデータベース
オフィスサーバー, セキュアな読み書き可能ファイルと印刷サーバー
オブジェクトクラス, 新しいスキーマ
オブジェクトクラスの定義, 新しいスキーマ
カスタマイズした印刷コマンド, カスタム印刷コマンド
カスタムスクリプト, smbpasswd: 暗号化したパスワードデータベース
キャッシュされた
パスワード, パスワードの検査
キャッシュされたローカルファイル, Opportunistic Lockingの概要
キャッシュされた参照, 不正なキャッシュされた共有参照はネットワークブラウジングに影響する
キャッシュされた暗号化パスワード, セキュリティに関する重要な注意事項
キャッシング, Opportunistic Lockingの概要
キャラクターデバイス, ファイルとディレクトリのアクセス制御
クライアント-サーバーモード, smbpasswdツール
クライアントに対して印刷を有効にする, 簡単な印刷設定
クライアントのドメインへの参加, 権限の説明
クライアントの操作, 機能と利便性
クライアントサイドのキャッシング, Opportunistic Lockingの概要
クライアントサイドのデータキャッシング, PDM Data Shares
クライアントマシンの追加, “net rpc rights”ユーティリティの使用
クライアント用Microsoftネットワーク, ドメインログオンの設定: Windows 9x/Me
クラスターサービス, 最先端の状況
クラスターリング技術, 最終目的
クラスター化されたsmbd, サーバープールの通信
クラスター化されたファイルサーバー, 最終目的
クロスポスト, メーリングリストにからの助言
クロックスキュー, /etc/krb5.confの設定
グループ, ユーザーとグループの変更, LDAPディレクトリとWindowsのコンピュータアカウント, UNIXとWindowsのグループ管理
アカウント, ドメイン制御: 設定例
マッピング, 機能と利便性
グループSID, セキュリティ識別子(SID)の管理
グループのアクセス許可, サーバーの共有とディレクトリのレイアウト
グループの所有者, 機能と利便性
グループの移行, ユーザーとグループアカウント
グループアカウント, ドメインログオンの設定: Windows 9x/Me, LDAPとSambaに対する注意, 機能と利便性, 管理に関する重要な情報, ドメインメンバーサーバーかドメインメンバークライアント, バックアップドメインコントローラー
グループプロファイル, グループプロファイルの作成と管理
グループポリシー, ドメイン制御: 設定例, 機能と利便性
グループポリシーエディター, Windows 9x/ME ポリシー, Windows NT4/200x, Samba-3実装の選択
グループポリシーオブジェクト, 目的 (see GPO)
グループポリシーコンテナ (see GPC)
グループポリシーテンプレート (see GPT)
グループマッピング, ユーザーとグループの変更, Samba-3.0.23でのグループマッピングの変更, グループのマッピング: Microsoft Windows と UNIX
グループメンバーシップ, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
グループ権限, 議論
グループ管理, 概要, UNIXとWindowsのグループ管理, 管理ユーザーの権限と権利
グローバルのprint command, カスタム印刷コマンド
グローバルセクション, [global]セクション
グローバルレベル, 印刷に関連する設定パラメーター
ケースオプション, 大きなディレクトリの取扱い
ケース無区別, 大きなディレクトリの取扱い
ケース照合, 大きなディレクトリの取扱い
ゲストアカウント, 集中印刷サーバー, カスタム印刷コマンド
ゲートウェイアドレス, Microsoft Windows XP Professional
コアファイル, 内部エラー
コネクションを切断する, NT4/200x のユーザープロファイル
コピーアンドペースト, NoMachine.Comによるリモート管理
コマンドラインユーティリティ, “net rpc rights”ユーティリティの使用
コマンド行, リモートとローカル管理:Netコマンド
コメントの削除, 機能と利便性
コリジョン, Linuxカーネルを変更した事によるSambaパフォーマンス問題
コンテナ, コンピュータアカウントの作成
コントロールパネル, ドメインへの参加: Windows 2000/XP Professional
コンパイル, Sambaの入手とインストール
コンピュータの管理, 共有のアクセス制御, Windows 200x/XP
コンピュータアカウント, Windows NT4 クライアント, サーバー設定のテスト, アカウント情報データベース, LDAPディレクトリとWindowsのコンピュータアカウント, User Rights and Privileges
コンピュータアカウントの作成, Windows NT4 クライアント, /etc/krb5.confの設定
コンピュータ名, ドメインへの参加: Windows 2000/XP Professional, ドメインログオンの設定: Windows 9x/Me, Microsoft Windowsネットワーク内でのような名前解決
コンプライアンス, pdbeditツール
コードページ, 機能と利便性
サブネット, NetBIOS over TCP/IP, ワークグループのブラウジングの設定
サブネットマスク, Microsoft Windows XP Professional, Microsoft Windows Me, テスト
サブネット越えのブラウジング, サブネット間のブラウジング
サブネット越しのブラウジング, ネットワークブラウジング
サブネット越しのブラウズ, サブネット間のブラウジング
サブネット間でのブラウジング, どのようにブラウジングは機能するか
サブネット間のブラウジング, ワークグループのブラウジングの設定, WINSサーバーの設定, サブネット間ブラウジングの動作
サポート, Samba サポート
サーバーの再起動, 権限の説明
サーバーの故障, これがなぜ難しいか?
サーバータイプ, サーバータイプ, 概要, SambaサーバーのサーバータイプとIDMAP
スタンドアロン, スタンドアロンサーバー
ドメインコントローラー, ドメインコントローラー
ドメインメンバー, ドメインメンバーサーバー, 設定例, 設定例, 機能と利便性
サーバープール, 分散ファイルシステムの試み, 分散ファイルシステム上の限定的な制約
サーバーマネージャ, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, マシン信頼アカウントの手動作成, NT4サーバーマネージャによるドメインマシンアカウントの管理, リモートサーバー管理
サーバーモード, 何がSambaをドメインコントローラーにするか?
サーバーリソースのブラウズ, 問題の解決方法
サーバー設定のテスト, /etc/krb5.confの設定
サービスの継続性, 高可用性サーバー製品
サービスレベル, 印刷に関連する設定パラメーター, [global]セクション
サービス不能, インタフェース保護の使用
シェアモード, 機能と利便性
シェアモードサーバー, 機能と利便性
シェルスクリプト, 印刷コマンド
システムアカウント, ユーザーアカウントマネージャ
システムインタフェーススクリプト, User Rights and Privileges
システムグループ, WindowsグループからUNIXグループへのマッピング
システムセキュリティ, 3.0.11より前のバージョンのみに適用
システムツール, 特徴と利点
システムポリシー, システムポリシーの作成と運用
システムポリシーエディター, システムポリシーの作成と運用, Windows 200x/XPポリシーの管理, MS Windows 9x/Me
システム管理者, User Rights and Privileges
シャットダウンの中止, 権限の説明
シャドウパスワードファイル, Samba-3でNT4形式でのドメインに参加する
シャドーコピー, Shadow Copy のセットアップ
ショートカット, TCP/IP設定, Microsoft Windows NTFSとUNIXファイルシステムとの比較, Windows 9x/Me のプロファイル設定
シンクライアント, ThinLincを使うリモート管理
シングルサインオン, 機能と利便性, 考慮すべき警告, 目的 (see SSO)
シングルユーザーモード, 用件
シングルログオン, Windows 9x/Meにおける特別な例
シンボリックリンク, 特徴と利点
スキャナモジュール, 議論
スキーマ, RFC2307bis Schema拡張を使ったADSからのIDMAPとNSSに対するLDAPの使用
スキーマファイル, 新しいアカウント格納システム
スクリプト, Sambaでのブラウジングサポート, LDAPとSambaに対する注意
スケーラビリティ, 機能と利便性
スタックトレース, 内部エラー
スタンドアロン, サーバータイプ, ドメイン制御の準備, 概要, ドメインメンバーサーバーかドメインメンバークライアント
スタンドアロンサーバー, スタンドアロンサーバー, 機能と利便性, 背景, ユーザーアカウントの追加, スタンドアロンSambaサーバー, 機能と利便性, ドメインレイアウト
スティッキービット, ファイルとディレクトリのアクセス制御, サーバーの共有とディレクトリのレイアウト
スナップショット, Shadow Copy のセットアップ
スプーリング, カスタム印刷コマンド, 集中スプール対“ピアツーピア”印刷
ピアツーピア, 集中スプール対“ピアツーピア”印刷
集中, 集中スプール対“ピアツーピア”印刷
スプールされたファイル, 技術的な序論
スプールのみ, 直接印刷機能:Windowsクライアント上のベンダドライバー
スプールのパス, testparmによる設定の検査
スプールファイル, カスタム印刷コマンド
スレーブサーバー, ドメインレイアウト
セカンダリコントローラー, ドメインレイアウト
セキュア, 機能と利便性
セキュアでない, ホストベースの保護の使用
セキュアなネットワーク, 序論
セキュリティ, Sambaセキュリティモード, ドメイン制御の準備
モード, 機能と利便性
セキュリティの欠陥, なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?
セキュリティの設定, Samba-3.0.xにおける新しい機能
セキュリティアカウント, 概要
セキュリティコンテキスト, ドメインメンバーサーバー, 信頼関係に関する背景情報
セキュリティドメイン, 信頼関係に関する背景情報
セキュリティポリシー, なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?
セキュリティモード, サーバータイプとセキュリティモード, Sambaセキュリティモード
セキュリティレベル, Sambaセキュリティモード, サーバーセキュリティ(ユーザーレベルのセキュリティ)
セキュリティ識別子, セキュリティ識別子(SID)の管理 (see SID)
セクション, 大きなディレクトリの取扱い
セクション名, 設定ファイルの文法
セグメント間のブラウジング, NetBIOS over TCP/IP
セッションサービス, 機能と利便性
ゼロベースのブロードキャスト, ブロードキャストアドレスについての注意
ソケット, 複数のサーバーのホスティング
ターミナルサーバー, ThinLincを使うリモート管理, SMBリクエストの分割
ダイナミックDNS (see DDNS)
チェックサム検索, Rsync
チャレンジ/レスポンスメカニズム, セキュリティに関する重要な注意事項
ツール, 集中印刷サーバー, LDAPとSambaに対する注意, Windows 200x/XP
テンプレート, グループプロファイルの作成と管理
テープ, サーバーの共有とディレクトリのレイアウト
ディザスタリカバリ, サーバーの共有とディレクトリのレイアウト
ディスク, 暗号化されたパスワードの長所
ディスクアクセス制御, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
ディスクスペース, サーバーの共有とディレクトリのレイアウト
ディストリビューション, Samba-3でNT4形式でのドメインに参加する
ディレクトリ, Active Directoryドメイン制御, 集中印刷サーバー, バックアップドメインコントローラー
ディレクトリのパーミッション, ファイル、ディレクトリと共有のアクセス制御, ディレクトリとファイルの削除操作からの保護
ディレクトリの保護, ディレクトリとファイルの削除操作からの保護
ディレクトリの区切り文字, Microsoft Windows NTFSとUNIXファイルシステムとの比較
ディレクトリの設定, ファイルとディレクトリのアクセス制御
ディレクトリをメモリに読み込む, 大きなディレクトリの取扱い
ディレクトリアクセスのパーミッション, ファイル、ディレクトリと共有のアクセス制御
ディレクトリサーバー, ldapsam
ディレクトリスキーマ, プライマリドメインコントローラー
ディレクトリ制御, ファイル、ディレクトリと共有のアクセス制御
ディレクトリ情報ツリー (see DIT)
デスクトッププロファイル, ドメイン制御: 設定例, Microsoft Windows NT4スタイルのドメイン制御, 機能と利便性, セキュリティ識別子(SID)の管理
デスクトップ・キャッシュ, Windows 9x/Me のプロファイル設定
デバイスモード, 新しいプリンターに対するデバイスモードの設定
デバイス固有のコマンド, 非PostScriptプリンターのためのPostScriptプリンター記述
デバッギング, Sambaそれ自身によるデバッグ
デバッグ, デバッグ固有の操作
デフォルトゲートウェイ, Microsoft Windows XP Professional
デフォルトプロファイル, Windows ユーザーのデフォルトプロファイル, デフォルトプロファイルを変更する
デフォルトユーザー, MS Windows 200x/XP
データの交換, ファイル、ディレクトリと共有のアクセス制御
データの破壊, UNIXまたはNFSクライアントがアクセスしたファイル
データの破損, 共有とディレクトリのブラウジングが非常に遅い
データの解析, 診断ツール
データストリーム, 技術的な序論
データベース, お手軽移行ガイド
トラブルシュート, 手っ取り早い設定の検証, Windowsに接続された印刷へのCUPSからの印刷
トランスポートレイヤのセキュリティ (see TLS)
トランスポート層の接続断, Opportunistic Lockingの概要
トランスポート層セキュリティ, TLS
概要, 概要
トリガ, ドメイン制御の準備
トレーニングコース, バックアップ手段についての議論
ドイツ, 技術的な議論
ドメイン, Windows 9x/Meにおける特別な例, ユーザーアカウントの追加, Microsoft Windowsネットワーク内でのような名前解決
groups, UNIXとWindowsのグループ管理
コントローラー, 機能と利便性, ドメインセキュリティモード(ユーザーレベルのセキュリティ), ドメイン制御, 機能と利便性
変換, ドメインコントローラーの種類
階層, ドメインコントローラーの種類
セキュリティ, ドメインセキュリティモード(ユーザーレベルのセキュリティ)
プロトコル, 機能と利便性
マスター
ブラウザー, ドメイン制御の準備
メンバー, サーバータイプ, 機能と利便性, ドメインコントローラーの種類
サーバー, 機能と利便性
メンバーサーバー, 機能と利便性
制御, サーバータイプ
役割, ドメインコントローラーの種類
ドメインSID, バックアップドメインコントローラーの設定
ドメインに参加, ドメインメンバーサーバー, Samba-3でNT4形式でのドメインに参加する, SambaサーバーをPDCドメインに参加させる
ドメインに参加できない, よくあるエラー
ドメインに対するNT4ユーザーマネージャ, “net rpc rights”ユーティリティの使用
ドメインのサーバーマネージャ, NT4サーバーマネージャによるドメインマシンアカウントの管理
ドメインの信頼, NT4ドメイン信頼関係の作成
ドメインの信頼を許可する, IDMAP_RIDを使うWinbind
ドメインへの参加, 存在するマシンアカウントがあるためにドメイン参加に失敗する, Samba-3でNT4形式でのドメインに参加する, ドメインへの参加: Windows 2000/XP Professional, SambaサーバーをPDCドメインに参加させる
ドメインへの参加権利, 権限の説明
ドメインアカウントのアクセスポリシー, ドメインアカウントポリシー管理
ドメイングループ, Samba-3.0.23でのグループマッピングの変更, グループのマッピング: Microsoft Windows と UNIX, 既定値のユーザー、グループと相対識別子, 機能と利便性
ドメイングループの列挙, Microsoft Remote Procedure Calls
ドメイングローバルグループ, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, 概要, Windowsクライアントの管理が出来る権利と権限は何か?
ドメイングローバルユーザー, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, Windowsクライアントの管理が出来る権利と権限は何か?
ドメインコンテキスト, ドメインレイアウト
ドメインコントローラー, SambaによるADSドメイン制御, セキュリティモードとマスターブラウザー, 基本的な背景情報について, Microsoft Windows NT4スタイルのドメイン制御, Active Directoryドメイン制御, NetBIOS Over TCP/IPが有効, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, Samba-3でNT4形式でのドメインに参加する, User Rights and Privileges, 考慮すべき警告, Winbindが提供するもの, SambaサーバーをPDCドメインに参加させる, システムポリシーの作成と運用, Microsoft Windows 200x/XP Professionalのポリシー, 詳細設定のテクニック, Samba-3.0.xにおける新しい機能, ドメインレイアウト, 移行プロセスの手順
ドメインコントローラーのリスト, Samba-3でNT4形式でのドメインに参加する
ドメインコントローラーへの位置づけ, どのようにワークステーションがそのドメインコントローラーを探すか?
ドメインサーバーマネージャ, 3.0.11より前のバージョンのみに適用
ドメインセキュリティ, 機能と利便性, Microsoft Windows NT4スタイルのドメイン制御, ドメインメンバーシップ, 機能と利便性, ドメインメンバーサーバー, Samba-3でNT4形式でのドメインに参加する, これがなぜsecurity = serverよりもすぐれているのか?, ドメインへの参加: Windows 2000/XP Professional, セキュリティに関する重要な注意事項, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, プライマリドメインコントローラー
ドメインセキュリティアカウント, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
ドメインプロファイル, Windows NT4形式のポリシーファイル
ドメインボタン, ドメインへの参加: Windows 2000/XP Professional
ドメインマシンアカウントの作成, ドメインメンバーサーバー
ドメインマスター, Sambaでのブラウジングサポート
ドメインメンバー, ドメインセキュリティモード(ユーザーレベルのセキュリティ), ドメイン制御の準備, ドメインメンバーシップ, 機能と利便性, Windows 200x/XP Professionalクライアント, よくあるエラー, ドメインへの参加: Windows 2000/XP Professional, ドメインブラウジングの設定, セキュリティに関する重要な注意事項, 議論, 概要, ドメインメンバーサーバーかドメインメンバークライアント, 外部のSIDの取り扱い, はじめに, ドメインレイアウト
ドメインメンバーの
ジョイン, 設定例
ドメインメンバーのワークステーション, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
ドメインメンバーの作成, Windows 200x/XP Professionalクライアント
ドメインメンバークライアント, 管理に関する重要な情報 (see DMC)
ドメインメンバーサーバー, 設定例, ドメインメンバーサーバー, Samba-3でNT4形式でのドメインに参加する, TCP/IPなしのNetBIOS, 分散マシン上の共通のUID/GIDマッピング, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, ドメインメンバーサーバーかドメインメンバークライアント, User Rights and Privileges, 機能と利便性 (see DMS)
ドメインメンバーシップ, ドメイン制御の準備, ドメイン制御: 設定例, ドメインメンバーシップ
ドメインユーザー, ドメインログオンの設定: Windows 9x/Me, 機能と利便性, Winbindが提供するもの, 用件, Linux/FreeBSD固有のPAM設定, 結論
ドメインユーザーの列挙, Microsoft Remote Procedure Calls
ドメインユーザーアカウント, UNIXとWindowsのグループ管理
ドメインユーザーマネージャ, ユーザーアカウントマネージャ, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, 3.0.11より前のバージョンのみに適用, NT4ドメイン信頼関係の作成, アカウント/ユーザーポリシーの管理
ドメインレベル, これがなぜsecurity = serverよりもすぐれているのか?
ドメインレベルのセキュリティ, Samba-3でNT4形式でのドメインに参加する
ドメインログオン, ドメイン制御: 設定例, ドメインとネットワークログインの設定, ドメインネットワークログオンサービス, Windows 9x/Meにおける特別な例, PDCの設定例, ドメインログオンの設定: Windows 9x/Me, Sambaでのブラウジングサポート, セキュリティに関する重要な注意事項
ドメインログオンサーバー, Windows 9x/Me のプロファイル設定
ドメイン全体のブラウズリスト, Sambaをドメインマスターにする
ドメイン制御, ドメイン制御の基礎, セキュリティモードとマスターブラウザー, よくあるエラー, 機能と利便性, ドメインメンバーサーバーかドメインメンバークライアント, NT4 PDC からSamba-3 PDCへの移行
backup, サーバータイプ
primary, サーバータイプ
ドメイン制御データベース (see SAM)
ドメイン名, ドメインログオンの設定: Windows 9x/Me
ドメイン外, WINSサーバーの設定
ドメイン環境, セキュリティに関する重要な注意事項
ドメイン用のユーザーマネージャ, リモートサーバー管理
ドメイン管理ツール, NT4サーバーマネージャによるドメインマシンアカウントの管理
ドメイン間, SambaにおけるNT形式のドメイン信頼関係の設定
信頼
アカウント, 機能と利便性
信頼関係, 機能と利便性
ドメイン間の信頼, ドメイン間の信頼関係, 機能と利便性, Windows 2000との間での、NT4形式のドメイン信頼関係, Samba-3.0.xにおける新しい機能
ドメイン間の信頼関係, 概要, SambaにおけるNT形式のドメイン信頼関係の設定
ドメイン間の接続, 信頼するドメインとしてのSamba
ドメイン間信頼アカウント, アカウント情報データベース, LDAPとSambaに対する注意
ドメイン間信頼関係
機能, ドメイン間信頼関係の機能
ドメイン非メンバー, 外部のSIDの取り扱い
ドライバー CDROM, ドライバーファイルの識別
ドライバーのアップロード, 機能と利便性, Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー
ドライバーのインストール, 機能と利便性, Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー
ドライバーのダウンロード, [print$]セクションのパラメーター
ドライバーの管理, 機能と利便性
ドライバーの追加, [global]セクション
ドライバーパス, ドライバーファイルの識別
ドライバーファイル, ドライバーファイルの識別
ドライバーファイルの登録, adddriverを付けたprinter driver filesの実行
ドライブの識別, Microsoft Windows NTFSとUNIXファイルシステムとの比較
ネイティブモード, Microsoft Active Directoryサービス
ネゴシエート, セキュリティに関する重要な注意事項
ネストされたグループ, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
ネストされたグループのサポート, Windowsクライアントの管理が出来る権利と権限は何か?
ネットワーク
パフォーマンス, ドメインコントローラーの種類
ブラウジング, 機能と利便性
ログオン
, セキュリティモードとマスターブラウザー
ネットワークID, ドメインへの参加: Windows 2000/XP Professional
ネットワークが遅い, Linuxカーネルを変更した事によるSambaパフォーマンス問題
ネットワークに繋がったワークステーション, Name Service Switch
ネットワークの設定, サブネット間のブラウジング
ネットワークアクセス, Sambaのパフォーマンスがとても悪い
ネットワークアクセスプロファイル, Microsoft Windows NT4スタイルのドメイン制御
ネットワークアクセス制御, ファイル、ディレクトリと共有のアクセス制御
ネットワークアナライザ, 診断ツール
ネットワークインタフェース, インタフェース保護の使用, テスト
ネットワーククライアント, Microsoft Windows 2000, 識別情報のマッピング(IDMAP)
ネットワークコンピュータ, 問題の解決方法, サブネット間ブラウジングの動作, [global]セクション, Sambaがドライバーを認識したかの確認
ネットワークシステム, よくあるエラー
ネットワークストレージ, BackupPC
ネットワークスニファ, 暗号化されたパスワードの長所
ネットワークセキュリティ, ドメインレイアウト
ネットワークセグメント, NetBIOS over TCP/IP, ドメインレイアウト
ネットワークトラフィック, ドメインメンバーサーバーかドメインメンバークライアント
ネットワークハードウェアの不良, 共有とディレクトリのブラウジングが非常に遅い
ネットワークバンド幅, 強制的にSambaをマスターにする, ドメインレイアウト
ネットワークブラウジングが遅い, 不正なキャッシュされた共有参照はネットワークブラウジングに影響する
ネットワークブラウジングの問題, Sambaをドメインマスターにする, 共有とディレクトリのブラウジングが非常に遅い
ネットワークプロパティ, ドメインログオンの設定: Windows 9x/Me
ネットワークポリシー, システムポリシーの作成と運用
ネットワークメンバーシップ, 技術的な詳細
ネットワークモニター, Windowsのネットワークモニター
ネットワークモニターツールとエージェント, NTワークステーション上へのネットワークモニターのインストール
ネットワークログオン, Windows 9x/Meにおける特別な例, 機能と利便性, ドメインログオンの設定: Windows 9x/Me
ネットワークログオンサービス, Windows 9x/Meにおける特別な例
ネットワークログオンサービスがない, 背景
ネットワーク擁護者, バックアップ手段についての議論
ネットワーク環境, LDAPとSambaに対する注意
ネットワーク管理, リモートデスクトップ管理
ネットワーク管理者, ファイル、ディレクトリと共有のアクセス制御, サーバーの共有とディレクトリのレイアウト
ネットワーク管理者の道具箱, リモートとローカル管理:Netコマンド
ネットワーク経由での送信, 暗号化されたパスワードの長所
ネットワーク設定の問題, TCP/IP設定
ネームサービススイッチ (see NSS)
ノベル, Windows 9x/Me のプロファイル設定
ノベルネットワーク用クライアント, Windows 9x/Me のプロファイル設定
ノードタイプ, NetBIOS over TCP/IP
ハードウェア不良, 共有とディレクトリのブラウジングが非常に遅い
バイト幅, 議論
バイト幅のロッキング, 議論
バイト幅ロッキング, Opportunistic Lockingの概要
バイト幅ロック, 議論
バグの報告, 概要
バックアップ, 用件, 特徴と利点, サーバーの共有とディレクトリのレイアウト, 特徴と利点
バックアップソリューション, バックアップ手段についての議論
バックアップドメインコントローラー, ドメインレイアウト
バックエンド, Passdbの変更, 分散ファイルシステムの試み
バックエンドの障害, 高可用性サーバー製品
バックエンドデータベース, ドメインコントローラーの種類, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, マシンのドメインへの追加に失敗する
バナーページ, WindowsのCUPS PostScriptドライバー対Adobeドライバー
パイプデバイス, ファイルとディレクトリのアクセス制御
パケットキャプチャー, Windows 9x/Me のプロファイル設定
パケット追跡, Windows 9x/Me のプロファイル設定
パスの指定, マシンのドメインへの追加に失敗する
パスワード, Microsoft Windows NT4スタイルのドメイン制御, はじめに
平文, Windows 9x/Meにおける特別な例
パスワードが割り当てられた, NT4ドメイン信頼関係の構築完了
パスワードのデバッグ, Sambaそれ自身によるデバッグ
パスワードのロック, 集中印刷サーバー
パスワードの一意性, シングルサインオンとドメインセキュリティ
パスワードの変更, マシン信頼アカウントの手動作成, 注意, smbpasswdツール
パスワードの暗号化, 平文
パスワードの設定, 集中印刷サーバー
パスワードサーバー, サーバーセキュリティ(ユーザーレベルのセキュリティ), smb.confの設定
パスワードスキーム, セキュリティに関する重要な注意事項
パスワードデータベース, バックアップドメインコントローラーの設定, 信頼されるドメインとしてのSamba
パスワードバックエンド, 参照用文書サーバー, アカウント情報データベース, ユーザーとマシンアカウントの表示
パスワードプロンプト, 暗号化されたパスワードの長所
パスワード変更機能, SWATを使用できるように有効化する
パスワード履歴, シングルサインオンとドメインセキュリティ
パスワード満了, ユーザーアカウントの変更
パスワード管理, Pluggable Authentication Modules
パッケージ, Sambaの入手とインストール
パフォーマンス, 大きなディレクトリの取扱い, 目的
パフォーマンスが悪い, Sambaのパフォーマンスがとても悪い
パフォーマンスベース, tdbsam
パフォーマンス劣化, 大きなディレクトリの取扱い
パラメーター, 手っ取り早い設定の検証
パーティションの作成, Shadow Copy のセットアップ
パーミッション, なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?, Shadow Copy のセットアップ
UNIXのファイルとディレクトリ, 機能と利便性
ファイルとディレクトリのACL, NTセキュリティダイアログを使用したUNIXパーミッションの管理
パーミッションと制御, 機能と利便性
パーミッション偽装モジュール, 必須プロファイル
ファイアウォール, 序論, インタフェース保護の使用, テスト
ファイアウォールが有効, ファイアウォールの使用
ファイアウォールの設定, ファイアウォールの使用
ファイルの保護, ディレクトリとファイルの削除操作からの保護
ファイルの削除, ディレクトリとファイルの削除操作からの保護
ファイルの所有者, 機能と利便性
ファイルの正規化, 大きなディレクトリの取扱い
ファイルアクセスのパーミッション, ファイル、ディレクトリと共有のアクセス制御
ファイルアクセスの監査, audit
ファイルサービス, 機能と利便性
ファイルシステム, Microsoft Windows NTFSとUNIXファイルシステムとの比較
UNIX, Microsoft Windows NTFSとUNIXファイルシステムとの比較
Windows, Microsoft Windows NTFSとUNIXファイルシステムとの比較
大文字小文字の区別, Microsoft Windows NTFSとUNIXファイルシステムとの比較
機能の比較, Microsoft Windows NTFSとUNIXファイルシステムとの比較
ファイルマネージャ, 問題の解決方法
ファイル名に関する規則, Microsoft Windows NTFSとUNIXファイルシステムとの比較
フェイルオーバーサーバー, 簡単なソリューション
フェイルオーバープロセス, 高可用性サーバー製品
フランス語, SWAT国際化サポートの有効化
フレーミングエラー, Linuxカーネルを変更した事によるSambaパフォーマンス問題
フロントエンド仮想サーバー, SMBリクエストの分割
ブラウザー選択, ワークグループのブラウジングの設定, ドメインブラウジングの設定, 強制的にSambaをマスターにする
ブラウジング, Windows 9x/Meにおける特別な例, ブラウジングとは何か?, Sambaをドメインマスターにする, Sambaでのブラウジングサポート
ブラウジングが遅い, 共有とディレクトリのブラウジングが非常に遅い
ブラウジングの問題, Windowsのネットワークプロトコル, よくあるエラー, "Unable to browse the network"というエラーメッセージが出た。
ブラウズリスト, ドメイン制御の準備, どのようにブラウジングは機能するか, Sambaをドメインマスターにする, WINS: The Windows Internetworking Name Server, サブネット間のブラウジング, サブネット間ブラウジングの動作
ブラウズリストのハンドリング, ネットワークブラウジング
ブラウズリストの管理, ブラウジングとは何か?
ブラウズリストメンテナ, どのようにブラウジングは機能するか
ブラウズリスト管理, セキュリティモードとマスターブラウザー
ブロックデバイス, ファイルとディレクトリのアクセス制御
ブロードキャスト, ネットワーク上のドメインコントローラーになれる要件, NetBIOS over TCP/IP, 強制的にSambaをマスターにする, サブネット間ブラウジングの動作
ブロードキャストが届かないサブネット, 強制的にSambaをマスターにする
ブロードキャストのトラフィック, サブネット間のブラウジング
ブロードキャストアドレス, 問題の解決方法, テスト
ブロードキャストベース, NetBIOS over TCP/IP
ブロードキャストベースの名前解決, Samba-3でNT4形式でのドメインに参加する
ブロードキャストメッセージ, NetBIOS over TCP/IP
ブロードキャストリクエスト, Windows 9x/Meにおける特別な例
ブートディスク, 用件
プライベートネットワーク, 序論, ホストベースの保護の使用
プライマリWINSサーバー, WINSサーバーの設定
プライマリグループ, マシン信頼アカウントの手動作成
プライマリドメインコントローラー, 複数の仮想サーバーホスティング
プラットフォーム, 移植性
プリンター, 機能と利便性
プリンターとFAX, Sambaがドライバーを認識したかの確認
プリンターのマイグレーション, 概要
プリンターの公開, 手っ取り早い設定の検証, Samba-2.2からの印刷環境
プリンターの既定値のアクセスパーミッション, Samba-2.2からの印刷環境
プリンターの設定, testparmによる設定の検査
プリンターアイコン, Sambaがドライバーを認識したかの確認
プリンターウィザードによる追加, ドライバーアップロード手法
プリンターウィザードの追加, Samba-2.2からの印刷環境
プリンターオブジェクト, Samba-2.2からの印刷環境
プリンタードライバー, Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー, [print$]共有の作成, CUPSを使う簡単なsmb.confの設定, すばらしい統一の達成
プリンタードライバーのマッピング, setdriverを付けたrpcclientの実行
プリンタードライバーのロード, 任意の[my_printer_name]セクション
プリンタードライバーデータ, 新しいプリンターに対するデバイスモードの設定
プリンタードライバーファイル, 無効になった [printer$]セクション, smbclientによるドライバーインストールの確認
プリンタープロパティの設定, [global]セクション
プリンタープーリング, Sambaとプリンターポート
プリンターモニター, Sambaのパフォーマンスがとても悪い
プリンター共有, [global]セクション
プリンター属性の公開, Samba-3.0.xにおける新しい機能
プリンター管理, 概要, 管理ユーザーの権限と権利
プリンター追加ウィザード, 機能と利便性, [global]セクション
プリントキュー, Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー, 指定したドライバー名の自由度
プロトコルスタックの設定, Microsoft Windows 2000
プロパティ, Microsoft Windows Me, ドメインログオンの設定: Windows 9x/Me
プロファイル, ドメイン制御: 設定例, Microsoft Windows NT4スタイルのドメイン制御, 新しいアカウント格納システム, 技術情報, システムポリシーの作成と運用
プロファイルのアクセス権限, グループプロファイルの作成と管理
プロファイルのパス, Windows 9x/Me のプロファイル設定, Windows NT4 workstation
プロファイルの中身, Windows 9x/Me と NT4/200x/XP ワークステーション間でプロファイルを共有する
プロファイルの共有, Windows 9x/Me と NT4/200x/XP ワークステーション間でプロファイルを共有する
プロファイルの混在, Windows Windows 9x/Me と NT4/200x のユーザープロファイルの混在
プロファイルタイプ, 移動プロファイルサポートを無効にする
プロファイルディレクトリー, Windows 9x/Me のプロファイル設定
プロファイル移行ツール, グループプロファイルの作成と管理
ベンダが提供したドライバー, 直接印刷機能:Windowsクライアント上のベンダドライバー
ページャープログラム, 簡単な印刷設定
ページ記述言語 (see PDL)
ホストのセキュリティ, 機能と利便性
ホストの範囲, ホストベースの保護の使用
ホストベースの保護, 機能と利便性
ホスト名, /etc/krb5.confの設定
ホームディレクトリ, マシン信頼アカウントの手動作成, 新しいアカウント格納システム, smbpasswd: 暗号化したパスワードデータベース, winbindddaemonの開始とテスト
ホームディレクトリのテンプレート, Linux/FreeBSD固有のPAM設定
ホームディレクトリのマッピング, なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?
ボランティア, メーリングリストにからの助言
ボリュームの作成, Shadow Copy のセットアップ
ボリュームグループ, Shadow Copy のセットアップ
ポイントアンドプリント, Samba-2.2からの印刷環境, Sambaサーバー上でのポイントアンドプリントによるクライアントドライバー, smbclientによるドライバーインストールの確認, Windowsクライアントドライバーのインストール, ドライバーアップロード手法, cupsomatic/foomaticの役割, cupsaddsmbの実行(Quiet Mode), 15ステップでの手動ドライバーインストール
ポテンシャルマスターブラウザー, 強制的にSambaをマスターにする
ポリシー, システムポリシーの作成と運用, アカウント/ユーザーポリシーの管理, Samba-3実装の選択
ポリシーエディター, システムポリシーの作成と運用, Windows NT4形式のポリシーファイル
ポリシーファイル, 機能と利便性, アカウント/ユーザーポリシーの管理
ポリシー設定, pdbeditツール
ポート 137, テスト
マイネットワーク, ブラウジングとは何か?, 問題の解決方法
マウント, Shadow Copy のセットアップ
マクロ, カスタム印刷コマンド
マシン, LDAPディレクトリとWindowsのコンピュータアカウント
アカウント, ドメインセキュリティモード(ユーザーレベルのセキュリティ)
マシンの参加, Windows NT4 クライアント
マシンアカウント, 機能と利便性, ドメインコントローラーの種類, LDAP設定の注意, マシン信頼アカウントの手動作成, LDAPディレクトリとWindowsのコンピュータアカウント, アカウント管理ツール, アカウントフラグ管理, tdbsam, User Rights and Privileges
マシンアカウントのパスワード
変更プロトコル, Samba-3でNT4形式でのドメインに参加する
マシンアカウントデータベース, Microsoft Windows NT4スタイルのドメイン制御
マシンポリシーオブジェクト, 目的
マシン信頼アカウント, 機能と利便性, ドメイン制御の準備, マシンアカウントが満了し続ける, smbpasswdファイルの複製はどうやるか?, ドメインメンバーシップ, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, マシン信頼アカウントの手動作成, NT4サーバーマネージャによるドメインマシンアカウントの管理, Windows 200x/XP Professionalクライアント, Windows NT4 クライアント, コンピュータアカウントの作成, よくあるエラー, マシンをドメインに追加し直すことができない, アカウント情報データベース, LDAPとSambaに対する注意
UNIXアカウント, マシン信頼アカウントの即時作成
パスワード, ドメイン制御の準備, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, マシン信頼アカウントの手動作成
作成, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, マシン信頼アカウントの即時作成
作成権限, Windows 200x/XP Professionalクライアント
マシン信頼アカウントの作成, Samba-3でNT4形式でのドメインに参加する
マシン名, マシン信頼アカウントの手動作成, /etc/hosts, Microsoft Windowsネットワーク内でのような名前解決
マシン認証, ドメインメンバーサーバー
マスターアナウンス, サブネット間ブラウジングの動作
マスターサーバー, ドメインレイアウト
マスターブラウザー, 強制的にSambaをマスターにする, サブネット間ブラウジングの動作
マッピング, Sambaドメインメンバー間でのユーザーIDマッピング共有, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング, WindowsグループからUNIXグループへのマッピング
マップされていないグループ, ユーザーとグループの変更
マップされていないユーザー, ユーザーとグループの変更
マニュアル, 機能と利便性
マルチバイト文字, 文字セットとユニコードとは何か
マルチバイト文字セット, Samba-3.0.xにおける新しい機能
マルチユーザーデータベース, マルチユーザーデータベース
ミッションクリティカル, Opportunistic Lockingの概要, 機能と利便性
ミドルウェア, LDAPに関するコメント
メカニズム, Samba-3でNT4形式でのドメインに参加する
メカノセット, バックアップ手段についての議論
メタサービズ, 複数仮想サーバーの性質(Personalities)
メタディレクトリ, シングルサインオンとドメインセキュリティ
メッセージングシステム, LDAPに関するコメント
メディアタイプ, cupsomatic/foomaticの役割
メモリ, 暗号化されたパスワードの長所
メモリ中へのキャッシュ, 暗号化されていないパスワードの長所
メンバー, ドメイン制御の準備
メンバーマシン, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
モジュール, 議論, Shadow Copy のセットアップ
ユニキャスト, NetBIOS over TCP/IP
ユニコード, 文字セットとユニコードとは何か, Sambaと文字セット, Samba-3.0.xにおける新しい機能
ユーザー, ユーザーとグループの変更, LDAPディレクトリとWindowsのコンピュータアカウント
ユーザーかグループ, “net rpc rights”ユーティリティの使用
ユーザーとグループ, Winbindが提供するもの
ユーザーと信頼アカウント, アカウント情報データベース
ユーザーのグループ, 管理ユーザーの権限と権利
ユーザーのログオン, User Rights and Privileges
ユーザーの移行, ユーザーとグループアカウント
ユーザーアカウント, LDAPとSambaに対する注意, LDAPディレクトリとWindowsのコンピュータアカウント, ユーザーアカウントマネージャ, アカウントフラグ管理, smbpasswd: 暗号化したパスワードデータベース, UNIXとWindowsのユーザー管理, ドメインメンバーサーバーかドメインメンバークライアント, User Rights and Privileges
追加/削除, smbpasswdツール, アカウントとグループの管理
ユーザーアカウントの
追加/削除, pdbeditツール
ユーザーアカウントの作成, 背景
ユーザーアカウントデータベース, Microsoft Windows NT4スタイルのドメイン制御
ユーザーアクセス管理, 機能と利便性
ユーザーデータベース, バックアップドメインコントローラーの設定, 平文
ユーザーマネージャ, 信頼されるドメインとしてのSamba, 信頼するドメインとしてのSamba, リモートサーバー管理
ユーザーマネージャー, グループプロファイルの作成と管理
ユーザーレベル, Sambaセキュリティモード, ユーザーレベルのセキュリティ
ユーザーレベルのアクセス制御, ドメインログオンの設定: Windows 9x/Me
ユーザーレベルのセキュリティ, 暗号化されたパスワードの長所
ユーザー・プロファイル, Windows 9x/Me のプロファイル設定
ユーザー名, Microsoft Windows NT4スタイルのドメイン制御
ユーザー名とパスワード, ドメインへの参加: Windows 2000/XP Professional
ユーザー属性, smbpasswd: 暗号化したパスワードデータベース
ユーザー管理, smbpasswdツール, pdbeditツール, アカウントとグループの管理, 概要, UNIXとWindowsのグループ管理, 管理ユーザーの権限と権利
ユーザー認証, Microsoft Remote Procedure Calls
ライセンス費用, 目的
ライブラリ, /etc/krb5.confの設定
ラスタイメージプロセッサ (see RIP)
ラスタデバイス, pstoraster
ラスタドライバー, pstoraster
ラスタライズ, pstoraster, cupsomatic/foomatic-rip 対 ネイティブなCUPS印刷
ラップトップ, BackupPC
ランダムなマシンアカウントのパスワード, Samba-3でNT4形式でのドメインに参加する
リサイズ, Shadow Copy のセットアップ
リソースキット, Windows NT4 のプロファイル管理ツール
リソースベースの除外, 機能と利便性
リダイレクション, Winbindが提供するもの
リダイレクタ, Opportunistic Lockingの概要
リポジトリ, ドメインメンバーサーバーかドメインメンバークライアント
リモート X プロトコル, NoMachine.Comによるリモート管理
リモートアップデートプロトコル, Rsync
リモートセグメント, Remote Browse Syncパラメーターの使用, ドメインレイアウト
リモートデスクトップの能力, NoMachine.Comによるリモート管理
リモートデスクトップ管理, リモートデスクトップ管理
リモートドメイン, NT4ドメイン信頼関係の作成, NT4ドメイン信頼関係の構築完了, 信頼されるドメインとしてのSamba
リモートプロシジャーコール (see RPC)
リモートプロシジャーコールシステムサービス (see RPCSS)
リモートプロファイル, Windows 9x/Me のプロファイル設定
リモートログイン, NoMachine.Comによるリモート管理
リモート管理, リモートとローカル管理:Netコマンド, Microsoft Remote Procedure Calls
リンク
hard, Microsoft Windows NTFSとUNIXファイルシステムとの比較
soft, Microsoft Windows NTFSとUNIXファイルシステムとの比較
リンクローダーの設定, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
リードオンリ, 機能と利便性
サーバー, 匿名リードオンリ文書サーバー
リードオンリアクセス, バックアップドメインコントローラー
ルーティングされたネットワークを超えた名前解決, どのようにブラウジングは機能するか
ループバックインタフェース, インタフェース保護の使用, Red Hat Linux
レガシーシステム, シングルサインオンとドメインセキュリティ
レコードのロッキング, 議論
レコードロッキング, 議論
レジストリ, ドメインコントローラーの種類, 技術情報, 機能と利便性, システムポリシーの作成と運用, Microsoft Windows 200x/XP Professionalのポリシー, MS Windows 9x/Me
レジストリの設定, アカウント/ユーザーポリシーの管理
レジストリキー, Windows ユーザーのデフォルトプロファイル
レジストリ変更, セキュリティに関する重要な注意事項
レストア, 特徴と利点
レビューワ, 詳細設定のテクニック
レプリケーション
SAM, バックアップドメインコントローラーの設定
レンジ, UNIXとWindowsのユーザー管理
レンダリング, cupsomatic/foomatic-rip 対 ネイティブなCUPS印刷
ロギング, デバッグ固有の操作
ログのチェック, マシンのドメインへの追加に失敗する
ログインシェル, LDAPに関するコメント
ログイン名, ユーザーのマッピング
ログオン, ドメインセキュリティモード(ユーザーレベルのセキュリティ)
ログオンサーバー, Windows 9x/Meにおける特別な例, MS Windows NT4 Workstation
ログオンスクリプト, 機能と利便性, 目的, ログオンスクリプト
ログオン要求, 基本的な背景情報について, NetBIOS Over TCP/IPが有効, SambaはNT4 PDCのバックアップドメインコントローラーになれるか?
ログオン認証, NetBIOS Over TCP/IPが無効
ログファイル, 前提条件
モニターリング, 前提条件
ログレベル, ADSドメイン, Windows 9x/Me のプロファイル設定
ロッキング, 機能と利便性, 議論
ロッキングのセマンティクス, 機能と利便性
ロッキングのセマンティックス, 議論
ロックのチェック, 議論
ローカル
groups, UNIXとWindowsのグループ管理
マスター
ブラウザー, ドメイン制御の準備
ローカル エリア接続のプロパティ, Microsoft Windows 2000
ローカルUNIXグループ, 概要
ローカルのsmbpasswdファイル, 背景
ローカルのキャッシュ, Windows 9x/Me のプロファイル設定
ローカルアカウント, ドメインメンバーサーバーかドメインメンバークライアント
ローカルエリア接続, Microsoft Windows XP Professional
ローカルキャッシュ, NetBIOSネームキャッシュ
ローカルグループ, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, ドメインメンバーサーバーかドメインメンバークライアント, Windowsクライアントの管理が出来る権利と権限は何か?, Name Service Switch
ローカルグループへのドメインユーザーとグループの追加, Windowsクライアントの管理が出来る権利と権限は何か?
ローカルサブネット, 強制的にSambaをマスターにする
ローカルシステムの印刷, 技術的な序論
ローカルスプール領域, 技術的な序論
ローカルセキュリティポリシー, Windows 200x/XP ローカルセキュリティポリシー
ローカルディスク, BackupPC
ローカルドメイン, 外部のSIDの取り扱い
ローカルプリントドライバー, [print$]セクションのパラメーター
ローカルプロファイル, その特長と利点, 移動プロファイルサポートを無効にする, Windows 9x/Me のプロファイル設定
ローカルマシン信頼アカウント, マシンアカウントが満了し続ける
ローカルマスターブラウザー, ドメインブラウジングの設定, リモートアナウンスパラメーターの使用 (see LMB)
ローカルユーザー, スタンドアロンSambaサーバー, ドメインメンバーサーバーかドメインメンバークライアント, Name Service Switch
ローカルユーザーアカウント, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング
ローカルロックのフラッシュ, Opportunistic Lockingの概要
ローカル認証, 背景
ローカル認証データベース, 背景
ロードされたモジュール, 機能と利便性
ワークグループ, サーバーセキュリティ(ユーザーレベルのセキュリティ), ドメイン制御の準備, Windows 9x/Meにおける特別な例, ドメインログオンの設定: Windows 9x/Me, ワークグループのブラウジングの設定, Sambaをドメインマスターにする, Microsoft Windowsネットワーク内でのような名前解決
メンバーシップ, ドメイン制御の準備
ワークグループのDMB, Sambaでのブラウジングサポート
ワークステーション, 技術情報
ワークフロープロトコル, シングルサインオンとドメインセキュリティ
一番簡単な
設定, 設定の例
一般的な PostScript, MIMEタイプとCUPSフィルタ
一般的なラスタ形式, CUPSフィルタリングアーキテクチャ
一貫したケース, 大きなディレクトリの取扱い
不完全なハードウェア, 共有とディレクトリのブラウジングが非常に遅い
不明なアカウント, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
両面印刷, pstops, フィルタリングチェインの例
主要な変更, 新しい機能
互換, セキュリティに関する重要な注意事項
互換性, 移植性
他のサブネットのブラウジング, Sambaでのブラウジングサポート
代替ソリューション, 目的
仮想サーバー, 最先端の状況, 簡単なソリューション
伝統的な印刷処理, カスタム印刷コマンド
信頼, LDAPディレクトリとWindowsのコンピュータアカウント, 信頼関係に関する背景情報
信頼が確立, ドメイン間信頼関係の機能
信頼されたアカウント, ドメインセキュリティモード(ユーザーレベルのセキュリティ)
信頼されたドメイン, ドメイン間の信頼関係, 信頼関係に関する背景情報, NT4ドメイン信頼関係の構築完了, 信頼するドメインとしてのSamba, Name Service Switch
信頼されたドメインの名前, 信頼されるドメインとしてのSamba
信頼しているドメイン, ドメイン間の信頼関係, 信頼関係に関する背景情報, NT4ドメイン信頼関係の構築完了
信頼アカウント, LDAPディレクトリとWindowsのコンピュータアカウント, アカウントフラグ管理, 概要, Windows 2000との間での、NT4形式のドメイン信頼関係
ドメイン間, 機能と利便性
マシン, 機能と利便性
信頼性, 機能と利便性, 目的
信頼関係, 機能と利便性, 信頼関係に関する背景情報, NT4ドメイン信頼関係の作成, NT4ドメイン信頼関係の構築完了, ドメイン間信頼関係の機能, SambaにおけるNT形式のドメイン信頼関係の設定, Windows 2000との間での、NT4形式のドメイン信頼関係
個別のセクション, [global]セクション
入れ墨効果(tattoo effect), Samba-3実装の選択
入力パケットのブロック, ファイアウォールの使用
共有, ブラウジングとは何か?, ファイル、ディレクトリと共有のアクセス制御, [global]セクション
共有とファイル, 用件
共有のACL, 機能と利便性, Windows 200x/XP, Samba-3実装の選択
共有のパーミッション, Windows NT4 Workstation/Server, Windows 200x/XP
共有のパーミッションの管理, Windows NT4 Workstation/Server
共有のブラウズ, IPC$ 共有ベースの拒否の使用
共有の分割, [global]セクション
共有の追加/削除/変更, 権限の説明
共有アクセス, 共有のアクセス制御
共有セクションの制御, Samba-3実装の選択
共有モード, 分散ファイルシステムの試み
共有レベル, Sambaセキュリティモード, 共有レベルのセキュリティ
共有レベルACLの管理, 3.0.11より前のバージョンのみに適用
共有レベルのACL, 3.0.11より前のバージョンのみに適用
共有単位のアクセス制御, 共有のアクセス制御
共有管理, 概要, 管理ユーザーの権限と権利
共通の制限, アカウント/ユーザーポリシーの管理
内蔵コマンド, カスタム印刷コマンド
内部順, 機能と利便性
再コンパイル, 複数のサーバーのホスティング
再設定, Microsoft Windows NT4スタイルのドメイン制御
再起動, ドメインへの参加: Windows 2000/XP Professional
分割, SMBリクエストの分割
分散アカウント, 新しいアカウント格納システム
分散コンピューティング環境 (see DCE)
分散ディレクトリ, ドメインメンバーサーバー
分散ファイルシステム, 最終目的, 分散ファイルシステムの試み (see DFS)
分散ロックプロトコル, 簡単なソリューション
分散認証システム, 目的
分離されたインスタンス, 複数のサーバーのホスティング
分離されたサーバー, 詳細設定のテクニック
分離されたワークグループ, ワークグループのブラウジングの設定, 複数仮想サーバーの性質(Personalities)
利点, 目的
制限されたDNS, 名前解決の順序
削除されたパラメーター, 削除されたパラメーター
割り当てられた権利, 権利の管理能力, “net rpc rights”ユーティリティの使用
割り当てられた権限, “net rpc rights”ユーティリティの使用
効率のよい認証, その機能と利点
効率の増大, Opportunistic Lockingの概要
動作がほぼ同じ, お手軽移行ガイド
動機, セキュリティモードとマスターブラウザー
動的なSMBサーバー, 目的
動的なロードが可能なライブラリーモジュール, その機能と利点
動的登録ファイル, ダイナミックDNS
包括的な文書, 複数のサーバーのホスティング
匿名, 集中印刷サーバー
プリントサーバー, 匿名プリントサーバー
読み書きサーバー, 匿名の読み書き可能な文書サーバー
匿名アクセス, 問題の解決方法
匿名サーバー, 詳細設定のテクニック
匿名ファイルサーバー, 複数仮想サーバーの性質(Personalities)
単一のDHCPサーバー, Microsoft Windows Me
単一のWINSサーバー, WINSサーバーの設定
単一のリポジトリ, アカウント情報データベース
単一サーバー, 最先端の状況
単一バイト文字, 文字セットとユニコードとは何か
単純さ, 機能と利便性
単純なアクセス制御, サーバーの共有とディレクトリのレイアウト
単純な操作, 新しいアカウント格納システム
単純印刷サーバー, 集中印刷サーバー
印刷の動作, 印刷に関連する設定パラメーター
印刷の設定, testparmによる設定の検査
印刷キュー, smbclientによるドライバーインストールの確認, CUPSバックエンド
印刷コマンド, 印刷コマンド, カスタム印刷コマンド
印刷サブシステム, 技術的な序論, 印刷コマンド
印刷サポート, 機能と利便性, 技術的な序論
印刷サーバー, 集中印刷サーバー, 機能と利便性
印刷サービス, 機能と利便性
印刷システム, LDAPに関するコメント, 技術的な序論
印刷ジョブ, カスタム印刷コマンド
印刷スプーリング, Microsoft Remote Procedure Calls
印刷スプールシステム, Overview
印刷テストページ, 最初のクライアントドライバーインストール
印刷フィルタリング, 技術的な序論
印刷処理, 技術的な序論
印刷呼び出し, Samba-2.2からの印刷環境
印刷環境, 簡単な印刷設定
印刷管理システム, Overview
印刷統計, Postscriptドライバーダウンロードを使う高度に賢い印刷
印刷設定, 技術的な序論
印刷関連の設定, testparmによる設定の検査
即時, Windows NT4 クライアント
参加成功, サーバー設定のテスト
参加済みのクライアント, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
参照用文書, 参照用文書サーバー
双方向
propagation, 機能と利便性
双方向の信頼, 信頼関係に関する背景情報, ネイティブなMicrosoft Windows NT4の信頼関係の設定, ドメイン間信頼関係の機能
古いsambaAccount, 新しいスキーマ
可用性, 機能と利便性, 目的
同じドメイン/ワークグループ, 複数の仮想サーバーホスティング
同時アクセス, Opportunistic Lockingの概要
同期, ドメインコントローラーの種類, バックアップドメインコントローラーの設定, /etc/krb5.confの設定, Remote Browse Syncパラメーターの使用, WINS: The Windows Internetworking Name Server, サブネット間ブラウジングの動作
同期の問題, はじめに
同期作業, サブネット間ブラウジングの動作
名前の短縮, Samba-3.0.xにおける新しい機能
名前の衝突, 任意の[my_printer_name]セクション
名前キャッシュのフラッシュ, SambaのNetBIOS名前キャッシュのフラッシュ
名前タイプ, WINS: The Windows Internetworking Name Server, 名前解決の順序
名前検索, NetBIOS over TCP/IP, どのようにブラウジングは機能するか, NetBIOSネームキャッシュ
名前登録, ネットワーク上のドメインコントローラーになれる要件
名前解決, ブラウジングとは何か?, NetBIOS over TCP/IP, どのようにブラウジングは機能するか, ブラウジングの技術的な概要, よくあるエラー, 前提条件
名前解決の順序, 名前解決の順序
商用Linux製品, ファイル、ディレクトリと共有のアクセス制御
問題のデバッグ, Sambaそれ自身によるデバッグ
固定IPアドレス, TCP/IP設定, Microsoft Windows XP Professional, Microsoft Windows 2000
固有のソケットのリッスン, 複数のサーバーのホスティング
固有のホームディレクトリ, なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?
国際化サポート, ガイドラインと技術的なTips
基盤, 対象となるユーザー
壊れたデータ, アカウントフラグ管理
変換, 技術情報, MIMEタイプとCUPSフィルタ
ドメインメンバーサーバー, ドメインコントローラーの種類
変更されたパラメーター, Samba-2.xからSamba-3.0.25へのアップグレード
変更の動機付け, 目的
外部ドメイン, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング
多数のファイル, 大きなディレクトリの取扱い
大きいディレクトリ, 大きなディレクトリの取扱い
大きなディレクトリ, 大きなディレクトリの取扱い
大きなドメイン, IDMAP_RIDを使うWinbind
大きな組織, 信頼関係に関する背景情報
大文字, /etc/krb5.confの設定, マシンのドメインへの追加に失敗する, グループの追加が失敗する, 大きなディレクトリの取扱い
大文字小文字の区別, PAM 設定のための文法
大文字小文字を区別しない, 簡単な印刷設定
失敗, マシンのドメインへの追加に失敗する, ADSドメイン
失敗したログイン, アカウント管理ツール
奇妙な削除動作, 大きなディレクトリの取扱い
存在する LDAP DIT, LDAPとSambaに対する注意
安全なアクセス, シングルサインオンとドメインセキュリティ
安全な認証, User Rights and Privileges
安全な通信, セキュリティとsambaSamAccount
完全な権限, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
定義済みの共有, なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?
寄贈, 複数のサーバーのホスティング
専用印刷サーバー, 機能と利便性
小文字のファイル名, 大きなディレクトリの取扱い
属性, OpenLDAPの設定, 新しいスキーマ
差分, Rsync
差分転送, Rsync
平文, パスワードの検査, 下位互換性のあるバックエンド, セキュリティに関する重要な注意事項, セキュリティとsambaSamAccount
パスワード, パスワードの検査
平文のパスワード, smbpasswdファイルの複製はどうやるか?
平文パスワード, Windows 9x/Meにおける特別な例, 技術情報, セキュリティに関する重要な注意事項
平文認証, 下位互換性のあるバックエンド
広域ネットワークの帯域, その機能と利点
強制同期, どのようにブラウジングは機能するか
強制選択, Sambaをドメインマスターにする
必要な権利, “net rpc rights”ユーティリティの使用
必須プロファイル, 必須プロファイル
性能の向上, 遅くて信頼できないネットワーク
恒久名, 静的なWINSエントリ
恒久的な変更, Samba-3実装の選択
悩んでいるネットワークユーザー, TCP/IP設定
情報の複製, はじめに
成功した移行, 目的
所有権の取得, ファイルの所有者の表示
所有者権限, Windows 9x/Me のプロファイル設定
手動でのUNIXアカウント作成, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
手動でのWINSサーバーエントリ, Microsoft Windows XP Professional
手動でのWINSサーバー設定, Microsoft Windows 2000
手動によるDNSの設定, Microsoft Windows XP Professional
手動設定, Microsoft Windows Me
技術レビュー, 詳細設定のテクニック
拒否モード, 議論
拡張, Shadow Copy のセットアップ
拡張BSD印刷環境, 拡張印刷設定
拡張MetaFile (see EMF)
拡張プロトコル, Windowsのネットワークプロトコル
拡張属性, ファイル、ディレクトリと共有のアクセス制御, ディレクトリとファイルの削除操作からの保護
拡張性, 機能と利便性, アカウント情報データベース, 機能と利便性
拡張性のあるバックエンド, 機能と利便性
拡張性の向上, 新しいアカウント格納システム
拡張文字セット, 文字セットとユニコードとは何か
接続を拒否, インタフェース保護の使用
接続を無視, インタフェース保護の使用
接続許可, インタフェース保護の使用
攻撃者からの保護, IPC$ 共有ベースの拒否の使用
文字セット, 文字セットとユニコードとは何か, Sambaと文字セット, Samba-3.0.xにおける新しい機能
文字セットの変換, 古い名前からの変換
文書の設計, サーバーの共有とディレクトリのレイアウト
文書化, 機能と利便性
新しいアカウント, 信頼されるドメインとしてのSamba
新しいパラメーター, 新しいパラメーター
既定値のdevmode, 新しいプリンターに対するデバイスモードの設定
既定値のDNS設定, 注意
既定値のグループ, 既定値のユーザー、グループと相対識別子
既定値のシェル, winbindddaemonの開始とテスト
既定値のプリンター, カスタム印刷コマンド
既定値のマッピング, Samba-3.0.23でのグループマッピングの変更, WindowsグループからUNIXグループへのマッピング
既定値のユーザー, 既定値のユーザー、グループと相対識別子
既定値の別名, 既定値のユーザー、グループと相対識別子
既定値の動作, 識別情報のマッピング(IDMAP)
既定値の印刷コマンド, [global]セクション, 既定値のUNIXシステム印刷コマンド
既定値の印刷環境, 機能と利便性
既定値の設定, アカウントフラグ管理
日本でのUNIX, 基本的なパラメーターの設定
日本語, 日本語の文字セット, SWAT国際化サポートの有効化
日本語のロケール, 基本的なパラメーターの設定
昇格, ドメインコントローラーの種類, Microsoft Windows NT4スタイルのドメイン制御
明らかな用途がより好まれる, バックアップ手段についての議論
明示的な設定, 手っ取り早い設定の検証
時刻の形式, ユーザーアカウントの変更
時間差, /etc/krb5.confの設定
暗号化, サーバーセキュリティ(ユーザーレベルのセキュリティ), パスワードの検査, セキュリティに関する重要な注意事項
暗号化されたセッション, セキュリティとsambaSamAccount
暗号化キー, Windows 200x/XP Professionalクライアント
暗号化タイプ, /etc/krb5.confの設定, 注意
暗号化パスワード, パスワードの検査, 機能と利便性, 技術情報, セキュリティに関する重要な注意事項, 暗号化されたパスワードの長所, Windows NT4/200x サーバーから Samba にプロファイルを移行する
暗黙のクラス, “lp”という名前の印刷キューが印刷ジョブを間違って扱ってしまう
書き込みアクセス, ディレクトリとファイルの削除操作からの保護
書き込み権限, コンピュータアカウントの作成
最大値, ドメイン間の信頼関係
最小の
設定, 設定ファイルの文法
最小のセキュリティ制御, スタンドアロンサーバー
最小の設定, 設定ファイルの文法
最終変更時刻, ユーザーとマシンアカウントの表示
有償サポート, 無償サポート
有効, 集中印刷サーバー
有効なプリンター, ブラウジングとは何か?, [global]セクション
有効なポート, Sambaとプリンターポート
有効なユーザー名/パスワード, IPC$ 共有ベースの拒否の使用
有効な権利, “net rpc rights”ユーティリティの使用
望ましい解決方法, Windowsクライアントの管理が出来る権利と権限は何か?
未署名のドライバー, Windows 200x/XP ローカルセキュリティポリシー
未認証のアクセス, ファイル、ディレクトリと共有のアクセス制御
本質的な価値, 目的
検査, 手っ取り早い設定の検証
検証, システムとアカウントポリシー, 概要
権利, 権利の管理能力
権利と権限, 管理ユーザーの権限と権利, 管理者のドメインSID
権利の割り当て, “net rpc rights”ユーティリティの使用
権利の管理, “net rpc rights”ユーティリティの使用
権利の許可, “net rpc rights”ユーティリティの使用
権限, Windows 200x/XP Professionalクライアント, 権利の管理能力, 信頼関係に関する背景情報, Samba-2.2からの印刷環境
権限のバイパス, “net rpc rights”ユーティリティの使用
権限の削除, “net rpc rights”ユーティリティの使用
権限の管理, 権利の管理能力
権限の継承, 議論
権限を付与するアプリケーション, 技術的な議論
権限モデル, 権利の管理能力
機能性, 目的
正しいUNIXシステムアカウント名, マシンのドメインへの追加に失敗する
汎用ラスタ, pstoraster
法律, pdbeditツール
混成のコンピューティング, 機能と利便性
満了したパスワード, ユーザーアカウントの変更
無停止サービス, 最終目的
片方向, 信頼関係に関する背景情報
片方向の信頼, ドメイン間信頼関係の機能
物理ネットワーク転送レイヤ, /etc/hosts
物理的な配置, 特徴と利点
特別なアカウント, User Rights and Privileges, 信頼されるドメインとしてのSamba
特別なセクション, [print$]セクションのパラメーター
特別な節, [print$]セクションのパラメーター
特別セクション, [global]セクション
特権アカウント, “net rpc rights”ユーティリティの使用
特権管理, 管理ユーザーの権限と権利
独立, 背景, 複数のサーバーのホスティング
独立フィルタ, pstoraster
環境変数, カスタム印刷コマンド
生存時間 (see TTL)
異なったリソース, 複数仮想サーバーの性質(Personalities)
異なるプロトコル, お手軽移行ガイド
異なる暗号化パスワード方式, 技術情報
直接印刷, 直接印刷機能:Windowsクライアント上のベンダドライバー
相互に排他なオプション, ブラウジングとは何か?
相互運用性, 機能と利便性, 機能と利便性, シングルサインオンとドメインセキュリティ, 識別情報のマッピング(IDMAP), ファイル、ディレクトリと共有のアクセス制御, 機能と利便性, 分散ファイルシステム上の限定的な制約
相対識別子, smbpasswd: 暗号化したパスワードデータベース (see RID)
相当な注意, バックアップ手段についての議論
着脱可能な認証モジュール (see PAM)
短縮されたキーストローク, TCP/IP設定
破損された, 特徴と利点
移動プロファイル, ドメイン制御の準備, fake_perms, その特長と利点, 移動プロファイルサポートを無効にする, Windows 9x/Me のプロファイル設定
移動プロファイルの削除, MS Windows 200x/XP
移動プロファイルを無効にする, 移動プロファイルサポートを無効にする
移動プロファイル管理, その特長と利点
移行, Samba-3.0.xにおける新しい機能, NT4 PDC からSamba-3 PDCへの移行, 目的
移行の計画, 計画と開始方法
移行手順, 目的
穴空け, pstops
空白文字, グループの追加が失敗する
管理のオーバーヘッド, シングルサインオンとドメインセキュリティ
管理の容易性, 目的
管理ツール, アカウント管理ツール
管理手続き, シングルサインオンとドメインセキュリティ
管理操作, “net rpc rights”ユーティリティの使用
管理用テンプレート, Microsoft Windows 200x/XP Professionalのポリシー
管理者の権利, 権限の説明, Windowsクライアントの管理が出来る権利と権限は何か?
管理者の権利と権限, Windowsクライアントの管理が出来る権利と権限は何か?
管理者アカウント, Windows 200x/XP Professionalクライアント, Windows NT4 クライアント, コンピュータアカウントの作成
管理者パスワード, 注意
管理者権限, SambaサーバーをPDCドメインに参加させる
管理者権限の委譲, 管理ユーザーの権限と権利
節, 設定ファイルの文法
簡単なガイド, Samba-2.xからSamba-3.0.25へのアップグレード
簡単な印刷方式, 簡単な印刷設定
簡単な設定, 設定の例
素通し印刷, 匿名プリントサーバー
統一されたログオン, はじめに
継承, ディレクトリとファイルの削除操作からの保護
綴りミスに対する寛容さ, 簡単な印刷設定
聖杯, 機能と利便性
自動マッピング, ドメインメンバーサーバーかドメインメンバークライアント
自動再接続, セキュリティに関する重要な注意事項, 暗号化されたパスワードの長所
自動生成されたprintcap, 既定値のUNIXシステム印刷コマンド
自動的なアカウントの生成, NT4サーバーマネージャによるドメインマシンアカウントの管理
英語, 日本語の文字セット, SWAT国際化サポートの有効化
複数のpersonality, 複数仮想サーバーの性質(Personalities)
複数のVFS, 議論
複数のWindowsワークグループかドメイン, Microsoft Windows Me
複数のWINSサーバー, NetBIOS over TCP/IP
複数のサーバー, 詳細設定のテクニック, 複数のサーバーのホスティング
複数のサーバーのホスティング, 複数のサーバーのホスティング
複数のドメイン, ドメインレイアウト
複数のネットワークセグメント, ドメインレイアウト
複数のバックエンド, パスワードバックエンド
複数のホスティング, 詳細設定のテクニック
複数のモジュール, 議論
複数の仮想サーバー, 複数仮想サーバーの性質(Personalities)
複数サーバーのホスティング, 複数のサーバーのホスティング, 複数仮想サーバーの性質(Personalities)
複製, 機能と利便性, LDAP設定の注意, バックアップドメインコントローラーの設定, smbpasswd: 暗号化したパスワードデータベース
SAM, ドメインコントローラーの種類, SambaはNT4 PDCのバックアップドメインコントローラーになれるか?, smbpasswdファイルの複製はどうやるか?
WINS, NetBIOS over TCP/IP, WINSサーバーの設定, WINS複製
ブラウズリスト, サブネット間のブラウジング
複製プロトコル, WINSサーバーの設定
複雑, サブネット間ブラウジングの動作
複雑な組織, ドメインレイアウト
規則, pdbeditツール
解像度, cupsomatic/foomaticの役割
設定が複雑すぎる, よくあるエラー
設定の
文書, testparmによる設定ファイルの検査
設定のコメントアウト, 手っ取り早い設定の検証
設定のテクニック, 詳細設定のテクニック
設定の問題, 概要
設定の文法, 簡単な印刷設定
設定ウィザード, ドメインへの参加: Windows 2000/XP Professional
設定ツール, SWAT: Samba Web 管理ツール
設定ファイル, 機能と利便性
設定変更の実行, Microsoft Windows 2000
診断, Winbindを使ったIDMAPデータのLDAPへの格納
診断ツール, Sambaそれ自身によるデバッグ
詳細なTCP/IP設定, Microsoft Windows XP Professional
認証, 機能と利便性, ドメインセキュリティモード(ユーザーレベルのセキュリティ), シングルサインオンとドメインセキュリティ, ドメインコントローラーの種類, Windows 9x/Meにおける特別な例, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, Samba-3でNT4形式でのドメインに参加する, これがなぜsecurity = serverよりもすぐれているのか?, ドメインへの参加: Windows 2000/XP Professional, セキュリティに関する重要な注意事項, LDAPに関するコメント, Pluggable Authentication Modules
バックエンド, ドメインメンバーサーバー
認証(credentials), ユーザーレベルのセキュリティ
認証をベースとしないアカウント管理, /etc/pam.d にあるエントリーの構造
認証アーキテクチャ, シングルサインオンとドメインセキュリティ
認証エージェント, シングルサインオンとドメインセキュリティ
認証サーバー, Microsoft Windows NT4スタイルのドメイン制御, MS Windows NT4 Workstation
認証システム, シングルサインオンとドメインセキュリティ, Samba-3.0.xにおける新しい機能
認証データベース, 機能と利便性
認証バックエンド, ドメインレイアウト
認証メカニズム, はじめに
認証制御, はじめに
認証局 (see CA)
認証方法, Pluggable Authentication Modules
認証機構, ドメインメンバーサーバー
認証管理, Pluggable Authentication Modules
読み取り専用アクセス, 複数仮想サーバーの性質(Personalities)
読み書きアクセス, 無効になった [printer$]セクション
読み込みのみ, 参照用文書サーバー
読み込み専用ファイル, 機能と利便性
誰でも書き込み可能, ファイルとディレクトリのアクセス制御
調査, バックアップ手段についての議論
論理ディレクトリ, 特徴と利点
論理ボリューム, Shadow Copy のセットアップ
論理ボリュームマネージャ (see LVM)
識別, ドメインログオンの設定: Windows 9x/Me
負荷分散, 特徴と利点
責任, pdbeditツール
起動スクリプト, winbindddaemonの開始とテスト
込み入った問題, SMBリクエストの分割
追加のドライバー, 追加のクライアントドライバーインストール
透過的な再接続, 最終目的
透過的な接続, 最終目的
通常のユーザー, 管理ユーザーの権限と権利
通常の接続, 信頼するドメインとしてのSamba
遅延オープン, Opportunistic Lockingの概要
運用コスト, 目的
適度なセキュリティ, 機能と利便性
選択, ドメインブラウジングの設定, 強制的にSambaをマスターにする
選択に勝つ, Sambaをドメインマスターにする
選択プロセス, 強制的にSambaをマスターにする
選択作業の強制, 強制的にSambaをマスターにする
重要な設定場面, 機能と利便性
開発ライブラリ, 用件
間違った設定, 簡単な印刷設定
降格, ドメインコントローラーの種類, Microsoft Windows NT4スタイルのドメイン制御
階層がない, 信頼関係に関する背景情報
障害, 機能と利便性
集中化
認証, シングルサインオンとドメインセキュリティ
集中化したアイデンティティ管理, シングルサインオンとドメインセキュリティ
集中管理, その機能と利点
静的なWINSエントリ, 静的なWINSエントリ
非LDAP
バックエンド, 機能と利便性
非PostScript, 非PostScriptプリンターのためにCUPSはPPDを使う, 非PostScriptプリンターのためのPostScriptプリンター記述
非PostScriptプリンター, Prefilters, Foomaticデータベースが生成したPPD
非セキュア, 機能と利便性
非ドメインメンバー, スタンドアロンサーバー, 背景
非メンバーのWindowsクライアント, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング
顧客, Samba サポート
高可用性, 特徴と利点, 機能と利便性
高可用性サーバー, 高可用性サーバー製品
高解像度の写真, cupsomatic/foomaticの役割

, 設定ファイルの文法, 設定の例, 匿名リードオンリ文書サーバー, 匿名の読み書き可能な文書サーバー, 匿名プリントサーバー, セキュアな読み書き可能ファイルと印刷サーバー, 設定例, 例: エンジニアリングオフィス, プライマリドメインコントローラー, バックアップドメインコントローラー, 設定例, 設定例, 設定例, 設定例, 設定例, パスワードの検査, シングルサインオンとドメインセキュリティ, ドメイン制御: 設定例, 設定例, PDCの設定例, LDAP設定の注意, 設定例, マシン信頼アカウントの手動作成, マシン信頼アカウントの即時作成, Sambaクライアント, Samba-3でNT4形式でのドメインに参加する, smb.confの設定, /etc/krb5.confの設定, Sambaドメインメンバー間でのユーザーIDマッピング共有, 参照用文書サーバー, 集中印刷サーバー, ワークグループのブラウジングの設定, ドメインブラウジングの設定, 複数のインタフェース, リモートアナウンスパラメーターの使用, Remote Browse Syncパラメーターの使用, WINSサーバーの設定, 名前解決の順序, 分散マシン上の共通のUID/GIDマッピング, Sambaの設定, smb.confにグループを追加するスクリプト例, Sambaサーバーからのワークステーション上のネストされたグループの管理, NT4形式のドメイン(Sambaドメインを含む), ADSドメイン, IDMAP_RIDを使うWinbind, Winbindを使ったIDMAPデータのLDAPへの格納, RFC2307bis Schema拡張を使ったADSからのIDMAPとNSSに対するLDAPの使用, “net rpc rights”ユーティリティの使用, ファイル、ディレクトリと共有のアクセス制御, 標準的なSambaの“create mask”パラメーターとの相互作用, Publicな共有にユーザーが書き込めない, SambaでMicrosoft Wordを使うとファイルの所有者が変更される, oplocksを無効にする, Kernel oplocksを無効にする, 機能と利便性, ホストベースの保護の使用, ユーザーベースの保護, インタフェース保護の使用, IPC$ 共有ベースの拒否の使用, なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?, ドメイン間の信頼関係, 特徴と利点, MSDFSのUNIXパスは大文字小文字を識別する, 簡単な印刷設定, 手っ取り早い設定の検証, 拡張印刷設定, カスタム印刷コマンド, [print$]共有の作成, CUPSを使う簡単なsmb.confの設定, より複雑なCUPS smb.conf設定, WindowsクライアントからCUPS/Samba印刷サーバーへ, cupsaddsmb用のsmb.confの準備, 議論, Shadow Copy のセットアップ, smb.confの設定, Solaris固有の設定, NoMachine.Comによるリモート管理, NT4/200x のユーザープロファイル, Windows 9x/Me ユーザープロファイル, Windows Windows 9x/Me と NT4/200x のユーザープロファイルの混在, デフォルトプロファイルを変更する, WINSによる検索, 基本的なパラメーターの設定, 個別の実装, 大きなディレクトリの取扱い, 詳細設定のテクニック, 複数仮想サーバーの性質(Personalities), 複数の仮想サーバーホスティング, IdMap LDAPサポート, 前提条件, テスト, デバッグレベル, デバッグ固有の操作, Windows 2000 サービスパック 2 (see SSO)
バックエンド, ドメインコントローラーの種類
ログオン
サービス, 基本的な背景情報について

A

access, ユーザーとグループの変更
Access, “net rpc rights”ユーティリティの使用
access controls, WindowsグループからUNIXグループへのマッピング
account, 設定の例, /etc/pam.d にあるエントリーの構造
account containers, LDAPデータベースの初期化
account control block (see ACB)
account control flags, アカウントフラグ管理
account encode_bits, アカウントフラグ管理
account flag order, アカウントフラグ管理
account import/export, アカウントのインポート/エクスポート
account storage system, アカウント情報データベース
account格納の方式, アカウント情報データベース
ACL, ユーザーとグループの変更, セキュリティとsambaSamAccount, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, 権限の説明, 機能と利便性, Samba-2.2からの印刷環境, 概要
ACLs, ファイル、ディレクトリと共有のアクセス制御, 無効になった [printer$]セクション
POSIX, ファイル、ディレクトリと共有のアクセス制御, 機能と利便性
Windows, 機能と利便性
ファイルシステム, ファイルとディレクトリのアクセス制御
共有, 機能と利便性
across network segments, NetBIOS over TCP/IP
active directory, 機能と利便性, 機能と利便性, シングルサインオンとドメインセキュリティ, ドメイン制御の準備, SambaによるADSドメイン制御
Active Directory, Active Directoryドメイン制御, Samba ADS ドメインメンバーシップ, UNIXとWindowsのグループ管理, スタンドアロンSambaサーバー, ドメインメンバーサーバーかドメインメンバークライアント, IDMAP_RIDを使うWinbind, ドメイン間の信頼関係
Active Directoryサーバー, 目的
AD4UNIX, ドメインメンバーサーバーかドメインメンバークライアント
ADAM, Winbindを使ったIDMAPデータのLDAPへの格納
add a user account, ユーザーアカウントの追加
add machine script, マシン信頼アカウントの即時作成, “net rpc rights”ユーティリティの使用, 動作の変更点
add user script, ユーザーアカウントマネージャ, 動作の変更点
adddriver, [print$]へのドライバーファイルインストール, adddriverを付けたprinter driver filesの実行, 指定したドライバー名の自由度, rpcclientマニュアルページのチェック, トラブルシューティング再考
additional privileges, 権限の説明
addmem, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
AddPrinterDriver(), rpcclientマニュアルページのチェック
admincfg.exe, Windows for Workgroupsにおけるパスワードの取り扱い方法の設定
administrative duties, 概要
administrative privileges, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
administrative responsibilities, 信頼関係に関する背景情報
Administrator, 議論, 管理に関する重要な情報, SambaサーバーをPDCドメインに参加させる
Administrator%password, Samba-3でNT4形式でのドメインに参加する
Administratorアカウントなし, 管理者のドメインSID
Adobe, Windows上でのGDI、UNIX上でのPostScript, カーネルモードでもPostScriptドライバーは大きな問題はない, すばらしい統一の達成
Adobe driver, WindowsのCUPS PostScriptドライバー対Adobeドライバー
Adobe PostScript, 考慮すべき警告, Windowsクライアント用のAdobeとCUPS PostScriptドライバー
Adobe PostScript ドライバー, クライアント上でのPostScriptドライバーのインストール
Adobe PPD, Linuxprinting.orgからのCUPSプリントドライバー
Adobeの仕様, cupsomatic/foomaticの役割
Adobeドライバーファイル, 異なったドライバーファイルの認識
ADS, ADS セキュリティモード(ユーザーレベルのセキュリティ), シングルサインオンとドメインセキュリティ, ドメインコントローラーの種類, 機能と利便性, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, ドメインメンバーサーバー, Samba-3でNT4形式でのドメインに参加する, smb.confの設定, /etc/krb5.confの設定, コンピュータアカウントの作成, サーバー設定のテスト, ネットワークブラウジング, TCP/IPなしのNetBIOS, DNSとActive Directory, サブネット間のブラウジング, アカウント情報データベース, 新しいアカウント格納システム, LDAPに関するコメント, アカウントとグループの管理, 管理者の作業と手段, ドメインメンバーサーバーかドメインメンバークライアント, プライマリドメインコントローラー, Winbindを使ったIDMAPデータのLDAPへの格納, User Rights and Privileges, ドメイン間の信頼関係, 機能と利便性, 信頼関係に関する背景情報, Windows 2000との間での、NT4形式のドメイン信頼関係, Samba-2.2からの印刷環境, 機能と利便性, 結果のキャッシュ保存, 機能と利便性, Microsoft Windows 200x/XP Professionalのポリシー, アカウント/ユーザーポリシーの管理, システムスタートアップとログオン処理の概要, MS Windows 200x/XP, PAM ベースの分散型認証, その機能と利点, 背景情報, Samba-3.0.xにおける新しい機能, passdbバックエンドと認証, 目的, 機能と利便性 (see Active Directory)
ADS DC, smb.confの設定
ADS スキーマ, プライマリドメインコントローラー
ADSなし, 目的
ADSのドメインメンバー, 識別情報のマッピング(IDMAP)
ADSドメイン, ドメインメンバーサーバーかドメインメンバークライアント, ADSドメイン
ADSドメインへの参加, Samba-3でNT4形式でのドメインに参加する
ADSマネージャ, コンピュータアカウントの作成
affect users, システムポリシーの作成と運用
affordable power, 最終目的
AFPL, Ghostscript: 非Postscriptプリンターに対するソフトウェアRIP
AFPL Ghostscript, pstoraster
AFS, 分散ファイルシステムの試み
AIX, 分散マシン上の共通のUID/GIDマッピング, [global]セクション, AIXにおけるNSS Winbind
algorithmic mapping, プライマリドメインコントローラー
alias group, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
Amanda, Amanda
ANSI コンパイラ, HPUX
anticipate failure, 機能と利便性
API, smbpasswd: 暗号化したパスワードデータベース
application/cups.vnd-postscript, WindowsのCUPS PostScriptドライバー対Adobeドライバー
application/octet-stream, application/octet-streamのための“raw”印刷を明示的に有効にする, MIMEタイプ変換ルール, application/octet-stream 印刷
application/pdf, MIMEタイプとCUPSフィルタ, MIMEタイプ変換ルール
application/postscript, MIMEタイプとCUPSフィルタ, MIMEタイプ変換ルール, Prefilters, pstops, WindowsのCUPS PostScriptドライバー対Adobeドライバー
application/vnd.cups-postscript, Prefilters, pstops
application/vnd.cups-raster, 非PostScriptプリンターのためのPostScriptプリンター記述
application/vnd.cups-raw, application/octet-streamのための“raw”印刷を明示的に有効にする
application/x-shell, MIMEタイプ変換ルール
apt-get, Shadow Copy のセットアップ
ARCFOUR-HMAC-MD5, サーバー設定のテスト
ARP/RARP, /etc/hosts
ASCII, MIMEタイプとCUPSフィルタ, 文字セットとユニコードとは何か, 日本語の文字セット
ASCIIテキスト, Prefilters
assigned RID, 議論
assistance, 無償サポート
associations, グループのマッピング: Microsoft Windows と UNIX
attach gdb, Sambaそれ自身によるデバッグ
audit module, extd_audit
auth, /etc/pam.d にあるエントリーの構造
authenticate users, Samba-3でNT4形式でのドメインに参加する
authenticated, smb.confの設定
authentication, ドメインコントローラーの種類, アカウントのインポート/エクスポート, 概要, WinbindとPAMの設定, その機能と利点
authentication module API, AIXにおけるNSS Winbind
authentication reply, これがなぜsecurity = serverよりもすぐれているのか?
authentication service, Linux/FreeBSD固有のPAM設定
authoritative, サブネット間ブラウジングの動作
authoritive, どのようにブラウジングは機能するか
autogen.sh, バイナリの構築
automatic redundancy, 強制的にSambaをマスターにする
autopoweruser.sh, Sambaサーバーからのワークステーション上のネストされたグループの管理
autotyping, MIMEタイプとCUPSフィルタ
AUXILIARY, RFC 2307 posixAccountとの関係とスキーマ
auxiliary members, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
average print run, Postscriptドライバーダウンロードを使う高度に賢い印刷

B

b-node, NetBIOS over TCP/IP
backend authentication, 目的
backend file system pool, 分散ファイルシステム上の限定的な制約
backends, Windowsに接続された印刷へのCUPSからの印刷
BackupPC, BackupPC
bad logon attempts, ユーザーアカウントの変更
bad password, テスト
banner pages, cupsaddsmbの実行(Quiet Mode)
barriers, 序論
Batch Oplock, Opportunistic Lockingの概要
BDC, ドメインセキュリティモード(ユーザーレベルのセキュリティ), 設定例, シングルサインオンとドメインセキュリティ, ドメインコントローラーの種類, 機能と利便性, Microsoft Windows NT4スタイルのドメイン制御, LDAP設定の注意, Active Directoryドメイン制御, バックアップドメインコントローラーの設定, 設定例, SambaはNT4 PDCのバックアップドメインコントローラーになれるか?, Samba-3でNT4形式でのドメインに参加する, これがなぜsecurity = serverよりもすぐれているのか?, 新しいアカウント格納システム, 暗号化されたパスワードの長所, 分散マシン上の共通のUID/GIDマッピング, tdbsam, 概要, ドメインメンバーサーバーかドメインメンバークライアント, プライマリドメインコントローラー, バックアップドメインコントローラー, SambaサーバーをPDCドメインに参加させる, NoMachine.Comによるリモート管理, ドメインレイアウト, 移行プロセスの手順
BDCs, ドメインレイアウト
bias, 強制的にSambaをマスターにする
binary format TDB, 新しいアカウント格納システム
BIND, ダイナミックDNS
bind interfaces only, 複数のサーバーのホスティング
BIND9, DNSとActive Directory
BIND9.NET, 機能と利便性
bindery-enabled, その機能と利点
BOBS, BOBS: Browseable Online Backup System
bogus, 設定例
bridge, ファイル、ディレクトリと共有のアクセス制御
bridges networks, どのようにブラウジングは機能するか
brlock.tdb, 印刷関連の*.tdbファイル
(see also TDB)
broadcast messaging, どのようにワークステーションがそのドメインコントローラーを探すか?
browse resources, 問題の解決方法
browse.dat, 問題の解決方法
browseable, 設定ファイルの文法
BrowseShortNames, “lp”という名前の印刷キューが印刷ジョブを間違って扱ってしまう
browsing intrinsics, どのようにブラウジングは機能するか
BSD, “$”マシン名中に$を含められない, マシン信頼アカウントの手動作成, 機能と利便性
BSD形式の印刷, 拡張印刷設定
BSD形式の印刷方式, 簡単な印刷設定
bug report, 無償サポート
Bugzilla, 概要
Bノード, 静的なWINSエントリ

C

c:\winnt\inf, Windows NT4形式のポリシーファイル
C:\WinNT\System32\config, Microsoft Windows NT4スタイルのドメイン制御
caching, Opportunistic Lockingの概要
caching reads, Opportunistic Lockingの概要
caching scheme, 結果のキャッシュ保存
caching writes, Opportunistic Lockingの概要
called name, ホストベースの保護の使用
CAP, 日本語の文字セット, 基本的なパラメーターの設定, Macintoshクライアント
cap-share, 基本的なパラメーターの設定
capability to delete, ディレクトリとファイルの削除操作からの保護
CAP_LINUX_IMMUTABLE, ディレクトリとファイルの削除操作からの保護
case-insensitive, ユーザーレベルのセキュリティ
case-preserving, ユーザーレベルのセキュリティ
central environment, LDAPに関するコメント
certificate, SSLを使うSWATのセキュア化
cfdisk, Shadow Copy のセットアップ
change capabilities, smbpasswdツール
chattr, ディレクトリとファイルの削除操作からの保護
chmod, 集中印刷サーバー, Shadow Copy のセットアップ
chown, 集中印刷サーバー, ファイルの所有者の表示, その機能と利点
chpass, マシン信頼アカウントの手動作成
CIFS, Sambaドメインメンバー間でのユーザーIDマッピング共有
CIFS/SMB, 機能と利便性, これがなぜ難しいか?
CIFS機能呼び出し, User Rights and Privileges
Citrix, ThinLincを使うリモート管理
client-side data caching, Opportunistic Lockingの概要
cluttering, デバッグ固有の操作
cmd, 共有とディレクトリのブラウジングが非常に遅い, Windowsクライアントの管理が出来る権利と権限は何か?
cmd shell, Windowsクライアントの管理が出来る権利と権限は何か?
CN, LDAP設定の注意, 概要
code maintainer, 無償サポート
collating, Sambaをドメインマスターにする
color, UNIX印刷ファイル変換とGUIの基礎
COM1:, Sambaとプリンターポート
commercial support, Samba サポート, 商用サポート
Common Internet Filesystem (see CIFS)
Common UNIX Printing System (see CUPS)
common.adm, Windows NT4形式のポリシーファイル
comp.protocols.smb, 概要
compile-time options, 手っ取り早い設定の検証
complex file name space, 簡単なソリューション
complexity, 設定例
Conectiva, フォーラム、ダウンロード、チュートリアル、HOWTO(Mac OS Xと商用UNIX用も)
config.cache, よくあるエラー
CONFIG.POL, Windows 9x/Meにおける特別な例
Config.POL, システムポリシーの作成と運用, Windows 9x/ME ポリシー
configure, バイナリの構築
confirm address, インタフェース保護の使用
confirm the password, 信頼するドメインとしてのSamba
confirm the trust, 信頼されるドメインとしてのSamba
connection resources, これがなぜsecurity = serverよりもすぐれているのか?
connections, 設定の例
connections.tdb, 印刷関連の*.tdbファイル
(see also TDB)
console, Linux/FreeBSD固有のPAM設定
consumer expects, Samba サポート
core graphic engine, Windowsドライバー、GDIとEMF
corrupted file, ドメインメンバーサーバーかドメインメンバークライアント
cosine.schema, OpenLDAPの設定
country of origin, 商用サポート
CP850, Sambaと文字セット
CP932, 基本的なパラメーターの設定
cracker, インタフェース保護の使用
create, ディレクトリの管理
credentials, シングルサインオンとドメインセキュリティ, LDAP設定の注意, /etc/krb5.confの設定, 管理ユーザーの権限と権利, User Rights and Privileges
credentials validation, NetBIOS Over TCP/IPが有効
crle, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
cron, バックアップドメインコントローラーの設定
CUPS, 機能と利便性, 技術的な序論, 拡張印刷設定, [global]セクション, 機能と利便性, Overview, 基本的なCUPSサポート設定, Windows形式のベンダPPDの使用
quotas, Quotasの設定
ページの課金, CUPSによるページの課金
CUPS API, 設定ファイルの文法, 既定値のUNIXシステム印刷コマンド
CUPS PostScript, 考慮すべき警告
CUPS PostScriptドライバー, WindowsのCUPS PostScriptドライバー対Adobeドライバー
CUPS print filters, 集中印刷サーバー
CUPS raster, CUPSフィルタリングアーキテクチャ
CUPS ラスタ, pstoraster
CUPS-PPD, cupsomatic, pdqomatic, lpdomatic, directomatic
cups.hlp, 考慮すべき警告
cupsaddsmb, ドライバーアップロード手法, cupsaddsmb: 不明なユーティリティ, 考慮すべき警告, cupsaddsmbの実行(Quiet Mode), 詳細な結果を表示するcupsaddsmbの実行, cupsaddsmbについて理解する, Samba PDCににおけるcupsaddsmb, cupsaddsmbフローチャート, クライアント上でのPostScriptドライバーのインストール, adddriverとsetdriverを完了させるための要求事項
cupsd.conf, 既定値のUNIXシステム印刷コマンド, 基本的なCUPSサポート設定, mime.convs, CUPSスプールフィルタの自動削除または保存
cupsomatic, Windows形式のベンダPPDの使用, CUPSフィルタリングアーキテクチャ, cupsomatic/foomaticの役割, cupsomatic/foomatic-rip 対 ネイティブなCUPS印刷, Linuxprinting.orgからのCUPSプリントドライバー, cupsomatic, pdqomatic, lpdomatic, directomatic
CUPSバックエンド, CUPSバックエンド
CUPSフィルタリング, 非PostScriptプリンターのためにCUPSはPPDを使う, CUPSフィルタリングアーキテクチャ
CUPSフィルタリングチェーン, CUPSバックエンド
CUPSライブラリAPI, 集中印刷サーバー
customer expected, Samba サポート

D

daemon, Sambaを起動する, ドメイン間の信頼関係, 用件, もう一つの方法: smbdをデーモンとして起動する
daemon running, winbindddaemonの開始とテスト
daemons, 再起動
data caching, Opportunistic Lockingの概要
database, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
DatabaseFS, DatabaseFS
DAVE, Macintoshクライアント
dbx, 内部エラー
DCE RPC, SambaサーバーをPDCドメインに参加させる
DDK, カーネルモードでもPostScriptドライバーは大きな問題はない, Windows NT/200x/XP用のCUPS“PostScript Driver”
DDNS, TCP/IPなしのNetBIOS, DNSとActive Directory, 背景情報
de-multiplex, 最先端の状況
Debian, Shadow Copy のセットアップ
Debian Sarge, Shadow Copy のセットアップ
debug, 内部エラー
debug level, Sambaそれ自身によるデバッグ, デバッグレベル
dedicated heartbeat, 高可用性サーバー製品
default accounts, ドメイン制御: 設定例
delegated, 管理に関する重要な情報
delegation, 信頼関係に関する背景情報
delete, ディレクトリの管理
delete user script, アカウントの削除
deleted files, recycle
delmem, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
deny, IPC$ 共有ベースの拒否の使用
deny access, ファイアウォールの使用
deny modes, 議論
deny-none, Opportunistic Lockingの概要
DENY_ALL, 議論
DENY_DOS, 議論
DENY_FCB, 議論
DENY_NONE, 議論
DENY_READ, 議論
DENY_WRITE, 議論
deployment, 無償サポート
deployment guidelines, LDAPとSambaに対する注意
DES-CBC-CRC, /etc/krb5.confの設定
DES-CBC-MD5, /etc/krb5.confの設定, サーバー設定のテスト
deterents, 序論
devfsd package, Shadow Copy のセットアップ
DFS, 特徴と利点 (see MS-DFS, 分散ファイルシステム)
DFS サーバー, 特徴と利点
DFS ジャンクション, 特徴と利点
DFS ツリー, 特徴と利点
DFS リンク, 特徴と利点
DFS ルート, 特徴と利点
DFS 対応, 特徴と利点
DFS 対応 クライアント, 特徴と利点
DHCP, TCP/IP設定, Microsoft Windows XP Professional, Microsoft Windows 2000, Microsoft Windows Me, サブネット間のブラウジング, 背景情報, 機能と利便性
DHCPが有効な操作, Microsoft Windows XP Professional
DHCPサーバー, LDAPに関するコメント
DHCP有効, Microsoft Windows 2000
diff, パッチ
dir, テスト
direct internet access, 序論
directory_mode, recycle
disass, 内部エラー
disparate information systems, シングルサインオンとドメインセキュリティ
display PostScript, UNIX印刷ファイル変換とGUIの基礎
displayName, OpenLDAPの設定
distort, UNIX印刷ファイル変換とGUIの基礎
distributed, 機能と利便性, ドメイン制御: 設定例
distribution, 設定の例
dithering algorithm, cupsomatic/foomaticの役割
DMB, ドメイン制御の準備, ドメイン制御: 設定例, セキュリティモードとマスターブラウザー, ネットワーク上のドメインコントローラーになれる要件, どのようにブラウジングは機能するか, ワークグループのブラウジングの設定, ドメインブラウジングの設定, 強制的にSambaをマスターにする, Sambaをドメインマスターにする, WINS: The Windows Internetworking Name Server, Windowsのネットワークプロトコル, サブネット間ブラウジングの動作
DMC, IDMAPバックエンドの使用例
DMS, ドメインセキュリティモード(ユーザーレベルのセキュリティ), 概要, IDMAPバックエンドの使用例, 詳細設定のテクニック
DN, LDAP設定の注意, 概要
DNS, ドメイン制御の準備, どのようにワークステーションがそのドメインコントローラーを探すか?, NetBIOS Over TCP/IPが無効, smb.confの設定, /etc/krb5.confの設定, Microsoft Windows XP Professional, Microsoft Windows 2000, Microsoft Windows Me, ネットワークブラウジング, 機能と利便性, NetBIOS over TCP/IP, TCP/IPなしのNetBIOS, どのようにブラウジングは機能するか, サブネット間のブラウジング, LDAPデータベースの初期化, Name Service Switch, 背景情報, DNSによる検索, テスト, 機能と利便性, 設定例
Active Directory, DNSとActive Directory
Dynamic, 背景情報, ダイナミックDNS
SRV レコード, DNSとActive Directory
DNS zon, /etc/krb5.confの設定
DNS/LDAP/ADS, ブラウジングの技術的な概要
DNSによる名前解決, Samba-3でNT4形式でのドメインに参加する
DNSサーバー, サブネット間ブラウジングの動作, LDAPに関するコメント
DNSサーバーの設定, Microsoft Windows XP Professional
DNSサーバーアクセス, 前提条件
DNSサーバー設定, Microsoft Windows 2000
dnsプロキシ, 前提条件
DNS検索, /etc/krb5.confの設定
DNS設定, 共有とディレクトリのブラウジングが非常に遅い
documentation, LDAPディレクトリとWindowsのコンピュータアカウント, Sambaの問題の調査と解決方法
domain
trust account, 機能と利便性
domain access, 識別情報のマッピング(IDMAP)
domain admin group, グループのマッピング: Microsoft Windows と UNIX
domain Administrator, 管理者のドメインSID
Domain Admins, Samba-3.0.23でのグループマッピングの変更, 議論, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, 管理に関する重要な情報, WindowsグループからUNIXグループへのマッピング, “net rpc rights”ユーティリティの使用
Domain Admins group, 議論
domain authentication, 概要
domain controller, その機能と利点
domain global, Windowsクライアントの管理が出来る権利と権限は何か?
domain group settings, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
Domain Groups, アカウントとグループの管理
Domain Guests, WindowsグループからUNIXグループへのマッピング
domain information, 新しいスキーマ
domain join, ADSドメイン
domain master, ドメイン制御: 設定例
Domain Name System (see DNS)
domain security, 信頼関係に関する背景情報, SambaサーバーをPDCドメインに参加させる, MS Windows 200x/XP
domain SID, セキュリティ識別子(SID)の管理
domain trust, 機能と利便性
Domain Users, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, WindowsグループからUNIXグループへのマッピング
Domain Usersグループ, ワークステーションのPower UsersグループへのDomain Usersの追加
DOMAIN<1B>, セキュリティモードとマスターブラウザー
DOMAIN<1C>, Windows 9x/Meにおける特別な例, セキュリティモードとマスターブラウザー
DOMAIN<1D>, セキュリティモードとマスターブラウザー
draft, cupsomatic/foomaticの役割
driver, testparmによる設定の検査
duplicate, LDAP設定の注意
DVI, MIMEタイプとCUPSフィルタ, Prefilters
Dynamic Host Configuration Protocol (see DHCP)
dynamic link loader, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する

E

e-Directory, シングルサインオンとドメインセキュリティ, ドメインメンバーサーバー
EAs, ファイルとディレクトリのアクセス制御
economically wise, 機能と利便性
eDirectory, LDAPに関するコメント
editreg, SambaのEditregツールセット
election, セキュリティモードとマスターブラウザー, どのようにブラウジングは機能するか
election criteria, どのようにブラウジングは機能するか
election packet, 強制的にSambaをマスターにする
EMF, Windowsドライバー、GDIとEMF, WindowsクライアントからNT印刷サーバーへ, サーバー上でのドライバーの実行
encapsulating, NetBIOS over TCP/IP
encryped password, ドメイン制御: 設定例
encrypted, 機能と利便性
encrypted passwords, passdbバックエンドと認証
enforcing, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
enumdrivers, ドライバーファイルの識別, rpcclientマニュアルページのチェック
EnumJobs(), Samba-2.2からの印刷環境
enumprinters, rpcclientマニュアルページのチェック
EPM (see ESP meta packager)
Epson Stylus, フィルタリングチェインの例
Epson Stylus inkjet, Foomaticデータベースが生成したPPD
equivalence, Windows2000ドメインコントローラーでサポートされている権限
equivalent rights and privileges, 管理者のドメインSID
errors that can afflict, よくあるエラー
ESC/P, サーバー上でのドライバーの実行
ESP, Ghostscript: 非Postscriptプリンターに対するソフトウェアRIP
Ghostscript, CUPSフィルタリングアーキテクチャ, cupsomatic/foomatic-rip 対 ネイティブなCUPS印刷
meta packager, Windows NT/200x/XP用のCUPS“PostScript Driver”
Print Pro, CUPSドライバー/PPDの提供元, Windows NT/200x/XP用のESP Print Pro PostScriptドライバー
ESP Ghostscript, CUPSフィルタリングアーキテクチャ
established, 信頼されるドメインとしてのSamba
ethereal, Windows 9x/Me のプロファイル設定, Tcpdump, Ethereal, Windowsのネットワークモニター
EUC-JP, 日本語の文字セット, 基本的なパラメーターの設定
eucJP-ms locale, 基本的なパラメーターの設定
Everyone - フルコントロール, 共有のアクセス制御
Everyone group, Samba-2.2からの印刷環境
EVMS, shadow_copy
examples, 設定の例
examples/LDAP, 新しいアカウント格納システム
execute, ファイルとディレクトリのアクセス制御
expands control abilities, 新しいアカウント格納システム
explicit trust, 信頼関係に関する背景情報
exploit opportunities, 機能と利便性
exploitation, インタフェース保護の使用
exposed, ファイアウォールの使用
extd_audit module, extd_audit
extended SAM, 新しいアカウント格納システム
extra machine, 複数の仮想サーバーホスティング

F

failed join, NT4形式のドメイン(Sambaドメインを含む), IDMAP_RIDを使うWinbind
failover communication, 高可用性サーバー製品
failure semantics, Sambaに対する変更要求
fake-permissions, 必須プロファイル
fake_permissions, ドメイン制御: 設定例
fake_perms, fake_perms
fdisk, Shadow Copy のセットアップ
Federated Identity Management (see FIM)
federated organizations, シングルサインオンとドメインセキュリティ
federated-identity, シングルサインオンとドメインセキュリティ
Fiber Channel, 高可用性サーバー製品
fickle, 機能と利便性
fid, SMBリクエストの分割
file system capabilities, ディレクトリとファイルの削除操作からの保護
FILE:, Sambaとプリンターポート
filter, MIMEタイプとCUPSフィルタ
Filter Oplock, Opportunistic Lockingの概要
FilterLimit, mime.convs
filters, MIMEタイプとCUPSフィルタ
FIM, シングルサインオンとドメインセキュリティ, LDAPに関するコメント
foomatic, Windows形式のベンダPPDの使用, CUPSフィルタリングアーキテクチャ, cupsomatic/foomaticの役割, cupsomatic/foomatic-rip 対 ネイティブなCUPS印刷, foomatic-rip と Foomaticの説明, Foomaticの奇妙な名前
foomatic-rip, CUPSフィルタリングアーキテクチャ, cupsomatic/foomaticの役割, cupsomatic/foomatic-rip 対 ネイティブなCUPS印刷, Linuxprinting.orgからのCUPSプリントドライバー, foomatic-rip と Foomaticの説明, すばらしい統一の達成
Foomatic/cupsomatic, cupsomatic/foomatic-rip 対 ネイティブなCUPS印刷
Foomaticチュートリアル, すばらしい統一の達成
Foomaticデータベース, Foomaticデータベースが生成したPPD
Foomaticプリンター, cupsomatic/foomaticの役割
foreign domain, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
foreign SID, 外部のSIDの取り扱い
foreign user, 外部のSIDの取り扱い
FQDN, 概要
free support, Samba サポート, 無償サポート
FreeBSD, “$”マシン名中に$を含められない, 基本的なパラメーターの設定
freezing, Shadow Copy のセットアップ
front-end virtual server, 最先端の状況
frustrating experience, LDAPディレクトリとWindowsのコンピュータアカウント
FTP, 暗号化されていないパスワードの長所
ftp, Rsync, rsyncとftp経由によるSambaソースへのアクセス
ftp access, Linux/FreeBSD固有のPAM設定
ftpd, /etc/pam.d にあるエントリーの構造
ftpサービス, Linux/FreeBSD固有のPAM設定
functional components, デバッグ固有の操作

G

gcc, Sambaそれ自身によるデバッグ, HPUX
gdb, Sambaそれ自身によるデバッグ, 内部エラー, 稼働中のプロセスへのアタッチ
GDI, Windows上でのGDI、UNIX上でのPostScript, Windowsドライバー、GDIとEMF, WindowsクライアントからNT印刷サーバーへ, サーバー上でのドライバーの実行
general security service application programming interface (see GSSAPI)
genlogon.pl, ネットワークログオンスクリプトの魔法
Gentoo, Linuxカーネルを変更した事によるSambaパフォーマンス問題
get, テスト
getdriver, ドライバーファイルの識別, [print$]へのドライバーファイルインストール
getdriverdir, rpcclientマニュアルページのチェック
getent, 新しいグループの追加又は作成, IDMAP_RIDを使うWinbind, winbindddaemonの開始とテスト
getent group demo, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
gethostbyname() 関数呼び出し, 名前解決の順序
getpwnam, RFC 2307 posixAccountとの関係とスキーマ, ドメインメンバーサーバーかドメインメンバークライアント
getpwnam()呼び出し, 動作の変更点
GetSID.exe, SID の取得
GhostScript, PostScriptとGhostscript, Ghostscript: 非Postscriptプリンターに対するソフトウェアRIP
(see also PostScript)
Ghostscript, CUPSフィルタリングアーキテクチャ, 非PostScriptプリンターのためのPostScriptプリンター記述
ESP (see ESP GhostScript)
GID, 設定例, マシン信頼アカウントの手動作成, これがなぜsecurity = serverよりもすぐれているのか?, Sambaドメインメンバー間でのユーザーIDマッピング共有, ユーザーとグループの変更, Passdbの変更, Samba-3.0.23でのグループマッピングの変更, 分散マシン上の共通のUID/GIDマッピング, 機能と利便性, 概要, WindowsグループからUNIXグループへのマッピング, 識別情報のマッピング(IDMAP), ドメインメンバーサーバーかドメインメンバークライアント, プライマリドメインコントローラー, 機能と利便性, 外部のSIDの取り扱い, winbindddaemonの開始とテスト
GID numbers, ドメインメンバーサーバーかドメインメンバークライアント
GIDレンジ, ドメイン間の信頼関係
GIF, MIMEタイプとCUPSフィルタ
global right, 権限の説明
Global support, 目的
GNOME, NoMachine.Comによるリモート管理
GNU Ghostscript, CUPSフィルタリングアーキテクチャ, pstoraster
GNU GPL, BackupPC
GNU tar, Amanda
GNU/Linux, 議論
GPG, SambaのPGP署名の検証
GPL, NoMachine.Comによるリモート管理
gpolmig.exe, Windows 200x/XPポリシーの管理
GPOs, 機能と利便性, Microsoft Windows 200x/XP Professionalのポリシー, Windows 200x/XPポリシーの管理, アカウント/ユーザーポリシーの管理, システムスタートアップとログオン処理の概要, MS Windows 200x/XP
grace time, ユーザーアカウントの変更
graphical objects, UNIX印刷ファイル変換とGUIの基礎
grayscale, cupsomatic/foomaticの役割
grep, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
group, 設定例, LDAPディレクトリとWindowsのコンピュータアカウント, ファイルとディレクトリのアクセス制御
group accounts, 警告:ユーザー固有のグループ問題
group mappings, 機能と利便性
group permissions, ユーザーとグループの変更
Group Policy, Windows 9x/ME ポリシー
group policy objects (see GPOs)
groupadd, 機能と利便性, smb.confにグループを追加するスクリプト例, グループの追加が失敗する
groupadd limitations, smb.confにグループを追加するスクリプト例
groupdel, 機能と利便性
groupmap, グループのマッピング: Microsoft Windows と UNIX
groupmod, 機能と利便性
grouppol.inf, Windows 9x/ME ポリシー
groups, 機能と利便性
domain, 議論
mapping, グループのマッピング: Microsoft Windows と UNIX
nested, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
GSSAPI, シングルサインオンとドメインセキュリティ
gtklp, Foomaticデータベースが生成したPPD
guest, ドメイン制御: 設定例, 参照用文書サーバー
guest account, 問題の解決方法, テスト
GUI, Overview
GUI画面でのクライアント設定, 機能と利便性
Gutenprint, rasterto [プリンター固有], ドライバー開発の外側

I

IANA, pstoraster
ID mapping, Samba-3.0.xにおける新しい機能
ID range, 機能と利便性
ID マッピング, 設定例
IDEALX, ldapsam
identify, ADSドメイン
identity, スタンドアロンSambaサーバー
identity information, シングルサインオンとドメインセキュリティ
identity management, シングルサインオンとドメインセキュリティ
IDMAP, Samba-3.0.23でのグループマッピングの変更, 機能と利便性, 識別情報のマッピング(IDMAP), スタンドアロンSambaサーバー, ドメインメンバーサーバーかドメインメンバークライアント, IDMAP_RIDを使うWinbind
idmap, 新しいスキーマ
idmap backend, 設定例, 機能と利便性, IdMap LDAPサポート
idmap gid, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング, ドメインメンバーサーバーかドメインメンバークライアント, IDMAP_RIDを使うWinbind, 機能と利便性
idmap GID, 新しいスキーマ
IDMAP infrastructure, 識別情報のマッピング(IDMAP)
idmap uid, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング, 機能と利便性, ドメインメンバーサーバーかドメインメンバークライアント, IDMAP_RIDを使うWinbind, 機能と利便性
idmap UID, 新しいスキーマ
idmap バックエンド, 分散マシン上の共通のUID/GIDマッピング
idmap_ad, 分散マシン上の共通のUID/GIDマッピング
idmap_ldap module, 新しいスキーマ
idmap_rid, ドメインメンバーサーバーかドメインメンバークライアント, IDMAP_RIDを使うWinbind
idmapバックエンド, 分散マシン上の共通のUID/GIDマッピング, ドメインメンバーサーバーかドメインメンバークライアント
IDMAPバックエンド, 分散マシン上の共通のUID/GIDマッピング
idの移行, Samba-3.0.xにおける新しい機能
IDの解決, 機能と利便性
IDマッピングデータベース, ユーザーとグループIDの割り当て
IETF, Overview
ifconfig, inetd.confからの起動, Linuxカーネルを変更した事によるSambaパフォーマンス問題
imagetoraster, imagetops と imagetoraster
immutable, ディレクトリとファイルの削除操作からの保護
impersonate, セキュリティとsambaSamAccount
important announcements, Sambaのアップグレード
Imprints, Imprintsツールセット
imprints, ドライバーアップロード手法
include, 詳細設定のテクニック
individual domain user, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
inetd, SWATインストールの有効か, テスト, smbd nmbdとwinbinddの起動, inetd.confからの起動
inetd.conf, テスト
inetorgperson.schema, OpenLDAPの設定
inf ファイル, ドライバーファイルの識別
initdb.ldif, プライマリドメインコントローラー
initGroups.sh, 例: エンジニアリングオフィス, グループマッピング設定のためのスクリプト, 移行プロセスの手順
inktype, cupsomatic/foomaticの役割
inspire simplicity, 設定例
inspired structure, 技術的な議論
interactive help, 無償サポート
Interdomain Trusts
Completing, NT4ドメイン信頼関係の構築完了
creating, ネイティブなMicrosoft Windows NT4の信頼関係の設定
interface scripts, ユーザーアカウントマネージャ
interfaces, 複数のサーバーのホスティング
intermediate information, LDAPとSambaに対する注意
intermediate tools, LDAPに関するコメント
Internet Engineering Task Force (see IETF)
Internet Printing Protocol (see IPP)
Internetworking Packet Exchange (see IPX)
internetworking super daemon, 機能と利便性
intolerance, 機能と利便性
invalid shell, 設定例
invalid users, テスト
IPC$, Windows 9x/Meにおける特別な例, 問題の解決方法, IPC$ 共有ベースの拒否の使用
IPC$接続, 最先端の状況
ipchains, テスト
ipconfig, TCP/IPなしのNetBIOS
iPlanet, ドメインメンバーサーバー
IPP, cupsaddsmbについて理解する
IPPクライアント, Administratorはすべてのローカルユーザーに対してプリンターをインストールできない
iptables, テスト
IPX, Windowsのネットワークプロトコル
IPアドレス, /etc/hosts, テスト
IPアドレスを指定, Microsoft Windows Me
IPアドレスを自動的に取得する, Microsoft Windows XP Professional, Microsoft Windows 2000
IPエイリアス, Microsoft Windows XP Professional
IRC, 無償サポート
IRIX, 議論, 基本的なパラメーターの設定
ISC
DHCP, 機能と利便性
DNS, 機能と利便性
ISC DHCP サーバー, Microsoft Windows XP Professional, Microsoft Windows Me
IXFR, 背景情報

L

LAN, 強制的にSambaをマスターにする, ThinLincを使うリモート管理, 高可用性サーバー製品, 診断ツール
LanMan, 機能と利便性, 基本的な背景情報について, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, 技術情報, Samba-2.2からの印刷環境
LanMan logon サービス, ドメイン制御の準備
LanManager, ユーザーレベルのセキュリティ, ドメインログオンの設定: Windows 9x/Me
LanManager互換, WINS: The Windows Internetworking Name Server
LanMangerのパスワード, ユーザーとマシンアカウントの表示
LanManパスワード, 下位互換性のあるバックエンド
latency, 遅くて信頼できないネットワーク
LCT (see 最終変更時刻)
LDAP, 機能と利便性, シングルサインオンとドメインセキュリティ, ドメインコントローラーの種類, LDAP設定の注意, バックアップドメインコントローラーの設定, smbpasswdファイルの複製はどうやるか?, これをすべてのLDAPに使えるか?, 機能と利便性, ドメインメンバーサーバー, Sambaドメインメンバー間でのユーザーIDマッピング共有, アカウント情報データベース, 新しいアカウント格納システム, セキュリティに関する重要な注意事項, 分散マシン上の共通のUID/GIDマッピング, LDAPに関するコメント, LDAPとSambaに対する注意, LDAPディレクトリとWindowsのコンピュータアカウント, ldapsam, サポートしているLDAPサーバー, RFC 2307 posixAccountとの関係とスキーマ, LDAPデータベースの初期化, Sambaの設定, 既定値のユーザー、グループと相対識別子, 識別情報のマッピング(IDMAP), ドメインメンバーサーバーかドメインメンバークライアント, バックアップドメインコントローラー, ドメイン間の信頼関係, 機能と利便性, 信頼関係に関する背景情報, Samba-2.2からの印刷環境, Microsoft Active Directoryサービス, その機能と利点, passdbバックエンドと認証, ドメインレイアウト
slave, 機能と利便性
サーバー, LDAP設定の注意
スレーブ, LDAP設定の注意
ディレクトリ, LDAPに関するコメント
マスター, LDAP設定の注意
LDAP database, LDAPデータベースの初期化
LDAP deployment, LDAPに関するコメント
LDAP directory, LDAPに関するコメント
ldap group suffix, 新しいスキーマ, 検索のための新しいサフィックス
ldap idmap suffix, Sambaドメインメンバー間でのユーザーIDマッピング共有, 新しいスキーマ, 検索のための新しいサフィックス
LDAP idmap バックエンド, 分散マシン上の共通のUID/GIDマッピング
ldap machine suffix, 検索のための新しいサフィックス
LDAP redirects, ドメインメンバーサーバーかドメインメンバークライアント
ldap suffix, 新しいスキーマ, 検索のための新しいサフィックス
ldap user suffix, 検索のための新しいサフィックス
LDAP ディレクトリ, アカウントフラグ管理
LDAP., LDAPディレクトリとWindowsのコンピュータアカウント
LDAP/Kerberos, Samba-3.0.xにおける新しい機能
LDAPS, セキュリティとsambaSamAccount
ldapsam, ドメイン制御: 設定例, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, アカウント情報データベース, smbpasswd: 暗号化したパスワードデータベース, ldapsam, サポートしているLDAPサーバー, 既定値のユーザー、グループと相対識別子, プライマリドメインコントローラー, 新しいスキーマ, 目的
ldapsam_compat, 下位互換性のあるバックエンド, 新しいスキーマ
ldapsearch, 新しいスキーマ
LDAPv3, セキュリティとsambaSamAccount
LDAPクエリ, 検索のための新しいサフィックス
LDAPサーバー, ドメインメンバーサーバーかドメインメンバークライアント
LDAPスキーマ, Samba-3.0.23におけるLDAPの変更
LDAPディレクトリ, LDAPに関するコメント, ldapsam, Samba-3.0.xにおける新しい機能
LDAPデータベース, 設定例, ドメインレイアウト
LDAPバックエンド, 背景, 分散マシン上の共通のUID/GIDマッピング, プライマリドメインコントローラー, お手軽移行ガイド
LDAPベース, 分散マシン上の共通のUID/GIDマッピング, ドメイン間の信頼関係
LDAP管理用パスワード, バックアップドメインコントローラーの設定, Sambaドメインメンバー間でのユーザーIDマッピング共有
ldconfig, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
ldd, libcups.soを使ったsmbdとのリンク
LDIF, LDAPデータベースの初期化, 新しいスキーマ
LDIF file, LDAPデータベースの初期化
Level1 Oplock, Opportunistic Lockingの概要
Level1 oplock, Opportunistic Lockingの概要
Level2 Oplock, Opportunistic Lockingの概要
LGPL, ldapsam
libcups, 既定値のUNIXシステム印刷コマンド, libcups.soを使ったsmbdとのリンク
libcups.so, libcups.soを使ったsmbdとのリンク
libcups.so.2, libcups.soを使ったsmbdとのリンク
Liberty Alliance, シングルサインオンとドメインセキュリティ
libiconv, 基本的なパラメーターの設定
libnss_winbind, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
libnss_winbind.so, Name Service Switch, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
libnss_wins.so, /etc/nsswitch.conf
limitations, 信頼関係に関する背景情報
linewidth, UNIX印刷ファイル変換とGUIの基礎
Linux, 分散マシン上の共通のUID/GIDマッピング, ThinLincを使うリモート管理, その機能と利点, 基本的なパラメーターの設定
Linux LVM, Shadow Copy のセットアップ
Linux LVMのパーティション, Shadow Copy のセットアップ
LinuxKongress2002, すばらしい統一の達成
Linuxprinting.org, cupsomatic/foomaticの役割, Linuxprinting.orgからのCUPSプリントドライバー, ドライバー開発の外側
Linux高可用性プロジェクト, 高可用性サーバー製品
listen for connections, インタフェース保護の使用
LLC, Microsoft Windows ネットワークへのSambaの統合
LM/NT パスワードハッシュ, smbpasswd: 暗号化したパスワードデータベース
LM/NTパスワードハッシュ, セキュリティとsambaSamAccount
LMB, ドメイン制御の準備, どのようにブラウジングは機能するか, ワークグループのブラウジングの設定, ドメインブラウジングの設定, 強制的にSambaをマスターにする, Sambaをドメインマスターにする, Remote Browse Syncパラメーターの使用, WINS: The Windows Internetworking Name Server, Windowsのネットワークプロトコル, Sambaでのブラウジングサポート, サブネット間ブラウジングの動作 (see ローカルマスターブラウザー)
LMBを無効, ワークグループのブラウジングの設定
LMHOSTS, どのようにブラウジングは機能するか, LMHOSTSファイル
lmhosts, WINS: The Windows Internetworking Name Server
local access permissions, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
local administrative privileges, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
local groups, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
Local Master Browser, NetBIOS over TCP/IP
local names, NetBIOS over TCP/IP
local registry values, Microsoft Windows 200x/XP Professionalのポリシー
local user, 再起動
locale, SWAT国際化サポートの有効化
localhost, ホストベースの保護の使用
locally known UID, WindowsグループからUNIXグループへのマッピング
Lock caching, Opportunistic Lockingの概要
lock directory, 複数のサーバーのホスティング
lock the account, ユーザーアカウントの変更
locking, ファイルとレコードのロッキング, 分散ファイルシステムの試み
locking protocol, 機能と利便性
locking.tdb, 印刷関連の*.tdbファイル
(see also TDB)
lockingの無効化, 機能と利便性
lockout, 設定例
log level, Sambaそれ自身によるデバッグ, デバッグレベル
log.nmbd, 問題の解決方法, テスト
logging, 監査の設定
Logical Link Control (see LLC)
Login, 暗号化されていないパスワードの長所
login, Linux/FreeBSD固有のPAM設定, その機能と利点
login id, ユーザーとマシンアカウントの表示
login name, 設定の例
LoginID, ドメインメンバーサーバーかドメインメンバークライアント
logon drive, ドメイン制御: 設定例
logon home, ドメイン制御: 設定例, Windows 9x/Me ユーザープロファイル
logon path, ドメイン制御: 設定例
logon script, ドメイン制御: 設定例
logons, NT4/200x のユーザープロファイル
logon処理, ドメイン制御: 設定例
lookups, smbpasswd: 暗号化したパスワードデータベース
loopback adapter, テスト
lower-case, ユーザーレベルのセキュリティ
lp, testparmによる設定の検査, “lp”という名前の印刷キューが印刷ジョブを間違って扱ってしまう
lpadmin, “Raw”印刷, インタフェーススクリプトを伴う印刷, Linuxprinting.orgからのCUPSプリントドライバー, Quotasの設定
LPD, [global]セクション
lpinfo, CUPSバックエンド
lpq cache time, [global]セクション
lpq command, [global]セクション
LPRNG, [global]セクション
lpstat, 設定ファイルの文法, トラブルシューティング再考
LPT1:, Sambaとプリンターポート
LsaEnumTrustedDomains, Sambaそれ自身によるデバッグ
LTSP, NoMachine.Comによるリモート管理
Lustre, 分散ファイルシステムの試み
lvcreate, Shadow Copy のセットアップ
LVM, shadow_copy, Shadow Copy のセットアップ
LVM ボリューム, Shadow Copy のセットアップ
lvm10 package, Shadow Copy のセットアップ
LVMスナップショット, Shadow Copy のセットアップ
LVMボリューム, Shadow Copy のセットアップ

M

m-node, NetBIOS over TCP/IP
Mac OS X , 基本的なパラメーターの設定
machine SID, セキュリティ識別子(SID)の管理
machine trust account, Windows 9x/Meにおける特別な例
machine_name, マシン信頼アカウントの手動作成
machine_nickname, マシン信頼アカウントの手動作成
Macintosh, 基本的なパラメーターの設定
MACアドレス, /etc/hosts
mail, LDAPに関するコメント
mailing list, 無償サポート
mailing lists, 無償サポート
make, /etc/nsswitch.conf, バイナリの構築
man page, smb.confの設定
man pages, 概要
man-in-the-middle, User Rights and Privileges
Manageability, 目的
managed by humans, 機能と利便性
management bottleneck, マルチユーザーデータベース
management costs, LDAPに関するコメント
Mandrake, フォーラム、ダウンロード、チュートリアル、HOWTO(Mac OS Xと商用UNIX用も)
Mandriva, フォーラム、ダウンロード、チュートリアル、HOWTO(Mac OS Xと商用UNIX用も)
map, Windows 200x/XP Professionalクライアント, ユーザーとグループアカウント
mapped, 管理に関する重要な情報, 概要, WindowsグループからUNIXグループへのマッピング
master smb.conf, 複数の仮想サーバーホスティング
mbd kept spawning, 壊れたtdbファイル
member, “net rpc rights”ユーティリティの使用
messages.tdb, 印刷関連の*.tdbファイル
(see also TDB)
meta-service, 設定ファイルの文法
Microsoft Active Directory, その機能と利点
Microsoft Developer Network CD, Windowsのネットワークモニター
Microsoft driver, カーネルモードでもPostScriptドライバーは大きな問題はない
Microsoft management console (see MMC)
Microsoft Remote Procedure Call (see MSRPC)
Microsoft Windows 2000, Active Directoryドメイン制御
Microsoft Windows 9x/Me, NT4サーバーマネージャによるドメインマシンアカウントの管理
Microsoft Wolfpack, 高可用性サーバー製品
migrate, サーバータイプとセキュリティモード
MIME, MIMEタイプとCUPSフィルタ, MIMEタイプ変換ルール, フィルタリングの概要, application/octet-stream 印刷
filters, MIMEタイプとCUPSフィルタ
raw, 匿名プリントサーバー, 集中印刷サーバー, application/octet-streamのための“raw”印刷を明示的に有効にする
MIME type, application/octet-streamのための“raw”印刷を明示的に有効にする, application/octet-stream 印刷
MIME タイプ, CUPSフィルタリングアーキテクチャ
MIME 変換規則, CUPSフィルタリングアーキテクチャ
MIME 認識, CUPSフィルタリングアーキテクチャ
mime.types, MIMEタイプとCUPSフィルタ
MIMEタイプ, Prefilters
misconfigurations, testparmによる設定ファイルの検査
misinformation, ドメインメンバーシップ
MIT, /etc/krb5.confの設定, ADSドメイン
MIT kerberos, ADSドメイン, Winbindを使ったIDMAPデータのLDAPへの格納
MIT Kerberos, その機能と利点
mixed mode, ADS セキュリティモード(ユーザーレベルのセキュリティ), Windows 2000との間での、NT4形式のドメイン信頼関係
mkdir, 集中印刷サーバー, Shadow Copy のセットアップ
mkfs.xfs, Shadow Copy のセットアップ
MMC, 機能と利便性, 機能と利便性, ドメインメンバーサーバーかドメインメンバークライアント, プライマリドメインコントローラー, 共有のアクセス制御, Windows 200x/XP, システムポリシーの作成と運用, Windows NT4/200x, 移動プロファイルサポートを無効にする
MMC snap-in, Windows 200x/XPポリシーの管理
modem/ISDN, NoMachine.Comによるリモート管理
modprobe, Shadow Copy のセットアップ
modules, 機能と利便性
mount, 共有レベルのセキュリティ
mouse-over, NoMachine.Comによるリモート管理
moveuser.exe, moveuser.exe
MS DCE RPC, SambaサーバーをPDCドメインに参加させる
MS Windows NT4/200x, 新しいアカウント格納システム
MS Windows SID, ドメインメンバーサーバーかドメインメンバークライアント
MS WINS, 機能と利便性
MS-DFS, MS-DFS: 貧者のクラスター
MS-RPC, Samba-2.2からの印刷環境
MS-WINS 複製, NetBIOS over TCP/IP
msdfs リンク, 特徴と利点
msg, SWAT国際化サポートの有効化
msg ファイル, SWAT国際化サポートの有効化
MSRPC, Microsoft Remote Procedure Calls, Name Service Switch
multiple network interfaces, 複数のインタフェース
multiple server personalities, 詳細設定のテクニック
multiple universal naming convention provider (see MUP)
mutual assistance, 無償サポート
My Network Places, Microsoft Windows Me
Myrinet, サーバープール通信の要求
Mノード, 静的なWINSエントリ

N

n security context, どのようにブラウジングは機能するか
n-memory buffer, NetBIOSネームキャッシュ
name lookup, ドメインコントローラーの種類
name resolution, /etc/hosts
name-to-address, WINS: The Windows Internetworking Name Server
nameserv.h, 静的なWINSエントリ
native ACLs, 機能と利便性
native dump, Amanda
native member, ドメインコントローラーの種類, 機能と利便性
native mode, ADS セキュリティモード(ユーザーレベルのセキュリティ)
NBT, Microsoft Windowsネットワーク内でのような名前解決
nbtstat, マシンをドメインに追加し直すことができない, NetBIOSネームキャッシュ
negotiating the charset, 文字セットとユニコードとは何か
nested group, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
nested groups, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
net, アカウント管理ツール, グループのマッピング: Microsoft Windows と UNIX, リモートとローカル管理:Netコマンド, 概要, 管理者の作業と手段, UNIXとWindowsのグループ管理, Windowsクライアントの管理が出来る権利と権限は何か?
ads, UNIXとWindowsのグループ管理
join, Samba-3でNT4形式でのドメインに参加する, コンピュータアカウントの作成, マシン信頼アカウント, ADSドメイン
leave, マシン信頼アカウント
printer info, プリンターとADS
printer publish, プリンターとADS
printer remove, プリンターとADS
printer search, プリンターとADS
status, マシン信頼アカウント
testjoin, マシン信頼アカウント
getlocalsid, ユーザーとグループの変更, セキュリティ識別子(SID)の管理, 新しいスキーマ
groupmap, 例: エンジニアリングオフィス, ユーザーとグループの変更, 機能と利便性, 設定例, 移行プロセスの手順
add, WindowsグループからUNIXグループへのマッピング
delete, WindowsグループからUNIXグループへのマッピング
list, 設定例, 新しいグループの追加又は作成
modify, WindowsグループからUNIXグループへのマッピング
localgroup, Windowsクライアントの管理が出来る権利と権限は何か?
rap, UNIXとWindowsのグループ管理
session, セッションとコネクションの管理
rpc, 設定例, 設定例, 機能と利便性, UNIXとWindowsのグループ管理
getsid, バックアップドメインコントローラーの設定, セキュリティ識別子(SID)の管理
group, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, 新しいグループの追加又は作成
group add, 新しいグループの追加又は作成
group addmem, グループメンバーシップの操作, Sambaサーバーからのワークステーション上のネストされたグループの管理
group delete, グループアカウントの削除
group delmem, グループメンバーシップの操作
group list, 新しいグループの追加又は作成
group members, グループメンバーシップの操作
group rename, グループアカウントの改名
info, その他の雑多な操作, 補足事項
join, 設定例, Samba-3でNT4形式でのドメインに参加する, マシン信頼アカウント, SambaサーバーをPDCドメインに参加させる, 移行プロセスの手順
join bdc, マシン信頼アカウント
join member, マシン信頼アカウント
list, “net rpc rights”ユーティリティの使用
printer migrate drivers, プリンターの移行
printer migrate forms, プリンターの移行
printer migrate printers, プリンターの移行
printer migrate security, プリンターの移行
printer migrate settings, プリンターの移行
right list accounts, 共有の移行
rights grant, 管理ユーザーの権限と権利, “net rpc rights”ユーティリティの使用
rights list, 管理ユーザーの権限と権利
rights list accounts, 管理ユーザーの権限と権利
share add, 共有の作成、編集と削除
share delete, 共有の作成、編集と削除
share migrate, 共有の移行
share migrate all, 共有とファイルの同時移行
share migrate files, ファイルとディレクトリの移行
share migrate security, 共有のアクセス許可の移行
testjoin, マシン信頼アカウント
trustdom add, ドメイン間の信頼関係
trustdom establish, ドメイン間の信頼関係, 信頼するドメインとしてのSamba
trustdom list, ドメイン間の信頼関係
trustdom revoke, ドメイン間の信頼関係
user add, ユーザーアカウントの追加
user delete, ユーザーアカウントの削除, マシン信頼アカウント
user info, ユーザーアカウントの管理
user password, ユーザーアカウントの追加
user rename, ユーザーアカウントの管理
vampire, ユーザーとグループの変更, 共有、ディレクトリとファイルのマイグレーション(移行), 移行プロセスの手順
setlocalsid, セキュリティ識別子(SID)の管理
time, その他の雑多な操作
set, その他の雑多な操作
system, その他の雑多な操作
zone, その他の雑多な操作
use, サーバー設定のテスト
NET, Samba PDC
net getlocalsid, 管理者のドメインSID
net groupmap, 新しいスキーマ
net rpc user add, 権限の説明
net tool, passdbバックエンドと認証
net use, エラーメッセージ: “異なった名前で接続できない”
net use /home, Windows 9x/Me ユーザープロファイル
net use lpt1:, クライアント上でのPostScriptドライバーのインストール
net view, [global]セクション, テスト
netatalk, netatalk
NetAtalk, 基本的なパラメーターの設定
Netatalk, Macintoshクライアント
NetBEUI, Microsoft Windows ネットワークへのSambaの統合
NetBIOS, ドメインセキュリティモード(ユーザーレベルのセキュリティ), 機能と利便性, ネットワーク上のドメインコントローラーになれる要件, どのようにワークステーションがそのドメインコントローラーを探すか?, 設定例, 機能と利便性, 議論, TCP/IPなしのNetBIOS, ブラウジングの技術的な概要, Microsoft Windows ネットワークへのSambaの統合, Microsoft Windowsネットワーク内でのような名前解決, NetBIOSネームキャッシュ
brooadcast, ドメイン制御の準備
名, ドメインセキュリティモード(ユーザーレベルのセキュリティ)
netbios alias, 複数仮想サーバーの性質(Personalities)
netbios aliases, 複数仮想サーバーの性質(Personalities)
netbios name, 複数のサーバーのホスティング
NetBIOS Name Server (see NBNS)
NetBIOS names, /etc/nsswitch.conf
NetBIOS over TCP/IP, ネットワークブラウジング, 機能と利便性, NetBIOS over TCP/IP, ブラウジングの技術的な概要, サブネット間のブラウジング, 背景情報
NetBIOS over TCP/IPが無効, 共有とディレクトリのブラウジングが非常に遅い
NetBIOS over TCP/IPを有効, NetBIOS over TCP/IP
NetBIOS の段階的な廃止, 議論
NetBIOS ネットワーキング, 機能と利便性
NetBIOS ネットワークインタフェース, Windowsのネットワークプロトコル
NetBIOSが無効, 機能と利便性
NetBIOSなし, TCP/IPなしのNetBIOS, 複数仮想サーバーの性質(Personalities)
NetBIOSなしの SMB over TCP/IP, NetBIOS over TCP/IP
NetBIOSなしのSMB, 複数仮想サーバーの性質(Personalities)
NetBIOSフラグ, 静的なWINSエントリ
NetBIOSブロードキャスト, Samba-3でNT4形式でのドメインに参加する
NetBIOS名, セキュリティモードとマスターブラウザー, マシン信頼アカウントの手動作成, Samba-3でNT4形式でのドメインに参加する, 名前解決の順序, Microsoft Windowsネットワーク内でのような名前解決, 複数仮想サーバーの性質(Personalities)
NetBIOS名の登録, どのようにブラウジングは機能するか
NetBIOS名の解決, ネットワークブラウジング, Sambaをドメインマスターにする
NetBIOS名の長さ, WINS: The Windows Internetworking Name Server
NetBIOS名前キャッシュ, マシンをドメインに追加し直すことができない, SambaのNetBIOS名前キャッシュのフラッシュ
NetBIOS名前タイプ, どのようにブラウジングは機能するか
NetBIOS名前解決, サブネット間ブラウジングの動作
NetBT, Microsoft Windowsネットワーク内でのような名前解決
netlogon, ドメインコントローラーの種類
NETLOGON, ドメイン制御の準備, ドメイン制御: 設定例, システムポリシーの作成と運用, Microsoft Windows 200x/XP Professionalのポリシー, アカウント/ユーザーポリシーの管理, MS Windows NT4 Workstation, MS Windows 200x/XP
Netlogon, 基本的な背景情報について
netlogon share, バックアップドメインコントローラーの設定
NetLogonサービス, WINS: The Windows Internetworking Name Server
netlogon共有, 移行プロセスの手順
Netmon, Windowsのネットワークモニター
Netmon., NTワークステーション上へのネットワークモニターのインストール
netmon.exe, Windows 9x/Me のプロファイル設定
NetSAMLogon, 移動プロファイル
Netscape's Directory Server, サポートしているLDAPサーバー
NetServerEnum2, サブネット間ブラウジングの動作
NetUserGetInfo, Windows 9x/Meにおける特別な例, 移動プロファイル
NetWare, Microsoft Windowsネットワーク内でのような名前解決
NetWare Bindery, その機能と利点
NetWare Core Protocol-based server, その機能と利点
NetWkstaUserLogon, Windows 9x/Meにおける特別な例
network
logon, ドメイン制御: 設定例
wide-area, Microsoft Windows NT4スタイルのドメイン制御
Network Basic Extended User Interface (see NetBEUI)
Network Basic Input/Output System (see NetBIOS)
Network Bridge, Microsoft Windows XP Professional
Network Bridgeの設定, Microsoft Windows XP Professional
network difficulty, 機能と利便性
network segment, どのようにブラウジングは機能するか
networkクライアント, 機能と利便性
netコマンド, Samba-3.0.xにおける新しい機能
newsgroup, 概要
Nexus.exe, 機能と利便性, NT4サーバーマネージャによるドメインマシンアカウントの管理, リモートサーバー管理
Nexusツールキット, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
NFS, Sambaドメインメンバー間でのユーザーIDマッピング共有, 分散マシン上の共通のUID/GIDマッピング, ThinLincを使うリモート管理, 分散ファイルシステムの試み, 分散ファイルシステム上の限定的な制約, IdMap LDAPサポート
NFSクライアント, UNIXまたはNFSクライアントがアクセスしたファイル
NIS, 共有レベルのセキュリティ, バックアップドメインコントローラーの設定, RFC 2307 posixAccountとの関係とスキーマ, ドメインメンバーサーバーかドメインメンバークライアント, Name Service Switch
NISデータベース, Pluggable Authentication Modules
nmbd, Sambaを起動する, testparmによる設定ファイルの検査, セキュアな読み書き可能ファイルと印刷サーバー, 設定例, ブラウジングとは何か?, NetBIOS over TCP/IP, Sambaでのブラウジングサポート, SambaのNetBIOS名前キャッシュのフラッシュ, NT4形式のドメイン(Sambaドメインを含む), テスト, Linux, Solaris, 複数のサーバーのホスティング, 複数仮想サーバーの性質(Personalities), テスト, Sambaそれ自身によるデバッグ, 壊れたtdbファイル
nmblookup, NetBIOSネームキャッシュ, テスト
No NetBIOS layer, TCP/IPなしのNetBIOS
nobody, 集中印刷サーバー
nobody account, 複数仮想サーバーの性質(Personalities)
nobodyアカウント, カスタム印刷コマンド
NoMachine, NoMachine.Comによるリモート管理
NoMachine.Com, NoMachine.Comによるリモート管理
non-authoritative, サブネット間ブラウジングの動作
nontransitive, 信頼関係に関する背景情報
normal color, cupsomatic/foomaticの役割
not transitive, Windows 2000との間での、NT4形式のドメイン信頼関係
Novell, ドメインメンバーサーバー
Novell eDirectory server, その機能と利点
NSS, 背景, 分散マシン上の共通のUID/GIDマッピング, LDAPディレクトリとWindowsのコンピュータアカウント, ldapsam, RFC 2307 posixAccountとの関係とスキーマ, アカウントとグループの管理, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, 識別情報のマッピング(IDMAP), ドメインメンバーサーバーかドメインメンバークライアント, IDMAP_RIDを使うWinbind, 機能と利便性, Winbindが提供するもの, Winbindの動き方, Name Service Switch, WinbindとPAMの設定, 結論
nsswitch.conf, 共有レベルのセキュリティ
nss_ldap, 設定例, 分散マシン上の共通のUID/GIDマッピング, LDAPディレクトリとWindowsのコンピュータアカウント, 識別情報のマッピング(IDMAP), ドメインメンバーサーバーかドメインメンバークライアント, RFC2307bis Schema拡張を使ったADSからのIDMAPとNSSに対するLDAPの使用
nss_winbind.so.1, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
NT サーバーマネージャ, Windows NT4 Workstation/Server
NT-controlled domain, 信頼するドメインとしてのSamba
NT4, ドメインメンバーサーバーかドメインメンバークライアント
NT4 ドメイン, 機能と利便性
Nt4sp6ai.exe, Windows NT4形式のポリシーファイル
NT4のドメインメンバー, 識別情報のマッピング(IDMAP)
NT4ドメイン, スタンドアロンSambaサーバー, ドメインメンバーサーバーかドメインメンバークライアント
NT4形式, Windows 2000との間での、NT4形式のドメイン信頼関係
NT4形式のドメイン, ドメイン間の信頼関係, 信頼関係に関する背景情報
NT4形式のポリシー更新, アカウント/ユーザーポリシーの管理
NTConfig.POL, ドメイン制御: 設定例, 機能と利便性, Windows 9x/ME ポリシー, 腐ったレジストリ, Microsoft Windows 200x/XP Professionalのポリシー, Windows 200x/XPポリシーの管理, アカウント/ユーザーポリシーの管理, SambaのEditregツールセット, MS Windows NT4 Workstation, Samba-3実装の選択
ntconfig.pol, Windows NT4形式のポリシーファイル
ntdrivers.tdb, 新しいプリンターに対するデバイスモードの設定, 印刷関連の*.tdbファイル
(see also TDB)
ntforms.tdb, 新しいプリンターに対するデバイスモードの設定, 印刷関連の*.tdbファイル
(see also TDB)
NTFS, ユーザーとグループの変更, Microsoft Windows NTFSとUNIXファイルシステムとの比較
NTLMv2, NTLMv2のセキュリティ
ntlm_auth, シングルサインオンとドメインセキュリティ
ntprinters.tdb, 新しいプリンターに対するデバイスモードの設定, 印刷関連の*.tdbファイル
(see also TDB)
NTUser.DAT, SambaのEditregツールセット, 必須プロファイル, Samba-3実装の選択
NTuser.DAT, Windows NT4 workstation, Windows 9x/Me と NT4/200x/XP ワークステーション間でプロファイルを共有する , プロファイルの移行/作成
NTuser.MAN, Windows NT4 workstation
NTUser.MAN, 必須プロファイル
NT_STATUS_LOGON_FAILURE, 動作の変更点
NT_STATUS_UNSUCCESSFUL, adddriverを付けたprinter driver filesの実行
NTのパスワード, ユーザーとマシンアカウントの表示
NTグループ, これがなぜsecurity = serverよりもすぐれているのか?, 既定値のユーザー、グループと相対識別子
NTドメイン, Winbindが提供するもの
NTマイグレーションスクリプト, ldapsam
NT形式で暗号化されたパスワード, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
NT方式による暗号化パスワード, 下位互換性のあるバックエンド
null shell, マシン信頼アカウントの手動作成
NX, NoMachine.Comによるリモート管理

O

object module dependencies, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
ObjectClass, RFC 2307 posixAccountとの関係とスキーマ
ObjectClasses, RFC 2307 posixAccountとの関係とスキーマ, OpenLDAPの設定
obtuse complexity, サーバーの共有とディレクトリのレイアウト
OID, RFC 2307 posixAccountとの関係とスキーマ
Omni, ドライバー開発の外側
on-the-fly, プライマリドメインコントローラー
on-the-fly logon scripts, 目的
on-the-fly policy files, 目的
one domain, 識別情報のマッピング(IDMAP)
OpenGFS, 分散ファイルシステムの試み
OpenLDAP, シングルサインオンとドメインセキュリティ, LDAP設定の注意, ドメインメンバーサーバー, Samba-3.0.23におけるLDAPの変更, 新しいアカウント格納システム, サポートしているLDAPサーバー, RFC 2307 posixAccountとの関係とスキーマ, OpenLDAPの設定, その機能と利点
OpenLDAPバックエンド, 下位互換性のあるバックエンド
OpenSSL, SSLを使うSWATのセキュア化, 認証局の作成
oplock, 分散ファイルシステムの試み
oplock break, Opportunistic Lockingの概要, Force Userに対する注意
oplock messages, Sambaに対する変更要求
oplocks, Opportunistic Lockingの概要
oplocks disabled, マルチユーザーデータベース
oplocksの実装, 高度なSamba Oplocksパラメーター
oplocksの無効化, PDM Data Shares
oplocksの管理, PDM Data Shares
oplockのメカニズム, 高度なSamba Oplocksパラメーター
oplockハンドリング, 分散ファイルシステム上の限定的な制約
oplockパラメーター, 高度なSamba Oplocksパラメーター
opportunistic locking, 機能と利便性, Opportunistic Lockingの概要
Opportunistic locking, Opportunistic Lockingの概要
optional, /etc/pam.d にあるエントリーの構造
Oracle(Sun) Solaris, その機能と利点
Organization for the Advancement of Structured Information Standards (see OASIS)
organizational directory, コンピュータアカウントの作成
organizational unit, コンピュータアカウントの作成 (see OU)
os level, ドメイン制御: 設定例
OSS/Free Software, NoMachine.Comによるリモート管理
OSサーチパス, SWATファイルの配置
other, ファイルとディレクトリのアクセス制御
outside threat, ホストベースの保護の使用
ownership, ファイルの所有者の表示
ownership cost, 目的

P

p-node, NetBIOS over TCP/IP
package, 設定の例
PADL, 分散マシン上の共通のUID/GIDマッピング, LDAPディレクトリとWindowsのコンピュータアカウント, ドメインメンバーサーバーかドメインメンバークライアント, Winbindを使ったIDMAPデータのLDAPへの格納
PADLバックエンド, 分散マシン上の共通のUID/GIDマッピング
page_log, page_logファイルの形式
paid-for support, Samba サポート
PAM, 背景, 下位互換性のあるバックエンド, 分散マシン上の共通のUID/GIDマッピング, 平文, ldapsam, Winbindの動き方, Pluggable Authentication Modules, 用件, テスト, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する, WinbindとPAMの設定, 結論, その機能と利点, 技術的な議論
PAM module, AIXにおけるNSS Winbind
PAM modules, その機能と利点
PAM が利用可能, PAM ベースの分散型認証
PAM の管理, PAM ベースの分散型認証
PAM 特有のトークン, PAM 設定のための文法
PAM 認証モジュール, PAM 設定のための文法
pam-devel, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する
pam_krb5.so, その機能と利点
pam_ldap, 分散マシン上の共通のUID/GIDマッピング
pam_ldap.so, その機能と利点
pam_mkhomedir, Linux/FreeBSD固有のPAM設定
pam_ncp_auth.so, その機能と利点
pam_pwdb.so, その機能と利点
pam_securetty.so, Linux/FreeBSD固有のPAM設定
pam_smbpass.so, PAM ベースの分散型認証, その機能と利点
pam_smbpasswd.so, その機能と利点
pam_smb_auth.so, その機能と利点
pam_unix.so, Linux/FreeBSD固有のPAM設定, その機能と利点
pam_unix2.so, その機能と利点
pam_userdb.so, その機能と利点
pam_winbind.so, Pluggable Authentication Modules, WinbindとPAMの設定, Linux/FreeBSD固有のPAM設定, その機能と利点
PAMが利用可能, その機能と利点
PAMが有効, Winbindが提供するもの
PAMの設定, 用件
PAMを有効にする, その機能と利点
paranoid, winbindddaemonの開始とテスト
passdb, マシンアカウントが満了し続ける
passdb backend, ドメイン制御: 設定例, アカウント情報データベース, LDAPに関するコメント, smbpasswdツール, 既定値のユーザー、グループと相対識別子, プライマリドメインコントローラー, 管理者のドメインSID, その機能と利点, 検索のための新しいサフィックス
passdb バックエンド, Samba-3.0.23でのグループマッピングの変更
passdbバックエンド, pdbeditツール, アカウントの削除, smbpasswd: 暗号化したパスワードデータベース, tdbsam, ドメインメンバーサーバーかドメインメンバークライアント, プライマリドメインコントローラー, ドメイン間の信頼関係, Samba-3.0.xにおける新しい機能
passwd, 集中印刷サーバー, LDAPディレクトリとWindowsのコンピュータアカウント, smbpasswdツール, Name Service Switch, その機能と利点
password, 信頼されるドメインとしてのSamba, 信頼するドメインとしてのSamba, /etc/pam.d にあるエントリーの構造
password aging, アカウント管理ツール
password expiration, smbpasswd: 暗号化したパスワードデータベース
patch, パッチ
pauses, Sambaのパフォーマンスがとても悪い
PBM, MIMEタイプとCUPSフィルタ
PCL, Windows上でのGDI、UNIX上でのPostScript, Windowsドライバー、GDIとEMF, UNIX印刷ファイル変換とGUIの基礎, インタフェーススクリプトを伴う印刷, サーバー上でのドライバーの実行, ネットワーク PostScript RIP
pdbedit, 例: エンジニアリングオフィス, アカウント管理ツール, pdbeditツール, ユーザーアカウントマネージャ, ユーザーとマシンアカウントの表示, ユーザーアカウントの追加, アカウントの削除, ユーザーアカウントの変更, アカウントフラグ管理, アカウントのインポート/エクスポート, 管理者のドメインSID, Samba PDC, お手軽移行ガイド, passdbバックエンドと認証, 移行プロセスの手順, Samba-3実装の選択
pdb_ldap, これをすべてのLDAPに使えるか?
PDC, ドメインセキュリティモード(ユーザーレベルのセキュリティ), 設定例, ドメインコントローラーの種類, セキュリティモードとマスターブラウザー, 機能と利便性, Microsoft Windows NT4スタイルのドメイン制御, PDCの設定例, LDAP設定の注意, ネットワーク上のドメインコントローラーになれる要件, バックアップドメインコントローラーの設定, 設定例, SambaはNT4 PDCのバックアップドメインコントローラーになれるか?, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, マシン信頼アカウントの手動作成, Samba-3でNT4形式でのドメインに参加する, これがなぜsecurity = serverよりもすぐれているのか?, マシンのドメインへの追加に失敗する, ワークグループのブラウジングの設定, ドメインブラウジングの設定, 新しいアカウント格納システム, 暗号化されたパスワードの長所, tdbsam, sambaSamAccountsのための特別なLDAP属性, 議論, 概要, ドメインメンバーサーバーかドメインメンバークライアント, プライマリドメインコントローラー, 信頼されるドメインとしてのSamba, 信頼するドメインとしてのSamba, Samba PDCににおけるcupsaddsmb, 外部のSIDの取り扱い, Microsoft Remote Procedure Calls, Pluggable Authentication Modules, 結果のキャッシュ保存, はじめに, SambaサーバーをPDCドメインに参加させる, winbindddaemonの開始とテスト, NoMachine.Comによるリモート管理, 新しいスキーマ, ドメインレイアウト, メーリングリストにからの助言, 壊れたtdbファイル
PDF, CUPSを使う簡単なsmb.confの設定, Windowsドライバー、GDIとEMF, PostScriptプリンター定義(PPD)の仕様, MIMEタイプとCUPSフィルタ, Prefilters, フィルタリングチェインの例
pdf, MIMEタイプ変換ルール
pdftops, MIMEタイプ変換ルール, フィルタリングチェインの例
pdftosocket, フィルタリングチェインの例
PDFフィルタ, 集中印刷サーバー
PDF抽出, PostScriptプリンター定義(PPD)の仕様
PDL, Windows上でのGDI、UNIX上でのPostScript, PostScriptとGhostscript, PostScriptプリンター定義(PPD)の仕様
PDM, PDM Data Shares
peer domain, SambaにおけるNT形式のドメイン信頼関係の設定
performance advantage, 機能と利便性
perimeter firewall, 機能と利便性
permissions, なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?
share, 共有のアクセス制御の定義
share ACLs, 共有のアクセス制御
Permissions, Windows 200x/XP
PGP, SambaのPGP署名の検証
Photo-CD, MIMEタイプとCUPSフィルタ
PID, 稼働中のプロセスへのアタッチ
pid directory, 複数のサーバーのホスティング
ping, ドメインレイアウト, テスト
PJL, ネットワーク PostScript RIP, WindowsのCUPS PostScriptドライバー対Adobeドライバー, Windowsクライアント用のAdobeとCUPS PostScriptドライバー
PJL-ヘッダー, Windowsクライアント用のAdobeとCUPS PostScriptドライバー
PLP, [global]セクション
Pluggable Authentication Modules (see PAM)
PNG, Ghostscript: 非Postscriptプリンターに対するソフトウェアRIP, MIMEタイプとCUPSフィルタ
PNM, MIMEタイプとCUPSフィルタ
Point'n'Print, 機能と利便性
point'n'print, クライアント上でのPostScriptドライバーのインストール
Poledit, Windows 200x/XPポリシーの管理
poledit.exe, システムポリシーの作成と運用, Windows NT4形式のポリシーファイル, Windows 200x/XPポリシーの管理
port 135, 複数のインタフェース
Port 135/TCP, ファイアウォールの使用
port 137, 複数のインタフェース
Port 137/UDP, ファイアウォールの使用
port 138, 複数のインタフェース
Port 138/UDP, ファイアウォールの使用
port 139, 複数のインタフェース
Port 139/TCP, ファイアウォールの使用
port 445, 複数のインタフェース
Port 445/TCP, ファイアウォールの使用
ports, testparmによる設定の検査, Ethereal
POSIX, バックアップドメインコントローラーの設定, LDAPディレクトリとWindowsのコンピュータアカウント, アカウントとグループの管理, 新しいグループの追加又は作成
POSIX ACLs, ファイルとディレクトリのアクセス制御, ディレクトリとファイルの削除操作からの保護
POSIX ACLS, Samba-3実装の選択
POSIX identity, LDAPとSambaに対する注意
POSIX locks, サーバープールの通信
POSIX semantics, サーバープールの通信
posixAccount, RFC 2307 posixAccountとの関係とスキーマ, OpenLDAPの設定
posixGroup, OpenLDAPの設定, アカウントとグループの管理
POSIXアカウント, ユーザーアカウントマネージャ, UNIXとWindowsのユーザー管理
POSIXユーザーアカウント, ドメイン間の信頼関係
PostScript, CUPSを使う簡単なsmb.confの設定, Postscriptドライバーダウンロードを使う高度に賢い印刷, Windows上でのGDI、UNIX上でのPostScript, Windowsドライバー、GDIとEMF, UNIX印刷ファイル変換とGUIの基礎, PostScriptとGhostscript, PostScriptプリンター定義(PPD)の仕様, Windows形式のベンダPPDの使用, MIMEタイプとCUPSフィルタ, Prefilters, pstops, 非PostScriptプリンターのためのPostScriptプリンター記述, フィルタリングチェインの例, サーバー上でのドライバーの実行, ネットワーク PostScript RIP, CUPS: A “Magical Stone”?, カーネルモードでもPostScriptドライバーは大きな問題はない, Windows NT/200x/XP用のCUPS“PostScript Driver”
(see also Ghostscript)
RIP, PostScriptとGhostscript
PostScriptインタプリタ, PostScriptとGhostscript
PostScriptドライバー, [print$]へのドライバーファイルインストール
PostScriptプリンター, Windowsに接続された印刷へのCUPSからの印刷
PostScriptプリンター記述 (see PPD)
potential printer, [print$]セクションのパラメーター
Power Users, Windowsクライアントの管理が出来る権利と権限は何か?
powerful, ドメインコントローラーの種類
PPD, [print$]へのドライバーファイルインストール, PostScriptとGhostscript, PostScriptプリンター定義(PPD)の仕様, 非PostScriptプリンターのためにCUPSはPPDを使う, MIMEタイプとCUPSフィルタ, “Raw”印刷, 非PostScriptプリンターのためのPostScriptプリンター記述, UNIX上の、非PSプリンターのためのPPD, Windows上の非PostScriptプリンターのためのPPD, CUPS: A “Magical Stone”?, クライアント上でのPostScriptドライバーのインストール, Windowsクライアント用のAdobeとCUPS PostScriptドライバー, Windowsに接続された印刷へのCUPSからの印刷
CUPS (see CUPS-PPD)
PPD-aware, PostScriptとGhostscript
PPDs, Windows形式のベンダPPDの使用, cupsomatic/foomaticの役割, すばらしい統一の達成
PPP, インタフェース保護の使用
precedence, 強制的にSambaをマスターにする
preferred master, ドメイン制御: 設定例
prefilter, imagetops と imagetoraster
prefilters, Prefilters
Primary Logon, Windows 9x/Me のプロファイル設定
print, testparmによる設定の検査
queue, 設定ファイルの文法
spooler, 設定ファイルの文法
print accounting, 機能と利便性
print jobs, [global]セクション
print quota, Postscriptドライバーダウンロードを使う高度に賢い印刷
printcap, 設定ファイルの文法, [global]セクション, [printers]セクション
Printcap, 基本的なCUPSサポート設定
PrintcapFormat, 基本的なCUPSサポート設定
printcapファイルがない, 集中印刷サーバー
printcap名, 集中印刷サーバー
printer driver, 無効になった [printer$]セクション
printer queue, Samba-2.2からの印刷環境
printer$ share, 無効になった [printer$]セクション
printers, 設定ファイルの文法
Printers, [global]セクション
printers admin, 権限の説明
printersセクション, [printers]セクション
printing, [global]セクション
printing now, Sambaのパフォーマンスがとても悪い
printing.tdb, 新しいプリンターに対するデバイスモードの設定, 印刷関連の*.tdbファイル
(see also TDB)
PrintPro (see ESP Print Pro)
private dir, 複数のサーバーのホスティング
private groups, 警告:ユーザー固有のグループ問題
private key, SSLを使うSWATのセキュア化
private/MACHINE.SID, バックアップドメインコントローラーの設定
private/secrets.tdb, バックアップドメインコントローラーの設定
privilege, 3.0.11より前のバージョンのみに適用, 権限の説明
privilege management, 管理に関する重要な情報
privileges, シングルサインオンとドメインセキュリティ, 3.0.11より前のバージョンのみに適用, 権限の説明
problem report, 無償サポート
problem resolution, Samba サポート
problematic print, 技術的な序論
process
の開始, Sambaを起動する
Process data management, PDM Data Shares
professional support, 無償サポート
profile, Windows 9x/Meにおける特別な例
profile path, PDCの設定例
ProfilePath, Windows 9x/Me のプロファイル設定
profiles, Windows 9x/Meにおける特別な例
project, 無償サポート
promiscuous mode, Windowsのネットワークモニター
propagate, 機能と利便性
provided services, Samba サポート
provisioned, シングルサインオンとドメインセキュリティ
pstops, Prefilters, pstops, フィルタリングチェインの例, Windowsクライアント用のAdobeとCUPS PostScriptドライバー
pstoraster, pstoraster, cupsomatic/foomatic-rip 対 ネイティブなCUPS印刷, Windowsクライアント用のAdobeとCUPS PostScriptドライバー
PulseAudio, ThinLincを使うリモート管理
put, テスト
pvcreate, Shadow Copy のセットアップ
Pノード, 静的なWINSエントリ

R

RAID, BackupPC
RAP, UNIXとWindowsのグループ管理
raster, Prefilters, Foomaticデータベースが生成したPPD
raster driver, CUPSフィルタリングアーキテクチャ
raster images, UNIX印刷ファイル変換とGUIの基礎
rastertoalps, rasterto [プリンター固有]
rastertobj, rasterto [プリンター固有]
rastertoepson, rasterto [プリンター固有], フィルタリングチェインの例
rastertoescp, rasterto [プリンター固有]
rastertohp, rasterto [プリンター固有]
rastertopcl, rasterto [プリンター固有]
rastertoprinter, rasterto [プリンター固有]
rastertosomething, cupsomatic/foomatic-rip 対 ネイティブなCUPS印刷
rastertoturboprint, rasterto [プリンター固有]
raw mode, application/octet-stream 印刷
raw printers, Overview
raw printing, 集中印刷サーバー
raw SMB, 機能と利便性
raw SMB over TCP/IP, TCP/IPなしのNetBIOS
rawprinter, “Raw”印刷
raw印刷, application/octet-streamのための“raw”印刷を明示的に有効にする, cupsaddsmbフローチャート
rcp, Rsync
rdesktop, NoMachine.Comによるリモート管理
rdesktop/RDP, NoMachine.Comによるリモート管理
read, ファイルとディレクトリのアクセス制御
read only, fake_perms
Read-ahead, Opportunistic Lockingの概要
realm, ADS セキュリティモード(ユーザーレベルのセキュリティ), NetBIOS Over TCP/IPが無効, smb.confの設定, /etc/krb5.confの設定, IDMAP_RIDを使うWinbind, Winbindを使ったIDMAPデータのLDAPへの格納
rebooted, ワークグループのブラウジングの設定
recycle, recycle
recycle bin, 議論
recycle directory, recycle
recycle:exclude, recycle
recycle:exclude_dir, recycle
recycle:keeptree, recycle
recycle:maxsize, recycle
recycle:noversions, recycle
recycle:repository, recycle
recycle:subdir_mode, recycle
recycle:touch, recycle
recycle:versions, recycle
Red Hat Linux, LDAP設定の注意, マシン信頼アカウントの即時作成, 警告:ユーザー固有のグループ問題
Red Hatクラスターマネージャ, 高可用性サーバー製品
redirect, 設定例
redundancy, NetBIOS over TCP/IP
regedit.exe, MS Windows 9x/Me
regedt32, MS Windows NT4 Workstation
regedt32.exe, Windows NT4/200x
registered, WINS: The Windows Internetworking Name Server, Sambaがドライバーを認識したかの確認
registers, ドメインブラウジングの設定
registry, Windows 9x/ME ポリシー
rejoin, セキュリティ識別子(SID)の管理
relationship password, 信頼されるドメインとしてのSamba
relative identifier (see RID)
Remote Access Dial-In User Service (see RADIUS)
remote announce, サブネット間のブラウジング
remote browse sync, サブネット間のブラウジング
Remote X, NoMachine.Comによるリモート管理
rename, ディレクトリの管理
render, 直接印刷機能:Windowsクライアント上のベンダドライバー
repeated intervals, NetBIOS over TCP/IP
replicate, バックアップドメインコントローラーの設定
replicated, 機能と利便性, 機能と利便性, Active Directoryドメイン制御, Microsoft Windows 200x/XP Professionalのポリシー
replicated SYSVOL, Microsoft Windows 200x/XP Professionalのポリシー
replication
SAM, 機能と利便性, Microsoft Windows NT4スタイルのドメイン制御
requesting payment, 無償サポート
required, /etc/pam.d にあるエントリーの構造
requisite, /etc/pam.d にあるエントリーの構造
resolver functions, Name Service Switch
resource failover, 高可用性サーバー製品
resource kit, Windows 200x/XPポリシーの管理
response, IDMAP_RIDを使うWinbind
RFC 1001, 設定例
RFC 1002, 設定例
RFC 1179, [global]セクション
RFC 2307, 分散マシン上の共通のUID/GIDマッピング
RFC 2307., RFC 2307 posixAccountとの関係とスキーマ
RFC 2830, 概要
rfc2307bis, RFC2307bis Schema拡張を使ったADSからのIDMAPとNSSに対するLDAPの使用
RFC2830, LDAP設定の注意
RFCs, Sambaの問題の調査と解決方法
rich database backend, 新しいアカウント格納システム
rich directory backend, 新しいアカウント格納システム
RID, 機能と利便性, マシン信頼アカウントの手動作成, ユーザーとグループの変更, 議論, 既定値のユーザー、グループと相対識別子, ドメインメンバーサーバーかドメインメンバークライアント, プライマリドメインコントローラー, IDMAP_RIDを使うWinbind, 管理者のドメインSID, ユーザーとグループIDの割り当て, 新しいスキーマ
RID 500, 管理者のドメインSID
RID base, プライマリドメインコントローラー
rights, シングルサインオンとドメインセキュリティ, Windows 9x/Meにおける特別な例, よくあるエラー
rights and privileges, 管理に関する重要な情報
RIP, 非PostScriptプリンターのためのPostScriptプリンター記述
rlogind, /etc/pam.d にあるエントリーの構造
rogue machine, SambaのNetBIOS名前キャッシュのフラッシュ
rogue user, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
root, Windows 200x/XP Professionalクライアント, ドメインへの参加: Windows 2000/XP Professional, User Rights and Privileges
root user, “net rpc rights”ユーティリティの使用
rootとして実行, “net rpc rights”ユーティリティの使用
rootアカウント, User Rights and Privileges, 管理者のドメインSID
rotate, UNIX印刷ファイル変換とGUIの基礎
RPC, これがなぜsecurity = serverよりもすぐれているのか?, 機能と利便性, SambaサーバーをPDCドメインに参加させる, 移動プロファイル
rpc.lockd, 議論
rpcclient, リモートとローカル管理:Netコマンド, ドライバーファイルの識別, 指定したドライバー名の自由度, トラブルシューティング再考, Samba PDC
adddriver, 詳細な結果を表示するcupsaddsmbの実行, cupsaddsmbについて理解する, rpcclientを使ったPostScriptドライバーファイルの手動インストール, rpcclientマニュアルページの理解, adddriverとsetdriverを完了させるための要求事項, 15ステップでの手動ドライバーインストール
enumdrivers, rpcclientを使ったPostScriptドライバーファイルの手動インストール, 15ステップでの手動ドライバーインストール
enumports, rpcclientを使ったPostScriptドライバーファイルの手動インストール
enumprinters, rpcclientを使ったPostScriptドライバーファイルの手動インストール, adddriverとsetdriverを完了させるための要求事項, 15ステップでの手動ドライバーインストール, トラブルシューティング再考
getdriver, Producing an Example by Querying a Windows Box, 15ステップでの手動ドライバーインストール
getprinter, Producing an Example by Querying a Windows Box, 15ステップでの手動ドライバーインストール, トラブルシューティング再考
setdriver, 考慮すべき警告, 詳細な結果を表示するcupsaddsmbの実行, cupsaddsmbについて理解する, rpcclientを使ったPostScriptドライバーファイルの手動インストール, adddriverとsetdriverを完了させるための要求事項, 15ステップでの手動ドライバーインストール
RPCコール, 結論
RPCモジュール, Samba-3.0.xにおける新しい機能
RPC呼び出し, 最先端の状況
rsh, BackupPC
rsync, バックアップドメインコントローラーの設定, smbpasswdファイルの複製はどうやるか?, 分散マシン上の共通のUID/GIDマッピング, smbpasswd: 暗号化したパスワードデータベース, BackupPC, Rsync, rsyncとftp経由によるSambaソースへのアクセス
rsyncd, BackupPC
runas, 常時最初のクライアントからの接続はrootか“printer admin”で行う
rundll32, 追加のクライアントドライバーインストール, クライアントドライバーのための既定値の印刷操作の設定, 15ステップでの手動ドライバーインストール, ユーザーの干渉なしにプリンターを追加する

S

SAM, 機能と利便性, ドメインコントローラーの種類, Microsoft Windows NT4スタイルのドメイン制御, マシンアカウントが満了し続ける, SambaはNT4 PDCのバックアップドメインコントローラーになれるか?, smbpasswdファイルの複製はどうやるか?, 機能と利便性, ユーザーとグループの変更, 下位互換性のあるバックエンド, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング, 結果のキャッシュ保存
差分ファイル, Microsoft Windows NT4スタイルのドメイン制御
複製, ドメインコントローラーの種類, Microsoft Windows NT4スタイルのドメイン制御
SAM backend, LDAPに関するコメント
ldapsam, 機能と利便性, 新しいアカウント格納システム, ldapsam
ldapsam_compat, 機能と利便性
smbpasswd, 機能と利便性
tdbsam, 機能と利便性, 新しいアカウント格納システム
SAM バックエンド, 分散マシン上の共通のUID/GIDマッピング
LDAP, 機能と利便性
ldapsam, 分散マシン上の共通のUID/GIDマッピング
smbpasswd, smbpasswd: 暗号化したパスワードデータベース
samba
nmbdの起動, Sambaを起動する
smbdの起動, Sambaを起動する
winbinddの起動, Sambaを起動する
Samba 1.9.17, WINSサーバーの設定
Samba daemons, Samba-3でNT4形式でのドメインに参加する
Samba SAM, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング
Samba SAM アカウント, マシンのドメインへの追加に失敗する
Samba SAMアカウントフラグ, アカウントフラグ管理
Samba メーリングリスト, 特徴と利点
Samba-2.2.x LDAPスキーマ, 下位互換性のあるバックエンド
Samba-3互換のLDAPバックエンド, お手軽移行ガイド
Samba-PDC-LDAP-HOWTO, ldapsam
samba-vscan, vscan
samba.schema, RFC 2307 posixAccountとの関係とスキーマ, OpenLDAPの設定, 新しいスキーマ
sambaDomain, 新しいスキーマ
sambaGroupMapping, 新しいスキーマ
sambaHomeDrive, sambaSamAccountsのための特別なLDAP属性
sambaHomePath, sambaSamAccountsのための特別なLDAP属性
sambaIdmapEntry, 新しいスキーマ
sambaLogonScript, sambaSamAccountsのための特別なLDAP属性
SambaNTPassword, セキュリティとsambaSamAccount
sambaProfilePath, sambaSamAccountsのための特別なLDAP属性
SambaSAMAccount, バックアップドメインコントローラーの設定, アカウント管理ツール, ユーザーアカウントの追加, アカウントの削除, ユーザーアカウントの変更, tdbsam
sambaSamAccount, LDAPディレクトリとWindowsのコンピュータアカウント, RFC 2307 posixAccountとの関係とスキーマ, OpenLDAPの設定, アカウントとグループの管理, sambaSamAccountsのための特別なLDAP属性, 新しいスキーマ
sambaSAMAccount, セキュリティとsambaSamAccount
sambaSID, Samba-3.0.23におけるLDAPの変更
sambaUNIXIdPool, 新しいスキーマ
SambaXPカンファレンス, 技術的な議論
sambaからsambaへの信頼, ドメイン間の信頼関係
Sambaのセキュリティ, 機能と利便性
sambaの起動
winbindd, 機能と利便性
Sambaの違い, Samba-2.xからSamba-3.0.25へのアップグレード
Sambaアカウント, マシン信頼アカウントの手動作成
Sambaスキーマ, 新しいアカウント格納システム
Sambaバックエンドデータベース, マシンのドメインへの追加に失敗する
Sambaプライベートディレクトリ, コンピュータアカウントの作成
Samba管理者, はじめに
samdbインタフェース, smbpasswd: 暗号化したパスワードデータベース
SAMバックエンド
tdbsam, tdbsam
非LDAP, 機能と利便性
Sarbanes-Oxley, pdbeditツール
scalability, tdbsam
scalable, LDAPに関するコメント
scalable coherent interface (see SCI)
scale, UNIX印刷ファイル変換とGUIの基礎
schannel, ドメイン参加後ドメインメンバーワークステーションにログオンできない
scp, Rsync
script, マシンのドメインへの追加に失敗する
scripted control, リモートとローカル管理:Netコマンド
SCSI, 高可用性サーバー製品
SeAddUsersPrivilege, 管理ユーザーの権限と権利, 権利の管理能力, 権限の説明
SeAssignPrimaryTokenPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeAuditPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeBackupPrivilege, 管理ユーザーの権限と権利, Windows2000ドメインコントローラーでサポートされている権限
SeChangeNotifyPrivilege, Windows2000ドメインコントローラーでサポートされている権限
Seclib, ファイルの所有者の表示
SeCreateGlobalPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeCreatePagefilePrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeCreatePermanentPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeCreateTokenPrivilege, Windows2000ドメインコントローラーでサポートされている権限
secret, セキュリティに関する重要な注意事項
secrets.tdb, バックアップドメインコントローラーの設定, Sambaドメインメンバー間でのユーザーIDマッピング共有, LDAPデータベースの初期化, 印刷関連の*.tdbファイル
(see also TDB)
security, 序論, 複数仮想サーバーの性質(Personalities)
controllers, ドメインセキュリティモード(ユーザーレベルのセキュリティ)
設定, 設定の例
security = user, Samba-3でNT4形式でのドメインに参加する
Security Account Manager (see SAM)
Security Assertion Markup Language (see SAML)
security credentials, バックアップドメインコントローラー, ネイティブなMicrosoft Windows NT4の信頼関係の設定
security hole, IPC$ 共有ベースの拒否の使用
security mode, セキュリティモードとマスターブラウザー
security name-space, 識別情報のマッピング(IDMAP)
security structure, 信頼関係に関する背景情報
security vulnerability, Sambaのアップグレード
security-aware, application/octet-stream 印刷
SeDebugPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeDiskOperatorPrivilege, 管理ユーザーの権限と権利, 権利の管理能力, 権限の説明
SeEnableDelegationPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeImpersonatePrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeIncreaseBasePriorityPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeIncreaseQuotaPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeLoadDriverPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeLockMemoryPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeMachineAccountPrivilege, 管理ユーザーの権限と権利, 権利の管理能力, 権限の説明, Windows2000ドメインコントローラーでサポートされている権限
SeManageVolumePrivilege, Windows2000ドメインコントローラーでサポートされている権限
SePrintOperatorPrivilege, 管理ユーザーの権限と権利, 権利の管理能力, 権限の説明
SeProfileSingleProcessPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeRemoteShutdownPrivilege, 管理ユーザーの権限と権利, 権利の管理能力, 権限の説明, Windows2000ドメインコントローラーでサポートされている権限
SeRestorePrivilege, 管理ユーザーの権限と権利, Windows2000ドメインコントローラーでサポートされている権限
Server Message Block (see SMB)
service name, 設定の例
services provided, Samba サポート
SeSecurityPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeShutdownPrivilege, Windows2000ドメインコントローラーでサポートされている権限
session, /etc/pam.d にあるエントリーの構造
session setup, ユーザーレベルのセキュリティ, サーバーセキュリティ(ユーザーレベルのセキュリティ)
sessionid.tdb, 印刷関連の*.tdbファイル
(see also TDB)
SessionSetupAndX, ドメインメンバーサーバーかドメインメンバークライアント
SeSyncAgentPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeSystemEnvironmentPrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeSystemProfilePrivilege, Windows2000ドメインコントローラーでサポートされている権限
SeSystemtimePrivilege, Windows2000ドメインコントローラーでサポートされている権限
set group id (see SGID)
set user id (see SUID)
SeTakeOwnershipPrivilege, 管理ユーザーの権限と権利, 権利の管理能力, 権限の説明, Windows2000ドメインコントローラーでサポートされている権限
SeTcbPrivilege, Windows2000ドメインコントローラーでサポートされている権限
setdriver, rpcclientマニュアルページのチェック, adddriverとsetdriverを完了させるための要求事項
SetPrinter(), rpcclientマニュアルページのチェック
SeUndockPrivilege, Windows2000ドメインコントローラーでサポートされている権限
severely impaired, TCP/IPなしのNetBIOS
SFU, IDMAP, Active DirectoryとMicrosoftの Services for UNIX 3.5
SFU 3.5, プライマリドメインコントローラー
SGI-RGB, MIMEタイプとCUPSフィルタ
SGID, ファイルとディレクトリのアクセス制御
shadow, LDAPディレクトリとWindowsのコンピュータアカウント
shadow_copy, shadow_copy
shadow_copyモジュール, shadow_copy
shadowユーティリティ, 機能と利便性
share, 設定ファイルの文法
share settings, 機能と利便性
share-level, 特徴と利点
share-mode security, セキュリティモードとマスターブラウザー
shared secret, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
share_info.tdb, 共有のアクセス制御, 印刷関連の*.tdbファイル
(see also TDB)
Sharing, Windows 200x/XP
shift, UNIX印刷ファイル変換とGUIの基礎
Shift_JIS, 日本語の文字セット, 基本的なパラメーターの設定
show-stopper-type, 計画と開始方法
SID, 機能と利便性, システムにログオンできない(C000019B), バックアップドメインコントローラーの設定, 設定例, これがなぜsecurity = serverよりもすぐれているのか?, Sambaドメインメンバー間でのユーザーIDマッピング共有, ユーザーとグループの変更, Samba-3.0.23でのグループマッピングの変更, 技術情報, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング, LDAPディレクトリとWindowsのコンピュータアカウント, グループのマッピング: Microsoft Windows と UNIX, 機能と利便性, セキュリティ識別子(SID)の管理, 識別情報のマッピング(IDMAP), ドメインメンバーサーバーかドメインメンバークライアント, プライマリドメインコントローラー, IDMAP_RIDを使うWinbind, 権利の管理能力, 管理者のドメインSID, 機能と利便性, 外部のSIDの取り扱い, 補足事項, SID の取得, 複数のサーバーのホスティング, Samba-3.0.xにおける新しい機能, プロファイルの移行/作成
SID-to-GID, 機能と利便性
SIDs, Samba-3実装の選択
SID管理, 概要
signing, ドメイン参加後ドメインメンバーワークステーションにログオンできない
Simple Object Access Protocol (see SOAP)
Simplicity is king, サーバーの共有とディレクトリのレイアウト
slapadd, LDAPデータベースの初期化
slapd, OpenLDAPの設定
slapd.conf, Samba-3.0.23におけるLDAPの変更, OpenLDAPの設定, セキュリティとsambaSamAccount
slapd.pem, LDAP設定の注意
slapindex, Samba-3.0.23におけるLDAPの変更
slappasswd, LDAPデータベースの初期化
smart printers, Overview
SMB, サーバーセキュリティ(ユーザーレベルのセキュリティ), Windows 2003 PDC に参加できない, 背景, 機能と利便性, NetBIOS over TCP/IP, ブラウジングの技術的な概要, インタフェース保護の使用, Samba-2.2からの印刷環境, Microsoft Windowsネットワーク内でのような名前解決, BackupPC, 最先端の状況, サーバープールの通信, Sambaの問題の調査と解決方法
SMB locks, サーバープールの通信
SMB password, smbpasswdツール
SMB Password, その機能と利点
SMB semantics, 分散ファイルシステムの試み
SMB Server, その機能と利点
SMB ネットワーキング, 診断ツール
smb-cdserver.conf, 複数仮想サーバーの性質(Personalities)
smb.conf, 複数仮想サーバーの性質(Personalities)
SMB/CIFS, ネットワーク上のドメインコントローラーになれる要件, Windows 2003 PDC に参加できない, セキュリティに関する重要な注意事項, 文字セットとユニコードとは何か
SMB/CIFSサーバー, パスワードバックエンド
smbclient, smbclientによるテスト, [print$]へのドライバーファイルインストール, smbclientによるドライバーインストールの確認, BackupPC, テスト, Sambaそれ自身によるデバッグ
smbd, Sambaを起動する, 設定の例, testparmによる設定ファイルの検査, セキュアな読み書き可能ファイルと印刷サーバー, 設定例, smbpasswd: 暗号化したパスワードデータベース, RFC 2307 posixAccountとの関係とスキーマ, Sambaの設定, ドメインメンバーサーバーかドメインメンバークライアント, NT4形式のドメイン(Sambaドメインを含む), 権限の説明, testparmによる設定の検査, 手っ取り早い設定の検証, extd_audit, 機能と利便性, テスト, SambaサーバーをPDCドメインに参加させる, Linux, Solaris, サーバープールの通信, 大きなディレクトリの取扱い, 複数のサーバーのホスティング, 複数仮想サーバーの性質(Personalities), Sambaそれ自身によるデバッグ
smbgroupedit, リモートとローカル管理:Netコマンド
smbgrpadd.sh, smb.confにグループを追加するスクリプト例
smbHome, sambaSamAccountsのための特別なLDAP属性
smbldap-groupadd, 新しいグループの追加又は作成
smbldap-tools, ldapsam
smbpasswd, 設定例, ドメイン制御: 設定例, バックアップドメインコントローラーの設定, smbpasswdファイルの複製はどうやるか?, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, smb.confの設定, Sambaドメインメンバー間でのユーザーIDマッピング共有, Samba-3.0.23でのグループマッピングの変更, アカウント情報データベース, 下位互換性のあるバックエンド, アカウント管理ツール, smbpasswdツール, pdbeditツール, ユーザーアカウントマネージャ, アカウントのインポート/エクスポート, smbpasswd: 暗号化したパスワードデータベース, ldapsam, RFC 2307 posixAccountとの関係とスキーマ, LDAPデータベースの初期化, ドメインメンバーサーバーかドメインメンバークライアント, 信頼されるドメインとしてのSamba, Samba PDC, passdbバックエンドと認証, 新しいスキーマ
smbpasswd平文データベース, smbpasswd: 暗号化したパスワードデータベース
smbpasswd形式, ユーザーとマシンアカウントの表示
SMBsessetupX, Windows 9x/Meにおける特別な例
smbspool, Windowsに接続された印刷へのCUPSからの印刷
smbstatus, 間違ったユーザーでSambaサーバーに接続されるのを防ぐ, 稼働中のプロセスへのアタッチ
SMBtconX, Windows 9x/Meにおける特別な例
smbusers, ユーザーベースの保護
SMBサーバー, 暗号化されたパスワードの長所
SMBサービス, 分散ファイルシステム上の限定的な制約
SMBステート情報, SMBリクエストの分割
SMBパスワードの暗号化, セキュリティに関する重要な注意事項
SMBプリンター, Administratorはすべてのローカルユーザーに対してプリンターをインストールできない
SMBベースのメッセージング, 議論
smbポート, 複数仮想サーバーの性質(Personalities)
SMBリクエスト, SMBリクエストの分割
SMB名, Microsoft Windowsネットワーク内でのような名前解決
SMB暗号化, 暗号化されたパスワードの長所
SMB署名, Windows 2003 PDC に参加できない, Samba-3.0.xにおける新しい機能
SMS, Windowsのネットワークモニター
sniffer, Windows 9x/Meにおける特別な例, 診断ツール
socket address, 複数のサーバーのホスティング
SOFTQ 印刷システム, [global]セクション
Solaris, 分散マシン上の共通のUID/GIDマッピング, WinbindとPAMの設定, ThinLincを使うリモート管理, その機能と利点, 基本的なパラメーターの設定
Solaris 9, Solaris
source code, 設定の例
specific restrictions, 共有のアクセス制御
spinning process, 稼働中のプロセスへのアタッチ
spool, testparmによる設定の検査
directory, 設定ファイルの文法
spooler., 設定ファイルの文法
SPOOLSS, Samba-2.2からの印刷環境
SQL, Passdbの変更
SQUID, シングルサインオンとドメインセキュリティ
SRV records, /etc/krb5.confの設定
SRV RR, 背景情報
SRV レコード, DNSとActive Directory
SrvMgr.exe, NT4サーバーマネージャによるドメインマシンアカウントの管理
srvmgr.exe, NT4サーバーマネージャによるドメインマシンアカウントの管理
SRVTOOLS.EXE, NT4サーバーマネージャによるドメインマシンアカウントの管理, リモートサーバー管理
SRVレコード, /etc/krb5.confの設定
ssh, バックアップドメインコントローラーの設定, smbpasswdファイルの複製はどうやるか?, smbpasswd: 暗号化したパスワードデータベース, BackupPC
SSH, smbclientによるドライバーインストールの確認, ThinLincを使うリモート管理
SSL, SSLを使うSWATのセキュア化
SSO, シングルサインオンとドメインセキュリティ, 機能と利便性, LDAPに関するコメント
stability, 目的
stale network links, 不正なキャッシュされた共有参照はネットワークブラウジングに影響する
standalone server, Samba-3でNT4形式でのドメインに参加する
standard confirmation, NT4ドメイン信頼関係の作成
stapling, pstops
StartDocPrinter, Samba-2.2からの印刷環境
starting samba
nmbd, セキュアな読み書き可能ファイルと印刷サーバー, 設定例
smbd, セキュアな読み書き可能ファイルと印刷サーバー, 設定例
winbindd, 設定例
startsmb, もう一つの方法: smbdをデーモンとして起動する
StartTLS, セキュリティとsambaSamAccount
state, これがなぜ難しいか?
state information, これがなぜ難しいか?
state of knowledge, 機能と利便性
status32コード, Samba-3.0.xにおける新しい機能
storage mechanism, アカウント管理ツール
storage methods, smbpasswdツール
stphoto2.ppd, フィルタリングチェインの例
strptime, ユーザーアカウントの変更
stunnel, SSLを使うSWATのセキュア化
su, /etc/pam.d にあるエントリーの構造
subscription, 無償サポート
subsuffixパラメーター, 検索のための新しいサフィックス
Subversion, 概要, Subversion経由でのアクセス
sufficient, /etc/pam.d にあるエントリーの構造
suffixes, MIMEタイプとCUPSフィルタ
SUID, ファイルとディレクトリのアクセス制御
Sun, ドメインメンバーサーバー
Sun ONE iDentity server, その機能と利点
SUN-Raster, MIMEタイプとCUPSフィルタ
support exposure, 目的
SVN
web, ViewCVS経由のアクセス
SVRTOOLS.EXE, 機能と利便性
SWAT, Sambaの設定 (smb.conf), SWAT: Samba Web 管理ツール
swat, SWAT, SWATインストールの有効か, SWATファイルの配置, SWATを使用できるように有効化する
security, SSLを使うSWATのセキュア化
有効化, SWATを使用できるように有効化する
SWAT permission allowed, SWATを使用できるように有効化する
swatコマンドラインオプション, SWATファイルの配置
SWATバイナリサポート, SWATインストールの有効か
system access controls, 新しいアカウント格納システム
SYSV, [global]セクション
SYSVOL, Microsoft Windows 200x/XP Professionalのポリシー

T

tail, 前提条件
take ownership, 権限の説明
tar, BackupPC
tarball, 設定の例
TCP, 複数のインタフェース, これがなぜ難しいか?
TCP failover, これがなぜ難しいか?
TCP port 139, 背景情報
TCP port 445, 背景情報
TCP/IP, Microsoft Windows XP Professional, Microsoft Windows Me, 機能と利便性, Windowsのネットワークプロトコル
TCP/IPのみ, Windowsのネットワークプロトコル
TCP/IPプロトコルの設定, Microsoft Windows XP Professional, Microsoft Windows 2000
TCP/IPプロトコルスタック, WINS: The Windows Internetworking Name Server
TCP/IPプロトコル設定, 技術的な詳細
TCP/IP設定, Microsoft Windows XP Professional, Microsoft Windows Me
TCP/IP設定パネル, Microsoft Windows 2000
tcpdump, Tcpdump
TCPデータストリーム, 最先端の状況
TCPポート, 機能と利便性
tcpポート, SambaサーバーをPDCドメインに参加させる
TCPポート 139, 複数仮想サーバーの性質(Personalities)
TCPポート 445, 複数仮想サーバーの性質(Personalities)
TDB, 新しいアカウント格納システム, setdriverを付けたrpcclientの実行, 印刷関連の*.tdbファイル, Trivial Database Files, 複数のサーバーのホスティング
backing up (see tdbbackup)
tdb, ユーザーとグループIDの割り当て, サーバープールの通信, 特徴と利点
tdb data files, TDBデータファイル
tdbbackup, tdbbackupの使用, 壊れたtdbファイル
tdbdump, 共有のアクセス制御
tdbsam, ドメイン制御: 設定例, Samba-3.0.23でのグループマッピングの変更, アカウント情報データベース, 技術情報, ユーザーとマシンアカウントの表示, smbpasswd: 暗号化したパスワードデータベース, tdbsam, 既定値のユーザー、グループと相対識別子, ドメインメンバーサーバーかドメインメンバークライアント, 目的
tdbsam データベース, パスワードバックエンド
TDBデータベース, adddriverを付けたprinter driver filesの実行
TDBデータベースファイル, 新しいプリンターに対するデバイスモードの設定
tdbファイル, 共有のアクセス制御
tdbファイルのバックアップ, TDBデータファイル
tdbファイルの位置, TDBデータベースファイルの情報
tdbファイルの説明, TDBデータベースファイルの情報, TDBデータファイル
Telnet, 暗号化されていないパスワードの長所
telnetでのログイン, Linux/FreeBSD固有のPAM設定
temporary location, 印刷コマンド
testparm, testparmによる設定ファイルの検査, 集中印刷サーバー, 簡単な印刷設定, testparmによる設定の検査, 手っ取り早い設定の検証, 拡張印刷設定, 前提条件, テスト, Sambaそれ自身によるデバッグ
tethereal, Tcpdump
text/plain, MIMEタイプ変換ルール
texttops, MIMEタイプ変換ルール
ThinLinc, ThinLincを使うリモート管理
tid, SMBリクエストの分割
TIFF, MIMEタイプとCUPSフィルタ
TightVNC, NoMachine.Comによるリモート管理, ThinLincを使うリモート管理
tools\reskit\netadmin\poledit, Windows 9x/ME ポリシー
transitive, 信頼関係に関する背景情報
transparent access, 機能と利便性
Transport Layer Seccurity, TLS
設定, 設定
Transport Layer Security, TLS
トラブルシューティング, トラブルシューティング
評価, 評価
trigger, Microsoft Windows NT4スタイルのドメイン制御
trivial database, 新しいアカウント格納システム (see TDB)
Trivial Database, 特徴と利点
Tru64 UNIX, 基本的なパラメーターの設定
trust, 機能と利便性
account, ドメインセキュリティモード(ユーザーレベルのセキュリティ)
trust account password, 機能と利便性
trust relationships, ドメイン間の信頼関係
trusted, サブネット間ブラウジングの動作, User Rights and Privileges
trusted domain, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加
trusted party, 信頼されるドメインとしてのSamba
trusting party, 信頼されるドメインとしてのSamba
trusts, ドメイン間の信頼関係
TTL, 静的なWINSエントリ
turn oplocks off, 高度なSamba Oplocksパラメーター
turnkey solution, LDAPディレクトリとWindowsのコンピュータアカウント

U

UCS-2, 日本語の文字セット
UDP, ドメイン制御の準備, NetBIOS over TCP/IP, どのようにブラウジングは機能するか, 強制的にSambaをマスターにする, 複数のインタフェース, サブネット間のブラウジング
UDP port 137, 背景情報
udpポート, SambaサーバーをPDCドメインに参加させる
UDPユニキャスト, どのようにブラウジングは機能するか
UID, 設定例, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, マシン信頼アカウントの手動作成, これがなぜsecurity = serverよりもすぐれているのか?, Sambaドメインメンバー間でのユーザーIDマッピング共有, 技術情報, Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング, 分散マシン上の共通のUID/GIDマッピング, LDAPディレクトリとWindowsのコンピュータアカウント, ユーザーとマシンアカウントの表示, 機能と利便性, 概要, WindowsグループからUNIXグループへのマッピング, UNIXとWindowsのユーザー管理, 識別情報のマッピング(IDMAP), ドメインメンバーサーバーかドメインメンバークライアント, プライマリドメインコントローラー, User Rights and Privileges, 機能と利便性, 外部のSIDの取り扱い, winbindddaemonの開始とテスト
uid, OpenLDAPの設定
UID numbers, ドメインメンバーサーバーかドメインメンバークライアント
UIDレンジ, ドメイン間の信頼関係
unauthorized, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
UNC notation, ドライバーファイルの識別
unexpected.tdb, 印刷関連の*.tdbファイル
(see also TDB)
Unicode UTF-8, 基本的なパラメーターの設定
UNIX, 基本的なパラメーターの設定
server, 機能と利便性
unix charset, 基本的なパラメーターの設定
UNIX ID, ユーザーとグループIDの割り当て
UNIX login ID, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
UNIX システムアカウント, マシンのドメインへの追加に失敗する
UNIX システムファイル, 特徴と利点
UNIX ドメインソケット, ファイルとディレクトリのアクセス制御
UNIX/Linux group, 警告:ユーザー固有のグループ問題
UNIX/Linuxのユーザーアカウント, UNIXとWindowsのユーザー管理
UNIXでの印刷, 技術的な序論
UNIXのパーミッション, Samba-3実装の選択
UNIXのファイルシステムアクセス制御, 機能と利便性
UNIXのプリンター, [global]セクション
UNIXのホームディレクトリ, なぜユーザーが他のユーザーのホームディレクトリをアクセスできるのか?
UNIXのロッキング, 議論
UNIXアカウント, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, マシン信頼アカウントの手動作成, マシン信頼アカウントの即時作成
UNIXグループ, グループのマッピング: Microsoft Windows と UNIX, WindowsグループからUNIXグループへのマッピング, Winbindが提供するもの
UNIXシステムアカウント, マシンのドメインへの追加に失敗する, User Rights and Privileges
UNIXドメインソケット, Winbindの動き方
UNIXホストシステム, User Rights and Privileges
UNIXユーザー, これがなぜsecurity = serverよりもすぐれているのか?, Winbindが提供するもの
UNIXユーザーとグループのマップ, Sambaドメインメンバー間でのユーザーIDマッピング共有
UNIXユーザーデータベース, 背景
UNIXユーザー識別子 (see UID)
UNIX風の暗号化パスワード, 技術情報
unlink calls, recycle
unlinked, ファイルとディレクトリのアクセス制御
unprivileged account names, 参照用文書サーバー
unsupported encryption, よくあるエラー
unsupported software, 商用サポート
updates, Sambaのアップグレード
upper-case, ユーザーレベルのセキュリティ
USB, フィルタリングチェインの例
user, ファイルとディレクトリのアクセス制御
user encoded, セキュリティ識別子(SID)の管理
user groups, 無償サポート
User Rights and Privileges, 管理者のドメインSID
user-mode security, セキュリティモードとマスターブラウザー
user.DAT, Windows 9x/Me のプロファイル設定, Windows 9x/Me と NT4/200x/XP ワークステーション間でプロファイルを共有する
user.MAN, Windows 9x/Me のプロファイル設定
User.MAN, 必須プロファイル
useradd, マシン信頼アカウントの手動作成, マシン信頼アカウントの即時作成
username map, ユーザーのマッピング
userPassword, LDAPデータベースの初期化
users, 機能と利便性
UsrMgr.exe, NT4サーバーマネージャによるドメインマシンアカウントの管理
UTF-8, Sambaと文字セット, 基本的なパラメーターの設定
UTF-8 エンコーディング, SWAT国際化サポートの有効化

W

W32X86, ドライバーファイルの識別, カーネルモードでもPostScriptドライバーは大きな問題はない, 考慮すべき警告
W32X86/2, Windows形式のベンダPPDの使用
WAN, 強制的にSambaをマスターにする, 遅くて信頼できないネットワーク
wbinfo, winbindddaemonの開始とテスト
WebClient, 共有とディレクトリのブラウジングが非常に遅い
Webベースの設定, SWAT: Samba Web 管理ツール
Win32 印刷API, Samba-2.2からの印刷環境
WIN40, ドライバーファイルの識別, Windowsクライアントの[print$]共有からのドライバーファイルの取得, 考慮すべき警告
winbind, これがなぜsecurity = serverよりもすぐれているのか?, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, ドメインメンバーサーバーかドメインメンバークライアント, IDMAPバックエンドの使用例, NT4形式のドメイン(Sambaドメインを含む), ドメイン間の信頼関係, 機能と利便性, smb.confの設定
Winbind, 背景, 対象となるユーザー, Microsoft Active Directoryサービス, Pluggable Authentication Modules, ユーザーとグループIDの割り当て, 結果のキャッシュ保存, はじめに, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する, AIXにおけるNSS Winbind, winbindddaemonの開始とテスト, Linux/FreeBSD固有のPAM設定, 結論, PAM ベースの分散型認証, その機能と利点
Winbind hooks, Winbindが提供するもの
winbind.so, Solaris固有の設定
winbindd, Sambaを起動する, testparmによる設定ファイルの検査, 設定例, 設定例, Samba-3.0.23でのグループマッピングの変更, LDAPディレクトリとWindowsのコンピュータアカウント, 機能と利便性, ネストされたグループ: WindowsドメイングループをWindowsローカルグループに追加, UNIXとWindowsのユーザー管理, 識別情報のマッピング(IDMAP), ドメインメンバーサーバーかドメインメンバークライアント, ドメイン間の信頼関係, 機能と利便性, Winbindの動き方, 用件, テスト, nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する, smb.confの設定, winbindddaemonの開始とテスト, Solaris, WinbindとPAMの設定, 複数のサーバーのホスティング
winbindd daemon, Linux
winbinddデーモンの二重化, Samba-3.0.xにおける新しい機能
Winbindアーキテクチャ, Samba-3.0.xにおける新しい機能
Winbindサービス, winbindddaemonの開始とテスト
Winbindベースの認証, PAM ベースの分散型認証
Windows, 識別情報のマッピング(IDMAP), 基本的なパラメーターの設定
Windows 2000, /etc/krb5.confの設定, サーバー設定のテスト, ネットワークブラウジング, 信頼関係に関する背景情報
Windows 2000 Professional TCP/IP, Microsoft Windows 2000
Windows 2000サーバー, Windows 2000との間での、NT4形式のドメイン信頼関係
Windows 2003, /etc/krb5.confの設定, Windows 2003 PDC に参加できない
Windows 200x/XP, NetBIOS over TCP/IP, 機能と利便性
Windows 9x/Me, ドメインログオンの設定: Windows 9x/Me, WINSサーバーの設定, Windowsのネットワークプロトコル, リモートサーバー管理
Windows 9x/Me/XP Home, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
Windows group, グループのマッピング: Microsoft Windows と UNIX, 警告:ユーザー固有のグループ問題
Windows Internet Name Server (see WINS)
Windows Me TCP/IP, Microsoft Windows Me
Windows Millennium, Microsoft Windows Me
Windows Millennium edition (Me) TCP/IP, Microsoft Windows Me
Windows NT PostScriptドライバー, Windowsに接続された印刷へのCUPSからの印刷
Windows NT/2000/XP, Sambaがドライバーを認識したかの確認
Windows NT/200x, WINSサーバーの設定, はじめに
Windows NT/200x/XP, [global]セクション
Windows NT/200x/XP Professional, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント, ドメインへの参加: Windows 2000/XP Professional, よくあるエラー
Windows NT3.10, 基本的な背景情報について
Windows NT4, Windows NT4 Workstation/Server, 機能と利便性
Windows NT4/200X, LDAPディレクトリとWindowsのコンピュータアカウント
Windows NT4/200x, 議論
Windows NT4/200x/XP, NetBIOS Over TCP/IPが有効, 既定値のユーザー、グループと相対識別子, Windows 200x/XP
Windows NT4/2kX/XPPro, User Rights and Privileges
Windows NT4サーバー, SambaにおけるNT形式のドメイン信頼関係の設定
Windows NT4ドメイン, ドメイン間信頼関係の機能
Windows NTサーバー, 信頼されるドメインとしてのSamba
Windows NTドメイン名, ドメインログオンの設定: Windows 9x/Me
Windows PPD, 690の“完璧な”プリンター
Windows Security Identifiers (see SID)
Windows XP Home, セキュリティに関する重要な注意事項
Windows XP Home edition, Windows XP Home Editionにおける特別な例, ドメインログオンの設定: Windows 9x/Me
Windows XP Home Edition, MS Windows 200x/XP
Windows XP Home エディション, 機能と利便性
Windows XP Professional, Microsoft Windows XP Professional, 機能と利便性
Windows XP Professional TCP/IP, Microsoft Windows 2000
Windows XP TCP/IP, Microsoft Windows XP Professional
windows のレジストリ設定
デフォルトプロファイルの場所, MS Windows NT4 Workstation, MS Windows 200x/XP
Windows リソースキット, 移動プロファイルサポートを無効にする
windows レジストリの設定, Windows 9x/Me のプロファイル設定
プロファイルのパス, Windows 9x/Me のプロファイル設定
移動プロファイル, 移動プロファイルサポートを無効にする
Windows ログオン, Windows 9x/Me のプロファイル設定
Windows95/98/ME, Sambaがドライバーを認識したかの確認
Windowsのグループ, User Rights and Privileges
Windowsのグループアカウント, 管理者のドメインSID
Windowsのユーザー, User Rights and Privileges
Windowsのユーザーアカウント, UNIXとWindowsのユーザー管理
Windowsの権限モデル, 権利の管理能力
Windowsアカウント管理, Winbindが提供するもの
Windowsエクスプローラー, 問題の解決方法, ドライバーファイルの識別
Windowsクライアント, Windowsクライアントの管理が出来る権利と権限は何か?
Windowsクライアントのフェイルオーバー, Opportunistic Lockingの概要
Windowsグループ, WindowsグループからUNIXグループへのマッピング
Windowsターミナルサーバー, NoMachine.Comによるリモート管理, ThinLincを使うリモート管理
Windowsドメイン, 動作の変更点
Windowsネットワーククライアント, 機能と利便性
Windowsレジストリ, MicrosoftWindowsワークステーション/サーバーのマシン信頼アカウント
Windowsワークステーション, Windowsクライアントの管理が出来る権利と権限は何か?
winnt.adm, Windows NT4形式のポリシーファイル
WINS, 機能と利便性, ドメインコントローラーの種類, ドメイン制御の準備, ネットワーク上のドメインコントローラーになれる要件, Samba-3でNT4形式でのドメインに参加する, 参照用文書サーバー, Microsoft Windows XP Professional, Microsoft Windows 2000, Microsoft Windows Me, ネットワークブラウジング, 機能と利便性, ブラウジングとは何か?, NetBIOS over TCP/IP, どのようにブラウジングは機能するか, ドメインブラウジングの設定, Sambaをドメインマスターにする, WINS: The Windows Internetworking Name Server, WINSサーバーの設定, ブラウジングの技術的な概要, Sambaでのブラウジングサポート, サブネット間のブラウジング, サブネット間ブラウジングの動作, WINSによる検索, 設定例
wins, /etc/nsswitch.conf
WINS Server, ブラウジングとは何か?
WINS server settings, Microsoft Windows Me
WINS Support, ブラウジングとは何か?
wins.dat, 静的なWINSエントリ
WINSの設定, 共有とディレクトリのブラウジングが非常に遅い
WINSサーバー, どのようにブラウジングは機能するか, ワークグループのブラウジングの設定, WINS: The Windows Internetworking Name Server, WINSサーバーの設定, Sambaでのブラウジングサポート, 共有とディレクトリのブラウジングが非常に遅い
WINSサーバーr, Sambaをドメインマスターにする
WINSサーバーアドレス, どのようにブラウジングは機能するか
WINSサービス, WINSサーバーの設定
WINS検索, Samba-3でNT4形式でのドメインに参加する
WINS複製, WINS複製, 静的なWINSエントリ
workgroup, 複数のサーバーのホスティング, 複数仮想サーバーの性質(Personalities)
write, ファイルとディレクトリのアクセス制御
Write caching, Opportunistic Lockingの概要
write changes, バックアップドメインコントローラー
writeable, fake_perms
WYSIWYG, Windowsドライバー、GDIとEMF