The security attributes of each Windows NT object (file, named pipe, registry key, user object, kernel object, private object, and so on) are described by a security descriptor (SD). The security descriptor contains information about the owner of the object and has an access control list (ACL), which specifies users and groups and their access permissions on that object.
Access Control Lists
There are two types of ACLs: discretionary and system. The discretionary ACL (DACL) is controlled by the owner of an object and specifies the access particular users or groups can have to that object. The system ACL (SACL) is controlled by the system administrator, and allows system-level security to be associated with the object. The usage of DACL and SACL APIs is very similar. However, the SACL APIs can only be used by a process with system administrator privileges. Because most security programming does not involve setting the system-level security and it is likely that your BackOffice application will need to set or impersonate the security credentials of users, this discussion will focus on the DACL APIs.
The DACL contains an access control entry (ACE) for each user, global group, or local group that is given access permission (whether allowing or denying access) to the object. When a DACL does not have any ACEs, no access rights have been explicitly granted. Therefore, access to the object is implicitly denied. However, when an object does not have a DACL, no protection is assigned to the object and any access request is granted. A security descriptor for an object is initially set to have a DACL with no ACEs, which means that there is no access for any user. To give access to all users or groups, the DACL for the SD must be explicitly set to NULL.
Security Descriptors
There are two types of security descriptors used in the system: absolute and self-relative. The distinction between these types is very important when programming in a BackOffice environment. An absolute security descriptor contains pointers to the DACL and ACE information. However, the self-relative security descriptor contains information in a contiguous block of memory, so the DACLs and ACEs are positioned at offsets. The security APIs use both absolute and self-relative formats at different times. When your application queries for security descriptor information, the information is always returned by the system in self-relative format. The program can then walk through the offsets to obtain the proper information. However, when you add to or change the security descriptor, it must be in absolute format. When programming a change to the security descriptor, for example, the program must read in security descriptor information in one format, then convert it and write it back in the other format.
A user of a process is assigned an access token, which contains identifiers that represent the user and any group to which the user belongs. This access token is checked against the security descriptor of an object to determine the type of permission the user has with respect to that object. When a client application connects to a server, the server process can impersonate the access token of the client process. This gives the server the ability to check the access permission of the client.
For more information about the Windows NT security model, see the "Windows Base Services" section of the Microsoft Platform SDK, and the Microsoft Windows NT Resource Kit.