An access control strategy is the building block on which you can start designing your directory services structure because it determines the overall strategy that you will follow in implementing security throughout the directory. There are two strategies that you will need to strike a balance between: access and control. Access means that you would build your directory security with easy accessibility in mind, focusing more on accommodating access than tightening security. Control implies that you grant the least permissions possible and would then move on to relaxing permissions as the need arises. This approach maintains system integrity and security as its top priority.
To implement a security strategy on files, folders, and directory objects, we need to enlist the help of ACLs or access control lists, which determine who has access to resources and how much access a given user has. ACLs are comprised of two layers of security, NTFS security and share security. NTFS security is implemented on the actual object, whereas share security is used when this resource is accessed over the network. When the NTFS and share permissions are not the same, the most restrictive permissions apply. NTFS permissions are the ideal place to set up your permissions because it has the ability to propagate its settings to subfolders , can be backed up, are more flexible, and can be audited , whereas shared permissions lack all of these.
When analyzing risks to your directory services, you should start by examining the methods by which your system can be compromised. The primary target is going to be user accounts and passwords; if an attacker can gain these credentials, then he or she can cause damage to the extent that the credentials will allow. Therefore, hardening your username and password strategy is a priority. To do this, you should avoid using known naming conventions for usernames, like first initial first name and complete last name or some other known configuration. Try to append this with an employee number or some other unique identifier.
This also brings us to password strategy. With Windows 2000 and Windows Server 2003, you can use Group Policy to enforce a strong password policy to protect your system. You can configure the password policy to force users to use a password with a certain character length. You can also enforce how often a password expires and should be changed. You can force your users not to use a password they have used before, and you can also enforce password complexity, which means the password would have to contain uppercase, lowercase, and special character letters before it is accepted by the system
User accounts have rights and permissions that can be assigned to them. On the one hand, this helps you regulate what they can do and what they can access on the network. This can also limit the scope of damage an attacker can do if he or she gains access to a user account, since the attacker will be limited by these rights and permissions. Rights allow a user to perform a task like shutting down the system or changing the system time, while permissions grant a user access to a resource such as a folder or a printer.
Many modern applications require what are known as service accounts, which are user accounts that are used solely by applications to start certain services and interact with users and the operating system. Service accounts can be common attack vectors for attackers looking for an easy entry point into your network. For this reason, it is important to grant service accounts just enough permission to complete its task. Many applications will use the Local System account by default to start its services. This account in particular has full control over the system, and if compromised can lead to denial-of-service (DoS) attacks by shutting down the system completely or stopping certain critical services. Whenever possible, service accounts should be local accounts on the system on which the application is running, so that if compromised, the extent of damage is limited to the system and not the domain.
Group Policy offers a great way to control user memberships to critical groups like Domain Admins and Enterprise Admins. Using Restricted groups, you can selectively choose which members are part of a group, and you can then enforce that membership. For example, if only Jim, Jack, and Jane are supposed to be Domain Admins, and Eli decides to add himself to the group, as soon as Group Policy refreshes, Eli will be removed since he is not included in the Restricted Group settings. In the same context, if Eli adds himself and removes all the other users, again as soon as Group Policy refreshes, Eli will be removed and the original users will be re-added.
Group Policy also allows you to implement Kerberos and Audit policies that can then be put into effect across an entire network. Kerberos is a strong network authentication protocol that can be configured in Group Policy under \Computer Configuration\Windows Settings\Security Settings\Account Policies\_Kerberos Policy . Audit policies are imperative in any enterprise to monitor access to certain files, folders, and objects and can be set via Group Policy as well under \Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy .
When designing a delegation strategy, you should be aware that there are two types of administrators, Service Administrators and Data Administrators. Service Administrators are responsible for the overall integrity and availability of Active Directory; they maintain network services and functions for the entire user base. Data administrators are responsible for specific objects stored within Active Directory such as user and group accounts and the like. You should create your Active Directory design so that these two tasks can be separated and managed by two different people or job functions. When designing a delegation strategy, its also imperative that you analyze your business needs for autonomy versus isolation. For example, your Human Resources department might require full and unshared control over their portion of the Active Directory and all of their network resources, with strict policies on security. In this case, the only way to give them this level of control is by creating a separate forest for them. Another department might be more willing to accept shared administration of their resources, in which case they would fall under the category of autonomy. At this point, you can create a separate domain or OU to subdivide their resources for them. Delegation of administration can be set the forest level, domain level, and OU level. The higher the level, the more isolated the administrative model. Conversely, the lower the level of delegation, the more it tends toward autonomous administration.
There are three types of groups that you can use to organize users within a forest: Domain Local groups, Global groups, and Universal groups. Domain Local groups are usually used to assign permissions on a resource. They can contain users and groups from any domain in the forest, but can only be assigned permissions on resources within their native domain. Global groups can contain users only from the domain in which they were created. Universal groups can contain users and groups from any domain in the forest and can be assigned permissions on any resource in the domain.
Microsoft best practices call for the use of AGDLP or AGUDLP when creating users and groups, with the intent of making permission assignments as flexible and easy to manage as possible. AGDLP calls for adding users to Global groups in their respective domains, adding the Global groups to Domain Local groups, and assigning permissions on resources to Domain Local groups. AGDULP uses a similar model, but Global groups would be added to Universal Groups, which would then be added to Domain Local groups and assigned permissions. You should carefully design any group nesting strategy so that you dont end up with more than two or three levels of nestings within a group to keep management simplified. You should also consider the best approach for the task at hand. Make sure you always document your group nestings and creation to account for disaster recovery and troubleshooting.
Finally, Windows 2000 and Windows Server 2003 have different functional levels for domains and forests. For domains, we have Windows 2000 mixed mode, which is the default for Windows 2000 and Windows Server 2003 domains. This allows for backward compatibility with Windows NT and Windows 2000. Windows 2000 native mode only allows for 2000 and 2003 DCs. You also have the option of using Windows Server 2003 interim mode, which will allow for backward compatibility with Windows NT4 DCs only. Finally, there is Windows Server 2003 mode, which will only allow Windows server 2003 DCs.
Likewise, there are three forest functional levels. Windows 2000 allows for Windows 2000, NT, and Windows Server 2003 DCs within all domains in the forest. Again, a Windows NT4 domain that is upgraded directly to Windows Server 2003 will be placed in Windows Server 2003 interim mode, which allows for Windows NT and Windows Server 2003 DCs. The final forest functional level is Windows Server 2003, which will only allow for Windows Server 2003 DCs in any domain in the forest. This unleashes the full potential and all the features of Windows Server 2003, since it does not need to be scaled back to accommodate older DCs that dont have the newest features and functionality.