Chapter 13. Remote and Local Management: The Net Command

John H. Samba Team Terpstra

Samba Team

<jht@samba.org>

Volker Samba Team Lendecke

Samba Team

<Volker.Lendecke@SerNet.DE>

Guenther Samba Team Deschner

Samba Team

<gd@samba.org>

May 9, 2005

- - - - +Chapter 13. Remote and Local Management: The Net Command

Chapter 13. Remote and Local Management: The Net Command
Prev	Part III. Advanced Configuration	Next

Chapter 13. Remote and Local Management: The Net Command

John H. Samba Team Terpstra

Samba Team

<jht@samba.org>

Volker Samba Team Lendecke

Samba Team

<Volker.Lendecke@SerNet.DE>

Guenther Samba Team Deschner

Samba Team

<gd@samba.org>

May 9, 2005

+ + + + The net 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 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 mimic 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 has introduced tools, such as @@ -22,27 +22,27 @@ provided should look at the net command before sear

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. -

Overview

+ + + - - - 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.

- - + + + + + - - - - - + + 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 @@ -50,41 +50,41 @@ the infliction of self-induced pain, agony, and desperation. Be warned: this is 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 overall 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 online UNIX man pages. -

Administrative Tasks and Methods

- - - - +

Administrative Tasks and Methods

+ + + + The basic operations of the net 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) @@ -94,36 +94,36 @@ the infliction of self-induced pain, agony, and desperation. Be warned: this is automatically fall back via the ads, rpc, and rap modes. Please refer to the man page for a more comprehensive overview of the capabilities of this utility. -

UNIX and Windows Group Management

- - - - - +

UNIX and Windows Group Management

+ + + + + As stated, the focus in most of this chapter is on use of the net rpc family of operations that are supported by Samba. Most of them are supported by the net ads mode when used in connection with Active Directory. The net rap operating mode is also supported for some of these operations. RAP protocols are used by IBM OS/2 and by several earlier SMB servers.

- - - + + + Samba's net 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.

- - - - + + + + Samba-3 recognizes two types of groups: domain groups and local groups. Domain groups can contain (have as members) only domain user accounts. Local groups can contain local users, domain users, and domain groups as members.

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. -

Adding, Renaming, or Deletion of Group Accounts

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 @@ -143,11 +143,11 @@ the infliction of self-induced pain, agony, and desperation. Be warned: this is 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. -

Adding or Creating a New Group

Before attempting to add a Windows group account, the currently available groups can be listed as shown here: - - + +

 root#  net rpc group list -Uroot%not24get
 Password:
@@ -163,7 +163,7 @@ Engineers
 	

 	A Windows group account called “SupportEngrs” can be added by executing the following
 command:
-
+
 
 root#  net rpc group add "SupportEngrs" -Uroot%not24get
 

@@ -183,9 +183,9 @@ Engineers
 SupportEngrs

- - - + + + The following demonstrates that the POSIX (UNIX/Linux system account) group has been created by calling the add group script = /opt/IDEALX/sbin/smbldap-groupadd -p "%g" interface script: @@ -205,7 +205,7 @@ 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 shown here: - +

 root#  net groupmap list
 Domain Admins (S-1-5-21-72630-4128915-11681869-512) -> Domain Admins
@@ -218,19 +218,19 @@ 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

Mapping Windows Groups to UNIX Groups

- - - - +

Mapping Windows Groups to UNIX Groups

+ + + + 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.

+ + + - - - 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 @@ -238,22 +238,22 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs account. The user account must also map to a locally known UID. Note that the net command does not call any RPC-functions here but directly accesses the passdb.

- - - - - - - + + + + + + + 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 include: add, modify, and delete. An example of each operation is shown here.

Note

@@ -290,15 +290,15 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs 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. -

Deleting a Group Account

- +

Deleting a Group Account

+ A group account may be deleted by executing the following command:

 root#  net rpc group delete SupportEngineers -Uroot%not24get

Validation of the deletion is advisable. The same commands may be executed as shown above. -

Rename Group Accounts

Note

Rename Group Accounts

Note

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. @@ -306,7 +306,7 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs 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”: - +

 root#  net rpc group rename SupportEngrs \
     CustomerSupport -Uroot%not24get
@@ -349,7 +349,7 @@ Engineers (S-1-5-21-72630-412605-116429-3001) -> Engineers
 	Given that the user ajt 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:
-
+
 
 root#  net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
 Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP
@@ -359,7 +359,7 @@ Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP
 	

 	To permit the user ajt to be added using the net rpc group utility,
 	this account must first be removed. The removal and confirmation of its effect is shown here:
-
+
 
 root#  net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24get
 root#  getent group Engineers
@@ -383,7 +383,7 @@ MIDEARTH\ajt
 	In this example the members of the Windows Domain Users account are validated using
 	the net rpc group utility. Note the this contents of the UNIX/Linux group was shown
 	four paragraphs earlier. The Windows (domain) group membership is shown here:
-
+
 
 root#  net rpc group members "Domain Users" -Uroot%not24get
 MIDEARTH\jht
@@ -440,11 +440,11 @@ DOM\jht
 
 root#  net rpc group delmem demo "DOM\jht" -Uroot%not24get
 

-	
Managing Nest Groups on Workstations from the Samba Server

+	
Managing Nest Groups on Workstations from the Samba Server

 	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:
-
+
 
 root#  net rpc group addmem "Administrators" "Domain Users" \
     -S WINPC032 -Uadministrator%secret
@@ -452,19 +452,19 @@ DOM\jht
 	

 	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.
-	
Procedure 13.1. Automating User Addition to the Workstation Power Users Group
Example 13.1. Script to Auto-add Domain Users to Workstation Power Users Group
+	
Procedure 13.1. Automating User Addition to the Workstation Power Users Group
Example 13.1. Script to Auto-add Domain Users to Workstation Power Users Group
 #!/bin/bash
 
 /usr/bin/net rpc group addmem "Power Users" "DOMAIN_NAME\$1" \
                    -UAdministrator%secret -S $2
 
 exit 0
-

Example 13.2. A Magic Netlogon Share
 
[netlogon]
comment = Netlogon Share
path = /var/lib/samba/netlogon
root preexec = /etc/samba/scripts/autopoweruser.sh %U %m
read only = Yes
guest ok = Yes


+

Example 13.2. A Magic Netlogon Share
 
[netlogon]
comment = Netlogon Share
path = /var/lib/samba/netlogon
root preexec = /etc/samba/scripts/autopoweruser.sh %U %m
read only = Yes
guest ok = Yes


 		Create the script shown in “Script to Auto-add Domain Users to Workstation Power Users Group” and locate it in
 		the directory /etc/samba/scripts, named as autopoweruser.sh.
-
-
-
+
+
+
 		

 		Set the permissions on this script to permit it to be executed as part of the logon process:
 
@@ -473,7 +473,7 @@ exit 0
 

 		

 		Modify the smb.conf file so the NETLOGON stanza contains the parameters
-		shown in the Netlogon Example smb.conf file as shown.
+		shown in the Netlogon Example smb.conf file.
 		

 		Ensure that every Windows workstation Administrator account has the same password that you
 		have used in the script shown in the Netlogon Example smb.conf
@@ -484,15 +484,15 @@ exit 0
 	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.
-	
UNIX and Windows User Management

+

UNIX and Windows User Management

+ + - - + + - - - - + + 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 @@ -516,8 +516,8 @@ net rpc password <username> [<password>] -Uadmin_username%admin_pass

The following demonstrates the addition of an account to the server FRODO: - - + +

 root#  net rpc user add jacko -S FRODO -Uroot%not24get
 Added user jacko
@@ -528,24 +528,24 @@ Added user jacko
 root#  net rpc user password jacko f4sth0rse \
     -S FRODO -Uroot%not24get

Deletion of User Accounts

Deletion of a user account can be done using the following syntax:

 net [<method>] user DELETE <name> [misc. options] [targets]

The following command will delete the user account jacko: - +

 root#  net rpc user delete jacko -Uroot%not24get
 Deleted user account

Managing User Accounts

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 “Adding User Accounts”.

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: - +

 root#  net rpc user info jacko -S SAURON -Uroot%not24get
 net rpc user info jacko -S SAURON -Uroot%not24get
@@ -558,14 +558,14 @@ Emergency Services

It is also possible to rename user accounts: -oldusername newusername +oldusername newusername Note that this operation does not yet work against Samba Servers. It is, however, possible to rename useraccounts on Windows Servers. -

User Mapping

- - - +

User Mapping

+ + + 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 smb.conf @@ -581,22 +581,22 @@ marygee: geeringm In this example the Windows user account “William Parsons” will be mapped to the UNIX user parsonsw, and the Windows user account “geeringm” will be mapped to the UNIX user marygee. -

Administering User Rights and Privileges

- - - - - +

Administering User Rights and Privileges

+ + + + + 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 root 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.

- + + + - - - + 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 “User Rights and Privileges”. Examples of use of the net for user rights and privilege @@ -632,15 +632,15 @@ No privileges assigned

The net command can be used to obtain the currently supported capabilities for rights and privileges using this method: - - - - - - - - - + + + + + + + + +

 root#  net rpc rights list -U root%not24get
      SeMachineAccountPrivilege  Add machines to domain
@@ -659,7 +659,7 @@ No privileges assigned
 	In this example, all rights are assigned to the Domain Admins group. This is a good
 	idea since members of this group are generally expected to be all-powerful. This assignment makes that
 	the reality:
-
+
 
 root#  net rpc rights grant "MIDEARTH\Domain Admins" \
     SeMachineAccountPrivilege SePrintOperatorPrivilege \
@@ -678,7 +678,7 @@ Successfully granted rights.
 

 	

 	The following step permits validation of the changes just made:
-
+
 
 root#  net rpc rights list accounts -U root%not24get
 MIDEARTH\jht
@@ -712,17 +712,17 @@ SeAddUsersPrivilege
 SeRemoteShutdownPrivilege
 SeDiskOperatorPrivilege
 

-

Managing Trust Relationships

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. -

Machine Trust Accounts

The net command looks in the smb.conf file to obtain its own configuration settings. Thus, the following command 'knows' which domain to join from the smb.conf file.

A Samba server domain trust account can be validated as shown in this example: - +

 root#  net rpc testjoin
 Join to 'MIDEARTH' is OK
@@ -735,7 +735,7 @@ Join to domain 'WORLDOCEAN' is not valid

The equivalent command for joining a Samba server to a Windows ADS domain is shown here: - +

 root#  net ads testjoin
 Using short domain name -- TAKEAWAY
@@ -750,7 +750,7 @@ Join to domain is not valid
 	

 	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:
-
+
 
 root#  net rpc join -S FRODO -Uroot%not24get
 Joined domain MIDEARTH.
@@ -765,7 +765,7 @@ merlin$:1009:9B4489D6B90461FD6A3EC3AB96147E16:\
 	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:
-
+
 
 root#  net rpc join member -S FRODO -Uroot%not24get
 Joined domain MIDEARTH.
@@ -773,7 +773,7 @@ Joined domain MIDEARTH.
 	Note that the command-line parameter member makes this join specific. By default
 	the type is deduced from the smb.conf file configuration. To specifically join as a PDC or BDC, the
 	command-line parameter will be [PDC | BDC]. For example:
-
+
 
 root#  net rpc join bdc -S FRODO -Uroot%not24get
 Joined domain MIDEARTH.
@@ -781,7 +781,7 @@ Joined domain MIDEARTH.
 	It is best to let Samba figure out the domain join type from the settings in the smb.conf file.
 	

 	The command to join a Samba server to a Windows ADS domain is shown here:
-
+
 
 root#  net ads join -UAdministrator%not24get
 Using short domain name -- GDANSK
@@ -792,7 +792,7 @@ Joined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ'
 	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 net command:
-
+
 
 root#  net rpc user delete HERRING\$ -Uroot%not24get
 Deleted user account.
@@ -802,26 +802,26 @@ Deleted user account.
 	

 	A Samba-3 server that is a Windows ADS domain member can execute the following command to detach from the
 	domain:
-
+
 
 root#  net ads leave
 

 	

 	Detailed information regarding an ADS domain can be obtained by a Samba DMS machine by executing the
 	following:
-
+
 
 root#  net ads status
 

 	The volume of information is extensive. Please refer to the book “Samba-3 by Example”,
 	Chapter 7 for more information regarding its use. This book may be obtained either in print or online from
 	the Samba-3 by Example.
-

Interdomain Trusts

Interdomain trust relationships form the primary mechanism by which users from one domain can be granted access rights and privileges in another domain.

To discover what trust relationships are in effect, execute this command: - +

 root#  net rpc trustdom list -Uroot%not24get
 Trusted domains list:
@@ -837,7 +837,7 @@ none
 	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:
-
+
 
 root#  net rpc trustdom add DAMNATION f00db4r -Uroot%not24get
 

@@ -850,7 +850,7 @@ DAMNATION$:1016:9AC1F121DF897688AAD3B435B51404EE: \
 	A trust account will always have an I in the field within the square brackets.
 	

 	If the trusting domain is not capable of being reached, the following command will fail:
-
+
 
 root#  net rpc trustdom list -Uroot%not24get
 Trusted domains list:
@@ -876,7 +876,7 @@ DAMNATION           domain controller is not responding
 	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:
-
+
 
 root#  net rpc trustdom establish DAMNATION
 Password: xxxxxxx	== f00db4r
@@ -897,7 +897,7 @@ DAMNATION           S-1-5-21-1385457007-882775198-1210191635
 	

 	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:
-
+
 
 root#  net rpc trustdom revoke DAMNATION -Uroot%not24get
 

@@ -907,21 +907,21 @@ DAMNATION           S-1-5-21-1385457007-882775198-1210191635
 root#  net rpc trustdom del DAMNATION -Uroot%not24get
 

 
-

Managing Security Identifiers (SIDS)

- - +

Managing Security Identifiers (SIDS)

+ + + + - - 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.

+ + - - 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 @@ -929,7 +929,7 @@ DAMNATION S-1-5-21-1385457007-882775198-1210191635

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 smb.conf file is also stored. Here is a simple action to achieve this: - +

 root#  net getlocalsid > /etc/samba/my-sid

@@ -945,7 +945,7 @@ SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429 If ever it becomes necessary to restore the SID that has been stored in the my-sid file, simply copy the SID (the string of characters that begins with S-1-5-21) to the command line shown here: - +

 root#  net setlocalsid S-1-5-21-1385457007-882775198-1210191635

@@ -956,7 +956,7 @@ SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429 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): - +

 root#  net rpc getsid -S FRODO -Uroot%not24get
 Storing SID S-1-5-21-726309263-4128913605-1168186429 \
@@ -964,25 +964,25 @@ Storing SID S-1-5-21-726309263-4128913605-1168186429 \

Usually it is not necessary to specify the target server (-S FRODO) or the administrator account credentials (-Uroot%not24get). -

Share Management

Share management is central to all file serving operations. Typical share operations include:

Creation/change/deletion of shares
Setting/changing ACLs on shares
Moving shares from one server to another
Change of permissions of share contents

Each of these are dealt with here insofar as they involve the use of the net command. Operations outside of this command are covered elsewhere in this document. -

Creating, Editing, and Removing Shares

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 Sambas smbd uses are called add share command, delete share command and - change share command. A set of example scripts are provided in the Samba source + change share command 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 sharepoint within the file system is the directory /data. The command that can be executed to perform the addition of this share is shown here: - +

 root#  net rpc share add Bulge=/data -S MERLIN -Uroot%not24get

@@ -1003,7 +1003,7 @@ ADMIN$

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: - +

 root#  net rpc share delete Bulge -S MERLIN -Uroot%not24get

@@ -1019,15 +1019,15 @@ IPC$ ADMIN$ kyocera

Creating and Changing Share ACLs

At this time the net tool cannot be used to manage ACLs on Samba shares. In MS Windows language this is called Share Permissions.

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 “File, Directory, and Share Access Controls”. -

Share, Directory, and File Migration

- +

Share, Directory, and File Migration

+ 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 @@ -1064,7 +1064,7 @@ kyocera

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. -

Share Migration

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 @@ -1091,7 +1091,7 @@ net rpc share MIGRATE SHARES <share-name> -S <source> 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 --exclude switch. For example: - +

 root#  net rpc share migrate shares myshare\
          -S win2k -U administrator%secret"
@@ -1104,13 +1104,13 @@ net rpc share MIGRATE SHARES <share-name> -S <source>
 	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:
-
+
 
 root#  net rpc right list accounts -Uroot%not24get
 

 	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.
-

File and Directory Migration

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) @@ -1161,7 +1161,7 @@ net rpc share MIGRATE FILES <share-name> -S <source>

An example for migration of files from a machine called nt4box to the Samba server from which the process will be handled is shown here: - +

 root#  net rpc share migrate files -S nt4box --acls \
     --attrs -U administrator%secret
@@ -1170,17 +1170,17 @@ net rpc share MIGRATE FILES <share-name> -S <source>
 	This command  will migrate all files and directories from all file shares on the Windows server called
 	nt4box to the Samba server from which migration is initiated. Files that are group-owned
 	will be owned by the user account administrator.
-

Share-ACL Migration

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: - +

 root#  net rpc share migrate security -S nt4box -U administrator%secret

This command will only copy the share-ACL of each share on nt4box to your local samba-system. -

Simultaneous Share and File Migration

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:

@@ -1189,12 +1189,12 @@ net rpc share MIGRATE ALL <share-name> -S <source>

An example of simultaneous migration is shown here: - +

 root#  net rpc share migrate all -S w2k3server -U administrator%secret

This will generate a complete server clone of the w2k3server server. -

Printer Migration

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 @@ -1203,7 +1203,7 @@ net rpc share MIGRATE ALL <share-name> -S <source> 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 + a complex network that is integrated with many international offices and a multiplexity 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 @@ -1219,7 +1219,7 @@ net rpc share MIGRATE ALL <share-name> -S <source> 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 smb.conf file parameter - add printer script. This script is essential to the migration process. + . This script is essential to the migration process. A suitable example script may be obtained from the $SAMBA_SOURCES/examples/scripts 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. @@ -1231,29 +1231,29 @@ net rpc share MIGRATE ALL <share-name> -S <source>

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: - +

 net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets]

Printer drivers can be migrated from the Windows print server to the Samba server using this command-line instruction: - +

 net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]

Printer forms can be migrated with the following operation: - +

 net rpc printer MIGRATE FORMS [printer] [misc. options] [targets]

Printer security settings (ACLs) can be migrated from the Windows server to the Samba server using this command: - +

 net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]

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: - +

 net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]

@@ -1263,14 +1263,14 @@ net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]

 net rpc printer MIGRATE ALL [printer] [misc. options] [targets]

Controlling Open Files

The man page documents the net file 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. -

Session and Connection Management

The session management interface of the net session command uses the old RAP method to obtain the list of connections to the Samba server, as shown here: - +

 root#  net rap session -S MERLIN -Uroot%not24get
 Computer             User name            Client Type        Opens Idle time
@@ -1285,11 +1285,11 @@ Computer             User name            Client Type        Opens Idle time
 
 root#  net rap session close marvel -Uroot%not24get
 

-

Printers and ADS

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 net ads print info command following this syntax: - +

 net ads printer info <printer_name> <server_name> -Uadministrator%secret

@@ -1297,26 +1297,26 @@ net ads printer info <printer_name> <server_name> -Uadministrator%se returned.

To publish (make available) a printer to ADS, execute the following command: - +

 net ads printer publish <printer_name> -Uadministrator%secret

This publishes a printer from the local Samba server to ADS.

Removal of a Samba printer from ADS is achieved by executing this command: - +

 net ads printer remove <printer_name> -Uadministrator%secret

A generic search (query) can also be made to locate a printer across the entire ADS domain by executing: - +

 net ads printer search <printer_name> -Uadministrator%secret

Manipulating the Samba Cache

Please refer to the net command man page for information regarding cache management. -

Managing IDMAP UID/SID Mappings

The IDMAP UID to SID, and SID to UID, mappings that are created by winbindd 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. @@ -1327,7 +1327,7 @@ net ads printer search <printer_name> -Uadministrator%secret

Winbind must be shut down to dump the IDMAP file. Before restoring a dump file, shut down winbindd and delete the old winbindd_idmap.tdb file. -

Creating an IDMAP Database Dump File

The IDMAP database can be dumped to a text file as shown here:

 net idmap dump <full_path_and_tdb_filename> > dumpfile.txt
@@ -1337,7 +1337,7 @@ net idmap dump <full_path_and_tdb_filename> > dumpfile.txt
 
 net idmap dump /var/lib/samba/winbindd_idmap.tdb > idmap_dump.txt
 

-

Restoring the IDMAP Database Dump File

The IDMAP dump file can be restored using the following command:

 net idmap restore idmap_dump.txt
@@ -1350,7 +1350,7 @@ net idmap restore /var/lib/samba/winbindd_idmap.tdb < idmap_dump.txt

Other Miscellaneous Operations

The following command is useful for obtaining basic statistics regarding a Samba domain. This command does not work with current Windows XP Professional clients. - +

 root#  net rpc info
 Domain Name: RAPIDFLY
@@ -1363,7 +1363,7 @@ Num local groups: 6
 	

 	Another useful tool is the net time tool set. This tool may be used to query the
 	current time on the target server as shown here:
-
+
 
 root#  net time -S SAURON
 Tue May 17 00:50:43 2005
@@ -1371,19 +1371,19 @@ Tue May 17 00:50:43 2005
 	In the event that it is the intent to pass the time information obtained to the UNIX
 	/bin/time, 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:
-
+
 
 root#  net time system -S FRODO
 051700532005.16
 

 	The time can be set on a target server by executing:
-
+
 
 root#  net time set -S MAGGOT -U Administrator%not24get
 Tue May 17 00:55:30 MDT 2005
 

 	It is possible to obtain the time zone of a server by executing the following command against it:
-
+
 
 root#  net time zone -S SAURON
 -0600
-- 
cgit v1.2.3