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). It should be noted that 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. This means that in a complex organisation there can be a single LDAP database, that itself can be distributed, that can simultaneously serve multiple domains (that can also be widely distributed).

It is recommended that from a design perspective, the number of users per server, as well as the number of servers, per domain should be scaled according to needs and should also consider server capacity and network bandwidth.

A physical network segment may house several domains, each of which may span multiple network segments. Where domains span routed network segments it is most advisable to consider and test the performance implications of the design and layout of a network. A Centrally located domain controller that is being designed to serve mulitple routed network segments may result in severe performance problems if the response time (eg: ping timing) between the remote segment and the PDC is more than 100 ms. In situations where the delay is too long it is highly recommended to locate a backup controller (BDC) to serve as the local authentication and access control server.

There are few cardinal rules to effective network design that can be broken with impunity. The most important rule of effective network management is that 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.

The nature of the data that must be stored needs to be born in mind when deciding how many shares must be created. The physical disk space layout should also be taken into account when designing where share points will be created. Keep in mind that all data needs to be backed up, thus the simpler the disk layout the easier it will be to keep track of what must be backed up to tape or other off-line storage medium. Always 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.

Many network administrators who are new to the game will attempt to use elaborate techniques to set access controls, on files, directories, shares, as well as in share definitions. There is the ever present danger that that administrator's successor will not understand the complex mess that has been inherited. Remember, apparent job security through complex design and implementation may ultimately cause loss of operations and downtime to users as the new administrator learns to untangle your web. Keep access controls simple and effective and make sure that users will never be interrupted by the stupidity of complexity.

Please refer to the section of this document on Advanced Network Adminsitration for information regarding the network logon script options for Samba-3. 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 privilidges granted to the user. The preferred controls should be affected through group membership so that group information can be used to custom create a logong 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 connect these to suitable Unix/Linux groups. Following this simple advice will mean that all user and group attributes should migrate painlessly.