Get a glimpse inside Paul Cooke's e-book "The definitive guide to Windows 2000 security" with this series of book excerpts, courtesy of Realtimepublishers.com. This excerpt is from Chapter 5, "Configuring access control." Click for the book excerpt series or get the full e-book.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Access control best practices
I cannot tell you how to actually handle granting permissions and user rights in your environment because every environment is different and every company culture is different. The most important thing to remember when you're setting up access control in your Windows 2000 environment is to give people the minimum number of rights they need to do their jobs. If Alice needs to reset the passwords for people in Hong Kong, grant her the necessary permissions on the AD objects to allow her to do so. If Bob needs access to all of the Human Resources files on the network, grant him the access he needs.
However, there is one universal rule that I believe you should always follow, no matter how silly it might seem at the time: Never give permissions to individual users; always use security groups. I cannot stress this point enough. If you use security groups to grant permissions, you can use AD to centrally control group memberships. You have to set the ACL only once; then you can control permissions using membership in the group. Believe me, adding and removing people from groups of users is much easier than modifying ACLs across your enterprise.
The type and scope of the group that you need to use is driven by both business and user requirements. For maximum flexibility, you need to tend toward deploying universal groups of type security. These groups can be mail-enabled to provide access control and distribution list functionality. However, as I noted earlier in this chapter, you can create universal groups of type security only in native-mode domains.
Another consideration for deploying universal security groups is that membership of universal groups is published to the GC, so any membership changes that you make will cause replication traffic. This replication is exacerbated by the fact that group membership is held in a single multi-valued attribute of the group object; therefore, a large group can generate a significant amount of replication traffic.
The simplest strategy for mitigating replication traffic is to use group nesting. Look toward creating large universal groups—umbrella groups that contain just other universal or global groups. While using nested universal groups allows client applications to view the full membership of the umbrella group and its subgroups, using global groups may affect the ability of your client applications to view group membership because global groups don't have their membership published in the GC.
As I've just discussed, the ability to expand and view the membership of a group depends on the scope of your group object. If a group object is a domain local or global group defined in the local domain, the membership list can be obtained from any local domain controller. And if a group object is a universal group and users appear directly in the list (not something that should be done), the membership can be obtained from any local GC.
But if a group object is a domain local or global group that has been created in another domain, or if a universal group contains global groups that are in other domains, client applications must make direct Lightweight Directory Access Protocol (LDAP) calls to a domain controller in the remote domain to retrieve the membership. Depending on the speed of the network, remote retrieval may take some time. There are no hard-and-fast rules, but be aware of the different tradeoffs that you'll have to make when you're deciding how to deal with large universal groups and how to nest them.
A final point to be aware of is that Microsoft recommends that the number of members in any type of group be limited to 5000. If a group needs to contain more than 5000 users, use nesting. Microsoft further recommends that for reasons of efficiency and scalability, nesting groups be limited to no more than 500 members. You can of course exceed these values, but if you do, keep a close eye on things.
Group best practices
Table 5.6 presents guidelines for determining whether a group type should be a security or distribution group.
|Create this group||When|
|Security||The group requires specific access to network resources. There is a possibility that the group will require specific access to network resources in the future. There is a possibility that the group will require specific access to public folders in E2K.|
|Distribution||There is no foreseeable need for specific access to network resources or to public folders in E2K now or in the future.|
Table 5.6: Guidelines for determining group type.
Table 5.7 provides guidelines for determining group scope.
|Create this group||When|
|Computer local||You need to grant specific access on a local computer without granting access across an entire domain.|
|Domain local||The group doesn't require users to see full membership from any domain, AND group membership needs to cross domain boundaries, AND the group is only used to grant access in a single domain.|
|Global||The group doesn't require users to see full membership from any domain, AND group membership doesn't need to cross domain boundaries.|
|Universal||The group requires users to see full membership from any domain, OR domain local and global groups won't meet the requirements for the use of the group.|
Table 5.7: Guidelines for determining group scope.
User rights assignments
As I mentioned in Chapter 3, user rights assignments can be tricky; determining whether the user rights that most applications say they require are truly required is a difficult task. In addition, the sheer number of applications and their required rights makes it impossible for me to really help you decide which user rights are truly appropriate in your environment. One thing I can do, though, is tell you never to assign the following user rights to any user or group:
- Act as part of the OS
- Create a token object
- Create permanent shared objects
- Debug programs
- Generate security audits
- Lock pages in memory
- Manage auditing and security log
- Modify firmware environment variables
- Replace a process level token
- Synchronize directory service data