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
|
RSS
