Tài liệu DomainController ActiveDirectory pdf

Understanding Domain Controllers Domain Controllers Security Issues 1 When it comes to Windows Server 2003 Active Directory networks, one of the most important server roles which can be configured is probably the domain controllers role. Domain controllers perform a number of important functions and control activities within a domain, including the following: • Contain a replica of the Active Directory directory for the domain to which it belongs, and is responsible for managing that directory • Provide authentication services for the network. • Store and distribute group policies. • Manage access to network resources within the domain. • Manage changes to user accounts and computer accounts. • Manage changes to passwords. • Track user account information through Security Identifiers (SIDs). When a user attempts to log on to the system, a request to authenticate the user is sent to each domain controller within the domain. • Replicates changes made to their Active Directory replica to the remainder of the domain controllers within the domain. • Domain controllers also integrate with network services such as DNS, DHCP, Kerberos security, and Remote Access. This in turn facilitates centralized management and security. From the above mentioned functions of domain controllers, you can see that the domain controllers’ server role is an integral server role in all Windows based networks. When configuring domain controllers, you can configure a domain controller to perform only one main function, or you can configure the domain controller to perform a number of functions. The larger the network, the more specialized the configuration of the domain controller tends to become. The domain controllers within your Windows Active Directory environment should be well protected by means of special security configurations. Any unauthorized individuals that are able to access a domain controller would be able to severely compromise security on your network. A few threats to domain controllers are listed here: • Attempts to gain access to the security database on domain controller. • Attempts to copy the security database so that the database can be viewed and examined at a later stage. • Attempts to access domain controllers with the objective of viewing and seizing security configuration information. • Attempts to gain access to the security database on the domain controller to change the existing user rights, with the intent of configuring an unauthorized user with administrative access to your domain. • Attempts to access the domain controller to change computers belonging to the domain so that rogue computers can access the domain. The importance of domain controllers basically forces you to implement security measures and policies that minimize the threats to domain controllers. One of the obvious security strategies that should be implemented is to implement physical security for your domain controllers. Your domain controllers should always be physically secured in a secure location such as a data center. Physical access to the domain controllers 1 location should be limited to a few authorized individuals only. You should also limit access from network connections to domain controllers. You should only configure services and applications that are needed by the domain controller server role. All services and applications that are unnecessary should be disabled or deleted. Basic Security Measures for Securing Domain Controllers The recommended basic security measures which you can implement to secure domain controllers are listed here: • Physically secure domain controllers. This should include access control to the location where domain controllers are kept. • The NTFS file system should be utilized to protect data on the system volume. • Limit membership to the following groups: o Domain Administrators group o Enterprise Administrators group • Strong passwords should be used on domain controllers to secure domain controllers from unauthorized access attempts. • All unnecessary services and applications should be deleted. • The syskey utility can be used to further protect the security database. • You can also secure domain controllers by requiring smart card access for access to domain controllers. • Use caution if you are delegating administrative control over the configuration of a domain controller. How to create a system key 1. Click Start, Run, and enter syskey. Click OK. 2. Select Encryption Enabled. 3. Click Update. 4. Select the appropriate option. 5. Click OK. Securing Domain Controllers with Firewalls You can use firewalls to protect domain controllers. Packet filtering features can be used to block traffic destined to and from a domain controller. You can also limit the number of ports that are opened between a domain controller and a computer. Only those ports which are needed for communication should be opened between a domain controller and computer. The ports used by Active Directory for specific Active Directory communication are listed here: • For a user network logon over a firewall: o MS traffic; TCP port 445 and UDP port 445 o DNS; TCP port 53 and UDP port 53. o Kerberos authentication protocol; TCP port 88 and UDP port 88. o Lightweight Directory Access Protocol (LDAP) ping; UDP port 389. • For a computer logon to a domain controller: o MS traffic; TCP port 445 and UDP port 445 o DNS; TCP port 53 and UDP port 53. o Kerberos authentication protocol; TCP port 88 and UDP port 88. o Lightweight Directory Access Protocol (LDAP) ping; UDP port 389. • For verification of trust relationships between domain controllers: o MS traffic; TCP port 445 and UDP port 445 o DNS; TCP port 53 and UDP port 53. o Kerberos authentication protocol; TCP port 88 and UDP port 88. o Lightweight Directory Access Protocol (LDAP); TCP port 389, for SSL TCP port 686. o Lightweight Directory Access Protocol (LDAP) ping; UDP port 389. o Netlogon. • For creation of a trust relationship between domain controller located in different domains: o MS traffic; TCP port 445 and UDP port 445 o DNS; TCP port 53 and UDP port 53. o Kerberos authentication protocol; TCP port 88 and UDP port 88. o Lightweight Directory Access Protocol (LDAP); TCP port 389, for SSL TCP port 686. o Lightweight Directory Access Protocol (LDAP) ping; UDP port 389. Domain Controller-Specific Predefined Security Templates When a server is first promoted to the domain controller role, a security template called the DC security.inf template is applied to the domain controller. A security template can be defined as a collection of security configuration settings or parameters that can be applied to a domain controller, member server or a workstation. The settings within a security template are used to control the security configuration of a computer through both local policies and group policies. The DC security.inf security template defines default system services settings, default security settings, and file system and Registry settings for a domain controller. The DC security template is created when a server is first promoted to the domain controller role, and basically forms the baseline security for the domain controller. The other predefined security templates which you can specify for a domain controller are: • securedc.inf template: This predefined security template contains security settings for domain controllers that enhance security on a domain controller while at the same time maintaining compatibility with most functions and applications. The securedc template includes enhanced security options and auditing policies. It also includes restrictions for anonymous users. The impact on applications is minimized, and computers are configured to LAN Manager responses. • hisecdc.inf template: This highly secure template contains security settings for domain controllers. The hisecdc template is considered a stronger, more secure setting than the securedc template. The hisecdc template provides improved security for NTLM (NTLM version 2), and applies both Registry and file security. The hisecdc template also disables all additional services and removes all members from the Power Users group. It is recommended that you use the hisecdc.inf template on domain controllers (if feasible). Backing Up and Restoring Domain Controllers A domain controller contains system state data that includes Active Directory and the SYSVOL directory. System state data consists of the Registry, system boot files, COM+ Class Registration database, Certificate Services database, and files under Windows File Protection. Backing up system state data backs up all system state data associated with the local computer. A domain controller can also contain applications or files that are specific to that particular domain controller. All these components have to be included when you back up the domain controller. When you restore system state data and Active Directory to a domain controller, you have to decide on the method of restore to perform. System state data can be restored on the domain controller through either of the following methods: • Nonauthoritative restore: When a nonauthoritative restore is performed, Active Directory is restored from backup media on the domain controller. This information is then updated during replication from the other domain controllers. The nonauthoritative restore method is the default method to restore system state data to a domain controller. • Authoritative restore: In an authoritative restore, Active Directory is installed to the point of the last backup job. This method is typically used to recover Active Directory objects that were deleted in error. An authoritative restore is performed by first performing a nonauthoritative restore, and then running the Ntdsutil utility prior to restarting the server. You use the Ntdsutil utility to indicate those items that are authoritative. Items that are marked as authoritative are not updated when the other domain controllers replicate to the particular domain controller. How to back up a domain controller 1. Log on to the domain. 2. Click Start, All Programs, Accessories, System Tools, and then click Backup. 3. When the Welcome To The Backup Or Restore Wizard page opens, click Next. 4. In the Backup Or Restore page, choose the Backup Files And Settings option. Click Next. 5. When the What To Back Up page opens, choose the Let Me Choose What To Back Up option. Click Next. 6. In the Items To Back Up page, select System State. Click Next. 7. When the Backup Type, Destination, And Name page opens, select the appropriate option in the Select The Backup Type box. 8. Choose the location for the backup in the Choose A Place To Save Your Backup box. 9. Enter a name for the backup job in the Type A Name For This Backup box. Click Next. 10. Click the Advanced button on the Completing The Backup Or Restore Wizard page. 11. When the Type Of Backup page opens, choose the Normal option for the backup type, and then click Next. 12. In the How To Back Up page, it is recommended to select the Verify Data After Backup option. 13. If hardware compression is supported, and you are using a tape mechanism, click the Use Hardware Compression, If Available option. Click Next. 14. When the Backup Options page opens, choose Replace The Existing Backups, and choose Allow Only The Owner And The Administrator Access To The Backup Data And To Any Backups Appended To This Medium. Click Next. 15. Select the Now option in the When To Back Up page. Click Next. 16. Click Finish. 17. Click the Report button on the Backup Progress page to view a report on the backup job just completed. How to restore system state data on a domain controller (nonauthoritative restore) 1. Restart the local computer. 2. During startup, press F8 to access the Windows Advanced Options. 3. Proceed to select Directory Services Restore Mode. Press Enter 4. Choose the operating system that should be started at the Please Select The Operating System To Start prompt. Press Enter. 5. Log on to the domain using an account with Administrator privileges. 6. Click OK when a message appears stating that Windows is running in safe mode. 7. Click Start, All Programs, Accessories, System Tools, and then click Backup. 8. When the Welcome To The Backup Or Restore Wizard page opens, click Next. 9. In the Backup Or Restore page, choose the Restore Files And Settings option. Click Next. 10. On the What To Restore page, choose the data that should be restored. Click Next. 11. Verify that the media that contains the backup file is in place. 12. Click Finish to start the nonauthoritative restore. 13. Click OK when a message appears stating that the restore will overwrite existing system state data. 14. When the restore process completes, restart the computer. Because of the type of information stored on domain controllers, you should audit all backup and restore events which are performed on your domain controllers. It is recommended that you enable the Local Policies | Security Options | Audit: Audit the use of Backup and Restore privilege option so that you can detect when backups are being performed dishonestly. Digitally Encrypting and Signing Authentication Traffic Computer accounts are used to manage and authenticate computers within a domain. Computer accounts are stored in Active Directory, and can be managed using the Active Directory Users And Computers management tool. A computer has to belong to a domain in order for you to log on to it using a domain user account. Computer accounts are automatically created for computers running Windows NT, Windows 2000, Windows XP Professional or Windows Server 2003 when joining a domain. Computer accounts contain a name, password, and security identifier (SID). Computer properties are included in the computer object in Active Directory. Active Directory automatically creates a computer object in the Computers OU when a computer joins a domain, and no computer account exists for the computer. For a computer to access and communicate with a domain controller within the domain, the computer has to be authenticated. There are three GPO settings that determine whether authentication traffic is signed and encrypted: • Domain member Digitally encrypt or sign secure channel data (always): Here, the computer will only use secure channel data to communicate with the domain controller. Before you can use this option, domain controllers have to minimally be upgraded to Windows NT 4.0 SP6a. Enabling the Digitally encrypt or sign secure channel data (always) option assist in preventing the following attacks when computers and domain controllers communicate: o Replay attacks o Man-in-the middle attacks • Domain member Digitally encrypt secure channel data (when possible): This option should be enabled and used if any down-level domain controllers or clients prevent you from using the former option. When this option, and the option below are enabled, the best possible security which can be used, is used. • Domain member Digitally sign secure channel data (when possible): This option should be enabled and used if down-level domain controllers or clients prevent you from using the Digitally encrypt or sign secure channel data (always) option. Configuring Audit Policies and Event Log Policies for Domain Controllers When Active Directory is installed on a computer and a new Active Directory domain is created, the computer object of the domain controller is stored in the Domain Controllers organizational unit (OU). A Group Policy Object (GPO) that is linked to the Domain Controllers OU is also created. The Domain Controllers OU contains the following audit policies which you can customize: • Audit Account Logon Events, Audit Account Management, Audit Directory Service Access, Audit Logon Events, Audit Policy Change, and Audit System Events You might also need to modify the policy settings of the Event Log to suit your auditing strategy. Limiting User Rights The Domain Controllers OU GPO by default grants the Allow Log On Locally user right to these groups: • Account Operators • Administrators • Backup Operators • Print Operators • Server Operators For the Print Operators and Account Operators built-in groups, it is recommended that you remove the Allow Log On Locally user rights. It is also recommended that you limit which individuals are allowed to shut down domain controllers. The Domain Controllers OU GPO by default grants the right to shut down domain controllers to these built-in groups: • Administrators • Backup Operators • Print Operators • Server Operators For the Print Operators and Backup Operators built-in groups, it is recommended that you remove the right to shut down domain controllers. Limiting Anonymous Access Anonymous authentication is an authentication method that actually allows a user and network client to be authenticated with the user/client furnishing no user credentials. However, if you are running Windows Server 2003, the user will not be authorized to access network resources. With the earlier Windows operating systems, this was not the case. Anonymous authentication is typically used to supply backward compatibility with systems prior to Windows 2000, for the following scenarios. • Windows NT 4.0 could possibly use anonymous access to obtain information from domain controllers. • Remote Access Server (RAS) servers on Windows NT 4.0 utilizes anonymous access for ascertaining dial-in permissions • Older operating systems could also use anonymous access to change passwords (Pre "Windows 2000"compatible access group) in Active Directory. To enable anonymous authentication, activate one of the following security policy settings: • Network Access: Share That Can Be Accessed Anonymously: Use this security policy setting to define specific shares which can be accessed. • Network Access: Let Everyone Permissions Apply To Anonymous Users: When enabled, anonymous users are added to the Everyone group. A better method of enabling anonymous access is to include the Anonymous Logon security principal in the specific access control list (ACL) that needs access. With Windows Server 2003, the Anonymous account is restricted by default. If you need to enable it for systems that require Anonymous access, use these recommendations to enable the Anonymous account so that you do not reduce security unnecessary: • To prevent intruders from using the using Anonymous logon to calculate accounts on a computer, you should use the Do not allow anonymous enumeration of SAM accounts and shares policy Group Policy Object. This option can be used if you are running Windows 2000 or later Windows operating system versions. • One of the most secure methods of enabling Anonymous logon or access is to edit the ACLs of resources that need to allow Anonymous logon. This is though a manually intensive process. • For clients that are running pre-Windows 2000 operating systems, you can add Everyone and Anonymous to the pre-Windows 2000 compatible access group if users need to be able change their passwords. • While it is not strongly recommended, you can use the Let Everyone permissions apply to anonymous users GPO to change the security configuration back to the Windows NT model. www.tech-faq.com Understanding Active Directory The Limitations of the Windows NT Domain Model and Network Security With Windows NT , domains were utilized to manage users, and to manage and secure network resources. A domain is the logical grouping of servers and network resources under a single domain name. In Windows NT, a domain could be considered as a central database containing security information which was then basically used to manage users and network resources. The Windows NT computers operated as domain controllers, with each domain essentially having one Primary Domain Controller (PDC) and one or multiple Backup Domain Controllers (BDCs). The PDC held the centralized database that contained the security information to manage users and resources. This was how domains were put into operation in Windows NT network environments. The centralized database or accounts database was replicated to the BDCs to ensure reliability. The master copy of the database however only resided on the PDC. Any changes had to be made on the PDC, and were then replicated to the BDCs. Network resources such as network printers and files were typically located in resource domains. Resource domains had their own PDC and BDCs. What this meant for most environments was that these resource domains were often managed on its own, often separate to the master domain(s). A master domain(s) normally managed network accounts. Because users typically need to access resources, the resource domains needed to trust the master domain(s). In the Windows NT domain model, trust relationships could only operate in one direction. For administrative purposes, the users stored in master domains were organized into global groups, and the global groups were then set with permissions to access the resource domain's network resources. Because of manner in which the Windows NT domain is structured, excessive network traffic can be generated by domain controllers synchronizing. In addition, managing a large number of trust relationships can become a cumbersome task and if not managed appropriately, can indeed become uncontrollable. This has led to the Windows NT 4 domain structure not scaling well to cater for larger complicated networks. Although it is possible to implement multiple Windows NT domains, managing multiple domains can too be an intricate process. Bandwidth costs would also typically increase due to domain controller synchronization. As mentioned earlier, the security information of users were stored in a centralized database. In Windows NT domain environments, the security account information is kept in the Security Account Manager (SAM) database. The SAM database is a flat file database that contains users and groups. Computer accounts are stored as a particular type of user account. Because the SAM is a component of the Registry, and the Registry has a Registry size limit (RSL), the SAM database in a Windows NT environment can only grow to a particular size. The Registry itself can not exceed 80 percent of paged pool memory. In Windows NT, this is 192MB. For Windows 2000 and Windows Server 2003, it is 470MB. In addition to this, in large Windows NT network environments where multiple BDC exists, a considerable load can be placed on the PDC to ensure that the databases are replicated. One of the major shortcomings of the Windows NT domain model is that the PDC is the only domain controller that can access the SAM database. When the PDC is unavailable, no computers can be joined to the particular domain, and new users and groups cannot be specified for the domain. Users cannot change their passwords when the PDC is unavailable. They can however access the BDC. To ensure access to the SAM database, administrators in a Windows NT domain would have to promote a robust enough BDC to a PDC. In cases where a wide area network (WAN) connection actually links the PDC to the remainder of the network, having an unavailable PDC can present an even greater problem. You would generally refrain from promoting a BDC to PDC. With global networks, the speed of the WAN links influences the speed at which changes are effected on the SAM of the PDC. The local BDC is not utilized. Because of the characteristics of domains, users need to be located into groups in order to access network resources. Since these groups could not be nested, the number of groups within a Windows NT domain could run into hundreds. Managing large numbers of groups can be an administrative challenge, and granting access to groups to resources could turn into an administrative nightmare. Improvements made by Active Directory to address the limitations of Windows NT domains Active Directory was designed to provide a centralized repository of information, or data store that could securely manage the resources of an organization. Active Directory makes it possible for different types of information to be stored in a centralized distributed database. The Active Directory directory services ensure that network resources are available to, and can be accessed by users, applications and programs. The directory included with the Active Directory directory services contains information on network resources. It also includes additional information on each service that can make this information accessible. Network resources contained in the directory are known as objects. Objects typically consist of user, group and computer information, databases, printers, security policies and servers. With Active Directory trust relationships are completely transitive between domains. Active Directory also makes it possible for administrators to log on to a one network computer, and then manage Active Directory objects on a different computer within the domain. Unlike the Windows NT domain model that could not mirror the structure of the organization, Active Directory makes is possible to mirror this structure because of the hierarchical organization of objects within Active Directory. Active Directory can be set up with as many branches required to classify administrative functions. Because all information stored in Active Directory is located in one centralized, distributed data store; administrative needs are reduced, the availability of security information is increased, and there is an improvement in the structure of information. With Windows Server 2003, the Active Directory account database can accommodate a billion objects, and multiple domain controllers can host copies of the Active Directory directory store. These features resolve the scalability, poor performance and single point of failure issues experienced with the Windows NT domain model. Active Directory also has an extensible schema. Schema refers to the structure of the database. What this means is that you can expand and customize the types of information stored within Active Directory. With Active Directory, all domain controllers in a domain are regarded as peers. Each domain controller contains a copy of the domain directory, and when changes are made to a domain controller, the updates are replicated to the remainder of the domain controller within the domain. Active Directory Structure Active Directory has a hierarchical structure that consists of various components which mirror the network of the organization. The components included in the Active Directory hierarchical structure are listed below: Domains, organizational units (OUs), domain trees and forests are considered logical structures. Sites and domain controllers are considered physical structures. • Domains are the main logical structure in Active Directory because they contain Active Directory objects. Network objects such as users, printers, shared resources, and more, are all stored in domains. Domains are also security boundaries. Access to objects in the domain is controlled by access control lists (ACLs). You can use the domain functional level to enable additional Active Directory features. You do this by raising the domain functional level of the domain controllers within the domain. In Windows 2000, the domain mode concept was used and not the domain functional level. The domain functional levels that can be specified are Windows 2000 Mixed, Windows 2000 Native, Windows Server 2003 Interim and Windows Server 2003. • Organizational Unit (OU): An OU is a container that enables you to organize objects such as users, computers and even other OUs in a domain to form a logical administrative group. An OU is the smallest Active Directory component to which you can delegate administrative authority. A domain can have it own unique OU hierarchy. • Domain Trees: When you group multiple domains into a hierarchical structure by adding child domains to a parent domain, you are basically forming a domain tree. Domains are regarded as being part of the same domain tree when they have a contiguous naming structure. A two-way transitive trust relationship is automatically created between the parent domain and child domains when you create the child domain. • Forests: A forest is the grouping of multiple domain trees into a hierarchical structure. Domain trees in a forest have a common schema, configuration, and global catalog. Domains within the forest are linked by two-way transitive trust. Through the forest functional level, you can enable additional forest wide Active Directory features. The forest functional levels that can be set are Windows 2000, Windows Server 2003 Interim, and Windows Server 2003. • Sites: In Active Directory, sites are formed through the grouping of multiple subnets. Sites are typically defined as locations in which network access is highly reliable, fast and not very expensive. • Domain Controllers (DCs): A domain controller is a server that stores a write copy of Active Directory. They maintain the Active Directory data store. Certain master roles can be assigned to domain controllers within a domain and forest. Domain controllers that are assigned special master roles are called Operations Masters. These domain controllers host a master copy of particular data in Active Directory. They also copy data to the remainder of the domain controllers. There are five different types of master roles that can be defined for domain controllers. Two types of master roles, forestwide master roles, are assigned to one domain controller in a forest. The other three master roles, domainwide master roles, are applied to a domain controller in every domain. o The Schema Master is a forestwide master role applied to a domain controller that manages all changes in the Active Directory schema. o The Domain Naming Master is a forestwide master role applied to a domain controller that manages changes to the forest, such as adding and removing a domain. The domain controller serving this role also manages changes to the domain namespace. o The Relative ID (RID) Master is a domainwide master role applied to a domain controller that creates unique ID numbers for domain controllers and manages the allocation of these numbers. o The PDC Emulator is a domainwide master role applied to a domain controller that operates like a Windows NT primary domain controller. This role is typically necessary when there are computers in your environment running pre-Windows 2000 and XP operating systems. o The Infrastructure Master is a domainwide master role applied to a domain controller that manages changes made to group memberships. The Global Catalog and Schema components actually manage the Active Directory hierarchical structure. In Active Directory, logically grouping resources to reflect the structure of the organization enables you to locate resources using the resource's name instead of its physical location. Active Directory logical structures also enable you to manage network accounts and shared resources. The components of Active Directory that represent the logical structure in an organization are: • Domains, Organizational Units (OUs), Trees, Forests, Objects The components of Active Directory that are regarded as Active Directory physical structures are used to reflect the organization's physical structure. The components of Active Directory that are physical structures are: • Sites, Subnets, Domain Controllers The following section examines the logical and physical components of Active Directory. A domain in Active Directory consists of a set of computers and resources that all share a common directory database which can store a multitude of objects. Domains contain all the objects that exist in the network. Each domain contains information on the objects that they contain. In Active Directory, domains are considered the core unit in its logical structure. Domains in Active Directory actually differ quite substantially from domains in Windows NT networks. In Windows NT networks, domains are able to store far less objects than what Active Directory domains can store. Windows NT domains are structured as peers to one another. What this means is that you cannot structure domains into a hierarchical structure. Active Directory domains on the other hand can be organized into a hierarchical structure through the use of forests and domain trees. An Active Directory domain holds the following: • Logical partition of users and groups • All other objects in the environments In Active Directory, domains have the following common characteristics: • The domain contains all network objects • The domain is a security boundary – access control lists (ACLs) control access to the objects within a domain.