path: root/docs/Samba-HOWTO-Collection/TOSHARG-TheNetCommand.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">

<chapter id="NetCommand">
<chapterinfo>
	&author.jht;
	&author.gd;
	<pubdate>May 9, 2005</pubdate>
</chapterinfo>

<title>Remote and Local Management &smbmdash; The Net Command</title>

<para>
The <command>net</command> command is one of the new features of Samba-3 and is an attempt to provide a useful
tool into which the majority of remote management operations necessary for common tasks. The
<command>net</command> tool is flexible by design and is intended for command line use as well as for scripted
control application.
</para>

<para>
Originally introduced with the intent to mimick the Microsoft Windows command that has the same name, the
<command>net</command> command has morphed into a very powerful instrument that has become an essential part
of the Samba network administrator's toolbox. The Samba Team have introduced tools, such as
<command>smbgroupedit, rpcclient</command> from which really useful have been integrated into the
<command>net</command>. The <command>smbgroupedit</command> command was absorbed entirely into the
<command>net</command>, while only some features of the <command>rpcclient</command> command have been
ported to it. Anyone who finds older references to these utilities and to the functionality they provided
should look at the <command>net</command> command before searching elsewhere.
</para>

<para>
A Samba-3 administrator can not afford to gloss over this chapter because to do so will almost certainly cause
the infliction of self induced pain, agony and desperation. Be warned, this is an important chapter.
</para>

	<sect1>
	<title>Self-Defense Overview</title>

	<para>
	The tasks that follow the installation of a Samba-3 server, whether Stand-Alone, Domain Member, of a
	Domain Controller (PDC or BDC) begins with the need to create administrative rights. Of course, the
	creation of user and group accounts is essential for both a Stand-Alone server as well as for a PDC.
	In the case of a BDC or a Domain Member server (DMS) Domain user and group accounts are obtained from
	the central domain authentication backend.
	</para>

	<para>
	Regardless of the type of server being installed, local UNIX groups must be mapped to the Windows
	networking domain global group accounts. Do you ask, why? Because Samba always limits its access to
	the resources of the host server by way of traditional UNIX UID/GID controls. This means that local
	groups must be mapped to domain global groups so that domain users who are members of the domain
	global groups can be given access rights based on UIDs and GIDs local to the server that is hosting
	Samba. Such mappings are implemented using the <command>net</command> command.
	</para>

	<para>
	UNIX systems that are hosting a Samba-3 server that is running as a member (PDC, BDC, or DMS) must have
	a machine security account in the domain authentication database (or directory). The creation of such
	security (or trust) accounts is also handled using the <command>net</command> command.
	</para>

	<para>
	The establishment of interdomain trusts is achieved using the <command>net</command> command also, as
	may a plethora of typical administrative duties such as: user management, group management, share and
	printer management, file and printer migration, security identifier management, and so on.
	</para>

	<para>
	The over-all picture should be clear now, the <command>net</command> command plays a central role
	on the Samba-3 stage. This role will continue to be developed. The inclusion of this chapter is
	evidence of its importance, one that has grown in complexity to the point that it is no longer considered
	prudent to cover its use fully in the on-line UNIX man pages.
	</para>

	</sect1>

	
	<sect1>
	<title>Administrative Tasks And Methods</title>

	<para>
	Stuff goes here - this is a work in progress.!!!!!
	</para>

	<sect2>
	<title>UNIX and Windows Group Management</title>

	<para>
	More stuff.!!!!!!!!!!
	</para>

	<sect3>
	<title>Adding, Renaming, or Deletion of Group Accounts</title>

	<sect4>
	<title>Adding or Creating a New Group</title>

	<para>
	Before attempting to add a Windows group account the currently available groups can be listed as shown
here:
<screen>
&rootprompt; net rpc group list -Uroot%not24get
Password:
Domain Admins
Domain Users
Domain Guests
Print Operators
Backup Operators
Replicator
Domain Computers
Engineers
</screen>
	A Windows group account called <quote>SupportEngrs</quote> can be added by executing the following
command:
<screen>
&rootprompt; net rpc group add "SupportEngrs" -Uroot%not24get
</screen>
	The addition will result in immediate availability of the new group account as validated by executing the
this command:
<screen>
&rootprompt; net rpc group list -Uroot%not24get
Password:
Domain Admins
Domain Users
Domain Guests
Print Operators
Backup Operators
Replicator
Domain Computers
Engineers
SupportEngrs
</screen>
	</para>

	<para>
	The following demonstrates that the POSIX (UNIX/Linux system account) group has been created by calling
	the <smbconfoption name="add group script">/opt/IDEALX/sbin/smbldap-groupadd -p "%g"</smbconfoption> interface
	script:
<screen>
&rootprompt; 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:
</screen>
	The following demonstrates that the use of the <command>net</command> command to add a group account
results in immediate mapping of the POSIX group that has been created to the Windows group account as whown
here:
<screen>
merlin:~ # 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
</screen>
	</para>

	</sect4>

	<sect4>
	<title>Mapping Windows Groups to UNIX Groups</title>

	<para>
	Windows groups must be mapped to UNIX system (POSIX) groups so that file system access controls
	can be asserted in a manner that is consistent with the methods appropriate to the operating
	system that is hosting the Samba server.
	</para>

	<para>
	Samba depends on default mappings for the <constant>Domain Admins, Domain Users</constant> and
	<constant>Domain Guests</constant> global groups. Additional groups may be added as shown in the
	examples just given. There are times when it is necessary to map an existing UNIX group account
	to a Windows group. This operation, in effect, creates a Windows group account as a consequence
	of creation of the mapping.
	</para>

	<para>
	The operations that are permitted includes: <constant>add, modify, delete</constant>. An example
	of each operation is shown here.
	</para>

	<para>
	An existing UNIX group may be mapped to an existing Windows group by this example:
<screen>
&rootprompt; net groupmap modify ntgroup="Domain Users" unixgroup=users
</screen>
	An existing UNIX group may be mapped to a new Windows group as shown here:
<screen>
&rootprompt; net groupmap add ntgroup="EliteEngrs" unixgroup=Engineers type=d
</screen>
	A Windows group may be deleted, and then a new Windows group can be mapped to the UNIX group by
	executing these commands:
<screen>
&rootprompt; net groupmap delete ntgroup=Engineers
&rootprompt; net groupmap add ntgroup=EngineDrivers unixgroup=Engineers type=d
</screen>
	</para>

	<para>
	Both the Windows group as well as the UNIX group can be deleted by executing:
<screen>
&rootprompt; net groupmap delete ntgroup=
</screen>
	</para>

	</sect4>

	<sect4>
	<title>Deleting a Group Account</title>

	<para>
	A group account may be deleted by executing the following command:
<screen>
&rootprompt; net rpc group delete SupportEngineers -Uroot%not24get
</screen>
	</para>

	<para>
	Validation of the deletion is advisable. The same commands may be executed as shown above.
	</para>

	</sect4>
	<sect4>
	<title>How to Rename a Group Account</title>

	<note><para>
	This command is not documented in the man pages, it is implemented in the source code, but it does not
	work. The example given documents (from the source code) how it should work. Watch the release notes
	of a future release to see when this may have been be fixed.
	</para></note>

	<para>
	Sometimes it is necessary to rename a group account. Good administrators know how painful some managers
	demands can be if this simple request is ignored. The following command demonstrates how the Windows group
	<quote>SupportEngrs</quote> can be renamed to <quote>CustomerSupport</quote>:
<screen>
&rootprompt; net rpc group rename SupportEngrs \
    CustomerSupport -Uroot%not24get
</screen>
	</para>

	</sect4>

	</sect3>

	<sect3>
	<title>Manipulating Group Memberships</title>

	<para>
	Fix me by adding stuff here!!!!!!
	</para>

	</sect3>

	<sect3>
	<title>Nested Group Support</title>

	<para>
	It is possible in Windows (and now in Samba also) to great a local group that has members (contains)
	domain users and domain global groups.  Creation of the local group <constant>demo</constant> is
	achieved by executing:
<screen>
&rootprompt; net rpc group add demo -L -Uroot%not24get
</screen>
	The -L switch means create a local group. Use the -S argument to direct the operation to a particular
	server. The parameters to the -U argument should be for a user who has appropriate administrative right
	and privileges on the machine.
	</para>

	<para>
	Addition and removal of group members can be achieved using the <constant>addmem</constant> and
	<constant>delmem</constant> subcommands of <command>net rpc group</command> command. For example,
	addition of <quote>DOM\Domain Users</quote> to the local group <constant>demo</constant> would be
	done by executing:
<screen>
&rootprompt; net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get
</screen>
	</para>

	<para>
	The members of a nested group can be listed by executing the following:
<screen>
&rootprompt; net rpc group members demo -Uroot%not24get
DOM\Domain Users
DOM\Engineers
DOM\jamesf
DOM\jht
</screen>
	</para>

	<para>
	Nest group members can be removed (deleted) as shown here:
<screen>
&rootprompt; net rpc group delmem demo "DOM\jht" -Uroot%not24get
</screen>
	</para>

	</sect3>

	</sect2>

	<sect2>
	<title>UNIX and Windows User Management</title>

	<para>
	Put somethings useful here man!!!!!!
	</para>

	</sect2>

	<sect2>
	<title>Administering User Rights and Privileges</title>

	<para>
<screen>
&rootprompt; 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

&rootprompt; 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

&rootprompt; net rpc rights grant "MIDEARTH\Domain Admins" \
    SeMachineAccountPrivilege SePrintOperatorPrivilege \
    SeAddUsersPrivilege SeRemoteShutdownPrivilege \
    SeDiskOperatorPrivilege  -U root%not24get
Successfully granted rights.

&rootprompt; net rpc rights grant "MIDEARTH\jht" \
    SeMachineAccountPrivilege SePrintOperatorPrivilege \
    SeAddUsersPrivilege SeDiskOperatorPrivilege \
    -U root%not24get
Successfully granted rights.

&rootprompt; 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
</screen>
	</para>

	</sect2>

	<sect2>
	<title>Managing Trust Relationships</title>

	<para>
	Document how to set up trusts here!!!!!!!!!!!
	</para>

	<sect3>
	<title>Machine Trust Accounts</title>

	<para>
<screen>
&rootprompt; net rpc testjoin
Join to 'MIDEARTH' is OK
</screen>
	</para>

	</sect3>

	<sect3>
	<title>Inter-Domain Trusts</title>

	<para>
	Document how to set up trusts here!!!!!!!!!!!
	</para>

	</sect3>

	</sect2>

	<sect2>
	<title>Managing Security Identifiers (SIDS)</title>

	<para>
	Document how to set up trusts here!!!!!!!!!!!
	</para>

	</sect2>
	
	<sect2>
	<title>Share Management</title>

	<para>
	Document how to set up trusts here!!!!!!!!!!!
	</para>

	<sect3>
	<title>Creating, Editing, and Removing Shares</title>

	<para>
	A share can be added using the <command>net rpc share</command> command capabilities.
	The target machine may be local or remote and is specified by the -S option. It must be noted
	that the addition and deletion of shares using this tool depends on the availability of a suitable
	interface script. The interface scripts Samba's <command>smbd</command> uses are called:
	<smbconfoption name="add share script"/> and <smbconfoption name="delete share script"/>.
	A set of example scripts are provided in the Samba source code tarball in the directory
	<filename>~samba/examples/scripts</filename>.
	</para>

	<para>
	The following steps demonstrate the use of the share management capabilities of the <command>net</command>
	utility. In the first step a share called <constant>Bulge</constant> is added. The share-point within the
	file system is the directory <filename>/data</filename>. The command that can be executed to perform the
	addition of this share is shown here:
<screen>
&rootprompt; net rpc share add Bulge=/data -S merlin -Uroot%not24get
</screen>
	Validation is an important process, and by executing the command <command>net rpc share</command>
	with no other operators a listing of available shares is shown here:
<screen>
&rootprompt; net rpc share -S merlin -Uroot%not24get
profdata
archive
Bulge   &lt;--- This one was added
print$
netlogon
profiles
IPC$
kyocera
ADMIN$
</screen>
	</para>

	<para>
	Often times it is desirable also to permit a share to be removed using a command-line tool.
	The following step permits the share that was previously added to be removed:
<screen>
&rootprompt; net rpc share delete Bulge -S merlin -Uroot%not24get
</screen>
	A simple validation shown here demonstrates that the share has been removed:
<screen>
&rootprompt; net rpc share -S merlin -Uroot%not24get
profdata
archive
print$
netlogon
profiles
IPC$
ADMIN$
kyocera
</screen>
	</para>

	</sect3>

	<sect3>
	<title>Creating and Changing Share ACLs</title>

	<para>
	</para>

	</sect3>

	<sect3>
	<title>Share, Directory and File Migration</title>

	<para>
	Shares and files can be migrated in the same manner as user, machine and group accounts.
	It is possible to preserve access control settings (ACLs) as well as security settings
	throughout the migration process. The <command>net rpc vampire</command> facility is used
	to migrate accounts from a Windows NT4 (or later) domain to a Samba server. This process
	preserves passwords and account security settings and is a precursor to the migration
	of shares and files.
	</para>

	<para>
	The <command>net rpc share</command> command may be used to migrate shares, directories
	files, printers, and all relevant data from a Windows server to a Samba server.
	</para>

	<para>
	A set of command-line switches permit the creation of almost direct clones of Windows file
	servers. For example, when migrating a file-server, file ACLs and DOS file attributes from
	the Windows server can be included in the migration process and will reappear, almost identicaly
	on the Samba server when the migration has been completed.
	</para>

	<para>
	The migration process can be completed only with the Samba server already being fully operational.
	This means that the user and group accounts must be migrated before attempting to migrate data
	share, files, and printers. The migration of files and printer configurations involves the use
	of both SMB and MS DCE RPC services. The benefit of the manner in which the migration process has
	been implemented, the possibility now exists to use a Samba server as a man-in-middle migration
	service that affects a transfer of data from one server to another. For example, if the Samba
	server is called MESSER, the source Windows NT4 server is called PEPPY, and the target Samba
	server is called GONZALES, the machien MESSER can be used to affect the migration of all data
	(files and shares) from PEPPY to GONZALES. If the target machine is not specified, the local
	server is assumed by default.
	</para>

	<para>
	The success of server migration requires a firm understanding of the structure of ther source
	server (or domain) as well as  the processes on which the migration is critically dependant.
	</para>

	<sect4>
	<title>Share Migration</title>

	<para>
	The <command>net rpc share migrate</command> command operation permits the migration of plain
	share stanzas. A stanza contains the parameters within which a file or print share are defined.
	The use of this migration method will create share stanzas that have as parameters the file
	system directory path, an optional description, and simple security settings that permit write
	access to files. One of the first steps necessary following migration is to review the share
	stanzas to ensure that the settings are suitable for use.
	</para>

	<para>
	The shares are created on-the-fly as part of the migration process. The <command>smbd</command>
	application does this by calling on the operating system to execute the script specified by the 
	&smb.conf; parameter <parameter>add share command</parameter>.
	</para>

	<para>
	There is a suitable example script for the <parameter>add share command</parameter> in the
	<filename>$SAMBA_SOURCES/examples/scripts</filename> directory. It should be noted that
	the account that is used to drive the migration must, of necessity, have appropriate file system
	access privileges and have the right to create shares and to set ACLs on them. Such rights are
	conferred by these rights: <parameter>SeAddUsersPrivilege, SeDiskOperatorPrivilege</parameter>.
	For more information regarding rights and privileges please refer to <link linkend="rights"/>.
	</para>

	<para>
	The syntax of the share migration command is shown here:
<screen>
net rpc share MIGRATE SHARES &lt;sharename&gt; -S &lt;source&gt;
        [--destination=localhost] [--exclude=share1,share2] [-v]
</screen>
	When the parameter &lt;sharename&gt; is ommited, all shares will be migrated. The potentially
	large list of available shares on the system that is being migrated can be limited using the
	<parameter>--exclude</parameter> switch. For example:
<screen>
&rootprompt; net rpc share migrate shares myshare\
         -S win2k -U administrator%secret"
</screen>
	This will migrate the share <constant>myshare</constant> from the server <constant>win2k</constant>
	to the Samba Server using the permissions that are tied to the account <constant>administrator</constant> 
	with the password <constant>secret</constant>. The account that is used must be the same on both the
	migration source server, as well as on the target Samba server. The use of the <command>net rpc
	vampire</command>, prior to attempting the migration of shares, will ensure that accounts will be
	identical on both systems. One precaution worth taking before commencement of migration of shares is
	to validate that the migrated accounts (on the Samba server) have the needed rights and privileges.
	This can be done as shown here:
<screen>
&rootprompt; net rpc right list accounts -Uroot%not24get
</screen>
	The steps taken so far performs only the migration of shares. Directories and directory contents
	are not migrated by the steps covered up to this point.
	</para>

	</sect4>

	<sect4>
	<title>File and Directory Migration</title>

	<para>
	Everything covered to this point has been done in preparation for the migration of file and directory
	data. For many people preparation is potentially boring and the real excitement only begins when file
	data can be used. The next steps demonstrates the techniques that can be used to transfer (migrate)
	data files using the <command>net</command> command.
	</para>

	<para>
	Transfer of files from one server to another has always been a challenge for Microsoft Windows
	administrators because Windows NT and 200X servers do not include the tools needed. The
	<command>xcopy</command> is not capable of preserving file and directory ACLs. Microsoft do provide a
	utility that can copy ACLs (security settings) called <command>scopy</command>, but it is provided only
	as part of the Windows NT or 200X Server Resource Kit.
	</para>

	<para>
	There are several tools, both commercial and freeware, that can be used from Windows server to copy files
	and directories with full preservation of security settings. One of the best known of the free tools is
	called <command>robocopy</command>.
	</para>

	<para>
	The <command>net</command> utility can be used to copy files and directories with full preservation of
	ACLs as well as DOS file attributes. Note that including ACLs makes sense only where the destination
	system will operate within the same security context as the source system. This applies to both a domain
	member server (DMS) as well as for domain controllers (DCs) that result from a vampired domain.
	Before file and directory migration all shares must already exist.
	</para>

	<para>
	The syntax for the migration commands is shown here:
<screen>
net rpc share MIGRATE FILES &lt;sharename&gt; -S &lt;source&gt;
    [--destination=localhost] [--exclude=share1,share2]
    [--acls] [--attrs] [--timestamps] [-v]
</screen>
	If the &lt;sharename&gt; parameter is ommited, all shares will be migrated. The potentially large
	list of shares on the source system can be restricted using the <parameter>--exclude</parameter> command
	switch.
	</para>

	<para>
	Where it is necessary to preserve all file ACLs, the <parameter>--acls</parameter> switch should be added
	to the above command line. Original file time stamps can be preserved by specifying the
	<parameter>--timestamps</parameter> switch, and the DOS file attributs (i.e.: hidden, archive, etc.) cab
	be preserved by specifying the <parameter>--attrs</parameter> switch.
	</para>

	<note><para>
	The ability to preserve ACLs depends on appropriate support for ACLs, as well as the general file system
	semantics of the host operating system on the target server. A migration from one Windows file server to
	another will perfectly preserve all file attributes. Because of the difficulty of mapping Windows ACLs
	onto a POSIX ACLs supporting system, there can be no perfect migration of Windows ACLs to a Samba server.
	</para></note>

	<para>
	The ACLs that result on a Samba server will most probably not match the originating ACLs. Windows support
	the possibility of files that are owned only by a group. Group-alone file ownership is not possible under
	UNIX/Linux. Errors in migrating group-owned files can be avoided by using the &smb.conf; file
	<smbconfoption name="force unknown acl user">yes</smbconfoption> parameter. This facility will
	automatically convert group-owned files into correctly user-owned files on the Samba server.
	</para>

	<para>
	An example for migration of files from a machine called <constant>nt4box</constant> to the Samba server
	from which the process will be handled is shown here:
<screen>
&rootprompt; net rpc share migrate files -S nt4box --acls \
    --attrs -U administrator%secret
</screen>
	</para>

	<para>
	The above command  will migrate all files and directories from all file shares on the Windows server called
	<constant>nt4box</constant> to the Samba server from which migration is initiated. Files that are group-owned
	will be owned by the user account <constant>administrator</constant>.
	</para>

	</sect4>

	<sect4>
	<title>Simultaneous Share and File Migration</title>

	<para>
	This operating mode shown here is just a combination of the two above. It first migrates
	share-definitions and then all shared files and directories afterwards:
<screen>
net rpc share MIGRATE ALL &lt;sharename&gt; -S &lt;source&gt;
    [--exclude=share1, share2] [--acls] [--attrs] [--timestamps] [-v]
</screen>
	</para>

	<para>
	An example of simultaneous migration is shown here:
<screen>
&rootprompt; net rpc share migrate all -S w2k3server -U administrator%secret
</screen>
	This will generate a complete server clone of the <parameter>w2k3server</parameter> server.
	</para>

	</sect4>

	</sect3>

	<sect3>
	<title>Printer Migration</title>

<para>
<screen>
Migrating printers
-----------------------------------------------------------

net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets]
        migrates printers from remote to local server


Migrating printer-drivers
-----------------------------------------------------------

net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]
        migrates printer-drivers from remote to local server


Migrating printer-forms
-----------------------------------------------------------

net rpc printer MIGRATE FORMS [printer] [misc. options] [targets]
        migrates printer-forms from remote to local server


Migrating printer security-settings
-----------------------------------------------------------

net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]
        migrates printer-ACLs from remote to local server


Migrating printer-settings
-----------------------------------------------------------

net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]
        migrates printer-settings from remote to local server


Migrating printers including all the above mentioned sets of information
-----------------------------------------------------------

net rpc printer MIGRATE ALL [printer] [misc. options] [targets]
        migrates drivers, forms, queues, settings and acls from
        remote to local print-server



Known Limitations
-----------------------------------------------------------

* net requires that the given credentials exist both on the migration source
  and the migration target.

* printer-settings may not be fully or incorrectly migrated. This might in
  particular happen when migrating a Windows 2003 print-server to Samba.
</screen>
	</para>

	</sect3>

	</sect2>

	<sect2>
	<title>Controlling Open Files</title>

	<para>
	Document how to set up trusts here!!!!!!!!!!!
	</para>

	</sect2>

	<sect2>
	<title>Session and Connection Management</title>

	<para>
	Document how to set up trusts here!!!!!!!!!!!
	</para>

	</sect2>

	<sect2>
	<title>Printers and ADS</title>

	<para>
	Document how to set up trusts here!!!!!!!!!!!
	</para>

	</sect2>

	<sect2>
	<title>Manipulating the Samba Cache</title>

	<para>
	Document how to set up trusts here!!!!!!!!!!!
	</para>

	</sect2>

	<sect2>
	<title>Other Miscellaneous Operations</title>

	<para>
<screen>
&rootprompt; net rpc info
Domain Name: MIDEARTH
Domain SID: S-1-5-21-726309263-4128913605-1168186429
Sequence number: 1115878548
Num users: 5
Num domain groups: 8
Num local groups: 0
</screen>
	</para>

	</sect2>

	</sect1>

</chapter>