目次
net
コマンドは Samba における新しい機能の1つで、共通作業のために、
リモート管理操作用における主要な操作用に便利なツールを提供する試みである。net
は自由度が高いデザインで、スクリプト制御アプリケーションのためと同様にコマンド行操作
でも使うように出来ている。
当初は同じ名前のMicrosoft Windows コマンドの模倣を狙って作られたが、net
は、Sambaネットワーク管理者の道具箱の基本的な部分になる、非常に強力なツールに変貌した。
Samba Teamは、smbgroupedit
とrpcclient
のような
ツールも提供していて、それらは本当に役に立つ能力がnet
コマンドに集約
された。smbgroupedit
コマンドは、いくつかの機能のみが
rpcclient
に集約された間、net
コマンドに完全に移植された。
それらのユーティリティや機能に対する古いリファレンスを見つけた場合、それ以外を探す前に、
net
コマンドを見るべきである。
Samba 管理者は、そうすることが、自ら招いた痛み、苦しみと自暴自棄を科すことをほとんど 確実に引き起こすので、この章を取り繕うことができない。
Samba サーバーのインストールに伴う作業は、スタンドアロンかドメインメンバーの どちらも、さらにドメインコントローラー( PDC または BDC )は管理者権限の作成を必要と するところから始まる。もちろん、ユーザーとグループアカウントの作成は、スタンド アロンサーバーと PDC 両者において必須である。BDC またはドメインメンバーサーバー(DMS) においては、ドメインユーザーとグループアカウントは中央のドメイン認証バック エンドから得られる。
インストールされているサーバーのタイプに関係なく、ローカルUNIXグループはWindowsの
ネットワークにおけるドメイングローバルグループアカウントにマップされねばならない。
なぜだろうか?それは、Sambaは常時、伝統的なUNIXのUIDとGID制御によってホスト
サーバーのリソースのアクセスを制限するからである。これは、ドメイングローバル
グループのメンバーであるドメインユーザーは、Sambaがホスティングしているサーバーの
ローカルなUIDとGIDをベースとしたアクセス権が与えられるようにするために、
ローカルグループはドメイングローバルグループにマップされなければならない。
このようなマッピングはnet
コマンドを使うことで実装される。
メンバー(PDC 、BDC あるいは DMS )として動作しているSamba サーバーがホスティングしている
UNIX システムは、ドメイン認証データベース(かあるいはディレクトリ)中にマシン信頼
アカウントを持たねばならない。そのようなセキュリティ(あるいは信頼)アカウントの
作成も、net
コマンドを使うことよって扱える。
net
コマンドを使うことで、ドメイン間信頼関係をも確立でき、
また、ユーザー管理、グループ管理、共有とプリンター管理、ファイルとプリンターの
マイグレーション、SIDの管理などのような、有り余るほどの典型的な管理作業も
できる。
全体の構成は今明確にすべきである:net
はSamba の動作において
重要な役割を演じる。その役割は継続して開発されている。この章に含まれているもの
は、その重要性の証拠であり、それは、完全にオンライン UNIX マニュアル中でその
使用をカバーすることが賢明であるとは、もはや考えられない点において、複雑に成長
してきた。
net
の基本的な動作はここに文書化されている。この文書は完璧
ではなく、不完全である。WindowsサーバーからSambaサーバーへの移行について最も着目
しているので、分散コンピューティング環境のリモートプロシジャーコール(DCE RPC)
モードの操作について強調している。Active Directoryドメインのメンバーであるサーバーに
対して使用されるとき、ADSモード操作を使うことは望ましい(そして、それはしばしば
必要である)。net
は両方ともサポートするが、すべての操作に
対してではない。モードが指定されない多くの操作では、net
は
自動的にads
, rpc
と
rap
モードにフォールバックする。このユーティリティの
能力についてのより包括的な概要はマニュアルページを参照のこと。
初めに、この章の主要な注目点は、Sambaによってサポートされている
net rpc
ファミリの動作の使用方法である。それらの大半は、
Active Directoryに接続したときに使われるnet ads
モードでも
サポートされる。net rap
動作モードもそれらの操作のいくつかで
サポートされる。RAPプロトコルはIBM OS/2といくつかの初期のSMBサーバーによって
使われる。
Sambaのnet
ツールはコマンドラインで完結するための、すべての
共通な管理作業が出来る十分な能力を実装している。このセクションでは、必須の
ユーザーとグループ管理機能のそれぞれについて説明している。
Samba は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グループは、SambaサーバーをホスティングしているOSに適した方法での首尾一貫 した方法で主張できるファイルシステムのアクセス制御が出来るように、UNIXシステム (POSIX)グループにマップされる必要がある。
SambaサーバーをホスティングしているUNIX/Linuxサーバーのファイルシステムで、すべての
ファイルシステム(ファイルとディレクトリ)アクセス制御はUID/GID識別の組を使って
実装される。SambaはUNIXファイルシステムの仕組みに優先したり、置き換えることは
しない。これは、ファイルシステムにアクセスするすべてのWindowsネットワーク操作は、
Windowsユーザーから特定のUNIX/Linuxグループアカウントにマップするメカニズムを
提供する。ユーザーアカウントはローカルに知られているUIDにもマップする必要がある。
net
コマンドはここでは任意のRPC機能は呼び出さないが、passdbに
直接アクセスすることに注意。
SambaはDomain Admins, Domain Users
と
Domain Guests
グローバルグループの既定値のマッピングに
依存する。追加のグループはサンプルで与えられた中でのように追加できる。存在する
UNIXグループアカウントをWindowsグループにマップすることが必要なときがある。
この操作は実際Windowsグループアカウントをマップ生成の結果として作成する。
add
、modify
とdelete
を含む操作が許可される。それぞれの操作の例はここで示される。
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=Engineersroot#
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
削除の検証は有効である。同じコマンドは以下で示されるように実行できる。
このコマンドはマニュアルページには記述がない。ソースコード上では実装されているが、 現時点では動作しない。ソースコード上から得られた文書例は、どのようにそれが 動くかを示す。これがいつ修正されるかを、今後のリリースにおけるリリースノート で確認すること(訳注:3.4.0でもマニュアルに記載はない)。
時々グループアカウントの改名が必要なときがある。良い管理者は、この単純な要求が 無視されるならば、何人かのマネージャの要求がどのくらい痛ましくなるかを知っている。 以下のコマンドは、どのようにWindowsグループ「SupportEngrs」が 「CustomerSupport」に改名できるかを示す:
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%not24getroot#
getent group Engineers Engineers:x:1000:jhtroot#
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%not24getroot#
getent group Engineers Engineers:x:1000:jht,ajtroot#
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
単純に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
コマンドの
addmem
とdelmem
サブコマンドを使う
ことで行える。たとえば、ローカルグループ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
Windowsネットワーク管理者はしばしばSambaメーリングリストに、個々のワーク ステーション上ですべての人に管理者権限を許可することが可能かと言うことを 質問してくる。これは、もちろんとても悪い習慣ではあるが、一般的にユーザーの不満を 防ぐために行われる。個々では、どのようにSamba PDCまたはBDCからリモートでそれが 出来るかを示す:
root#
net rpc group addmem "Administrators" "Domain Users" \
-S WINPC032 -Uadministrator%secret
これはスクリプト化出来、そのためにWindowsワークステーションからドメインに ログオンするユーザーとして実行できる。どのようにそれが行われるかの簡単な例を 以下に示す。
手順13.1 ワークステーションの Power Usersグループへの自動的なユーザーの追加
例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
「ワークステーションのPower UsersグループにDomain Users を自動で追加するスクリプト」で示されているスクリプトを
作成し、autopoweruser.sh
という名前で
ディレクトリ/etc/samba/scripts
中に配置する。
ログオンプロセスの一部として実行できるようにスクリプトにパーを設定する:
root#
chown root:root /etc/samba/autopoweruser.shroot#
chmod 755 /etc/samba/autopoweruser.sh
Netlogonのsmb.confファイルでの例
で示されるようなNETLOGON
セクションが含むパラメーター
のようにsmb.conf
ファイルを変更する。
すべてのWindowsワークステーション管理者アカウントが、 Netlogonのsmb.confファイルでの例 にあるようなスクリプト中で使われるのと同じパスワードを持つようにする。
このスクリプトはユーザーがネットワークにログオンする時には毎回実行される。 そのため、すべてのユーザーはローカル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
root#
net rpc user add jacko -S FRODO -Uroot%not24get
Added user jacko
アカウントのパスワードは以下の方法で追加できる(すべて同じ操作を示す):
root#
net rpc password jacko f4sth0rse -S FRODO -Uroot%not24getroot#
net rpc user password jacko f4sth0rse \ -S FRODO -Uroot%not24get
ユーザーアカウントの削除方法は以下の通り:
net [<method>] user DELETE <name> [misc. options] [targets]
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
コマンドの使用例は
この章の適切な箇所にある。
ユーザー権限と権利が正しく設定した場合、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 サーバーはドメインから、以下のコマンドで離脱できる:
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
すべての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 command、
delete 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
現時点で、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つの制限が知られている:
net
コマンドは移行元と移行先両方でユーザー資格証明が
存在することを必要とする。
プリンターの設定は完全に移行できないか不正になるかもしれない。これは、 Windows 2003 サーバーをSambaに移行する際に特に発生するかもしれない。
net rpc share migrate
コマンド操作は簡単な共有セクションの移行
ができる。セクションはファイル又はプリンター共有が定義されているパラメーターを含む。
この移行方法はパラメーターとして、ファイルシステムディレクトリパス、オプション記述
と、ファイルへの書き込み許可を行う単純なセキュリティ設定を持つ共有セクションを
作成する。以下の移行で必要な最初のステップの1つは、共有セクションの設定が利用に
適しているかを確認することである。
共有は移行プロセスの一部として動的に作成される。smbd
は、
smb.conf
パラメーターのadd share command
によって
指定されるスクリプトを実行するためにOSを呼び出すことでこのことを行う。
$SAMBA_SOURCES/examples/scripts
ディレクトリ中に
add share command
のための適切な例がある。移行を
行うときに使うアカウントは、必要に応じて、適切なファイルシステムへのアクセス
権とそれらに対するACL設定および共有の作成権限を持たねばならないことに注意。
そのような権限は、SeAddUsersPrivilege
と
SeDiskOperatorPrivilege
という権限である。
権限と権利についてのより詳細な情報は、「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
スイッチを指定することで保存できる。
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
Sambaが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
winbindd
によって、IDMAP UIDからSIDとSIDからUIDへのマッピング
は、テキストファイルにバックアップできる。テキストファイルは、手動で編集
できるが、自分自身が正確に何をやっているのかを知っている時にのみ、それを行う
ことを強く推奨する。
IDMAP テキストダンプファイルはリストア(再ロード)できる。この動作が必要とされる 2つの状況は次の通り: a) 存在するIDMAPファイルが壊れたか、b)編集されたマッピング 情報をインストールする必要がある場合。
WinbindはIDMAPファイルをダンプするためには停止しなければならない。ダンプファイルを
リストアする前に、winbindd
を停止し、古い
winbindd_idmap.tdb
ファイルを削除する。
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
以下のコマンドは、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