Samba-3 can be configured as a domain controller, a back-up domain controller (probably best called a secondary controller), a domain member, or as a stand-alone server. The Windows network security domain context should be sized and scoped before implementation. Particular attention needs to be paid to the location of the primary domain controller (PDC) as well as backup controllers (BDCs). One way in which Samba-3 differs from Microsoft technology is that if one chooses to use an LDAP authentication backend then the same database can be used by several different domains. In a complex organisation there can be a single LDAP database, which itself can be distributed (ie: Have a master server and multiple slave servers) that can simultaneously serve multiple domains.

From a design perspective, the number of users per server, as well as the number of servers, per domain should be scaled taking into consideration server capacity and network bandwidth.

A physical network segment may house several domains. Each may span multiple network segments. Where domains span routed network segments, consider and test the performance implications of the design and layout of a network. A Centrally located domain controller that is designed to serve multiple routed network segments may result in severe performance problems. Check the response time (eg: ping timing) between the remote segment and the PDC. If long (more than 100 ms) locate a backup controller (BDC) on the remote segmanet to serve as the local authentication and access control server.

There are cardinal rules to effective network design. These can not be broken with impunity. The most important rule: Simplicity is king in every well controlled network. Every part of the infrastructure must be managed, the more complex it is, the greater will be the demand of keeping systems secure and functional.

Keep in mind the nature of how data must be share. Physical disk space layout should be considered carefully. Some data must be backed up. The simpler the disk layout the easier it will be to keep track of backed needs. Identify what back media will be meet needs, consider backup to tape , CD-ROM or (DVD-ROM), or other off-line storage medium. Plan and implement for minimum maintenance. Leave nothing to chance in your design, above all, do not leave backups to chance: Backup and test, validate every backup, create a disaster recovery plan and prove that it works.

Users should be grouped according to data access control needs. File and directory access is best controlled via group permissions and the use of the "sticky bit" on group controlled directories may substantially avoid file access complaints from samba share users.

Inexperienced network administrators often attempt elaborate techniques to set access controls on files, directories, shares, as well as in share definitions. Keep your design and implementation simple and document your design extensively. Have others audit your documentation. Do not create a complex mess that your successor will not understand. Remember, job security through complex design and implementation may cause loss of operations and downtime to users as the new administrator learns to untangle your knots. Keep access controls simple and effective and make sure that users will never be interrupted by stupid complexity.

Logon scripts can help to ensure that all users gain share and printer connections they need.

Logon scripts can be created 'on-the-fly' so that all commands executed are specific to the rights and priviliges granted to the user. The preferred controls should be affected through group membership so that group information can be used to custom create a logon script using the root preexec parameters to the NETLOGON share.

Some sites prefer to use a tool such as kixstart to establish a controlled user environment. In any case you may wish to do a google search for logon script process controls. In particular, you may wish to explore the use of the Microsoft knowledgebase article KB189105 that deals with how to add printers without user intervention via the logon script process.

User and Group Profiles may be migrated using the tools described in the section titled Desktop Profile Management.

Profiles may also be managed using the Samba-3 tool profiles. This tool allows the MS Windows NT style security identifiers (SIDs) that are stored inside the profile NTuser.DAT file to be changed to the SID of the Samba-3 domain.

It is possible to migrate all account settings from an MS Windows NT4 domain to Samba-3. Before attempting to migrate user and group accounts it is STRONGLY advised to create in Samba-3 the groups that are present on the MS Windows NT4 domain AND to map these to suitable Unix/Linux groups. By following this simple advice all user and group attributes should migrate painlessly.