Section 1.6. Authentication: Peer-to-Peer Versus Domains

1.6. Authentication: Peer-to-Peer Versus Domains

Peer-to-peer networks (not to be confused with P2P file sharing) were originally designed to allow users to share resources from their desktop computer with other users across a network. Network browsing was also originally designed to support this type of ad hoc networking in which no central management of disks or printers was needed. Users could turn their PCs on or off at will without fear of disrupting other users or network services (except those people who were accessing files or printers on the now-offline host).

When a request to access a file share or printer was received, the local computer was responsible for handling the authentication request as part of the connection process. Thus, any user account information or passwords had to be stored on the CIFS "server." If a user required access to shares on six remote machines, the user had to either remember six passwords or keep her account information synchronized across all six servers. Both solutions faced a scalability issue.

The peer-to-peer networking model of local authentication 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. 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 browsing group of CIFS-enabled computers with one addition: a server acting as a domain controller (see Figure 1-11).

Figure 1-11. A simple Windows domain

A domain controller in a Windows domain performs a role similar to a Network Information Service (NIS) server or LDAP directory service 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 related to security, including verifying user credentials (authentication) and granting or denying a user access to the resources of the domain (authorization). These tasks are 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 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, and computers. SIDs are commonly written in ASCII form as hyphen-separated fields, like this:

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

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.

Because domains centralize the management of account information, users are now able to use just one login name/password combination. However, the downside of this setup is that if the domain controller is unavailable, servers can no longer authenticate user requests. Therefore, Microsoft developed the concept of multiple domain controllers that maintain duplicate copies of the domain's SAM. For example, Windows NT domains utilize a primary domain controller (PDC) and one or more backup domain controllers (BDCs). 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. If the PDC fails or becomes inaccessible, its duties can be taken over by one of the BDCs. BDCs frequently synchronize their SAM data with the PDC so that if the need arises, any one of them can immediately begin performing domain-controller services without affecting the clients.

However, note that Windows NT BDCs have read-only copies of the SAM database; they can update their data only by synchronizing with a PDC. In AD domains, all domain controllers (DCs) are considered equal. In order to support legacy clients such as Windows NT, one AD DC is designated as the PDC, but all DCs maintain a modifiable copy of the domain's authentication database. Changes on one domain controller are propagated to other DCs via a multimaster replication protocol.

Domain trust relationships allow clients within one domain to access the resources within another without having to possess a separate account in the second domain. 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 its own domain. This DC then contacts a DC in the first (trusted) domain to check whether the user is valid before instructing the server to grant access to the resource.

Samba 3.0 can perform the role of a Windows NT domain controller. It is possible to have a Samba PDC and Samba BDCs in the same domain. Samba can even particpate in trust relationships with other domains. However, at the current time of writing, you cannot mix Windows DCs and Samba DCs in the same domain. This rule may change in a future release. Make sure to check the Samba web site for the latest release and updates.

Samba can also function as a domain member server in either a Windows or Samba controlled domain, meaning that it has a computer account in the DC'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.