Exploring Windows 2003 Security: Overview

Back in January 2002, Microsoft launched “Trustworthy Computing,” an initiative focused on securing the Windows platform. This directly impacted the release dates of the next wave of Microsoft products (grouped under .NET umbrella), but additional months of development effort resulted in products much more secure and stable than any of their predecessors.

Features designed to offer higher levels of security are present in nearly every area of Windows Server 2003. Marcin Policht will explore these enhancements in a series of articles. This first installment provides an overview of the major changes that affect many Windows users and administrators.

This article is the first in a series that will cover these security enhancements introduced in Windows 2003 Server.

New features designed to offer increasing levels of security are present in nearly every area of the new operating system’s functionality. We will start with the ones that affect a great number of Windows users and administrators.

Default NTFS and Shared Permissions

In the previous version of Windows, the default permissions granted Full Control to Everyone (in both cases), effectively leaving the file system entirely nonsecure (in case of a local access to the system). This has changed, starting in Windows XP Professional.

NTFS permissions to the root drive granted to Everyone group are limited to Read and Execute and apply only to the root folder. This means that Everyone group does not inherit these permissions on any subfolder created under the root directory. Everyone group is also excluded from the Access Control List for more secure file system areas such as Program Files or Windows folders. Users, in addition to Read and Execute, can create subfolders (inheritable) and files in the subfolders. (Note that this does not include the root drive.) The level of permissions granted to System account and members of local Administrators group has not changed — they still retain Full Control to the root folder and all of its subfolders and files. Creator Owner is granted Full Control to subfolders and files in them, which allows users to fully manage subfolders they created.

Shared permissions to newly created shares are now limited to Read for Everyone.

In addition, Everyone group no longer includes anonymous SID, which further mitigates the possibility of unauthorized access to the file system. You can also quickly verify how well your NTFS security works by using the Effective Permissions tab on the Advanced Security Settings for a selected file or folder. This eliminates any guesswork and possibly complex analysis of the inherited and directly assigned NTFS permissions. However, this feature does not take shared permissions into account.

File and Folder Ownership

Now, you can not only take ownership of a selected file system object (file or folder), but you can also grant it to any user using the Owner tab of the Advanced Security Setting dialog box for that file or folder. This feature simplifies dealing with Windows disk quotas, which are based on the ownership property. For example, an administrator creating a new file a on user’s behalf (e.g., via file copy or new program installation) results in the administrator becoming an owner of that file. Therefore, the new file size does not count toward the user’s quota limit. In the past, this would require cumbersome workarounds or use of third-party tools. With the assignment of ownership functionality available through the user interface, this problem can be easily fixed (for any type of operating system using NTFS — including Windows NT 4.0, 2000, and XP Professional — as long as the change is performed on the Windows 2003 Server).

Note that the same functionality (effective permissions and assigning ownership) is also available for Active Directory objects managed from Windows 2003 servers (via Effective Permissions and Owner tabs on the Advanced Security dialog box within Active Directory Users and Computers MMC snap-in).

Windows Services Configuration

Windows Services Configuration changes can be grouped into two main categories:

• Startup Type: Several likely exploitable services, such as Clipbook, Network DDE (and Network DDE DSDM), Telnet, or WebClient are disabled by default. Others are enabled only when necessary (e.g., Intersite Messaging during domain controller promotion; or Routing and Remote Access Service when configuring Windows 2003 server as a router, demand-dial, or remote access server).
• Log On As Account: Fewer services are running in the security context of the Local System because this account has unlimited local privileges. Instead, in many cases, Local System is replaced with the Local Service or Network Service accounts. Both have privileges only slightly higher than those of authenticated users. As their names indicate, Local Service account is intended for local system services (and has no capability to authenticate over the network), whereas Network Service is assigned to services that require network access. (It impersonates computer accounts when authenticating over the network.)

Authentication

Authentication enhancements apply to authenticating against both local systems and Active Directory domains.

Default local system authentication settings limit the use of local accounts with blank passwords to the console only. This means that such accounts cannot be used for any type of access originating from a remote systems (such as drive mapping or remote desktop/remote assistance connections).

Active Directory authentication changes are most prominent when dealing with cross-forest trusts. Cross-forest trust functionality allows creating Kerberos-based trust relationships between forest root domains (which requires both forests operate on the Windows 2003 functional level, implying all domain controllers are running Windows 2003 servers and all domains are at Windows 2003 domain functional level).

Such trust relationships are transitive, which means that they extend to all lower level domains in each of the forests. This allows any user in one forest to securely access any resource residing in the other forest, including cross-forest logons (using UPN naming conventions). With the default settings, authentication is forestwide, giving all security principals from other forests the same ability to access local resources as users and computers from the local forest. In both cases, users are subject to permissions set on these resources.

If you do not feel comfortable with this type of scenario, you can configure selective authentication on a per-forest trust level that requires Windows 2003 forest functional level. In this case, you will be able to designate user or group accounts from the other forest that will be allowed to authenticate as well as select resources in your forest that these accounts will be allowed to authenticate against. This process consists of two main stages.

The first stage involves granting security principals from the other forest “Allowed to Authenticate” permissions on the Active Directory object representing the computer account containing the resource. For example, assume there is a trust relationship between two Windows 2003 functional level forests — ForestA and ForestB — configured with selective authentication. UserA in DomainA of ForestA must access ShareB share on ServerB in DomainB of the ForestB. To accomplish this, the following sequence of steps must take place.

• An administrator of DomainA creates a global group (e.g., GroupA) in DomainA and includes UserA as its member. You can also grant appropriate permissions directly to UserA (one advantage to this approach is transparency), but dealing with individual user accounts becomes inefficient if there are many.
• Launch Active Directory Users and Computers with the focus on the DomainB. Locate ServerB and double-click on its icon to bring up the ServerB Properties dialog box.
• Click on the Security tab and add the DomainAGroupA to the list in the upper portion of the box. In the lower portion, select the checkbox in the Allow column for the “Allowed to Authenticate” and “Read” permissions. This will complete the first step — and allow members of DomainAGroupA to be authenticated when accessing DomainBServerB.

In the second stage, simply grant the desired level of permissions to ShareB on ServerB to the DomainAGroupA global group (alternatively, you can add the DomainAGroupA global group to a DomainB domain local group and grant permissions to the local group). This can be done using standard methods (typically GUI or command line tools, like CACLS).

Cross-forest authentication can also be performed for user logins via Internet Authentication Service (although in this case, two-way cross forest trusts are required).

This concludes the first article in the Windows 2003 security series. The next installment will examine other topics relating to new Active Directory security features (such as SID Filtering) and look into application code control for managed and nonmanaged code.