summaryrefslogtreecommitdiff
path: root/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
diff options
context:
space:
mode:
Diffstat (limited to 'docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml')
-rw-r--r--docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml260
1 files changed, 237 insertions, 23 deletions
diff --git a/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml b/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
index 3856e5744a..807a3c84a2 100644
--- a/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
@@ -12,13 +12,20 @@
<title>Remote and Local Management: The Net Command</title>
<para>
+<indexterm><primary>net</primary></indexterm>
+<indexterm><primary>remote management</primary></indexterm>
+<indexterm><primary>command-line</primary></indexterm>
+<indexterm><primary>scripted control</primary></indexterm>
The <command>net</command> command is one of the new features of Samba-3 and is an attempt to provide a useful
-tool for 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.
+tool for 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>
+<indexterm><primary>net</primary></indexterm>
+<indexterm><primary>network administrator's toolbox</primary></indexterm>
+<indexterm><primary>smbgroupedit</primary></indexterm>
+<indexterm><primary>rpcclient</primary></indexterm>
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 has introduced tools, such as
@@ -38,6 +45,12 @@ the infliction of self-induced pain, agony, and desperation. Be warned: this is
<title>Overview</title>
<para>
+<indexterm><primary>standalone</primary></indexterm>
+<indexterm><primary>domain member</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>DMS</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
The tasks that follow the installation of a Samba-3 server, whether standalone or 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 standalone server and a PDC.
@@ -46,6 +59,14 @@ the infliction of self-induced pain, agony, and desperation. Be warned: this is
</para>
<para>
+<indexterm><primary>server type</primary></indexterm>
+<indexterm><primary>local UNIX groups</primary></indexterm>
+<indexterm><primary>mapped</primary></indexterm>
+<indexterm><primary>domain global group</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>GID</primary></indexterm>
+<indexterm><primary>access rights</primary></indexterm>
+<indexterm><primary>net</primary></indexterm>
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 and GID controls. This means that local
@@ -55,18 +76,36 @@ the infliction of self-induced pain, agony, and desperation. Be warned: this is
</para>
<para>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>DMS</primary></indexterm>
+<indexterm><primary>security account</primary></indexterm>
+<indexterm><primary>domain authentication</primary></indexterm>
+<indexterm><primary>trust accounts</primary></indexterm>
+<indexterm><primary>net</primary></indexterm>
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>
+<indexterm><primary>interdomain trusts</primary></indexterm>
+<indexterm><primary>net</primary></indexterm>
+<indexterm><primary>administrative duties</primary></indexterm>
+<indexterm><primary>user management</primary></indexterm>
+<indexterm><primary>group management</primary></indexterm>
+<indexterm><primary>share management</primary></indexterm>
+<indexterm><primary>printer management</primary></indexterm>
+<indexterm><primary>printer migration</primary></indexterm>
+<indexterm><primary>SID management</primary></indexterm>
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>
+<indexterm><primary>net</primary></indexterm>
+<indexterm><primary>man pages</primary></indexterm>
The overall 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
@@ -79,14 +118,19 @@ the infliction of self-induced pain, agony, and desperation. Be warned: this is
<title>Administrative Tasks and Methods</title>
<para>
+<indexterm><primary>net</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>Distributed Computing Environment</primary><see>DCE</see></indexterm>
+<indexterm><primary>Remote Procedure Call</primary><see>RPC</see></indexterm>
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</constant>,
- <constant>rpc</constant>, and <constant>rap</constant> modes. Please refer to the man page for a more
- comprehensive overview of the capabilities of this utility.
+ server, the emphasis is on the use of the Distributed Computing Environment Remote Procedure Call (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</constant>, <constant>rpc</constant>, and
+ <constant>rap</constant> modes. Please refer to the man page for a more comprehensive overview of the
+ capabilities of this utility.
</para>
</sect1>
@@ -95,20 +139,32 @@ the infliction of self-induced pain, agony, and desperation. Be warned: this is
<title>UNIX and Windows Group Management</title>
<para>
- As stated, 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 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.
+<indexterm><primary>Active Directory</primary></indexterm>
+<indexterm><primary>net</primary><secondary>rpc</secondary></indexterm>
+<indexterm><primary>net</primary><secondary>ads</secondary></indexterm>
+<indexterm><primary>net</primary><secondary>rap</secondary></indexterm>
+<indexterm><primary>RAP</primary></indexterm>
+ As stated, 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 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>
+<indexterm><primary>net</primary></indexterm>
+<indexterm><primary>user management</primary></indexterm>
+<indexterm><primary>group management</primary></indexterm>
Samba's <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>
+<indexterm><primary>groups</primary></indexterm>
+<indexterm><primary>domain</primary><secondary>groups</secondary></indexterm>
+<indexterm><primary>local</primary><secondary>groups</secondary></indexterm>
+<indexterm><primary>domain user accounts</primary></indexterm>
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.
@@ -127,7 +183,8 @@ the infliction of self-induced pain, agony, and desperation. Be warned: this is
<para>
Before attempting to add a Windows group account, the currently available groups can be listed as shown
-here:
+ here:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group</tertiary></indexterm>
<screen>
&rootprompt; net rpc group list -Uroot%not24get
Password:
@@ -163,6 +220,9 @@ SupportEngrs
</para>
<para>
+<indexterm><primary>POSIX</primary></indexterm>
+<indexterm><primary>smbldap-groupadd</primary></indexterm>
+<indexterm><primary>getent</primary></indexterm>
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:
@@ -182,6 +242,7 @@ SupportEngrs:x:1003:
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:
+<indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>list</tertiary></indexterm>
<screen>
&rootprompt; net groupmap list
Domain Admins (S-1-5-21-72630-4128915-11681869-512) -> Domain Admins
@@ -202,12 +263,20 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
<title>Mapping Windows Groups to UNIX Groups</title>
<para>
+<indexterm><primary>mapped</primary></indexterm>
+<indexterm><primary>Windows groups</primary></indexterm>
+<indexterm><primary>system groups</primary></indexterm>
+<indexterm><primary>access controls</primary></indexterm>
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>
+<indexterm><primary>access controls</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>GID</primary></indexterm>
+<indexterm><primary>locally known UID</primary></indexterm>
All file system (file and directory) access controls, within the file system of a UNIX/Linux server that is
hosting a Samba server, are implemented using a UID/GID identity tuple. Samba does not in any way override
or replace UNIX file system semantics. Thus it is necessary that all Windows networking operations that
@@ -216,6 +285,13 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
</para>
<para>
+<indexterm><primary>default mappings</primary></indexterm>
+<indexterm><primary>Domain Admins</primary></indexterm>
+<indexterm><primary>Domain Users</primary></indexterm>
+<indexterm><primary>Domain Guests</primary></indexterm>
+<indexterm><primary>Windows group</primary></indexterm>
+<indexterm><primary>UNIX group</primary></indexterm>
+<indexterm><primary>mapping</primary></indexterm>
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
@@ -224,6 +300,9 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
</para>
<para>
+<indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>modify</tertiary></indexterm>
+<indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>add</tertiary></indexterm>
+<indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>delete</tertiary></indexterm>
The operations that are permitted include: <constant>add</constant>, <constant>modify</constant>,
and <constant>delete</constant>. An example of each operation is shown here.
</para>
@@ -261,6 +340,7 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
<title>Deleting a Group Account</title>
<para>
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group delete</tertiary></indexterm>
A group account may be deleted by executing the following command:
<screen>
&rootprompt; net rpc group delete SupportEngineers -Uroot%not24get
@@ -286,6 +366,7 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
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>:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group rename</tertiary></indexterm>
<screen>
&rootprompt; net rpc group rename SupportEngrs \
CustomerSupport -Uroot%not24get
@@ -341,6 +422,7 @@ Engineers (S-1-5-21-72630-412605-116429-3001) -> Engineers
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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group addmem</tertiary></indexterm>
<screen>
&rootprompt; net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP
@@ -352,6 +434,7 @@ Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP
<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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group delmem</tertiary></indexterm>
<screen>
&rootprompt; net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24get
&rootprompt; getent group Engineers
@@ -379,6 +462,7 @@ MIDEARTH\ajt
In this example the members of the Windows <constant>Domain Users</constant> account are validated using
the <command>net rpc group</command> utility. Note the this contents of the UNIX/Linux group was shown
four paragraphs earlier. The Windows (domain) group membership is shown here:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group members</tertiary></indexterm>
<screen>
&rootprompt; net rpc group members "Domain Users" -Uroot%not24get
MIDEARTH\jht
@@ -459,6 +543,7 @@ DOM\jht
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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group addmem</tertiary></indexterm>
<screen>
&rootprompt; net rpc group addmem "Administrators" "Domain Users" \
-S WINPC032 -Uadministrator%secret
@@ -476,6 +561,9 @@ DOM\jht
<step><para>
Create the script shown in <link linkend="autopoweruserscript"></link> and locate it in
the directory <filename>/etc/samba/scripts</filename>, named as <filename>autopoweruser.sh</filename>.
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group addmem</tertiary></indexterm>
+<indexterm><primary>autopoweruser.sh</primary></indexterm>
+<indexterm><primary>/etc/samba/scripts</primary></indexterm>
</para></step>
<example id="autopoweruserscript">
@@ -540,6 +628,14 @@ exit 0
<title>UNIX and Windows User Management</title>
<para>
+<indexterm><primary>user account</primary></indexterm>
+<indexterm><primary>UNIX/Linux user account</primary></indexterm>
+<indexterm><primary>UID</primary></indexterm>
+<indexterm><primary>POSIX account</primary></indexterm>
+<indexterm><primary>range</primary></indexterm>
+<indexterm><primary>Windows user accounts</primary></indexterm>
+<indexterm><primary>winbindd</primary></indexterm>
+<indexterm><primary>account information</primary></indexterm>
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
@@ -572,6 +668,8 @@ net rpc password &lt;username&gt; [&lt;password&gt;] -Uadmin_username%admin_pass
<para>
The following demonstrates the addition of an account to the server <constant>FRODO</constant>:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user add</tertiary></indexterm>
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user password</tertiary></indexterm>
<screen>
&rootprompt; net rpc user add jacko -S FRODO -Uroot%not24get
Added user jacko
@@ -595,6 +693,7 @@ Added user jacko
net [&lt;method&gt;] user DELETE &lt;name&gt; [misc. options] [targets]
</screen>
The following command will delete the user account <constant>jacko</constant>:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user delete</tertiary></indexterm>
<screen>
&rootprompt; net rpc user delete jacko -Uroot%not24get
Deleted user account
@@ -614,6 +713,7 @@ Deleted user account
<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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user info</tertiary></indexterm>
<screen>
&rootprompt; net rpc user info jacko -S SAURON -Uroot%not24get
net rpc user info jacko -S SAURON -Uroot%not24get
@@ -632,6 +732,9 @@ Emergency Services
<title>User Mapping</title>
<para>
+<indexterm><primary>logon name</primary></indexterm>
+<indexterm><primary>/etc/samba/smbusers</primary></indexterm>
+<indexterm><primary>username map</primary></indexterm>
In some situations it is unavoidable that a user's 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;
@@ -657,6 +760,11 @@ marygee: geeringm
<title>Administering User Rights and Privileges</title>
<para>
+<indexterm><primary>credentials</primary></indexterm>
+<indexterm><primary>manage printers</primary></indexterm>
+<indexterm><primary>manage shares</primary></indexterm>
+<indexterm><primary>manage groups</primary></indexterm>
+<indexterm><primary>manage users</primary></indexterm>
With all versions of Samba earlier than 3.0.11 the only account on a Samba server that could
manage users, groups, shares, printers, and such was the <constant>root</constant> account. This caused
problems for some users and was a frequent source of scorn over the necessity to hand out the
@@ -664,6 +772,11 @@ marygee: geeringm
</para>
<para>
+<indexterm><primary>delegate administrative privileges</primary></indexterm>
+<indexterm><primary>normal user</primary></indexterm>
+<indexterm><primary>rights and privilege</primary></indexterm>
+<indexterm><primary>privilege management</primary></indexterm>
+<indexterm><primary>groups of users</primary></indexterm>
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
@@ -705,6 +818,15 @@ No privileges assigned
<para>
The <command>net</command> command can be used to obtain the currently supported capabilities for rights
and privileges using this method:
+<indexterm><primary>SeMachineAccountPrivilege</primary></indexterm>
+<indexterm><primary>SePrintOperatorPrivilege</primary></indexterm>
+<indexterm><primary>SeAddUsersPrivilege</primary></indexterm>
+<indexterm><primary>SeRemoteShutdownPrivilege</primary></indexterm>
+<indexterm><primary>SeDiskOperatorPrivilege</primary></indexterm>
+<indexterm><primary>SeBackupPrivilege</primary></indexterm>
+<indexterm><primary>SeRestorePrivilege</primary></indexterm>
+<indexterm><primary>SeTakeOwnershipPrivilege</primary></indexterm>
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>rights list</tertiary></indexterm>
<screen>
&rootprompt; net rpc rights list -U root%not24get
SeMachineAccountPrivilege Add machines to domain
@@ -712,6 +834,9 @@ No privileges assigned
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
</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
@@ -719,9 +844,49 @@ No privileges assigned
</para>
<para>
+ For reference purposes, a Windows 2000 Domain Controller reports that it supports the following
+ privileges:
+<screen>
+ SeCreateTokenPrivilege Create a token object
+ SeAssignPrimaryTokenPrivilege Replace a process level token
+ SeLockMemoryPrivilege Lock pages in memory
+ SeIncreaseQuotaPrivilege Increase quotas
+ SeMachineAccountPrivilege Add workstations to domain
+ SeTcbPrivilege Act as part of the operating system
+ SeSecurityPrivilege Manage auditing and security log
+ SeTakeOwnershipPrivilege Take ownership of files or other objects
+ SeLoadDriverPrivilege Load and unload device drivers
+ SeSystemProfilePrivilege Profile system performance
+ SeSystemtimePrivilege Change the system time
+SeProfileSingleProcessPrivilege Profile single process
+SeIncreaseBasePriorityPrivilege Increase scheduling priority
+ SeCreatePagefilePrivilege Create a pagefile
+ SeCreatePermanentPrivilege Create permanent shared objects
+ SeBackupPrivilege Back up files and directories
+ SeRestorePrivilege Restore files and directories
+ SeShutdownPrivilege Shut down the system
+ SeDebugPrivilege Debug programs
+ SeAuditPrivilege Generate security audits
+ SeSystemEnvironmentPrivilege Modify firmware environment values
+ SeChangeNotifyPrivilege Bypass traverse checking
+ SeRemoteShutdownPrivilege Force shutdown from a remote system
+ SeUndockPrivilege Remove computer from docking station
+ SeSyncAgentPrivilege Synchronize directory service data
+ SeEnableDelegationPrivilege Enable computer and user accounts to
+ be trusted for delegation
+ SeManageVolumePrivilege Perform volume maintenance tasks
+ SeImpersonatePrivilege Impersonate a client after authentication
+ SeCreateGlobalPrivilege Create global objects
+</screen>
+ The Samba Team are implementing only those privileges that are logical and useful in the UNIX/Linux
+ envronment. Many of the Windows 200X/XP privileges have no direct equivalence in UNIX.
+ </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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>rights grant</tertiary></indexterm>
<screen>
&rootprompt; net rpc rights grant "MIDEARTH\Domain Admins" \
SeMachineAccountPrivilege SePrintOperatorPrivilege \
@@ -742,6 +907,7 @@ Successfully granted rights.
<para>
The following step permits validation of the changes just made:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>rights list accounts</tertiary></indexterm>
<screen>
&rootprompt; net rpc rights list accounts -U root%not24get
MIDEARTH\jht
@@ -794,6 +960,7 @@ SeDiskOperatorPrivilege
<para>
A Samba server domain trust account can be validated as shown in this example:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>testjoin</tertiary></indexterm>
<screen>
&rootprompt; net rpc testjoin
Join to 'MIDEARTH' is OK
@@ -808,6 +975,7 @@ Join to domain 'WORLDOCEAN' is not valid
<para>
The equivalent command for joining a Samba server to a Windows ADS domain is shown here:
+<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>testjoin</tertiary></indexterm>
<screen>
&rootprompt; net ads testjoin
Using short domain name -- TAKEAWAY
@@ -824,6 +992,7 @@ Join to domain is not valid
<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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
<screen>
&rootprompt; net rpc join -S FRODO -Uroot%not24get
Joined domain MIDEARTH.
@@ -838,6 +1007,7 @@ merlin$:1009:9B4489D6B90461FD6A3EC3AB96147E16:\
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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join member</tertiary></indexterm>
<screen>
&rootprompt; net rpc join member -S FRODO -Uroot%not24get
Joined domain MIDEARTH.
@@ -845,6 +1015,7 @@ Joined domain MIDEARTH.
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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join bdc</tertiary></indexterm>
<screen>
&rootprompt; net rpc join bdc -S FRODO -Uroot%not24get
Joined domain MIDEARTH.
@@ -854,6 +1025,7 @@ Joined domain MIDEARTH.
<para>
The command to join a Samba server to a Windows ADS domain is shown here:
+<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>join</tertiary></indexterm>
<screen>
&rootprompt; net ads join -UAdministrator%not24get
Using short domain name -- GDANSK
@@ -866,6 +1038,7 @@ Joined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ'
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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user delete</tertiary></indexterm>
<screen>
&rootprompt; net rpc user delete HERRING\$ -Uroot%not24get
Deleted user account.
@@ -877,6 +1050,7 @@ Deleted user account.
<para>
A Samba-3 server that is a Windows ADS domain member can execute the following command to detach from the
domain:
+<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>leave</tertiary></indexterm>
<screen>
&rootprompt; net ads leave
</screen>
@@ -885,12 +1059,13 @@ Deleted user account.
<para>
Detailed information regarding an ADS domain can be obtained by a Samba DMS machine by executing the
following:
+<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>status</tertiary></indexterm>
<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 online from
-the <ulink url="http://www.samba.org/samba/docs/Samba3-ByExample.pdf">Samba-3 by Example</ulink>.
+ Chapter 7 for more information regarding its use. This book may be obtained either in print or online from
+ the <ulink url="http://www.samba.org/samba/docs/Samba3-ByExample.pdf">Samba-3 by Example</ulink>.
</para>
</sect2>
@@ -905,6 +1080,7 @@ the <ulink url="http://www.samba.org/samba/docs/Samba3-ByExample.pdf">Samba-3 by
<para>
To discover what trust relationships are in effect, execute this command:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom list</tertiary></indexterm>
<screen>
&rootprompt; net rpc trustdom list -Uroot%not24get
Trusted domains list:
@@ -922,13 +1098,14 @@ none
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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom add</tertiary></indexterm>
<screen>
-&rootprompt; net rpc trustdom add damnation f00db4r -Uroot%not24get
+&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: \
+&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.
@@ -936,6 +1113,7 @@ damnation$:1016:9AC1F121DF897688AAD3B435B51404EE: \
<para>
If the trusting domain is not capable of being reached, the following command will fail:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom list</tertiary></indexterm>
<screen>
&rootprompt; net rpc trustdom list -Uroot%not24get
Trusted domains list:
@@ -963,8 +1141,9 @@ DAMNATION domain controller is not responding
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 joining the trust relationship:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom establish</tertiary></indexterm>
<screen>
-&rootprompt; net rpc trustdom establish damnation
+&rootprompt; net rpc trustdom establish DAMNATION
Password: xxxxxxx == f00db4r
Could not connect to server TRANSGRESSION
Trust to domain DAMNATION established
@@ -985,13 +1164,14 @@ DAMNATION S-1-5-21-1385457007-882775198-1210191635
<para>
Sometimes it is necessary to remove the ability for local users to access a foreign domain. The trusting
connection can be revoked as shown here:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom revoke</tertiary></indexterm>
<screen>
-&rootprompt; net rpc trustdom revoke damnation -Uroot%not24get
+&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
+&rootprompt; net rpc trustdom del DAMNATION -Uroot%not24get
</screen>
</para>
@@ -1004,6 +1184,11 @@ DAMNATION S-1-5-21-1385457007-882775198-1210191635
<title>Managing Security Identifiers (SIDS)</title>
<para>
+<indexterm><primary>security identifier</primary></indexterm>
+<indexterm><primary>SID</primary></indexterm>
+<indexterm><primary>desktop profiles</primary></indexterm>
+<indexterm><primary>user encoded</primary></indexterm>
+<indexterm><primary>group SID</primary></indexterm>
The basic security identifier that is used by 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
@@ -1011,6 +1196,10 @@ DAMNATION S-1-5-21-1385457007-882775198-1210191635
</para>
<para>
+<indexterm><primary>machine SID</primary></indexterm>
+<indexterm><primary>domain SID</primary></indexterm>
+<indexterm><primary>SID</primary></indexterm>
+<indexterm><primary>rejoin</primary></indexterm>
It is truly prudent to store the machine and/or domain SID in a file for safekeeping. 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
@@ -1020,6 +1209,7 @@ DAMNATION S-1-5-21-1385457007-882775198-1210191635
<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:
+<indexterm><primary>net</primary><secondary>getlocalsid</secondary></indexterm>
<screen>
&rootprompt; net getlocalsid > /etc/samba/my-sid
</screen>
@@ -1039,6 +1229,7 @@ SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429
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:
+<indexterm><primary>net</primary><secondary>setlocalsid</secondary></indexterm>
<screen>
&rootprompt; net setlocalsid S-1-5-21-1385457007-882775198-1210191635
</screen>
@@ -1051,6 +1242,7 @@ SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429
DMS and workstation clients should have their own machine SID to avoid
any potential namespace 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):
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>getsid</tertiary></indexterm>
<screen>
&rootprompt; net rpc getsid -S FRODO -Uroot%not24get
Storing SID S-1-5-21-726309263-4128913605-1168186429 \
@@ -1099,6 +1291,7 @@ Storing SID S-1-5-21-726309263-4128913605-1168186429 \
utility. In the first step a share called <constant>Bulge</constant> is added. The sharepoint 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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share add</tertiary></indexterm>
<screen>
&rootprompt; net rpc share add Bulge=/data -S MERLIN -Uroot%not24get
</screen>
@@ -1121,6 +1314,7 @@ ADMIN$
<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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share delete</tertiary></indexterm>
<screen>
&rootprompt; net rpc share delete Bulge -S MERLIN -Uroot%not24get
</screen>
@@ -1160,6 +1354,7 @@ kyocera
<title>Share, Directory, and File Migration</title>
<para>
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>vampire</tertiary></indexterm>
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
@@ -1250,6 +1445,7 @@ net rpc share MIGRATE SHARES &lt;share-name&gt; -S &lt;source&gt;
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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share migrate</tertiary></indexterm>
<screen>
&rootprompt; net rpc share migrate shares myshare\
-S win2k -U administrator%secret"
@@ -1262,6 +1458,7 @@ net rpc share MIGRATE SHARES &lt;share-name&gt; -S &lt;source&gt;
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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>right list accounts</tertiary></indexterm>
<screen>
&rootprompt; net rpc right list accounts -Uroot%not24get
</screen>
@@ -1340,6 +1537,7 @@ net rpc share MIGRATE FILES &lt;share-name&gt; -S &lt;source&gt;
<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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share migrate files</tertiary></indexterm>
<screen>
&rootprompt; net rpc share migrate files -S nt4box --acls \
--attrs -U administrator%secret
@@ -1368,6 +1566,7 @@ net rpc share MIGRATE ALL &lt;share-name&gt; -S &lt;source&gt;
<para>
An example of simultaneous migration is shown here:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share migrate all</tertiary></indexterm>
<screen>
&rootprompt; net rpc share migrate all -S w2k3server -U administrator%secret
</screen>
@@ -1440,24 +1639,29 @@ net rpc share MIGRATE ALL &lt;share-name&gt; -S &lt;source&gt;
<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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate printers</tertiary></indexterm>
<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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate drivers</tertiary></indexterm>
<screen>
net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]
</screen>
Printer forms can be migrated with the following operation:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate forms</tertiary></indexterm>
<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:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate security</tertiary></indexterm>
<screen>
net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]
</screen>
Printer configuration settings include factors such as paper size and default paper orientation.
These can be migrated from the Windows print server to the Samba server with this command:
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate settings</tertiary></indexterm>
<screen>
net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]
</screen>
@@ -1492,6 +1696,7 @@ net rpc printer MIGRATE ALL [printer] [misc. options] [targets]
<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:
+<indexterm><primary>net</primary><secondary>rap</secondary><tertiary>session</tertiary></indexterm>
<screen>
&rootprompt; net rap session -S MERLIN -Uroot%not24get
Computer User name Client Type Opens Idle time
@@ -1519,6 +1724,7 @@ Computer User name Client Type Opens Idle time
When Samba-3 is used within an 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 may be obtained
from the ADS server by executing the <command>net ads print info</command> command following this syntax:
+<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>printer info</tertiary></indexterm>
<screen>
net ads printer info &lt;printer_name&gt; &lt;server_name&gt; -Uadministrator%secret
</screen>
@@ -1528,6 +1734,7 @@ net ads printer info &lt;printer_name&gt; &lt;server_name&gt; -Uadministrator%se
<para>
To publish (make available) a printer to ADS, execute the following command:
+<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>printer publish</tertiary></indexterm>
<screen>
net ads printer publish &lt;printer_name&gt; -Uadministrator%secret
</screen>
@@ -1536,6 +1743,7 @@ net ads printer publish &lt;printer_name&gt; -Uadministrator%secret
<para>
Removal of a Samba printer from ADS is achieved by executing this command:
+<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>printer remove</tertiary></indexterm>
<screen>
net ads printer remove &lt;printer_name&gt; -Uadministrator%secret
</screen>
@@ -1543,6 +1751,7 @@ net ads printer remove &lt;printer_name&gt; -Uadministrator%secret
<para>
A generic search (query) can also be made to locate a printer across the entire ADS domain by executing:
+<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>printer search</tertiary></indexterm>
<screen>
net ads printer search &lt;printer_name&gt; -Uadministrator%secret
</screen>
@@ -1565,6 +1774,7 @@ net ads printer search &lt;printer_name&gt; -Uadministrator%secret
<para>
The following command is useful for obtaining basic statistics regarding a Samba domain. This command does
not work with current Windows XP Professional clients.
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>info</tertiary></indexterm>
<screen>
&rootprompt; net rpc info
Domain Name: RAPIDFLY
@@ -1579,6 +1789,7 @@ Num local groups: 6
<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:
+<indexterm><primary>net</primary><secondary>time</secondary></indexterm>
<screen>
&rootprompt; net time -S SAURON
Tue May 17 00:50:43 2005
@@ -1586,16 +1797,19 @@ Tue May 17 00:50:43 2005
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:
+<indexterm><primary>net</primary><secondary>time</secondary><tertiary>system</tertiary></indexterm>
<screen>
&rootprompt; net time system -S FRODO
051700532005.16
</screen>
The time can be set on a target server by executing:
+<indexterm><primary>net</primary><secondary>time</secondary><tertiary>set</tertiary></indexterm>
<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 of a server by executing the following command against it:
+<indexterm><primary>net</primary><secondary>time</secondary><tertiary>zone</tertiary></indexterm>
<screen>
&rootprompt; net time zone -S SAURON
-0600