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