Restricted Code
Windows adds the Restricted Code well-known security principal to a user's access token when you run RunAs with the Run this program with restricted access option in Windows 2003 or the Protect my computer and data from unauthorized program activity option in XP. RunAs offers high-privilege accounts (e.g., administrators) a convenient way to switch to the security context of a least-privileged user when executing a program, thus limiting the exposure to malware inherent in their high-privilege security context. For more information about RunAs, see "Learn to Be Least," October 2005, InstantDoc ID 47622.
When the user's access token has the Restricted Code well-known security principal, Windows eliminates all rights held by the user except for Bypass Traverse Checking, prevents the application from accessing the user's profile, and allows only Read access to the HKEY_LOCAL_ MACHINE and HKEY_CURRENT_ USER registry hives.
Restricted Code provides a convenient way to honor least privilege without having to remember two user accounts and two passwords. Instead of using RunAs to switch to the security context of a least-privilege account, you can use RunAs to switch to a locked-down version of the account's current security context— without entering the credentials of a second account. For more information about the RunAs feature and its use of Restricted Code, see Aaron Margosis' article "Running Restricted" at http://blogs.msdn.com/aaron_ margosis/archive/2004/09/10/227727 .aspx.
Logon-and Authentication-Type
The Windows 2003, XP, and Win2K OSs include well-known security principals that Windows adds to the access tokens of other well-known security principals based on the principal's logon type. These logon-type well-known security principals are Batch, Dialup, Interactive, Network, Service, and Terminal Server User. (Terminal Server User is for all users logged on using Terminal Services 4.0 application compatibility mode.)
Windows 2003 and XP SP2 add the Remote Interactive Logon wellknown security principal, which identifies users who log on using the Windows 2003 or XP versions of Terminal Services or a Remote Desktop connection. For more information about logon types, see "Logon Rights: The Heart of Windows Access Control," August 2005, InstantDoc ID 46870.
Windows 2003 also adds three authentication-type well-known security principals—NTLM Authentication, SChannel Authentication, and Digest Authentication. These wellknown security principals reflect the authentication protocol that a principal used to authenticate to Windows in the principal's access token. Note that Microsoft hasn't provided principals to represent Kerberos and basic authentication.
You can use both the logon-and authentication-type well-known security principals to gain a more granular level of control over authorization. These new well-known security principals let you give users different levels of access to a resource depending on the authentication protocol (e.g., NTLM, Digest, SSL) and logon type (i.e., from the console, using Terminal Services).
Self, Creator Owner, and Creator Group
Windows includes several hierarchical object structures (including AD, the registry, and the file system) that support permission inheritance. You define permissions on a parent object, then these permissions are automatically applied to its child objects. Windows provides the Self, Creator Owner, and Creator Group wellknown security principals that administer the permissions in these hierarchical structures.
Typically, you add all three of these well-known security principals to the ACL of a parent object, then the child objects inherit these principals in the following way:
- Child objects inherit permissions given to the Creator Owner on a parent object in such a way that the account that creates the child object is set as owner on the object and gets those specific permissions as explicit permissions on the child object. For example, if the AD administrator sets Write permission on certain user-object properties for the Creator Owner on an organizational unit (OU), when a user creates a new user object in that OU, that user gets Write permission on those user-object properties.
- The Creator Group functions similarly to Creator Owner, but instead of adding permissions to the child object for the Creator Owner, you grant or deny permissions to the Creator Group, which then adds permissions for the primary group of the object owner to the child object.
- Self acts as a placeholder for the object. Say, for example, an AD administrator adds permission to write the postalAddress user-object attribute for Self to the ACL of an OU. When you create a new user object called Jan in that OU, user Jan will have Write permissions for his postalAddress attribute (Jan will be allowed to maintain his proper postalAddress data in his AD user object). Note that the same Self permissions on another user object won't allow Jan to edit the other user's postalAddress, because that Self permission is unrelated to Jan's user account.
By default, Windows grants Self read permissions on the memberattribute of a group. This means that all members of a group can see who else belongs to the group. Because AD also grants Authenticated Users read access to a group's member list, Authenticated Users can see the same.
Powerful but Complex
You've seen the power of Windows well-known security principals and learned a bit about the complexity behind administering access to Windows resources. Seeing the wellknown security principals added in Windows 2003 and considering the growing importance of delegated and self-service administration, you can expect that Windows will provide even more well-known security principals in the future.
End of Article
Prev. page
1
[2]
next page -->
