Large number of small fixes to the layout and the build system.

(This used to be commit 73fac0653c774a8ed8654b064fd63d4e486f6b0f)

1 files changed, 1537 insertions, 0 deletions

diff --git a/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml b/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
new file mode 100644
index 0000000000..e811fa150c
--- /dev/null
+++ b/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
@@ -0,0 +1,1537 @@
+<?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.vl;
+	&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 mimic 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>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 inter-domain 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>
+	The basic operations of the <command>net</command> command are documented here. This documentation is not
+	exhaustive, and thus it is incomplete. Since the primary focus is on migration from Windows servers to
+	a Samba server the emphasis is on the use of the DCE RPC mode of operation. When used against a server
+	that is a member of an Active Directory domain it is preferable (and often necessary) to use ADS mode
+	operations. The <command>net</command> command supports both, but not for every operation. For most
+	operations, if the mode is not specified <command>net</command> will automatically fall back via
+	the <constant>ads, rpc, rap</constant> modes.  Please refer to the man page for a more comprehensive
+	overview of the capabilities of this utility.
+	</para>
+
+	</sect1>
+
+	<sect1>
+	<title>UNIX and Windows Group Management</title>
+
+	<para>
+	In repetition of what has been said, the focus in most of this chapter is on use of the <command>net
+	rpc</command> family of operations that are supported by Samba. Most of them are supported by the
+	<command>net ads</command> mode when used in connection with MS Active Directory. The <command>net
+	rap</command> operating mode is also supported for some of these operations. RAP protocols are used
+	by IBM OS/2 and by several earlier SMB servers.
+	</para>
+
+	<para>
+	Sambas' <command>net</command> tool implements sufficient capability to permit all common administrative
+	tasks to be completed from the command line. In this section each of the essential user and group management
+	facilities are explored.
+	</para>
+
+	<para>
+	Samba-3 recognizes two types of groups: <emphasis>domain groups</emphasis> and <emphasis>local
+	groups</emphasis>. Domain groups can contain (have as members) only domain user accounts. Local groups
+	can contain local users, domain users, and domain groups as members.
+	</para>
+
+	<para>
+	The purpose of a local group is to permit file permission to be set for a group account that, like the
+	usual UNIX/Linux group, is persistent across redeployment of a Windows file server.
+	</para>
+
+	<sect2>
+	<title>Adding, Renaming, or Deletion of Group Accounts</title>
+
+	<sect3>
+	<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 shown
+here:
+<screen>
+&rootprompt; 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>
+
+	</sect3>
+
+	<sect3>
+	<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>
+	All file system (file and directory) access controls, within the file system of a UNIX/Linux server that is
+	hosting a Samba server, is implemented using a UID/GID identity tuple. Samba does not in any way over-ride
+	or replace UNIX file system semantics. Thus it is necessary that all Windows networking operations that
+	access the file system must provide a mechanism that maps a Windows user to a particular UNIX/Linux group
+	account. The user account must also map to a locally known UID.
+	</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>
+	Two types of Windows groups can be created: <constant>domain (global),</constant> and <constant>local</constant>.
+	In the above examples the Windows groups created were of type <constant>domain</constant>, or global. The
+	following command will create a Windows group of type <constant>local</constant>.
+<screen>
+&rootprompt; net groupmap add ntgroup=Pixies unixgroup=pixies type=l
+</screen>
+	Local groups can be used with Samba to enable multiple nested group support.
+	</para>
+
+	</sect3>
+
+	<sect3>
+	<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>
+
+	</sect3>
+
+	<sect3>
+	<title>Rename Group Accounts</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>
+
+	</sect3>
+
+	</sect2>
+
+	<sect2>
+	<title>Manipulating Group Memberships</title>
+
+	<para>
+	Three operations can be performed in respect of group membership. It is possible to (1) add Windows users
+	to Windows group, to (2) delete Windows users from Windows groups, and to (3) list the Windows users that are
+	members of a Windows group.
+	</para>
+
+	<para>
+	So as to avoid confusion, it makes sense to check group membership before attempting to make and changes.
+	The <command>getent group</command> will list UNIX/Linux group membership. UNIX/Linux group members are
+	seen also as members of a Windows group that has been mapped using the <command>net groupmap</command>
+	command (see <link linkend="groupmapping"/>). The following list of UNIX/Linux group membership shows
+	that the user <constant>ajt</constant> is a member of the UNIX/Linux group <constant>Engineers</constant>.
+<screen>
+&rootprompt; 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
+</screen>
+	The UNIX/Linux groups have been mapped to Windows groups, as is shown here:
+<screen>
+&rootprompt; 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
+</screen>
+	</para>
+
+	<para>
+	Given that the user <constant>ajt</constant> is already a member of the UNIX/Linux group, and via the
+	group mapping, a member of the Windows group, an attempt to add this account again should fail. This is
+	demonstrated here:
+<screen>
+&rootprompt; net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
+Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP
+</screen>
+	This shows that the group mapping between UNIX/Linux groups and Windows groups is effective and
+	transparent.
+	</para>
+
+	<para>
+	To permit the user <constant>ajt</constant> to be added using the <command>net rpc group</command> utility
+	this account must first be removed. The removal, and confirmation of its effect is shown here:
+<screen>
+&rootprompt; net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24get
+&rootprompt; getent group Engineers
+Engineers:x:1000:jht
+&rootprompt; net rpc group members Engineers -Uroot%not24get
+MIDEARTH\jht
+</screen>
+	In this example both at the UNIX/Linux system level, the group no longer has the <constant>ajt</constant>
+	as a member. The above also shows this to be the case for Windows group membership.
+	</para>
+
+	<para>
+	The account is now added again, using the <command>net rpc group</command> utility:
+<screen>
+&rootprompt; net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
+&rootprompt; getent group Engineers
+Engineers:x:1000:jht,ajt
+&rootprompt; net rpc group members Engineers -Uroot%not24get
+MIDEARTH\jht
+MIDEARTH\ajt
+</screen>
+	</para>
+
+	<para>
+	In this example the members of the Windows <constant>Domain Users</constant> account is validated using
+	the <command>net rpc group</command> utility. Note that this contents of the UNIX/Linux group was shown
+	4 paragraphs earlier. The Windows (domain) group membership is shown here:
+<screen>
+&rootprompt; net rpc group members "Domain Users" -Uroot%not24get
+MIDEARTH\jht
+MIDEARTH\lct
+MIDEARTH\ajt
+MIDEARTH\met
+MIDEARTH\vlendecke
+</screen>
+	The example shown here is an express example that Windows group names are treated by Samba (as with
+	MS Windows) in a case insensitive manner:
+<screen>
+&rootprompt; net rpc group members "DomAiN USerS" -Uroot%not24get
+MIDEARTH\jht
+MIDEARTH\lct
+MIDEARTH\ajt
+MIDEARTH\met
+MIDEARTH\vlendecke
+</screen>
+	</para>
+
+	<note><para>
+	An attempt to specify the group name as <constant>MIDEARTH\Domain Users</constant> in place of
+	just simply <constant>Domain Users</constant> will fail. The default behavior of the net rpc group
+	is to direct the command at the local machine. The Windows group is treated as being local to the machine.
+	If it is necessary to query another machine, its name can be specified using the <constant>-S
+	servername</constant> parameter to the <command>net</command> command.
+	</para></note>
+
+	</sect2>
+
+	<sect2>
+	<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 -S MORDON -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>
+	Nested group members can be removed (deleted) as shown here:
+<screen>
+&rootprompt; net rpc group delmem demo "DOM\jht" -Uroot%not24get
+</screen>
+	</para>
+
+	<para>
+	Windows network administrators often ask on the Samba mailing list how it is possible to grant everyone
+	administrative rights on their own workstation. This is of course a very bad practice, but commonly done
+	to avoid user complaints. Here is how it can be done remotely from a Samba PDC or BDC:
+<screen>
+&rootprompt; net rpc group addmem "Administrators" "Domain Users" \
+    -S WINPC032 -Uadministrator%secret
+</screen>
+	</para>
+
+	</sect2>
+
+	</sect1>
+
+	<sect1>
+	<title>UNIX and Windows User Management</title>
+
+	<para>
+	Every Windows network user account must be translated to a UNIX/Linux user account. In actual fact,
+	the only account information the UNIX/Linux Samba server needs is a UID.  The UID is available either
+	from a system (POSIX) account, or from a pool (range) of UID numbers that is set aside for the purpose
+	of being allocated for use by Windows user accounts. In the case of the UID pool, the UID for a
+	particular user will be allocated by <command>winbindd</command>.
+	</para>
+
+	<para>
+	Although this is not the appropriate place to discuss the <smbconfoption name="username map"/> facility,
+	this interface is an important method of mapping a Windows user account to a UNIX account that has a
+	different name. Refer to the man page for the &smb.conf; file for more information regarding this
+	facility. User name mappings can not be managed using the <command>net</command> utility.
+	</para>
+
+	<sect2 id="sbeuseraddn">
+	<title>Adding User Accounts</title>
+
+	<para>
+	The syntax for adding a user account via the <command>net</command> (according to the man page) is shown
+	here:
+<screen>
+net [&lt;method&gt;] user ADD &lt;name&gt; [-c container] [-F user flags] \
+    [misc. options] [targets]
+</screen>
+	The user account password may be set using this syntax:
+<screen>
+net rpc password &lt;username&gt; [&lt;password&gt;] -Uadmin_username%admin_pass
+</screen>
+	</para>
+
+	<para>
+	The following demonstrates the addition of an account to the server <constant>FRODO</constant>:
+<screen>
+&rootprompt; net rpc user add jacko -S FRODO -Uroot%not24get
+Added user jacko
+</screen>
+	The account password can be set with the following methods (all show the same operation):
+<screen>
+&rootprompt; net rpc password jacko f4sth0rse -S FRODO -Uroot%not24get
+&rootprompt; net rpc user password jacko f4sth0rse \
+    -S FRODO -Uroot%not24get
+</screen>
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>Deletion of User Accounts</title>
+
+	<para>
+	Deletion of a user account can be done using the following syntax:
+<screen>
+net [&lt;method&gt;] user DELETE &lt;name&gt; [misc. options] [targets]
+</screen>
+	The following command will delete the user account <constant>jacko</constant>:
+<screen>
+&rootprompt; net rpc user delete jacko -Uroot%not24get
+Deleted user account
+</screen>
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>Managing User Accounts</title>
+
+	<para>
+	Two basic user account operations are routinely used, change of password and querying which groups a user
+	is a member of. The change of password operation is shown in <link linkend="sbeuseraddn"/>.
+	</para>
+
+	<para>
+	The ability to query Windows group membership can be essential. Here is how a remote server may be
+	interrogated to find which groups a user is a member of:
+<screen>
+&rootprompt; 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
+</screen>
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>User Mapping</title>
+
+	<para>
+	In some situations it is unavoidable that a users' Windows logon name will differ from the login ID
+	that user has on the Samba server. It is possible to create a special file on the Samba server that
+	will permit the Windows user name to be mapped to a different UNIX/Linux user name. The &smb.conf;
+	file must also be amended so that the <constant>[global]</constant> stanza contains the parameter:
+<screen>
+username map = /etc/samba/smbusers
+</screen>
+	The content of the <filename>/etc/samba/smbusers</filename> file is shown here:
+<screen>
+parsonsw: "William Parsons"
+marygee: geeringm
+</screen>
+	In this example the Windows user account <quote>William Parsons</quote> will be mapped to the UNIX user
+	<constant>parsonsw</constant>, and the Windows user account <quote>geeringm</quote> will be mapped to the
+	UNIX user <constant>marygee</constant>.
+	</para>
+
+	</sect2>
+
+	</sect1>
+
+	<sect1>
+	<title>Administering User Rights and Privileges</title>
+
+	<para>
+	With all versions of Samba earlier than 3.0.11 the only account on a Samba server that had the ability
+	to manage users, groups, shares, printers, etc. is the <constant>root</constant> account. This caused
+	immense problems for some users and was a frequent source of scorn over the necessity to hand out the
+	credentials for the most security sensitive account on a UNIX/Linux system.
+	</para>
+
+	<para>
+	New to Samba version 3.0.11 is the ability to delegate administrative privileges as necessary to either
+	a normal user, or to groups of users. The significance of the administrative privileges is documented
+	in <link linkend="rights"/>. Examples of use of the <command>net</command> for user rights and privilege
+	management is appropriate to this chapter.
+	</para>
+
+	<note><para>
+	When user rights and privileges are correctly set there is no longer a need for there to be a Windows
+	network account for the <constant>root</constant> user (nor for any synonym of it) with a UNIX UID=0.
+	Initial user rights and privileges can be assigned by any account that is a member of the <constant>
+	Domain Admins</constant> group. Rights can be assigned to user as well as group accounts.
+	</para></note>
+
+	<para>
+	By default, no privileges and rights are assigned. This is demonstrated by executing the command
+	shown here:
+<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
+</screen>
+	</para>
+
+	<para>
+	The <command>net</command> command can be used to obtain the currently supported capabilities for rights
+	and privileges using this method:
+<screen>
+&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
+</screen>
+	Machine account privilege is necessary to permit a Windows NT4 or later network client to be added to the
+	domain. The disk operator privilege is necessary to permit the user to manage share ACLs and file and
+	directory ACLs for objects not owned by the user.
+	</para>
+
+	<para>
+	In this example, all rights are assigned to the <constant>Domain Admins</constant> group. This is a good
+	idea since members of this group are generally expected to be all-powerful. This assignment makes that
+	the reality:
+<screen>
+&rootprompt; net rpc rights grant "MIDEARTH\Domain Admins" \
+    SeMachineAccountPrivilege SePrintOperatorPrivilege \
+    SeAddUsersPrivilege SeRemoteShutdownPrivilege \
+    SeDiskOperatorPrivilege  -U root%not24get
+Successfully granted rights.
+</screen>
+	Next, the domain user <constant>jht</constant> is given the privileges needed for day to day
+	administration:
+<screen>
+&rootprompt; net rpc rights grant "MIDEARTH\jht" \
+    SeMachineAccountPrivilege SePrintOperatorPrivilege \
+    SeAddUsersPrivilege SeDiskOperatorPrivilege \
+    -U root%not24get
+Successfully granted rights.
+</screen>
+	</para>
+
+	<para>
+	The following step permits validation of the changes just made:
+<screen>
+&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>
+
+	</sect1>
+
+	<sect1>
+	<title>Managing Trust Relationships</title>
+
+	<para>
+	There are essentially two types of trust relationships. The first between domain controllers and domain
+	member machines (network clients), the second trusts between domains (called inter-domain trusts). All
+	Samba servers that participate in domain security require a domain membership trust account, as do like
+	Windows NT/2KX/XPP workstations.
+	</para>
+
+	<sect2>
+	<title>Machine Trust Accounts</title>
+
+	<para>
+	A Samba server domain trust account can be validated as shown in this example:
+<screen>
+&rootprompt; net rpc testjoin
+Join to 'MIDEARTH' is OK
+</screen>
+	Where there is no domain membership account, or when the account credentials are not valid the following
+	results will be observed:
+<screen>
+net rpc testjoin -S DOLPHIN
+Join to domain 'WORLDOCEAN' is not valid
+</screen>
+	</para>
+
+	<para>
+	The equivalent command for joining a Samba server to a Windows ADS domain is shown here:
+<screen>
+&rootprompt; net ads testjoin
+Using short domain name -- TAKEAWAY
+Joined 'LEMONADE' to realm 'TAKEAWAY.BIZ'
+</screen>
+	In the event that the ADS trust was not established, or is broken for one reason or another, the following
+	error message may be obtained:
+<screen>
+&rootprompt; net ads testjoin -UAdministrator%secret
+Join to domain is not valid
+</screen>
+	</para>
+
+	<para>
+	The following demonstrates the process of creating a machine trust account in the target domain for the
+	Samba server from which the command is executed:
+<screen>
+&rootprompt; net rpc join -S FRODO -Uroot%not24get
+Joined domain MIDEARTH.
+</screen>
+	The joining of a Samba server to a Samba domain results in the creation of a machine account. An example
+	of this is shown here:
+<screen>
+&rootprompt; pdbedit -Lw merlin\$
+merlin$:1009:9B4489D6B90461FD6A3EC3AB96147E16:\
+176D8C554E99914BDF3407DEA2231D80:[S          ]:LCT-42891919:
+</screen>
+	The S in the square brackets means this is a server (PDC/BDC) account. The domain join can be cast to join
+	purely as a workstation, in which case the S is replaced with a W (indicating a workstation account). The
+	following command can be used to affect this:
+<screen>
+&rootprompt; net rpc join member -S FRODO -Uroot%not24get
+Joined domain MIDEARTH.
+</screen>
+	Note that the command-line parameter <constant>member</constant> makes this join specific. By default
+	the type is deduced from the &smb.conf; file configuration. To specifically join as a PDC or BDC the
+	command-line parameter will be <constant>[PDC | BDC]</constant>. For example:
+<screen>
+&rootprompt; net rpc join bdc -S FRODO -Uroot%not24get
+Joined domain MIDEARTH.
+</screen>
+	It is best to let Samba figure out the domain join type from the settings in the &smb.conf; file.
+	</para>
+
+	<para>
+	The command to join a Samba server to a Windows ADS domain is shown here:
+<screen>
+&rootprompt; net ads join -UAdministrator%not24get
+Using short domain name -- GDANSK
+Joined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ'
+</screen>
+	</para>
+
+	<para>
+	There is no specific option to remove a machine account from ain NT4 domain. When a domain member that is a
+	Windows machine is withdrawn from the domain the domain membership account is not automatically removed
+	either. Inactive domain member accounts can be removed using any convenient tool. If necessary, the
+	machine account can be removed using the following <command>net</command> command:
+<screen>
+&rootprompt; net rpc user delete HERRING\$ -Uroot%not24get
+Deleted user account.
+</screen>
+	The removal is made possible because machine account are just like user accounts with a trailing $
+	character. The account management operations treat user and machine accounts in like manner.
+	</para>
+
+	<para>
+	A Samba-3 server that is a Windows ADS domain member can execute the following command to detach from the
+	domain:
+<screen>
+&rootprompt; net ads leave
+</screen>
+	</para>
+
+	<para>
+	Detailed information regarding an ADS domain can be obtained by a Samba DMS machine by executing the
+	following:
+<screen>
+&rootprompt; net ads status
+</screen>
+	The volume of information is extensive. Please refer to the book <quote>Samba-3 by Example</quote>,
+Chapter 7 for more information regarding its use. This book may be obtained either in print, or on line from
+the <ulink url="http://www.samba.org/samba/docs/Samba-Guide.pdf">Samba-Guide</ulink>.
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>Inter-Domain Trusts</title>
+
+	<para>
+	Inter-domain trust relationships form the primary mechanism by which users from one domain can be granted
+	access rights and privileges in another domain. 
+	</para>
+
+	<para>
+	To discover what trust relationships are in effect execute this command:
+<screen>
+&rootprompt; net rpc trustdom list -Uroot%not24get
+Trusted domains list:
+
+none
+
+Trusting domains list:
+
+none
+</screen>
+	There are no inter-domain trusts at this time, the following steps will create them.
+	</para>
+
+	<para>
+	It is necessary to create a trust account in the local domain. A domain controller in a second domain can
+	create a trusted connection with this account. That means that the foreign domain is being trusted
+	to access resources in the local domain. This command creates the local trust account:
+<screen>
+&rootprompt; net rpc trustdom add damnation f00db4r -Uroot%not24get
+</screen>
+	The account can be revealed by using the <command>pdbedit</command> as shown here:
+<screen>
+&rootprompt; pdbedit -Lw damnation\$
+damnation$:1016:9AC1F121DF897688AAD3B435B51404EE: \
+7F845808B91BB9F7FEF44B247D9DC9A6:[I         ]:LCT-428934B1:
+</screen>
+	A trust account will always have an I in the field within the square brackets.
+	</para>
+
+	<para>
+	If the trusting domain is not capable of being reached the following command will fail
+<screen>
+&rootprompt; net rpc trustdom list -Uroot%not24get
+Trusted domains list:
+
+none
+
+Trusting domains list:
+
+DAMNATION           S-1-5-21-1385457007-882775198-1210191635
+</screen>
+	The above command executed successfully; a failure is indicated when the following response is obtained:
+<screen>
+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
+</screen>
+	</para>
+
+	<para>
+	Where a trust account has been created on a foreign domain, Samba is able to establish the trust (connect with)
+	the foreign account. In the process it creates a one-way trust to the resources on the remote domain. This
+	command achieves the objective of enjoining the trust relationship:
+<screen>
+&rootprompt; net rpc trustdom establish damnation
+Password: xxxxxxx	== f00db4r
+Could not connect to server TRANSGRESSION
+Trust to domain DAMNATION established
+</screen>
+	Validation of the two-way trust now established is possible as shown here:
+<screen>
+&rootprompt; 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
+</screen>
+	</para>
+
+	<para>
+	Sometimes it is necessary to remove the ability for local uses to access a foreign domain. The trusting
+	connection can be revoked as shown here:
+<screen>
+&rootprompt; net rpc trustdom revoke damnation -Uroot%not24get
+</screen>
+	At other times it becomes necessary to remove the ability for users from a foreign domain to be able to
+	access resources in the local domain. The command shown here will do that:
+<screen>
+&rootprompt; net rpc trustdom del damnation -Uroot%not24get
+</screen>
+
+	</para>
+
+	</sect2>
+
+	</sect1>
+
+	<sect1>
+	<title>Managing Security Identifiers (SIDS)</title>
+
+	<para>
+	The basic security identifier that is used b y all Windows networking operations is the Windows security
+	identifier (SID). All Windows network machines (servers and workstations), users, and groups are
+	identified by their respective SID. All desktop profiles are also encoded with user and group SIDs that
+	are specific to the SID of the domain to which the user belongs.
+	</para>
+
+	<para>
+	It is truly prudent to store the machine and/or domain SID in a file for safe-keeping. Why? Because 
+	a change in hostname or in the domain (workgroup) name may result in a change in the SID. When you
+	have the SID on hand it is a simple matter to restore it. The alternative is to suffer the pain of
+	having to recover user desktop profiles and perhaps re-join all member machines to the domain.
+	</para>
+
+	<para>
+	First, do not forget to store the local sid in a file. It is a good idea to put this in the directory
+	in which the &smb.conf; file is also stored. Here is a simple action to achieve this:
+<screen>
+&rootprompt; net getlocalsid > /etc/samba/my-sid
+</screen>
+	Good, there is now a safe copy of the local machine SID. On a PDC/BDC this is the domain SID also.
+	</para>
+
+	<para>
+	The following command reveals what the former one should have placed into the file called
+	<filename>my-sid</filename>:
+<screen>
+&rootprompt; net getlocalsid
+SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429
+</screen>
+	</para>
+
+	<para>
+	If ever it becomes necessary to restore the SID that has been stored in the <filename>my-sid</filename>
+	file, simply copy the SID (the string of characters that begins with <constant>S-1-5-21</constant>) to
+	the command-line shown here:
+<screen>
+&rootprompt; net setlocalsid S-1-5-21-1385457007-882775198-1210191635
+</screen>
+	Restoration of a machine SID is a simple operation, but the absence of a back-up copy can be very
+	problematic.
+	</para>
+
+	<para>
+	The following operation is useful only for machines that are being configured as a PDC or a BDC.
+	Domain member servers (DMS) and workstation clients should have their own machine SID to avoid
+	any potential name-space collision. Here is the way that the BDC SID can be synchronized to that
+	of the PDC (this is the default NT4 domain practice also):
+<screen>
+&rootprompt; net rpc getsid -S FRODO -Uroot%not24get
+Storing SID S-1-5-21-726309263-4128913605-1168186429 \
+    for Domain MIDEARTH in secrets.tdb
+</screen>
+	Usually it is not necessary to specify the target server (-S FRODO) or the administrator account
+	credentials (-Uroot%not24get).
+	</para>
+
+	</sect1>
+	
+	<sect1>
+	<title>Share Management</title>
+
+	<para>
+	Share management is central to all file serving operations. Typical share operations include:
+	</para>
+
+	<itemizedlist>
+		<listitem><para>Creation/change/deletion of shares</para></listitem>
+		<listitem><para>Setting/changing ACLs on shares</para></listitem>
+		<listitem><para>Moving shares from one server to another</para></listitem>
+		<listitem><para>Change of permissions of share contents</para></listitem>
+	</itemizedlist>
+
+	<para>
+	Each of these are dealt with here in so far as they involve the use of the <command>net</command>
+	command. Operations outside of this command are covered elsewhere in this document.
+	</para>
+
+	<sect2>
+	<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 Sambas <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 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>
+
+	</sect2>
+
+	<sect2>
+	<title>Creating and Changing Share ACLs</title>
+
+	<para>
+	At this time the net tool can not be used to manage ACLs on Samba shares. In MS Windows 
+	language this is called: Share Permissions.
+	</para>
+
+	<para>
+	It is possible to set ACLs on Samba shares using either the SRVTOOLS NT4 Domain Server Manager,
+	of using the Computer Management MMC snap-in. Neither will be covered here as this subject is
+	covered in <link linkend="AccessControls"/>.
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<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 identically
+	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 machine 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 the source
+	server (or domain) as well as  the processes on which the migration is critically dependant.
+	</para>
+
+	<para>
+	There are two known limitations to the migration process:
+	</para>
+
+	<orderedlist>
+		<listitem><para>
+		The <command>net</command> command requires that the user credentials provided exist both
+		on the migration source and the migration target.
+		</para></listitem>
+
+		<listitem><para>
+		Printer settings may not be fully or incorrectly migrated. This might in particular happen
+		when migrating a Windows 2003 print server to Samba.
+		</para></listitem>
+	</orderedlist>
+
+	<sect3>
+	<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;share-name&gt; -S &lt;source&gt;
+        [--destination=localhost] [--exclude=share1,share2] [-v]
+</screen>
+	When the parameter &lt;share-name&gt; 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
+	<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>
+
+	</sect3>
+
+	<sect3>
+	<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;share-name&gt; -S &lt;source&gt;
+    [--destination=localhost] [--exclude=share1,share2]
+    [--acls] [--attrs] [--timestamps] [-v]
+</screen>
+	If the &lt;share-name&gt; parameter is omitted, 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 attributes (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>
+
+	</sect3>
+
+	<sect3>
+	<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;share-name&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>
+
+	</sect3>
+
+	</sect2>
+
+	<sect2>
+	<title>Printer Migration</title>
+
+	<para>
+	The installation of a new server, as with the migration to a new network environment, often has similarity
+	to the building of a house; progress is very rapid from the laying of foundations up to the stage at which
+	the the house can be locked-up, but the finishing off appears to take longer and longer as building
+	approaches completion.
+	</para>
+
+	<para>
+	Printing needs vary greatly depending on the network environment, and may be very simple or complex. If
+	the need is very simple the best solution to the implementation of printing support may well be to
+	re-install everything from a clean slate instead of migrating older configurations. On the other hand,
+	a complex network that is integrated with many international offices and a multiplexity of local branch
+	offices, each of which form an inter-twined maze of printing possibilities, the ability to migrate all
+	printer configurations is decidedly beneficial. To manually re-establish a complex printing network
+	will take much time and frustration. Often-times it will not be possible to find driver files that are
+	currently in use thus necessitating the installation of newer drivers. Newer drivers often implement
+	printing features that will necessitate a change in the printer usage. Additionally, with very complex
+	printer configurations it becomes almost impossible to re-create the same environment - not matter
+	how extensively it has been documented.
+	</para>
+
+	<para>
+	The migration of an existing printing architecture involves the following:
+	</para>
+
+	<itemizedlist>
+		<listitem><para>Establishment of print queues.</para></listitem>
+
+		<listitem><para>Installation of printer drivers (both for the print server and for Windows clients.</para></listitem>
+
+		<listitem><para>Configuration of printing forms.</para></listitem>
+
+		<listitem><para>Implementation of security settings.</para></listitem>
+
+		<listitem><para>Configuration of printer settings.</para></listitem>
+	</itemizedlist>
+
+	<para>
+	The Samba <command>net</command> utility permits printer migration from one Windows print server
+	to another. When this tool is used to migrate printers to a Samba server <command>smbd</command>,
+	the application the receives the network requests to create the necessary services, must call-out
+	to the operating system in order to create the underlying printers. The call-out is implemented
+	by way of an interface script that can be specified by the &smb.conf; file parameter
+	<smbconfoption id="add printer script"/>. This script is essential to the migration process.
+	A suitable example script may be obtained from the <filename>$SAMBA_SOURCES/examples/scripts</filename>
+	directory. Take note that this script must be customized to suit the operating system environment
+	and may use its tools to create a print queue.
+	</para>
+
+	<para>
+	Each of the components listed above can be completed separately, or they can be completed as part of an
+	automated operation. Many network administrators prefer to deal with migration issues in a manner that
+	gives them the most control, particularly when things go wrong. The syntax for each operation will now
+	be briefly described.
+	</para>
+
+	<para>
+	Printer migration from a Windows print server (NT4 or 200X) is shown. This instruction causes the
+	printer share to be created together with the underlying print queue:
+<screen>
+net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets]
+</screen>
+	Printer drivers can be migrated from the Windows print server to the Samba server using this
+	command line instruction:
+<screen>
+net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]
+</screen>
+	Printer forms can be migrated with the following operation:
+<screen>
+net rpc printer MIGRATE FORMS [printer] [misc. options] [targets]
+</screen>
+	Printer security settings (ACLs) can be migrated from the Windows server to the Samba server using this command:
+<screen>
+net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]
+</screen>
+	Printer configuration settings include factors such as paper size, default paper orientation, etc.
+	These can be migrated from the Windows print server to the Samba server with this command:
+<screen>
+net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]
+</screen>
+	</para>
+
+	<para>
+	Migration of printers including all the above mentioned sets of information may be completed
+	with a single command using this syntax:
+<screen>
+net rpc printer MIGRATE ALL [printer] [misc. options] [targets]
+</screen>
+	</para>
+
+	</sect2>
+
+	</sect1>
+
+	<sect1>
+	<title>Controlling Open Files</title>
+
+	<para>
+	The man page documents the <command>net file</command> function suite. These ability is provided to
+	close open files using either RAP or RPC function calls. Please refer to the man page for specific
+	usage information.
+	</para>
+
+	</sect1>
+
+	<sect1>
+	<title>Session and Connection Management</title>
+
+	<para>
+	The session management interface of the <command>net session</command> command uses the old RAP
+	method to obtain the list of connections to the Samba server, as shown here:
+<screen>
+&rootprompt; 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
+</screen>
+	</para>
+
+	<para>
+	A session can be closed by executing a command as shown here:
+<screen>
+&rootprompt; net rap session close marvel -Uroot%not24get
+</screen>
+	</para>
+
+	</sect1>
+
+	<sect1>
+	<title>Printers and ADS</title>
+
+	<para>
+	When Samba-3 is used within as MS Windows ADS environment printers shared via Samba will not be browseable
+	until they have been published to the ADS domain. Information regarding published printers my be obtained
+	from the ADS server by executing the <command>net ads print info</command> command following this syntax:
+<screen>
+net ads printer info &lt;printer_name&gt; &lt;server_name&gt; -Uadministrator%secret
+</screen>
+	If the asterisk (*) is used in place of the printer_name argument, a list of all printers will be
+	returned.
+	</para>
+
+	<para>
+	To publish (make available)  a printer to ADS execute the following command:
+<screen>
+net ads printer publish &lt;printer_name&gt; -Uadministrator%secret
+</screen>
+	This publishes a printer from the local Samba server to ADS.
+	</para>
+
+	<para>
+	Removal of a Samba printer from ADS is achieved by executing this command:
+<screen>
+net ads printer remove &lt;printer_name&gt; -Uadministrator%secret
+</screen>
+	</para>
+
+	<para>
+	A generic search (query) can also be made to locate a printer across the entire ADS domain by executing:
+<screen>
+net ads printer search &lt;printer_name&gt; -Uadministrator%secret
+</screen>
+	</para>
+
+	</sect1>
+
+	<sect1>
+	<title>Manipulating the Samba Cache</title>
+
+	<para>
+	Please refer to the net command man page for information regarding cache management.
+	</para>
+
+	</sect1>
+
+	<sect1>
+	<title>Other Miscellaneous Operations</title>
+
+	<para>
+	The following command is useful for obtaining basic statistics regarding a Samba domain. This command does
+	not work against current Windows XP Professional clients.
+<screen>
+&rootprompt; 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
+</screen>
+	</para>
+
+	<para>
+	Another useful tool is the <command>net time</command> tool set. This tool may be used to query the
+	current time on the target server as shown here:
+<screen>
+&rootprompt; net time -S SAURON
+Tue May 17 00:50:43 2005
+</screen>
+	In the event that it is the intent to pass the time information obtained to the UNIX
+	<command>/bin/time</command> it is a good idea to obtain the time from the target server in a format
+	that is ready to be passed through. This may be done by executing:
+<screen>
+&rootprompt; net time system -S FRODO
+051700532005.16
+</screen>
+	The time can be set on a target server by executing:
+<screen>
+&rootprompt; net time set -S MAGGOT -U Administrator%not24get
+Tue May 17 00:55:30 MDT 2005
+</screen>
+	It is possible to obtain the time-zone a server is in by executing the following command against it:
+<screen>
+&rootprompt; net time zone -S SAURON
+-0600
+</screen>
+	</para>
+
+	</sect1>
+
+</chapter>