1.5 Windows Workgroups and Domains

Up to now, we've covered basic SMB technology, which is all you would need if you had nothing more advanced than MS-DOS clients on your network. We do assume you want to support Windows clients , especially the more recent versions, so next we'll describe the enhancements Microsoft has added to SMB networking ”namely, Windows for Workgroups and Windows domains.

1.5.1 Windows Workgroups

Windows Workgroups are very similar to the SMB groups already described. You need to know just a few additional things.

1.5.1.1 Browsing

Browsing is the process of finding the other computers and shared resources in the Windows network. Note that there is no connection with a World Wide Web browser, apart from the general idea of "discovering what's there." On the other hand, browsing the Windows network is like the Web in that what's out there can change without warning.

Before browsing existed, users had to know the name of the computer they wanted to connect to on the network and then manually enter a UNC such as the following into an application or file manager to access resources:

 \toltec\spirit\ 

Browsing is much more convenient , making it possible to examine the contents of a network by using the point-and-click GUI interface of the Network Neighborhood (or My Network Places ^[5] ) on a Windows client.

^[5] This was originally called Network Neighborhood in Windows 95/98/NT, but Microsoft has changed the name to My Network Places in the more recent Windows Me/2000/XP. We will continue to call it Network Neighborhood, and if you're using a new version of Windows, be aware that My Network Places can act a little differently in some ways.

You will encounter two types of browsing in an SMB network:

• Browsing a list of computers and shared resources

• Browsing the shared resource of a specific computer

Let's look at the first one. On each LAN (or subnet) with a Windows workgroup or domain, one computer has the responsibility of maintaining a list of the computers that are currently accessible through the network. This computer is called the local master browser , and the list that it maintains is called the browse list . Computers on a subnet use the browse list to cut down on the amount of network traffic generated while browsing. Instead of each computer dynamically polling to determine a list of the currently available computers, the computer can simply query the local master browser to obtain a complete, up-to-date list.

To browse the resources on a computer, a user must connect to the specific computer; this information cannot be obtained from the browse list. Browsing the list of resources on a computer can be done by double-clicking the computer's icon when it is presented in the Network Neighborhood. As you saw at the opening of the chapter, the computer will respond with a list of shared resources that can be accessed after the user is successfully authenticated.

Each server on a Windows workgroup is required to announce its presence to the local master browser after it has registered a NetBIOS name, and (theoretically) announce that it is leaving the workgroup when it is shut down. It is the local master browser's responsibility to record what the servers have announced.

The Windows Network Neighborhood can behave oddly: until you select a particular computer to browse, the Network Neighborhood window might contain data that is not up-to-date. That means the Network Neighborhood window can be showing computers that have crashed or can be missing computers that haven't been noticed yet. Put succinctly, once you've selected a server and connected to it, you can be a lot more confident that the shares and printers really exist on the network.

Unlike the roles you've seen earlier, almost any Windows system (including Windows for Workgroups and Windows 95/98/Me or NT/2000/XP) can act as a local master browser. The local master browser can have one or more backup browsers on the local subnet that will take over in the event that the local master browser fails or becomes inaccessible. To ensure fluid operation, the local backup browsers will frequently synchronize their browse list with the local master browser.

Here is how to calculate the minimum number of backup browsers that will be allocated on a workgroup:

• If up to 32 Windows NT/2000/XP workstations are on the network, or up to 16 Windows 95/98/Me computers are on the network, the local master browser allocates one backup browser in addition to the local master browser.

• If the number of Windows NT/2000/XP workstations falls between 33 and 64, or the number of Windows 95/98/Me workstations falls between 17 and 32, the local master browser allocates two backup browsers.

• For each group of 32 NT/2000/XP workstations or 16 Windows 95/98/Me computers beyond this, the local master browser allocates another backup browser.

There is currently no upper limit on the number of backup browsers that can be allocated by the local master browser.

1.5.1.2 Browsing elections

Browsing is a critical aspect of any Windows workgroup. However, not everything runs perfectly on any network. For example, let's say that a computer running Windows on the desk of a small company's CEO is the local master browser ”that is, until he switches it off while plugging in his massage chair . At this point the Windows NT Workstation in the spare parts department might agree to take over the job. However, that computer is currently running a large, poorly written program that has brought its processor to its knees. The moral: browsing has to be very tolerant of servers coming and going. Because nearly every Windows system can serve as a browser, there has to be a way of deciding at any time who will take on the job. This decision-making process is called an election .

An election algorithm is built into nearly all Windows operating systems such that they can each agree who is going to be a local master browser and who will be local backup browsers. An election can be forced at any time. For example, let's assume that the CEO has finished his massage and reboots his server. As the server comes online, it will announce its presence, and an election will take place to see if the PC in the spare parts department should still be the master browser.

When an election is performed, each computer broadcasts information about itself via datagrams. This information includes the following:

• The version of the election protocol used

• The operating system on the computer

• The amount of time the client has been on the network

• The hostname of the client

These values determine which operating system has seniority and will fulfill the role of the local master browser. (Chapter 7 describes the election process in more detail.) The architecture developed to achieve this is not elegant and has built-in security problems. While a browsing domain can be integrated with domain security, the election algorithm does not take into consideration which computers become browsers. Thus it is possible for any computer running a browser service to register itself as participating in the browsing election and (after winning) being able to change the browse list. Nevertheless, browsing is a key feature of Windows networking, and backward-compatibility requirements will ensure that it is in use for years to come.

1.5.1.3 Windows 95/98/Me authentication

Three types of passwords arise when Windows 95/98/Me is operating in a Windows workgroup:

• A Windows password

• A Windows Networking password

• A password for each shared resource that has been assigned password protection

The Windows password functions in a manner that might be a source of confusion for Unix system administrators. It is not there to prevent unauthorized users from using the computer. (If you don't believe that, try clicking the Cancel button on the password dialog box and see what happens!) Instead, the Windows password is used to gain access to a file that contains the Windows Networking and network resource passwords. There is one such file per registered user of the system, and they can be found in the C:\Windows directory with a name composed of the user's account name, followed by a .pwl extension. For example, if the user's account name is " sarah ," the file will be C:\Windows\sarah.pwl . This file is encrypted using the Windows password as the encryption key.

As a security measure, you might want to check for junk .pwl files on Windows 95/98/Me clients, which might have been created by mistakes users made while attempting to log on. A .pwl file is easily cracked and can contain valid passwords for Samba accounts and network shares.

The first time the network is accessed, Windows attempts to use the Windows password as the Windows Networking password. If this is successful, the user will not be prompted for two separate passwords, and subsequent logins to the Windows system will automatically result in logging on to the Windows network as well, making things much simpler for the user.

Shared network resources in the workgroup can also have passwords assigned to them to limit their accessibility. The first time a user attempts to access the resource, she is asked for its password, and a checkbox in the password dialog box gives the user the option to add the password to her password list. This is the default; if it is accepted, Windows will store the password in the user's .pwl file, and all further authentication to the resource will be handled automatically by Windows.

Samba's approach to workgroup authentication is a little different, which is a result of blending the Windows workgroup model with that of the Unix host upon which Samba runs. This will be discussed further in Chapter 9.

1.5.2 Windows NT Domains

The peer-to-peer networking model of workgroups functions fairly well as long as the number of computers on the network is small and there is a close-knit community of users. However, in larger networks the simplicity of workgroups becomes a limiting factor. Workgroups offer only the most basic level of security, and because each resource can have its own password, it is inconvenient (to say the least) for users to remember the password for each resource in a large network. Even if that were not a problem, many people find it frustrating to have to interrupt their creative workflow to enter a shared password into a dialog box every time another network resource is accessed.

To support the needs of larger networks, such as those found in departmental computing environments, Microsoft introduced domains with Windows NT 3.51. A Windows NT domain is essentially a workgroup of SMB computers that has one addition: a server acting as a domain controller (see Figure 1-12).

Figure 1-12. A simple Windows domain

1.5.2.1 Domain controllers

A domain controller in a Windows NT domain functions much like a Network Information Service (NIS) server in a Unix network, maintaining a domain-wide database of user and group information, as well as performing related services. The responsibilities of a domain controller are mainly centered around security, including authentication , the process of granting or denying a user access to the resources of the domain. This is typically done through the use of a username and password. The service that maintains the database on the domain controllers is called the Security Account Manager (SAM).

The Windows NT security model revolves around security identifiers (SIDs) and access control lists (ACLs). Security identifiers are used to represent objects in the domain, which include (but are not limited to) users, groups, computers, and processes. SIDs are commonly written in ASCII form as hyphen-separated fields, like this:

 S-1-5-21-1638239387-7675610646-9254035128-545 

The part of the SID starting with the "S" and leading up to the rightmost hyphen identifies a domain. The number after the rightmost hyphen is called a relative identifier (RID) and is a unique number within the domain that identifies the user, group, computer, or other object. The RID is the analog of a user ID (UID) or group ID (GID) on a Unix system or within an NIS domain.

ACLs supply the same function as "rwx" file permissions that are common in Unix systems. However, ACLs are more versatile. Unix file permissions only set permissions for the owner and group to which the file belongs, and "other," meaning everyone else. Windows NT/2000/XP ACLs allow permissions to be set individually for any number of arbitrary users and/or groups. ACLs are made up of one or more access control entries (ACEs), each of which contains an SID and the access rights associated with it.

ACL support has been added as a standard feature for some Unix variants and is available as an add-on for others. Samba supports mappings between Windows and Unix ACLs, and this will be covered in Chapter 8.

1.5.2.2 Primary and backup domain controllers

You've already read about master and backup browsers. Domain controllers are similar in that a domain has a primary domain controller (PDC) and can have one or more backup domain controllers (BDCs) as well. If the PDC fails or becomes inaccessible, its duties are automatically taken over by one of the BDCs. BDCs frequently synchronize their SAM data with the PDC so if the need arises, any one of them can immediately begin performing domain-controller services without impacting the clients. However, note that BDCs have read-only copies of the SAM database; they can update their data only by synchronizing with a PDC. A server in a Windows domain can use the SAM of any PDC or BDC to authenticate a user who attempts to access its resources and log on to the domain.

All recent versions of Windows can log on to a domain as clients to access the resources of the domain servers. The systems that are considered members of the domain are a more exclusive class, composed of the PDC and BDCs, as well as domain member servers, which are systems that have joined a domain as members , and are known to the domain controllers by having a computer account in the SAM database.

1.5.2.3 Authentication

When a user logs on to a Windows domain by typing in a username and password, a secure challenge and response protocol is invoked between the client computer and a domain controller to verify that the username and password are valid. Then the domain controller sends a SID back to the client, which uses it to create a Security Access Token (SAT) that is valid only for that system, to be used for further authentication. This access token has information about the user coded into it, including the username, the group, and the rights the user has within the domain. At this point, the user is logged on to the domain.

Subsequently, when the client attempts to access a shared resource within the domain, the client system enters into a secure challenge and response exchange with the server of the resource. The server then enters into another secure challenge and response conversation with a domain controller to check that the client is valid. (What actually happens is that the server uses information it gets from the client to pretend to be the client and authenticate itself with the domain controller. If the domain controller validates the credentials, it sends an SID back to the server, which uses the SID to create its own SAT for the client to enable access to its local resources on the client's behalf .) At this point, the client is authenticated for resources on the server and is allowed to access them. The server then uses the SID in the access token to determine what permissions the client has to use and modify the requested resource by comparing them to entries in the ACL of the resource.

Although this method of authentication might seem overly complicated, it allows clients to authenticate without having plain-text passwords travel through the network, and it is much more difficult to crack than the relatively weak workgroup security we described earlier.

1.5.2.4 Name service with WINS and DNS

The Windows Internet Name Service (WINS) is Microsoft's implementation of a NetBIOS name server (NBNS). As such, WINS inherits much of NetBIOS's characteristics. First, WINS is flat; you can have only simple machine names such as inca , mixtec , or navaho , and workgroups such as PERU, MEXICO, or USA. In addition, WINS is dynamic: when a client first comes online, it is required to report its hostname, its address, and its workgroup to the local WINS server. This WINS server will retain the information so long as the client periodically refreshes its WINS registration, which indicates that it's still connected to the network. Note that WINS servers are not workgroup- or domain-specific; they can contain information for multiple domains and/or workgroups, which might exist on more than one subnet.

Multiple WINS servers can be set to synchronize with each other. This allows entries for computers that come online and go offline in the network to propagate from one WINS server to another. While in theory this seems efficient, it can quickly become cumbersome if several WINS servers are covering a network. Because WINS services can cross multiple subnets (you'll either hardcode the address of a WINS server in each of your clients or obtain it via DHCP), it is often more efficient to have each Windows client, regardless of the number of Windows domains, point themselves to the same WINS server. That way, only one authoritative WINS server will have the correct information, instead of several WINS servers continually struggling to synchronize themselves with the most recent changes.

The currently active WINS server is known as the primary WINS server . You can also install a secondary WINS server, which will take over if the primary WINS server fails or becomes inaccessible. Both the primary and any other WINS servers will synchronize their address databases on a periodic basis.

In the Windows family of operating systems, only a server edition of Windows NT/2000 can act as a WINS server. Samba 2.2 can function as a primary WINS server, but cannot synchronize its database with other WINS servers. It therefore cannot act as a secondary WINS server or as a primary WINS server for a Windows secondary WINS server.

WINS handles name service by default, although Microsoft added DNS starting with Windows NT 4 Server. It is compatible with DNS that is standard on virtually every Unix system, and a Unix server (such as the Samba host) can also be used for DNS.

1.5.2.5 Trust relationships

One additional aspect of Windows NT domains not yet supported in Samba 2.2 is that it is possible to set up a trust relationship between domains, allowing clients within one domain to access the resources within another without the user having to go through additional authentication. The protocol that is followed is called pass-through authentication , in which the user's credentials are passed from the client system in the first domain to the server in the second domain, which consults a domain controller in the first (trusted) domain to check that the user is valid before granting access to the resource.

Note that in many aspects, the behaviors of a Windows workgroup and a Windows NT domain overlap. For example, the master and backup browsers in a domain are always the PDC and BDC, respectively. Let's update our Windows domain diagram to include both a local master and local backup browser. The result is shown in Figure 1-13.

Figure 1-13. A Windows domain with a local master and local backup browser

The similarity between workgroups and NT domains is not accidental because the concept of Windows domains did not evolve until Windows NT 3.5 was introduced, and Windows domains were forced to remain backward-compatible with the workgroups present in Windows for Workgroups.

Samba can function as a primary domain controller for Windows 95/98/Me and Windows NT/2000/XP clients with the limitation that it can act as a PDC only, and not as a BDC.

Samba can also function as a domain member server , meaning that it has a computer account in the PDC's account database and is therefore recognized as being part of the domain. A domain member server does not authenticate users logging on to the domain, but still handles security functions (such as file permissions) for domain users accessing its resources.

1.5.3 Active Directory Domains

Starting with Windows 2000, Microsoft has introduced Active Directory, the next step beyond Windows NT domains. We won't go into much detail concerning Active Directory because it is a huge topic. Samba 2.2 doesn't support Active Directory at all, and support in Samba 3.0 is limited to acting as a client. For now, be aware that with Active Directory, the authentication model is centered around Lightweight Directory Access Protocol (LDAP), and name service is provided by DNS instead of WINS. Domains in Active Directory can be organized in a hierarchical tree structure, in which each domain controller operates as a peer, with no distinction between primary and backup controllers as in Windows NT domains.

Windows 2000/XP systems can be set up as simple workgroup or Windows NT domain clients (which will function with Samba). The server editions of Windows 2000 can be set up to run Active Directory and support Windows NT domains for backward compatibility ( mixed mode ). In this case, Samba 2.2 works with Windows 2000 servers in the same way it works with Windows NT 4.0 servers. When set up to operate in native mode, Windows 2000 servers support only Active Directory. Even so, Samba 2.2 can operate as a server in a domain hosted by a native-mode Windows 2000 server, using the Windows 2000 server's PDC emulation mode . However, it is not possible for Samba 2.2 or 3.0 to operate as a domain controller in a Windows 2000 Active Directory domain.

If you want to know more about Active Directory, we encourage you to obtain a copy of the O'Reilly book, Windows 2000 Active Directory .

1.5.4 Can a Windows Workgroup Span Multiple Subnets?

Yes, but most people who have done it have had their share of headaches . Spanning multiple subnets was not part of the initial design of Windows NT 3.5 or Windows for Workgroups. As a result, a Windows domain that spans two or more subnets is, in reality, the "gluing" together of two or more workgroups that share an identical name. The good news is that you can still use a PDC to control authentication across each subnet. The bad news is that things are not as simple with browsing.

As mentioned previously, each subnet must have its own local master browser. When a Windows domain spans multiple subnets, a system administrator will have to assign one of the computers as the domain master browser . The domain master browser will keep a browse list for the entire Windows domain. This browse list is created by periodically synchronizing the browse lists of each local master browser with the browse list of the domain master browser. After the synchronization, the local master browser and the domain master browser should contain identical entries. See Figure 1-14 for an illustration.

Figure 1-14. A workgroup that spans more than one subnet

Sound good? Well, it's not quite nirvana for the following reasons:

• If it exists, a PDC always plays the role of the domain master browser. By Microsoft design, the two always share the NetBIOS resource type <1B> and ( unfortunately ) cannot be separated.

• Windows 95/98/Me computers cannot become or even contact a domain master browser. This means that it is necessary to have at least one Windows NT/2000/XP system (or Samba server) on each subnet of a multisubnet workgroup.

Each subnet's local master browser continues to maintain the browse list for its subnet, for which it becomes authoritative. So if a computer wants to see a list of servers within its own subnet, the local master browser of that subnet will be queried. If a computer wants to see a list of servers outside the subnet, it can still go only as far as the local master browser. This works because at appointed intervals, the authoritative browse list of a subnet's local master browser is synchronized with the domain master browser, which is synchronized with the local master browser of the other subnets in the domain. This is called browse list propagation .

Samba can act as a domain master browser in a Windows NT domain, or it can act as a local master browser for a subnet, synchronizing its browse list with the domain master browser.