Security Planning and Design

Migrating from Windows NT to Windows Server 2003 presents considerably different challenges in security planning than if you are migrating from Windows 2000, chiefly because if you are at Windows 2000, you probably already migrated from Windows NT and resolved security issues at that point. This section focuses primarily on a Windows NT-to-2000 migration, although there will be notes about security features that are different in 2003, such as the Kerberos cross forest trust.

Security Groups

Windows 2000 introduced two new security groups: universal groups and domain local groups . Other groups, such as built-in and global groups, have been around since Windows NT, but Windows Server 2003 does not introduce any new classes of groups. This section is not intended to educate you on the details of these groups, but how security requirements should be specified in the AD design document. The most significant change in Windows 2000 or 2003 security groups from Windows NT security groups is the addition of universal and domain local groups.

When you create universal groups, as Table 5.5 indicates, you can include accounts, global groups, and other universal groups from any domain in the forest. This gives the Administrator a great deal of power and flexibility in creating groups with forest-wide scope. Universal groups are only available in Windows 2000 native mode domains and in Windows Server 2003 domain functional level domains. Only GC servers can enumerate universal group membership because only GCs know about all objects in all domains in the forest.

Table 5.5. Security Group Comparison

Universal Groups	Local Groups	Domain Local	Global
Can contain members from any domain in the forest: Users, computers, printers, contacts Global, universal groups	Can contain accounts; domain local groups from the same domain; global groups, and universal groups from any domain in the forest (mixed or interim Domain functional level).	Can contain accounts, global groups, and universal groups from any domain and other domain local groups from the same domain (native mode).	Can contain accounts and global groups from the same domain (native mode only).
Can be assigned permissions from any domain in the forest.	Can be assigned permissions only on the computer it is defined on.	Assigned permissions only in the domain it is in.	Assigned permissions in any domain within the forest.
Available in Windows 2000 and 2003 native mode domains only (not Windows 2000 mixed mode).		Windows 2000 and 2003 native mode domains.
Can be converted to domain local. Can be converted to a global group if it doesn't contain other universal groups as members.		Can be converted to universal if it doesn't contain any other domain local groups.	Can be converted to universal if it's not a member of another global group.

note

Windows Server 2003 provides additional choices in GC authentication with the Universal Group Membership Caching feature. This feature is described in detail in Chapter 1 and later in this chapter in the "GC Server" section. This feature allows a user 's universal and global group membership to be cached by a local DC, which contacts the GC on behalf of the user. This provides performance improvement for users in sites that have a DC server, but not a GC server.

The domain local group is seen by all machines in the domain. This gives you the capability of assigning a local group to a resource without having to create it on every single computer in the domain. Domain local groups, like universal groups, are only available in Windows 2000 native mode domains and in Windows Server 2003 native mode (Windows Server 2003 Domain functional level) domains.

tip

Chapter 9 of Gary Olsen's Windows 2000: Active Directory Design and Deployment (New Riders, 2000) and Chapters 1 and 5 of the Jan De Clercq and Micky Balladelli book Mission Critical Active Directory (Digital Press, 2000) provide a thorough description of the various security groups available in Windows 2000. These definitions apply for Windows Server 2003 as well.

Table 5.5 is a good summary of universal, local, domain local, and global groups.

When migrating from Windows NT 4.0, it's imperative that you make a comprehensive list of all groups defined in the Windows NT domain(s). You might be surprised to find out how many groups are defined and how few are used. In the county government case study noted previously, it had a very small staff of users, but the security group listing was several pages long. A chart such as that in Table 5.6 helps map the old groups to the new Windows Server 2003 designations and identifies groups that should be eliminated. Remember, the migration is a good opportunity for a house cleaning of groups. This chart will come in handy when you use the migration tools described in Chapter 3, because they allow you to define the groups to be eliminated and not migrated.

Table 5.6. Group Migration Mapping

Group Name and Description	Scope (Windows NT)	Scope (Windows 2003)
DEVGG : global group, developers	Global	Eliminated
PRN-LG1 : printers local group1	Local	Domain local
ITS-GG : global group, IT staff	Global	Universal (rename to ITS-UG)
Domain users	Global	Global

Role Based Security

Role-based security is a common sense approach. Traditionally, users were assigned security permissions based on their job titles. Role-based security is applied based on the user's job function. Using the group scopes described in the previous section and the user job functions, you can create a map such as that shown in Table 5.7. You can use the following list to help define these roles; of course, you will probably be able to identify other roles.

• Identify specific tasks that will need to be performed, such as creating users, changing passwords, starting and stopping services, and managing and creating print queues. Identify tasks that are domain- and OU-centered.

• Identify the permissions that are required to perform those tasks.

• Identify specific job functions such as OU Admin, Domain Admin, Enterprise Admin, Desktop Support, Print Operators, Backup Operators, and so forth.

• Map each job function to the required permissions to perform the tasks that are associated with that function.

Table 5.7. Role-Based Security Matrix

Task	Permissions Granted	Function: Domain Admin	Function: Printer Operator	Function: OU Admin
User Acct Control	Create User	Yes	No	Yes “ for OU
User Acct Control	Change Password	Yes	No	Yes “ for OU
Print Que Mgt	Create Print Que	Yes	Yes	Yes “ for OU
Print Que Mgt	Clear Print Que	Yes	Yes	Yes “ for OU

After these definitions are made, create a global group for each job junction identified, and add the members with that job function to the group. Create a domain local group and apply the appropriate permissions. Add the global group created for the function to the domain local group.

note

Additional information on role-based security is found in Microsoft's whitepaper "Best Practices for Delegating Active Directory Administration" at http://www.microsoft.com/downloads/details.aspx?FamilyID=631747a3-79e1-48fa-9730-dae7c0a1d6d3&DisplayLang=en.

NTFS and Share Permissions

NT File System (NTFS) and share permissions should be mapped out in a form using a table format, for example. This table identifies each directory and the permissions granted to each group. You also should develop a strategy for defining share and NTFS permissions. For instance, because share permissions are less granular and less secure than NTFS permissions, a common strategy is to leave share permissions open and then restrict NTFS permissions. This strategy should also take into account applications that might have their own requirements. You must thoroughly test user access to appropriate data ”both gaining access to data they are permitted to access, and being denied access to data they are not permitted to access.

tip

The NIMDA virus has changed the way share permissions are granted. Many security books and whitepapers written before NIMDA advocate granting the Everyone group Full Control permissions to a share. In fact, Windows NT and Windows 2000 shares are automatically created granting Everyone the Full Control privilege. However, doing so will cause an infection of the virus fairly quickly. I have seen some companies where merely creating a default share in Windows 2000 caused a NIMDA infection within minutes. Windows Server 2003, in an attempt to reduce the potential impact, now creates shares with the Everyone group granted Read permission by default. Take this into consideration when planning share and NTFS permissions. See http://www.microsoft.com/technet/security/bulletin/MS00-078.mspx for more information on the NIMDA virus.

Computer Security Templates

Computer security is determined by the security template used. These templates are stored in %systemroot%\security\templates and contain security settings for basic, secure, and high secure conditions. Although some are applied by default, the Administrator can import them into any Group Policy. They are intended merely as an aid to the Administrator and should not be considered a perfect answer. Windows 2000 contains 12 default security templates:

• Basicdc.inf : Basic security for DCs.

• Securedc.inf : Medium-level security for DCs.

• Hisecdc.inf : High-level security for DCs.

• DCsecurity.inf : Default security settings for DCs.

• Basicsv.inf : Default template used for servers that are not DCs.

• Basicws.inf : Basic security for workstations.

• Securews.inf : Medium-level security for workstations.

• Hisecws.inf : High-level security for workstations.

• Compatws.inf : Relaxed security settings to allow legacy applications to run.

• Setup Security.inf : Default security settings.

tip

The Setup Security.inf template should never be modified. This template can be used to apply the default security settings to a GPO. Note also that this should not be accomplished by editing the GPO, but by using the Security Configuration and Analysis snap-in. For more information, see "Best Practices for Security Templates" in the Windows Server 2003 online help.

In addition, you can create your own template by creating a GPO, modifying the security settings, and then exporting the settings into an INF file. In the Group Policy Editor, go to Computer Configuration\Windows Settings, right-click on Security Settings, and select Export Policy. Save to the %systemroot%\security\templates folder, and the templates will be easy to import to other GPOs. Table 5.8 provides a matrix of the security settings for each of these templates in Windows 2000.

Table 5.8. Security Settings

Filename	Account Policies			Local Policies
	Pass word	Acct Lock-out	Kerberos	Audiing	User Rights	Security Options	Event Log	Restricted Groups	System Services	Registry	File System
Basicdc.inf						Y	Y			Y	Y
Securedc.inf	Y	Y		Y		Y	Y
Hisecdc.inf	Y	Y		Y		Y	Y
Basicsv.inf	Y	Y				Y	Y		Y	Y	Y
Basicwk.inf	Y	Y			Y		Y		Y	Y	Y
Compatws.inf								Y		Y	Y
Securews.inf	Y	Y		Y		Y	Y	Y
Hisecws.inf	Y	Y		Y		Y	Y			Y	Y

Windows Server 2003 has only nine of these templates, including compatws.inf, DC security.inf, hisecdc.inf, hisecws.inf, iesacls.inf, rootsec.inf, securedc.inf, securews.inf, and setup security.inf. The DC security.inf template is applied to DCs during the DCPromo process. The rootsec.inf template, new to Windows Server 2003, applies root permissions to the root of the system drive. More information on these templates is available in the Windows Server 2003 online help under Predefined Security Templates.

Account Security

Account security consists of password policy, account lockout policy, and Kerberos policy. You can implement account security by applying Group Policies. Just as in Windows 2000, you can apply account security only at the domain level in Windows Server 2003. This is a very important concept. These settings are located under Computer Configuration\Windows Settings\Security Settings\Account Policies and include password policy, account lockout policy, and Kerberos policy settings. This means that settings in any of these areas apply to objects only if they are applied in a GPO at the domain level. They cannot be applied at the GPO level. This means, for instance, that if you have a corporate password policy that defines the minimum password length as eight characters , you must define that in a GPO that is applied at the domain level. Further, if you have a multiple domain structure, it must be defined at the domain level for each domain. Note also that you can define these settings in GPOs that are applied at the OU level, but they will never take effect.

For instance, if you define a GPO called Security at the domain level and define the minimum password length to be eight characters, and an OU Administrator creates a GPO called OUSecurity and defines the minimum password length to be five characters, the effective setting for the users will be eight characters, even without setting the No Override option.

Security settings follow the same rules as other settings if multiple GPOs are at the domain level that defines security. These GPOs are listed in the Group Policy Editor in a list, as shown in Figure 5.30. The GPOs are processed bottom to top in the list. Thus, the GPO at the top of the list has highest priority because it follows the last writer wins rule. In the example in Figure 5.30, if the Administrators policy has password length set to ten, the accounting policy has it set to eight, and the default domain policy has it set to five, the effective policy will be five because the default domain policy is highest in the list and it's the last one processed (it overrides the others due to the last writer wins operation).

Figure 5.30. Multiple GPOs in the domain.

tip

Account policies cannot be applied from OU-based GPOs, only from domain-based GPOs. Although they can be defined in the GPO template, they will not be applied.

Account Security and DCs

One of the most important things for you to note in GPO design is that DCs just act differently when applying security. A good example is a customer who complained that he had defined the account security settings in the default domain policy at the domain level to have a minimum password length of 6 and retain a history of 15 passwords. However, when his users tried to change their passwords, they get a notification that passwords must be 10 characters and it retains a history of 6 passwords. We looked at the local security database (sdb) on a test client and it indicated the effective setting was a length of 6 and history of 15. We ran GPResult from an XP client (GPResult is built-in to 2003 and XP), and it indicated that the applied security settings were 6 and 15. Yet when we attempted to change the password, we got a message saying the settings were 10 and 6. We then discovered that logging in to the client with a local account allowed us to change to a 6-character password. Logging in to a domain account gave us the other settings of 10 and 6. We eventually discovered that the client had blocked inheritance on the DCs OU because it didn't want their desktop lockdown policies to apply to DCs. Because DCs get their security settings from the domain GPO like everyone else, this blocked them from getting the correct security settings of password length = 6 and history =15. Prior to setting the block inheritance option, the security policy had settings defining password length = 10 and history = 6. Those settings were written into the local sdb of each DC. Because that is the only security the DCs could see and the DCs actually apply their security to clients they authenticate, the clients were getting the DC's version of security, rather than what was defined at the domain level.

The important points here are to understand this scenario that shows how DCs determine security policy, and remember to not set the block inheritance option at the DC's OU.

Account Lockout

Perhaps one of the most frustrating issues in Windows 2000 Security is that of account lockout. Account lockout is a security feature that permits the Admin to have an account locked out (deny login privileges) when a bad password has been attempted for a certain number of tries . Although intended to prevent hackers from easily guessing account names and passwords, it becomes a big help desk issue for legitimate users who get locked out, typically during a password change operation. The issue is complicated by replication latency between the DC that the help desk technician changes the password on and the DC that authenticates the user.

Account lockout became such a huge issue at Compaq prior to the HP merger that scripts were run nightly to reset accounts and others were developed to be triggered by the user selecting an option in an automated phone message.

Microsoft made the claim at the release of Windows 2000 SP3 that the account lockout issue was solved , but it's still a problem area. Not to say anything is particularly broken or a bug that should be fixed, but it's a problem Administrators have to deal with. It is important to understand this issue and develop account lockout strategies accordingly .

Account lockout is implemented as a security policy at the domain level or for local user accounts. Three settings comprise account lockout policy, as shown in Figure 5.31:

• Account Lockout Threshold : The number of failed logon attempts (range 0 to 99,999) before the user account is locked out. The lower the number, the more secure you are from hackers guessing the password; however, low numbers also increase calls to the help desk. Microsoft recommends 10, which makes account lockout a little more tolerant. After an account is locked out, it cannot be used until reset by an Administrator or until the Lockout Duration period has expired . A value of 0 prevents the account from being locked out.

• Reset Account Lockout Counter : The number of minutes (range 1 to 99,999) after a failed logon attempt before the failed logon attempt counter is reset to 0. A lower number here makes it less secure, but makes the user wait longer to reset the password without calling the help desk to have the account reset. If the Account Lockout Threshold is defined, the reset counter value must be less than or equal to the Account Lockout Duration value.

• Account Lockout Duration : The number of minutes (range 0 to 99,999) that an account remains locked out before it is reset and becomes unlocked. A setting of 0 causes the account to remain locked out until manually reset by an Administrator.

Figure 5.31. Account Lockout Policy settings in the GPO.

tip

Attempting to set values for the Reset Account Lockout Counter or the Account Lockout Duration that violates the interdependency rules noted here will cause a pop-up message indicating what the value must be set to. You cannot set them to incompatible values.

In addition, features are built in that prevent you from defining settings that are incompatible with these rules. For example, in Company.com, I configured the Account Lockout Duration to 60 minutes. A pop-up message, shown in Figure 5.32, informed me that the Account Lockout Threshold and Account Lockout Duration would be changed to 5 attempts and 30 minutes, respectively.

Figure 5.32. Informational message indicating that Account Lockout Threshold and Reset Account Lockout Counter values are changed based on the setting of 60 minutes defined for the Account Lockout Duration.

Microsoft doesn't go out of its way to tell you that resources, such as shares or interactive sessions on multiple computers using those credentials, cause account lockout policy to be such a problem. For instance, if you are logged in with a single account to a Terminal Server session on a server in the lab with an interactive logon to your laptop and have a VPN connection from home, and you change your password from your laptop without logging the other sessions off, your account soon will be locked out. This has never been an issue in Windows NT 4.0 domains, so what's so new in AD that could cause this issue? Kerberos. When users log on from Kerberos-capable clients (Windows 2000 and greater) and authenticate against an AD domain, the Kerberos protocol is used instead of the NTLM protocol (as was the case in Windows NT 4.0). However, to tighten security in the Windows world, the Kerberos credentials expire after a defined period of time (maximum lifetime for a user or Ticket Granting Ticket is ten hours by default), which causes a machine to re-evaluate a user's credentials over time against an AD DC (Kerberos Distribution Center). If the password has been changed without logging on and off, the credential validation takes place with the old password and thus soon locks out the account.

In addition, having shares mapped using those credentials will have the same effect. Most likely, in our network, if I change my password and haven't logged off all sessions and disconnected all shares using that account, it will be locked out within about 15 minutes. Before changing my password, I have to go through all my home network computers, lab servers, laptop, and desktop to make sure I'm logged off from all Terminal Server, Remote Desktop, and interactive sessions, as well as to make sure all the shares are disconnected. Once it took me three days to find all the sessions I had going, because I tend to not log out of the lab machines to save time when testing.

Let's follow a couple of scenarios to see how this works. Consider the configuration shown in Figure 5.33. User Nancy in San Jose forgets her password. The incorrect password is attempted at the authenticating DC in San Jose, SJC-DC3. Because the password is incorrect, the password request is sent to the PDC Emulator, ATL-DC1, in case the password was changed and this DC isn't aware of it. This fails and Nancy gets the invalid username or password error. She tries five times, at which time her account is locked out by the PDC by setting the lockoutTime on the user account, and SJC-DC3 locks it out as well. The PDC now replicates the lockoutTime to all DCs, informing them of when the account was locked out so they can make the comparison for the Account Lockout Duration time.

Figure 5.33. Scenario for account lockout after password change.

Nancy could wait for the Account Lockout Duration period of three hours to expire before trying again or she could call the help desk to have it reset. However, suppose Nancy has to drive to San Francisco for a meeting. She connects to the company network and attempts to log in again two hours after the account was locked out. Here, the authenticating DC is SFO-DC8, which hasn't had the lockout message replicated yet. It refers the request to the PDC and the client gets the account lockout message.

Now Nancy calls the help desk technician who resets the password and then expires the password, forcing Nancy to change it again when she logs in. The Admin, however, is in Atlanta and he resets the password on ATL-DC1. The account reset is replicated urgently, but the password change is not. Before replication makes it to SFO-DC8, Nancy tries the new password. The request is passed to the PDC who authenticates it, but SFO-DC8 prompts Nancy to change the password. Because SFO-DC8 doesn't know about the password set by the Admin, it gives Nancy a failure and she might retry it until it locks out again. To prevent this, the Admin can change the password on the user's local DC, in this case, SFO-DC8.

Microsoft created a couple of tools that help in this matter. One, the acctinfo.dll, registered on each DC, provides the Additional Account Info tab in the user account attributes dialog box, as shown in Figure 5.34. Note the Set PW on Site DC button at the lower left of the dialog box. Assuming the subnet/site mapping is correct, this will force the change to take place initially on a DC in the user's site. Note that Site Affinity is a function of the workstation, so the reset takes place at the site where the user's workstation exists. In the previous example, Nancy's normal "home" site is San Jose, but because she uses DHCP, when she connects to the network in San Francisco, her laptop's Site Affinity is San Francisco so the authentication is to SFO-DC8.

Figure 5.34. The Additional Account Info tab available with acctinfo.dll.

Another scenario could be that Nancy successfully changes her password, but forgets that she has several drives mapped to shares using the old credentials and the account is locked out. She calls the help desk; they reset the account and password. Nancy logs in, changes the password, and awhile later the account is locked out. Nancy sees the account is locked out when she tries to use Outlook, map a new share, or perform any other operation requiring her to specify credentials. The message that the account is locked out is a clear indication of the problem. Nancy would have to make sure all drive mappings are disconnected and all Terminal Server and interactive logon sessions are logged off ”except the one used to change the password.

Another tool Microsoft has provided is the LockoutStatus.exe utility. Figure 5.35 shows the features of this tool. Note that it identifies each user, the account's locked status, the bad password count, and so on. This gives you the ability to monitor the account lockout status. You also can see in the figure that the user's current password settings are displayed. This user is in a test domain with a password that doesn't expire, which is why the numbers in this example, such as current password age, are so high.

Figure 5.35. The LockoutStatus tool monitors the current status of bad password count and other parameters for managing account lockout.

note

For more information about account lockout issues, you can download the "Account Lockout Best Practices" whitepaper at http://www.microsoft.com/downloads/details.aspx?FamilyID=8c8e0d90-a13b-4977-a4fc-3e2b67e3748e&DisplayLang=en. The AcctInfo.dll and LockoutStatus.exe tools can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyID=7af2e69c-91f3-4e63-8629-b999adde0b9e&DisplayLang=en.

Microsoft Software Update Service (SUS) and Windows Update Service (WUS)

At this writing, SUS has been Microsoft's initial attempt to provide a tool to automate the download and application of security patches, service packs , and other updates to servers and workstations. Currently, the new WUS has not been released.

Software Update Service (SUS)

When a SUS server is identified, the SUS software is installed. This server is configured to download from Microsoft's Windows update site periodically (default is 3 a.m. daily). The SUS is then enabled through a Group Policy, where you specify the name of the SUS server. The clients that the policy applies to download the updates periodically and either notify the user of their availability or automatically apply them (optional).

The SUS server is domain-independent . Thus, if you have several domains, you can have a single SUS server to serve all computers in all domains. You can also specify a hierarchy of SUS servers, as shown in Figure 5.36. In this example, the top-level SUS server, SUS-01, gets the downloads from Microsoft. The second-level servers, SUS-02, SUS-03, and SUS-04, download from SUS-01. Because they are located via HTTP, they are domain-independent and can be placed at convenient locations in the network for best performance in serving clients.

Figure 5.36. SUS server hierarchy.

note

You can get the SUS software for the server at http://www.microsoft.com/downloads/details.aspx?FamilyID=a7aa96e4-6e41-4f54-972c-ae66a4e4bf6c&DisplayLang=en. You should also download the "Software Update Services Overview" whitepaper from http://support.microsoft.com/default.aspx?scid=kb;en-us;810796.

Some of the features of the SUS include

• You can download from Microsoft or other SUS servers.

• The Administrator can configure the download schedule.

• The Administrator can configure patches, service packs, and so on to be automatically applied at the client or to require Administrator approval before deploying to the client.

• Clients can be configured to automatically install the updates or to notify the user, like the normal update service does.

• Clients can be configured to automatically reboot when the updates are applied or to be rebooted manually. (Thus, you can fully automate SUS so that patches are automatically downloaded from Microsoft, distributed to the clients, installed, and the clients rebooted without manual intervention ”or with intervention as desired.)

• SUS works across domain boundaries using the HTTP service.

• The SUS server can be managed from any computer via a browser by specifying the server name in the format http:// servername /SUSAdmin , where servername is the name of the SUS server.

• Works on DCs or servers.

• It's free!

Some of the drawbacks include

• It's free (you get what you pay for).

• There's no good way to determine whether the updates worked or not. You have to drill down in the event logs of the client to determine whether they were applied.

• There's no way to report which clients have been updated. You can put the patches on the machines, but you don't know whether they have been applied.

• Still requires a lot of manual intervention. It's still a long way from what Administrators really need and have been begging for ”an automated way to determine vulnerabilities in the system and to apply the patches proactively.

tip

Microsoft has provided the SUS 1.0 ADM file for SP1: http://www.microsoft.com/downloads/details.aspx?FamilyID=d26a0aea-d274-42e6-8025-8c667b4c94e9&DisplayLang=en. This ADM is an add-on to Group Policy that permits additional administrative control over SUS clients running SUS SP1.

Although the SUS made life somewhat easier in patch management, it's not the answer Administrators are looking for. The better solution is the WUS, which is in beta at this writing.

Windows Update Service (WUS)

Because this product is in beta at this writing, there is not a lot of detail on how it works or actual deployments. I have summarized some of the features that Microsoft is promising . Make sure you check Microsoft's Web site for details after WUS is released. One big change is the addition of the Microsoft Update (MU) service. SUS used the Windows Update (WU) service, but this service only included Windows OS updates. MU hosts services that host all Microsoft updates for all Microsoft products. Note that WUS get updates from MU.

The WUS takes a big step in enterprise patch management with the following features:

• An SQL (Structured Query Language) database or MSDE (Microsoft Data Engine) holds all data other than content.

• Uses .NET Framework.

• Scriptable through exposed APIs (Application Program Interfaces) for server and client.

• Manages all Microsoft product patches ”not just Windows.

• Can configure to manage other products' patches.

• Can build hierarchy of WUS servers.

• Easier to configure than SUS.

• WUS Client Automatic Updates are controlled by policy.

• Built-in security features.

• Validates all downloaded content for Microsoft certificates.

• All content download locations are secured by ACLs.