Using Standard NT Security Features in Windows 7 : UNDERSTANDING BASIC NT SECURITY

5/14/2013 4:18:22 AM


Windows 7 has a number of new security features. Some are internal. You won't use the following features directly, but they do affect the way in which your application executes.

  • Kernel patch protection

  • Service hardening

  • Data execution prevention

  • Address space layout randomization

  • Mandatory integrity levels

These features change the way Windows 7 executes your application and the environment in which the application executes. In some cases, you may need to consider how these features work when writing your application, but managed application code developers, such as those who use C#, can probably forget these features even exist except to realize that they work in the background to secure the application environment.

Microsoft has also streamlined the User Account Control (UAC) functionality to make it less intrusive. Some security pundits have decried this action because it actually makes Windows 7 a little less secure. However, the other side of the coin is that users are less likely to ignore warnings that they see occasionally, rather than ones they see as part of nearly every action. 

In fact, developers and administrators alike often see auditing as just another step along the road toward the world of Big Brother described in the book 1984. See for details. However, auditing has many practical uses:

  • Regulatory compliance requirements

  • Business compliance requirements

  • Application monitoring and debugging

  • Trojan, virus, and other forms of malware detection

  • Resource control

  • Internal threat monitoring


Many developers view Windows NT security as difficult. However, the concepts behind Windows NT security are actually quite simple. When you leave your house, you close the door and lock it. The lock is a kind of security that you place on your house. Only someone with an appropriate key can access the house once you lock it (let's assume for a moment that intruders lack tools such as pry bars). The lock is a kind of access control, while the key is a right to access the house. Windows NT security works precisely this way. A resource, such as a file, has a lock on it that provides access control, while a user has a privilege (the key) that grants permission to use the resource in some way.

Let's take access to your house to the next level. The front door is only one level of access. You might have locked rooms, a safe, gun cabinet, or other elements in the house that require additional permissions to access. The main reason for these additional permissions is that the contents of the room or safe are especially valuable or perhaps unsafe. You might not want your children accessing them. To access these additional elements, you have a combination, additional keys, or other means of access. In other words, you have additional permissions not shared by everyone in the household. Windows NT security works in the same way. Most resources provide multiple levels of permissions that some users enjoy and others don't.

Access comes in two forms in Windows NT security. A user has personal rights that are assigned directly to that user — akin to the keys someone has on his or her key ring. In addition, a user can belong to a group of users who all share the same rights — akin to the key under the doormat that everyone in the house knows about and uses. It's important to understand that the user's access is limited to the combination of group and individual rights that the administrator assigns.

Figure 1. Administrators rely on utilities to change resource permissions.

Rights are assigned by two parties. Administrators assign rights to users by changing the Windows configuration directly with a Microsoft-supplied utility, such as the security editor shown in Figure 1. Likewise, a developer can write code that sets Windows security for particular objects, calls, and portions of an application. When the developer couples this level of security with application settings, the administrator can achieve better security without losing any flexibility. In both cases, changes by the administrator or developer affect the rights required to perform specific tasks using resources such as a file. The right to write to a file is separate from the right to read from the file.

User-level access depends on a Security IDentifier (SID, usually pronounced "Sid," like the name). When the user first logs in to the system, Windows assigns an access token to the user and places the user's SID (stored on the domain controller or other security database) within it. The user object carries around both the access token and the SID for the duration of the session. An access token also contains both a Discretionary Access Control List (DACL, pronounced "dackel") and a System Access Control List (SACL, pronounced "sackel"). The combination of Access Control Lists (ACLs) and SID within the access token is a key that allows the user access to certain system resources. Because this access lasts the entire session, the user must log out and then back in to the system whenever the administrator makes a change to security; otherwise, the user won't gain additional rights that the administrator provides.

A key is no good without a lock to open. The lock placed on Windows resources is called a security descriptor. In essence, a security descriptor tells what rights the user needs to access the resource. If the rights within the ACLs meet or exceed the rights in the security descriptor, then the lock opens and the resource becomes available. Figure 10-2 shows the contents of the ACL and the security descriptor used for token-based security. The following sections provide more details about how token-based security actually works, using Figure 2 as the point of discussion.

Figure 2. Token-based security relies on ACLs and security descriptors.

2.1. Working with ACLs

There are two ways of looking at a user's rights under Windows: individual rights and group rights. The user's SID is the account number that Windows assigns to the user during login. The access token that holds the SID also contains other structures that identify the groups the user belongs to and what privileges the user has. Each group entry also has a SID. This SID points to other structures that describe the group's rights. To understand the user's rights, you need to know both the user's individual rights and the rights of the groups to which the user belongs. An administrator normally uses the Local Users and Groups or the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in to change the contents of this access token, as shown in Figure 3. (To use this feature, right-click an entry, such as Guest, choose Properties from the Context menu, and select the Member Of tab to change the user's group affiliations.)

Figure 3. MMC snap-ins make it possible to change user access tokens.

The privileges section of the access token shown in Figure 2 begins with a count of the number of privileges the user has — the number of special privilege entries in the access token. This section also contains an array of privilege entries. Each privilege entry contains a Locally Unique IDentifier (LUID) — essentially a pointer to the entry object — and an attribute mask. The attribute mask tells what rights the user has to the object. Group SID entries are essentially the same. They contain a privilege count and an array of privilege entries.

One of the things you need to know as part of working with some kinds of objects is that object rights flow down to the lowest possible node unless overridden by another SID. For example, if you give the user read and write privileges to the \Temp directory on a hard drive, those rights will also apply to the \Temp\Stuff directory unless you assigned the user specific rights to that directory. The same holds true for containers. Assigning a user rights to a container object like a Word document gives the user the right to look at everything within that container, even other files in most cases. It's important to track a user's exact rights to objects on your server using security surveys, since you could inadvertently give the user more rights than needed to perform a certain task.

2.2. Understanding the Security Descriptors

At this point, you have a better idea of how the access token (the key) works. It's time to look at the security descriptor (the lock). Figure 10-2 shows that each security descriptor contains five main sections. The following list describes each section.

  • Header and Flags: The header consists of version information and a list of control flags. The flags tell you the descriptor status. For example, the SE_DACL_PRESENT flag indicates the presence of a DACL. If the DACL is missing, then Windows allows everyone to use the object. The basic security descriptors haven't changed since Windows 2000, so you can see a list of basic security descriptors at The overview at provides additional information about Windows security flags.

  • Owner SID: Tells who owns the object. This doesn't have to be an individual user; Windows allows use of a group SID here as well. The limiting factor is that the group SID must appear in the token of the person changing the entry. In other words, you can't assign ownership to a group where you don't have membership.

  • Group SID: Tells which group owns the object. This entry contains only the main group responsible for the object and won't contain a list of all groups with access to the object.

  • SACL: Controls the Windows auditing feature. Every time a user or group accesses an object when the auditing feature for that object is on, Windows makes an entry in the audit log. There's more than one entry in this section, in most cases, so Windows stores the information in an array.

  • DACL: Controls object use. Windows assigns groups and users to a specific object. In most cases there's more than one entry in this section, so Windows stores the information in an array. A DACL can contain a custom value, a default value, or a null (empty) value, or it may not appear in the security descriptor at all (this last option is rare and dangerous). You'll normally find more objects with default values than any other DACL type.

2.3. Understanding the ACEs

As previously mentioned, a security descriptor relies on a SACL and a DACL to control the security of an object. Both elements use the same basic ACL data structure, but for different purposes. An ACL consists of two entry types. The first is a header that lists the number of Access Control Entries (ACEs) in the ACL. Windows uses this number to determine when it's reached the end of the ACE list. (There isn't any end-of-structure record or other way to determine the size of each ACE in the structure.) The second entry is an array of ACEs.

An ACE defines the object rights for a single user or group. Every ACE has a header that defines the type, size, and flags for the ACE. It includes an access mask that defines rights a user or group has to the object. Finally, there's an entry for the user or group SID.

There are four main ACE header types (you can find the full list of ACE headers at Windows currently uses three out of the four main ACE header types. The following list tells you about each of the main header types:

  • General Access: This header type appears in the DACL and grants object rights to a user. Use it to add to the rights a user already has for an object on an instance-by-instance basis. For example, you might want to prevent the user from changing the system time so that you can keep the machines on the network synchronized. However, there might be one situation — such as daylight saving time — when the user would need this right. You could use an access-allowed ACE to allow the user to change the time in this one instance.

  • Object Access: This header type appears in the DACL and helps Windows assign specific security to software objects and sub-objects. A developer must provide special code to provide this access. For example, the developer could use this type of ACE to assign security to the property of a COM object. To use this type of ACE, the developer needs to obtain or create a globally unique identifier (GUID) for the object in question. Once the developer adds the required code, application settings can allow the administrator to control access to particular application features at run time.

  • System Audit: This ACE header type works with the SACL. It defines which events to audit for a particular user or group. There are system audit header types for both general and object use. The .NET Framework doesn't provide a specific auditing feature, so you can use this feature when you want to know who's accessing a particular Website feature and when they access it. This feature requires that the user log in to the system. Yes, it does work with anonymous access, but all you'll see is the anonymous user information.

  • System Alarm: This is the currently unused ACE type. It enables either the SACL or DACL to set an alarm when specific events happen.

  •  Windows Server 2008 R2 networking : Planning and Deploying a TCP/IP Network Infrastructure (part 2) - Policy-based QoS
  •  Windows Server 2008 R2 networking : Planning and Deploying a TCP/IP Network Infrastructure (part 1)
  •  Windows Server 2008 R2 networking : Overview of Windows Server 2008 R2 Networking
  •  Windows Server 2003 : Recovering from System Failure
  •  Windows Server 2003 : Advanced Backup and Restore (part 2) - Scheduling Backup Jobs, Shadow Copies of Shared Folders
  •  Windows Server 2003 : Advanced Backup and Restore (part 1) - Managing Media, Backup Options, The Ntbackup Command
  •  Windows Server 2003 : Managing and Implementing Disaster Recovery - Restoring Data
  •  Windows 7 : Networking and HomeGroup Sharing - Sharing Between PCs (part 2) - Old-School Sharing
  •  Windows 7 : Networking and HomeGroup Sharing - Sharing Between PCs (part 1) - HomeGroup Sharing
  •  Troubleshooting Reference – May 2013 (Part 2)
    Top 10
    Review : Sigma 24mm f/1.4 DG HSM Art
    Review : Canon EF11-24mm f/4L USM
    Review : Creative Sound Blaster Roar 2
    Review : Philips Fidelio M2L
    Review : Alienware 17 - Dell's Alienware laptops
    Review Smartwatch : Wellograph
    Review : Xiaomi Redmi 2
    Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
    Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
    3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
    Popular Tags
    Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8