MICROSOFT NT ENTERPRISE DESIGN
Microsoft NT Domain Models The concept of
domains stems back to early versions of Microsoft LAN Manager and
IBM LAN Server. A domain is simply a group of objects that can be
centrally administered. These domain objects can include user Ids,
user groups, file servers, print servers, and application servers.
NT domains allow for users to log in once into the network and then
have the ability to access multiple resources in the domain such as
file and print servers. Some network operating systems, such as
NetWare 3.1X, require a user ID and password for each server that is
to be attached or accessed. Once an NT domain user is authenticated,
the appropriate level of server access permissioning can be done on
each NT server.
The Single Domain Model is obviously a design model in which all
the objects, users and resources, are in one domain. This is the
simplest domain model to implement and administer. There are however
both theoretical and practical limits on the size of a single
domain. The industry recommended limit is 15,000 objects per domain
with a theoretical limit of 40,000 objects such as Ids, user groups,
file servers, print servers, and application servers. It is
important to remember that these objects are contained in a single
database that may be transmitted across local and wide area networks
and loaded into memory for administration purposes. A single domain
model may be appropriate for corporations with less than 15,000
objects.
The concept of trusts was created for organizations
with more than one domain to enable resource servers in one domain
to "trust" the users and groups in another domain. What this means
is the users in one domain can access a server in another domain.
This is considered a one-way trust, where the resource objects are
in the "trusting domain" and the user objects are in the "trusted
domain". A two-way trust is where both domains are acting as both
trusted and trusting domains. When there many resource domains in an
enterprise organization, a complicated system of one-way and two-way
trusts may have to be maintained and administration can sometimes be
very difficult.
The Complete Trust Model is a distributed domain model where
every single domain trusts every other single domain. Each of the
domains can contain the recommended 15,000 objects consisting of
user Ids, groups, and resource servers. This model can be used in
organizations where distributed administration is necessary.
The Master Domain Model is an enterprise design model in which
the user Ids an d user groups are objects in a single ìmaster
domainî and are trusted by file, print, and application servers that
are in ìresource domainsî. The master domain is known as the trusted
domain and the resource domains are known as trusting domains. This
model provides for single user ID administration while supporting
access to a multi-domain environment. This is a two-tier model in
which every resource domain must have a trust set up with the master
domain since these trust relationships are non-transitive. In this
model, the recommended 15,000 object limit now applies to user Ids
and groups only, and the file, print, and application server objects
exist in the resource domains.
The Multiple Master Domain Model is used when you reach the
recommended 15,000 user id and group object limit in a Master Domain
model. To implement this model, a one-way trust must be set up
between each Master and Resource Domains. In addition, a two-way
trust must be established between the Master Domains.
Factors other than object counts must be considered in an
enterprise NT Domain design. Some of these are organizational,
geographical, administration, security and scalability for future
growth.
Organizational needs:
- Budget constraints - The fewer the domains the lower the
equipment costs.
- Resource ownership &control - If resources are distinct to
each organizational unit, it may be advantageous to use separate
domains.
- Political factors - User and management's comfort levels may
dictate the domain model based on organizational boundaries.
Geographical issues:
- Robustness of the WAN - The more robust the WAN is, the more
flexibility in the domain design.
- Spanning time zones - For more efficient support, localized
resource domains may be needed.
- Dispersed shared resources - The use of enterprise-wide shared
resources can be implemented with any of the domain models.
Administrative needs:
- Password administration - Centralized password administration
can best be accomplished using a master domain model.
- Single logon - Any enterprise design that includes untrusted
domains may require multiple logons.
- Centralized vs. Distributed - Complete trust domain model may
not be viable in organizations with centralized administration.
Security issues:
- Confidential server systems - A system domain may be required
for systems requiring special security access.
- Password security - The need for a limited number of
administrators with access to change passwords may dictate a more
distributed domain model.
Scalability needs:
- Future growth - Projected increase in object counts may
determine the domain model.
- Upgrade path - Matching your domain design for ease of
migration to X.500 directory services.
Next
Updated August 15, 1996
Print
This Page
E-mail this URL |