1
<?xml version="1.0" encoding="iso-8859-1"?>
2
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
4
<chapter id="NetCommand">
9
<pubdate>May 9, 2005</pubdate>
12
<title>Remote and Local Management: The Net Command</title>
15
<indexterm><primary>net</primary></indexterm>
16
<indexterm><primary>remote management</primary></indexterm>
17
<indexterm><primary>command-line</primary></indexterm>
18
<indexterm><primary>scripted control</primary></indexterm>
19
The <command>net</command> command is one of the new features of Samba-3 and is an attempt to provide a useful
20
tool for the majority of remote management operations necessary for common tasks. The <command>net</command>
21
tool is flexible by design and is intended for command-line use as well as for scripted control application.
25
<indexterm><primary>net</primary></indexterm>
26
<indexterm><primary>network administrator's toolbox</primary></indexterm>
27
<indexterm><primary>smbgroupedit</primary></indexterm>
28
<indexterm><primary>rpcclient</primary></indexterm>
29
Originally introduced with the intent to mimic the Microsoft Windows command that has the same name, the
30
<command>net</command> command has morphed into a very powerful instrument that has become an essential part
31
of the Samba network administrator's toolbox. The Samba Team has introduced tools, such as
32
<command>smbgroupedit</command> and <command>rpcclient</command>, from which really useful capabilities have
33
been integrated into the <command>net</command>. The <command>smbgroupedit</command> command was absorbed
34
entirely into the <command>net</command>, while only some features of the <command>rpcclient</command> command
35
have been ported to it. Anyone who finds older references to these utilities and to the functionality they
36
provided should look at the <command>net</command> command before searching elsewhere.
40
A Samba-3 administrator cannot afford to gloss over this chapter because to do so will almost certainly cause
41
the infliction of self-induced pain, agony, and desperation. Be warned: this is an important chapter.
45
<title>Overview</title>
48
<indexterm><primary>standalone</primary></indexterm>
49
<indexterm><primary>domain member</primary></indexterm>
50
<indexterm><primary>PDC</primary></indexterm>
51
<indexterm><primary>BDC</primary></indexterm>
52
<indexterm><primary>DMS</primary></indexterm>
53
<indexterm><primary>authentication</primary></indexterm>
54
The tasks that follow the installation of a Samba-3 server, whether standalone or domain member, of a
55
domain controller (PDC or BDC) begins with the need to create administrative rights. Of course, the
56
creation of user and group accounts is essential for both a standalone server and a PDC.
57
In the case of a BDC or a Domain Member server (DMS), domain user and group accounts are obtained from
58
the central domain authentication backend.
62
<indexterm><primary>server type</primary></indexterm>
63
<indexterm><primary>local UNIX groups</primary></indexterm>
64
<indexterm><primary>mapped</primary></indexterm>
65
<indexterm><primary>domain global group</primary></indexterm>
66
<indexterm><primary>UID</primary></indexterm>
67
<indexterm><primary>GID</primary></indexterm>
68
<indexterm><primary>access rights</primary></indexterm>
69
<indexterm><primary>net</primary></indexterm>
70
Regardless of the type of server being installed, local UNIX groups must be mapped to the Windows
71
networking domain global group accounts. Do you ask why? Because Samba always limits its access to
72
the resources of the host server by way of traditional UNIX UID and GID controls. This means that local
73
groups must be mapped to domain global groups so that domain users who are members of the domain
74
global groups can be given access rights based on UIDs and GIDs local to the server that is hosting
75
Samba. Such mappings are implemented using the <command>net</command> command.
79
<indexterm><primary>PDC</primary></indexterm>
80
<indexterm><primary>BDC</primary></indexterm>
81
<indexterm><primary>DMS</primary></indexterm>
82
<indexterm><primary>security account</primary></indexterm>
83
<indexterm><primary>domain authentication</primary></indexterm>
84
<indexterm><primary>trust accounts</primary></indexterm>
85
<indexterm><primary>net</primary></indexterm>
86
UNIX systems that are hosting a Samba-3 server that is running as a member (PDC, BDC, or DMS) must have
87
a machine security account in the domain authentication database (or directory). The creation of such
88
security (or trust) accounts is also handled using the <command>net</command> command.
92
<indexterm><primary>interdomain trusts</primary></indexterm>
93
<indexterm><primary>net</primary></indexterm>
94
<indexterm><primary>administrative duties</primary></indexterm>
95
<indexterm><primary>user management</primary></indexterm>
96
<indexterm><primary>group management</primary></indexterm>
97
<indexterm><primary>share management</primary></indexterm>
98
<indexterm><primary>printer management</primary></indexterm>
99
<indexterm><primary>printer migration</primary></indexterm>
100
<indexterm><primary>SID management</primary></indexterm>
101
The establishment of interdomain trusts is achieved using the <command>net</command> command also, as
102
may a plethora of typical administrative duties such as user management, group management, share and
103
printer management, file and printer migration, security identifier management, and so on.
107
<indexterm><primary>net</primary></indexterm>
108
<indexterm><primary>man pages</primary></indexterm>
109
The overall picture should be clear now: the <command>net</command> command plays a central role
110
on the Samba-3 stage. This role will continue to be developed. The inclusion of this chapter is
111
evidence of its importance, one that has grown in complexity to the point that it is no longer considered
112
prudent to cover its use fully in the online UNIX man pages.
118
<title>Administrative Tasks and Methods</title>
121
<indexterm><primary>net</primary></indexterm>
122
<indexterm><primary>ADS</primary></indexterm>
123
<indexterm><primary>Distributed Computing Environment</primary><see>DCE</see></indexterm>
124
<indexterm><primary>Remote Procedure Call</primary><see>RPC</see></indexterm>
125
The basic operations of the <command>net</command> command are documented here. This documentation is not
126
exhaustive, and thus it is incomplete. Since the primary focus is on migration from Windows servers to a Samba
127
server, the emphasis is on the use of the Distributed Computing Environment Remote Procedure Call (DCE RPC)
128
mode of operation. When used against a server that is a member of an Active Directory domain, it is preferable
129
(and often necessary) to use ADS mode operations. The <command>net</command> command supports both, but not
130
for every operation. For most operations, if the mode is not specified, <command>net</command> will
131
automatically fall back via the <constant>ads</constant>, <constant>rpc</constant>, and
132
<constant>rap</constant> modes. Please refer to the man page for a more comprehensive overview of the
133
capabilities of this utility.
139
<title>UNIX and Windows Group Management</title>
142
<indexterm><primary>Active Directory</primary></indexterm>
143
<indexterm><primary>net</primary><secondary>rpc</secondary></indexterm>
144
<indexterm><primary>net</primary><secondary>ads</secondary></indexterm>
145
<indexterm><primary>net</primary><secondary>rap</secondary></indexterm>
146
<indexterm><primary>RAP</primary></indexterm>
147
As stated, the focus in most of this chapter is on use of the <command>net rpc</command> family of
148
operations that are supported by Samba. Most of them are supported by the <command>net ads</command>
149
mode when used in connection with Active Directory. The <command>net rap</command> operating mode is
150
also supported for some of these operations. RAP protocols are used by IBM OS/2 and by several
155
<indexterm><primary>net</primary></indexterm>
156
<indexterm><primary>user management</primary></indexterm>
157
<indexterm><primary>group management</primary></indexterm>
158
Samba's <command>net</command> tool implements sufficient capability to permit all common administrative
159
tasks to be completed from the command line. In this section each of the essential user and group management
160
facilities are explored.
164
<indexterm><primary>groups</primary></indexterm>
165
<indexterm><primary>domain</primary><secondary>groups</secondary></indexterm>
166
<indexterm><primary>local</primary><secondary>groups</secondary></indexterm>
167
<indexterm><primary>domain user accounts</primary></indexterm>
168
Samba-3 recognizes two types of groups: <emphasis>domain groups</emphasis> and <emphasis>local
169
groups</emphasis>. Domain groups can contain (have as members) only domain user accounts. Local groups
170
can contain local users, domain users, and domain groups as members.
174
The purpose of a local group is to permit file permission to be set for a group account that, like the
175
usual UNIX/Linux group, is persistent across redeployment of a Windows file server.
179
<title>Adding, Renaming, or Deletion of Group Accounts</title>
182
Samba provides file and print services to Windows clients. The file system resources it makes available
183
to the Windows environment must, of necessity, be provided in a manner that is compatible with the
184
Windows networking environment. UNIX groups are created and deleted as required to serve operational
185
needs in the UNIX operating system and its file systems.
189
In order to make available to the Windows environment, Samba has a facility by which UNIX groups can
190
be mapped to a logical entity, called a Windows (or domain) group. Samba supports two types of Windows
191
groups, local and global. Global groups can contain as members, global users. This membership is
192
affected in the normal UNIX manner, but adding UNIX users to UNIX groups. Windows user accounts consist
193
of a mapping between a user SambaSAMAccount (logical entity) and a UNIX user account. Therefore,
194
a UNIX user is mapped to a Windows user (i.e., is given a Windows user account and password) and the
195
UNIX groups to which that user belongs, is mapped to a Windows group account. The result is that in
196
the Windows account environment that user is also a member of the Windows group account by virtue
197
of UNIX group memberships.
201
The following sub-sections that deal with management of Windows groups demonstrates the relationship
202
between the UNIX group account and its members to the respective Windows group accounts. It goes on to
203
show how UNIX group members automatically pass-through to Windows group membership as soon as a logical
204
mapping has been created.
208
<title>Adding or Creating a New Group</title>
211
Before attempting to add a Windows group account, the currently available groups can be listed as shown
213
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group</tertiary></indexterm>
214
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group list</tertiary></indexterm>
216
&rootprompt; net rpc group list -Uroot%not24get
231
A Windows group account called <quote>SupportEngrs</quote> can be added by executing the following
233
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group add</tertiary></indexterm>
235
&rootprompt; net rpc group add "SupportEngrs" -Uroot%not24get
237
The addition will result in immediate availability of the new group account as validated by executing
240
&rootprompt; net rpc group list -Uroot%not24get
255
<indexterm><primary>POSIX</primary></indexterm>
256
<indexterm><primary>smbldap-groupadd</primary></indexterm>
257
<indexterm><primary>getent</primary></indexterm>
258
The following demonstrates that the POSIX (UNIX/Linux system account) group has been created by calling
259
the <smbconfoption name="add group script">/opt/IDEALX/sbin/smbldap-groupadd -p "%g"</smbconfoption> interface
262
&rootprompt; getent group
264
Domain Admins:x:512:root
265
Domain Users:x:513:jht,lct,ajt,met
267
Print Operators:x:550:
268
Backup Operators:x:551:
270
Domain Computers:x:553:
274
The following demonstrates that the use of the <command>net</command> command to add a group account
275
results in immediate mapping of the POSIX group that has been created to the Windows group account as shown
277
<indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>list</tertiary></indexterm>
279
&rootprompt; net groupmap list
280
Domain Admins (S-1-5-21-72630-4128915-11681869-512) -> Domain Admins
281
Domain Users (S-1-5-21-72630-4128915-11681869-513) -> Domain Users
282
Domain Guests (S-1-5-21-72630-4128915-11681869-514) -> Domain Guests
283
Print Operators (S-1-5-21-72630-4128915-11681869-550) -> Print Operators
284
Backup Operators (S-1-5-21-72630-4128915-11681869-551) -> Backup Operators
285
Replicator (S-1-5-21-72630-4128915-11681869-552) -> Replicator
286
Domain Computers (S-1-5-21-72630-4128915-11681869-553) -> Domain Computers
287
Engineers (S-1-5-21-72630-4128915-11681869-3005) -> Engineers
288
SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
295
<title>Mapping Windows Groups to UNIX Groups</title>
298
<indexterm><primary>mapped</primary></indexterm>
299
<indexterm><primary>Windows groups</primary></indexterm>
300
<indexterm><primary>system groups</primary></indexterm>
301
<indexterm><primary>access controls</primary></indexterm>
302
Windows groups must be mapped to UNIX system (POSIX) groups so that file system access controls
303
can be asserted in a manner that is consistent with the methods appropriate to the operating
304
system that is hosting the Samba server.
308
<indexterm><primary>access controls</primary></indexterm>
309
<indexterm><primary>UID</primary></indexterm>
310
<indexterm><primary>GID</primary></indexterm>
311
<indexterm><primary>locally known UID</primary></indexterm>
312
All file system (file and directory) access controls, within the file system of a UNIX/Linux server that is
313
hosting a Samba server, are implemented using a UID/GID identity tuple. Samba does not in any way override
314
or replace UNIX file system semantics. Thus it is necessary that all Windows networking operations that
315
access the file system provide a mechanism that maps a Windows user to a particular UNIX/Linux group
316
account. The user account must also map to a locally known UID. Note that the <command>net</command>
317
command does not call any RPC-functions here but directly accesses the passdb.
321
<indexterm><primary>default mappings</primary></indexterm>
322
<indexterm><primary>Domain Admins</primary></indexterm>
323
<indexterm><primary>Domain Users</primary></indexterm>
324
<indexterm><primary>Domain Guests</primary></indexterm>
325
<indexterm><primary>Windows group</primary></indexterm>
326
<indexterm><primary>UNIX group</primary></indexterm>
327
<indexterm><primary>mapping</primary></indexterm>
328
Samba depends on default mappings for the <constant>Domain Admins, Domain Users</constant>, and
329
<constant>Domain Guests</constant> global groups. Additional groups may be added as shown in the
330
examples just given. There are times when it is necessary to map an existing UNIX group account
331
to a Windows group. This operation, in effect, creates a Windows group account as a consequence
332
of creation of the mapping.
336
<indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>modify</tertiary></indexterm>
337
<indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>add</tertiary></indexterm>
338
<indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>delete</tertiary></indexterm>
339
The operations that are permitted include: <constant>add</constant>, <constant>modify</constant>,
340
and <constant>delete</constant>. An example of each operation is shown here.
344
Commencing with Samba-3.0.23 Windows Domain Groups must be explicitly created. By default, all
345
UNIX groups are exposed to Windows networking as Windows local groups.
349
An existing UNIX group may be mapped to an existing Windows group by this example:
351
&rootprompt; net groupmap modify ntgroup="Domain Users" unixgroup=users
353
An existing UNIX group may be mapped to a new Windows group as shown here:
355
&rootprompt; net groupmap add ntgroup="EliteEngrs" unixgroup=Engineers type=d
357
Supported mapping types are 'd' (domain global) and 'l' (domain local).
358
A Windows group may be deleted, and then a new Windows group can be mapped to the UNIX group by
359
executing these commands:
361
&rootprompt; net groupmap delete ntgroup=Engineers
362
&rootprompt; net groupmap add ntgroup=EngineDrivers unixgroup=Engineers type=d
364
The deletion and addition operations affected only the logical entities known as Windows groups, or domain
365
groups. These operations are inert to UNIX system groups, meaning that they neither delete nor create UNIX
366
system groups. The mapping of a UNIX group to a Windows group makes the UNIX group available as Windows
367
groups so that files and folders on domain member clients (workstations and servers) can be given
368
domain-wide access controls for domain users and groups.
372
Two types of Windows groups can be created: <constant>domain (global)</constant> and <constant>local</constant>.
373
In the previous examples the Windows groups created were of type <constant>domain</constant> or global. The
374
following command will create a Windows group of type <constant>local</constant>.
376
&rootprompt; net groupmap add ntgroup=Pixies unixgroup=pixies type=l
378
Supported mapping types are 'd' (domain global) and 'l' (domain local), a domain local group in Samba is
379
treated as local to the individual Samba server. Local groups can be used with Samba to enable multiple
380
nested group support.
386
<title>Deleting a Group Account</title>
389
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group delete</tertiary></indexterm>
390
A group account may be deleted by executing the following command:
392
&rootprompt; net rpc group delete SupportEngineers -Uroot%not24get
397
Validation of the deletion is advisable. The same commands may be executed as shown above.
403
<title>Rename Group Accounts</title>
406
This command is not documented in the man pages; it is implemented in the source code, but it does not
407
work at this time. The example given documents, from the source code, how it should work. Watch the
408
release notes of a future release to see when this may have been fixed.
412
Sometimes it is necessary to rename a group account. Good administrators know how painful some managers'
413
demands can be if this simple request is ignored. The following command demonstrates how the Windows group
414
<quote>SupportEngrs</quote> can be renamed to <quote>CustomerSupport</quote>:
415
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group rename</tertiary></indexterm>
417
&rootprompt; net rpc group rename SupportEngrs \
418
CustomerSupport -Uroot%not24get
426
<sect2 id="grpmemshipchg">
427
<title>Manipulating Group Memberships</title>
430
Three operations can be performed regarding group membership. It is possible to (1) add Windows users
431
to a Windows group, to (2) delete Windows users from Windows groups, and to (3) list the Windows users that are
432
members of a Windows group.
436
To avoid confusion, it makes sense to check group membership before attempting to make any changes.
437
The <command>getent group</command> will list UNIX/Linux group membership. UNIX/Linux group members are
438
seen also as members of a Windows group that has been mapped using the <command>net groupmap</command>
439
command (see <link linkend="groupmapping"/>). The following list of UNIX/Linux group membership shows
440
that the user <constant>ajt</constant> is a member of the UNIX/Linux group <constant>Engineers</constant>.
442
&rootprompt; getent group
444
Domain Admins:x:512:root
445
Domain Users:x:513:jht,lct,ajt,met,vlendecke
447
Print Operators:x:550:
448
Backup Operators:x:551:
450
Domain Computers:x:553:
451
Engineers:x:1000:jht,ajt
453
The UNIX/Linux groups have been mapped to Windows groups, as is shown here:
455
&rootprompt; net groupmap list
456
Domain Admins (S-1-5-21-72630-412605-116429-512) -> Domain Admins
457
Domain Users (S-1-5-21-72630-412605-116429-513) -> Domain Users
458
Domain Guests (S-1-5-21-72630-412605-116429-514) -> Domain Guests
459
Print Operators (S-1-5-21-72630-412605-116429-550) -> Print Operators
460
Backup Operators (S-1-5-21-72630-412605-116429-551) -> Backup Operators
461
Replicator (S-1-5-21-72630-412605-116429-552) -> Replicator
462
Domain Computers (S-1-5-21-72630-412605-116429-553) -> Domain Computers
463
Engineers (S-1-5-21-72630-412605-116429-3001) -> Engineers
468
Given that the user <constant>ajt</constant> is already a member of the UNIX/Linux group and, via the
469
group mapping, a member of the Windows group, an attempt to add this account again should fail. This is
471
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group addmem</tertiary></indexterm>
473
&rootprompt; net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
474
Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP
476
This shows that the group mapping between UNIX/Linux groups and Windows groups is effective and
481
To permit the user <constant>ajt</constant> to be added using the <command>net rpc group</command> utility,
482
this account must first be removed. The removal and confirmation of its effect is shown here:
483
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group delmem</tertiary></indexterm>
485
&rootprompt; net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24get
486
&rootprompt; getent group Engineers
488
&rootprompt; net rpc group members Engineers -Uroot%not24get
491
In this example both at the UNIX/Linux system level, the group no longer has the <constant>ajt</constant>
492
as a member. The above also shows this to be the case for Windows group membership.
496
The account is now added again, using the <command>net rpc group</command> utility:
498
&rootprompt; net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
499
&rootprompt; getent group Engineers
500
Engineers:x:1000:jht,ajt
501
&rootprompt; net rpc group members Engineers -Uroot%not24get
508
In this example the members of the Windows <constant>Domain Users</constant> account are validated using
509
the <command>net rpc group</command> utility. Note the this contents of the UNIX/Linux group was shown
510
four paragraphs earlier. The Windows (domain) group membership is shown here:
511
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group members</tertiary></indexterm>
513
&rootprompt; net rpc group members "Domain Users" -Uroot%not24get
520
This express example shows that Windows group names are treated by Samba (as with
521
MS Windows) in a case-insensitive manner:
523
&rootprompt; net rpc group members "DomAiN USerS" -Uroot%not24get
533
An attempt to specify the group name as <constant>MIDEARTH\Domain Users</constant> in place of
534
just simply <constant>Domain Users</constant> will fail. The default behavior of the net rpc group
535
is to direct the command at the local machine. The Windows group is treated as being local to the machine.
536
If it is necessary to query another machine, its name can be specified using the <constant>-S
537
servername</constant> parameter to the <command>net</command> command.
542
<sect2 id="nestedgrpmgmgt">
543
<title>Nested Group Support</title>
546
It is possible in Windows (and now in Samba also) to create a local group that has members (contains),
547
domain users, and domain global groups. Creation of the local group <constant>demo</constant> is
548
achieved by executing:
550
&rootprompt; net rpc group add demo -L -S MORDON -Uroot%not24get
552
The -L switch means create a local group. Use the -S argument to direct the operation to a particular
553
server. The parameters to the -U argument should be for a user who has appropriate administrative right
554
and privileges on the machine.
558
Addition and removal of group members can be achieved using the <constant>addmem</constant> and
559
<constant>delmem</constant> subcommands of <command>net rpc group</command> command. For example,
560
addition of <quote>DOM\Domain Users</quote> to the local group <constant>demo</constant> would be
563
&rootprompt; net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get
568
The members of a nested group can be listed by executing the following:
570
&rootprompt; net rpc group members demo -Uroot%not24get
579
Nested group members can be removed (deleted) as shown here:
581
&rootprompt; net rpc group delmem demo "DOM\jht" -Uroot%not24get
586
<title>Managing Nest Groups on Workstations from the Samba Server</title>
589
Windows network administrators often ask on the Samba mailing list how it is possible to grant everyone
590
administrative rights on their own workstation. This is of course a very bad practice, but commonly done
591
to avoid user complaints. Here is how it can be done remotely from a Samba PDC or BDC:
592
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group addmem</tertiary></indexterm>
594
&rootprompt; net rpc group addmem "Administrators" "Domain Users" \
595
-S WINPC032 -Uadministrator%secret
600
This can be scripted, and can therefore be performed as a user logs onto the domain from a Windows
601
workstation. Here is a simple example that shows how this can be done.
605
<title>Automating User Addition to the Workstation Power Users Group</title>
608
Create the script shown in <link linkend="autopoweruserscript"></link> and locate it in
609
the directory <filename>/etc/samba/scripts</filename>, named as <filename>autopoweruser.sh</filename>.
610
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group addmem</tertiary></indexterm>
611
<indexterm><primary>autopoweruser.sh</primary></indexterm>
612
<indexterm><primary>/etc/samba/scripts</primary></indexterm>
615
<example id="autopoweruserscript">
616
<title>Script to Auto-add Domain Users to Workstation Power Users Group</title>
620
/usr/bin/net rpc group addmem "Power Users" "DOMAIN_NAME\$1" \
621
-UAdministrator%secret -S $2
628
Set the permissions on this script to permit it to be executed as part of the logon process:
630
&rootprompt; chown root:root /etc/samba/autopoweruser.sh
631
&rootprompt; chmod 755 /etc/samba/autopoweruser.sh
636
Modify the &smb.conf; file so the <literal>NETLOGON</literal> stanza contains the parameters
637
shown in <link linkend="magicnetlogon">the Netlogon Example smb.conf file</link>.
640
<example id="magicnetlogon">
641
<title>A Magic Netlogon Share</title>
643
<smbconfsection name="[netlogon]"/>
644
<smbconfoption name="comment">Netlogon Share</smbconfoption>
645
<smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
646
<smbconfoption name="root preexec">/etc/samba/scripts/autopoweruser.sh %U %m</smbconfoption>
647
<smbconfoption name="read only">Yes</smbconfoption>
648
<smbconfoption name="guest ok">Yes</smbconfoption>
653
Ensure that every Windows workstation Administrator account has the same password that you
654
have used in the script shown in <link linkend="magicnetlogon">the Netlogon Example smb.conf
661
This script will be executed every time a user logs on to the network. Therefore every user will
662
have local Windows workstation management rights. This could of course be assigned using a group,
663
in which case there is little justification for the use of this procedure. The key justification
664
for the use of this method is that it will guarantee that all users have appropriate rights on
675
<title>UNIX and Windows User Management</title>
678
<indexterm><primary>user account</primary></indexterm>
679
<indexterm><primary>UNIX/Linux user account</primary></indexterm>
680
<indexterm><primary>UID</primary></indexterm>
681
<indexterm><primary>POSIX account</primary></indexterm>
682
<indexterm><primary>range</primary></indexterm>
683
<indexterm><primary>Windows user accounts</primary></indexterm>
684
<indexterm><primary>winbindd</primary></indexterm>
685
<indexterm><primary>account information</primary></indexterm>
686
Every Windows network user account must be translated to a UNIX/Linux user account. In actual fact,
687
the only account information the UNIX/Linux Samba server needs is a UID. The UID is available either
688
from a system (POSIX) account or from a pool (range) of UID numbers that is set aside for the purpose
689
of being allocated for use by Windows user accounts. In the case of the UID pool, the UID for a
690
particular user will be allocated by <command>winbindd</command>.
694
Although this is not the appropriate place to discuss the <smbconfoption name="username map"/> facility,
695
this interface is an important method of mapping a Windows user account to a UNIX account that has a
696
different name. Refer to the man page for the &smb.conf; file for more information regarding this
697
facility. User name mappings cannot be managed using the <command>net</command> utility.
700
<sect2 id="sbeuseraddn">
701
<title>Adding User Accounts</title>
704
The syntax for adding a user account via the <command>net</command> (according to the man page) is shown
707
net [<method>] user ADD <name> [-c container] [-F user flags] \
708
[misc. options] [targets]
710
The user account password may be set using this syntax:
712
net rpc password <username> [<password>] -Uadmin_username%admin_pass
717
The following demonstrates the addition of an account to the server <constant>FRODO</constant>:
718
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user add</tertiary></indexterm>
719
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user password</tertiary></indexterm>
721
&rootprompt; net rpc user add jacko -S FRODO -Uroot%not24get
724
The account password can be set with the following methods (all show the same operation):
726
&rootprompt; net rpc password jacko f4sth0rse -S FRODO -Uroot%not24get
727
&rootprompt; net rpc user password jacko f4sth0rse \
728
-S FRODO -Uroot%not24get
735
<title>Deletion of User Accounts</title>
738
Deletion of a user account can be done using the following syntax:
740
net [<method>] user DELETE <name> [misc. options] [targets]
742
The following command will delete the user account <constant>jacko</constant>:
743
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user delete</tertiary></indexterm>
745
&rootprompt; net rpc user delete jacko -Uroot%not24get
753
<title>Managing User Accounts</title>
756
Two basic user account operations are routinely used: change of password and querying which groups a user
757
is a member of. The change of password operation is shown in <link linkend="sbeuseraddn"/>.
761
The ability to query Windows group membership can be essential. Here is how a remote server may be
762
interrogated to find which groups a user is a member of:
763
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user info</tertiary></indexterm>
765
&rootprompt; net rpc user info jacko -S SAURON -Uroot%not24get
766
net rpc user info jacko -S SAURON -Uroot%not24get
777
It is also possible to rename user accounts:
778
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user rename</tertiary></indexterm>oldusername newusername
779
Note that this operation does not yet work against Samba Servers. It is, however, possible to rename useraccounts on
787
<title>User Mapping</title>
790
<indexterm><primary>logon name</primary></indexterm>
791
<indexterm><primary>/etc/samba/smbusers</primary></indexterm>
792
<indexterm><primary>username map</primary></indexterm>
793
In some situations it is unavoidable that a user's Windows logon name will differ from the login ID
794
that user has on the Samba server. It is possible to create a special file on the Samba server that
795
will permit the Windows user name to be mapped to a different UNIX/Linux user name. The &smb.conf;
796
file must also be amended so that the <constant>[global]</constant> stanza contains the parameter:
798
username map = /etc/samba/smbusers
800
The content of the <filename>/etc/samba/smbusers</filename> file is shown here:
802
parsonsw: "William Parsons"
805
In this example the Windows user account <quote>William Parsons</quote> will be mapped to the UNIX user
806
<constant>parsonsw</constant>, and the Windows user account <quote>geeringm</quote> will be mapped to the
807
UNIX user <constant>marygee</constant>.
815
<title>Administering User Rights and Privileges</title>
818
<indexterm><primary>credentials</primary></indexterm>
819
<indexterm><primary>manage printers</primary></indexterm>
820
<indexterm><primary>manage shares</primary></indexterm>
821
<indexterm><primary>manage groups</primary></indexterm>
822
<indexterm><primary>manage users</primary></indexterm>
823
With all versions of Samba earlier than 3.0.11 the only account on a Samba server that could
824
manage users, groups, shares, printers, and such was the <constant>root</constant> account. This caused
825
problems for some users and was a frequent source of scorn over the necessity to hand out the
826
credentials for the most security-sensitive account on a UNIX/Linux system.
830
<indexterm><primary>delegate administrative privileges</primary></indexterm>
831
<indexterm><primary>normal user</primary></indexterm>
832
<indexterm><primary>rights and privilege</primary></indexterm>
833
<indexterm><primary>privilege management</primary></indexterm>
834
<indexterm><primary>groups of users</primary></indexterm>
835
New to Samba version 3.0.11 is the ability to delegate administrative privileges as necessary to either
836
a normal user or to groups of users. The significance of the administrative privileges is documented
837
in <link linkend="rights"/>. Examples of use of the <command>net</command> for user rights and privilege
838
management is appropriate to this chapter.
842
When user rights and privileges are correctly set, there is no longer a need for a Windows
843
network account for the <constant>root</constant> user (nor for any synonym of it) with a UNIX UID=0.
844
Initial user rights and privileges can be assigned by any account that is a member of the <constant>
845
Domain Admins</constant> group. Rights can be assigned to user as well as group accounts.
849
By default, no privileges and rights are assigned. This is demonstrated by executing the command
852
&rootprompt; net rpc rights list accounts -U root%not24get
853
BUILTIN\Print Operators
854
No privileges assigned
856
BUILTIN\Account Operators
857
No privileges assigned
859
BUILTIN\Backup Operators
860
No privileges assigned
862
BUILTIN\Server Operators
863
No privileges assigned
865
BUILTIN\Administrators
866
No privileges assigned
869
No privileges assigned
874
The <command>net</command> command can be used to obtain the currently supported capabilities for rights
875
and privileges using this method:
876
<indexterm><primary>SeMachineAccountPrivilege</primary></indexterm>
877
<indexterm><primary>SePrintOperatorPrivilege</primary></indexterm>
878
<indexterm><primary>SeAddUsersPrivilege</primary></indexterm>
879
<indexterm><primary>SeRemoteShutdownPrivilege</primary></indexterm>
880
<indexterm><primary>SeDiskOperatorPrivilege</primary></indexterm>
881
<indexterm><primary>SeBackupPrivilege</primary></indexterm>
882
<indexterm><primary>SeRestorePrivilege</primary></indexterm>
883
<indexterm><primary>SeTakeOwnershipPrivilege</primary></indexterm>
884
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>rights list</tertiary></indexterm>
886
&rootprompt; net rpc rights list -U root%not24get
887
SeMachineAccountPrivilege Add machines to domain
888
SePrintOperatorPrivilege Manage printers
889
SeAddUsersPrivilege Add users and groups to the domain
890
SeRemoteShutdownPrivilege Force shutdown from a remote system
891
SeDiskOperatorPrivilege Manage disk shares
892
SeBackupPrivilege Back up files and directories
893
SeRestorePrivilege Restore files and directories
894
SeTakeOwnershipPrivilege Take ownership of files or other objects
896
Machine account privilege is necessary to permit a Windows NT4 or later network client to be added to the
897
domain. The disk operator privilege is necessary to permit the user to manage share ACLs and file and
898
directory ACLs for objects not owned by the user.
902
In this example, all rights are assigned to the <constant>Domain Admins</constant> group. This is a good
903
idea since members of this group are generally expected to be all-powerful. This assignment makes that
905
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>rights grant</tertiary></indexterm>
907
&rootprompt; net rpc rights grant "MIDEARTH\Domain Admins" \
908
SeMachineAccountPrivilege SePrintOperatorPrivilege \
909
SeAddUsersPrivilege SeRemoteShutdownPrivilege \
910
SeDiskOperatorPrivilege -U root%not24get
911
Successfully granted rights.
913
Next, the domain user <constant>jht</constant> is given the privileges needed for day-to-day
916
&rootprompt; net rpc rights grant "MIDEARTH\jht" \
917
SeMachineAccountPrivilege SePrintOperatorPrivilege \
918
SeAddUsersPrivilege SeDiskOperatorPrivilege \
920
Successfully granted rights.
925
The following step permits validation of the changes just made:
926
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>rights list accounts</tertiary></indexterm>
928
&rootprompt; net rpc rights list accounts -U root%not24get
930
SeMachineAccountPrivilege
931
SePrintOperatorPrivilege
933
SeDiskOperatorPrivilege
935
BUILTIN\Print Operators
936
No privileges assigned
938
BUILTIN\Account Operators
939
No privileges assigned
941
BUILTIN\Backup Operators
942
No privileges assigned
944
BUILTIN\Server Operators
945
No privileges assigned
947
BUILTIN\Administrators
948
No privileges assigned
951
No privileges assigned
953
MIDEARTH\Domain Admins
954
SeMachineAccountPrivilege
955
SePrintOperatorPrivilege
957
SeRemoteShutdownPrivilege
958
SeDiskOperatorPrivilege
965
<title>Managing Trust Relationships</title>
968
There are essentially two types of trust relationships: the first is between domain controllers and domain
969
member machines (network clients), the second is between domains (called interdomain trusts). All
970
Samba servers that participate in domain security require a domain membership trust account, as do like
971
Windows NT/200x/XP workstations.
975
<title>Machine Trust Accounts</title>
978
The net command looks in the &smb.conf; file to obtain its own configuration settings. Thus, the following
979
command 'knows' which domain to join from the &smb.conf; file.
983
A Samba server domain trust account can be validated as shown in this example:
984
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>testjoin</tertiary></indexterm>
986
&rootprompt; net rpc testjoin
987
Join to 'MIDEARTH' is OK
989
Where there is no domain membership account, or when the account credentials are not valid, the following
990
results will be observed:
992
net rpc testjoin -S DOLPHIN
993
Join to domain 'WORLDOCEAN' is not valid
998
The equivalent command for joining a Samba server to a Windows ADS domain is shown here:
999
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>testjoin</tertiary></indexterm>
1001
&rootprompt; net ads testjoin
1002
Using short domain name -- TAKEAWAY
1003
Joined 'LEMONADE' to realm 'TAKEAWAY.BIZ'
1005
In the event that the ADS trust was not established, or is broken for one reason or another, the following
1006
error message may be obtained:
1008
&rootprompt; net ads testjoin -UAdministrator%secret
1009
Join to domain is not valid
1014
The following demonstrates the process of creating a machine trust account in the target domain for the
1015
Samba server from which the command is executed:
1016
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
1018
&rootprompt; net rpc join -S FRODO -Uroot%not24get
1019
Joined domain MIDEARTH.
1021
The joining of a Samba server to a Samba domain results in the creation of a machine account. An example
1022
of this is shown here:
1024
&rootprompt; pdbedit -Lw merlin\$
1025
merlin$:1009:9B4489D6B90461FD6A3EC3AB96147E16:\
1026
176D8C554E99914BDF3407DEA2231D80:[S ]:LCT-42891919:
1028
The S in the square brackets means this is a server (PDC/BDC) account. The domain join can be cast to join
1029
purely as a workstation, in which case the S is replaced with a W (indicating a workstation account). The
1030
following command can be used to affect this:
1031
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join member</tertiary></indexterm>
1033
&rootprompt; net rpc join member -S FRODO -Uroot%not24get
1034
Joined domain MIDEARTH.
1036
Note that the command-line parameter <constant>member</constant> makes this join specific. By default
1037
the type is deduced from the &smb.conf; file configuration. To specifically join as a PDC or BDC, the
1038
command-line parameter will be <constant>[PDC | BDC]</constant>. For example:
1039
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join bdc</tertiary></indexterm>
1041
&rootprompt; net rpc join bdc -S FRODO -Uroot%not24get
1042
Joined domain MIDEARTH.
1044
It is best to let Samba figure out the domain join type from the settings in the &smb.conf; file.
1048
The command to join a Samba server to a Windows ADS domain is shown here:
1049
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>join</tertiary></indexterm>
1051
&rootprompt; net ads join -UAdministrator%not24get
1052
Using short domain name -- GDANSK
1053
Joined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ'
1058
There is no specific option to remove a machine account from an NT4 domain. When a domain member that is a
1059
Windows machine is withdrawn from the domain, the domain membership account is not automatically removed
1060
either. Inactive domain member accounts can be removed using any convenient tool. If necessary, the
1061
machine account can be removed using the following <command>net</command> command:
1062
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>user delete</tertiary></indexterm>
1064
&rootprompt; net rpc user delete HERRING\$ -Uroot%not24get
1065
Deleted user account.
1067
The removal is made possible because machine accounts are just like user accounts with a trailing $
1068
character. The account management operations treat user and machine accounts in like manner.
1072
A Samba-3 server that is a Windows ADS domain member can execute the following command to detach from the
1074
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>leave</tertiary></indexterm>
1076
&rootprompt; net ads leave
1081
Detailed information regarding an ADS domain can be obtained by a Samba DMS machine by executing the
1083
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>status</tertiary></indexterm>
1085
&rootprompt; net ads status
1087
The volume of information is extensive. Please refer to the book <quote>Samba-3 by Example</quote>,
1088
Chapter 7 for more information regarding its use. This book may be obtained either in print or online from
1089
the <ulink url="http://www.samba.org/samba/docs/Samba3-ByExample.pdf">Samba-3 by Example</ulink>.
1095
<title>Interdomain Trusts</title>
1098
Interdomain trust relationships form the primary mechanism by which users from one domain can be granted
1099
access rights and privileges in another domain.
1103
To discover what trust relationships are in effect, execute this command:
1104
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom list</tertiary></indexterm>
1106
&rootprompt; net rpc trustdom list -Uroot%not24get
1107
Trusted domains list:
1111
Trusting domains list:
1115
There are no interdomain trusts at this time; the following steps will create them.
1119
It is necessary to create a trust account in the local domain. A domain controller in a second domain can
1120
create a trusted connection with this account. That means that the foreign domain is being trusted
1121
to access resources in the local domain. This command creates the local trust account:
1122
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom add</tertiary></indexterm>
1124
&rootprompt; net rpc trustdom add DAMNATION f00db4r -Uroot%not24get
1126
The account can be revealed by using the <command>pdbedit</command> as shown here:
1128
&rootprompt; pdbedit -Lw DAMNATION\$
1129
DAMNATION$:1016:9AC1F121DF897688AAD3B435B51404EE: \
1130
7F845808B91BB9F7FEF44B247D9DC9A6:[I ]:LCT-428934B1:
1132
A trust account will always have an I in the field within the square brackets.
1136
If the trusting domain is not capable of being reached, the following command will fail:
1137
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom list</tertiary></indexterm>
1139
&rootprompt; net rpc trustdom list -Uroot%not24get
1140
Trusted domains list:
1144
Trusting domains list:
1146
DAMNATION S-1-5-21-1385457007-882775198-1210191635
1148
The above command executed successfully; a failure is indicated when the following response is obtained:
1150
net rpc trustdom list -Uroot%not24get
1151
Trusted domains list:
1153
DAMNATION S-1-5-21-1385457007-882775198-1210191635
1155
Trusting domains list:
1157
DAMNATION domain controller is not responding
1162
Where a trust account has been created on a foreign domain, Samba is able to establish the trust (connect with)
1163
the foreign account. In the process it creates a one-way trust to the resources on the remote domain. This
1164
command achieves the objective of joining the trust relationship:
1165
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom establish</tertiary></indexterm>
1167
&rootprompt; net rpc trustdom establish DAMNATION
1168
Password: xxxxxxx == f00db4r
1169
Could not connect to server TRANSGRESSION
1170
Trust to domain DAMNATION established
1172
Validation of the two-way trust now established is possible as shown here:
1174
&rootprompt; net rpc trustdom list -Uroot%not24get
1175
Trusted domains list:
1177
DAMNATION S-1-5-21-1385457007-882775198-1210191635
1179
Trusting domains list:
1181
DAMNATION S-1-5-21-1385457007-882775198-1210191635
1186
Sometimes it is necessary to remove the ability for local users to access a foreign domain. The trusting
1187
connection can be revoked as shown here:
1188
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>trustdom revoke</tertiary></indexterm>
1190
&rootprompt; net rpc trustdom revoke DAMNATION -Uroot%not24get
1192
At other times it becomes necessary to remove the ability for users from a foreign domain to be able to
1193
access resources in the local domain. The command shown here will do that:
1195
&rootprompt; net rpc trustdom del DAMNATION -Uroot%not24get
1205
<title>Managing Security Identifiers (SIDS)</title>
1208
<indexterm><primary>security identifier</primary></indexterm>
1209
<indexterm><primary>SID</primary></indexterm>
1210
<indexterm><primary>desktop profiles</primary></indexterm>
1211
<indexterm><primary>user encoded</primary></indexterm>
1212
<indexterm><primary>group SID</primary></indexterm>
1213
The basic security identifier that is used by all Windows networking operations is the Windows security
1214
identifier (SID). All Windows network machines (servers and workstations), users, and groups are
1215
identified by their respective SID. All desktop profiles are also encoded with user and group SIDs that
1216
are specific to the SID of the domain to which the user belongs.
1220
<indexterm><primary>machine SID</primary></indexterm>
1221
<indexterm><primary>domain SID</primary></indexterm>
1222
<indexterm><primary>SID</primary></indexterm>
1223
<indexterm><primary>rejoin</primary></indexterm>
1224
It is truly prudent to store the machine and/or domain SID in a file for safekeeping. Why? Because
1225
a change in hostname or in the domain (workgroup) name may result in a change in the SID. When you
1226
have the SID on hand, it is a simple matter to restore it. The alternative is to suffer the pain of
1227
having to recover user desktop profiles and perhaps rejoin all member machines to the domain.
1231
First, do not forget to store the local SID in a file. It is a good idea to put this in the directory
1232
in which the &smb.conf; file is also stored. Here is a simple action to achieve this:
1233
<indexterm><primary>net</primary><secondary>getlocalsid</secondary></indexterm>
1235
&rootprompt; net getlocalsid > /etc/samba/my-sid
1237
Good, there is now a safe copy of the local machine SID. On a PDC/BDC this is the domain SID also.
1241
The following command reveals what the former one should have placed into the file called
1242
<filename>my-sid</filename>:
1244
&rootprompt; net getlocalsid
1245
SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429
1250
If ever it becomes necessary to restore the SID that has been stored in the <filename>my-sid</filename>
1251
file, simply copy the SID (the string of characters that begins with <constant>S-1-5-21</constant>) to
1252
the command line shown here:
1253
<indexterm><primary>net</primary><secondary>setlocalsid</secondary></indexterm>
1255
&rootprompt; net setlocalsid S-1-5-21-1385457007-882775198-1210191635
1257
Restoration of a machine SID is a simple operation, but the absence of a backup copy can be very
1262
The following operation is useful only for machines that are being configured as a PDC or a BDC.
1263
DMS and workstation clients should have their own machine SID to avoid
1264
any potential namespace collision. Here is the way that the BDC SID can be synchronized to that
1265
of the PDC (this is the default NT4 domain practice also):
1266
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>getsid</tertiary></indexterm>
1268
&rootprompt; net rpc getsid -S FRODO -Uroot%not24get
1269
Storing SID S-1-5-21-726309263-4128913605-1168186429 \
1270
for Domain MIDEARTH in secrets.tdb
1272
Usually it is not necessary to specify the target server (-S FRODO) or the administrator account
1273
credentials (-Uroot%not24get).
1279
<title>Share Management</title>
1282
Share management is central to all file serving operations. Typical share operations include:
1286
<listitem><para>Creation/change/deletion of shares</para></listitem>
1287
<listitem><para>Setting/changing ACLs on shares</para></listitem>
1288
<listitem><para>Moving shares from one server to another</para></listitem>
1289
<listitem><para>Change of permissions of share contents</para></listitem>
1293
Each of these are dealt with here insofar as they involve the use of the <command>net</command>
1294
command. Operations outside of this command are covered elsewhere in this document.
1298
<title>Creating, Editing, and Removing Shares</title>
1301
A share can be added using the <command>net rpc share</command> command capabilities.
1302
The target machine may be local or remote and is specified by the -S option. It must be noted
1303
that the addition and deletion of shares using this tool depends on the availability of a suitable
1304
interface script. The interface scripts Sambas <command>smbd</command> uses are called
1305
<smbconfoption name="add share command"/>, <smbconfoption name="delete share command"/> and
1306
<smbconfoption name="change share command"/> A set of example scripts are provided in the Samba source
1307
code tarball in the directory <filename>~samba/examples/scripts</filename>.
1311
The following steps demonstrate the use of the share management capabilities of the <command>net</command>
1312
utility. In the first step a share called <constant>Bulge</constant> is added. The sharepoint within the
1313
file system is the directory <filename>/data</filename>. The command that can be executed to perform the
1314
addition of this share is shown here:
1315
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share add</tertiary></indexterm>
1317
&rootprompt; net rpc share add Bulge=/data -S MERLIN -Uroot%not24get
1319
Validation is an important process, and by executing the command <command>net rpc share</command>
1320
with no other operators it is possible to obtain a listing of available shares, as shown here:
1322
&rootprompt; net rpc share -S MERLIN -Uroot%not24get
1325
Bulge <--- This one was added
1336
Often it is desirable also to permit a share to be removed using a command-line tool.
1337
The following step permits the share that was previously added to be removed:
1338
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share delete</tertiary></indexterm>
1340
&rootprompt; net rpc share delete Bulge -S MERLIN -Uroot%not24get
1342
A simple validation shown here demonstrates that the share has been removed:
1344
&rootprompt; net rpc share -S MERLIN -Uroot%not24get
1359
<title>Creating and Changing Share ACLs</title>
1362
At this time the <command>net</command> tool cannot be used to manage ACLs on Samba shares. In MS Windows
1363
language this is called Share Permissions.
1367
It is possible to set ACLs on Samba shares using either the SRVTOOLS NT4 Domain Server Manager
1368
or using the Computer Management MMC snap-in. Neither is covered here,
1369
but see <link linkend="AccessControls"/>.
1375
<title>Share, Directory, and File Migration</title>
1378
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>vampire</tertiary></indexterm>
1379
Shares and files can be migrated in the same manner as user, machine, and group accounts.
1380
It is possible to preserve access control settings (ACLs) as well as security settings
1381
throughout the migration process. The <command>net rpc vampire</command> facility is used
1382
to migrate accounts from a Windows NT4 (or later) domain to a Samba server. This process
1383
preserves passwords and account security settings and is a precursor to the migration
1384
of shares and files.
1388
The <command>net rpc share</command> command may be used to migrate shares, directories,
1389
files, and all relevant data from a Windows server to a Samba server.
1393
A set of command-line switches permit the creation of almost direct clones of Windows file
1394
servers. For example, when migrating a fileserver, file ACLs and DOS file attributes from
1395
the Windows server can be included in the migration process and will reappear, almost identically,
1396
on the Samba server when the migration has been completed.
1400
The migration process can be completed only with the Samba server already being fully operational.
1401
The user and group accounts must be migrated before attempting to migrate data
1402
share, files, and printers. The migration of files and printer configurations involves the use
1403
of both SMB and MS DCE RPC services. The benefit of the manner in which the migration process has
1404
been implemented is that the possibility now exists to use a Samba server as a man-in-middle migration
1405
service that affects a transfer of data from one server to another. For example, if the Samba
1406
server is called MESSER, the source Windows NT4 server is called PEPPY, and the target Samba
1407
server is called GONZALES, the machine MESSER can be used to effect the migration of all data
1408
(files and shares) from PEPPY to GONZALES. If the target machine is not specified, the local
1409
server is assumed by default - as net's general rule of thumb .
1413
The success of server migration requires a firm understanding of the structure of the source
1414
server (or domain) as well as the processes on which the migration is critically dependant.
1418
There are two known limitations to the migration process:
1423
The <command>net</command> command requires that the user credentials provided exist on both
1424
the migration source and the migration target.
1428
Printer settings may not be fully or may be incorrectly migrated. This might in particular happen
1429
when migrating a Windows 2003 print server to Samba.
1434
<title>Share Migration</title>
1437
The <command>net rpc share migrate</command> command operation permits the migration of plain
1438
share stanzas. A stanza contains the parameters within which a file or print share are defined.
1439
The use of this migration method will create share stanzas that have as parameters the file
1440
system directory path, an optional description, and simple security settings that permit write
1441
access to files. One of the first steps necessary following migration is to review the share
1442
stanzas to ensure that the settings are suitable for use.
1446
The shares are created on the fly as part of the migration process. The <command>smbd</command>
1447
application does this by calling on the operating system to execute the script specified by the
1448
&smb.conf; parameter <parameter>add share command</parameter>.
1452
There is a suitable example script for the <parameter>add share command</parameter> in the
1453
<filename>$SAMBA_SOURCES/examples/scripts</filename> directory. It should be noted that
1454
the account that is used to drive the migration must, of necessity, have appropriate file system
1455
access privileges and have the right to create shares and to set ACLs on them. Such rights are
1456
conferred by these rights: <parameter>SeAddUsersPrivilege</parameter> and <parameter>SeDiskOperatorPrivilege</parameter>.
1457
For more information regarding rights and privileges please refer to <link linkend="rights"/>.
1461
The syntax of the share migration command is shown here:
1463
net rpc share MIGRATE SHARES <share-name> -S <source>
1464
[--destination=localhost] [--exclude=share1,share2] [-v]
1466
When the parameter <share-name> is omitted, all shares will be migrated. The potentially
1467
large list of available shares on the system that is being migrated can be limited using the
1468
<parameter>--exclude</parameter> switch. For example:
1469
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share migrate</tertiary></indexterm>
1471
&rootprompt; net rpc share migrate shares myshare\
1472
-S win2k -U administrator%secret"
1474
This will migrate the share <constant>myshare</constant> from the server <constant>win2k</constant>
1475
to the Samba Server using the permissions that are tied to the account <constant>administrator</constant>
1476
with the password <constant>secret</constant>. The account that is used must be the same on both the
1477
migration source server and the target Samba server. The use of the <command>net rpc
1478
vampire</command>, prior to attempting the migration of shares, will ensure that accounts will be
1479
identical on both systems. One precaution worth taking before commencement of migration of shares is
1480
to validate that the migrated accounts (on the Samba server) have the needed rights and privileges.
1481
This can be done as shown here:
1482
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>right list accounts</tertiary></indexterm>
1484
&rootprompt; net rpc right list accounts -Uroot%not24get
1486
The steps taken so far perform only the migration of shares. Directories and directory contents
1487
are not migrated by the steps covered up to this point.
1493
<title>File and Directory Migration</title>
1496
Everything covered to this point has been done in preparation for the migration of file and directory
1497
data. For many people preparation is potentially boring and the real excitement only begins when file
1498
data can be used. The next steps demonstrate the techniques that can be used to transfer (migrate)
1499
data files using the <command>net</command> command.
1503
Transfer of files from one server to another has always been a challenge for MS Windows
1504
administrators because Windows NT and 200X servers do not always include the tools needed. The
1505
<command>xcopy</command> from Windows NT is not capable of preserving file and directory ACLs,
1506
it does so only with Windows 200x. Microsoft does provide a
1507
utility that can copy ACLs (security settings) called <command>scopy</command>, but it is provided only
1508
as part of the Windows NT or 200X Server Resource Kit.
1512
There are several tools, both commercial and freeware, that can be used from a Windows server to copy files
1513
and directories with full preservation of security settings. One of the best known of the free tools is
1514
called <command>robocopy</command>.
1518
The <command>net</command> utility can be used to copy files and directories with full preservation of
1519
ACLs as well as DOS file attributes. Note that including ACLs makes sense only where the destination
1520
system will operate within the same security context as the source system. This applies both to a
1521
DMS and to domain controllers that result from a vampired domain.
1522
Before file and directory migration, all shares must already exist.
1526
The syntax for the migration commands is shown here:
1528
net rpc share MIGRATE FILES <share-name> -S <source>
1529
[--destination=localhost] [--exclude=share1,share2]
1530
[--acls] [--attrs] [--timestamps] [-v]
1532
If the <share-name> parameter is omitted, all shares will be migrated. The potentially large
1533
list of shares on the source system can be restricted using the <parameter>--exclude</parameter> command
1538
Where it is necessary to preserve all file ACLs, the <parameter>--acls</parameter> switch should be added
1539
to the above command line. Original file timestamps can be preserved by specifying the
1540
<parameter>--timestamps</parameter> switch, and the DOS file attributes (i.e., hidden, archive, etc.) can
1541
be preserved by specifying the <parameter>--attrs</parameter> switch.
1545
The ability to preserve ACLs depends on appropriate support for ACLs as well as the general file system
1546
semantics of the host operating system on the target server. A migration from one Windows file server to
1547
another will perfectly preserve all file attributes. Because of the difficulty of mapping Windows ACLs
1548
onto a POSIX ACLs-supporting system, there can be no perfect migration of Windows ACLs to a Samba server.
1552
The ACLs that result on a Samba server will most probably not match the originating ACLs. Windows supports
1553
the possibility of files that are owned only by a group. Group-alone file ownership is not possible under
1554
UNIX/Linux. Errors in migrating group-owned files can be avoided by using the &smb.conf; file
1555
<smbconfoption name="force unknown acl user">yes</smbconfoption> parameter. This facility will
1556
automatically convert group-owned files into correctly user-owned files on the Samba server.
1560
An example for migration of files from a machine called <constant>nt4box</constant> to the Samba server
1561
from which the process will be handled is shown here:
1562
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share migrate files</tertiary></indexterm>
1564
&rootprompt; net rpc share migrate files -S nt4box --acls \
1565
--attrs -U administrator%secret
1570
This command will migrate all files and directories from all file shares on the Windows server called
1571
<constant>nt4box</constant> to the Samba server from which migration is initiated. Files that are group-owned
1572
will be owned by the user account <constant>administrator</constant>.
1578
<title>Share-ACL Migration</title>
1580
It is possible to have share-ACLs (security descriptors) that won't allow you, even as Administrator, to
1581
copy any files or directories into it. Therefor the migration of the share-ACLs has been put into a separate
1583
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share migrate security</tertiary></indexterm>
1585
&rootprompt; net rpc share migrate security -S nt4box -U administrator%secret
1590
This command will only copy the share-ACL of each share on nt4box to your local samba-system.
1595
<title>Simultaneous Share and File Migration</title>
1598
The operating mode shown here is just a combination of the previous three. It first migrates
1599
share definitions and then all shared files and directories and finally migrates the share-ACLs:
1601
net rpc share MIGRATE ALL <share-name> -S <source>
1602
[--exclude=share1, share2] [--acls] [--attrs] [--timestamps] [-v]
1607
An example of simultaneous migration is shown here:
1608
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share migrate all</tertiary></indexterm>
1610
&rootprompt; net rpc share migrate all -S w2k3server -U administrator%secret
1612
This will generate a complete server clone of the <parameter>w2k3server</parameter> server.
1620
<title>Printer Migration</title>
1623
The installation of a new server, as with the migration to a new network environment, often is similar to
1624
building a house; progress is very rapid from the laying of foundations up to the stage at which
1625
the house can be locked up, but the finishing off appears to take longer and longer as building
1626
approaches completion.
1630
Printing needs vary greatly depending on the network environment and may be very simple or complex. If
1631
the need is very simple, the best solution to the implementation of printing support may well be to
1632
re-install everything from a clean slate instead of migrating older configurations. On the other hand,
1633
a complex network that is integrated with many international offices and a multiplexity of local branch
1634
offices, each of which form an inter-twined maze of printing possibilities, the ability to migrate all
1635
printer configurations is decidedly beneficial. To manually re-establish a complex printing network
1636
will take much time and frustration. Often it will not be possible to find driver files that are
1637
currently in use, necessitating the installation of newer drivers. Newer drivers often implement
1638
printing features that will necessitate a change in the printer usage. Additionally, with very complex
1639
printer configurations it becomes almost impossible to re-create the same environment &smbmdash; no matter
1640
how extensively it has been documented.
1644
The migration of an existing printing architecture involves the following:
1648
<listitem><para>Establishment of print queues.</para></listitem>
1650
<listitem><para>Installation of printer drivers (both for the print server and for Windows clients.</para></listitem>
1652
<listitem><para>Configuration of printing forms.</para></listitem>
1654
<listitem><para>Implementation of security settings.</para></listitem>
1656
<listitem><para>Configuration of printer settings.</para></listitem>
1660
The Samba <command>net</command> utility permits printer migration from one Windows print server
1661
to another. When this tool is used to migrate printers to a Samba server <command>smbd</command>,
1662
the application that receives the network requests to create the necessary services must call out
1663
to the operating system in order to create the underlying printers. The call-out is implemented
1664
by way of an interface script that can be specified by the &smb.conf; file parameter
1665
<smbconfoption id="add printer script"/>. This script is essential to the migration process.
1666
A suitable example script may be obtained from the <filename>$SAMBA_SOURCES/examples/scripts</filename>
1667
directory. Take note that this script must be customized to suit the operating system environment
1668
and may use its tools to create a print queue.
1672
Each of the components listed above can be completed separately, or they can be completed as part of an
1673
automated operation. Many network administrators prefer to deal with migration issues in a manner that
1674
gives them the most control, particularly when things go wrong. The syntax for each operation is now
1679
Printer migration from a Windows print server (NT4 or 200x) is shown. This instruction causes the
1680
printer share to be created together with the underlying print queue:
1681
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate printers</tertiary></indexterm>
1683
net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets]
1685
Printer drivers can be migrated from the Windows print server to the Samba server using this
1686
command-line instruction:
1687
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate drivers</tertiary></indexterm>
1689
net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]
1691
Printer forms can be migrated with the following operation:
1692
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate forms</tertiary></indexterm>
1694
net rpc printer MIGRATE FORMS [printer] [misc. options] [targets]
1696
Printer security settings (ACLs) can be migrated from the Windows server to the Samba server using this command:
1697
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate security</tertiary></indexterm>
1699
net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]
1701
Printer configuration settings include factors such as paper size and default paper orientation.
1702
These can be migrated from the Windows print server to the Samba server with this command:
1703
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate settings</tertiary></indexterm>
1705
net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]
1710
Migration of printers including the above-mentioned sets of information may be completed
1711
with a single command using this syntax:
1713
net rpc printer MIGRATE ALL [printer] [misc. options] [targets]
1722
<title>Controlling Open Files</title>
1725
The man page documents the <command>net file</command> function suite, which provides the tools to
1726
close open files using either RAP or RPC function calls. Please refer to the man page for specific
1733
<title>Session and Connection Management</title>
1736
The session management interface of the <command>net session</command> command uses the old RAP
1737
method to obtain the list of connections to the Samba server, as shown here:
1738
<indexterm><primary>net</primary><secondary>rap</secondary><tertiary>session</tertiary></indexterm>
1740
&rootprompt; net rap session -S MERLIN -Uroot%not24get
1741
Computer User name Client Type Opens Idle time
1742
------------------------------------------------------------------------------
1743
\\merlin root Unknown Client 0 00:00:00
1744
\\marvel jht Unknown Client 0 00:00:00
1745
\\maggot jht Unknown Client 0 00:00:00
1746
\\marvel jht Unknown Client 0 00:00:00
1751
A session can be closed by executing a command as shown here:
1753
&rootprompt; net rap session close marvel -Uroot%not24get
1760
<title>Printers and ADS</title>
1763
When Samba-3 is used within an MS Windows ADS environment, printers shared via Samba will not be browseable
1764
until they have been published to the ADS domain. Information regarding published printers may be obtained
1765
from the ADS server by executing the <command>net ads print info</command> command following this syntax:
1766
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>printer info</tertiary></indexterm>
1768
net ads printer info <printer_name> <server_name> -Uadministrator%secret
1770
If the asterisk (*) is used in place of the printer_name argument, a list of all printers will be
1775
To publish (make available) a printer to ADS, execute the following command:
1776
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>printer publish</tertiary></indexterm>
1778
net ads printer publish <printer_name> -Uadministrator%secret
1780
This publishes a printer from the local Samba server to ADS.
1784
Removal of a Samba printer from ADS is achieved by executing this command:
1785
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>printer remove</tertiary></indexterm>
1787
net ads printer remove <printer_name> -Uadministrator%secret
1792
A generic search (query) can also be made to locate a printer across the entire ADS domain by executing:
1793
<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>printer search</tertiary></indexterm>
1795
net ads printer search <printer_name> -Uadministrator%secret
1802
<title>Manipulating the Samba Cache</title>
1805
Please refer to the <command>net</command> command man page for information regarding cache management.
1811
<title>Managing IDMAP UID/SID Mappings</title>
1814
The IDMAP UID to SID, and SID to UID, mappings that are created by <command>winbindd</command> can be
1815
backed up to a text file. The text file can be manually edited, although it is highly recommended that
1816
you attempt this only if you know precisely what you are doing.
1820
An IDMAP text dump file can be restored (or reloaded). There are two situations that may necessitate
1821
this action: a) The existing IDMAP file is corrupt, b) It is necessary to install an editted version
1822
of the mapping information.
1826
Winbind must be shut down to dump the IDMAP file. Before restoring a dump file, shut down
1827
<command>winbindd</command> and delete the old <filename>winbindd_idmap.tdb</filename> file.
1831
<title>Creating an IDMAP Database Dump File</title>
1834
The IDMAP database can be dumped to a text file as shown here:
1836
net idmap dump <full_path_and_tdb_filename> > dumpfile.txt
1838
Where a particular build of Samba the run-time tdb files are stored in the
1839
<filename>/var/lib/samba</filename> directory the following commands to create the dump file will suffice:
1841
net idmap dump /var/lib/samba/winbindd_idmap.tdb > idmap_dump.txt
1848
<title>Restoring the IDMAP Database Dump File</title>
1851
The IDMAP dump file can be restored using the following command:
1853
net idmap restore <full_path_and_tdb_filename> < dumpfile.txt
1855
Where the Samba run-time tdb files are stored in the <filename>/var/lib/samba</filename> directory
1856
the following command can be used to restore the data to the tdb file:
1858
net idmap restore /var/lib/samba/winbindd_idmap.tdb < idmap_dump.txt
1866
<sect1 id="netmisc1">
1867
<title>Other Miscellaneous Operations</title>
1870
The following command is useful for obtaining basic statistics regarding a Samba domain. This command does
1871
not work with current Windows XP Professional clients.
1872
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>info</tertiary></indexterm>
1874
&rootprompt; net rpc info
1875
Domain Name: RAPIDFLY
1876
Domain SID: S-1-5-21-399034208-633907489-3292421255
1877
Sequence number: 1116312355
1879
Num domain groups: 27
1885
Another useful tool is the <command>net time</command> tool set. This tool may be used to query the
1886
current time on the target server as shown here:
1887
<indexterm><primary>net</primary><secondary>time</secondary></indexterm>
1889
&rootprompt; net time -S SAURON
1890
Tue May 17 00:50:43 2005
1892
In the event that it is the intent to pass the time information obtained to the UNIX
1893
<command>/bin/time</command>, it is a good idea to obtain the time from the target server in a format
1894
that is ready to be passed through. This may be done by executing:
1895
<indexterm><primary>net</primary><secondary>time</secondary><tertiary>system</tertiary></indexterm>
1897
&rootprompt; net time system -S FRODO
1900
The time can be set on a target server by executing:
1901
<indexterm><primary>net</primary><secondary>time</secondary><tertiary>set</tertiary></indexterm>
1903
&rootprompt; net time set -S MAGGOT -U Administrator%not24get
1904
Tue May 17 00:55:30 MDT 2005
1906
It is possible to obtain the time zone of a server by executing the following command against it:
1907
<indexterm><primary>net</primary><secondary>time</secondary><tertiary>zone</tertiary></indexterm>
1909
&rootprompt; net time zone -S SAURON
added
removed
docs-xml/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
