Securing Windows 2000 Active Directory 1

Securing Windows 2000 Active Directory (Part 2) Protecting active directory’s integrity is paramount. This is the second article in the two part series that focuses on active directory security. Active directory is the windows 2000 information repository that needs to be kept very secure. Active directory has vital service dependencies such as DNS which changes the scope of what needs to remain secure. I will focus on actions that you can take in order to safeguard the active directory service.

For those that missed the first article in this series may click here to be taken to Part 1. In the next article Ricky Magalhaes will focus on the active directory process. As part of securing your active directory you need to ensure that as a contingency plan you are able to restore your active directory in event of disaster. If you would like to receive an email when the next article in this Active Directory series is released, subscribe to the WindowSecurity.com Real-Time Article Updates from our Newsletter subscriptions page).

Protect your Domain Controller Domain controllers contain sensitive data, used for domain authentication. Domain controllers therefore need to remain very secure. Ensure that only authorized personnel have access to critical servers like domain controllers. Ensure that the domain controller auto locks if left idle for more than three minutes. This can be done in the properties of the desktop under the screen saver wait option.

Using SYSKEY to secure the restore process SYSKEY can be used for additional security. SYSKEY must also be protected and should be kept in your company safe and offsite with your backup tapes if it is stored on floppy disk, if you choose to make SYSKEY a password you should update your documentation and store that in a secure location. The SYSKEY password should not be known by any unauthorized users and should be kept as secret as your administrator password.

Offline attacks. If an intruder gets hold of your domain controller it is possible for him to copy password databases to a remote machine so that later an offline attack can be run on your domain passwords. If you have strong password policies and guidelines that enforce long alphanumeric passwords it will be extremely challenging to crack your domain passwords. However as newer faster hardware and software becomes available it makes the job of cracking passwords so much

easier than it was in previous years. Some antivirus packages do not allow common password cracking utilities to run. To ensure that your users are not trying to use these malicious applications set your antivirus software to log all viruses that it finds. Good antivirus packages have a centrally managed “most recently found virus list.” Frequently inspect this list to see if your password cracking software appears there.

Fault Tolerance A second domain controller is necessary incase of the initial Domain controller failing. Bear in mind that if you domain spans across several domain controllers you should backup all of the domain controllers as a single entity to ensure completeness.

Trusts Administrators from connected domains can pose a security risk and knowing that active directory automatically creates two-way transitive trust between the forest root and the parent domain and the new domain. It maybe a good idea to limit these trusts to non-transitive “one way” trusts if you feel that remote administrators will cause a problem. Ensure that the remote administrators have no permissions on your domain and that they have not added themselves to the administrative OU.

Object Access Control Group all of your group objects in manageable units from the word go, this will result in less risk and administration. Use GPO (global policy objects) to control a computer object, workstation or stand-alone computers. A user that logs on to that computer can inherit the user rights for the GPOs. Templates and GPOs are generally the better solution when implementing a given security policy for a group or category of users.

Permissions Permissions can be seen as the control mechanism of a resource, allowing or disallowing access. Even when you have a full understanding of permissions you can find your self in a tight spot for allowing the wrong permissions to propagate. The most secure way recommended by most security experts is reapplying the permissions when moving an active directory object, permissions assigned to the local object typically move with the AD object. Typically inherited AD permissions do not move with the AD object. When an Active directory object is moved the object inherits the permissions of the destination container. It is always a better strategy to check what has happened to the permissions just to make sure, as it is not easy to keep rack of thousands of AD objects. If you have a concern and have accountability issues document and get sign off on any AD object you move. Any published service should have permissions that explicitly allow users contained in groups within your domain, make sure that no everyone group allowed permission as intruders can then try to use vulnerabilities like buffer overflows on a printer to attack your published resources.

Before You Can Modify the Schema Warning do not allow anyone other than enterprise administrators access to your schema, by default this is the case. It is essential that you do not let anyone assign an inappropriate level of control when dealing with the schema as it can result in them being able to modify objects— classes and attributes of the AD objects. Prior to using a particular PC make modifications to the schema, there are two prerequisites. • •

The computer must have a certain Registry setting added to it. The domain controller modifying the schema must be known by the other domain controllers as the one server which can currently modify the schema.

The Registry setting is mandatory to grant an extra level of administrative control over schema changes, ensuring that only authorized administrators can modify the schema. Before making changes to the registry it is highly recommended that you backup your registry. To enable a domain controller to modify the schema, type regedit and go to \HKeyLocalMachine\System\CurrentControlSet\Services\NTDS\Parameters key on the DC. Add a registry value called (Schema Update Allowed, of type REG_DWORD), and give it any non-zero, positive integer value.

Applying viewing and attributing via a batch file At times you may want to apply the security templates to multiple networked machines. By using the following command prompt utilities you will have the flexibility to…

1. 2. 3.

Automatically create, analyze and apply system security templates by using secedit.exe. Query and edit security attributes using dsacls.exe. Read security attributes from an ACL output is formatted as tab-delimited using aldiag.exe.

• •

aldiag.exe can also compare the ACL on a directory services object to the permissions defined in the schema defaults Grant effective permissions to a specific users or groups listed in the ACL.

MMC Consoles To reduce the risk of an intruder obtaining full control to your admin tools, instead of giving the junior administrators and operators full control to your active directory MMC you can create specific MMCs with limited capabilities. As a rule of thumb only give access to tools that the respective people need i.e. only give the DNS admin people access to the DNS component within the MMC.

Create a custom MMC

1.

2. 3. 4. 5. 6.

click Start then Run type mmc click ok. Add desired snap-ins and extensions from the Add/Remove Snap-ins dialog Open the Option dialog and click the Console tab Select User (or Author) mode Configure the allowable view Save the MMC console

Give the respective operator user access to the saved MMC and remember to save the MMC on a drive that has been formatted with NTFS. After saving the MMC on the NTFS drive you can assign permissions to the saved .msc file, do not allow modify or write permission only read and execute.

Using the security analysis and configuration tool The security, analysis and configuration tool is a snap-in that analyzes and configures local machine system security. Use it to provide recommendations and to resolve discrepancies revealed by the tool. There are various security templates that you can import and apply to the local machine. Test these templates on a lab machine before applying it to a production machine. To get to this tool 1. 2. 3.

click on start then click run type in MMC then click on console or file then click on add/remove snapins then click on the add button

4. find the Security configuration and analysis tool snapin then click Add. 5. Click ok till you reach back to the MMC again. 6. Now you can begin to use the Security configuration and analysis tool to import database files.

Replication Active directory replication is not predictable, this has some advantages but should not be something to rely on as a security feature. Use replication timestamps to avoid replication problems that may pose a security risk when deleting or moving an account. Use the “Replicate now” function to manually initiate the replication process. The “Replicate Now” function for each server in Active Directory Sites and Services is limited to the server pair selected from the details pane. Note: changes to a universal group will cause the entire membership list to be replicated. Replication Protocols: Sites can be replicated with either RPC or SMTP (Simple Mail Transfer Protocol). It is recommended to use SMTP for replication between sites rather than using RPC. SMTP is also preferred when crossing a firewall boundary as it is considered to be more secure compared to RPC. Replication Monitor graphically displays the replication topology of connections between servers within the same site.

Securing domain master Roles How you design you domain master roles can compromise your security. Recommendations 1. 2.

Ensure that the Schema master is protected from any sort of access because this machine is the only domain controller that can write to the directory schema. Ensure that the Domain naming master is kept under strong password policies as this machine is the only domain controller that can add or remove domains.

Note: Global Catalog queries are sent to port 3268 on the domain controller that contains the global; catalog. Typically Active Directory queries are sent to port 389, port 389 is the classic LDAP port. These ports a very vulnerable as they are very well known and are susceptible to IP floods. Remember to remove a disabled domain controller that held a schema master, domain-naming master, or RID master whose role has been seized as copies of pertinent data could still be on that server accessible to potential intruders. Hide the identity of domain controllers from external and internal networks. By doing this you are making it more difficult for intruders to attack your server. I have noticed that some organizations name their domain controllers something trivial and they install a pack of fictitious domain controllers that are part of a fictitious no business impact group that is just created to lure intruders. Such an arrangement is called a honey pot. Intruders will aim at these honey pots and attack them, this will give you enough time to know what the intruder is planning on doing and will allow you to take the necessary recourse to prevent business damage.

Auditing Auditing is a vital part of securing any system. What auditing does is it logs all attempts by adding ACEs (Access Control Entries) to the SACL (System Access Control List) of the security descriptor of the Active Directory object to be audited. If you know that some one is trying to access a resource on your domain you will then be able to decipher if an intruder is attempting malicious access to your servers or network resources. Audit events will be recorded in the computer’s Security Log in the Event Viewer. Secure the %Systemroot%\Debug folder on an NTFS drive as this folder often contains events that may be related to security. DCPromoUI.log, DCPromos.log, DCPromo.log, Netsetup.log, netlogon.log, Ntfrsapi.log, Userenv.log are all files that may contain pertinent security information.

Active directory Database Maintenance

The backup and restoring of active directory is essential when developing your organizations contingency plan and disaster recovery security policy. If anything happens to your active directory and you have a backup you will be able to restore your AD to the last state before it was backed up. In other words backup your active directory regularly. Backing up the system state of all of your domain controllers will ensure that you have a complete active directory backup. However I recommend that you backup everything on your domain controllers for a more complete backup plan. Please remember to restore regularly for if you can not restore it is futile to backup. The Restore process The restore process should be one of the most documented and pertinent part of your active directory security strategy. Non-authoritative restore will Allow administrators to mark live data as current, thus preventing the replication process from overwriting that information. Note: the administrator must know the distinguished names of objects to be restored. Therefore, it is recommended that system administrators keep an updated object map from which to restore Active Directory objects. Once the data has been restored it will not replicate to the other domain controllers. Authoritative restore will Restore the AD to its state before the last backup. Distributed services are restored from the backup and the restored data is then replicated, and when doing this the restore will overwrite live data upon replication. A reader of this article pointed out to me that when doing an authoritative restore you will be able to have the authority to overwrite data. Warning: Schema changes are permanent. It is recommended to backup AD and the schemas before making schema changes. In further articles I will detail some deeper aspects of underlying services that need to be more secure in a windows network.

Summary: After reading this article it becomes apparent that active directory does not function by itself and that there are underlying services that also need to be taken to account when backing up an active directory system. The whole system as a whole needs to be considered. This document should serve as a good basis when designing your windows 2000 active directory security strategy.