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"> 3 4<chapter id="NetCommand"> 5<chapterinfo> 6 &author.jht; 7 &author.vl; 8 &author.gd; 9 <pubdate>May 9, 2005</pubdate> 10</chapterinfo> 11 12<title>Remote and Local Management: The Net Command</title> 13 14<para> 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> 19The <command>net</command> command is one of the new features of Samba-3 and is an attempt to provide a useful 20tool for the majority of remote management operations necessary for common tasks. The <command>net</command> 21tool is flexible by design and is intended for command-line use as well as for scripted control application. 22</para> 23 24<para> 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> 29Originally 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 31of 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 33been integrated into the <command>net</command>. The <command>smbgroupedit</command> command was absorbed 34entirely into the <command>net</command>, while only some features of the <command>rpcclient</command> command 35have been ported to it. Anyone who finds older references to these utilities and to the functionality they 36provided should look at the <command>net</command> command before searching elsewhere. 37</para> 38 39<para> 40A Samba-3 administrator cannot afford to gloss over this chapter because to do so will almost certainly cause 41the infliction of self-induced pain, agony, and desperation. Be warned: this is an important chapter. 42</para> 43 44 <sect1> 45 <title>Overview</title> 46 47 <para> 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. 59 </para> 60 61 <para> 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. 76 </para> 77 78 <para> 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. 89 </para> 90 91 <para> 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. 104 </para> 105 106 <para> 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. 113 </para> 114 115 </sect1> 116 117 <sect1> 118 <title>Administrative Tasks and Methods</title> 119 120 <para> 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. 134 </para> 135 136 </sect1> 137 138 <sect1> 139 <title>UNIX and Windows Group Management</title> 140 141 <para> 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 151 earlier SMB servers. 152 </para> 153 154 <para> 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. 161 </para> 162 163 <para> 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. 171 </para> 172 173 <para> 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. 176 </para> 177 178 <sect2> 179 <title>Adding, Renaming, or Deletion of Group Accounts</title> 180 181 <para> 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. 186 </para> 187 188 <para> 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. 198 </para> 199 200 <para> 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. 205 </para> 206 207 <sect3> 208 <title>Adding or Creating a New Group</title> 209 210 <para> 211 Before attempting to add a Windows group account, the currently available groups can be listed as shown 212 here: 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> 215<screen> 216&rootprompt; net rpc group list -Uroot%not24get 217Password: 218Domain Admins 219Domain Users 220Domain Guests 221Print Operators 222Backup Operators 223Replicator 224Domain Computers 225Engineers 226</screen> 227 </para> 228 229<?latex \newpage ?> 230 <para> 231 A Windows group account called <quote>SupportEngrs</quote> can be added by executing the following 232command: 233<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group add</tertiary></indexterm> 234<screen> 235&rootprompt; net rpc group add "SupportEngrs" -Uroot%not24get 236</screen> 237 The addition will result in immediate availability of the new group account as validated by executing 238this command: 239<screen> 240&rootprompt; net rpc group list -Uroot%not24get 241Password: 242Domain Admins 243Domain Users 244Domain Guests 245Print Operators 246Backup Operators 247Replicator 248Domain Computers 249Engineers 250SupportEngrs 251</screen> 252 </para> 253 254 <para> 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 260 script: 261<screen> 262&rootprompt; getent group 263... 264Domain Admins:x:512:root 265Domain Users:x:513:jht,lct,ajt,met 266Domain Guests:x:514: 267Print Operators:x:550: 268Backup Operators:x:551: 269Replicator:x:552: 270Domain Computers:x:553: 271Engineers:x:1002:jht 272SupportEngrs:x:1003: 273</screen> 274 The following demonstrates that the use of the <command>net</command> command to add a group account 275results in immediate mapping of the POSIX group that has been created to the Windows group account as shown 276here: 277<indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>list</tertiary></indexterm> 278<screen> 279&rootprompt; net groupmap list 280Domain Admins (S-1-5-21-72630-4128915-11681869-512) -> Domain Admins 281Domain Users (S-1-5-21-72630-4128915-11681869-513) -> Domain Users 282Domain Guests (S-1-5-21-72630-4128915-11681869-514) -> Domain Guests 283Print Operators (S-1-5-21-72630-4128915-11681869-550) -> Print Operators 284Backup Operators (S-1-5-21-72630-4128915-11681869-551) -> Backup Operators 285Replicator (S-1-5-21-72630-4128915-11681869-552) -> Replicator 286Domain Computers (S-1-5-21-72630-4128915-11681869-553) -> Domain Computers 287Engineers (S-1-5-21-72630-4128915-11681869-3005) -> Engineers 288SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs 289</screen> 290 </para> 291 292 </sect3> 293 294 <sect3> 295 <title>Mapping Windows Groups to UNIX Groups</title> 296 297 <para> 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. 305 </para> 306 307 <para> 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. 318 </para> 319 320 <para> 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. 333 </para> 334 335 <para> 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. 341 </para> 342 343 <note><para> 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. 346 </para></note> 347 348 <para> 349 An existing UNIX group may be mapped to an existing Windows group by this example: 350<screen> 351&rootprompt; net groupmap modify ntgroup="Domain Users" unixgroup=users 352</screen> 353 An existing UNIX group may be mapped to a new Windows group as shown here: 354<screen> 355&rootprompt; net groupmap add ntgroup="EliteEngrs" unixgroup=Engineers type=d 356</screen> 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: 360<screen> 361&rootprompt; net groupmap delete ntgroup=Engineers 362&rootprompt; net groupmap add ntgroup=EngineDrivers unixgroup=Engineers type=d 363</screen> 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. 369 </para> 370 371 <para> 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>. 375<screen> 376&rootprompt; net groupmap add ntgroup=Pixies unixgroup=pixies type=l 377</screen> 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. 381 </para> 382 383 </sect3> 384 385 <sect3> 386 <title>Deleting a Group Account</title> 387 388 <para> 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: 391<screen> 392&rootprompt; net rpc group delete SupportEngineers -Uroot%not24get 393</screen> 394 </para> 395 396 <para> 397 Validation of the deletion is advisable. The same commands may be executed as shown above. 398 </para> 399 400 </sect3> 401 402 <sect3> 403 <title>Rename Group Accounts</title> 404 405 <note><para> 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. 409 </para></note> 410 411 <para> 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> 416<screen> 417&rootprompt; net rpc group rename SupportEngrs \ 418 CustomerSupport -Uroot%not24get 419</screen> 420 </para> 421 422 </sect3> 423 424 </sect2> 425 426 <sect2 id="grpmemshipchg"> 427 <title>Manipulating Group Memberships</title> 428 429 <para> 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. 433 </para> 434 435 <para> 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>. 441<screen> 442&rootprompt; getent group 443... 444Domain Admins:x:512:root 445Domain Users:x:513:jht,lct,ajt,met,vlendecke 446Domain Guests:x:514: 447Print Operators:x:550: 448Backup Operators:x:551: 449Replicator:x:552: 450Domain Computers:x:553: 451Engineers:x:1000:jht,ajt 452</screen> 453 The UNIX/Linux groups have been mapped to Windows groups, as is shown here: 454<screen> 455&rootprompt; net groupmap list 456Domain Admins (S-1-5-21-72630-412605-116429-512) -> Domain Admins 457Domain Users (S-1-5-21-72630-412605-116429-513) -> Domain Users 458Domain Guests (S-1-5-21-72630-412605-116429-514) -> Domain Guests 459Print Operators (S-1-5-21-72630-412605-116429-550) -> Print Operators 460Backup Operators (S-1-5-21-72630-412605-116429-551) -> Backup Operators 461Replicator (S-1-5-21-72630-412605-116429-552) -> Replicator 462Domain Computers (S-1-5-21-72630-412605-116429-553) -> Domain Computers 463Engineers (S-1-5-21-72630-412605-116429-3001) -> Engineers 464</screen> 465 </para> 466 467 <para> 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 470 demonstrated here: 471<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group addmem</tertiary></indexterm> 472<screen> 473&rootprompt; net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get 474Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP 475</screen> 476 This shows that the group mapping between UNIX/Linux groups and Windows groups is effective and 477 transparent. 478 </para> 479 480 <para> 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> 484<screen> 485&rootprompt; net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24get 486&rootprompt; getent group Engineers 487Engineers:x:1000:jht 488&rootprompt; net rpc group members Engineers -Uroot%not24get 489MIDEARTH\jht 490</screen> 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. 493 </para> 494 495 <para> 496 The account is now added again, using the <command>net rpc group</command> utility: 497<screen> 498&rootprompt; net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get 499&rootprompt; getent group Engineers 500Engineers:x:1000:jht,ajt 501&rootprompt; net rpc group members Engineers -Uroot%not24get 502MIDEARTH\jht 503MIDEARTH\ajt 504</screen> 505 </para> 506 507 <para> 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> 512<screen> 513&rootprompt; net rpc group members "Domain Users" -Uroot%not24get 514MIDEARTH\jht 515MIDEARTH\lct 516MIDEARTH\ajt 517MIDEARTH\met 518MIDEARTH\vlendecke 519</screen> 520 This express example shows that Windows group names are treated by Samba (as with 521 MS Windows) in a case-insensitive manner: 522<screen> 523&rootprompt; net rpc group members "DomAiN USerS" -Uroot%not24get 524MIDEARTH\jht 525MIDEARTH\lct 526MIDEARTH\ajt 527MIDEARTH\met 528MIDEARTH\vlendecke 529</screen> 530 </para> 531 532 <note><para> 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. 538 </para></note> 539 540 </sect2> 541 542 <sect2 id="nestedgrpmgmgt"> 543 <title>Nested Group Support</title> 544 545 <para> 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: 549<screen> 550&rootprompt; net rpc group add demo -L -S MORDON -Uroot%not24get 551</screen> 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. 555 </para> 556 557 <para> 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 561 done by executing: 562<screen> 563&rootprompt; net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get 564</screen> 565 </para> 566 567 <para> 568 The members of a nested group can be listed by executing the following: 569<screen> 570&rootprompt; net rpc group members demo -Uroot%not24get 571DOM\Domain Users 572DOM\Engineers 573DOM\jamesf 574DOM\jht 575</screen> 576 </para> 577 578 <para> 579 Nested group members can be removed (deleted) as shown here: 580<screen> 581&rootprompt; net rpc group delmem demo "DOM\jht" -Uroot%not24get 582</screen> 583 </para> 584 585 <sect3> 586 <title>Managing Nest Groups on Workstations from the Samba Server</title> 587 588 <para> 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> 593<screen> 594&rootprompt; net rpc group addmem "Administrators" "Domain Users" \ 595 -S WINPC032 -Uadministrator%secret 596</screen> 597 </para> 598 599 <para> 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. 602 </para> 603 604 <procedure> 605 <title>Automating User Addition to the Workstation Power Users Group</title> 606 607 <step><para> 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> 613 </para></step> 614 615<example id="autopoweruserscript"> 616<title>Script to Auto-add Domain Users to Workstation Power Users Group</title> 617<screen> 618#!/bin/bash 619 620/usr/bin/net rpc group addmem "Power Users" "DOMAIN_NAME\$1" \ 621 -UAdministrator%secret -S $2 622 623exit 0 624</screen> 625</example> 626 627 <step><para> 628 Set the permissions on this script to permit it to be executed as part of the logon process: 629<screen> 630&rootprompt; chown root:root /etc/samba/autopoweruser.sh 631&rootprompt; chmod 755 /etc/samba/autopoweruser.sh 632</screen> 633 </para></step> 634 635 <step><para> 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> as shown. 638 </para></step> 639 640<example id="magicnetlogon"> 641<title>A Magic Netlogon Share</title> 642<smbconfblock> 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> 649</smbconfblock> 650</example> 651 652 <step><para> 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 655 file</link> 656 </para></step> 657 658</procedure> 659 660 <para> 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 665 the workstation. 666 </para> 667 668 </sect3> 669 670 </sect2> 671 672 </sect1> 673 674 <sect1> 675 <title>UNIX and Windows User Management</title> 676 677 <para> 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>. 691 </para> 692 693 <para> 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. 698 </para> 699 700 <sect2 id="sbeuseraddn"> 701 <title>Adding User Accounts</title> 702 703 <para> 704 The syntax for adding a user account via the <command>net</command> (according to the man page) is shown 705 here: 706<screen> 707net [<method>] user ADD <name> [-c container] [-F user flags] \ 708 [misc. options] [targets] 709</screen> 710 The user account password may be set using this syntax: 711<screen> 712net rpc password <username> [<password>] -Uadmin_username%admin_pass 713</screen> 714 </para> 715 716 <para> 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> 720<screen> 721&rootprompt; net rpc user add jacko -S FRODO -Uroot%not24get 722Added user jacko 723</screen> 724 The account password can be set with the following methods (all show the same operation): 725<screen> 726&rootprompt; net rpc password jacko f4sth0rse -S FRODO -Uroot%not24get 727&rootprompt; net rpc user password jacko f4sth0rse \ 728 -S FRODO -Uroot%not24get 729</screen> 730 </para> 731 732 </sect2> 733 734 <sect2> 735 <title>Deletion of User Accounts</title> 736 737 <para> 738 Deletion of a user account can be done using the following syntax: 739<screen> 740net [<method>] user DELETE <name> [misc. options] [targets] 741</screen> 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> 744<screen> 745&rootprompt; net rpc user delete jacko -Uroot%not24get 746Deleted user account 747</screen> 748 </para> 749 750 </sect2> 751 752 <sect2> 753 <title>Managing User Accounts</title> 754 755 <para> 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"/>. 758 </para> 759 760 <para> 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> 764<screen> 765&rootprompt; net rpc user info jacko -S SAURON -Uroot%not24get 766net rpc user info jacko -S SAURON -Uroot%not24get 767Domain Users 768Domain Admins 769Engineers 770TorridGroup 771BOP Shop 772Emergency Services 773</screen> 774 </para> 775 776 <para> 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 780 Windows Servers. 781 782 </para> 783 784 </sect2> 785 786 <sect2> 787 <title>User Mapping</title> 788 789 <para> 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: 797<screen> 798username map = /etc/samba/smbusers 799</screen> 800 The content of the <filename>/etc/samba/smbusers</filename> file is shown here: 801<screen> 802parsonsw: "William Parsons" 803marygee: geeringm 804</screen> 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>. 808 </para> 809 810 </sect2> 811 812 </sect1> 813 814 <sect1> 815 <title>Administering User Rights and Privileges</title> 816 817 <para> 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. 827 </para> 828 829 <para> 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. 839 </para> 840 841 <note><para> 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. 846 </para></note> 847 848 <para> 849 By default, no privileges and rights are assigned. This is demonstrated by executing the command 850 shown here: 851<screen> 852&rootprompt; net rpc rights list accounts -U root%not24get 853BUILTIN\Print Operators 854No privileges assigned 855 856BUILTIN\Account Operators 857No privileges assigned 858 859BUILTIN\Backup Operators 860No privileges assigned 861 862BUILTIN\Server Operators 863No privileges assigned 864 865BUILTIN\Administrators 866No privileges assigned 867 868Everyone 869No privileges assigned 870</screen> 871 </para> 872 873 <para> 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> 885<screen> 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 895</screen> 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. 899 </para> 900 901 <para> 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 904 the reality: 905<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>rights grant</tertiary></indexterm> 906<screen> 907&rootprompt; net rpc rights grant "MIDEARTH\Domain Admins" \ 908 SeMachineAccountPrivilege SePrintOperatorPrivilege \ 909 SeAddUsersPrivilege SeRemoteShutdownPrivilege \ 910 SeDiskOperatorPrivilege -U root%not24get 911Successfully granted rights. 912</screen> 913 Next, the domain user <constant>jht</constant> is given the privileges needed for day-to-day 914 administration: 915<screen> 916&rootprompt; net rpc rights grant "MIDEARTH\jht" \ 917 SeMachineAccountPrivilege SePrintOperatorPrivilege \ 918 SeAddUsersPrivilege SeDiskOperatorPrivilege \ 919 -U root%not24get 920Successfully granted rights. 921</screen> 922 </para> 923 924 <para> 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> 927<screen> 928&rootprompt; net rpc rights list accounts -U root%not24get 929MIDEARTH\jht 930SeMachineAccountPrivilege 931SePrintOperatorPrivilege 932SeAddUsersPrivilege 933SeDiskOperatorPrivilege 934 935BUILTIN\Print Operators 936No privileges assigned 937 938BUILTIN\Account Operators 939No privileges assigned 940 941BUILTIN\Backup Operators 942No privileges assigned 943 944BUILTIN\Server Operators 945No privileges assigned 946 947BUILTIN\Administrators 948No privileges assigned 949 950Everyone 951No privileges assigned 952 953MIDEARTH\Domain Admins 954SeMachineAccountPrivilege 955SePrintOperatorPrivilege 956SeAddUsersPrivilege 957SeRemoteShutdownPrivilege 958SeDiskOperatorPrivilege 959</screen> 960 </para> 961 962 </sect1> 963 964 <sect1> 965 <title>Managing Trust Relationships</title> 966 967 <para> 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. 972 </para> 973 974 <sect2> 975 <title>Machine Trust Accounts</title> 976 977 <para> 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. 980 </para> 981 982 <para> 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> 985<screen> 986&rootprompt; net rpc testjoin 987Join to 'MIDEARTH' is OK 988</screen> 989 Where there is no domain membership account, or when the account credentials are not valid, the following 990 results will be observed: 991<screen> 992net rpc testjoin -S DOLPHIN 993Join to domain 'WORLDOCEAN' is not valid 994</screen> 995 </para> 996 997 <para> 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> 1000<screen> 1001&rootprompt; net ads testjoin 1002Using short domain name -- TAKEAWAY 1003Joined 'LEMONADE' to realm 'TAKEAWAY.BIZ' 1004</screen> 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: 1007<screen> 1008&rootprompt; net ads testjoin -UAdministrator%secret 1009Join to domain is not valid 1010</screen> 1011 </para> 1012 1013 <para> 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> 1017<screen> 1018&rootprompt; net rpc join -S FRODO -Uroot%not24get 1019Joined domain MIDEARTH. 1020</screen> 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: 1023<screen> 1024&rootprompt; pdbedit -Lw merlin\$ 1025merlin$:1009:9B4489D6B90461FD6A3EC3AB96147E16:\ 1026176D8C554E99914BDF3407DEA2231D80:[S ]:LCT-42891919: 1027</screen> 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> 1032<screen> 1033&rootprompt; net rpc join member -S FRODO -Uroot%not24get 1034Joined domain MIDEARTH. 1035</screen> 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> 1040<screen> 1041&rootprompt; net rpc join bdc -S FRODO -Uroot%not24get 1042Joined domain MIDEARTH. 1043</screen> 1044 It is best to let Samba figure out the domain join type from the settings in the &smb.conf; file. 1045 </para> 1046 1047 <para> 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> 1050<screen> 1051&rootprompt; net ads join -UAdministrator%not24get 1052Using short domain name -- GDANSK 1053Joined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ' 1054</screen> 1055 </para> 1056 1057 <para> 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> 1063<screen> 1064&rootprompt; net rpc user delete HERRING\$ -Uroot%not24get 1065Deleted user account. 1066</screen> 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. 1069 </para> 1070 1071 <para> 1072 A Samba-3 server that is a Windows ADS domain member can execute the following command to detach from the 1073 domain: 1074<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>leave</tertiary></indexterm> 1075<screen> 1076&rootprompt; net ads leave 1077</screen> 1078 </para> 1079 1080 <para> 1081 Detailed information regarding an ADS domain can be obtained by a Samba DMS machine by executing the 1082 following: 1083<indexterm><primary>net</primary><secondary>ads</secondary><tertiary>status</tertiary></indexterm> 1084<screen> 1085&rootprompt; net ads status 1086</screen> 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>. 1090 </para> 1091 1092 </sect2> 1093 1094 <sect2> 1095 <title>Interdomain Trusts</title> 1096 1097 <para> 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. 1100 </para> 1101 1102 <para> 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> 1105<screen> 1106&rootprompt; net rpc trustdom list -Uroot%not24get 1107Trusted domains list: 1108 1109none 1110 1111Trusting domains list: 1112 1113none 1114</screen> 1115 There are no interdomain trusts at this time; the following steps will create them. 1116 </para> 1117 1118 <para> 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> 1123<screen> 1124&rootprompt; net rpc trustdom add DAMNATION f00db4r -Uroot%not24get 1125</screen> 1126 The account can be revealed by using the <command>pdbedit</command> as shown here: 1127<screen> 1128&rootprompt; pdbedit -Lw DAMNATION\$ 1129DAMNATION$:1016:9AC1F121DF897688AAD3B435B51404EE: \ 11307F845808B91BB9F7FEF44B247D9DC9A6:[I ]:LCT-428934B1: 1131</screen> 1132 A trust account will always have an I in the field within the square brackets. 1133 </para> 1134 1135 <para> 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> 1138<screen> 1139&rootprompt; net rpc trustdom list -Uroot%not24get 1140Trusted domains list: 1141 1142none 1143 1144Trusting domains list: 1145 1146DAMNATION S-1-5-21-1385457007-882775198-1210191635 1147</screen> 1148 The above command executed successfully; a failure is indicated when the following response is obtained: 1149<screen> 1150net rpc trustdom list -Uroot%not24get 1151Trusted domains list: 1152 1153DAMNATION S-1-5-21-1385457007-882775198-1210191635 1154 1155Trusting domains list: 1156 1157DAMNATION domain controller is not responding 1158</screen> 1159 </para> 1160 1161 <para> 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> 1166<screen> 1167&rootprompt; net rpc trustdom establish DAMNATION 1168Password: xxxxxxx == f00db4r 1169Could not connect to server TRANSGRESSION 1170Trust to domain DAMNATION established 1171</screen> 1172 Validation of the two-way trust now established is possible as shown here: 1173<screen> 1174&rootprompt; net rpc trustdom list -Uroot%not24get 1175Trusted domains list: 1176 1177DAMNATION S-1-5-21-1385457007-882775198-1210191635 1178 1179Trusting domains list: 1180 1181DAMNATION S-1-5-21-1385457007-882775198-1210191635 1182</screen> 1183 </para> 1184 1185 <para> 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> 1189<screen> 1190&rootprompt; net rpc trustdom revoke DAMNATION -Uroot%not24get 1191</screen> 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: 1194<screen> 1195&rootprompt; net rpc trustdom del DAMNATION -Uroot%not24get 1196</screen> 1197 1198 </para> 1199 1200 </sect2> 1201 1202 </sect1> 1203 1204 <sect1> 1205 <title>Managing Security Identifiers (SIDS)</title> 1206 1207 <para> 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. 1217 </para> 1218 1219 <para> 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. 1228 </para> 1229 1230 <para> 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> 1234<screen> 1235&rootprompt; net getlocalsid > /etc/samba/my-sid 1236</screen> 1237 Good, there is now a safe copy of the local machine SID. On a PDC/BDC this is the domain SID also. 1238 </para> 1239 1240 <para> 1241 The following command reveals what the former one should have placed into the file called 1242 <filename>my-sid</filename>: 1243<screen> 1244&rootprompt; net getlocalsid 1245SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429 1246</screen> 1247 </para> 1248 1249 <para> 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> 1254<screen> 1255&rootprompt; net setlocalsid S-1-5-21-1385457007-882775198-1210191635 1256</screen> 1257 Restoration of a machine SID is a simple operation, but the absence of a backup copy can be very 1258 problematic. 1259 </para> 1260 1261 <para> 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> 1267<screen> 1268&rootprompt; net rpc getsid -S FRODO -Uroot%not24get 1269Storing SID S-1-5-21-726309263-4128913605-1168186429 \ 1270 for Domain MIDEARTH in secrets.tdb 1271</screen> 1272 Usually it is not necessary to specify the target server (-S FRODO) or the administrator account 1273 credentials (-Uroot%not24get). 1274 </para> 1275 1276 </sect1> 1277 1278 <sect1> 1279 <title>Share Management</title> 1280 1281 <para> 1282 Share management is central to all file serving operations. Typical share operations include: 1283 </para> 1284 1285 <itemizedlist> 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> 1290 </itemizedlist> 1291 1292 <para> 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. 1295 </para> 1296 1297 <sect2> 1298 <title>Creating, Editing, and Removing Shares</title> 1299 1300 <para> 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>. 1308 </para> 1309 1310 <para> 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> 1316<screen> 1317&rootprompt; net rpc share add Bulge=/data -S MERLIN -Uroot%not24get 1318</screen> 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: 1321<screen> 1322&rootprompt; net rpc share -S MERLIN -Uroot%not24get 1323profdata 1324archive 1325Bulge <--- This one was added 1326print$ 1327netlogon 1328profiles 1329IPC$ 1330kyocera 1331ADMIN$ 1332</screen> 1333 </para> 1334 1335 <para> 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> 1339<screen> 1340&rootprompt; net rpc share delete Bulge -S MERLIN -Uroot%not24get 1341</screen> 1342 A simple validation shown here demonstrates that the share has been removed: 1343<screen> 1344&rootprompt; net rpc share -S MERLIN -Uroot%not24get 1345profdata 1346archive 1347print$ 1348netlogon 1349profiles 1350IPC$ 1351ADMIN$ 1352kyocera 1353</screen> 1354 </para> 1355 1356 </sect2> 1357 1358 <sect2> 1359 <title>Creating and Changing Share ACLs</title> 1360 1361 <para> 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. 1364 </para> 1365 1366 <para> 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"/>. 1370 </para> 1371 1372 </sect2> 1373 1374 <sect2> 1375 <title>Share, Directory, and File Migration</title> 1376 1377 <para> 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. 1385 </para> 1386 1387 <para> 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. 1390 </para> 1391 1392 <para> 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. 1397 </para> 1398 1399 <para> 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 . 1410 </para> 1411 1412 <para> 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. 1415 </para> 1416 1417 <para> 1418 There are two known limitations to the migration process: 1419 </para> 1420 1421 <orderedlist> 1422 <listitem><para> 1423 The <command>net</command> command requires that the user credentials provided exist on both 1424 the migration source and the migration target. 1425 </para></listitem> 1426 1427 <listitem><para> 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. 1430 </para></listitem> 1431 </orderedlist> 1432 1433 <sect3> 1434 <title>Share Migration</title> 1435 1436 <para> 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. 1443 </para> 1444 1445 <para> 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>. 1449 </para> 1450 1451 <para> 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"/>. 1458 </para> 1459 1460 <para> 1461 The syntax of the share migration command is shown here: 1462<screen> 1463net rpc share MIGRATE SHARES <share-name> -S <source> 1464 [--destination=localhost] [--exclude=share1,share2] [-v] 1465</screen> 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> 1470<screen> 1471&rootprompt; net rpc share migrate shares myshare\ 1472 -S win2k -U administrator%secret" 1473</screen> 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> 1483<screen> 1484&rootprompt; net rpc right list accounts -Uroot%not24get 1485</screen> 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. 1488 </para> 1489 1490 </sect3> 1491 1492 <sect3> 1493 <title>File and Directory Migration</title> 1494 1495 <para> 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. 1500 </para> 1501 1502 <para> 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. 1509 </para> 1510 1511 <para> 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>. 1515 </para> 1516 1517 <para> 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. 1523 </para> 1524 1525 <para> 1526 The syntax for the migration commands is shown here: 1527<screen> 1528net rpc share MIGRATE FILES <share-name> -S <source> 1529 [--destination=localhost] [--exclude=share1,share2] 1530 [--acls] [--attrs] [--timestamps] [-v] 1531</screen> 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 1534 switch. 1535 </para> 1536 1537 <para> 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. 1542 </para> 1543 1544 <note><para> 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. 1549 </para></note> 1550 1551 <para> 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. 1557 </para> 1558 1559 <para> 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> 1563<screen> 1564&rootprompt; net rpc share migrate files -S nt4box --acls \ 1565 --attrs -U administrator%secret 1566</screen> 1567 </para> 1568 1569 <para> 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>. 1573 </para> 1574 1575 </sect3> 1576 1577 <sect3> 1578 <title>Share-ACL Migration</title> 1579 <para> 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 1582 function: 1583<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share migrate security</tertiary></indexterm> 1584<screen> 1585&rootprompt; net rpc share migrate security -S nt4box -U administrator%secret 1586</screen> 1587 </para> 1588 1589 <para> 1590 This command will only copy the share-ACL of each share on nt4box to your local samba-system. 1591 </para> 1592 </sect3> 1593 1594 <sect3> 1595 <title>Simultaneous Share and File Migration</title> 1596 1597 <para> 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: 1600<screen> 1601net rpc share MIGRATE ALL <share-name> -S <source> 1602 [--exclude=share1, share2] [--acls] [--attrs] [--timestamps] [-v] 1603</screen> 1604 </para> 1605 1606 <para> 1607 An example of simultaneous migration is shown here: 1608<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>share migrate all</tertiary></indexterm> 1609<screen> 1610&rootprompt; net rpc share migrate all -S w2k3server -U administrator%secret 1611</screen> 1612 This will generate a complete server clone of the <parameter>w2k3server</parameter> server. 1613 </para> 1614 1615 </sect3> 1616 1617 </sect2> 1618 1619 <sect2> 1620 <title>Printer Migration</title> 1621 1622 <para> 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. 1627 </para> 1628 1629 <para> 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 complex arrangement 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. 1641 </para> 1642 1643 <para> 1644 The migration of an existing printing architecture involves the following: 1645 </para> 1646 1647 <itemizedlist> 1648 <listitem><para>Establishment of print queues.</para></listitem> 1649 1650 <listitem><para>Installation of printer drivers (both for the print server and for Windows clients.</para></listitem> 1651 1652 <listitem><para>Configuration of printing forms.</para></listitem> 1653 1654 <listitem><para>Implementation of security settings.</para></listitem> 1655 1656 <listitem><para>Configuration of printer settings.</para></listitem> 1657 </itemizedlist> 1658 1659 <para> 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 name="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. 1669 </para> 1670 1671 <para> 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 1675 briefly described. 1676 </para> 1677 1678 <para> 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> 1682<screen> 1683net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets] 1684</screen> 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> 1688<screen> 1689net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets] 1690</screen> 1691 Printer forms can be migrated with the following operation: 1692<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>printer migrate forms</tertiary></indexterm> 1693<screen> 1694net rpc printer MIGRATE FORMS [printer] [misc. options] [targets] 1695</screen> 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> 1698<screen> 1699net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets] 1700</screen> 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> 1704<screen> 1705net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets] 1706</screen> 1707 </para> 1708 1709 <para> 1710 Migration of printers including the above-mentioned sets of information may be completed 1711 with a single command using this syntax: 1712<screen> 1713net rpc printer MIGRATE ALL [printer] [misc. options] [targets] 1714</screen> 1715 </para> 1716 1717 </sect2> 1718 1719 </sect1> 1720 1721 <sect1> 1722 <title>Controlling Open Files</title> 1723 1724 <para> 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 1727 usage information. 1728 </para> 1729 1730 </sect1> 1731 1732 <sect1> 1733 <title>Session and Connection Management</title> 1734 1735 <para> 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> 1739<screen> 1740&rootprompt; net rap session -S MERLIN -Uroot%not24get 1741Computer 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 1747</screen> 1748 </para> 1749 1750 <para> 1751 A session can be closed by executing a command as shown here: 1752<screen> 1753&rootprompt; net rap session close marvel -Uroot%not24get 1754</screen> 1755 </para> 1756 1757 </sect1> 1758 1759 <sect1> 1760 <title>Printers and ADS</title> 1761 1762 <para> 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> 1767<screen> 1768net ads printer info <printer_name> <server_name> -Uadministrator%secret 1769</screen> 1770 If the asterisk (*) is used in place of the printer_name argument, a list of all printers will be 1771 returned. 1772 </para> 1773 1774 <para> 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> 1777<screen> 1778net ads printer publish <printer_name> -Uadministrator%secret 1779</screen> 1780 This publishes a printer from the local Samba server to ADS. 1781 </para> 1782 1783 <para> 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> 1786<screen> 1787net ads printer remove <printer_name> -Uadministrator%secret 1788</screen> 1789 </para> 1790 1791 <para> 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> 1794<screen> 1795net ads printer search <printer_name> -Uadministrator%secret 1796</screen> 1797 </para> 1798 1799 </sect1> 1800 1801 <sect1> 1802 <title>Manipulating the Samba Cache</title> 1803 1804 <para> 1805 Please refer to the <command>net</command> command man page for information regarding cache management. 1806 </para> 1807 1808 </sect1> 1809 1810 <sect1> 1811 <title>Managing IDMAP UID/SID Mappings</title> 1812 1813 <para> 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. 1817 </para> 1818 1819 <para> 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. 1823 </para> 1824 1825 <para> 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. 1828 </para> 1829 1830 <sect2> 1831 <title>Creating an IDMAP Database Dump File</title> 1832 1833 <para> 1834 The IDMAP database can be dumped to a text file as shown here: 1835<screen> 1836net idmap dump <full_path_and_tdb_filename> > dumpfile.txt 1837</screen> 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: 1840<screen> 1841net idmap dump /var/lib/samba/winbindd_idmap.tdb > idmap_dump.txt 1842</screen> 1843 </para> 1844 1845 </sect2> 1846 1847 <sect2> 1848 <title>Restoring the IDMAP Database Dump File</title> 1849 1850 <para> 1851 The IDMAP dump file can be restored using the following command: 1852<screen> 1853net idmap restore idmap_dump.txt 1854</screen> 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: 1857<screen> 1858net idmap restore /var/lib/samba/winbindd_idmap.tdb < idmap_dump.txt 1859</screen> 1860 </para> 1861 1862 </sect2> 1863 1864 </sect1> 1865 1866 <sect1 id="netmisc1"> 1867 <title>Other Miscellaneous Operations</title> 1868 1869 <para> 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> 1873<screen> 1874&rootprompt; net rpc info 1875Domain Name: RAPIDFLY 1876Domain SID: S-1-5-21-399034208-633907489-3292421255 1877Sequence number: 1116312355 1878Num users: 720 1879Num domain groups: 27 1880Num local groups: 6 1881</screen> 1882 </para> 1883 1884 <para> 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> 1888<screen> 1889&rootprompt; net time -S SAURON 1890Tue May 17 00:50:43 2005 1891</screen> 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> 1896<screen> 1897&rootprompt; net time system -S FRODO 1898051700532005.16 1899</screen> 1900 The time can be set on a target server by executing: 1901<indexterm><primary>net</primary><secondary>time</secondary><tertiary>set</tertiary></indexterm> 1902<screen> 1903&rootprompt; net time set -S MAGGOT -U Administrator%not24get 1904Tue May 17 00:55:30 MDT 2005 1905</screen> 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> 1908<screen> 1909&rootprompt; net time zone -S SAURON 1910-0600 1911</screen> 1912 </para> 1913 1914 </sect1> 1915 1916</chapter> 1917