Four typical misunderstandings in Windows 2008 domain environment design

In the Windows network environment, the domain is the core. In fact, the concept of the domain has been proposed since the NT era, and has been continuously improved. In the 2008 server environment, it can be said that it is quite perfect. Unfortunately, many system administrators have some typical misunderstandings when designing the domain structure for various reasons. The author makes some summaries here, I hope that readers will be changed, and no one will be crowned.

Myth #1: Set up different domains for different offices.

If there is a company now, it has one office in Shanghai and Guangzhou, and its headquarters is in Beijing. In this case, do you need to set up a domain for each of Shanghai and Guangzhou? Many system designers have done this before. In fact, there is no such need. Especially after Microsoft proposed a read-only domain controller in 2008, there is no need to set up separate domains for some offices. Otherwise, it will only increase the workload of system administrators.

In fact, the domain is an initial logical boundary or the smallest logical boundary of the Microsoft network environment. System engineers manage and store users and computers from within the boundaries of the domain. Includes printers, user account information, permissions, and more. From a security perspective, domains also act as administrative security boundaries for objects and include their own security policies. Simply put, it means that the domain is the logical structure of the object and can easily span multiple physical locations. This shows that when designing the domain structure, the physical location is not the main factor (and sometimes needs to be considered), and it mainly depends on the logical structure of the enterprise application environment.

So in practice, there is no need to set up multiple separate domains for offices in different geographic locations. We must try our best to avoid this kind of old life. In the 2008 application environment, system administrators can take advantage of read-only domain controllers to resolve security issues at the office or branch office.

The author believes that if the branch or office of the company is small, such as only a few dozen people, then there is no need to set a domain for it. On the contrary, if the branch of the enterprise is a single legal person, or it has hundreds of people, the company often needs to have professional system administrators in this branch. At this point, for the sake of management flexibility, a separate domain can be set up for this branch. In short, regardless of the location, it is unreasonable to set up separate domains for the office due to geographical location.

Myth 2: Confusing trust delivery with access rights.

Multiple domains form a domain tree. Or the domain tree is made up of multiple domains that are connected by a two-way transitive trust. In this definition, there is a core keyword called trust bidirectional transitive. If there is a domain number now, A.com is the trusted root domain, and B.A.COM and C.A.COM are its two parallel subdomains. Now according to the two-way transitive trust rule, if the A domain trusts B, then the B domain also believes the A domain. If the C domain trusts the A domain, then the A domain also trusts the B domain. According to the delivery rule, B trusts A, and A trusts C, and the B domain also trusts the C domain.

Now, when I ask the question, if the administrator of the A domain can manage the B domain and the C domain, does it mean that the administrator of the B domain can also manage the C domain? Because B believes A, and A believes in C, for which B can manage C? In fact, a conceptual error has been made here. Confuse trust with access rights. It's like you have a friend who trusts him very much. But it doesn't mean he can manage your family.

For this reason, system administrators need to keep in mind that although in a domain tree environment, trust is two-way and can be passed. But that doesn't mean that all users have full access. Even for administrators between domains, trust only provides one path from one domain to another. Or, trust is a prerequisite for management. Only on the basis of trust can it be authorized to manage it. By default, the system does not allow access from one domain to another. The administrator of the domain must grant permissions to users or administrators of another domain to access resources in their domain.

However, it should be noted that each domain in the domain tree shares a common schema and global catalog. All domains within a tree share the same namespace. According to the default security mechanism, the administrator of a subdomain has relative control over its entire domain. Another subdomain or even the root domain cannot access resources in its domain without authorization. It can also be seen from this that distrust and access are fundamentally different. Of course, on the basis of trust, the system administrator can grant other domain or root domain users certain permissions as needed to enable them to have access to specific resources of their domain.

In short, system administrators need to distinguish between the connection and the difference between trust and access rights, and can't confuse the two. Then based on this, consider whether you need to set the appropriate access rights for users in other domains.

Myth 3: Adopt the default domain authentication mode.

In the 2008 network environment, it supports two default domain authentication modes, NTLM and Kerberos authentication. NTLM is short for NT LAN Manager. As can be seen from this name, it follows the authentication system of Microsoft's early NT network environment. This type of authenticator passes the encrypted password across the network in a hashed form. Although the encryption of the commands transmitted in the network is taken, there are still certain security risks. Anyone can monitor the hash information passed over the network and collect it before using a third-party decryption tool to crack it. The difficulty of cracking depends on the complexity of encryption. In the case of normal production, an attacker can use a dictionary or brute force attack technology to decipher the password, and the crack is only a matter of time.

The Kerberos authentication method is different. Simply put, this authentication method does not send password information on the network, and its own encryption measures are more secure than NT local area network authentication systems. Unfortunately, for the sake of forward compatibility, even in the 2008 environment, Microsoft has adopted a relatively insecure NTLM authentication method by default. Some system administrators may not be very familiar with this aspect. In some occasions where application security requirements are relatively high, this default security mechanism is adopted, which has caused a lot of security incidents.

I recommend that system administrators need to understand the differences between the two authentication modes. Then, according to the actual situation of the enterprise, if the security level requirement is relatively high, then the authentication mode adopted needs to be switched, and a more secure Kerberos authentication mode is selected.

Myth 4: Confusing functional levels can't maximize performance.

In the Windows 2008 server environment, as with 2003, a functional level design was also adopted. The level of functionality is taken primarily to ensure backward compatibility with legacy domain versions. In the new network environment, 2008 also has its own level of functionality to maintain compatibility.

The following levels of functionality are now supported in 2008. 2000 local functional level (allows the controller to adopt the 2008, 2003 and 2000 SP3 versions, note that if it is a 2000 domain controller, it needs to be patched with SP3), 2003 functional level (allows 2003 and 2008 domain controllers to coexist, and will add The functionality added to the forest includes transferable trust), 2008 functional level (all domain controllers must have a server version of 2008). This level of functionality can be seen, primarily for domain controllers, regardless of the version of other servers or clients. By default, the server uses a degraded mode of compatibility to perform operations.

If you use a lower level of functionality, you won't be able to use the new features that 2008 brings. If the functional level of 2003 is adopted, the fine-grained password policy will not be adopted, and the capability of the domain DS cannot be fully realized. As you can see, different levels of functionality actually limit what features a system administrator can take. To do this in the domain design, the system analyst needs to confirm the new features of 2008 and confirm that these new features need to run at least at that level. Then judge whether you need to use these functions according to the actual situation of the enterprise. Finalize the level of functionality you need to take. Instead of first introducing a level of functionality, consider which features are not available. In this case, the cart before the horse is upside down.