&author.jht; &author.gd; May 9, 2005 The net command is one of the new features of Samba-3 and is an attempt to provide a useful tool into which the majority of remote management operations necessary for common tasks. The net tool is flexible by design and is intended for command line use as well as for scripted control application. Originally introduced with the intent to mimick the Microsoft Windows command that has the same name, the net command has morphed into a very powerful instrument that has become an essential part of the Samba network administrator's toolbox. The Samba Team have introduced tools, such as smbgroupedit, rpcclient from which really useful have been integrated into the net. The smbgroupedit command was absorbed entirely into the net, while only some features of the rpcclient command have been ported to it. Anyone who finds older references to these utilities and to the functionality they provided should look at the net command before searching elsewhere. A Samba-3 administrator can not 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. The tasks that follow the installation of a Samba-3 server, whether Stand-Alone, 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 Stand-Alone server as well as for 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. 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/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 net command. 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 net command. The establishment of interdomain trusts is achieved using the net 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. The over-all picture should be clear now, the net 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 on-line UNIX man pages. Stuff goes here - this is a work in progress.!!!!! More stuff.!!!!!!!!!! Before attempting to add a Windows group account the currently available groups can be listed as shown here: &rootprompt; net rpc group list -Uroot%not24get Password: Domain Admins Domain Users Domain Guests Print Operators Backup Operators Replicator Domain Computers Engineers A Windows group account called SupportEngrs can be added by executing the following command: &rootprompt; net rpc group add "SupportEngrs" -Uroot%not24get The addition will result in immediate availability of the new group account as validated by executing the this command: &rootprompt; net rpc group list -Uroot%not24get Password: Domain Admins Domain Users Domain Guests Print Operators Backup Operators Replicator Domain Computers Engineers SupportEngrs The following demonstrates that the POSIX (UNIX/Linux system account) group has been created by calling the /opt/IDEALX/sbin/smbldap-groupadd -p "%g" interface script: &rootprompt; 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: The following demonstrates that the use of the net command to add a group account results in immediate mapping of the POSIX group that has been created to the Windows group account as whown here: merlin:~ # 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 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. Samba depends on default mappings for the Domain Admins, Domain Users and Domain Guests 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. The operations that are permitted includes: add, modify, delete. An example of each operation is shown here. An existing UNIX group may be mapped to an existing Windows group by this example: &rootprompt; net groupmap modify ntgroup="Domain Users" unixgroup=users An existing UNIX group may be mapped to a new Windows group as shown here: &rootprompt; net groupmap add ntgroup="EliteEngrs" unixgroup=Engineers type=d A Windows group may be deleted, and then a new Windows group can be mapped to the UNIX group by executing these commands: &rootprompt; net groupmap delete ntgroup=Engineers &rootprompt; net groupmap add ntgroup=EngineDrivers unixgroup=Engineers type=d Both the Windows group as well as the UNIX group can be deleted by executing: &rootprompt; net groupmap delete ntgroup= A group account may be deleted by executing the following command: &rootprompt; net rpc group delete SupportEngineers -Uroot%not24get Validation of the deletion is advisable. The same commands may be executed as shown above. This command is not documented in the man pages, it is implemented in the source code, but it does not work. 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 be fixed. 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 SupportEngrs can be renamed to CustomerSupport: &rootprompt; net rpc group rename SupportEngrs \ CustomerSupport -Uroot%not24get Fix me by adding stuff here!!!!!! It is possible in Windows (and now in Samba also) to great a local group that has members (contains) domain users and domain global groups. Creation of the local group demo is achieved by executing: &rootprompt; net rpc group add demo -L -Uroot%not24get 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. Addition and removal of group members can be achieved using the addmem and delmem subcommands of net rpc group command. For example, addition of DOM\Domain Users to the local group demo would be done by executing: &rootprompt; net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get The members of a nested group can be listed by executing the following: &rootprompt; net rpc group members demo -Uroot%not24get DOM\Domain Users DOM\Engineers DOM\jamesf DOM\jht Nest group members can be removed (deleted) as shown here: &rootprompt; net rpc group delmem demo "DOM\jht" -Uroot%not24get Put somethings useful here man!!!!!! &rootprompt; 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 &rootprompt; 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 &rootprompt; net rpc rights grant "MIDEARTH\Domain Admins" \ SeMachineAccountPrivilege SePrintOperatorPrivilege \ SeAddUsersPrivilege SeRemoteShutdownPrivilege \ SeDiskOperatorPrivilege -U root%not24get Successfully granted rights. &rootprompt; net rpc rights grant "MIDEARTH\jht" \ SeMachineAccountPrivilege SePrintOperatorPrivilege \ SeAddUsersPrivilege SeDiskOperatorPrivilege \ -U root%not24get Successfully granted rights. &rootprompt; 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 &rootprompt; Document how to set up trusts here!!!!!!!!!!! &rootprompt; net rpc testjoin Join to 'MIDEARTH' is OK Document how to set up trusts here!!!!!!!!!!! Document how to set up trusts here!!!!!!!!!!! Document how to set up trusts here!!!!!!!!!!! A share can be added using the net rpc share 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 Samba's smbd uses are called: and . A set of example scripts are provided in the Samba source code tarball in the directory ~samba/examples/scripts. The following steps demonstrate the use of the share management capabilities of the net utility. In the first step a share called Bulge is added. The share-point within the file system is the directory /data. The command that can be executed to perform the addition of this share is shown here: &rootprompt; net rpc share add Bulge=/data -S merlin -Uroot%not24get Validation is an important process, and by executing the command net rpc share with no other operators a listing of available shares is shown here: &rootprompt; net rpc share -S merlin -Uroot%not24get profdata archive Bulge <--- This one was added print$ netlogon profiles IPC$ kyocera ADMIN$ Often times 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: &rootprompt; net rpc share delete Bulge -S merlin -Uroot%not24get A simple validation shown here demonstrates that the share has been removed: &rootprompt; net rpc share -S merlin -Uroot%not24get profdata archive print$ netlogon profiles IPC$ ADMIN$ kyocera 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 net rpc vampire 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. The net rpc share command may be used to migrate shares, directories files, printers, and all relevant data from a Windows server to a Samba server. A set of command-line switches permit the creation of almost direct clones of Windows file servers. For example, when migrating a file-server, file ACLs and DOS file attributes from the Windows server can be included in the migration process and will reappear, almost identicaly on the Samba server when the migration has been completed. The migration process can be completed only with the Samba server already being fully operational. This means that 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, 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 machien MESSER can be used to affect 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. The success of server migration requires a firm understanding of the structure of ther source server (or domain) as well as the processes on which the migration is critically dependant. The net rpc share migrate 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. The shares are created on-the-fly as part of the migration process. The smbd application does this by calling on the operating system to execute the script specified by the &smb.conf; parameter add share command. There is a suitable example script for the add share command in the $SAMBA_SOURCES/examples/scripts 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: SeAddUsersPrivilege, SeDiskOperatorPrivilege. For more information regarding rights and privileges please refer to . The syntax of the share migration command is shown here: net rpc share MIGRATE SHARES <sharename> -S <source> [--destination=localhost] [--exclude=share1,share2] [-v] When the parameter <sharename> is ommited, all shares will be migrated. The potentially large list of available shares on the system that is being migrated can be limited using the --exclude switch. For example: &rootprompt; net rpc share migrate shares myshare\ -S win2k -U administrator%secret" This will migrate the share myshare from the server win2k to the Samba Server using the permissions that are tied to the account administrator with the password secret. The account that is used must be the same on both the migration source server, as well as on the target Samba server. The use of the net rpc vampire, 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: &rootprompt; net rpc right list accounts -Uroot%not24get The steps taken so far performs only the migration of shares. Directories and directory contents are not migrated by the steps covered up to this point. 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 happens when file data can be used. Migrate files and directories of file-shares ----------------------------------------------------------- Of more interest than the plain share-migration is getting all files and directories recursively from a remote server to your local system. "net" allows to do exactly that. As several other Windows-based utilities (robocopy, scopy and xcopy to name only a few), "net" can keep the original file-ACLs and DOS-attributes during the file-copy-process. Please note that including ACLs only makes sense when it is planned that the destination system is run under the same security-context as the source system. This is true if the destination system is run either as a domain-member or as domain-controller of a "vampired" domain. Also note that the migrated share (as share-definition) *must* already exist on the destination system. * Syntax: net rpc share MIGRATE FILES <sharename> -S <source> [--destination=localhost] [--exclude=share1,share2] [--acls] [--attrs] [--timestamps] [-v] If <sharename> is ommited, all shares will be migrated. The (possibly huge) list of offered shares on the remote system can be limited with the "--exclude"-switch. File-ACLs are included when run with the "--acls"-switch, DOS-attributes (hidden-, archive-bit, etc.) are included with "--attrs", the original timestamps are kept when "--timestamps" is choosen. Note that the resulting set of ACLs, attributes and timestamps is strongly dependent on the capabilities of your destination system. You may already have noticed the differences between NTFS-ACLs (that all Windows-Server provide) and POSIX-ACLs (that are available on Samba-Servers). As the file-copy is done using native Microsoft Network Protocols, "net" does not alter e.g. ACLs in any ways, it just copies them one-by-one. Anyway, the resulting ACLs on Samba will most probably not match the originating ACLs. The ACL-migration may even fail when files and directories on your source system are owned by a group. As group-ownership of files and directories is not implemented by Samba3, the copy of the whole ACL will fail on that file. This is not critical for the whole migration process and there is a valid workaround: You can use "force unknown acl user = yes" on the shares on the Samba-side. That way, group-ownership is silently converted into a user-ownership to the user that is used by the "net"-migration-command. * Example: net rpc share migrate files -S nt4box --acls --attrs -U administrator%secret - will migrate all files and directories from all file-shares shared on "nt4box" to your to local Samba server using the "Administrator"-account - including all file-ACLs and all DOS-attributes If. files are owned by a group on "nt4box" they will be owned by "administrator" on the Samba server only when all samba-shares use "force unknown acl user = yes". Migrating shares including files and directories ----------------------------------------------------------- This mode is just a combination of the two above. It first migrates share-definitions and then all shared files and directories afterwards. * Syntax: net rpc share MIGRATE ALL <sharename> -S <source> [--exclude=share1, share2] [--acls] [--attrs] [--timestamps] [-v] ' Example: net rpc share migrate all -S w2k3server -U administrator%secret - will generate a full file-server clone of "w2k3server" using the "administrator"-account. Migrating printers ----------------------------------------------------------- net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets] migrates printers from remote to local server Migrating printer-drivers ----------------------------------------------------------- net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets] migrates printer-drivers from remote to local server Migrating printer-forms ----------------------------------------------------------- net rpc printer MIGRATE FORMS [printer] [misc. options] [targets] migrates printer-forms from remote to local server Migrating printer security-settings ----------------------------------------------------------- net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets] migrates printer-ACLs from remote to local server Migrating printer-settings ----------------------------------------------------------- net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets] migrates printer-settings from remote to local server Migrating printers including all the above mentioned sets of information ----------------------------------------------------------- net rpc printer MIGRATE ALL [printer] [misc. options] [targets] migrates drivers, forms, queues, settings and acls from remote to local print-server Known Limitations ----------------------------------------------------------- * net requires that the given credentials exist both on the migration source and the migration target. * printer-settings may not be fully or incorrectly migrated. This might in particular happen when migrating a Windows 2003 print-server to Samba. Document how to set up trusts here!!!!!!!!!!! Document how to set up trusts here!!!!!!!!!!! Document how to set up trusts here!!!!!!!!!!! Document how to set up trusts here!!!!!!!!!!! &rootprompt; net rpc info Domain Name: MIDEARTH Domain SID: S-1-5-21-726309263-4128913605-1168186429 Sequence number: 1115878548 Num users: 5 Num domain groups: 8 Num local groups: 0