Chapter 4. Domain Control

There are many who approach MS Windows networking with incredible misconceptions. That's okay, because it gives the rest of us plenty of opportunity to be of assistance. Those who really want help would be well advised to become familiar with information that is already available.

The reader is advised not to tackle this section without having first understood and mastered some basics. MS Windows networking is not particularly forgiving of misconfiguration. Users of MS Windows networking are likely to complain of persistent niggles that may be caused by a broken network configuration. To a great many people, however, MS Windows networking starts with a Domain Controller that in some magical way is expected to solve all network operational ills.

The diagram in Figure 4.1 shows a typical MS Windows Domain Security network environment. Workstations A, B and C are representative of many physical MS Windows network clients .

Figure 4.1. An Example Domain.

graphics/04fig01.gif

From the Samba mailing list one can readily identify many common networking issues. If you are not clear on the following subjects, then it will do much good to read the sections of this HOWTO that deal with it. These are the most common causes of MS Windows networking problems:

Basic TCP/IP configuration.
NetBIOS name resolution.
Authentication configuration.
User and group configuration.
Basic file and directory permission control in UNIX/Linux.
Understanding how MS Windows clients interoperate in a network environment.

Do not be put off; on the surface of it MS Windows networking seems so simple that anyone can do it. In fact, it is not a good idea to set up an MS Windows network with inadequate training and preparation. But let's get our first indelible principle out of the way: It is perfectly okay to make mistakes! In the right place and at the right time, mistakes are the essence of learning. It is very much not okay to make mistakes that cause loss of productivity and impose an avoidable financial burden on an organization.

Where is the right place to make mistakes? Only out of harm's way. If you are going to make mistakes, then please do it on a test network, away from users and in such a way as to not inflict pain on others. Do your learning on a test network.

4.1 Features and Benefits

What is the key benefit of Microsoft Domain Security ?

In a word, Single Sign On , or SSO for short. To many, this is the Holy Grail of MS Windows NT and beyond networking. SSO allows users in a well-designed network to log onto any workstation that is a member of the domain that their user account is in (or in a domain that has an appropriate trust relationship with the domain they are visiting) and they will be able to log onto the network and access resources (shares, files and printers) as if they are sitting at their home (personal) workstation. This is a feature of the Domain Security protocols.

The benefits of Domain Security are available to those sites that deploy a Samba PDC. A Domain provides a unique network security identifier (SID). Domain user and group security identifiers are comprised of the network SID plus a relative identifier (RID) that is unique to the account. User and Group SIDs (the network SID plus the RID) can be used to create Access Control Lists (ACLs) attached to network resources to provide organizational access control. UNIX systems recognize only local security identifiers.

N OTE

Network clients of an MS Windows Domain Security Environment must be Domain Members to be able to gain access to the advanced features provided. Domain Membership involves more than just setting the workgroup name to the Domain name . It requires the creation of a Domain trust account for the workstation (called a machine account). Refer to Chapter 6, Domain Membership for more information.

The following functionalities are new to the Samba-3 release:

Windows NT4 domain trusts.
Adding users via the User Manager for Domains. This can be done on any MS Windows client using the Nexus.exe toolkit for Windows 9x/Me, or using the SRVTOOLS.EXE package for MS Windows NT4/200x/XP platforms. These packages are available from Microsoft's Web site.
Introduces replaceable and multiple user account (authentication) backends . In the case where the backend is placed in an LDAP database, Samba-3 confers the benefits of a backend that can be distributed, replicated and is highly scalable.
Implements full Unicode support. This simplifies cross locale internationalization support. It also opens up the use of protocols that Samba-2.2.x had but could not use due to the need to fully support Unicode.

The following functionalities are not provided by Samba-3:

SAM replication with Windows NT4 Domain Controllers (i.e., a Samba PDC and a Windows NT BDC or vice versa). This means Samba cannot operate as a BDC when the PDC is Microsoft-based or replicate account data to Windows BDCs.
Acting as a Windows 2000 Domain Controller (i.e., Kerberos and Active Directory). In point of fact, Samba-3 does have some Active Directory Domain Control ability that is at this time purely experimental that is certain to change as it becomes a fully supported feature some time during the Samba-3 (or later) life cycle. However, Active Directory is more then just SMB ” it's also LDAP, Kerberos, DHCP, and other protocols (with proprietary extensions, of course).
The Windows 200x/XP MMC (Computer Management) Console can not be used to manage a Samba-3 server. For this you can use only the MS Windows NT4 Domain Server manager and the MS Windows NT4 Domain User Manager. Both are part of the SVRTOOLS.EXE package mentioned later.

Windows 9x/Me/XP Home clients are not true members of a domain for reasons outlined in this chapter. The protocol for support of Windows 9x/Me style network (domain) logons is completely different from NT4/Windows 200x type domain logons and has been officially supported for some time. These clients use the old LanMan Network Logon facilities that are supported in Samba since approximately the Samba-1.9.15 series.

Samba-3 implements group mapping between Windows NT groups and UNIX groups (this is really quite complicated to explain in a short space). This is discussed more fully in Chapter 11, Group Mapping ” MS Windows and UNIX .

Samba-3, like an MS Windows NT4 PDC or a Windows 200x Active Directory, needs to store user and Machine Trust Account information in a suitable backend datastore. Refer to Section 6.2. With Samba-3 there can be multiple backends for this. A complete discussion of account database backends can be found in Chapter 10, Account Information Databases .

Buy on amazon.com >>

Terpstra J.H., Vernooij J.R.

<< Previous page

Table of contents

Next page >>