Chapter 13. リモートとローカル管理:Netコマンド
Prev | Part III. 詳細な設定方法 | Next

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

### John H. Terpstra

Samba Team

`<jht@samba.org>`

### Volker Lendecke

Samba Team

`<Volker.Lendecke@SerNet.DE>`

### Guenther Deschner

Samba Team

`<gd@samba.org>`

May 9, 2005

`net`コマンドはSamba-3における新しい機能の1つで、共通作業のために、多くの必要なリモート管理操作用の便利なツールを提供する試みである。`net`は自由度が高いデザインで、スクリプト制御アプリケーションのためと同様にコマンド行操作でも使うように出来ている。

当初は同じ名前のMicrosoft Windows コマンドの模倣を狙って作られたが、`net`は、Sambaネットワーク管理者の道具箱の基本的な部分になる、非常に強力なツールに変貌した。Samba Teamは、`smbgroupedit`と`rpcclient`のようなツールも提供していて、それらは本当に役に立つ能力が`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`, `rpc`と `rap`モードにフォールバックする。このユーティリティの 能力についてのより包括的な概要はマニュアルページを参照のこと。

## 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%not24getPassword:Domain AdminsDomain UsersDomain GuestsPrint OperatorsBackup OperatorsReplicatorDomain ComputersEngineers

“SupportEngrs”というWindowsグループアカウントは、以下のコマンドを 実行することで追加できる:

    root#  net rpc group add "SupportEngrs" -Uroot%not24get

以下のコマンドを実行することで、新しいグループアカウント追加の結果が有効になっていることが検証できる:

    root#  net rpc group list -Uroot%not24getPassword:Domain AdminsDomain UsersDomain GuestsPrint OperatorsBackup OperatorsReplicatorDomain ComputersEngineersSupportEngrs

以下はPOSIX(UNIX/Linuxシステムアカウント)グループが、 add group script = /opt/IDEALX/sbin/smbldap-groupadd -p "%g" インタフェーススクリプトを呼び出すことによって作成されたことを表示する:

    root#  getent group...Domain Admins:x:512:rootDomain Users:x:513:jht,lct,ajt,metDomain Guests:x:514:Print Operators:x:550:Backup Operators:x:551:Replicator:x:552:Domain Computers:x:553:Engineers:x:1002:jhtSupportEngrs:x:1003:

以下は、グループアカウントを追加する`net`の使用で、Windows グループアカウントのために作られたPOSIXグループの即時的なマッピング中での結果を示す:

    root#  net groupmap listDomain Admins (S-1-5-21-72630-4128915-11681869-512) -> Domain AdminsDomain Users (S-1-5-21-72630-4128915-11681869-513) -> Domain UsersDomain Guests (S-1-5-21-72630-4128915-11681869-514) -> Domain GuestsPrint Operators (S-1-5-21-72630-4128915-11681869-550) -> Print OperatorsBackup Operators (S-1-5-21-72630-4128915-11681869-551) -> Backup OperatorsReplicator (S-1-5-21-72630-4128915-11681869-552) -> ReplicatorDomain Computers (S-1-5-21-72630-4128915-11681869-553) -> Domain ComputersEngineers (S-1-5-21-72630-4128915-11681869-3005) -> EngineersSupportEngrs (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 Users`と `Domain Guests`グローバルグループの既定値のマッピングに 依存する。追加のグループはサンプルで与えられた中でのように追加できる。存在する UNIXグループアカウントをWindowsグループにマップすることが必要なときがある。 この操作は実際Windowsグループアカウントをマップ生成の結果として作成する。

`add`、`modify`と`delete` を含む操作が許可される。それぞれの操作の例はここで示される。

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

削除の検証は有効である。同じコマンドは以下で示されるように実行できる。

#### グループアカウントの改名

### Note

このコマンドはマニュアルページには記述がない。ソースコード上では実装されているが、 現時点では動作しない。ソースコード上から得られた文書例は、どのようにそれが 動くかを示す。これがいつ修正されるかを、今後のリリースにおけるリリースノート で確認すること(訳注: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:rootDomain Users:x:513:jht,lct,ajt,met,vlendeckeDomain 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 listDomain Admins (S-1-5-21-72630-412605-116429-512) -> Domain AdminsDomain Users (S-1-5-21-72630-412605-116429-513) -> Domain UsersDomain Guests (S-1-5-21-72630-412605-116429-514) -> Domain GuestsPrint Operators (S-1-5-21-72630-412605-116429-550) -> Print OperatorsBackup Operators (S-1-5-21-72630-412605-116429-551) -> Backup OperatorsReplicator (S-1-5-21-72630-412605-116429-552) -> ReplicatorDomain Computers (S-1-5-21-72630-412605-116429-553) -> Domain ComputersEngineers (S-1-5-21-72630-412605-116429-3001) -> Engineers

与えられた`ajt`というユーザは、すでにUNIX/Linuxグループの メンバで、グループマッピング経由、Windowsグループのメンバで、このアカウントを 再度追加する試みは失敗する。これのデモは以下の通り:

    root#  net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24getCould 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 EngineersEngineers:x:1000:jhtroot#  net rpc group members Engineers -Uroot%not24getMIDEARTH\jht

この例2つの中で、UNIX/Linuxシステムレベルで、グループはもはや`ajt` をメンバとしてはいない。上記は又Windowsグループメンバシップの場合も示している。

`net rpc group`ユーティリティを使ってアカウントは再度追加される:

    root#  net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24getroot#  getent group EngineersEngineers:x:1000:jht,ajtroot#  net rpc group members Engineers -Uroot%not24getMIDEARTH\jhtMIDEARTH\ajt

この例では、Windowsの`Domain Users`アカウントのメンバは `net rpc group`ユーティリティを使って検証される。この UNIX/Linuxグループの内容は4つ前のパラグラフで示されていることに注意。 Windows(ドメイン)グループメンバシップは以下のようになる:

    root#  net rpc group members "Domain Users" -Uroot%not24getMIDEARTH\jhtMIDEARTH\lctMIDEARTH\ajtMIDEARTH\metMIDEARTH\vlendecke

この特別な例は、Windowsグループ名が、大文字小文字を区別しない流儀で (Microsoft Windowsと同じ)Sambaによって扱われることを示す:

    root#  net rpc group members "DomAiN USerS" -Uroot%not24getMIDEARTH\jhtMIDEARTH\lctMIDEARTH\ajtMIDEARTH\metMIDEARTH\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`コマンドの `addmem`と`delmem`サブコマンドを使う ことで行える。たとえば、ローカルグループ`demo`に対して “DOM\Domain Users”を追加するには以下のように行う:

    root#  net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get

以下のようにして、ネストされたグループのメンバを表示することが出来る:

    root#  net rpc group members demo -Uroot%not24getDOM\Domain UsersDOM\EngineersDOM\jamesfDOM\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 $2exit 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.shroot#  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 [] user ADD  [-c container] [-F user flags] \    [misc. options] [targets]

ユーザアカウントのパスワードは以下の方法で設定できる:

    net rpc password  [] -Uadmin_username%admin_pass

以下ではサーバ`FRODO`にアカウントを追加する例を示す:

    root#  net rpc user add jacko -S FRODO -Uroot%not24getAdded user jacko

アカウントのパスワードは以下の方法で追加できる(すべて同じ操作を示す):

    root#  net rpc password jacko f4sth0rse -S FRODO -Uroot%not24getroot#  net rpc user password jacko f4sth0rse \    -S FRODO -Uroot%not24get

### ユーザアカウントの削除

ユーザアカウントの削除方法は以下の通り:

    net [] user DELETE  [misc. options] [targets]

以下ではユーザアカウント`jacko`を削除する:

    root#  net rpc user delete jacko -Uroot%not24getDeleted user account

### ユーザアカウントの管理

2の基本的なユーザアカウント操作が定常的に使われる:パスワード変更とどのグループに ユーザが所属しているかの問い合わせである。パスワード変更操作は “ユーザアカウントの追加”の通り。

Windowsグループのメンバシップの問い合わせ能力は基本的である。以下では、リモート サーバが、どのグループにユーザが属しているかを調べることが出来るかを示す:

    root#  net rpc user info jacko -S SAURON -Uroot%not24getnet rpc user info jacko -S SAURON -Uroot%not24getDomain UsersDomain AdminsEngineersTorridGroupBOP ShopEmergency 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%not24getBUILTIN\Print OperatorsNo privileges assignedBUILTIN\Account OperatorsNo privileges assignedBUILTIN\Backup OperatorsNo privileges assignedBUILTIN\Server OperatorsNo privileges assignedBUILTIN\AdministratorsNo privileges assignedEveryoneNo 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%not24getSuccessfully granted rights.

次に、ドメインユーザ`jht`は、日々の管理の必要性のために権限を 割り当てられる:

    root#  net rpc rights grant "MIDEARTH\jht" \    SeMachineAccountPrivilege SePrintOperatorPrivilege \    SeAddUsersPrivilege SeDiskOperatorPrivilege \    -U root%not24getSuccessfully granted rights.

以下のステップでは今行った変更の確認を行う:

    root#  net rpc rights list accounts -U root%not24getMIDEARTH\jhtSeMachineAccountPrivilegeSePrintOperatorPrivilegeSeAddUsersPrivilegeSeDiskOperatorPrivilegeBUILTIN\Print OperatorsNo privileges assignedBUILTIN\Account OperatorsNo privileges assignedBUILTIN\Backup OperatorsNo privileges assignedBUILTIN\Server OperatorsNo privileges assignedBUILTIN\AdministratorsNo privileges assignedEveryoneNo privileges assignedMIDEARTH\Domain AdminsSeMachineAccountPrivilegeSePrintOperatorPrivilegeSeAddUsersPrivilegeSeRemoteShutdownPrivilegeSeDiskOperatorPrivilege

## 信頼関係の管理

基本的な信頼関係には2つのタイプがある:最初のものは、ドメインコントローラと ドメインメンバマシン(ネットワーククライアント)間のものであり、2番目のものは、 ドメイン間(ドメイン間信頼関係と呼ばれる)である。ドメインセキュリティに参加する すべてのSambaサーバは、Windows NT/200x/XPワークステーションがそうであるように、 ドメインメンバシップ信頼アカウントを必要とする。

### マシン信頼アカウント

それ自身の固有の設定を取得するために、netコマンドは`smb.conf`ファイルを見に行く。 そのため、以下のコマンドは、`smb.conf`から、どのドメインに参加するかを知っている。

Sambaサーバのドメイン信頼アカウントは以下の例のようにして確認できる:

    root#  net rpc testjoinJoin to 'MIDEARTH' is OK

ここで、ドメインメンバシップアカウントがないか、アカウントの認証が無効の場合、 以下の結果が表示される:

    net rpc testjoin -S DOLPHINJoin 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 testjoinUsing short domain name -- TAKEAWAYJoined 'LEMONADE' to realm 'TAKEAWAY.BIZ'

ADSの信頼関係が確立されていない状態か、何らかの理由で無効になっている場合、 以下のエラーメッセージが表示される:

    root#  net ads testjoin -UAdministrator%secretJoin to domain is not valid

以下は、コマンドが実行された時にSambaサーバがターゲットのドメイン中でマシン 信頼アカウントを作成する手順を示す:

    root#  net rpc join -S FRODO -Uroot%not24getJoined 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%not24getJoined domain MIDEARTH.

コマンドラインパラメータ`member`はこれをjoin固有にすること に注意。既定値では、タイプは`smb.conf`ファイルの設定から推測される。特に、PDC又は BDCとしてjoinするためには、コマンドラインパラメータを `[PDC | BDC]`とする。例をあげると、

    root#  net rpc join bdc -S FRODO -Uroot%not24getJoined domain MIDEARTH.

となる。これは、`smb.conf`ファイル中の設定からドメインへのjoinのタイプを Sambaに理解させるのに最も良い方法である。

Windows ADSにSambaサーバをjoinさせるコマンドは以下の通り:

    root#  net ads join -UAdministrator%not24getUsing short domain name -- GDANSKJoined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ'

NT4ドメインからマシンを削除するための特定のオプションはない。ドメインから削除 されるドメインメンバがWindowsマシンの場合、ドメインメンバシップアカウントは自動的 には削除されない。無効になっているドメインアカウントは、何らかのツールで削除する ことが出来る。もしも必要ならば、マシンアカウントは以下の`net` コマンドで削除できる:

    root#  net rpc user delete HERRING\$ -Uroot%not24getDeleted 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%not24getTrusted domains list:noneTrusting 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%not24getTrusted domains list:noneTrusting 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%not24getTrusted domains list:DAMNATION           S-1-5-21-1385457007-882775198-1210191635Trusting domains list:DAMNATION           domain controller is not responding

信頼アカウントが外部ドメインで作成された場合、Sambaは信頼関係を外部アカウントに 対して(接続して)確立する。プロセスの中で、リモートドメイン上でリソースに対する 1方向の信頼を確立する。このコマンドは信頼関係に参加する目的を達成する:

    root#  net rpc trustdom establish DAMNATIONPassword: xxxxxxx	== f00db4rCould not connect to server TRANSGRESSIONTrust to domain DAMNATION established

今確立した双方向の信頼関係の表示は以下のように行える:

    root#  net rpc trustdom list -Uroot%not24getTrusted domains list:DAMNATION           S-1-5-21-1385457007-882775198-1210191635Trusting 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 getlocalsidSID 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%not24getStoring 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%not24getprofdataarchiveBulge   <--- This one was addedprint$netlogonprofilesIPC$kyoceraADMIN$

コマンドラインツールを使って共有を削除することもしばしば好ましい。以下の手順では、 以前に作成した共有を削除する:

    root#  net rpc share delete Bulge -S MERLIN -Uroot%not24get

共有が削除された結果の簡単な検証は以下の通り:

    root#  net rpc share -S MERLIN -Uroot%not24getprofdataarchiveprint$netlogonprofilesIPC$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設定および共有の作成権限を持たねばならないことに注意。 そのような権限は、`SeAddUsersPrivilege`と `SeDiskOperatorPrivilege`という権限である。 権限と権利についてのより詳細な情報は、“User Rights and Privileges”を参照のこと。

共有の移行のためのコマンドの文法は以下の通り:

    net rpc share MIGRATE SHARES  -S         [--destination=localhost] [--exclude=share1,share2] [-v]

When the parameter 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  -S     [--destination=localhost] [--exclude=share1,share2]    [--acls] [--attrs] [--timestamps] [-v]

もしも、パラメータが省略された場合、すべての共有が移行される。 移行元システム上での、潜在的にある大量の共有の一覧は、 `--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  -S     [--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%not24getComputer             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   -Uadministrator%secret

もしも星印(*)がプリンタ名引数の場所で使われた場合、すべてのプリンタの一覧が返る。

ADSに対してプリンタを公開する(有効にする)には、以下のコマンドを実行する:

    net ads printer publish  -Uadministrator%secret

これはローカルSambaサーバのプリンタをADSに公開する。

ADSからSambaプリンタを削除するには、以下のコマンドを実行する:

    net ads printer remove  -Uadministrator%secret

ADSドメイン全体に渡ってプリンタの場所を調べる一般的な検索(問い合わせ)も、以下を使うことで出来る:

    net ads printer search  -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  > 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 infoDomain Name: RAPIDFLYDomain SID: S-1-5-21-399034208-633907489-3292421255Sequence number: 1116312355Num users: 720Num domain groups: 27Num local groups: 6

そのほかの便利なツールは、`net time`サブコマンド群である。この サブコマンド群は以下のように、対象のサーバ上の現在の時刻を問い合わせるのに使える:

    root#  net time -S SAURONTue May 17 00:50:43 2005

UNIXの`/bin/time`から得られる時刻情報を渡すことが目的の場合は、 渡すために準備されたフォーマットで対象のサーバから時刻を得るのはよい方法である。 これは、以下を実行することで行える:

    root#  net time system -S FRODO051700532005.16

対象のサーバ上で時刻を設定するためには以下のようにする:

    root#  net time set -S MAGGOT -U Administrator%not24getTue May 17 00:55:30 MDT 2005

以下のコマンドを実行することで、サーバのタイムゾーンを得ることが出来る:

    root#  net time zone -S SAURON-0600

Prev | Up | Next
Chapter 12. グループのマッピング: Microsoft Windows と UNIX | Home | Chapter 14. 識別情報のマッピング(IDMAP)