Besides files and directories, NT secures many other objects. The Win32 API implements five function groups that work with security descriptors and correspond to five kinds of objects.

• File and directory objects: NT stores their security information (including mail slots and named pipes) with the objects. Security for these objects is available only on NT File System (NTFS)-formatted volumes.
• User objects (window-management objects): These objects include windows station and desktop objects. All User objects are in memory and are never persisted (saved) to disk.
• Kernel objects: The Windows kernel uses these objects, which include processes, threads, and semaphores and mutexes (signaling objects that control access to objects and code). Like User objects, kernel objects are not persisted.
• Service objects: These objects, which include any Win32 service listed in the Control Panel, are under the control of the Service Control Manager and are not persistent.
• Private objects: Application programs can implement and must maintain their own security, and private objects let them interact with the Win32 security system. For example, a database system, perhaps SQL Server, might need to store security information internally and use NT’s user domain validation. The Registry is a Win32 API implementation of private objects. Security information is stored inside the Registry.

A security descriptor (SD) describes the security attributes of each securable object. These attributes identify the object’s owner and two access control lists (ACLs), one for object access and the other for auditing. The ACL for object access is the discretionary access control list (DACL). It contains several access-control entries (ACEs). Each ACE identifies an SID and its access permission (allowed or disallowed). The other ACL is the system access control list (SACL), which controls event auditing.

Very Important Privileges: User Rights

In addition to access rights, which are associated with objects, NT implements privileges. To assign object rights, you use File Manager or Explorer; to assign privileges, you use User Manager. Privileges become part of the access token that a user receives when successfully logged on to the system. The OS determines the set of privileges available; applications can’t define their own.

Privileges are a source of frustration. Have you ever added an account to a system, tried to log on to that account, and received the message, “The local policy of this system does not permit you to log on interactively?” By default, NT assigns new users to the group Users, but this group, also by default, doesn’t have permission to log on locally.

With Microsoft’s Internet Information Server (IIS), you can run into a similar problem. The pre-established Internet user account, iusr_machine, is a local account with few privileges, so you can’t use it as the IIS anonymous-logon account if the user specifies Hypertext Transfer Protocol (HTTP) basic authentication.

If you explore usrmgr.exe, you find the Everyone group under Access this computer from the network, although the system doesn’t appear to have this group. NT defines a few well-known SIDs, such as Everyone and Interactive, to help you work with common access rights.

In general, privileges override individual object security. An example of needing to override security is when a backup administrator must change the archive flag on every file on a volume. Without the corresponding privilege, the administrator has to add another ACE to each file to let the backup program touch the flag. If you add the SID for Everyone to a privilege or access right, NT security doesn’t have to check any further, so some operations go faster.

www.bestitdocuments.com