The new company has three divisions. Staff for each division are spread across the company. Some staff are office-bound and some are mobile users. Mobile users travel globally. Some spend considerable periods working in other offices. Everyone wants to be able to work without constraint of productivity.

The challenge is not insignificant. In some parts of the world, even dial-up connectivity is poor, while in other regions political encumbrances severely curtail user needs. Parts of the global Internet infrastructure remain shielded off for reasons outside the scope of this discussion.

Decisions must be made regarding where data is to be stored, how it will be replicated (if at all), and what the network bandwidth implications are. For example, one decision that can be made is to give each office its own master file storage area that can be synchronized to a central repository in New York. This would permit global data to be backed up from a single location. The synchronization tool could be rsync, run via a cron job. Mobile users may use off-line file storage under Windows XP Professional. This way, they can synchronize all files that have changed since each logon to the network.

No matter which way you look at this, the bandwidth requirements for acceptable performance are substantial even if only 10 percent of staff are global data users. A company with 3,500 employees, 280 of whom are mobile users who use a similarly distributed network, found they needed at least 2 Mb/sec connectivity between the UK and US offices. Even over 2 Mb/sec bandwidth, this company abandoned any attempt to run roaming profile usage for mobile users. At that time, the average roaming profile took 480 KB, while today the minimum Windows XP Professional roaming profile involves a transfer of over 750 KB from the profile server to and from the client.

Obviously then, user needs and wide-area practicalities dictate the economic and technical aspects of your network design as well as for standard operating procedures.

Network logons that include roaming profile handling requires from 140 KB to 2 MB. The inclusion of support for a minimal set of common desktop applications can push the size of a complete profile to over 15 MB. This has substantial implications for location of user profiles. Additionally, it is a significant factor in determining the nature and style of mandatory profiles that may be enforced as part of a total service-level assurance program that might be implemented.

One way to reduce the network bandwidth impact of user logon traffic is through folder redirection. In “Making Happy Users”, you implemented this in the new Windows XP Professional standard desktop configuration. When desktop folders such as My Documents are redirected to a network drive, they should also be excluded from synchronization to and from the server on logon or logout. Redirected folders are analogous to network drive connections.

Of course, network applications should only be run off local application servers. As a general rule, even with 2 Mb/sec network bandwidth, it would not make sense at all for someone who is working out of the London office to run applications off a server that is located in New York.

When network bandwidth becomes a precious commodity (that is most of the time), there is a significant demand to understand network processes and to mold the limits of acceptability around the constraints of affordability.

When a Windows NT4/200x/XP Professional client user logs onto the network, several important things must happen.

Given that this book is about Samba and that it implements the Windows NT4-style domain semantics, it makes little sense to compare Samba with Microsoft Active Directory insofar as the logon protocols and principles of operation are concerned. The following information pertains exclusively to the interaction between a Windows XP Professional workstation and a Samba-3.0.20 server. In the discussion that follows, use is made of DHCP and WINS.

As soon as the Windows workstation starts up, it obtains an IP address. This is immediately followed by registration of its name both by broadcast and Unicast registration that is directed at the WINS server.

Given that the client is already a domain member, it then sends a directed (Unicast) request to the WINS server seeking the list of IP addresses for domain controllers (NetBIOS name type 0x1C). The WINS server replies with the information requested.

The client sends two netlogon mailslot broadcast requests to the local network and to each of the IP addresses returned by the WINS server. Whichever answers this request first appears to be the machine that the Windows XP client attempts to use to process the network logon. The mailslot messages use UDP broadcast to the local network and UDP Unicast directed at each machine that was listed in the WINS server response to a request for the list of domain controllers.

The logon process begins with negotiation of the SMB/CIFS protocols that are to be used; this is followed by an exchange of information that ultimately includes the client sending the credentials with which the user is attempting to logon. The logon server must now approve the further establishment of the connection, but that is a good point to halt for now. The priority here must center around identification of network infrastructure needs. A secondary fact we need to know is, what happens when local domain controllers fail or break?

Under most circumstances, the nearest domain controller responds to the netlogon mailslot broadcast. The exception to this norm occurs when the nearest domain controller is too busy or is out of service. Herein lies an important fact. This means it is important that every network segment should have at least two domain controllers. Since there can be only one PDC, all additional domain controllers are by definition BDCs.

The provision of sufficient servers that are BDCs is an important design factor. The second important design factor involves how each of the BDCs obtains user authentication data. That is the subject of the next section, which involves key decisions regarding Identity Management facilities.

Network managers recognize that in large organizations users generally need to be given resource access based on needs, while being excluded from other resources for reasons of privacy. It is therefore essential that all users identify themselves at the point of network access. The network logon is the principal means by which user credentials are validated and filtered and appropriate rights and privileges are allocated.

Unfortunately, network resources tend to have their own Identity Management facilities, the quality and manageability of which varies from quite poor to exceptionally good. Corporations that use a mixture of systems soon discover that until recently, few systems were designed to interoperate. For example, UNIX systems each have an independent user database. Sun Microsystems developed a facility that was originally called Yellow Pages, and was renamed when a telephone company objected to the use of its trademark. What was once called Yellow Pages is today known as Network Information System (NIS).

NIS gained a strong following throughout the UNIX/VMS space in a short period of time and retained that appeal and use for over a decade. Security concerns and inherent limitations have caused it to enter its twilight. NIS did not gain widespread appeal outside of the UNIX world and was not universally adopted. Sun updated this to a more secure implementation called NIS+, but even it has fallen victim to changing demands as the demand for directory services that can be coupled with other information systems is catching on.

Nevertheless, both NIS and NIS+ continue to hold ground in business areas where UNIX still has major sway. Examples of organizations that remain firmly attached to the use of NIS and NIS+ include large government departments, education institutions, and large corporations that have a scientific or engineering focus.

Today's networking world needs a scalable, distributed Identity Management infrastructure, commonly called a directory. The most popular technologies today are Microsoft Active Directory service and a number of LDAP implementations.

The problem of managing multiple directories has become a focal point over the past decade, creating a large market for metadirectory products and services that allow organizations that have multiple directories and multiple management and control centers to provision information from one directory into another. The attendant benefit to end users is the promise of having to remember and deal with fewer login identities and passwords.

The challenge of every large network is to find the optimum balance of internal systems and facilities for Identity Management resources. How well the solution is chosen and implemented has potentially significant impact on network bandwidth and systems response needs.

In “Making Happy Users”, you implemented a single LDAP server for the entire network. This may work for smaller networks, but almost certainly fails to meet the needs of large and complex networks. The following section documents how you may implement a single master LDAP server with multiple slave servers.

What is the best method for implementing master/slave LDAP servers within the context of a distributed 2,000-user network is a question that remains to be answered.

One possibility that has great appeal is to create a single, large distributed domain. The practical implications of this design (see “Network Topology 2000 User Complex Design A”) demands the placement of sufficient BDCs in each location. Additionally, network administrators must make sure that profiles are not transferred over the wide-area links, except as a totally unavoidable measure. Network design must balance the risk of loss of user productivity against the cost of network management and maintenance.

The network design in “Network Topology 2000 User Complex Design B” takes the approach that management of networks that are too remote to be managed effectively from New York ought to be given a certain degree of autonomy. With this rationale, the Los Angeles and London networks, though fully integrated with those on the East Coast, each have their own domain name space and can be independently managed and controlled. One of the key drawbacks of this design is that it flies in the face of the ability for network users to roam globally without some compromise in how they may access global resources.

Desk-bound users need not be negatively affected by this design, since the use of interdomain trusts can be used to satisfy the need for global data sharing.

When Samba-3 is configured to use an LDAP backend, it stores the domain account information in a directory entry. This account entry contains the domain SID. An unintended but exploitable side effect is that this makes it possible to operate with more than one PDC on a distributed network.

How might this peculiar feature be exploited? The answer is simple. It is imperative that each network segment have its own WINS server. Major servers on remote network segments can be given a static WINS entry in the wins.dat file on each WINS server. This allows all essential data to be visible from all locations. Each location would, however, function as if it is an independent domain, while all sharing the same domain SID. Since all domain account information can be stored in a single LDAP backend, users have unfettered ability to roam.

This concept has not been exhaustively validated, though we can see no reason why this should not work. The important facets are the following: The name of the domain must be identical in all locations. Each network segment must have its own WINS server. The name of the PDC must be the same in all locations; this necessitates the use of NetBIOS name aliases for each PDC so that they can be accessed globally using the alias and not the PDC's primary name. A single master LDAP server can be based in New York, with multiple LDAP slave servers located on every network segment. Finally, the BDCs should each use failover LDAP servers that are in fact slave LDAP servers on the local segments.

With a single master LDAP server, all network updates are effected on a single server. In the event that this should become excessively fragile or network bandwidth limiting, one could implement a delegated LDAP domain. This is also known as a partitioned (or multiple partition) LDAP database and as a distributed LDAP directory.

As the LDAP directory grows, it becomes increasingly important that its structure is implemented in a manner that mirrors organizational needs, so as to limit network update and referential traffic. It should be noted that all directory administrators must of necessity follow the same standard procedures for managing the directory, because retroactive correction of inconsistent directory information can be exceedingly difficult.