Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] - نسخه متنی

Roberta Bragg

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







The Access Control Process


Now that you are familiar with users, groups, and permissions, take another look at the access control process. The access control process examines a request for access and grants or denies access. The following steps take place:


1.

Resource access is requested.

2.

The Security Reference Monitor compares the contents in the access token one at a time to see if there is any match between the SIDs in the token and those in the ACL on the object. Access is allowed or denied based on the results.

3.

If a match is found, the Allow or Deny information in this access control entry is compared to the requested access. If there is an Allow match, then the access is granted.

4.

If there is a Deny match, then access is denied, and the process is ended.

5.

If the access information is incompletethat is, both read and write are requested, and the successful comparison indicates read is allowedthen the comparison will continue until write is either explicitly allowed or denied, or until it is implicitly denied because there is no match.

6.

Unless a Deny match is found or an Allow is completed, if there are still ACEs in the ACL, the process continues.

7.

If the list of ACEs in the ACL is exhausted, and no match has been found, then access is denied.


Let's look at an example of this in practice. User Joe wants to open a Word document, budget.doc, for reading and writing. He double-clicks the file in Windows Explorer. The access control list on the file and the SIDs in his access token are listed in Figure 3-21. The ACL on budget.doc contains the ACEs as listed in the box labeled "Access Control List," while Joe's access token contains the SIDs in the box labeled "Access Token." Because it's easier for us to look at names instead of SIDs, no actual SIDs or other numerical representations are listed. The real access token and ACL would look much different but would evaluate to the same information and produce the same result. The ACL contains ACEs that are composed of SIDs and the access rights granted. The access token includes the account SID and the SIDs of groups of which the account is a member.

Figure 3-21. An example ACL and Access Token for comparison.

While you may be able to quickly determine if Joe will be granted the access he desires by just looking at the figure, take the time to step through the SRM process:


1.

The first ACE in the file ACL is examined. It contains the group "Administrators."

2.

Joe's access token does not include the Administrators group.

3.

The next ACE in the ACL lists the Accountants group. Joe's access token does list this group. The ACE grants the Read Allow permission. But this is not enough, because Joe requested Read and Write.

4.

The next ACE is examined. This ACE lists the Accounting Clerks group. Joe's access token also includes this group. The ACE grants the Allow Write permission.

5.

The requested access is granted, and the process stops, even though there are more ACEs in the ACL and more groups in Joe's access token.


Use the resource kit tool Show Privilege to determine what rights and privileges a user has on a computer. Use the resource kit tool whoami to show the contents of the access token for the currently logged on user.

Managing Proprietary Information


A new component, Rights Management Solutions (RMS), can be used to influence management of proprietary information on Windows systems. RMS is a client/server application development environment. On Windows Server 2003, the core elements of the RMS service manage licensing, machine activation, enrollment, and administrative functions. Client-side development uses native APIs for Windows 98 Second Edition and later clients. Applications that restrict authorization to copy, use, download, and otherwise manipulate licensed software and digital documents and recordings can be centrally controlled. For more information, the document "Microsoft Rights Management Solutions for the Enterprise: Persistent Policy Expression and Enforcement for Digital Information" can be downloaded from http://www.microsoft.com/windowsserver2003/techinfo/overview/rm.mspx.


/ 194