Windows IT Pro is the leading independent community for IT professionals deploying Microsoft Windows server and client applications and technologies.
  
  
  Advanced Search 


October 2001

A Model Network


RSS
Subscribe to Windows IT Pro | See More Domains Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!
SideBar    Not as Safe as You Think

The right NT domain model can make a difference

EDITOR'S NOTE: This series of articles, "NT Security Fundamentals," is adapted from Audit and Security of Windows NT Server, a course Randy Franklin Smith wrote for MIS Training Institute.

In "PDCs, BDCs, and Trust Relationships," September 2001, I discuss Windows NT domain controller (DC) roles and the logistics of the trust relationships that you can establish between NT domains. To put this knowledge to its best use, don't create domains or trust relationships haphazardly151;organize them according to one of four domain models: single domain, complete trust, master domain, or multiple master (aka multi-master) domain.

When choosing a model, you need to consider your network's administrative structure, number of users, and security needs. If one of the more complex domain models is the best fit, don't be reluctant to implement it for fear of replication-related problems. You can tweak the registry to ensure that your PDCs replicate to your BDCs in a timely fashion without taking up too much network bandwidth.

Deciding Factors
Several factors come into play when you consider which domain model best fits your needs. Which model you should use depends on how your company administers groups, users, servers, and workstations; how many users your network has; and whether you need to isolate some sensitive resources.

Administrative structure. Does one IT team administer all user accounts and groups, or is the chore split among IT groups according to division or region? Do multiple IT teams administer servers and workstations? Some organizations centralize user-account administration but assign management of computers at remote sites to administrators at those sites.

Number of network users. Each user and computer takes up storage in a PDC's SAM; the SAM's storage space is limited, so an NT domain can hold only so many users. Large organizations require multiple domains simply because of the number of users on the network. I recommend that you maintain no more than 15,000 users per domain (although I do know of companies that successfully manage 20,000 users in one domain).

Isolation of sensitive resources. Do you need to maintain a separate subset of computers to host highly confidential information or sensitive resources? Some domain models make consistent security standards difficult to maintain, whereas other models involve trust relationships that help improve security.

The Single Domain Model
A single domain NT network, which Figure 1 shows, is simple: centralized user-account administration, no trust relationships to manage, and only one domain security policy to maintain. For large organizations or companies with multiple geographic locations, however, the single domain model isn't a possibility. Such companies seldom use only one IT team to handle user-account administration. A company with offices in several cities probably has a team of administrators in each city. Large companies are especially likely to be geographically split (or simply have too many users to fit in one domain). NT offers no way to subdivide a domain and give administrative teams separate control over subsets of users. Either you're a member of a domain's Domain Admins group and have full control over users and groups in the domain, or you aren't a member of that group and have no administrative authority. Therefore, organizations that want to split user- and group-account administration must create separate domains for each IT team so that each team has discrete control over users in its jurisdiction.

Some organizations with multiple domains apply the single domain model to one domain to isolate a sensitive department from the rest of the organization. However, this ploy can produce a false sense of security, as the sidebar "Not as Safe as You Think," page 60, explains. If you want to keep users out of a certain area of your network, you need an internal firewall as well as a separate domain.

The Complete Trust Model
The complete trust model is a likely option for organizations that have a separate team of administrators for each autonomous department or location. Each division maintains a separate domain that contains the users and computers in that division. To let a user in one domain access information in other domains, the model specifies that you create 2-way trust relationships between all domains, as Figure 2 shows. The number of trust relationships equals y(y-1), where y is the number of domains in the network.

The complete trust model is extremely scalable. Each domain can hold thousands of users, but because all domains trust one another, a user needs only one account to access resources anywhere in the network. However, this model can result in a lot of trust relationships. For example, to implement the model for a seven-domain network, you'd need to define 42 trust relationships.

The complete trust model is prone to inconsistent security standards. The other domain models limit the number of domains that can contain user accounts, but in the complete trust model, each domain contains user accounts, and a different IT team administers each domain. Each domain in the complete trust model has a separate lockout policy, audit policy, and password requirements. As I explained in "PDCs, BDCs, and Trust Relationships," when your domain trusts another domain, you trust the other domain's administrators to manage their user accounts as carefully as you manage yours. Suppose you create a trust relationship with another domain and grant a user from that domain access to resources in your domain. Later, your company terminates the user, but the administrators in the trusted domain neglect to disable his or her account. Your domain is vulnerable to malicious acts from that user. Similarly, when you grant access to a global group from another domain, you must rely on that domain's administrators to keep the group's membership up-to-date.

   Previous  [1]  2  3  Next 


Top Viewed ArticlesView all articles
Command Prompt Tricks

One reader shares his tip for setting up the command prompt to reflect a remote path. ...

WinInfo Short Takes: Week of November 9, 2009

An often irreverent look at some of the week's other news, including some more Windows 7 sales momentum, some Sophos stupidity, Microsoft's cloud computing self-loathing, more whining from the browser makers, Zoho's "Fake Office," and much, much more ...

Where is Microsoft NetMeeting in Windows XP?

...


Security Whitepapers Reducing the Costs and Risks of Branch Office Data Protection

Solving Desktop Management Challenges in Healthcare

Solving Desktop Management Challenges in Education

Related Events WinConnections and Microsoft® Exchange Connections

Deep Dive into Windows Server 2008 R2 presented by John Savill

Check out our list of Free Email Newsletters!

Security eBooks Spam Fighting and Email Security for the 21st Century

Understanding and Leveraging Code Signing Technologies

A Guide to Windows Certification and Public Keys

Related Security Resources Introducing Left-Brain.com, the online IT bookstore
Looking for books, CDs, toolkits, eBooks? Prime your mind at Left-Brain.com

Discover Windows IT Pro eLearning Series!
Clear & detailed technical information and helpful how-to's, all in our trademark no-nonsense format


Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro DevProConnections IT Job Hound
Left-Brain.com Technology Resource Directory asp.netPRO ITTV Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 © 2009 Penton Media, Inc. Terms of Use | Privacy Statement