source: branches/samba-3.0/docs/htmldocs/Samba3-HOWTO/NetCommand.html

Last change on this file was 311, checked in by Herwig Bauernfeind, 16 years ago

Update 3.0 to final 3.0.36 (docs)
File size: 90.0 KB
Line 
1<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 13. Remote and Local Management: The Net Command</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" href="index.html" title="The Official Samba 3.0.x HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="prev" href="groupmapping.html" title="Chapter 12. Group Mapping: MS Windows and UNIX"><link rel="next" href="idmapper.html" title="Chapter 14. Identity Mapping (IDMAP)"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 13. Remote and Local Management: The Net Command</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="idmapper.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="NetCommand"></a>Chapter 13. Remote and Local Management: The Net Command</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="orgname">Samba Team</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:jht@samba.org">jht@samba.org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Volker</span> <span class="orgname">Samba Team</span> <span class="surname">Lendecke</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:Volker.Lendecke@SerNet.DE">Volker.Lendecke@SerNet.DE</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Guenther</span> <span class="orgname">SuSE</span> <span class="surname">Deschner</span></h3><div class="affiliation"><span class="orgname">SuSE<br></span><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:gd@suse.de">gd@suse.de</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">May 9, 2005</p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="NetCommand.html#id2599013">Overview</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id2599312">Administrative Tasks and Methods</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id2599393">UNIX and Windows Group Management</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#id2599551">Adding, Renaming, or Deletion of Group Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#grpmemshipchg">Manipulating Group Memberships</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#nestedgrpmgmgt">Nested Group Support</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#id2600921">UNIX and Windows User Management</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#sbeuseraddn">Adding User Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id2601132">Deletion of User Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id2601181">Managing User Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id2601249">User Mapping</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#id2601332">Administering User Rights and Privileges</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id2601678">Managing Trust Relationships</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#id2601693">Machine Trust Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id2602062">Interdomain Trusts</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#id2602295">Managing Security Identifiers (SIDS)</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id2602524">Share Management</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#id2602569">Creating, Editing, and Removing Shares</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id2602757">Creating and Changing Share ACLs</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id2602787">Share, Directory, and File Migration</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id2603410">Printer Migration</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#id2603660">Controlling Open Files</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id2603680">Session and Connection Management</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id2603745">Printers and ADS</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id2603861">Manipulating the Samba Cache</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id2603879">Managing IDMAP UID/SID Mappings</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#id2603923">Creating an IDMAP Database Dump File</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id2603958">Restoring the IDMAP Database Dump File</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#netmisc1">Other Miscellaneous Operations</a></span></dt></dl></div><p>
2<a class="indexterm" name="id2598875"></a>
3<a class="indexterm" name="id2598881"></a>
4<a class="indexterm" name="id2598888"></a>
5<a class="indexterm" name="id2598895"></a>
6The <code class="literal">net</code> command is one of the new features of Samba-3 and is an attempt to provide a useful
7tool for the majority of remote management operations necessary for common tasks. The <code class="literal">net</code>
8tool is flexible by design and is intended for command-line use as well as for scripted control application.
9</p><p>
10<a class="indexterm" name="id2598921"></a>
11<a class="indexterm" name="id2598928"></a>
12<a class="indexterm" name="id2598935"></a>
13<a class="indexterm" name="id2598942"></a>
14Originally introduced with the intent to mimic the Microsoft Windows command that has the same name, the
15<code class="literal">net</code> command has morphed into a very powerful instrument that has become an essential part
16of the Samba network administrator's toolbox. The Samba Team has introduced tools, such as
17<code class="literal">smbgroupedit</code> and <code class="literal">rpcclient</code>, from which really useful capabilities have
18been integrated into the <code class="literal">net</code>. The <code class="literal">smbgroupedit</code> command was absorbed
19entirely into the <code class="literal">net</code>, while only some features of the <code class="literal">rpcclient</code> command
20have been ported to it. Anyone who finds older references to these utilities and to the functionality they
21provided should look at the <code class="literal">net</code> command before searching elsewhere.
22</p><p>
23A Samba-3 administrator cannot afford to gloss over this chapter because to do so will almost certainly cause
24the infliction of self-induced pain, agony, and desperation. Be warned: this is an important chapter.
25</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2599013"></a>Overview</h2></div></div></div><p>
26<a class="indexterm" name="id2599021"></a>
27<a class="indexterm" name="id2599028"></a>
28<a class="indexterm" name="id2599035"></a>
29<a class="indexterm" name="id2599041"></a>
30<a class="indexterm" name="id2599048"></a>
31<a class="indexterm" name="id2599054"></a>
32 The tasks that follow the installation of a Samba-3 server, whether standalone or domain member, of a
33 domain controller (PDC or BDC) begins with the need to create administrative rights. Of course, the
34 creation of user and group accounts is essential for both a standalone server and a PDC.
35 In the case of a BDC or a Domain Member server (DMS), domain user and group accounts are obtained from
36 the central domain authentication backend.
37 </p><p>
38<a class="indexterm" name="id2599072"></a>
39<a class="indexterm" name="id2599079"></a>
40<a class="indexterm" name="id2599086"></a>
41<a class="indexterm" name="id2599093"></a>
42<a class="indexterm" name="id2599100"></a>
43<a class="indexterm" name="id2599106"></a>
44<a class="indexterm" name="id2599113"></a>
45<a class="indexterm" name="id2599120"></a>
46 Regardless of the type of server being installed, local UNIX groups must be mapped to the Windows
47 networking domain global group accounts. Do you ask why? Because Samba always limits its access to
48 the resources of the host server by way of traditional UNIX UID and GID controls. This means that local
49 groups must be mapped to domain global groups so that domain users who are members of the domain
50 global groups can be given access rights based on UIDs and GIDs local to the server that is hosting
51 Samba. Such mappings are implemented using the <code class="literal">net</code> command.
52 </p><p>
53<a class="indexterm" name="id2599144"></a>
54<a class="indexterm" name="id2599151"></a>
55<a class="indexterm" name="id2599158"></a>
56<a class="indexterm" name="id2599164"></a>
57<a class="indexterm" name="id2599171"></a>
58<a class="indexterm" name="id2599178"></a>
59<a class="indexterm" name="id2599185"></a>
60 UNIX systems that are hosting a Samba-3 server that is running as a member (PDC, BDC, or DMS) must have
61 a machine security account in the domain authentication database (or directory). The creation of such
62 security (or trust) accounts is also handled using the <code class="literal">net</code> command.
63 </p><p>
64<a class="indexterm" name="id2599209"></a>
65<a class="indexterm" name="id2599216"></a>
66<a class="indexterm" name="id2599223"></a>
67<a class="indexterm" name="id2599230"></a>
68<a class="indexterm" name="id2599237"></a>
69<a class="indexterm" name="id2599244"></a>
70<a class="indexterm" name="id2599251"></a>
71<a class="indexterm" name="id2599258"></a>
72<a class="indexterm" name="id2599265"></a>
73 The establishment of interdomain trusts is achieved using the <code class="literal">net</code> command also, as
74 may a plethora of typical administrative duties such as user management, group management, share and
75 printer management, file and printer migration, security identifier management, and so on.
76 </p><p>
77<a class="indexterm" name="id2599285"></a>
78<a class="indexterm" name="id2599292"></a>
79 The overall picture should be clear now: the <code class="literal">net</code> command plays a central role
80 on the Samba-3 stage. This role will continue to be developed. The inclusion of this chapter is
81 evidence of its importance, one that has grown in complexity to the point that it is no longer considered
82 prudent to cover its use fully in the online UNIX man pages.
83 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2599312"></a>Administrative Tasks and Methods</h2></div></div></div><p>
84<a class="indexterm" name="id2599320"></a>
85<a class="indexterm" name="id2599327"></a>
86<a class="indexterm" name="id2599333"></a>
87<a class="indexterm" name="id2599343"></a>
88 The basic operations of the <code class="literal">net</code> command are documented here. This documentation is not
89 exhaustive, and thus it is incomplete. Since the primary focus is on migration from Windows servers to a Samba
90 server, the emphasis is on the use of the Distributed Computing Environment Remote Procedure Call (DCE RPC)
91 mode of operation. When used against a server that is a member of an Active Directory domain, it is preferable
92 (and often necessary) to use ADS mode operations. The <code class="literal">net</code> command supports both, but not
93 for every operation. For most operations, if the mode is not specified, <code class="literal">net</code> will
94 automatically fall back via the <code class="constant">ads</code>, <code class="constant">rpc</code>, and
95 <code class="constant">rap</code> modes. Please refer to the man page for a more comprehensive overview of the
96 capabilities of this utility.
97 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2599393"></a>UNIX and Windows Group Management</h2></div></div></div><p>
98<a class="indexterm" name="id2599401"></a>
99<a class="indexterm" name="id2599408"></a>
100<a class="indexterm" name="id2599417"></a>
101<a class="indexterm" name="id2599426"></a>
102<a class="indexterm" name="id2599434"></a>
103 As stated, the focus in most of this chapter is on use of the <code class="literal">net rpc</code> family of
104 operations that are supported by Samba. Most of them are supported by the <code class="literal">net ads</code>
105 mode when used in connection with Active Directory. The <code class="literal">net rap</code> operating mode is
106 also supported for some of these operations. RAP protocols are used by IBM OS/2 and by several
107 earlier SMB servers.
108 </p><p>
109<a class="indexterm" name="id2599467"></a>
110<a class="indexterm" name="id2599474"></a>
111<a class="indexterm" name="id2599481"></a>
112 Samba's <code class="literal">net</code> tool implements sufficient capability to permit all common administrative
113 tasks to be completed from the command line. In this section each of the essential user and group management
114 facilities are explored.
115 </p><p>
116<a class="indexterm" name="id2599500"></a>
117<a class="indexterm" name="id2599507"></a>
118<a class="indexterm" name="id2599516"></a>
119<a class="indexterm" name="id2599526"></a>
120 Samba-3 recognizes two types of groups: <span class="emphasis"><em>domain groups</em></span> and <span class="emphasis"><em>local
121 groups</em></span>. Domain groups can contain (have as members) only domain user accounts. Local groups
122 can contain local users, domain users, and domain groups as members.
123 </p><p>
124 The purpose of a local group is to permit file permission to be set for a group account that, like the
125 usual UNIX/Linux group, is persistent across redeployment of a Windows file server.
126 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2599551"></a>Adding, Renaming, or Deletion of Group Accounts</h3></div></div></div><p>
127 Samba provides file and print services to Windows clients. The file system resources it makes available
128 to the Windows environment must, of necessity, be provided in a manner that is compatible with the
129 Windows networking environment. UNIX groups are created and deleted as required to serve operational
130 needs in the UNIX operating system and its file systems.
131 </p><p>
132 In order to make available to the Windows environment, Samba has a facility by which UNIX groups can
133 be mapped to a logical entity, called a Windows (or domain) group. Samba supports two types of Windows
134 groups, local and global. Global groups can contain as members, global users. This membership is
135 affected in the normal UNIX manner, but adding UNIX users to UNIX groups. Windows user accounts consist
136 of a mapping between a user SambaSAMAccount (logical entity) and a UNIX user account. Therefore,
137 a UNIX user is mapped to a Windows user (i.e., is given a Windows user account and password) and the
138 UNIX groups to which that user belongs, is mapped to a Windows group account. The result is that in
139 the Windows account environment that user is also a member of the Windows group account by virtue
140 of UNIX group memberships.
141 </p><p>
142 The following sub-sections that deal with management of Windows groups demonstrates the relationship
143 between the UNIX group account and its members to the respective Windows group accounts. It goes on to
144 show how UNIX group members automatically pass-through to Windows group membership as soon as a logical
145 mapping has been created.
146 </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2599594"></a>Adding or Creating a New Group</h4></div></div></div><p>
147 Before attempting to add a Windows group account, the currently available groups can be listed as shown
148 here:
149<a class="indexterm" name="id2599604"></a>
150<a class="indexterm" name="id2599615"></a>
151</p><pre class="screen">
152<code class="prompt">root# </code> net rpc group list -Uroot%not24get
153Password:
154Domain Admins
155Domain Users
156Domain Guests
157Print Operators
158Backup Operators
159Replicator
160Domain Computers
161Engineers
162</pre><p>
163 </p><p>
164 A Windows group account called &#8220;<span class="quote">SupportEngrs</span>&#8221; can be added by executing the following
165command:
166<a class="indexterm" name="id2599651"></a>
167</p><pre class="screen">
168<code class="prompt">root# </code> net rpc group add "SupportEngrs" -Uroot%not24get
169</pre><p>
170 The addition will result in immediate availability of the new group account as validated by executing
171this command:
172</p><pre class="screen">
173<code class="prompt">root# </code> net rpc group list -Uroot%not24get
174Password:
175Domain Admins
176Domain Users
177Domain Guests
178Print Operators
179Backup Operators
180Replicator
181Domain Computers
182Engineers
183SupportEngrs
184</pre><p>
185 </p><p>
186<a class="indexterm" name="id2599694"></a>
187<a class="indexterm" name="id2599700"></a>
188<a class="indexterm" name="id2599707"></a>
189 The following demonstrates that the POSIX (UNIX/Linux system account) group has been created by calling
190 the <a class="link" href="smb.conf.5.html#ADDGROUPSCRIPT" target="_top">add group script = /opt/IDEALX/sbin/smbldap-groupadd -p "%g"</a> interface
191 script:
192</p><pre class="screen">
193<code class="prompt">root# </code> getent group
194...
195Domain Admins:x:512:root
196Domain Users:x:513:jht,lct,ajt,met
197Domain Guests:x:514:
198Print Operators:x:550:
199Backup Operators:x:551:
200Replicator:x:552:
201Domain Computers:x:553:
202Engineers:x:1002:jht
203SupportEngrs:x:1003:
204</pre><p>
205 The following demonstrates that the use of the <code class="literal">net</code> command to add a group account
206results in immediate mapping of the POSIX group that has been created to the Windows group account as shown
207here:
208<a class="indexterm" name="id2599754"></a>
209</p><pre class="screen">
210<code class="prompt">root# </code> net groupmap list
211Domain Admins (S-1-5-21-72630-4128915-11681869-512) -&gt; Domain Admins
212Domain Users (S-1-5-21-72630-4128915-11681869-513) -&gt; Domain Users
213Domain Guests (S-1-5-21-72630-4128915-11681869-514) -&gt; Domain Guests
214Print Operators (S-1-5-21-72630-4128915-11681869-550) -&gt; Print Operators
215Backup Operators (S-1-5-21-72630-4128915-11681869-551) -&gt; Backup Operators
216Replicator (S-1-5-21-72630-4128915-11681869-552) -&gt; Replicator
217Domain Computers (S-1-5-21-72630-4128915-11681869-553) -&gt; Domain Computers
218Engineers (S-1-5-21-72630-4128915-11681869-3005) -&gt; Engineers
219SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -&gt; SupportEngrs
220</pre><p>
221 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2599795"></a>Mapping Windows Groups to UNIX Groups</h4></div></div></div><p>
222<a class="indexterm" name="id2599803"></a>
223<a class="indexterm" name="id2599810"></a>
224<a class="indexterm" name="id2599816"></a>
225<a class="indexterm" name="id2599823"></a>
226 Windows groups must be mapped to UNIX system (POSIX) groups so that file system access controls
227 can be asserted in a manner that is consistent with the methods appropriate to the operating
228 system that is hosting the Samba server.
229 </p><p>
230<a class="indexterm" name="id2599838"></a>
231<a class="indexterm" name="id2599844"></a>
232<a class="indexterm" name="id2599851"></a>
233<a class="indexterm" name="id2599858"></a>
234 All file system (file and directory) access controls, within the file system of a UNIX/Linux server that is
235 hosting a Samba server, are implemented using a UID/GID identity tuple. Samba does not in any way override
236 or replace UNIX file system semantics. Thus it is necessary that all Windows networking operations that
237 access the file system provide a mechanism that maps a Windows user to a particular UNIX/Linux group
238 account. The user account must also map to a locally known UID. Note that the <code class="literal">net</code>
239 command does not call any RPC-functions here but directly accesses the passdb.
240 </p><p>
241<a class="indexterm" name="id2599883"></a>
242<a class="indexterm" name="id2599890"></a>
243<a class="indexterm" name="id2599897"></a>
244<a class="indexterm" name="id2599904"></a>
245<a class="indexterm" name="id2599911"></a>
246<a class="indexterm" name="id2599918"></a>
247<a class="indexterm" name="id2599925"></a>
248 Samba depends on default mappings for the <code class="constant">Domain Admins, Domain Users</code>, and
249 <code class="constant">Domain Guests</code> global groups. Additional groups may be added as shown in the
250 examples just given. There are times when it is necessary to map an existing UNIX group account
251 to a Windows group. This operation, in effect, creates a Windows group account as a consequence
252 of creation of the mapping.
253 </p><p>
254<a class="indexterm" name="id2599948"></a>
255<a class="indexterm" name="id2599959"></a>
256<a class="indexterm" name="id2599970"></a>
257 The operations that are permitted include: <code class="constant">add</code>, <code class="constant">modify</code>,
258 and <code class="constant">delete</code>. An example of each operation is shown here.
259 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
260 Commencing with Samba-3.0.23 Windows Domain Groups must be explicitly created. By default, all
261 UNIX groups are exposed to Windows networking as Windows local groups.
262 </p></div><p>
263 An existing UNIX group may be mapped to an existing Windows group by this example:
264</p><pre class="screen">
265<code class="prompt">root# </code> net groupmap modify ntgroup="Domain Users" unixgroup=users
266</pre><p>
267 An existing UNIX group may be mapped to a new Windows group as shown here:
268</p><pre class="screen">
269<code class="prompt">root# </code> net groupmap add ntgroup="EliteEngrs" unixgroup=Engineers type=d
270</pre><p>
271 Supported mapping types are 'd' (domain global) and 'l' (domain local).
272 A Windows group may be deleted, and then a new Windows group can be mapped to the UNIX group by
273 executing these commands:
274</p><pre class="screen">
275<code class="prompt">root# </code> net groupmap delete ntgroup=Engineers
276<code class="prompt">root# </code> net groupmap add ntgroup=EngineDrivers unixgroup=Engineers type=d
277</pre><p>
278 The deletion and addition operations affected only the logical entities known as Windows groups, or domain
279 groups. These operations are inert to UNIX system groups, meaning that they neither delete nor create UNIX
280 system groups. The mapping of a UNIX group to a Windows group makes the UNIX group available as Windows
281 groups so that files and folders on domain member clients (workstations and servers) can be given
282 domain-wide access controls for domain users and groups.
283 </p><p>
284 Two types of Windows groups can be created: <code class="constant">domain (global)</code> and <code class="constant">local</code>.
285 In the previous examples the Windows groups created were of type <code class="constant">domain</code> or global. The
286 following command will create a Windows group of type <code class="constant">local</code>.
287</p><pre class="screen">
288<code class="prompt">root# </code> net groupmap add ntgroup=Pixies unixgroup=pixies type=l
289</pre><p>
290 Supported mapping types are 'd' (domain global) and 'l' (domain local), a domain local group in Samba is
291 treated as local to the individual Samba server. Local groups can be used with Samba to enable multiple
292 nested group support.
293 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2600103"></a>Deleting a Group Account</h4></div></div></div><p>
294<a class="indexterm" name="id2600111"></a>
295 A group account may be deleted by executing the following command:
296</p><pre class="screen">
297<code class="prompt">root# </code> net rpc group delete SupportEngineers -Uroot%not24get
298</pre><p>
299 </p><p>
300 Validation of the deletion is advisable. The same commands may be executed as shown above.
301 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2600143"></a>Rename Group Accounts</h4></div></div></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
302 This command is not documented in the man pages; it is implemented in the source code, but it does not
303 work at this time. The example given documents, from the source code, how it should work. Watch the
304 release notes of a future release to see when this may have been fixed.
305 </p></div><p>
306 Sometimes it is necessary to rename a group account. Good administrators know how painful some managers'
307 demands can be if this simple request is ignored. The following command demonstrates how the Windows group
308 &#8220;<span class="quote">SupportEngrs</span>&#8221; can be renamed to &#8220;<span class="quote">CustomerSupport</span>&#8221;:
309<a class="indexterm" name="id2600171"></a>
310</p><pre class="screen">
311<code class="prompt">root# </code> net rpc group rename SupportEngrs \
312 CustomerSupport -Uroot%not24get
313</pre><p>
314 </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="grpmemshipchg"></a>Manipulating Group Memberships</h3></div></div></div><p>
315 Three operations can be performed regarding group membership. It is possible to (1) add Windows users
316 to a Windows group, to (2) delete Windows users from Windows groups, and to (3) list the Windows users that are
317 members of a Windows group.
318 </p><p>
319 To avoid confusion, it makes sense to check group membership before attempting to make any changes.
320 The <code class="literal">getent group</code> will list UNIX/Linux group membership. UNIX/Linux group members are
321 seen also as members of a Windows group that has been mapped using the <code class="literal">net groupmap</code>
322 command (see <a class="link" href="groupmapping.html" title="Chapter 12. Group Mapping: MS Windows and UNIX">&#8220;Group Mapping: MS Windows and UNIX&#8221;</a>). The following list of UNIX/Linux group membership shows
323 that the user <code class="constant">ajt</code> is a member of the UNIX/Linux group <code class="constant">Engineers</code>.
324</p><pre class="screen">
325<code class="prompt">root# </code> getent group
326...
327Domain Admins:x:512:root
328Domain Users:x:513:jht,lct,ajt,met,vlendecke
329Domain Guests:x:514:
330Print Operators:x:550:
331Backup Operators:x:551:
332Replicator:x:552:
333Domain Computers:x:553:
334Engineers:x:1000:jht,ajt
335</pre><p>
336 The UNIX/Linux groups have been mapped to Windows groups, as is shown here:
337</p><pre class="screen">
338<code class="prompt">root# </code> net groupmap list
339Domain Admins (S-1-5-21-72630-412605-116429-512) -&gt; Domain Admins
340Domain Users (S-1-5-21-72630-412605-116429-513) -&gt; Domain Users
341Domain Guests (S-1-5-21-72630-412605-116429-514) -&gt; Domain Guests
342Print Operators (S-1-5-21-72630-412605-116429-550) -&gt; Print Operators
343Backup Operators (S-1-5-21-72630-412605-116429-551) -&gt; Backup Operators
344Replicator (S-1-5-21-72630-412605-116429-552) -&gt; Replicator
345Domain Computers (S-1-5-21-72630-412605-116429-553) -&gt; Domain Computers
346Engineers (S-1-5-21-72630-412605-116429-3001) -&gt; Engineers
347</pre><p>
348 </p><p>
349 Given that the user <code class="constant">ajt</code> is already a member of the UNIX/Linux group and, via the
350 group mapping, a member of the Windows group, an attempt to add this account again should fail. This is
351 demonstrated here:
352<a class="indexterm" name="id2600302"></a>
353</p><pre class="screen">
354<code class="prompt">root# </code> net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
355Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP
356</pre><p>
357 This shows that the group mapping between UNIX/Linux groups and Windows groups is effective and
358 transparent.
359 </p><p>
360 To permit the user <code class="constant">ajt</code> to be added using the <code class="literal">net rpc group</code> utility,
361 this account must first be removed. The removal and confirmation of its effect is shown here:
362<a class="indexterm" name="id2600344"></a>
363</p><pre class="screen">
364<code class="prompt">root# </code> net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24get
365<code class="prompt">root# </code> getent group Engineers
366Engineers:x:1000:jht
367<code class="prompt">root# </code> net rpc group members Engineers -Uroot%not24get
368MIDEARTH\jht
369</pre><p>
370 In this example both at the UNIX/Linux system level, the group no longer has the <code class="constant">ajt</code>
371 as a member. The above also shows this to be the case for Windows group membership.
372 </p><p>
373 The account is now added again, using the <code class="literal">net rpc group</code> utility:
374</p><pre class="screen">
375<code class="prompt">root# </code> net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
376<code class="prompt">root# </code> getent group Engineers
377Engineers:x:1000:jht,ajt
378<code class="prompt">root# </code> net rpc group members Engineers -Uroot%not24get
379MIDEARTH\jht
380MIDEARTH\ajt
381</pre><p>
382 </p><p>
383 In this example the members of the Windows <code class="constant">Domain Users</code> account are validated using
384 the <code class="literal">net rpc group</code> utility. Note the this contents of the UNIX/Linux group was shown
385 four paragraphs earlier. The Windows (domain) group membership is shown here:
386<a class="indexterm" name="id2600441"></a>
387</p><pre class="screen">
388<code class="prompt">root# </code> net rpc group members "Domain Users" -Uroot%not24get
389MIDEARTH\jht
390MIDEARTH\lct
391MIDEARTH\ajt
392MIDEARTH\met
393MIDEARTH\vlendecke
394</pre><p>
395 This express example shows that Windows group names are treated by Samba (as with
396 MS Windows) in a case-insensitive manner:
397</p><pre class="screen">
398<code class="prompt">root# </code> net rpc group members "DomAiN USerS" -Uroot%not24get
399MIDEARTH\jht
400MIDEARTH\lct
401MIDEARTH\ajt
402MIDEARTH\met
403MIDEARTH\vlendecke
404</pre><p>
405 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
406 An attempt to specify the group name as <code class="constant">MIDEARTH\Domain Users</code> in place of
407 just simply <code class="constant">Domain Users</code> will fail. The default behavior of the net rpc group
408 is to direct the command at the local machine. The Windows group is treated as being local to the machine.
409 If it is necessary to query another machine, its name can be specified using the <code class="constant">-S
410 servername</code> parameter to the <code class="literal">net</code> command.
411 </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="nestedgrpmgmgt"></a>Nested Group Support</h3></div></div></div><p>
412 It is possible in Windows (and now in Samba also) to create a local group that has members (contains),
413 domain users, and domain global groups. Creation of the local group <code class="constant">demo</code> is
414 achieved by executing:
415</p><pre class="screen">
416<code class="prompt">root# </code> net rpc group add demo -L -S MORDON -Uroot%not24get
417</pre><p>
418 The -L switch means create a local group. Use the -S argument to direct the operation to a particular
419 server. The parameters to the -U argument should be for a user who has appropriate administrative right
420 and privileges on the machine.
421 </p><p>
422 Addition and removal of group members can be achieved using the <code class="constant">addmem</code> and
423 <code class="constant">delmem</code> subcommands of <code class="literal">net rpc group</code> command. For example,
424 addition of &#8220;<span class="quote">DOM\Domain Users</span>&#8221; to the local group <code class="constant">demo</code> would be
425 done by executing:
426</p><pre class="screen">
427<code class="prompt">root# </code> net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get
428</pre><p>
429 </p><p>
430 The members of a nested group can be listed by executing the following:
431</p><pre class="screen">
432<code class="prompt">root# </code> net rpc group members demo -Uroot%not24get
433DOM\Domain Users
434DOM\Engineers
435DOM\jamesf
436DOM\jht
437</pre><p>
438 </p><p>
439 Nested group members can be removed (deleted) as shown here:
440</p><pre class="screen">
441<code class="prompt">root# </code> net rpc group delmem demo "DOM\jht" -Uroot%not24get
442</pre><p>
443 </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2600622"></a>Managing Nest Groups on Workstations from the Samba Server</h4></div></div></div><p>
444 Windows network administrators often ask on the Samba mailing list how it is possible to grant everyone
445 administrative rights on their own workstation. This is of course a very bad practice, but commonly done
446 to avoid user complaints. Here is how it can be done remotely from a Samba PDC or BDC:
447<a class="indexterm" name="id2600636"></a>
448</p><pre class="screen">
449<code class="prompt">root# </code> net rpc group addmem "Administrators" "Domain Users" \
450 -S WINPC032 -Uadministrator%secret
451</pre><p>
452 </p><p>
453 This can be scripted, and can therefore be performed as a user logs onto the domain from a Windows
454 workstation. Here is a simple example that shows how this can be done.
455 </p><div class="procedure"><a name="id2600667"></a><p class="title"><b>Procedure 13.1. Automating User Addition to the Workstation Power Users Group</b></p><div class="example"><a name="autopoweruserscript"></a><p class="title"><b>Example 13.1. Script to Auto-add Domain Users to Workstation Power Users Group</b></p><div class="example-contents"><pre class="screen">
456#!/bin/bash
457
458/usr/bin/net rpc group addmem "Power Users" "DOMAIN_NAME\$1" \
459 -UAdministrator%secret -S $2
460
461exit 0
462</pre></div></div><br class="example-break"><div class="example"><a name="magicnetlogon"></a><p class="title"><b>Example 13.2. A Magic Netlogon Share</b></p><div class="example-contents"><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><em class="parameter"><code>[netlogon]</code></em></td></tr><tr><td><a class="indexterm" name="id2600823"></a><em class="parameter"><code>comment = Netlogon Share</code></em></td></tr><tr><td><a class="indexterm" name="id2600835"></a><em class="parameter"><code>path = /var/lib/samba/netlogon</code></em></td></tr><tr><td><a class="indexterm" name="id2600847"></a><em class="parameter"><code>root preexec = /etc/samba/scripts/autopoweruser.sh %U %m</code></em></td></tr><tr><td><a class="indexterm" name="id2600859"></a><em class="parameter"><code>read only = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id2600870"></a><em class="parameter"><code>guest ok = Yes</code></em></td></tr></table></div></div><br class="example-break"><ol type="1"><li><p>
463 Create the script shown in <a class="link" href="NetCommand.html#autopoweruserscript" title="Example 13.1. Script to Auto-add Domain Users to Workstation Power Users Group">&#8220;Script to Auto-add Domain Users to Workstation Power Users Group&#8221;</a> and locate it in
464 the directory <code class="filename">/etc/samba/scripts</code>, named as <code class="filename">autopoweruser.sh</code>.
465<a class="indexterm" name="id2600699"></a>
466<a class="indexterm" name="id2600710"></a>
467<a class="indexterm" name="id2600717"></a>
468 </p></li><li><p>
469 Set the permissions on this script to permit it to be executed as part of the logon process:
470</p><pre class="screen">
471<code class="prompt">root# </code> chown root:root /etc/samba/autopoweruser.sh
472<code class="prompt">root# </code> chmod 755 /etc/samba/autopoweruser.sh
473</pre><p>
474 </p></li><li><p>
475 Modify the <code class="filename">smb.conf</code> file so the <code class="literal">NETLOGON</code> stanza contains the parameters
476 shown in <a class="link" href="NetCommand.html#magicnetlogon" title="Example 13.2. A Magic Netlogon Share">the Netlogon Example smb.conf file</a>.
477 </p></li><li><p>
478 Ensure that every Windows workstation Administrator account has the same password that you
479 have used in the script shown in <a class="link" href="NetCommand.html#magicnetlogon" title="Example 13.2. A Magic Netlogon Share">the Netlogon Example smb.conf
480 file</a>
481 </p></li></ol></div><p>
482 This script will be executed every time a user logs on to the network. Therefore every user will
483 have local Windows workstation management rights. This could of course be assigned using a group,
484 in which case there is little justification for the use of this procedure. The key justification
485 for the use of this method is that it will guarantee that all users have appropriate rights on
486 the workstation.
487 </p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2600921"></a>UNIX and Windows User Management</h2></div></div></div><p>
488<a class="indexterm" name="id2600929"></a>
489<a class="indexterm" name="id2600936"></a>
490<a class="indexterm" name="id2600943"></a>
491<a class="indexterm" name="id2600949"></a>
492<a class="indexterm" name="id2600956"></a>
493<a class="indexterm" name="id2600963"></a>
494<a class="indexterm" name="id2600970"></a>
495<a class="indexterm" name="id2600977"></a>
496 Every Windows network user account must be translated to a UNIX/Linux user account. In actual fact,
497 the only account information the UNIX/Linux Samba server needs is a UID. The UID is available either
498 from a system (POSIX) account or from a pool (range) of UID numbers that is set aside for the purpose
499 of being allocated for use by Windows user accounts. In the case of the UID pool, the UID for a
500 particular user will be allocated by <code class="literal">winbindd</code>.
501 </p><p>
502 Although this is not the appropriate place to discuss the <a class="link" href="smb.conf.5.html#USERNAMEMAP" target="_top">username map</a> facility,
503 this interface is an important method of mapping a Windows user account to a UNIX account that has a
504 different name. Refer to the man page for the <code class="filename">smb.conf</code> file for more information regarding this
505 facility. User name mappings cannot be managed using the <code class="literal">net</code> utility.
506 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="sbeuseraddn"></a>Adding User Accounts</h3></div></div></div><p>
507 The syntax for adding a user account via the <code class="literal">net</code> (according to the man page) is shown
508 here:
509</p><pre class="screen">
510net [&lt;method&gt;] user ADD &lt;name&gt; [-c container] [-F user flags] \
511 [misc. options] [targets]
512</pre><p>
513 The user account password may be set using this syntax:
514</p><pre class="screen">
515net rpc password &lt;username&gt; [&lt;password&gt;] -Uadmin_username%admin_pass
516</pre><p>
517 </p><p>
518 The following demonstrates the addition of an account to the server <code class="constant">FRODO</code>:
519<a class="indexterm" name="id2601074"></a>
520<a class="indexterm" name="id2601085"></a>
521</p><pre class="screen">
522<code class="prompt">root# </code> net rpc user add jacko -S FRODO -Uroot%not24get
523Added user jacko
524</pre><p>
525 The account password can be set with the following methods (all show the same operation):
526</p><pre class="screen">
527<code class="prompt">root# </code> net rpc password jacko f4sth0rse -S FRODO -Uroot%not24get
528<code class="prompt">root# </code> net rpc user password jacko f4sth0rse \
529 -S FRODO -Uroot%not24get
530</pre><p>
531 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2601132"></a>Deletion of User Accounts</h3></div></div></div><p>
532 Deletion of a user account can be done using the following syntax:
533</p><pre class="screen">
534net [&lt;method&gt;] user DELETE &lt;name&gt; [misc. options] [targets]
535</pre><p>
536 The following command will delete the user account <code class="constant">jacko</code>:
537<a class="indexterm" name="id2601155"></a>
538</p><pre class="screen">
539<code class="prompt">root# </code> net rpc user delete jacko -Uroot%not24get
540Deleted user account
541</pre><p>
542 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2601181"></a>Managing User Accounts</h3></div></div></div><p>
543 Two basic user account operations are routinely used: change of password and querying which groups a user
544 is a member of. The change of password operation is shown in <a class="link" href="NetCommand.html#sbeuseraddn" title="Adding User Accounts">&#8220;Adding User Accounts&#8221;</a>.
545 </p><p>
546 The ability to query Windows group membership can be essential. Here is how a remote server may be
547 interrogated to find which groups a user is a member of:
548<a class="indexterm" name="id2601204"></a>
549</p><pre class="screen">
550<code class="prompt">root# </code> net rpc user info jacko -S SAURON -Uroot%not24get
551net rpc user info jacko -S SAURON -Uroot%not24get
552Domain Users
553Domain Admins
554Engineers
555TorridGroup
556BOP Shop
557Emergency Services
558</pre><p>
559 </p><p>
560 It is also possible to rename user accounts:
561<a class="indexterm" name="id2601233"></a>oldusername newusername
562 Note that this operation does not yet work against Samba Servers. It is, however, possible to rename useraccounts on
563 Windows Servers.
564
565 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2601249"></a>User Mapping</h3></div></div></div><p>
566<a class="indexterm" name="id2601257"></a>
567<a class="indexterm" name="id2601264"></a>
568<a class="indexterm" name="id2601271"></a>
569 In some situations it is unavoidable that a user's Windows logon name will differ from the login ID
570 that user has on the Samba server. It is possible to create a special file on the Samba server that
571 will permit the Windows user name to be mapped to a different UNIX/Linux user name. The <code class="filename">smb.conf</code>
572 file must also be amended so that the <code class="constant">[global]</code> stanza contains the parameter:
573</p><pre class="screen">
574username map = /etc/samba/smbusers
575</pre><p>
576 The content of the <code class="filename">/etc/samba/smbusers</code> file is shown here:
577</p><pre class="screen">
578parsonsw: "William Parsons"
579marygee: geeringm
580</pre><p>
581 In this example the Windows user account &#8220;<span class="quote">William Parsons</span>&#8221; will be mapped to the UNIX user
582 <code class="constant">parsonsw</code>, and the Windows user account &#8220;<span class="quote">geeringm</span>&#8221; will be mapped to the
583 UNIX user <code class="constant">marygee</code>.
584 </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2601332"></a>Administering User Rights and Privileges</h2></div></div></div><p>
585<a class="indexterm" name="id2601341"></a>
586<a class="indexterm" name="id2601348"></a>
587<a class="indexterm" name="id2601354"></a>
588<a class="indexterm" name="id2601361"></a>
589<a class="indexterm" name="id2601368"></a>
590 With all versions of Samba earlier than 3.0.11 the only account on a Samba server that could
591 manage users, groups, shares, printers, and such was the <code class="constant">root</code> account. This caused
592 problems for some users and was a frequent source of scorn over the necessity to hand out the
593 credentials for the most security-sensitive account on a UNIX/Linux system.
594 </p><p>
595<a class="indexterm" name="id2601388"></a>
596<a class="indexterm" name="id2601395"></a>
597<a class="indexterm" name="id2601402"></a>
598<a class="indexterm" name="id2601409"></a>
599<a class="indexterm" name="id2601416"></a>
600 New to Samba version 3.0.11 is the ability to delegate administrative privileges as necessary to either
601 a normal user or to groups of users. The significance of the administrative privileges is documented
602 in <a class="link" href="rights.html" title="Chapter 15. User Rights and Privileges">&#8220;User Rights and Privileges&#8221;</a>. Examples of use of the <code class="literal">net</code> for user rights and privilege
603 management is appropriate to this chapter.
604 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
605 When user rights and privileges are correctly set, there is no longer a need for a Windows
606 network account for the <code class="constant">root</code> user (nor for any synonym of it) with a UNIX UID=0.
607 Initial user rights and privileges can be assigned by any account that is a member of the <code class="constant">
608 Domain Admins</code> group. Rights can be assigned to user as well as group accounts.
609 </p></div><p>
610 By default, no privileges and rights are assigned. This is demonstrated by executing the command
611 shown here:
612</p><pre class="screen">
613<code class="prompt">root# </code> net rpc rights list accounts -U root%not24get
614BUILTIN\Print Operators
615No privileges assigned
616
617BUILTIN\Account Operators
618No privileges assigned
619
620BUILTIN\Backup Operators
621No privileges assigned
622
623BUILTIN\Server Operators
624No privileges assigned
625
626BUILTIN\Administrators
627No privileges assigned
628
629Everyone
630No privileges assigned
631</pre><p>
632 </p><p>
633 The <code class="literal">net</code> command can be used to obtain the currently supported capabilities for rights
634 and privileges using this method:
635<a class="indexterm" name="id2601490"></a>
636<a class="indexterm" name="id2601497"></a>
637<a class="indexterm" name="id2601504"></a>
638<a class="indexterm" name="id2601511"></a>
639<a class="indexterm" name="id2601518"></a>
640<a class="indexterm" name="id2601525"></a>
641<a class="indexterm" name="id2601532"></a>
642<a class="indexterm" name="id2601539"></a>
643<a class="indexterm" name="id2601546"></a>
644</p><pre class="screen">
645<code class="prompt">root# </code> net rpc rights list -U root%not24get
646 SeMachineAccountPrivilege Add machines to domain
647 SePrintOperatorPrivilege Manage printers
648 SeAddUsersPrivilege Add users and groups to the domain
649 SeRemoteShutdownPrivilege Force shutdown from a remote system
650 SeDiskOperatorPrivilege Manage disk shares
651 SeBackupPrivilege Back up files and directories
652 SeRestorePrivilege Restore files and directories
653 SeTakeOwnershipPrivilege Take ownership of files or other objects
654</pre><p>
655 Machine account privilege is necessary to permit a Windows NT4 or later network client to be added to the
656 domain. The disk operator privilege is necessary to permit the user to manage share ACLs and file and
657 directory ACLs for objects not owned by the user.
658 </p><p>
659 In this example, all rights are assigned to the <code class="constant">Domain Admins</code> group. This is a good
660 idea since members of this group are generally expected to be all-powerful. This assignment makes that
661 the reality:
662<a class="indexterm" name="id2601592"></a>
663</p><pre class="screen">
664<code class="prompt">root# </code> net rpc rights grant "MIDEARTH\Domain Admins" \
665 SeMachineAccountPrivilege SePrintOperatorPrivilege \
666 SeAddUsersPrivilege SeRemoteShutdownPrivilege \
667 SeDiskOperatorPrivilege -U root%not24get
668Successfully granted rights.
669</pre><p>
670 Next, the domain user <code class="constant">jht</code> is given the privileges needed for day-to-day
671 administration:
672</p><pre class="screen">
673<code class="prompt">root# </code> net rpc rights grant "MIDEARTH\jht" \
674 SeMachineAccountPrivilege SePrintOperatorPrivilege \
675 SeAddUsersPrivilege SeDiskOperatorPrivilege \
676 -U root%not24get
677Successfully granted rights.
678</pre><p>
679 </p><p>
680 The following step permits validation of the changes just made:
681<a class="indexterm" name="id2601643"></a>
682</p><pre class="screen">
683<code class="prompt">root# </code> net rpc rights list accounts -U root%not24get
684MIDEARTH\jht
685SeMachineAccountPrivilege
686SePrintOperatorPrivilege
687SeAddUsersPrivilege
688SeDiskOperatorPrivilege
689
690BUILTIN\Print Operators
691No privileges assigned
692
693BUILTIN\Account Operators
694No privileges assigned
695
696BUILTIN\Backup Operators
697No privileges assigned
698
699BUILTIN\Server Operators
700No privileges assigned
701
702BUILTIN\Administrators
703No privileges assigned
704
705Everyone
706No privileges assigned
707
708MIDEARTH\Domain Admins
709SeMachineAccountPrivilege
710SePrintOperatorPrivilege
711SeAddUsersPrivilege
712SeRemoteShutdownPrivilege
713SeDiskOperatorPrivilege
714</pre><p>
715 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2601678"></a>Managing Trust Relationships</h2></div></div></div><p>
716 There are essentially two types of trust relationships: the first is between domain controllers and domain
717 member machines (network clients), the second is between domains (called interdomain trusts). All
718 Samba servers that participate in domain security require a domain membership trust account, as do like
719 Windows NT/200x/XP workstations.
720 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2601693"></a>Machine Trust Accounts</h3></div></div></div><p>
721 The net command looks in the <code class="filename">smb.conf</code> file to obtain its own configuration settings. Thus, the following
722 command 'knows' which domain to join from the <code class="filename">smb.conf</code> file.
723 </p><p>
724 A Samba server domain trust account can be validated as shown in this example:
725<a class="indexterm" name="id2601720"></a>
726</p><pre class="screen">
727<code class="prompt">root# </code> net rpc testjoin
728Join to 'MIDEARTH' is OK
729</pre><p>
730 Where there is no domain membership account, or when the account credentials are not valid, the following
731 results will be observed:
732</p><pre class="screen">
733net rpc testjoin -S DOLPHIN
734Join to domain 'WORLDOCEAN' is not valid
735</pre><p>
736 </p><p>
737 The equivalent command for joining a Samba server to a Windows ADS domain is shown here:
738<a class="indexterm" name="id2601757"></a>
739</p><pre class="screen">
740<code class="prompt">root# </code> net ads testjoin
741Using short domain name -- TAKEAWAY
742Joined 'LEMONADE' to realm 'TAKEAWAY.BIZ'
743</pre><p>
744 In the event that the ADS trust was not established, or is broken for one reason or another, the following
745 error message may be obtained:
746</p><pre class="screen">
747<code class="prompt">root# </code> net ads testjoin -UAdministrator%secret
748Join to domain is not valid
749</pre><p>
750 </p><p>
751 The following demonstrates the process of creating a machine trust account in the target domain for the
752 Samba server from which the command is executed:
753<a class="indexterm" name="id2601802"></a>
754</p><pre class="screen">
755<code class="prompt">root# </code> net rpc join -S FRODO -Uroot%not24get
756Joined domain MIDEARTH.
757</pre><p>
758 The joining of a Samba server to a Samba domain results in the creation of a machine account. An example
759 of this is shown here:
760</p><pre class="screen">
761<code class="prompt">root# </code> pdbedit -Lw merlin\$
762merlin$:1009:9B4489D6B90461FD6A3EC3AB96147E16:\
763176D8C554E99914BDF3407DEA2231D80:[S ]:LCT-42891919:
764</pre><p>
765 The S in the square brackets means this is a server (PDC/BDC) account. The domain join can be cast to join
766 purely as a workstation, in which case the S is replaced with a W (indicating a workstation account). The
767 following command can be used to affect this:
768<a class="indexterm" name="id2601846"></a>
769</p><pre class="screen">
770<code class="prompt">root# </code> net rpc join member -S FRODO -Uroot%not24get
771Joined domain MIDEARTH.
772</pre><p>
773 Note that the command-line parameter <code class="constant">member</code> makes this join specific. By default
774 the type is deduced from the <code class="filename">smb.conf</code> file configuration. To specifically join as a PDC or BDC, the
775 command-line parameter will be <code class="constant">[PDC | BDC]</code>. For example:
776<a class="indexterm" name="id2601887"></a>
777</p><pre class="screen">
778<code class="prompt">root# </code> net rpc join bdc -S FRODO -Uroot%not24get
779Joined domain MIDEARTH.
780</pre><p>
781 It is best to let Samba figure out the domain join type from the settings in the <code class="filename">smb.conf</code> file.
782 </p><p>
783 The command to join a Samba server to a Windows ADS domain is shown here:
784<a class="indexterm" name="id2601923"></a>
785</p><pre class="screen">
786<code class="prompt">root# </code> net ads join -UAdministrator%not24get
787Using short domain name -- GDANSK
788Joined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ'
789</pre><p>
790 </p><p>
791 There is no specific option to remove a machine account from an NT4 domain. When a domain member that is a
792 Windows machine is withdrawn from the domain, the domain membership account is not automatically removed
793 either. Inactive domain member accounts can be removed using any convenient tool. If necessary, the
794 machine account can be removed using the following <code class="literal">net</code> command:
795<a class="indexterm" name="id2601963"></a>
796</p><pre class="screen">
797<code class="prompt">root# </code> net rpc user delete HERRING\$ -Uroot%not24get
798Deleted user account.
799</pre><p>
800 The removal is made possible because machine accounts are just like user accounts with a trailing $
801 character. The account management operations treat user and machine accounts in like manner.
802 </p><p>
803 A Samba-3 server that is a Windows ADS domain member can execute the following command to detach from the
804 domain:
805<a class="indexterm" name="id2601995"></a>
806</p><pre class="screen">
807<code class="prompt">root# </code> net ads leave
808</pre><p>
809 </p><p>
810 Detailed information regarding an ADS domain can be obtained by a Samba DMS machine by executing the
811 following:
812<a class="indexterm" name="id2602023"></a>
813</p><pre class="screen">
814<code class="prompt">root# </code> net ads status
815</pre><p>
816 The volume of information is extensive. Please refer to the book &#8220;<span class="quote">Samba-3 by Example</span>&#8221;,
817 Chapter 7 for more information regarding its use. This book may be obtained either in print or online from
818 the <a class="ulink" href="http://www.samba.org/samba/docs/Samba3-ByExample.pdf" target="_top">Samba-3 by Example</a>.
819 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2602062"></a>Interdomain Trusts</h3></div></div></div><p>
820 Interdomain trust relationships form the primary mechanism by which users from one domain can be granted
821 access rights and privileges in another domain.
822 </p><p>
823 To discover what trust relationships are in effect, execute this command:
824<a class="indexterm" name="id2602077"></a>
825</p><pre class="screen">
826<code class="prompt">root# </code> net rpc trustdom list -Uroot%not24get
827Trusted domains list:
828
829none
830
831Trusting domains list:
832
833none
834</pre><p>
835 There are no interdomain trusts at this time; the following steps will create them.
836 </p><p>
837 It is necessary to create a trust account in the local domain. A domain controller in a second domain can
838 create a trusted connection with this account. That means that the foreign domain is being trusted
839 to access resources in the local domain. This command creates the local trust account:
840<a class="indexterm" name="id2602111"></a>
841</p><pre class="screen">
842<code class="prompt">root# </code> net rpc trustdom add DAMNATION f00db4r -Uroot%not24get
843</pre><p>
844 The account can be revealed by using the <code class="literal">pdbedit</code> as shown here:
845</p><pre class="screen">
846<code class="prompt">root# </code> pdbedit -Lw DAMNATION\$
847DAMNATION$:1016:9AC1F121DF897688AAD3B435B51404EE: \
8487F845808B91BB9F7FEF44B247D9DC9A6:[I ]:LCT-428934B1:
849</pre><p>
850 A trust account will always have an I in the field within the square brackets.
851 </p><p>
852 If the trusting domain is not capable of being reached, the following command will fail:
853<a class="indexterm" name="id2602162"></a>
854</p><pre class="screen">
855<code class="prompt">root# </code> net rpc trustdom list -Uroot%not24get
856Trusted domains list:
857
858none
859
860Trusting domains list:
861
862DAMNATION S-1-5-21-1385457007-882775198-1210191635
863</pre><p>
864 The above command executed successfully; a failure is indicated when the following response is obtained:
865</p><pre class="screen">
866net rpc trustdom list -Uroot%not24get
867Trusted domains list:
868
869DAMNATION S-1-5-21-1385457007-882775198-1210191635
870
871Trusting domains list:
872
873DAMNATION domain controller is not responding
874</pre><p>
875 </p><p>
876 Where a trust account has been created on a foreign domain, Samba is able to establish the trust (connect with)
877 the foreign account. In the process it creates a one-way trust to the resources on the remote domain. This
878 command achieves the objective of joining the trust relationship:
879<a class="indexterm" name="id2602206"></a>
880</p><pre class="screen">
881<code class="prompt">root# </code> net rpc trustdom establish DAMNATION
882Password: xxxxxxx == f00db4r
883Could not connect to server TRANSGRESSION
884Trust to domain DAMNATION established
885</pre><p>
886 Validation of the two-way trust now established is possible as shown here:
887</p><pre class="screen">
888<code class="prompt">root# </code> net rpc trustdom list -Uroot%not24get
889Trusted domains list:
890
891DAMNATION S-1-5-21-1385457007-882775198-1210191635
892
893Trusting domains list:
894
895DAMNATION S-1-5-21-1385457007-882775198-1210191635
896</pre><p>
897 </p><p>
898 Sometimes it is necessary to remove the ability for local users to access a foreign domain. The trusting
899 connection can be revoked as shown here:
900<a class="indexterm" name="id2602253"></a>
901</p><pre class="screen">
902<code class="prompt">root# </code> net rpc trustdom revoke DAMNATION -Uroot%not24get
903</pre><p>
904 At other times it becomes necessary to remove the ability for users from a foreign domain to be able to
905 access resources in the local domain. The command shown here will do that:
906</p><pre class="screen">
907<code class="prompt">root# </code> net rpc trustdom del DAMNATION -Uroot%not24get
908</pre><p>
909
910 </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2602295"></a>Managing Security Identifiers (SIDS)</h2></div></div></div><p>
911<a class="indexterm" name="id2602304"></a>
912<a class="indexterm" name="id2602311"></a>
913<a class="indexterm" name="id2602317"></a>
914<a class="indexterm" name="id2602324"></a>
915<a class="indexterm" name="id2602331"></a>
916 The basic security identifier that is used by all Windows networking operations is the Windows security
917 identifier (SID). All Windows network machines (servers and workstations), users, and groups are
918 identified by their respective SID. All desktop profiles are also encoded with user and group SIDs that
919 are specific to the SID of the domain to which the user belongs.
920 </p><p>
921<a class="indexterm" name="id2602354"></a>
922<a class="indexterm" name="id2602360"></a>
923<a class="indexterm" name="id2602367"></a>
924<a class="indexterm" name="id2602374"></a>
925 It is truly prudent to store the machine and/or domain SID in a file for safekeeping. Why? Because
926 a change in hostname or in the domain (workgroup) name may result in a change in the SID. When you
927 have the SID on hand, it is a simple matter to restore it. The alternative is to suffer the pain of
928 having to recover user desktop profiles and perhaps rejoin all member machines to the domain.
929 </p><p>
930 First, do not forget to store the local SID in a file. It is a good idea to put this in the directory
931 in which the <code class="filename">smb.conf</code> file is also stored. Here is a simple action to achieve this:
932<a class="indexterm" name="id2602400"></a>
933</p><pre class="screen">
934<code class="prompt">root# </code> net getlocalsid &gt; /etc/samba/my-sid
935</pre><p>
936 Good, there is now a safe copy of the local machine SID. On a PDC/BDC this is the domain SID also.
937 </p><p>
938 The following command reveals what the former one should have placed into the file called
939 <code class="filename">my-sid</code>:
940</p><pre class="screen">
941<code class="prompt">root# </code> net getlocalsid
942SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429
943</pre><p>
944 </p><p>
945 If ever it becomes necessary to restore the SID that has been stored in the <code class="filename">my-sid</code>
946 file, simply copy the SID (the string of characters that begins with <code class="constant">S-1-5-21</code>) to
947 the command line shown here:
948<a class="indexterm" name="id2602462"></a>
949</p><pre class="screen">
950<code class="prompt">root# </code> net setlocalsid S-1-5-21-1385457007-882775198-1210191635
951</pre><p>
952 Restoration of a machine SID is a simple operation, but the absence of a backup copy can be very
953 problematic.
954 </p><p>
955 The following operation is useful only for machines that are being configured as a PDC or a BDC.
956 DMS and workstation clients should have their own machine SID to avoid
957 any potential namespace collision. Here is the way that the BDC SID can be synchronized to that
958 of the PDC (this is the default NT4 domain practice also):
959<a class="indexterm" name="id2602494"></a>
960</p><pre class="screen">
961<code class="prompt">root# </code> net rpc getsid -S FRODO -Uroot%not24get
962Storing SID S-1-5-21-726309263-4128913605-1168186429 \
963 for Domain MIDEARTH in secrets.tdb
964</pre><p>
965 Usually it is not necessary to specify the target server (-S FRODO) or the administrator account
966 credentials (-Uroot%not24get).
967 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2602524"></a>Share Management</h2></div></div></div><p>
968 Share management is central to all file serving operations. Typical share operations include:
969 </p><div class="itemizedlist"><ul type="disc"><li><p>Creation/change/deletion of shares</p></li><li><p>Setting/changing ACLs on shares</p></li><li><p>Moving shares from one server to another</p></li><li><p>Change of permissions of share contents</p></li></ul></div><p>
970 Each of these are dealt with here insofar as they involve the use of the <code class="literal">net</code>
971 command. Operations outside of this command are covered elsewhere in this document.
972 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2602569"></a>Creating, Editing, and Removing Shares</h3></div></div></div><p>
973 A share can be added using the <code class="literal">net rpc share</code> command capabilities.
974 The target machine may be local or remote and is specified by the -S option. It must be noted
975 that the addition and deletion of shares using this tool depends on the availability of a suitable
976 interface script. The interface scripts Sambas <code class="literal">smbd</code> uses are called
977 <a class="link" href="smb.conf.5.html#ADDSHARECOMMAND" target="_top">add share command</a>, <a class="link" href="smb.conf.5.html#DELETESHARECOMMAND" target="_top">delete share command</a> and
978 <a class="link" href="smb.conf.5.html#CHANGESHARECOMMAND" target="_top">change share command</a> A set of example scripts are provided in the Samba source
979 code tarball in the directory <code class="filename">~samba/examples/scripts</code>.
980 </p><p>
981 The following steps demonstrate the use of the share management capabilities of the <code class="literal">net</code>
982 utility. In the first step a share called <code class="constant">Bulge</code> is added. The sharepoint within the
983 file system is the directory <code class="filename">/data</code>. The command that can be executed to perform the
984 addition of this share is shown here:
985<a class="indexterm" name="id2602665"></a>
986</p><pre class="screen">
987<code class="prompt">root# </code> net rpc share add Bulge=/data -S MERLIN -Uroot%not24get
988</pre><p>
989 Validation is an important process, and by executing the command <code class="literal">net rpc share</code>
990 with no other operators it is possible to obtain a listing of available shares, as shown here:
991</p><pre class="screen">
992<code class="prompt">root# </code> net rpc share -S MERLIN -Uroot%not24get
993profdata
994archive
995Bulge &lt;--- This one was added
996print$
997netlogon
998profiles
999IPC$
1000kyocera
1001ADMIN$
1002</pre><p>
1003 </p><p>
1004 Often it is desirable also to permit a share to be removed using a command-line tool.
1005 The following step permits the share that was previously added to be removed:
1006<a class="indexterm" name="id2602716"></a>
1007</p><pre class="screen">
1008<code class="prompt">root# </code> net rpc share delete Bulge -S MERLIN -Uroot%not24get
1009</pre><p>
1010 A simple validation shown here demonstrates that the share has been removed:
1011</p><pre class="screen">
1012<code class="prompt">root# </code> net rpc share -S MERLIN -Uroot%not24get
1013profdata
1014archive
1015print$
1016netlogon
1017profiles
1018IPC$
1019ADMIN$
1020kyocera
1021</pre><p>
1022 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2602757"></a>Creating and Changing Share ACLs</h3></div></div></div><p>
1023 At this time the <code class="literal">net</code> tool cannot be used to manage ACLs on Samba shares. In MS Windows
1024 language this is called Share Permissions.
1025 </p><p>
1026 It is possible to set ACLs on Samba shares using either the SRVTOOLS NT4 Domain Server Manager
1027 or using the Computer Management MMC snap-in. Neither is covered here,
1028 but see <a class="link" href="AccessControls.html" title="Chapter 16. File, Directory, and Share Access Controls">&#8220;File, Directory, and Share Access Controls&#8221;</a>.
1029 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2602787"></a>Share, Directory, and File Migration</h3></div></div></div><p>
1030<a class="indexterm" name="id2602795"></a>
1031 Shares and files can be migrated in the same manner as user, machine, and group accounts.
1032 It is possible to preserve access control settings (ACLs) as well as security settings
1033 throughout the migration process. The <code class="literal">net rpc vampire</code> facility is used
1034 to migrate accounts from a Windows NT4 (or later) domain to a Samba server. This process
1035 preserves passwords and account security settings and is a precursor to the migration
1036 of shares and files.
1037 </p><p>
1038 The <code class="literal">net rpc share</code> command may be used to migrate shares, directories,
1039 files, and all relevant data from a Windows server to a Samba server.
1040 </p><p>
1041 A set of command-line switches permit the creation of almost direct clones of Windows file
1042 servers. For example, when migrating a fileserver, file ACLs and DOS file attributes from
1043 the Windows server can be included in the migration process and will reappear, almost identically,
1044 on the Samba server when the migration has been completed.
1045 </p><p>
1046 The migration process can be completed only with the Samba server already being fully operational.
1047 The user and group accounts must be migrated before attempting to migrate data
1048 share, files, and printers. The migration of files and printer configurations involves the use
1049 of both SMB and MS DCE RPC services. The benefit of the manner in which the migration process has
1050 been implemented is that the possibility now exists to use a Samba server as a man-in-middle migration
1051 service that affects a transfer of data from one server to another. For example, if the Samba
1052 server is called MESSER, the source Windows NT4 server is called PEPPY, and the target Samba
1053 server is called GONZALES, the machine MESSER can be used to effect the migration of all data
1054 (files and shares) from PEPPY to GONZALES. If the target machine is not specified, the local
1055 server is assumed by default - as net's general rule of thumb .
1056 </p><p>
1057 The success of server migration requires a firm understanding of the structure of the source
1058 server (or domain) as well as the processes on which the migration is critically dependant.
1059 </p><p>
1060 There are two known limitations to the migration process:
1061 </p><div class="orderedlist"><ol type="1"><li><p>
1062 The <code class="literal">net</code> command requires that the user credentials provided exist on both
1063 the migration source and the migration target.
1064 </p></li><li><p>
1065 Printer settings may not be fully or may be incorrectly migrated. This might in particular happen
1066 when migrating a Windows 2003 print server to Samba.
1067 </p></li></ol></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2602897"></a>Share Migration</h4></div></div></div><p>
1068 The <code class="literal">net rpc share migrate</code> command operation permits the migration of plain
1069 share stanzas. A stanza contains the parameters within which a file or print share are defined.
1070 The use of this migration method will create share stanzas that have as parameters the file
1071 system directory path, an optional description, and simple security settings that permit write
1072 access to files. One of the first steps necessary following migration is to review the share
1073 stanzas to ensure that the settings are suitable for use.
1074 </p><p>
1075 The shares are created on the fly as part of the migration process. The <code class="literal">smbd</code>
1076 application does this by calling on the operating system to execute the script specified by the
1077 <code class="filename">smb.conf</code> parameter <em class="parameter"><code>add share command</code></em>.
1078 </p><p>
1079 There is a suitable example script for the <em class="parameter"><code>add share command</code></em> in the
1080 <code class="filename">$SAMBA_SOURCES/examples/scripts</code> directory. It should be noted that
1081 the account that is used to drive the migration must, of necessity, have appropriate file system
1082 access privileges and have the right to create shares and to set ACLs on them. Such rights are
1083 conferred by these rights: <em class="parameter"><code>SeAddUsersPrivilege</code></em> and <em class="parameter"><code>SeDiskOperatorPrivilege</code></em>.
1084 For more information regarding rights and privileges please refer to <a class="link" href="rights.html" title="Chapter 15. User Rights and Privileges">&#8220;User Rights and Privileges&#8221;</a>.
1085 </p><p>
1086 The syntax of the share migration command is shown here:
1087</p><pre class="screen">
1088net rpc share MIGRATE SHARES &lt;share-name&gt; -S &lt;source&gt;
1089 [--destination=localhost] [--exclude=share1,share2] [-v]
1090</pre><p>
1091 When the parameter &lt;share-name&gt; is omitted, all shares will be migrated. The potentially
1092 large list of available shares on the system that is being migrated can be limited using the
1093 <em class="parameter"><code>--exclude</code></em> switch. For example:
1094<a class="indexterm" name="id2603010"></a>
1095</p><pre class="screen">
1096<code class="prompt">root# </code> net rpc share migrate shares myshare\
1097 -S win2k -U administrator%secret"
1098</pre><p>
1099 This will migrate the share <code class="constant">myshare</code> from the server <code class="constant">win2k</code>
1100 to the Samba Server using the permissions that are tied to the account <code class="constant">administrator</code>
1101 with the password <code class="constant">secret</code>. The account that is used must be the same on both the
1102 migration source server and the target Samba server. The use of the <code class="literal">net rpc
1103 vampire</code>, prior to attempting the migration of shares, will ensure that accounts will be
1104 identical on both systems. One precaution worth taking before commencement of migration of shares is
1105 to validate that the migrated accounts (on the Samba server) have the needed rights and privileges.
1106 This can be done as shown here:
1107<a class="indexterm" name="id2603065"></a>
1108</p><pre class="screen">
1109<code class="prompt">root# </code> net rpc right list accounts -Uroot%not24get
1110</pre><p>
1111 The steps taken so far perform only the migration of shares. Directories and directory contents
1112 are not migrated by the steps covered up to this point.
1113 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2603093"></a>File and Directory Migration</h4></div></div></div><p>
1114 Everything covered to this point has been done in preparation for the migration of file and directory
1115 data. For many people preparation is potentially boring and the real excitement only begins when file
1116 data can be used. The next steps demonstrate the techniques that can be used to transfer (migrate)
1117 data files using the <code class="literal">net</code> command.
1118 </p><p>
1119 Transfer of files from one server to another has always been a challenge for MS Windows
1120 administrators because Windows NT and 200X servers do not always include the tools needed. The
1121 <code class="literal">xcopy</code> from Windows NT is not capable of preserving file and directory ACLs,
1122 it does so only with Windows 200x. Microsoft does provide a
1123 utility that can copy ACLs (security settings) called <code class="literal">scopy</code>, but it is provided only
1124 as part of the Windows NT or 200X Server Resource Kit.
1125 </p><p>
1126 There are several tools, both commercial and freeware, that can be used from a Windows server to copy files
1127 and directories with full preservation of security settings. One of the best known of the free tools is
1128 called <code class="literal">robocopy</code>.
1129 </p><p>
1130 The <code class="literal">net</code> utility can be used to copy files and directories with full preservation of
1131 ACLs as well as DOS file attributes. Note that including ACLs makes sense only where the destination
1132 system will operate within the same security context as the source system. This applies both to a
1133 DMS and to domain controllers that result from a vampired domain.
1134 Before file and directory migration, all shares must already exist.
1135 </p><p>
1136 The syntax for the migration commands is shown here:
1137</p><pre class="screen">
1138net rpc share MIGRATE FILES &lt;share-name&gt; -S &lt;source&gt;
1139 [--destination=localhost] [--exclude=share1,share2]
1140 [--acls] [--attrs] [--timestamps] [-v]
1141</pre><p>
1142 If the &lt;share-name&gt; parameter is omitted, all shares will be migrated. The potentially large
1143 list of shares on the source system can be restricted using the <em class="parameter"><code>--exclude</code></em> command
1144 switch.
1145 </p><p>
1146 Where it is necessary to preserve all file ACLs, the <em class="parameter"><code>--acls</code></em> switch should be added
1147 to the above command line. Original file timestamps can be preserved by specifying the
1148 <em class="parameter"><code>--timestamps</code></em> switch, and the DOS file attributes (i.e., hidden, archive, etc.) can
1149 be preserved by specifying the <em class="parameter"><code>--attrs</code></em> switch.
1150 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
1151 The ability to preserve ACLs depends on appropriate support for ACLs as well as the general file system
1152 semantics of the host operating system on the target server. A migration from one Windows file server to
1153 another will perfectly preserve all file attributes. Because of the difficulty of mapping Windows ACLs
1154 onto a POSIX ACLs-supporting system, there can be no perfect migration of Windows ACLs to a Samba server.
1155 </p></div><p>
1156 The ACLs that result on a Samba server will most probably not match the originating ACLs. Windows supports
1157 the possibility of files that are owned only by a group. Group-alone file ownership is not possible under
1158 UNIX/Linux. Errors in migrating group-owned files can be avoided by using the <code class="filename">smb.conf</code> file
1159 <a class="link" href="smb.conf.5.html#FORCEUNKNOWNACLUSER" target="_top">force unknown acl user = yes</a> parameter. This facility will
1160 automatically convert group-owned files into correctly user-owned files on the Samba server.
1161 </p><p>
1162 An example for migration of files from a machine called <code class="constant">nt4box</code> to the Samba server
1163 from which the process will be handled is shown here:
1164<a class="indexterm" name="id2603268"></a>
1165</p><pre class="screen">
1166<code class="prompt">root# </code> net rpc share migrate files -S nt4box --acls \
1167 --attrs -U administrator%secret
1168</pre><p>
1169 </p><p>
1170 This command will migrate all files and directories from all file shares on the Windows server called
1171 <code class="constant">nt4box</code> to the Samba server from which migration is initiated. Files that are group-owned
1172 will be owned by the user account <code class="constant">administrator</code>.
1173 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2603308"></a>Share-ACL Migration</h4></div></div></div><p>
1174 It is possible to have share-ACLs (security descriptors) that won't allow you, even as Administrator, to
1175 copy any files or directories into it. Therefor the migration of the share-ACLs has been put into a separate
1176 function:
1177<a class="indexterm" name="id2603320"></a>
1178</p><pre class="screen">
1179<code class="prompt">root# </code> net rpc share migrate security -S nt4box -U administrator%secret
1180</pre><p>
1181 </p><p>
1182 This command will only copy the share-ACL of each share on nt4box to your local samba-system.
1183 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2603351"></a>Simultaneous Share and File Migration</h4></div></div></div><p>
1184 The operating mode shown here is just a combination of the previous three. It first migrates
1185 share definitions and then all shared files and directories and finally migrates the share-ACLs:
1186</p><pre class="screen">
1187net rpc share MIGRATE ALL &lt;share-name&gt; -S &lt;source&gt;
1188 [--exclude=share1, share2] [--acls] [--attrs] [--timestamps] [-v]
1189</pre><p>
1190 </p><p>
1191 An example of simultaneous migration is shown here:
1192<a class="indexterm" name="id2603376"></a>
1193</p><pre class="screen">
1194<code class="prompt">root# </code> net rpc share migrate all -S w2k3server -U administrator%secret
1195</pre><p>
1196 This will generate a complete server clone of the <em class="parameter"><code>w2k3server</code></em> server.
1197 </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2603410"></a>Printer Migration</h3></div></div></div><p>
1198 The installation of a new server, as with the migration to a new network environment, often is similar to
1199 building a house; progress is very rapid from the laying of foundations up to the stage at which
1200 the house can be locked up, but the finishing off appears to take longer and longer as building
1201 approaches completion.
1202 </p><p>
1203 Printing needs vary greatly depending on the network environment and may be very simple or complex. If
1204 the need is very simple, the best solution to the implementation of printing support may well be to
1205 re-install everything from a clean slate instead of migrating older configurations. On the other hand,
1206 a complex network that is integrated with many international offices and a multiplexity of local branch
1207 offices, each of which form an inter-twined maze of printing possibilities, the ability to migrate all
1208 printer configurations is decidedly beneficial. To manually re-establish a complex printing network
1209 will take much time and frustration. Often it will not be possible to find driver files that are
1210 currently in use, necessitating the installation of newer drivers. Newer drivers often implement
1211 printing features that will necessitate a change in the printer usage. Additionally, with very complex
1212 printer configurations it becomes almost impossible to re-create the same environment no matter
1213 how extensively it has been documented.
1214 </p><p>
1215 The migration of an existing printing architecture involves the following:
1216 </p><div class="itemizedlist"><ul type="disc"><li><p>Establishment of print queues.</p></li><li><p>Installation of printer drivers (both for the print server and for Windows clients.</p></li><li><p>Configuration of printing forms.</p></li><li><p>Implementation of security settings.</p></li><li><p>Configuration of printer settings.</p></li></ul></div><p>
1217 The Samba <code class="literal">net</code> utility permits printer migration from one Windows print server
1218 to another. When this tool is used to migrate printers to a Samba server <code class="literal">smbd</code>,
1219 the application that receives the network requests to create the necessary services must call out
1220 to the operating system in order to create the underlying printers. The call-out is implemented
1221 by way of an interface script that can be specified by the <code class="filename">smb.conf</code> file parameter
1222 <a class="link" href="smb.conf.5.html#" target="_top"></a>. This script is essential to the migration process.
1223 A suitable example script may be obtained from the <code class="filename">$SAMBA_SOURCES/examples/scripts</code>
1224 directory. Take note that this script must be customized to suit the operating system environment
1225 and may use its tools to create a print queue.
1226 </p><p>
1227 Each of the components listed above can be completed separately, or they can be completed as part of an
1228 automated operation. Many network administrators prefer to deal with migration issues in a manner that
1229 gives them the most control, particularly when things go wrong. The syntax for each operation is now
1230 briefly described.
1231 </p><p>
1232 Printer migration from a Windows print server (NT4 or 200x) is shown. This instruction causes the
1233 printer share to be created together with the underlying print queue:
1234<a class="indexterm" name="id2603545"></a>
1235</p><pre class="screen">
1236net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets]
1237</pre><p>
1238 Printer drivers can be migrated from the Windows print server to the Samba server using this
1239 command-line instruction:
1240<a class="indexterm" name="id2603565"></a>
1241</p><pre class="screen">
1242net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]
1243</pre><p>
1244 Printer forms can be migrated with the following operation:
1245<a class="indexterm" name="id2603585"></a>
1246</p><pre class="screen">
1247net rpc printer MIGRATE FORMS [printer] [misc. options] [targets]
1248</pre><p>
1249 Printer security settings (ACLs) can be migrated from the Windows server to the Samba server using this command:
1250<a class="indexterm" name="id2603605"></a>
1251</p><pre class="screen">
1252net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]
1253</pre><p>
1254 Printer configuration settings include factors such as paper size and default paper orientation.
1255 These can be migrated from the Windows print server to the Samba server with this command:
1256<a class="indexterm" name="id2603627"></a>
1257</p><pre class="screen">
1258net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]
1259</pre><p>
1260 </p><p>
1261 Migration of printers including the above-mentioned sets of information may be completed
1262 with a single command using this syntax:
1263</p><pre class="screen">
1264net rpc printer MIGRATE ALL [printer] [misc. options] [targets]
1265</pre><p>
1266 </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2603660"></a>Controlling Open Files</h2></div></div></div><p>
1267 The man page documents the <code class="literal">net file</code> function suite, which provides the tools to
1268 close open files using either RAP or RPC function calls. Please refer to the man page for specific
1269 usage information.
1270 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2603680"></a>Session and Connection Management</h2></div></div></div><p>
1271 The session management interface of the <code class="literal">net session</code> command uses the old RAP
1272 method to obtain the list of connections to the Samba server, as shown here:
1273<a class="indexterm" name="id2603696"></a>
1274</p><pre class="screen">
1275<code class="prompt">root# </code> net rap session -S MERLIN -Uroot%not24get
1276Computer User name Client Type Opens Idle time
1277------------------------------------------------------------------------------
1278\\merlin root Unknown Client 0 00:00:00
1279\\marvel jht Unknown Client 0 00:00:00
1280\\maggot jht Unknown Client 0 00:00:00
1281\\marvel jht Unknown Client 0 00:00:00
1282</pre><p>
1283 </p><p>
1284 A session can be closed by executing a command as shown here:
1285</p><pre class="screen">
1286<code class="prompt">root# </code> net rap session close marvel -Uroot%not24get
1287</pre><p>
1288 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2603745"></a>Printers and ADS</h2></div></div></div><p>
1289 When Samba-3 is used within an MS Windows ADS environment, printers shared via Samba will not be browseable
1290 until they have been published to the ADS domain. Information regarding published printers may be obtained
1291 from the ADS server by executing the <code class="literal">net ads print info</code> command following this syntax:
1292<a class="indexterm" name="id2603764"></a>
1293</p><pre class="screen">
1294net ads printer info &lt;printer_name&gt; &lt;server_name&gt; -Uadministrator%secret
1295</pre><p>
1296 If the asterisk (*) is used in place of the printer_name argument, a list of all printers will be
1297 returned.
1298 </p><p>
1299 To publish (make available) a printer to ADS, execute the following command:
1300<a class="indexterm" name="id2603790"></a>
1301</p><pre class="screen">
1302net ads printer publish &lt;printer_name&gt; -Uadministrator%secret
1303</pre><p>
1304 This publishes a printer from the local Samba server to ADS.
1305 </p><p>
1306 Removal of a Samba printer from ADS is achieved by executing this command:
1307<a class="indexterm" name="id2603815"></a>
1308</p><pre class="screen">
1309net ads printer remove &lt;printer_name&gt; -Uadministrator%secret
1310</pre><p>
1311 </p><p>
1312 A generic search (query) can also be made to locate a printer across the entire ADS domain by executing:
1313<a class="indexterm" name="id2603840"></a>
1314</p><pre class="screen">
1315net ads printer search &lt;printer_name&gt; -Uadministrator%secret
1316</pre><p>
1317 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2603861"></a>Manipulating the Samba Cache</h2></div></div></div><p>
1318 Please refer to the <code class="literal">net</code> command man page for information regarding cache management.
1319 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2603879"></a>Managing IDMAP UID/SID Mappings</h2></div></div></div><p>
1320 The IDMAP UID to SID, and SID to UID, mappings that are created by <code class="literal">winbindd</code> can be
1321 backed up to a text file. The text file can be manually edited, although it is highly recommended that
1322 you attempt this only if you know precisely what you are doing.
1323 </p><p>
1324 An IDMAP text dump file can be restored (or reloaded). There are two situations that may necessitate
1325 this action: a) The existing IDMAP file is corrupt, b) It is necessary to install an editted version
1326 of the mapping information.
1327 </p><p>
1328 Winbind must be shut down to dump the IDMAP file. Before restoring a dump file, shut down
1329 <code class="literal">winbindd</code> and delete the old <code class="filename">winbindd_idmap.tdb</code> file.
1330 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2603923"></a>Creating an IDMAP Database Dump File</h3></div></div></div><p>
1331 The IDMAP database can be dumped to a text file as shown here:
1332</p><pre class="screen">
1333net idmap dump &lt;full_path_and_tdb_filename&gt; &gt; dumpfile.txt
1334</pre><p>
1335 Where a particular build of Samba the run-time tdb files are stored in the
1336 <code class="filename">/var/lib/samba</code> directory the following commands to create the dump file will suffice:
1337</p><pre class="screen">
1338net idmap dump /var/lib/samba/winbindd_idmap.tdb &gt; idmap_dump.txt
1339</pre><p>
1340 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2603958"></a>Restoring the IDMAP Database Dump File</h3></div></div></div><p>
1341 The IDMAP dump file can be restored using the following command:
1342</p><pre class="screen">
1343net idmap restore idmap_dump.txt
1344</pre><p>
1345 Where the Samba run-time tdb files are stored in the <code class="filename">/var/lib/samba</code> directory
1346 the following command can be used to restore the data to the tdb file:
1347</p><pre class="screen">
1348net idmap restore /var/lib/samba/winbindd_idmap.tdb &lt; idmap_dump.txt
1349</pre><p>
1350 </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="netmisc1"></a>Other Miscellaneous Operations</h2></div></div></div><p>
1351 The following command is useful for obtaining basic statistics regarding a Samba domain. This command does
1352 not work with current Windows XP Professional clients.
1353<a class="indexterm" name="id2604008"></a>
1354</p><pre class="screen">
1355<code class="prompt">root# </code> net rpc info
1356Domain Name: RAPIDFLY
1357Domain SID: S-1-5-21-399034208-633907489-3292421255
1358Sequence number: 1116312355
1359Num users: 720
1360Num domain groups: 27
1361Num local groups: 6
1362</pre><p>
1363 </p><p>
1364 Another useful tool is the <code class="literal">net time</code> tool set. This tool may be used to query the
1365 current time on the target server as shown here:
1366<a class="indexterm" name="id2604044"></a>
1367</p><pre class="screen">
1368<code class="prompt">root# </code> net time -S SAURON
1369Tue May 17 00:50:43 2005
1370</pre><p>
1371 In the event that it is the intent to pass the time information obtained to the UNIX
1372 <code class="literal">/bin/time</code>, it is a good idea to obtain the time from the target server in a format
1373 that is ready to be passed through. This may be done by executing:
1374<a class="indexterm" name="id2604075"></a>
1375</p><pre class="screen">
1376<code class="prompt">root# </code> net time system -S FRODO
1377051700532005.16
1378</pre><p>
1379 The time can be set on a target server by executing:
1380<a class="indexterm" name="id2604100"></a>
1381</p><pre class="screen">
1382<code class="prompt">root# </code> net time set -S MAGGOT -U Administrator%not24get
1383Tue May 17 00:55:30 MDT 2005
1384</pre><p>
1385 It is possible to obtain the time zone of a server by executing the following command against it:
1386<a class="indexterm" name="id2604125"></a>
1387</p><pre class="screen">
1388<code class="prompt">root# </code> net time zone -S SAURON
1389-0600
1390</pre><p>
1391 </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="idmapper.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 12. Group Mapping: MS Windows and UNIX </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 14. Identity Mapping (IDMAP)</td></tr></table></div></body></html>
Note: See TracBrowser for help on using the repository browser.