13.5 Providing Security for Domains

     

Now that we have a good understanding of Active Directory, the infrastructure components , default security, and how to apply security, we are going to investigate each component individually, including how to provide security for it. We start with the domain. The domain has many areas that need to be secured to ensure that an attacker has few areas to focus on. Some of these focus areas could fall under domain controllers, since the objects are stored there, but these are really domainwide considerations, not just domain controller considerations.

13.5.1 Users, Groups, and Computers

As we have seen in earlier chapters, the SID is the mechanism used by the operating system to control and manage the security principals. Remember, the security principals include user , group , and computer accounts. You will want to protect all security principals above all other objects, because it is the security principals that are given access to resources. If an attacker can access a resource as an account that has elevated privileges or administrative privileges, there is almost no way to stop him from doing as he pleases with that resource.

The following simple rules will help you protect user, group, and computer accounts.

13.5.1.1 Clean up stale accounts

If an account ( especially a user or computer account) has not been used in a while, be sure to have a process to remove it from the Active Directory. The new feature to run Saved Queries in the Active Directory will help you quickly find stale accounts. For user accounts, you can query Disabled accounts and accounts that have not logged on for x days. For computer accounts, you can query Disabled accounts and quickly delete those that are no longer needed. The Saved Queries node is the first one listed when you open Active Directory Users and Computers. To create a new query, like the ones mentioned, right-click on the Saved Queries node and then click New Query. The new window will prompt you for the name for your new query. After you insert a new name for your query, click the Define Query button, which will display the Find Common Queries window shown in Figure 13-6.

Figure 13-6. Saved Query interface used inside Active Directory Users and Computers
figs/sws_1306.gif

13.5.1.2 Protect user accounts

It seems obvious, but the passwords for user accounts are rarely protected to the level that they should be. In protecting the user accounts, make sure that the password complexity is configured in the Password Policy. Windows 2000 did not require this, but Windows Server 2003 Active Directory has this as the default, if the domain is installed new. Another step to protecting user accounts is to have a safe and secure process for users to recover from lost passwords. If the process is simply to have a user call with her username to ask for a new password, the door is left wide open for "social engineering." Implement a process that requires some other form of user verification, and then make sure the password is securely sent to the user and that the old password is changed as soon as the user logs in.

13.5.1.3 Use proper group nesting

The group "mantra" has been around since the early Windows NT days: Users go into Global Groups, Global Groups go into Local Groups, and Local Groups are given permissions .

The reason for this structure is really multifold. First, it provides a process that is easy to follow and straightforward to troubleshoot. Second, it allows domain administrators to control the Global Groups on the domain controllers and local administrators of the servers to control the Local Groups. Finally, it repels the worse configuration of all, which is to place a user account into a Local Group directly! The reason this is so insecure is because it is almost impossible to track down memberships in Local Groups.

For example, let's assume that you have a user account named Derek. Derek is an administrator who is given free reign like most domain administrators. So, Derek places his user account in almost every Local Group on every file server in the company. There are 5000 file servers in your company, each with an average of 50 Local Groups. Today, Derek is leaving the IT administration role to become a director. Your company has intelligently restricted directors from having administrative access. However, with Derek shotgunned out to all the Local Groups, he is in essence an administrator with the access that he possesses. If the mantra had been followed, Derek's user account could have been reassigned to different Global Groups, removing the administrative access, giving him the director access that he needs.

13.5.1.4 Protect service accounts

We all know that a service account is responsible for running a service, which normally spans multiple computers. Services such as backup/restore, Exchange 5.5, SQL, and so on need to have access to multiple computers and are given elevated privilege on these computers. Some key configurations need to occur for these accounts. First, it might be a good idea to provide a dual-user password for the critical service accounts. This will require that at least two administrators be present, to change or log on as a service account. Another good idea for these accounts is to give them a very long and complex password. It is not uncommon to provide a password with more than 20 characters for a service account that controls Exchange or SQL. Finally, it is a good practice to configure the Logon Workstations attribute for these service accounts, as shown in Figure 13-7.

Figure 13-7. Logon Workstations restriction setting for user accounts
figs/sws_1307.gif

To configure the Logon Workstations attribute for a user account, follow these steps:

  1. Open Active Directory Users and Computers.

  2. Right-click on a user account, then click on the Properties menu option.

  3. Select the Account tab.

  4. Click on Log on To.

  5. Select the The Following Computers radio button in the Logon Workstations window.

  6. Type the name of the workstation in the Computer Name text box, then click the Add button.

  7. Repeat step 6 until all computer names are added.

  8. Click the OK button in the Logon Workstation window.

  9. Click the OK button in the user Properties window.

This option is successful only if NetBIOS is enabled on the network connections, which is almost a requirement for most networks. This will allow the service accounts to log on successfully only to the computers they need to, which will prohibit an attacker from trying to log on as one of these accounts. If you have older Windows 9x and Windows NT computers, they too can be listed for this configuration.

Beyond the preceding security concerns and suggestions for locking down service accounts are some additional ideas that can help protect these accounts: First, do not use the same service account across services. This will expose more than just one service at one time if the username and password are compromised. Next, these accounts should not be allowed to have nonexpiring passwords. These user accounts should be as restricted as (if not more restricted than) other user accounts. This will require a documented and regular procedure to change the password on each service account. Finally, use the Network Service account instead of a user account if possible. This account is designed to be used as a network service, functioning on the network as the computer on which it is configured.

13.5.2 Administrative Groups

The domain is full of default, built-in groups. These groups give immediate privilege access to domain controllers, services, accounts, and more. The membership in these groups needs to be monitored and limited to reduce exposure to attacks and vulnerability. Some administrative type groups have more privileges than others. The most essential groups that reside on domain controllers that you need to be concerned with for every domain include:


Domain Admins

The only member of this group to begin with is the Administrator user account. The members of this group can administer all domain controllers for the domain, as well as all computers that are members of the domain. The reason this occurs is that the Domain Admins group is automatically placed in the local Administrators group for every computer that joins the domain.


Administrators

The purpose of this group is to allow the members to control the domain controllers for this domain. By default, the only member is the Administrator. This group has a smaller scope of influence than the Domain Admins group, since the members in this group can administer only the domain controllers, not every computer in the domain.


DNSAdmins

The purpose of this group is to allow the members to control the DNS servers, both standalone and Active Directory-integrated.


Cert Publishers

The members of this group are allowed to publish certificates to Active Directory.


DNSUpdateProxy

The members of this group are able to perform dynamic updates to DNS on behalf of other clients . The only members in this group should be DHCP server computer accounts.


Pre-Windows 2000 Compatible Access

This group is designed to provide backward compatibility. The members of this group are allowed Read access on all users and groups in the domain.

Two forestwide groups, Enterprise Admins and Schema Admins, will be discussed in the "Providing Security for Forests" section later in this chapter.


Other groups are listed in a default Active Directory domain but don't have the widespread notoriety and vulnerabilities as these groups. Membership in these groups should be kept to a minimum, and all members of the group should be aware of the privilege that is given to them, so they can protect the account while logged in to the domain.

13.5.3 Administrator Accounts

The domain has one built-in Administrator account, but this section will focus on all potential administrators that are given elevated privileges. First, I want to focus on the real Administrator account. This account needs to be protected! There is no other way to say it. This means you should consider the following points for this account:

  • Don't allow any user to use the account for logon.

  • Don't use this account as a service account.

  • Rename the account (most use a common name, to have it fit in with the other accounts).

  • Give this account a special, complex password (preferably more than 15 characters, using characters from each possible character range in the password, maybe dual administrator so that it takes two administrators to log on with the account).

  • Change the Description for this account.

  • Create a bogus Administrator account (make sure the description of this account is the same as the original Administrator account).

Other administrator accounts will have to be created to allow the IT staff to perform their jobs, in addition to their normal user accounts. These additional accounts need to be protected as well. Here are some considerations for these accounts:

  • Allow this account to be used only for administrative tasks .

  • Don't use any of these accounts as a service account.

  • Ensure these accounts have lengthy, complex passwords.

  • Consider a company policy requiring that these admin accounts change their passwords more frequently than the normal user password policy demands. Unfortunately, you cannot currently enforce this with Group Policy but can audit the password ages with scripts and management tools.

The key here is to not allow the administrators to use this account for their routine duties as an employee. When they check their email, write memos, surf the Internet, and so forth, they should do so through a typical user account, not an account with elevated privileges.

Finally, some administrative accounts are not placed in Admin groups but are rather given administrative privilege through user rights or delegation. These accounts include service accounts and those for server administrators and helpdesk personnel. In addition to accounts that have administrative privileges, accounts that are given elevated privileges to control applications should be protected. These accounts should be protected in these ways:

  • Allow these accounts to be used only for administrative tasks.

  • Ensure these accounts have complex passwords.

13.5.4 Object Security and ACLs

We saw in Chapter 7 how users are able to access resources. It can't be stated strongly enough how important this process is to the overall security of your domain. If a user, group, or computer account is compromised by an attacker, your entire network could be in jeopardy. Remember, when a user authenticates, he receives a token that contains the user SID, group SIDs, and user rights.

To see the contents of a token, just run the whoami /all command on any computer. You will get results similar to those shown in Figure 13-8.

Figure 13-8. Contents of a user token displayed by running whoami /all
figs/sws_1308.gif

Since the output of the whoami command shows the SIDs for the user and group accounts, you can investigate the SIDs, using a tool such as user2sid or sid2user , to verify that these SIDs should be on this user's token. This falls into the auditing function that should be performed by both the IT staff and security auditing staff on a regular basis.

13.5.5 Example: Configuring Domain User Accountsto Access Resources

Derek is the domain administrator responsible for group management and Active Directory administration. Yvette has been hired to run a new HR file-based database that will run on an existing server named FS1. Derek has not created the new user account for Yvette, but he will be receiving the paperwork from the HR manager soon. Derek needs to configure the user account, groups, and resource permissions to give Yvette Full Control access to the database.

To set the stage completely, it is important to understand the structure of the Active Directory forest. The domain is configured in Windows 2000 mixed functional level, however, there are no Windows NT BDCs. FS1 is a member of the domain and Derek has administrative privileges to FS1.

Derek would follow these steps to properly configure the access for Yvette:

  1. Open Active Directory Users and Computers.

  2. Right-click on the domain node, then click the New Organizational Unit menu option.

  3. Right-click the HR OU, then click the New User menu option.

  4. Type in a password that meets the password complexity for the domain, confirm the password in the Confirm text box, then click the Next button.

  5. Click the Finish button.

  6. Right-click on the HR OU, then click the New Group menu option.

  7. Right-click the Yvette user account, then click the Add to a Group menu option.

  8. Make sure the domain name is listed in the From This Location text box. If it is not, click the Locations button, select the domain name from the Locations window, then click the OK button.

  9. Type HR_DBM in the "Enter the object name to select" text box, then click the OK button.

  10. On FS1, click Start Control Panel.

  11. In the Control Panel, double-click the Administrative Tools icon.

  12. In the Administrative Tools window, double-click the Computer Management icon.

  13. Expand the Local Users and Groups node in the Computer Management window.

  14. Right-click on the Groups folder in the right pane, then click the New Group menu option.

  15. Type DB1_FullControl into the Group Name text box.

  16. Click the Add button.

  17. Make sure the domain name is listed in the From This Location text box. If it is not, click the Locations button, select the domain name from the Locations window, then click the OK button.

  18. Type DB_DBM into the Enter the object name to select textbox, and then click the OK button

  19. Click the Create button.

  20. Click Start My Computer.

  21. Double-click the C:\ option.

  22. Right-click on the HRDatabase folder, then click Properties menu option (this is the folder containing the new database file).

  23. Select the Security tab.

  24. Select the Authenticated Users in the Group or User Names window, then click the Remove button.

  25. Click the Add button.

  26. Make sure the computer name is listed in the From This Location text box. If it is not, click the Locations button, select the computer name from the Locations window, then click the OK button.

  27. Type DB1_FullControl into the Enter the object name to select textbox, then click the OK button.

  28. Click on the Full Control checkbox under the Allow column, then click the OK button.

This is the typical method to configure groups within a Windows domain. Note that the user account and global group are located on the domain controllers, whereas the local group and ACL for the resource are located on the member server. With this configuration, Yvette will have Full Control access to the new database, as long as she logs on to the domain.

13.5.5.1 Configuring correct user group nesting structures

If Derek were to convert the domain to Windows 2000 native functional level or higher, he could and should use a different group strategy. Remember that when a domain is in mixed mode, the Domain Local Groups are not visible to the domain members; they are visible only to the domain controllers (they act like Local Groups did on Windows NT 4.0 domain controllers). The new group strategy would bypass the Local Group on FS1 and would take advantage of the centralized administration capabilities of Domain Local Groups in Active Directory. Derek would follow these steps for the domain with this configuration (the first 11 steps from the preceding process are the same, so we will start where the Domain Local Group is created):

  1. Right-click on the HR OU, then click the New Group menu option.

  2. Right-click the HR_DB1_FullControl group account, then click the Properties menu option.

  3. Select the Member Of tab.

  4. Click the Add button.

  5. Make sure the domain name is listed in the From This Location text box. If it is not, click the Locations button, select the domain name from the Locations window, then click the OK button.

  6. Type HR_DBM in the "Enter the object name to select" text box, then click the OK button.

  7. On FS1, click Start My Computer.

  8. Double-click the C:\ option.

  9. Right-click on the HRDatabase folder, then click Properties menu option (this is the folder containing the new database file).

  10. Select the Security tab.

  11. Select the Authenticated Users in the Group or User Names window, then click the Remove button.

  12. Click the Add button.

  13. Make sure the domain name is listed in the From This Location text box. If it is not, click the Locations button, select the domain name from the Locations window, then click the OK button.

  14. Type HR_DB1_FullControl into the Enter the object name to select textbox, and then click the OK button

  15. Click on the Full Control checkbox under the Allow column, then click the OK button.

The benefit of using this group structure is that now all groups are located in Active Directory. Also, if DB1 is ever duplicated for load balancing or testing purposes, there is no need to configure a new Local Group on the new server; rather, the ACL of the resource just needs to be configured with the Domain Local Group. This can reduce the overall number of groups that are spread throughout the IT infrastructure, if enough design is mixed in with the implementation. Also, all groups are centralized, which makes administration a bit easier.

13.5.6 Account Policies

One of the most important aspects of any domain is the Account Policies that restrict the passwords for the domain users. To fully protect the domain, you must implement an Account Policy that prohibits an attacker from easily gaining access to the network. This "ease" is from either guessing easy passwords, social engineering, or even reading sticky notes attached to the monitors of users who feel this is the only way to remember their password.

From this, you can see there is a middle ground where passwords should not be too easy, or too hard. For each company, this does differ . Earlier we discussed what the default settings for the Password Policies are in Windows Server 2003 Active Directory, as shown in Table 13-2. These settings are a great place to start, but you should configure any additional settings to strengthen your security that won't force your users to start writing passwords on sticky notes. This might include longer passwords, shorter password ages, or even a custom password filter that makes the password pass a dictionary list omission before allowing it to be configured.

Account Policies for upgraded domains will retain their original settings. If you have upgraded from Windows NT or Windows 2000 Active Directory, be sure to reconfigure the Account Policies to meet at least the minimum settings established in a default Windows Server 2003 Active Directory domain, for the best security.


You can find more information on creating your own custom password filter at the following Microsoft link: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/sample_password_filter.asp.

13.5.6.1 Account Policies at the OU level

Many administrators feel that they should be able to configure the Account Policies in a GPO and link it to the OU. The goal is to have the user accounts in the OU have only the more stringent Password Policy settings configured in the GPO. However, this will fail! The reasons it will fail are logical, as well as a feature of the operating system.

As for the logic, the Account Policies are not user configurations. This means that the Account Policies configure the Computer object, not the User objects. (See Chapter 5 for details.) The Account Policies will configure either Active Directory on domain controllers or the Local SAM on computers in the domain. This last statement drives home the feature of the operating system. The only location where you can modify the Account Policies for domain users is at the domain-linked GPO. There is no other way, custom or built-in, to accomplish this. It is a feature of the operating system!

What do the Account Policies configured in a GPO linked to an OU configure, you might ask. These Account Policy settings will modify the Local SAM on the computer accounts that exist in the OU, forcing the users who log on locally to these computers to adhere to the GPO linked to the OU, not the GPO linked to the domain.

13.5.7 Trusts

To secure your trust relationships, you really need to focus on the external trusts and not be as concerned with the internal trusts. The reason for this is that the internal trusts are automatic and you can't delete them (well, if you did, you would cause severe damage).

The trusts that are a concern are any trust relationships that go outside the forest. This could be to any of the following domain types:

  • Windows NT 4 domain

  • Windows 2000 domain

  • Windows Server 2003 domain

  • Kerberos realm

When you evaluate making a trust, make sure you consider the reason the domains are not in the same forest to begin with. You will want to keep cross-domain administration to a minimum; otherwise , it can become a security issue and vulnerability. You also want to match the Account Policies in domains that trust one another. If the Account Policy in one domain is weaker than the other domain, the user accounts in the weak-password domain are vulnerable, which makes your domain vulnerable, since they have access to your domain.



Securing Windows Server 2003
Securing Windows Server 2003
ISBN: 0596006853
EAN: 2147483647
Year: 2006
Pages: 139

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net