diff options
Diffstat (limited to 'docs/htmldocs/Samba3-HOWTO/NetCommand.html')
| -rw-r--r-- | docs/htmldocs/Samba3-HOWTO/NetCommand.html | 1391 |
1 files changed, 0 insertions, 1391 deletions
diff --git a/docs/htmldocs/Samba3-HOWTO/NetCommand.html b/docs/htmldocs/Samba3-HOWTO/NetCommand.html deleted file mode 100644 index 7e2bd75b01..0000000000 --- a/docs/htmldocs/Samba3-HOWTO/NetCommand.html +++ /dev/null @@ -1,1391 +0,0 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 13. Remote and Local Management: The Net Command</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="The Official Samba 3.5.x HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="prev" href="groupmapping.html" title="Chapter 12. Group Mapping: MS Windows and UNIX"><link rel="next" href="idmapper.html" title="Chapter 14. Identity Mapping (IDMAP)"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 13. Remote and Local Management: The Net Command</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="idmapper.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 13. Remote and Local Management: The Net Command"><div class="titlepage"><div><div><h2 class="title"><a name="NetCommand"></a>Chapter 13. Remote and Local Management: The Net Command</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jht@samba.org">jht@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Volker</span> <span class="surname">Lendecke</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:Volker.Lendecke@SerNet.DE">Volker.Lendecke@SerNet.DE</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Guenther</span> <span class="surname">Deschner</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:gd@samba.org">gd@samba.org</a>></code></p></div></div></div></div><div><p class="pubdate">May 9, 2005</p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="NetCommand.html#id367921">Overview</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id368198">Administrative Tasks and Methods</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id368272">UNIX and Windows Group Management</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#id368421">Adding, Renaming, or Deletion of Group Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#grpmemshipchg">Manipulating Group Memberships</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#nestedgrpmgmgt">Nested Group Support</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#id369648">UNIX and Windows User Management</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#sbeuseraddn">Adding User Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id369843">Deletion of User Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id369887">Managing User Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id369950">User Mapping</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#id370027">Administering User Rights and Privileges</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id370337">Managing Trust Relationships</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#id370349">Machine Trust Accounts</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id370687">Interdomain Trusts</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#id370896">Managing Security Identifiers (SIDS)</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id371098">Share Management</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#id371140">Creating, Editing, and Removing Shares</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id371309">Creating and Changing Share ACLs</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id371336">Share, Directory, and File Migration</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id371872">Printer Migration</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#id372088">Controlling Open Files</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id372105">Session and Connection Management</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id372165">Printers and ADS</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id372268">Manipulating the Samba Cache</a></span></dt><dt><span class="sect1"><a href="NetCommand.html#id372285">Managing IDMAP UID/SID Mappings</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetCommand.html#id372323">Creating an IDMAP Database Dump File</a></span></dt><dt><span class="sect2"><a href="NetCommand.html#id372354">Restoring the IDMAP Database Dump File</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetCommand.html#netmisc1">Other Miscellaneous Operations</a></span></dt></dl></div><p> -<a class="indexterm" name="id367793"></a> -<a class="indexterm" name="id367799"></a> -<a class="indexterm" name="id367806"></a> -<a class="indexterm" name="id367813"></a> -The <code class="literal">net</code> command is one of the new features of Samba-3 and is an attempt to provide a useful -tool for the majority of remote management operations necessary for common tasks. The <code class="literal">net</code> -tool is flexible by design and is intended for command-line use as well as for scripted control application. -</p><p> -<a class="indexterm" name="id367837"></a> -<a class="indexterm" name="id367843"></a> -<a class="indexterm" name="id367850"></a> -<a class="indexterm" name="id367857"></a> -Originally introduced with the intent to mimic the Microsoft Windows command that has the same name, the -<code class="literal">net</code> command has morphed into a very powerful instrument that has become an essential part -of the Samba network administrator's toolbox. The Samba Team has introduced tools, such as -<code class="literal">smbgroupedit</code> and <code class="literal">rpcclient</code>, from which really useful capabilities have -been integrated into the <code class="literal">net</code>. The <code class="literal">smbgroupedit</code> command was absorbed -entirely into the <code class="literal">net</code>, while only some features of the <code class="literal">rpcclient</code> command -have been ported to it. Anyone who finds older references to these utilities and to the functionality they -provided should look at the <code class="literal">net</code> command before searching elsewhere. -</p><p> -A Samba-3 administrator cannot afford to gloss over this chapter because to do so will almost certainly cause -the infliction of self-induced pain, agony, and desperation. Be warned: this is an important chapter. -</p><div class="sect1" title="Overview"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id367921"></a>Overview</h2></div></div></div><p> -<a class="indexterm" name="id367929"></a> -<a class="indexterm" name="id367936"></a> -<a class="indexterm" name="id367943"></a> -<a class="indexterm" name="id367949"></a> -<a class="indexterm" name="id367956"></a> -<a class="indexterm" name="id367962"></a> - The tasks that follow the installation of a Samba-3 server, whether standalone or domain member, of a - domain controller (PDC or BDC) begins with the need to create administrative rights. Of course, the - creation of user and group accounts is essential for both a standalone server and a PDC. - In the case of a BDC or a Domain Member server (DMS), domain user and group accounts are obtained from - the central domain authentication backend. - </p><p> -<a class="indexterm" name="id367976"></a> -<a class="indexterm" name="id367983"></a> -<a class="indexterm" name="id367990"></a> -<a class="indexterm" name="id367996"></a> -<a class="indexterm" name="id368003"></a> -<a class="indexterm" name="id368010"></a> -<a class="indexterm" name="id368016"></a> -<a class="indexterm" name="id368023"></a> - Regardless of the type of server being installed, local UNIX groups must be mapped to the Windows - networking domain global group accounts. Do you ask why? Because Samba always limits its access to - the resources of the host server by way of traditional UNIX UID and GID controls. This means that local - groups must be mapped to domain global groups so that domain users who are members of the domain - global groups can be given access rights based on UIDs and GIDs local to the server that is hosting - Samba. Such mappings are implemented using the <code class="literal">net</code> command. - </p><p> -<a class="indexterm" name="id368043"></a> -<a class="indexterm" name="id368050"></a> -<a class="indexterm" name="id368056"></a> -<a class="indexterm" name="id368063"></a> -<a class="indexterm" name="id368070"></a> -<a class="indexterm" name="id368077"></a> -<a class="indexterm" name="id368083"></a> - UNIX systems that are hosting a Samba-3 server that is running as a member (PDC, BDC, or DMS) must have - a machine security account in the domain authentication database (or directory). The creation of such - security (or trust) accounts is also handled using the <code class="literal">net</code> command. - </p><p> -<a class="indexterm" name="id368101"></a> -<a class="indexterm" name="id368108"></a> -<a class="indexterm" name="id368115"></a> -<a class="indexterm" name="id368121"></a> -<a class="indexterm" name="id368128"></a> -<a class="indexterm" name="id368135"></a> -<a class="indexterm" name="id368142"></a> -<a class="indexterm" name="id368149"></a> -<a class="indexterm" name="id368155"></a> - The establishment of interdomain trusts is achieved using the <code class="literal">net</code> command also, as - may a plethora of typical administrative duties such as user management, group management, share and - printer management, file and printer migration, security identifier management, and so on. - </p><p> -<a class="indexterm" name="id368173"></a> -<a class="indexterm" name="id368180"></a> - The overall picture should be clear now: the <code class="literal">net</code> command plays a central role - on the Samba-3 stage. This role will continue to be developed. The inclusion of this chapter is - evidence of its importance, one that has grown in complexity to the point that it is no longer considered - prudent to cover its use fully in the online UNIX man pages. - </p></div><div class="sect1" title="Administrative Tasks and Methods"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id368198"></a>Administrative Tasks and Methods</h2></div></div></div><p> -<a class="indexterm" name="id368205"></a> -<a class="indexterm" name="id368212"></a> -<a class="indexterm" name="id368218"></a> -<a class="indexterm" name="id368228"></a> - The basic operations of the <code class="literal">net</code> command are documented here. This documentation is not - exhaustive, and thus it is incomplete. Since the primary focus is on migration from Windows servers to a Samba - server, the emphasis is on the use of the Distributed Computing Environment Remote Procedure Call (DCE RPC) - mode of operation. When used against a server that is a member of an Active Directory domain, it is preferable - (and often necessary) to use ADS mode operations. The <code class="literal">net</code> command supports both, but not - for every operation. For most operations, if the mode is not specified, <code class="literal">net</code> will - automatically fall back via the <code class="constant">ads</code>, <code class="constant">rpc</code>, and - <code class="constant">rap</code> modes. Please refer to the man page for a more comprehensive overview of the - capabilities of this utility. - </p></div><div class="sect1" title="UNIX and Windows Group Management"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id368272"></a>UNIX and Windows Group Management</h2></div></div></div><p> -<a class="indexterm" name="id368280"></a> -<a class="indexterm" name="id368286"></a> -<a class="indexterm" name="id368295"></a> -<a class="indexterm" name="id368304"></a> -<a class="indexterm" name="id368312"></a> - As stated, the focus in most of this chapter is on use of the <code class="literal">net rpc</code> family of - operations that are supported by Samba. Most of them are supported by the <code class="literal">net ads</code> - mode when used in connection with Active Directory. The <code class="literal">net rap</code> operating mode is - also supported for some of these operations. RAP protocols are used by IBM OS/2 and by several - earlier SMB servers. - </p><p> -<a class="indexterm" name="id368343"></a> -<a class="indexterm" name="id368349"></a> -<a class="indexterm" name="id368356"></a> - Samba's <code class="literal">net</code> tool implements sufficient capability to permit all common administrative - tasks to be completed from the command line. In this section each of the essential user and group management - facilities are explored. - </p><p> -<a class="indexterm" name="id368374"></a> -<a class="indexterm" name="id368380"></a> -<a class="indexterm" name="id368390"></a> -<a class="indexterm" name="id368399"></a> - Samba-3 recognizes two types of groups: <span class="emphasis"><em>domain groups</em></span> and <span class="emphasis"><em>local - groups</em></span>. Domain groups can contain (have as members) only domain user accounts. Local groups - can contain local users, domain users, and domain groups as members. - </p><p> - The purpose of a local group is to permit file permission to be set for a group account that, like the - usual UNIX/Linux group, is persistent across redeployment of a Windows file server. - </p><div class="sect2" title="Adding, Renaming, or Deletion of Group Accounts"><div class="titlepage"><div><div><h3 class="title"><a name="id368421"></a>Adding, Renaming, or Deletion of Group Accounts</h3></div></div></div><p> - Samba provides file and print services to Windows clients. The file system resources it makes available - to the Windows environment must, of necessity, be provided in a manner that is compatible with the - Windows networking environment. UNIX groups are created and deleted as required to serve operational - needs in the UNIX operating system and its file systems. - </p><p> - In order to make available to the Windows environment, Samba has a facility by which UNIX groups can - be mapped to a logical entity, called a Windows (or domain) group. Samba supports two types of Windows - groups, local and global. Global groups can contain as members, global users. This membership is - affected in the normal UNIX manner, but adding UNIX users to UNIX groups. Windows user accounts consist - of a mapping between a user SambaSAMAccount (logical entity) and a UNIX user account. Therefore, - a UNIX user is mapped to a Windows user (i.e., is given a Windows user account and password) and the - UNIX groups to which that user belongs, is mapped to a Windows group account. The result is that in - the Windows account environment that user is also a member of the Windows group account by virtue - of UNIX group memberships. - </p><p> - The following sub-sections that deal with management of Windows groups demonstrates the relationship - between the UNIX group account and its members to the respective Windows group accounts. It goes on to - show how UNIX group members automatically pass-through to Windows group membership as soon as a logical - mapping has been created. - </p><div class="sect3" title="Adding or Creating a New Group"><div class="titlepage"><div><div><h4 class="title"><a name="id368450"></a>Adding or Creating a New Group</h4></div></div></div><p> - Before attempting to add a Windows group account, the currently available groups can be listed as shown - here: -<a class="indexterm" name="id368459"></a> -<a class="indexterm" name="id368470"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group list -Uroot%not24get -Password: -Domain Admins -Domain Users -Domain Guests -Print Operators -Backup Operators -Replicator -Domain Computers -Engineers -</pre><p> - </p><p> - A Windows group account called <span class="quote">“<span class="quote">SupportEngrs</span>”</span> can be added by executing the following -command: -<a class="indexterm" name="id368504"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group add "SupportEngrs" -Uroot%not24get -</pre><p> - The addition will result in immediate availability of the new group account as validated by executing -this command: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group list -Uroot%not24get -Password: -Domain Admins -Domain Users -Domain Guests -Print Operators -Backup Operators -Replicator -Domain Computers -Engineers -SupportEngrs -</pre><p> - </p><p> -<a class="indexterm" name="id368543"></a> -<a class="indexterm" name="id368550"></a> -<a class="indexterm" name="id368557"></a> - The following demonstrates that the POSIX (UNIX/Linux system account) group has been created by calling - the <a class="link" href="smb.conf.5.html#ADDGROUPSCRIPT" target="_top">add group script = /opt/IDEALX/sbin/smbldap-groupadd -p "%g"</a> interface - script: -</p><pre class="screen"> -<code class="prompt">root# </code> getent group -... -Domain Admins:x:512:root -Domain Users:x:513:jht,lct,ajt,met -Domain Guests:x:514: -Print Operators:x:550: -Backup Operators:x:551: -Replicator:x:552: -Domain Computers:x:553: -Engineers:x:1002:jht -SupportEngrs:x:1003: -</pre><p> - The following demonstrates that the use of the <code class="literal">net</code> command to add a group account -results in immediate mapping of the POSIX group that has been created to the Windows group account as shown -here: -<a class="indexterm" name="id368597"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net groupmap list -Domain Admins (S-1-5-21-72630-4128915-11681869-512) -> Domain Admins -Domain Users (S-1-5-21-72630-4128915-11681869-513) -> Domain Users -Domain Guests (S-1-5-21-72630-4128915-11681869-514) -> Domain Guests -Print Operators (S-1-5-21-72630-4128915-11681869-550) -> Print Operators -Backup Operators (S-1-5-21-72630-4128915-11681869-551) -> Backup Operators -Replicator (S-1-5-21-72630-4128915-11681869-552) -> Replicator -Domain Computers (S-1-5-21-72630-4128915-11681869-553) -> Domain Computers -Engineers (S-1-5-21-72630-4128915-11681869-3005) -> Engineers -SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs -</pre><p> - </p></div><div class="sect3" title="Mapping Windows Groups to UNIX Groups"><div class="titlepage"><div><div><h4 class="title"><a name="id368629"></a>Mapping Windows Groups to UNIX Groups</h4></div></div></div><p> -<a class="indexterm" name="id368637"></a> -<a class="indexterm" name="id368644"></a> -<a class="indexterm" name="id368651"></a> -<a class="indexterm" name="id368658"></a> - Windows groups must be mapped to UNIX system (POSIX) groups so that file system access controls - can be asserted in a manner that is consistent with the methods appropriate to the operating - system that is hosting the Samba server. - </p><p> -<a class="indexterm" name="id368670"></a> -<a class="indexterm" name="id368676"></a> -<a class="indexterm" name="id368683"></a> -<a class="indexterm" name="id368690"></a> - All file system (file and directory) access controls, within the file system of a UNIX/Linux server that is - hosting a Samba server, are implemented using a UID/GID identity tuple. Samba does not in any way override - or replace UNIX file system semantics. Thus it is necessary that all Windows networking operations that - access the file system provide a mechanism that maps a Windows user to a particular UNIX/Linux group - account. The user account must also map to a locally known UID. Note that the <code class="literal">net</code> - command does not call any RPC-functions here but directly accesses the passdb. - </p><p> -<a class="indexterm" name="id368710"></a> -<a class="indexterm" name="id368717"></a> -<a class="indexterm" name="id368724"></a> -<a class="indexterm" name="id368731"></a> -<a class="indexterm" name="id368737"></a> -<a class="indexterm" name="id368744"></a> -<a class="indexterm" name="id368751"></a> - Samba depends on default mappings for the <code class="constant">Domain Admins, Domain Users</code>, and - <code class="constant">Domain Guests</code> global groups. Additional groups may be added as shown in the - examples just given. There are times when it is necessary to map an existing UNIX group account - to a Windows group. This operation, in effect, creates a Windows group account as a consequence - of creation of the mapping. - </p><p> -<a class="indexterm" name="id368771"></a> -<a class="indexterm" name="id368783"></a> -<a class="indexterm" name="id368794"></a> - The operations that are permitted include: <code class="constant">add</code>, <code class="constant">modify</code>, - and <code class="constant">delete</code>. An example of each operation is shown here. - </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> - Commencing with Samba-3.0.23 Windows Domain Groups must be explicitly created. By default, all - UNIX groups are exposed to Windows networking as Windows local groups. - </p></div><p> - An existing UNIX group may be mapped to an existing Windows group by this example: -</p><pre class="screen"> -<code class="prompt">root# </code> net groupmap modify ntgroup="Domain Users" unixgroup=users -</pre><p> - An existing UNIX group may be mapped to a new Windows group as shown here: -</p><pre class="screen"> -<code class="prompt">root# </code> net groupmap add ntgroup="EliteEngrs" unixgroup=Engineers type=d -</pre><p> - Supported mapping types are 'd' (domain global) and 'l' (domain local). - A Windows group may be deleted, and then a new Windows group can be mapped to the UNIX group by - executing these commands: -</p><pre class="screen"> -<code class="prompt">root# </code> net groupmap delete ntgroup=Engineers -<code class="prompt">root# </code> net groupmap add ntgroup=EngineDrivers unixgroup=Engineers type=d -</pre><p> - The deletion and addition operations affected only the logical entities known as Windows groups, or domain - groups. These operations are inert to UNIX system groups, meaning that they neither delete nor create UNIX - system groups. The mapping of a UNIX group to a Windows group makes the UNIX group available as Windows - groups so that files and folders on domain member clients (workstations and servers) can be given - domain-wide access controls for domain users and groups. - </p><p> - Two types of Windows groups can be created: <code class="constant">domain (global)</code> and <code class="constant">local</code>. - In the previous examples the Windows groups created were of type <code class="constant">domain</code> or global. The - following command will create a Windows group of type <code class="constant">local</code>. -</p><pre class="screen"> -<code class="prompt">root# </code> net groupmap add ntgroup=Pixies unixgroup=pixies type=l -</pre><p> - Supported mapping types are 'd' (domain global) and 'l' (domain local), a domain local group in Samba is - treated as local to the individual Samba server. Local groups can be used with Samba to enable multiple - nested group support. - </p></div><div class="sect3" title="Deleting a Group Account"><div class="titlepage"><div><div><h4 class="title"><a name="id368910"></a>Deleting a Group Account</h4></div></div></div><p> -<a class="indexterm" name="id368918"></a> - A group account may be deleted by executing the following command: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group delete SupportEngineers -Uroot%not24get -</pre><p> - </p><p> - Validation of the deletion is advisable. The same commands may be executed as shown above. - </p></div><div class="sect3" title="Rename Group Accounts"><div class="titlepage"><div><div><h4 class="title"><a name="id368948"></a>Rename Group Accounts</h4></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> - This command is not documented in the man pages; it is implemented in the source code, but it does not - work at this time. The example given documents, from the source code, how it should work. Watch the - release notes of a future release to see when this may have been fixed. - </p></div><p> - Sometimes it is necessary to rename a group account. Good administrators know how painful some managers' - demands can be if this simple request is ignored. The following command demonstrates how the Windows group - <span class="quote">“<span class="quote">SupportEngrs</span>”</span> can be renamed to <span class="quote">“<span class="quote">CustomerSupport</span>”</span>: -<a class="indexterm" name="id368972"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group rename SupportEngrs \ - CustomerSupport -Uroot%not24get -</pre><p> - </p></div></div><div class="sect2" title="Manipulating Group Memberships"><div class="titlepage"><div><div><h3 class="title"><a name="grpmemshipchg"></a>Manipulating Group Memberships</h3></div></div></div><p> - Three operations can be performed regarding group membership. It is possible to (1) add Windows users - to a Windows group, to (2) delete Windows users from Windows groups, and to (3) list the Windows users that are - members of a Windows group. - </p><p> - To avoid confusion, it makes sense to check group membership before attempting to make any changes. - The <code class="literal">getent group</code> will list UNIX/Linux group membership. UNIX/Linux group members are - seen also as members of a Windows group that has been mapped using the <code class="literal">net groupmap</code> - command (see <a class="link" href="groupmapping.html" title="Chapter 12. Group Mapping: MS Windows and UNIX">“Group Mapping: MS Windows and UNIX”</a>). The following list of UNIX/Linux group membership shows - that the user <code class="constant">ajt</code> is a member of the UNIX/Linux group <code class="constant">Engineers</code>. -</p><pre class="screen"> -<code class="prompt">root# </code> getent group -... -Domain Admins:x:512:root -Domain Users:x:513:jht,lct,ajt,met,vlendecke -Domain Guests:x:514: -Print Operators:x:550: -Backup Operators:x:551: -Replicator:x:552: -Domain Computers:x:553: -Engineers:x:1000:jht,ajt -</pre><p> - The UNIX/Linux groups have been mapped to Windows groups, as is shown here: -</p><pre class="screen"> -<code class="prompt">root# </code> net groupmap list -Domain Admins (S-1-5-21-72630-412605-116429-512) -> Domain Admins -Domain Users (S-1-5-21-72630-412605-116429-513) -> Domain Users -Domain Guests (S-1-5-21-72630-412605-116429-514) -> Domain Guests -Print Operators (S-1-5-21-72630-412605-116429-550) -> Print Operators -Backup Operators (S-1-5-21-72630-412605-116429-551) -> Backup Operators -Replicator (S-1-5-21-72630-412605-116429-552) -> Replicator -Domain Computers (S-1-5-21-72630-412605-116429-553) -> Domain Computers -Engineers (S-1-5-21-72630-412605-116429-3001) -> Engineers -</pre><p> - </p><p> - Given that the user <code class="constant">ajt</code> is already a member of the UNIX/Linux group and, via the - group mapping, a member of the Windows group, an attempt to add this account again should fail. This is - demonstrated here: -<a class="indexterm" name="id369083"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get -Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP -</pre><p> - This shows that the group mapping between UNIX/Linux groups and Windows groups is effective and - transparent. - </p><p> - To permit the user <code class="constant">ajt</code> to be added using the <code class="literal">net rpc group</code> utility, - this account must first be removed. The removal and confirmation of its effect is shown here: -<a class="indexterm" name="id369121"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24get -<code class="prompt">root# </code> getent group Engineers -Engineers:x:1000:jht -<code class="prompt">root# </code> net rpc group members Engineers -Uroot%not24get -MIDEARTH\jht -</pre><p> - In this example both at the UNIX/Linux system level, the group no longer has the <code class="constant">ajt</code> - as a member. The above also shows this to be the case for Windows group membership. - </p><p> - The account is now added again, using the <code class="literal">net rpc group</code> utility: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get -<code class="prompt">root# </code> getent group Engineers -Engineers:x:1000:jht,ajt -<code class="prompt">root# </code> net rpc group members Engineers -Uroot%not24get -MIDEARTH\jht -MIDEARTH\ajt -</pre><p> - </p><p> - In this example the members of the Windows <code class="constant">Domain Users</code> account are validated using - the <code class="literal">net rpc group</code> utility. Note the this contents of the UNIX/Linux group was shown - four paragraphs earlier. The Windows (domain) group membership is shown here: -<a class="indexterm" name="id369211"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group members "Domain Users" -Uroot%not24get -MIDEARTH\jht -MIDEARTH\lct -MIDEARTH\ajt -MIDEARTH\met -MIDEARTH\vlendecke -</pre><p> - This express example shows that Windows group names are treated by Samba (as with - MS Windows) in a case-insensitive manner: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group members "DomAiN USerS" -Uroot%not24get -MIDEARTH\jht -MIDEARTH\lct -MIDEARTH\ajt -MIDEARTH\met -MIDEARTH\vlendecke -</pre><p> - </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> - An attempt to specify the group name as <code class="constant">MIDEARTH\Domain Users</code> in place of - just simply <code class="constant">Domain Users</code> will fail. The default behavior of the net rpc group - is to direct the command at the local machine. The Windows group is treated as being local to the machine. - If it is necessary to query another machine, its name can be specified using the <code class="constant">-S - servername</code> parameter to the <code class="literal">net</code> command. - </p></div></div><div class="sect2" title="Nested Group Support"><div class="titlepage"><div><div><h3 class="title"><a name="nestedgrpmgmgt"></a>Nested Group Support</h3></div></div></div><p> - It is possible in Windows (and now in Samba also) to create a local group that has members (contains), - domain users, and domain global groups. Creation of the local group <code class="constant">demo</code> is - achieved by executing: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group add demo -L -S MORDON -Uroot%not24get -</pre><p> - The -L switch means create a local group. Use the -S argument to direct the operation to a particular - server. The parameters to the -U argument should be for a user who has appropriate administrative right - and privileges on the machine. - </p><p> - Addition and removal of group members can be achieved using the <code class="constant">addmem</code> and - <code class="constant">delmem</code> subcommands of <code class="literal">net rpc group</code> command. For example, - addition of <span class="quote">“<span class="quote">DOM\Domain Users</span>”</span> to the local group <code class="constant">demo</code> would be - done by executing: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get -</pre><p> - </p><p> - The members of a nested group can be listed by executing the following: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group members demo -Uroot%not24get -DOM\Domain Users -DOM\Engineers -DOM\jamesf -DOM\jht -</pre><p> - </p><p> - Nested group members can be removed (deleted) as shown here: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group delmem demo "DOM\jht" -Uroot%not24get -</pre><p> - </p><div class="sect3" title="Managing Nest Groups on Workstations from the Samba Server"><div class="titlepage"><div><div><h4 class="title"><a name="id369374"></a>Managing Nest Groups on Workstations from the Samba Server</h4></div></div></div><p> - Windows network administrators often ask on the Samba mailing list how it is possible to grant everyone - administrative rights on their own workstation. This is of course a very bad practice, but commonly done - to avoid user complaints. Here is how it can be done remotely from a Samba PDC or BDC: -<a class="indexterm" name="id369385"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc group addmem "Administrators" "Domain Users" \ - -S WINPC032 -Uadministrator%secret -</pre><p> - </p><p> - This can be scripted, and can therefore be performed as a user logs onto the domain from a Windows - workstation. Here is a simple example that shows how this can be done. - </p><div class="procedure" title="Procedure 13.1. Automating User Addition to the Workstation Power Users Group"><a name="id369414"></a><p class="title"><b>Procedure 13.1. Automating User Addition to the Workstation Power Users Group</b></p><div class="example"><a name="autopoweruserscript"></a><p class="title"><b>Example 13.1. Script to Auto-add Domain Users to Workstation Power Users Group</b></p><div class="example-contents"><pre class="screen"> -#!/bin/bash - -/usr/bin/net rpc group addmem "Power Users" "DOMAIN_NAME\$1" \ - -UAdministrator%secret -S $2 - -exit 0 -</pre></div></div><br class="example-break"><div class="example"><a name="magicnetlogon"></a><p class="title"><b>Example 13.2. A Magic Netlogon Share</b></p><div class="example-contents"><table border="0" summary="Simple list" class="simplelist"><tr><td> </td></tr><tr><td><em class="parameter"><code>[netlogon]</code></em></td></tr><tr><td><a class="indexterm" name="id369563"></a><em class="parameter"><code>comment = Netlogon Share</code></em></td></tr><tr><td><a class="indexterm" name="id369574"></a><em class="parameter"><code>path = /var/lib/samba/netlogon</code></em></td></tr><tr><td><a class="indexterm" name="id369586"></a><em class="parameter"><code>root preexec = /etc/samba/scripts/autopoweruser.sh %U %m</code></em></td></tr><tr><td><a class="indexterm" name="id369598"></a><em class="parameter"><code>read only = Yes</code></em></td></tr><tr><td><a class="indexterm" name="id369609"></a><em class="parameter"><code>guest ok = Yes</code></em></td></tr></table></div></div><br class="example-break"><ol class="procedure" type="1"><li class="step" title="Step 1"><p> - Create the script shown in <a class="link" href="NetCommand.html#autopoweruserscript" title="Example 13.1. Script to Auto-add Domain Users to Workstation Power Users Group">“Script to Auto-add Domain Users to Workstation Power Users Group”</a> and locate it in - the directory <code class="filename">/etc/samba/scripts</code>, named as <code class="filename">autopoweruser.sh</code>. -<a class="indexterm" name="id369445"></a> -<a class="indexterm" name="id369456"></a> -<a class="indexterm" name="id369463"></a> - </p></li><li class="step" title="Step 2"><p> - Set the permissions on this script to permit it to be executed as part of the logon process: -</p><pre class="screen"> -<code class="prompt">root# </code> chown root:root /etc/samba/autopoweruser.sh -<code class="prompt">root# </code> chmod 755 /etc/samba/autopoweruser.sh -</pre><p> - </p></li><li class="step" title="Step 3"><p> - Modify the <code class="filename">smb.conf</code> file so the <code class="literal">NETLOGON</code> stanza contains the parameters - shown in <a class="link" href="NetCommand.html#magicnetlogon" title="Example 13.2. A Magic Netlogon Share">the Netlogon Example smb.conf file</a> as shown. - </p></li><li class="step" title="Step 4"><p> - Ensure that every Windows workstation Administrator account has the same password that you - have used in the script shown in <a class="link" href="NetCommand.html#magicnetlogon" title="Example 13.2. A Magic Netlogon Share">the Netlogon Example smb.conf - file</a> - </p></li></ol></div><p> - This script will be executed every time a user logs on to the network. Therefore every user will - have local Windows workstation management rights. This could of course be assigned using a group, - in which case there is little justification for the use of this procedure. The key justification - for the use of this method is that it will guarantee that all users have appropriate rights on - the workstation. - </p></div></div></div><div class="sect1" title="UNIX and Windows User Management"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id369648"></a>UNIX and Windows User Management</h2></div></div></div><p> -<a class="indexterm" name="id369656"></a> -<a class="indexterm" name="id369662"></a> -<a class="indexterm" name="id369669"></a> -<a class="indexterm" name="id369675"></a> -<a class="indexterm" name="id369682"></a> -<a class="indexterm" name="id369689"></a> -<a class="indexterm" name="id369696"></a> -<a class="indexterm" name="id369703"></a> - Every Windows network user account must be translated to a UNIX/Linux user account. In actual fact, - the only account information the UNIX/Linux Samba server needs is a UID. The UID is available either - from a system (POSIX) account or from a pool (range) of UID numbers that is set aside for the purpose - of being allocated for use by Windows user accounts. In the case of the UID pool, the UID for a - particular user will be allocated by <code class="literal">winbindd</code>. - </p><p> - Although this is not the appropriate place to discuss the <a class="link" href="smb.conf.5.html#USERNAMEMAP" target="_top">username map</a> facility, - this interface is an important method of mapping a Windows user account to a UNIX account that has a - different name. Refer to the man page for the <code class="filename">smb.conf</code> file for more information regarding this - facility. User name mappings cannot be managed using the <code class="literal">net</code> utility. - </p><div class="sect2" title="Adding User Accounts"><div class="titlepage"><div><div><h3 class="title"><a name="sbeuseraddn"></a>Adding User Accounts</h3></div></div></div><p> - The syntax for adding a user account via the <code class="literal">net</code> (according to the man page) is shown - here: -</p><pre class="screen"> -net [<method>] user ADD <name> [-c container] [-F user flags] \ - [misc. options] [targets] -</pre><p> - The user account password may be set using this syntax: -</p><pre class="screen"> -net rpc password <username> [<password>] -Uadmin_username%admin_pass -</pre><p> - </p><p> - The following demonstrates the addition of an account to the server <code class="constant">FRODO</code>: -<a class="indexterm" name="id369787"></a> -<a class="indexterm" name="id369798"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc user add jacko -S FRODO -Uroot%not24get -Added user jacko -</pre><p> - The account password can be set with the following methods (all show the same operation): -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc password jacko f4sth0rse -S FRODO -Uroot%not24get -<code class="prompt">root# </code> net rpc user password jacko f4sth0rse \ - -S FRODO -Uroot%not24get -</pre><p> - </p></div><div class="sect2" title="Deletion of User Accounts"><div class="titlepage"><div><div><h3 class="title"><a name="id369843"></a>Deletion of User Accounts</h3></div></div></div><p> - Deletion of a user account can be done using the following syntax: -</p><pre class="screen"> -net [<method>] user DELETE <name> [misc. options] [targets] -</pre><p> - The following command will delete the user account <code class="constant">jacko</code>: -<a class="indexterm" name="id369862"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc user delete jacko -Uroot%not24get -Deleted user account -</pre><p> - </p></div><div class="sect2" title="Managing User Accounts"><div class="titlepage"><div><div><h3 class="title"><a name="id369887"></a>Managing User Accounts</h3></div></div></div><p> - Two basic user account operations are routinely used: change of password and querying which groups a user - is a member of. The change of password operation is shown in <a class="link" href="NetCommand.html#sbeuseraddn" title="Adding User Accounts">“Adding User Accounts”</a>. - </p><p> - The ability to query Windows group membership can be essential. Here is how a remote server may be - interrogated to find which groups a user is a member of: -<a class="indexterm" name="id369908"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc user info jacko -S SAURON -Uroot%not24get -net rpc user info jacko -S SAURON -Uroot%not24get -Domain Users -Domain Admins -Engineers -TorridGroup -BOP Shop -Emergency Services -</pre><p> - </p><p> - It is also possible to rename user accounts: -<a class="indexterm" name="id369935"></a>oldusername newusername - Note that this operation does not yet work against Samba Servers. It is, however, possible to rename useraccounts on - Windows Servers. - - </p></div><div class="sect2" title="User Mapping"><div class="titlepage"><div><div><h3 class="title"><a name="id369950"></a>User Mapping</h3></div></div></div><p> -<a class="indexterm" name="id369957"></a> -<a class="indexterm" name="id369964"></a> -<a class="indexterm" name="id369971"></a> - In some situations it is unavoidable that a user's Windows logon name will differ from the login ID - that user has on the Samba server. It is possible to create a special file on the Samba server that - will permit the Windows user name to be mapped to a different UNIX/Linux user name. The <code class="filename">smb.conf</code> - file must also be amended so that the <code class="constant">[global]</code> stanza contains the parameter: -</p><pre class="screen"> -username map = /etc/samba/smbusers -</pre><p> - The content of the <code class="filename">/etc/samba/smbusers</code> file is shown here: -</p><pre class="screen"> -parsonsw: "William Parsons" -marygee: geeringm -</pre><p> - In this example the Windows user account <span class="quote">“<span class="quote">William Parsons</span>”</span> will be mapped to the UNIX user - <code class="constant">parsonsw</code>, and the Windows user account <span class="quote">“<span class="quote">geeringm</span>”</span> will be mapped to the - UNIX user <code class="constant">marygee</code>. - </p></div></div><div class="sect1" title="Administering User Rights and Privileges"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id370027"></a>Administering User Rights and Privileges</h2></div></div></div><p> -<a class="indexterm" name="id370035"></a> -<a class="indexterm" name="id370042"></a> -<a class="indexterm" name="id370049"></a> -<a class="indexterm" name="id370056"></a> -<a class="indexterm" name="id370062"></a> - With all versions of Samba earlier than 3.0.11 the only account on a Samba server that could - manage users, groups, shares, printers, and such was the <code class="constant">root</code> account. This caused - problems for some users and was a frequent source of scorn over the necessity to hand out the - credentials for the most security-sensitive account on a UNIX/Linux system. - </p><p> -<a class="indexterm" name="id370079"></a> -<a class="indexterm" name="id370086"></a> -<a class="indexterm" name="id370093"></a> -<a class="indexterm" name="id370100"></a> -<a class="indexterm" name="id370106"></a> - New to Samba version 3.0.11 is the ability to delegate administrative privileges as necessary to either - a normal user or to groups of users. The significance of the administrative privileges is documented - in <a class="link" href="rights.html" title="Chapter 15. User Rights and Privileges">“User Rights and Privileges”</a>. Examples of use of the <code class="literal">net</code> for user rights and privilege - management is appropriate to this chapter. - </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> - When user rights and privileges are correctly set, there is no longer a need for a Windows - network account for the <code class="constant">root</code> user (nor for any synonym of it) with a UNIX UID=0. - Initial user rights and privileges can be assigned by any account that is a member of the <code class="constant"> - Domain Admins</code> group. Rights can be assigned to user as well as group accounts. - </p></div><p> - By default, no privileges and rights are assigned. This is demonstrated by executing the command - shown here: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc rights list accounts -U root%not24get -BUILTIN\Print Operators -No privileges assigned - -BUILTIN\Account Operators -No privileges assigned - -BUILTIN\Backup Operators -No privileges assigned - -BUILTIN\Server Operators -No privileges assigned - -BUILTIN\Administrators -No privileges assigned - -Everyone -No privileges assigned -</pre><p> - </p><p> - The <code class="literal">net</code> command can be used to obtain the currently supported capabilities for rights - and privileges using this method: -<a class="indexterm" name="id370170"></a> -<a class="indexterm" name="id370177"></a> -<a class="indexterm" name="id370184"></a> -<a class="indexterm" name="id370190"></a> -<a class="indexterm" name="id370197"></a> -<a class="indexterm" name="id370204"></a> -<a class="indexterm" name="id370211"></a> -<a class="indexterm" name="id370218"></a> -<a class="indexterm" name="id370225"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc rights list -U root%not24get - SeMachineAccountPrivilege Add machines to domain - SePrintOperatorPrivilege Manage printers - SeAddUsersPrivilege Add users and groups to the domain - SeRemoteShutdownPrivilege Force shutdown from a remote system - SeDiskOperatorPrivilege Manage disk shares - SeBackupPrivilege Back up files and directories - SeRestorePrivilege Restore files and directories - SeTakeOwnershipPrivilege Take ownership of files or other objects -</pre><p> - Machine account privilege is necessary to permit a Windows NT4 or later network client to be added to the - domain. The disk operator privilege is necessary to permit the user to manage share ACLs and file and - directory ACLs for objects not owned by the user. - </p><p> - In this example, all rights are assigned to the <code class="constant">Domain Admins</code> group. This is a good - idea since members of this group are generally expected to be all-powerful. This assignment makes that - the reality: -<a class="indexterm" name="id370262"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc rights grant "MIDEARTH\Domain Admins" \ - SeMachineAccountPrivilege SePrintOperatorPrivilege \ - SeAddUsersPrivilege SeRemoteShutdownPrivilege \ - SeDiskOperatorPrivilege -U root%not24get -Successfully granted rights. -</pre><p> - Next, the domain user <code class="constant">jht</code> is given the privileges needed for day-to-day - administration: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc rights grant "MIDEARTH\jht" \ - SeMachineAccountPrivilege SePrintOperatorPrivilege \ - SeAddUsersPrivilege SeDiskOperatorPrivilege \ - -U root%not24get -Successfully granted rights. -</pre><p> - </p><p> - The following step permits validation of the changes just made: -<a class="indexterm" name="id370308"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc rights list accounts -U root%not24get -MIDEARTH\jht -SeMachineAccountPrivilege -SePrintOperatorPrivilege -SeAddUsersPrivilege -SeDiskOperatorPrivilege - -BUILTIN\Print Operators -No privileges assigned - -BUILTIN\Account Operators -No privileges assigned - -BUILTIN\Backup Operators -No privileges assigned - -BUILTIN\Server Operators -No privileges assigned - -BUILTIN\Administrators -No privileges assigned - -Everyone -No privileges assigned - -MIDEARTH\Domain Admins -SeMachineAccountPrivilege -SePrintOperatorPrivilege -SeAddUsersPrivilege -SeRemoteShutdownPrivilege -SeDiskOperatorPrivilege -</pre><p> - </p></div><div class="sect1" title="Managing Trust Relationships"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id370337"></a>Managing Trust Relationships</h2></div></div></div><p> - There are essentially two types of trust relationships: the first is between domain controllers and domain - member machines (network clients), the second is between domains (called interdomain trusts). All - Samba servers that participate in domain security require a domain membership trust account, as do like - Windows NT/200x/XP workstations. - </p><div class="sect2" title="Machine Trust Accounts"><div class="titlepage"><div><div><h3 class="title"><a name="id370349"></a>Machine Trust Accounts</h3></div></div></div><p> - The net command looks in the <code class="filename">smb.conf</code> file to obtain its own configuration settings. Thus, the following - command 'knows' which domain to join from the <code class="filename">smb.conf</code> file. - </p><p> - A Samba server domain trust account can be validated as shown in this example: -<a class="indexterm" name="id370374"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc testjoin -Join to 'MIDEARTH' is OK -</pre><p> - Where there is no domain membership account, or when the account credentials are not valid, the following - results will be observed: -</p><pre class="screen"> -net rpc testjoin -S DOLPHIN -Join to domain 'WORLDOCEAN' is not valid -</pre><p> - </p><p> - The equivalent command for joining a Samba server to a Windows ADS domain is shown here: -<a class="indexterm" name="id370409"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net ads testjoin -Using short domain name -- TAKEAWAY -Joined 'LEMONADE' to realm 'TAKEAWAY.BIZ' -</pre><p> - In the event that the ADS trust was not established, or is broken for one reason or another, the following - error message may be obtained: -</p><pre class="screen"> -<code class="prompt">root# </code> net ads testjoin -UAdministrator%secret -Join to domain is not valid -</pre><p> - </p><p> - The following demonstrates the process of creating a machine trust account in the target domain for the - Samba server from which the command is executed: -<a class="indexterm" name="id370450"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc join -S FRODO -Uroot%not24get -Joined domain MIDEARTH. -</pre><p> - The joining of a Samba server to a Samba domain results in the creation of a machine account. An example - of this is shown here: -</p><pre class="screen"> -<code class="prompt">root# </code> pdbedit -Lw merlin\$ -merlin$:1009:9B4489D6B90461FD6A3EC3AB96147E16:\ -176D8C554E99914BDF3407DEA2231D80:[S ]:LCT-42891919: -</pre><p> - The S in the square brackets means this is a server (PDC/BDC) account. The domain join can be cast to join - purely as a workstation, in which case the S is replaced with a W (indicating a workstation account). The - following command can be used to affect this: -<a class="indexterm" name="id370488"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc join member -S FRODO -Uroot%not24get -Joined domain MIDEARTH. -</pre><p> - Note that the command-line parameter <code class="constant">member</code> makes this join specific. By default - the type is deduced from the <code class="filename">smb.conf</code> file configuration. To specifically join as a PDC or BDC, the - command-line parameter will be <code class="constant">[PDC | BDC]</code>. For example: -<a class="indexterm" name="id370526"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc join bdc -S FRODO -Uroot%not24get -Joined domain MIDEARTH. -</pre><p> - It is best to let Samba figure out the domain join type from the settings in the <code class="filename">smb.conf</code> file. - </p><p> - The command to join a Samba server to a Windows ADS domain is shown here: -<a class="indexterm" name="id370560"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net ads join -UAdministrator%not24get -Using short domain name -- GDANSK -Joined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ' -</pre><p> - </p><p> - There is no specific option to remove a machine account from an NT4 domain. When a domain member that is a - Windows machine is withdrawn from the domain, the domain membership account is not automatically removed - either. Inactive domain member accounts can be removed using any convenient tool. If necessary, the - machine account can be removed using the following <code class="literal">net</code> command: -<a class="indexterm" name="id370596"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc user delete HERRING\$ -Uroot%not24get -Deleted user account. -</pre><p> - The removal is made possible because machine accounts are just like user accounts with a trailing $ - character. The account management operations treat user and machine accounts in like manner. - </p><p> - A Samba-3 server that is a Windows ADS domain member can execute the following command to detach from the - domain: -<a class="indexterm" name="id370625"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net ads leave -</pre><p> - </p><p> - Detailed information regarding an ADS domain can be obtained by a Samba DMS machine by executing the - following: -<a class="indexterm" name="id370651"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net ads status -</pre><p> - The volume of information is extensive. Please refer to the book <span class="quote">“<span class="quote">Samba-3 by Example</span>”</span>, - Chapter 7 for more information regarding its use. This book may be obtained either in print or online from - the <a class="ulink" href="http://www.samba.org/samba/docs/Samba3-ByExample.pdf" target="_top">Samba-3 by Example</a>. - </p></div><div class="sect2" title="Interdomain Trusts"><div class="titlepage"><div><div><h3 class="title"><a name="id370687"></a>Interdomain Trusts</h3></div></div></div><p> - Interdomain trust relationships form the primary mechanism by which users from one domain can be granted - access rights and privileges in another domain. - </p><p> - To discover what trust relationships are in effect, execute this command: -<a class="indexterm" name="id370700"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc trustdom list -Uroot%not24get -Trusted domains list: - -none - -Trusting domains list: - -none -</pre><p> - There are no interdomain trusts at this time; the following steps will create them. - </p><p> - It is necessary to create a trust account in the local domain. A domain controller in a second domain can - create a trusted connection with this account. That means that the foreign domain is being trusted - to access resources in the local domain. This command creates the local trust account: -<a class="indexterm" name="id370730"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc trustdom add DAMNATION f00db4r -Uroot%not24get -</pre><p> - The account can be revealed by using the <code class="literal">pdbedit</code> as shown here: -</p><pre class="screen"> -<code class="prompt">root# </code> pdbedit -Lw DAMNATION\$ -DAMNATION$:1016:9AC1F121DF897688AAD3B435B51404EE: \ -7F845808B91BB9F7FEF44B247D9DC9A6:[I ]:LCT-428934B1: -</pre><p> - A trust account will always have an I in the field within the square brackets. - </p><p> - If the trusting domain is not capable of being reached, the following command will fail: -<a class="indexterm" name="id370777"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc trustdom list -Uroot%not24get -Trusted domains list: - -none - -Trusting domains list: - -DAMNATION S-1-5-21-1385457007-882775198-1210191635 -</pre><p> - The above command executed successfully; a failure is indicated when the following response is obtained: -</p><pre class="screen"> -net rpc trustdom list -Uroot%not24get -Trusted domains list: - -DAMNATION S-1-5-21-1385457007-882775198-1210191635 - -Trusting domains list: - -DAMNATION domain controller is not responding -</pre><p> - </p><p> - Where a trust account has been created on a foreign domain, Samba is able to establish the trust (connect with) - the foreign account. In the process it creates a one-way trust to the resources on the remote domain. This - command achieves the objective of joining the trust relationship: -<a class="indexterm" name="id370815"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc trustdom establish DAMNATION -Password: xxxxxxx == f00db4r -Could not connect to server TRANSGRESSION -Trust to domain DAMNATION established -</pre><p> - Validation of the two-way trust now established is possible as shown here: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc trustdom list -Uroot%not24get -Trusted domains list: - -DAMNATION S-1-5-21-1385457007-882775198-1210191635 - -Trusting domains list: - -DAMNATION S-1-5-21-1385457007-882775198-1210191635 -</pre><p> - </p><p> - Sometimes it is necessary to remove the ability for local users to access a foreign domain. The trusting - connection can be revoked as shown here: -<a class="indexterm" name="id370857"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc trustdom revoke DAMNATION -Uroot%not24get -</pre><p> - At other times it becomes necessary to remove the ability for users from a foreign domain to be able to - access resources in the local domain. The command shown here will do that: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc trustdom del DAMNATION -Uroot%not24get -</pre><p> - - </p></div></div><div class="sect1" title="Managing Security Identifiers (SIDS)"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id370896"></a>Managing Security Identifiers (SIDS)</h2></div></div></div><p> -<a class="indexterm" name="id370904"></a> -<a class="indexterm" name="id370911"></a> -<a class="indexterm" name="id370918"></a> -<a class="indexterm" name="id370924"></a> -<a class="indexterm" name="id370931"></a> - The basic security identifier that is used by all Windows networking operations is the Windows security - identifier (SID). All Windows network machines (servers and workstations), users, and groups are - identified by their respective SID. All desktop profiles are also encoded with user and group SIDs that - are specific to the SID of the domain to which the user belongs. - </p><p> -<a class="indexterm" name="id370945"></a> -<a class="indexterm" name="id370951"></a> -<a class="indexterm" name="id370958"></a> -<a class="indexterm" name="id370965"></a> - It is truly prudent to store the machine and/or domain SID in a file for safekeeping. Why? Because - a change in hostname or in the domain (workgroup) name may result in a change in the SID. When you - have the SID on hand, it is a simple matter to restore it. The alternative is to suffer the pain of - having to recover user desktop profiles and perhaps rejoin all member machines to the domain. - </p><p> - First, do not forget to store the local SID in a file. It is a good idea to put this in the directory - in which the <code class="filename">smb.conf</code> file is also stored. Here is a simple action to achieve this: -<a class="indexterm" name="id370986"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net getlocalsid > /etc/samba/my-sid -</pre><p> - Good, there is now a safe copy of the local machine SID. On a PDC/BDC this is the domain SID also. - </p><p> - The following command reveals what the former one should have placed into the file called - <code class="filename">my-sid</code>: -</p><pre class="screen"> -<code class="prompt">root# </code> net getlocalsid -SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429 -</pre><p> - </p><p> - If ever it becomes necessary to restore the SID that has been stored in the <code class="filename">my-sid</code> - file, simply copy the SID (the string of characters that begins with <code class="constant">S-1-5-21</code>) to - the command line shown here: -<a class="indexterm" name="id371043"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net setlocalsid S-1-5-21-1385457007-882775198-1210191635 -</pre><p> - Restoration of a machine SID is a simple operation, but the absence of a backup copy can be very - problematic. - </p><p> - The following operation is useful only for machines that are being configured as a PDC or a BDC. - DMS and workstation clients should have their own machine SID to avoid - any potential namespace collision. Here is the way that the BDC SID can be synchronized to that - of the PDC (this is the default NT4 domain practice also): -<a class="indexterm" name="id371071"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc getsid -S FRODO -Uroot%not24get -Storing SID S-1-5-21-726309263-4128913605-1168186429 \ - for Domain MIDEARTH in secrets.tdb -</pre><p> - Usually it is not necessary to specify the target server (-S FRODO) or the administrator account - credentials (-Uroot%not24get). - </p></div><div class="sect1" title="Share Management"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id371098"></a>Share Management</h2></div></div></div><p> - Share management is central to all file serving operations. Typical share operations include: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Creation/change/deletion of shares</p></li><li class="listitem"><p>Setting/changing ACLs on shares</p></li><li class="listitem"><p>Moving shares from one server to another</p></li><li class="listitem"><p>Change of permissions of share contents</p></li></ul></div><p> - Each of these are dealt with here insofar as they involve the use of the <code class="literal">net</code> - command. Operations outside of this command are covered elsewhere in this document. - </p><div class="sect2" title="Creating, Editing, and Removing Shares"><div class="titlepage"><div><div><h3 class="title"><a name="id371140"></a>Creating, Editing, and Removing Shares</h3></div></div></div><p> - A share can be added using the <code class="literal">net rpc share</code> command capabilities. - The target machine may be local or remote and is specified by the -S option. It must be noted - that the addition and deletion of shares using this tool depends on the availability of a suitable - interface script. The interface scripts Sambas <code class="literal">smbd</code> uses are called - <a class="link" href="smb.conf.5.html#ADDSHARECOMMAND" target="_top">add share command</a>, <a class="link" href="smb.conf.5.html#DELETESHARECOMMAND" target="_top">delete share command</a> and - <a class="link" href="smb.conf.5.html#CHANGESHARECOMMAND" target="_top">change share command</a>. A set of example scripts are provided in the Samba source - code tarball in the directory <code class="filename">~samba/examples/scripts</code>. - </p><p> - The following steps demonstrate the use of the share management capabilities of the <code class="literal">net</code> - utility. In the first step a share called <code class="constant">Bulge</code> is added. The sharepoint within the - file system is the directory <code class="filename">/data</code>. The command that can be executed to perform the - addition of this share is shown here: -<a class="indexterm" name="id371223"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc share add Bulge=/data -S MERLIN -Uroot%not24get -</pre><p> - Validation is an important process, and by executing the command <code class="literal">net rpc share</code> - with no other operators it is possible to obtain a listing of available shares, as shown here: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc share -S MERLIN -Uroot%not24get -profdata -archive -Bulge <--- This one was added -print$ -netlogon -profiles -IPC$ -kyocera -ADMIN$ -</pre><p> - </p><p> - Often it is desirable also to permit a share to be removed using a command-line tool. - The following step permits the share that was previously added to be removed: -<a class="indexterm" name="id371271"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc share delete Bulge -S MERLIN -Uroot%not24get -</pre><p> - A simple validation shown here demonstrates that the share has been removed: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc share -S MERLIN -Uroot%not24get -profdata -archive -print$ -netlogon -profiles -IPC$ -ADMIN$ -kyocera -</pre><p> - </p></div><div class="sect2" title="Creating and Changing Share ACLs"><div class="titlepage"><div><div><h3 class="title"><a name="id371309"></a>Creating and Changing Share ACLs</h3></div></div></div><p> - At this time the <code class="literal">net</code> tool cannot be used to manage ACLs on Samba shares. In MS Windows - language this is called Share Permissions. - </p><p> - It is possible to set ACLs on Samba shares using either the SRVTOOLS NT4 Domain Server Manager - or using the Computer Management MMC snap-in. Neither is covered here, - but see <a class="link" href="AccessControls.html" title="Chapter 16. File, Directory, and Share Access Controls">“File, Directory, and Share Access Controls”</a>. - </p></div><div class="sect2" title="Share, Directory, and File Migration"><div class="titlepage"><div><div><h3 class="title"><a name="id371336"></a>Share, Directory, and File Migration</h3></div></div></div><p> -<a class="indexterm" name="id371344"></a> - Shares and files can be migrated in the same manner as user, machine, and group accounts. - It is possible to preserve access control settings (ACLs) as well as security settings - throughout the migration process. The <code class="literal">net rpc vampire</code> facility is used - to migrate accounts from a Windows NT4 (or later) domain to a Samba server. This process - preserves passwords and account security settings and is a precursor to the migration - of shares and files. - </p><p> - The <code class="literal">net rpc share</code> command may be used to migrate shares, directories, - files, and all relevant data from a Windows server to a Samba server. - </p><p> - A set of command-line switches permit the creation of almost direct clones of Windows file - servers. For example, when migrating a fileserver, file ACLs and DOS file attributes from - the Windows server can be included in the migration process and will reappear, almost identically, - on the Samba server when the migration has been completed. - </p><p> - The migration process can be completed only with the Samba server already being fully operational. - The user and group accounts must be migrated before attempting to migrate data - share, files, and printers. The migration of files and printer configurations involves the use - of both SMB and MS DCE RPC services. The benefit of the manner in which the migration process has - been implemented is that the possibility now exists to use a Samba server as a man-in-middle migration - service that affects a transfer of data from one server to another. For example, if the Samba - server is called MESSER, the source Windows NT4 server is called PEPPY, and the target Samba - server is called GONZALES, the machine MESSER can be used to effect the migration of all data - (files and shares) from PEPPY to GONZALES. If the target machine is not specified, the local - server is assumed by default - as net's general rule of thumb . - </p><p> - The success of server migration requires a firm understanding of the structure of the source - server (or domain) as well as the processes on which the migration is critically dependant. - </p><p> - There are two known limitations to the migration process: - </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> - The <code class="literal">net</code> command requires that the user credentials provided exist on both - the migration source and the migration target. - </p></li><li class="listitem"><p> - Printer settings may not be fully or may be incorrectly migrated. This might in particular happen - when migrating a Windows 2003 print server to Samba. - </p></li></ol></div><div class="sect3" title="Share Migration"><div class="titlepage"><div><div><h4 class="title"><a name="id371426"></a>Share Migration</h4></div></div></div><p> - The <code class="literal">net rpc share migrate</code> command operation permits the migration of plain - share stanzas. A stanza contains the parameters within which a file or print share are defined. - The use of this migration method will create share stanzas that have as parameters the file - system directory path, an optional description, and simple security settings that permit write - access to files. One of the first steps necessary following migration is to review the share - stanzas to ensure that the settings are suitable for use. - </p><p> - The shares are created on the fly as part of the migration process. The <code class="literal">smbd</code> - application does this by calling on the operating system to execute the script specified by the - <code class="filename">smb.conf</code> parameter <em class="parameter"><code>add share command</code></em>. - </p><p> - There is a suitable example script for the <em class="parameter"><code>add share command</code></em> in the - <code class="filename">$SAMBA_SOURCES/examples/scripts</code> directory. It should be noted that - the account that is used to drive the migration must, of necessity, have appropriate file system - access privileges and have the right to create shares and to set ACLs on them. Such rights are - conferred by these rights: <em class="parameter"><code>SeAddUsersPrivilege</code></em> and <em class="parameter"><code>SeDiskOperatorPrivilege</code></em>. - For more information regarding rights and privileges please refer to <a class="link" href="rights.html" title="Chapter 15. User Rights and Privileges">“User Rights and Privileges”</a>. - </p><p> - The syntax of the share migration command is shown here: -</p><pre class="screen"> -net rpc share MIGRATE SHARES <share-name> -S <source> - [--destination=localhost] [--exclude=share1,share2] [-v] -</pre><p> - When the parameter <share-name> is omitted, all shares will be migrated. The potentially - large list of available shares on the system that is being migrated can be limited using the - <em class="parameter"><code>--exclude</code></em> switch. For example: -<a class="indexterm" name="id371524"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc share migrate shares myshare\ - -S win2k -U administrator%secret" -</pre><p> - This will migrate the share <code class="constant">myshare</code> from the server <code class="constant">win2k</code> - to the Samba Server using the permissions that are tied to the account <code class="constant">administrator</code> - with the password <code class="constant">secret</code>. The account that is used must be the same on both the - migration source server and the target Samba server. The use of the <code class="literal">net rpc - vampire</code>, prior to attempting the migration of shares, will ensure that accounts will be - identical on both systems. One precaution worth taking before commencement of migration of shares is - to validate that the migrated accounts (on the Samba server) have the needed rights and privileges. - This can be done as shown here: -<a class="indexterm" name="id371572"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc right list accounts -Uroot%not24get -</pre><p> - The steps taken so far perform only the migration of shares. Directories and directory contents - are not migrated by the steps covered up to this point. - </p></div><div class="sect3" title="File and Directory Migration"><div class="titlepage"><div><div><h4 class="title"><a name="id371598"></a>File and Directory Migration</h4></div></div></div><p> - Everything covered to this point has been done in preparation for the migration of file and directory - data. For many people preparation is potentially boring and the real excitement only begins when file - data can be used. The next steps demonstrate the techniques that can be used to transfer (migrate) - data files using the <code class="literal">net</code> command. - </p><p> - Transfer of files from one server to another has always been a challenge for MS Windows - administrators because Windows NT and 200X servers do not always include the tools needed. The - <code class="literal">xcopy</code> from Windows NT is not capable of preserving file and directory ACLs, - it does so only with Windows 200x. Microsoft does provide a - utility that can copy ACLs (security settings) called <code class="literal">scopy</code>, but it is provided only - as part of the Windows NT or 200X Server Resource Kit. - </p><p> - There are several tools, both commercial and freeware, that can be used from a Windows server to copy files - and directories with full preservation of security settings. One of the best known of the free tools is - called <code class="literal">robocopy</code>. - </p><p> - The <code class="literal">net</code> utility can be used to copy files and directories with full preservation of - ACLs as well as DOS file attributes. Note that including ACLs makes sense only where the destination - system will operate within the same security context as the source system. This applies both to a - DMS and to domain controllers that result from a vampired domain. - Before file and directory migration, all shares must already exist. - </p><p> - The syntax for the migration commands is shown here: -</p><pre class="screen"> -net rpc share MIGRATE FILES <share-name> -S <source> - [--destination=localhost] [--exclude=share1,share2] - [--acls] [--attrs] [--timestamps] [-v] -</pre><p> - If the <share-name> parameter is omitted, all shares will be migrated. The potentially large - list of shares on the source system can be restricted using the <em class="parameter"><code>--exclude</code></em> command - switch. - </p><p> - Where it is necessary to preserve all file ACLs, the <em class="parameter"><code>--acls</code></em> switch should be added - to the above command line. Original file timestamps can be preserved by specifying the - <em class="parameter"><code>--timestamps</code></em> switch, and the DOS file attributes (i.e., hidden, archive, etc.) can - be preserved by specifying the <em class="parameter"><code>--attrs</code></em> switch. - </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> - The ability to preserve ACLs depends on appropriate support for ACLs as well as the general file system - semantics of the host operating system on the target server. A migration from one Windows file server to - another will perfectly preserve all file attributes. Because of the difficulty of mapping Windows ACLs - onto a POSIX ACLs-supporting system, there can be no perfect migration of Windows ACLs to a Samba server. - </p></div><p> - The ACLs that result on a Samba server will most probably not match the originating ACLs. Windows supports - the possibility of files that are owned only by a group. Group-alone file ownership is not possible under - UNIX/Linux. Errors in migrating group-owned files can be avoided by using the <code class="filename">smb.conf</code> file - <a class="link" href="smb.conf.5.html#FORCEUNKNOWNACLUSER" target="_top">force unknown acl user = yes</a> parameter. This facility will - automatically convert group-owned files into correctly user-owned files on the Samba server. - </p><p> - An example for migration of files from a machine called <code class="constant">nt4box</code> to the Samba server - from which the process will be handled is shown here: -<a class="indexterm" name="id371742"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc share migrate files -S nt4box --acls \ - --attrs -U administrator%secret -</pre><p> - </p><p> - This command will migrate all files and directories from all file shares on the Windows server called - <code class="constant">nt4box</code> to the Samba server from which migration is initiated. Files that are group-owned - will be owned by the user account <code class="constant">administrator</code>. - </p></div><div class="sect3" title="Share-ACL Migration"><div class="titlepage"><div><div><h4 class="title"><a name="id371779"></a>Share-ACL Migration</h4></div></div></div><p> - It is possible to have share-ACLs (security descriptors) that won't allow you, even as Administrator, to - copy any files or directories into it. Therefor the migration of the share-ACLs has been put into a separate - function: -<a class="indexterm" name="id371789"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc share migrate security -S nt4box -U administrator%secret -</pre><p> - </p><p> - This command will only copy the share-ACL of each share on nt4box to your local samba-system. - </p></div><div class="sect3" title="Simultaneous Share and File Migration"><div class="titlepage"><div><div><h4 class="title"><a name="id371818"></a>Simultaneous Share and File Migration</h4></div></div></div><p> - The operating mode shown here is just a combination of the previous three. It first migrates - share definitions and then all shared files and directories and finally migrates the share-ACLs: -</p><pre class="screen"> -net rpc share MIGRATE ALL <share-name> -S <source> - [--exclude=share1, share2] [--acls] [--attrs] [--timestamps] [-v] -</pre><p> - </p><p> - An example of simultaneous migration is shown here: -<a class="indexterm" name="id371839"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc share migrate all -S w2k3server -U administrator%secret -</pre><p> - This will generate a complete server clone of the <em class="parameter"><code>w2k3server</code></em> server. - </p></div></div><div class="sect2" title="Printer Migration"><div class="titlepage"><div><div><h3 class="title"><a name="id371872"></a>Printer Migration</h3></div></div></div><p> - The installation of a new server, as with the migration to a new network environment, often is similar to - building a house; progress is very rapid from the laying of foundations up to the stage at which - the house can be locked up, but the finishing off appears to take longer and longer as building - approaches completion. - </p><p> - Printing needs vary greatly depending on the network environment and may be very simple or complex. If - the need is very simple, the best solution to the implementation of printing support may well be to - re-install everything from a clean slate instead of migrating older configurations. On the other hand, - a complex network that is integrated with many international offices and a complex arrangement of local branch - offices, each of which form an inter-twined maze of printing possibilities, the ability to migrate all - printer configurations is decidedly beneficial. To manually re-establish a complex printing network - will take much time and frustration. Often it will not be possible to find driver files that are - currently in use, necessitating the installation of newer drivers. Newer drivers often implement - printing features that will necessitate a change in the printer usage. Additionally, with very complex - printer configurations it becomes almost impossible to re-create the same environment no matter - how extensively it has been documented. - </p><p> - The migration of an existing printing architecture involves the following: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Establishment of print queues.</p></li><li class="listitem"><p>Installation of printer drivers (both for the print server and for Windows clients.</p></li><li class="listitem"><p>Configuration of printing forms.</p></li><li class="listitem"><p>Implementation of security settings.</p></li><li class="listitem"><p>Configuration of printer settings.</p></li></ul></div><p> - The Samba <code class="literal">net</code> utility permits printer migration from one Windows print server - to another. When this tool is used to migrate printers to a Samba server <code class="literal">smbd</code>, - the application that receives the network requests to create the necessary services must call out - to the operating system in order to create the underlying printers. The call-out is implemented - by way of an interface script that can be specified by the <code class="filename">smb.conf</code> file parameter - <a class="link" href="smb.conf.5.html#ADDPRINTERSCRIPT" target="_top">add printer script</a>. This script is essential to the migration process. - A suitable example script may be obtained from the <code class="filename">$SAMBA_SOURCES/examples/scripts</code> - directory. Take note that this script must be customized to suit the operating system environment - and may use its tools to create a print queue. - </p><p> - Each of the components listed above can be completed separately, or they can be completed as part of an - automated operation. Many network administrators prefer to deal with migration issues in a manner that - gives them the most control, particularly when things go wrong. The syntax for each operation is now - briefly described. - </p><p> - Printer migration from a Windows print server (NT4 or 200x) is shown. This instruction causes the - printer share to be created together with the underlying print queue: -<a class="indexterm" name="id371984"></a> -</p><pre class="screen"> -net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets] -</pre><p> - Printer drivers can be migrated from the Windows print server to the Samba server using this - command-line instruction: -<a class="indexterm" name="id372002"></a> -</p><pre class="screen"> -net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets] -</pre><p> - Printer forms can be migrated with the following operation: -<a class="indexterm" name="id372019"></a> -</p><pre class="screen"> -net rpc printer MIGRATE FORMS [printer] [misc. options] [targets] -</pre><p> - Printer security settings (ACLs) can be migrated from the Windows server to the Samba server using this command: -<a class="indexterm" name="id372038"></a> -</p><pre class="screen"> -net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets] -</pre><p> - Printer configuration settings include factors such as paper size and default paper orientation. - These can be migrated from the Windows print server to the Samba server with this command: -<a class="indexterm" name="id372057"></a> -</p><pre class="screen"> -net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets] -</pre><p> - </p><p> - Migration of printers including the above-mentioned sets of information may be completed - with a single command using this syntax: -</p><pre class="screen"> -net rpc printer MIGRATE ALL [printer] [misc. options] [targets] -</pre><p> - </p></div></div><div class="sect1" title="Controlling Open Files"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id372088"></a>Controlling Open Files</h2></div></div></div><p> - The man page documents the <code class="literal">net file</code> function suite, which provides the tools to - close open files using either RAP or RPC function calls. Please refer to the man page for specific - usage information. - </p></div><div class="sect1" title="Session and Connection Management"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id372105"></a>Session and Connection Management</h2></div></div></div><p> - The session management interface of the <code class="literal">net session</code> command uses the old RAP - method to obtain the list of connections to the Samba server, as shown here: -<a class="indexterm" name="id372120"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rap session -S MERLIN -Uroot%not24get -Computer User name Client Type Opens Idle time ------------------------------------------------------------------------------- -\\merlin root Unknown Client 0 00:00:00 -\\marvel jht Unknown Client 0 00:00:00 -\\maggot jht Unknown Client 0 00:00:00 -\\marvel jht Unknown Client 0 00:00:00 -</pre><p> - </p><p> - A session can be closed by executing a command as shown here: -</p><pre class="screen"> -<code class="prompt">root# </code> net rap session close marvel -Uroot%not24get -</pre><p> - </p></div><div class="sect1" title="Printers and ADS"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id372165"></a>Printers and ADS</h2></div></div></div><p> - When Samba-3 is used within an MS Windows ADS environment, printers shared via Samba will not be browseable - until they have been published to the ADS domain. Information regarding published printers may be obtained - from the ADS server by executing the <code class="literal">net ads print info</code> command following this syntax: -<a class="indexterm" name="id372181"></a> -</p><pre class="screen"> -net ads printer info <printer_name> <server_name> -Uadministrator%secret -</pre><p> - If the asterisk (*) is used in place of the printer_name argument, a list of all printers will be - returned. - </p><p> - To publish (make available) a printer to ADS, execute the following command: -<a class="indexterm" name="id372204"></a> -</p><pre class="screen"> -net ads printer publish <printer_name> -Uadministrator%secret -</pre><p> - This publishes a printer from the local Samba server to ADS. - </p><p> - Removal of a Samba printer from ADS is achieved by executing this command: -<a class="indexterm" name="id372226"></a> -</p><pre class="screen"> -net ads printer remove <printer_name> -Uadministrator%secret -</pre><p> - </p><p> - A generic search (query) can also be made to locate a printer across the entire ADS domain by executing: -<a class="indexterm" name="id372248"></a> -</p><pre class="screen"> -net ads printer search <printer_name> -Uadministrator%secret -</pre><p> - </p></div><div class="sect1" title="Manipulating the Samba Cache"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id372268"></a>Manipulating the Samba Cache</h2></div></div></div><p> - Please refer to the <code class="literal">net</code> command man page for information regarding cache management. - </p></div><div class="sect1" title="Managing IDMAP UID/SID Mappings"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id372285"></a>Managing IDMAP UID/SID Mappings</h2></div></div></div><p> - The IDMAP UID to SID, and SID to UID, mappings that are created by <code class="literal">winbindd</code> can be - backed up to a text file. The text file can be manually edited, although it is highly recommended that - you attempt this only if you know precisely what you are doing. - </p><p> - An IDMAP text dump file can be restored (or reloaded). There are two situations that may necessitate - this action: a) The existing IDMAP file is corrupt, b) It is necessary to install an editted version - of the mapping information. - </p><p> - Winbind must be shut down to dump the IDMAP file. Before restoring a dump file, shut down - <code class="literal">winbindd</code> and delete the old <code class="filename">winbindd_idmap.tdb</code> file. - </p><div class="sect2" title="Creating an IDMAP Database Dump File"><div class="titlepage"><div><div><h3 class="title"><a name="id372323"></a>Creating an IDMAP Database Dump File</h3></div></div></div><p> - The IDMAP database can be dumped to a text file as shown here: -</p><pre class="screen"> -net idmap dump <full_path_and_tdb_filename> > dumpfile.txt -</pre><p> - Where a particular build of Samba the run-time tdb files are stored in the - <code class="filename">/var/lib/samba</code> directory the following commands to create the dump file will suffice: -</p><pre class="screen"> -net idmap dump /var/lib/samba/winbindd_idmap.tdb > idmap_dump.txt -</pre><p> - </p></div><div class="sect2" title="Restoring the IDMAP Database Dump File"><div class="titlepage"><div><div><h3 class="title"><a name="id372354"></a>Restoring the IDMAP Database Dump File</h3></div></div></div><p> - The IDMAP dump file can be restored using the following command: -</p><pre class="screen"> -net idmap restore idmap_dump.txt -</pre><p> - Where the Samba run-time tdb files are stored in the <code class="filename">/var/lib/samba</code> directory - the following command can be used to restore the data to the tdb file: -</p><pre class="screen"> -net idmap restore /var/lib/samba/winbindd_idmap.tdb < idmap_dump.txt -</pre><p> - </p></div></div><div class="sect1" title="Other Miscellaneous Operations"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="netmisc1"></a>Other Miscellaneous Operations</h2></div></div></div><p> - The following command is useful for obtaining basic statistics regarding a Samba domain. This command does - not work with current Windows XP Professional clients. -<a class="indexterm" name="id372399"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc info -Domain Name: RAPIDFLY -Domain SID: S-1-5-21-399034208-633907489-3292421255 -Sequence number: 1116312355 -Num users: 720 -Num domain groups: 27 -Num local groups: 6 -</pre><p> - </p><p> - Another useful tool is the <code class="literal">net time</code> tool set. This tool may be used to query the - current time on the target server as shown here: -<a class="indexterm" name="id372432"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net time -S SAURON -Tue May 17 00:50:43 2005 -</pre><p> - In the event that it is the intent to pass the time information obtained to the UNIX - <code class="literal">/bin/time</code>, it is a good idea to obtain the time from the target server in a format - that is ready to be passed through. This may be done by executing: -<a class="indexterm" name="id372461"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net time system -S FRODO -051700532005.16 -</pre><p> - The time can be set on a target server by executing: -<a class="indexterm" name="id372485"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net time set -S MAGGOT -U Administrator%not24get -Tue May 17 00:55:30 MDT 2005 -</pre><p> - It is possible to obtain the time zone of a server by executing the following command against it: -<a class="indexterm" name="id372509"></a> -</p><pre class="screen"> -<code class="prompt">root# </code> net time zone -S SAURON --0600 -</pre><p> - </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="idmapper.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 12. Group Mapping: MS Windows and UNIX </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 14. Identity Mapping (IDMAP)</td></tr></table></div></body></html> |