NTFS Permissions - Part 2
 

مادامی که Security ضروری باشد برای شبکه ... متاسفانه برخی از Administrator ها فکرمی کنند که فقط با داشتن Firewall خوب امنیت ایجاد می شود .

بررسی های مختلف نشان داده که فقط 65 درصد امنیت شبکه را یک Firewall خوب می تواند تامین کند .

سه بخش مهم وجود دارد در امنیت یک شبکه که یک Firewall کمکی به آن نمی تواند بکند و ممکن است که از داشتن Firewall هم مهمتر باشد .
 

Physical Security

اولین بخش را می توان Physical Security نام برد .

One of the Microsoft 10 Immutable Laws of Security states "If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore." You must ensure that any computer that has sensitive data stored on it is physically secure.
Authentication Method

بخش دوم ما این مورد می باشد که خوب بسیار مهم می باشد .

متاسفانه بسیاری از واحد های کاری دارای Password های بسیار آسان و معمولی می باشند و قوانین حاکم بر آنها منظور Policy های آنها نیز ضعیف می باشد .

پس داشتن Policy های قوی برای Password ها بسیار مهم می باشد اگر بتوان از Password ها سوءاستفاده کرد دیگر نیازی به استفاده از بخش اول نمی باشد.
 
NTFS Permissions

بخش سوم ما Permissions می باشد .در ابتدا شاید Permission کمی دشوار و سخت بنظر بی آید چون در کنار آن مفاهمی مانند موارد زیر نیز باید درنظر گرفته شود .

file system permissions, share permissions, inherited and direct permissions, effective permissions, ownership, Kerberos, NTLM, Ticket Granting Tickets, Access Tokens, and more

در اینجا سعی می شود بیشتر با این موارد آشنا شد.
Basics of NTFS Permissions

NTFS Permission دارای نوع می باشد Standard Permission و Special Permission.

Standard Permission بر روی یک Folder دارای مواردی همچون Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write می باشد

Special Permission نسبتا زیادتر از نوع Standard می باشد که در جدول موجود در Figure 1 مشاهده می کنید لیست آنها را.

Figure 2: Specifying Where to Apply Permissions

Figure 2:  Specifying Where to Apply Permissions

هر دو نوع Standard /Special دارای دو حالت Allow و یا Deny می باشد .

Deny مخالفت می کند با Allow .

If the permissions are inherited, then the Allow and Deny work a bit differently (for more information regarding this topic, see my column in the November-December 2005 issue of TechNet Magazine at How IT works: NTFS Permissions.
So how do you control what objects receive the permissions you assign?

شما می توانید همانند شکل Figure 2 برای هر Folder/File/Subfolder تک تک Permission تعریف کنید البته نیاز به زمان دارد.و یا اینکه برای Users و Groups ها Permission

تعریف کنید .بصورت Default یک Permission به تمامی Subfolder ها و فایلهای درون آنها داده نمی شود یا شما تک تک باید معرفی کنید و با اینکه مانند شکل Figure 2 گزینه

This Folder , Subfolder and files را انتخاب کنید .با این کار بسیار در زمان تعریف Permission صرفه جویی می شود .روش بهتر این می باشد افراد راعضو گروه کنید و سپس از

این روش به آن گروه Permission بدهید برای Folder خاص .اگر در منوی بالا گزینه This folder only را انتخاب کنید Permission جدید فقط بر روی موارد جدید ایجاد شده در شاخه رخ می هد.

اما اگز مانند شکل گزینه را انتخاب کنید به تمامی زیر شاخه ها نیز Permission به ارث می رسد.

در قسمت Apply onto شما مدل های متفاوتی را می توانید انتخاب کنید .

موارد بسیاری مشکل رخ داده که افراد برای یک Share Folder درای Permission های Read/Execute/Write می باشند اما فقط اجازه Read دارند .

این مشکل بسیار راحت حل می شود با مراحل زیر:

  1. Grant the Read & Execute and Write permissions for This folder only (selected in the Apply onto list) to the users you want to have access to the folder.

  2. Grant the Read & Execute permission for the Subfolders and files only to the same users.

  3. Grant the Write permission to the special user Creator Owner.

بااین کار افراد مشخص شده به راحتی می توانند فایل های خود را اضافه کنند و بخوانند ولی فقط سازنده هر فایل می تواند آن را Modify کند
Discretionary Access Control List (DACL)

در NTFS  هر شخص که سازنده هر Object باشد Owner آن می باشد و اختیارات کامل در مورد Object خود دارد.ومی تواند Permission آن را نیز انتخاب کند و تغییر دهد این مدل

را DACL  می نامند.
Permission Description
Full Control Specifies whether a user has all other permissions for a file or folder.
Traverse Folder/Execute File For folders, specifies whether a user can move through folders to reach other files or folders. For files, specifies whether a user can run an executable.
List Folder/Read Data For folders, specifies whether a user can view file names and subfolder names within the folder. For files, specifies whether a user can view data in files.
Read Attributes Specifies whether a user can view the attributes of a file or folder, such as read-only and hidden.
Read Extended Attributes Specifies whether a user can view the extended attributes of a file or folder.
Create Files/Write Data For folders, specifies whether a user can create files within the folder. For files, specifies whether a user can change files or overwrite data.
Create Folders/Append Data For folders, specifies whether a user can create folders within the folder. For files, specifies whether a user can make changes to the end of the file, but not change, delete, or overwrite existing data.
Write Attributes Specifies whether a user can change the attributes of a file or folder.
Write Extended Attributes Specifies whether a user can change the extended attributes of a file or folder.
Delete Subfolders and Files Specifies whether a user can delete a subfolder or file, even if the Delete permission has not been granted on the subfolder or file.
Delete Specifies whether a user can delete a file or folder.
Change Permissions Specifies whether a user can change permissions on a file or folder.
Take Ownership Specifies whether a user can take ownership of a file or folder.
Figure 1 :  NTFS Special Permissions

روش بهتری وجود دارد و آن هم استفاده از Script می باشد .Ownership Script tool یکی از آنها می باشد

You will find instructions for using the File Ownership Script Tool at HOW TO: Use the File Ownership Script Tool (Fileowners.pl) in Windows 2000.
Once you take ownership of the file or folder, the user who created the object cannot change the permissions you set unless, of course, you give them that permission. The next questions are when does the administrator take ownership, and what happens if the user changes the permissions before the administrator takes ownership. There is excellent information at Watching Folder Activity in VB.NET. You will need some programming skills and the Microsoft® .NET Framework installed, as well as Visual Studio® .NET (version 1.0 or later). This site takes you through the steps to create code that can monitor a folder for activity and direct how to respond to that activity. If you combine both of these resources, you can monitor a folder and take ownership automatically as soon as a user creates an item.
Permissions and File Systems

برای مثال اگر شما از Drive D استفاده می کنید برای افراد و Department Files آنها و هر Department تشکیل شده ازافرادی همچون Managers و Workers و Assistance و...

برای شروع سه Global Groups ایجاد کرده برای سه نوع افرادی که در بالا گفته شد .و افراد هر قسمت را به گروه خود اضافه می کنیم .این بسیار بهتر می باشد

که شما Permission را به گروه ها بدهید تا به تک تک افراد .سپس به User Administrator قدرت کامل یعنی Full Control می دهید  به Drive D و تمامی Subfolders یعنی تمامی D .

در آخر به گروه های مختلف Permission های خاص هر یک را اضافه کنید همانند Figure 3.
Group Permissions
Managers Modify
Workers Read & Execute, Write
Assistants Read & Execute
Figure 3 :  Group Permissions

برای انجام این کار شما به راحتی می توانید مراحل زیر را انجام دهید .

If permissions have been modified in one of the departmental folders, it’s very easy to restore the permissions you set. To do so, just right-click on the departmental folder and choose Properties. In the properties dialog box, click on the Advanced tab, click the Advanced button, and check Replace permission entries on all child objects with entries shown here that apply to child objects. This will force the departmental folder permissions down the tree and will remove any other permissions. This will even force these permissions on files and folders that have inheritance blocked.

با انتخاب کزینه Replace Permission entries on all child objects with entries shown here apply to child object تمامی Permission ها موجود از بین می روند و Permission جدید شما

جایگزین آنها می شود .
 
Groups and Permissions

درک صحیح از Groups و استفاده درست از آن در Permission بسیار مهم می باشد برای ایجاد یک Permission خوب و مناسب .

Groups دارای چهار نوع و یا Type می باشد که عبارتند از Local, Domain Local ,Global , universal.
 
Group Type Member Scope Permission Scope
Local Any domain in the forest Local machine
Domain Local Any domain in the forest Local domain
Global Local domain Anywhere in the forest
Universal Any domain in the forest Anywhere in the forest

Figure 4 :  Group Membership and Permissions

Local Groups در محیط یک Computer فعالیت می کند و در درون یک Member Server و یا یک Workstations قرار دارد .از این گروه فقط می توان برای دادن

Permission به  Resource های Local Computer استفاده کرد .اما می تواند Member و یا عضو از هر گروهی در درون Forest داشته باشد .

Domain local Groups در محیط یک Domain فعالیت می کند و برای دادن Permission در این محیط می باشد .و می تواند عضو و یا Member بگیرد از تمامی Domain های یک Forest.

Global Groups می تواند در هرجای یک Forest فعالیت کند و Permission برایش تعریف شود .اما فقط می تواند عضو و یا Member از Local Domain خود بگیرد .

Universal Groups می تواند در هر جای یک Forest فعالیت کند و Permission تعریف کند و می تواند از هر Domain درون Forest عضو و یا Member بگیرد .

در Figure 4  می توانید این چهار نوع را مشاهده کنید .
 

Microsoft برای Group دو Categories مشخص کرده بنامهای Users Groups / Resource Groups :
Category I - Users Groups

در Categories اول که نام آن  Users Groups می باشد  دو نوع عمده Global Groups و Universal Groups وحود دارد .

Global Groups درواقع Primary گروه ما می باشد برای User ها یعنی انتخاب اول ما می باشد .در شبکه ما افراد یک Domain را عضو این گروه می کنیم که

می خواهیم این افراد Access داشته باشندبه یک Resource در شبکه .اما زمانی که ما می خواهیم افراد Domain های متفاوتی  به یک Resource دسترسی داشته باشند

تک تک Global Groups آن Domain ها را عضو یک Universal Groups می کنیم .
 
Category II - Resource Groups

Local Groups و Domain Local Groups در این Categories قرار می گیرد .

در اصل شما Permission هر Resource را به Domain Local Groups و یا Local Groups می دهید و در نهایت Global / Universal Groups  را به عضویت آن دو درمی آورید یعنی به

دو گروه مربوط به این Categories اضافه می کنید.
 

برای دادن یک Permission مناسب اول باید Detail را مشخص کرد یعنی نام گروه شما باید مشخص کنند کارآن گروه بصورت واضح باشد .

نام باید مشخص کنند نام Accounts ها و یا عضو آنها و نیز نوع گروه باشد .برای مثال  Domain ABC دارای یک Global Groups بنام  gg_Accounts_ABC می باشد

در شبکه های بزرگتر پیچیدگی بیشتر می باشد برای این منظور شما باید Permission را به Domain Local Groups بدهید و Global Groups ها را به عضویت

Domain Local Groups درآورید .در اینجا نیز نام گروه بسیار مهم می باشد شما باید نام گروه Domain Local Groups را که ایجاد کرده اید را از دو جزء مهم تشکیل دهید

نام باید نوع گروه و نیز نام Resource که به آن نسبت داده شده را مشخص کند .برای مثال اگر یک Folder بنام Data بر روی یک Server بنام FileSrv1 وجود دارد

و شما فقط Permission - Read به آن گروه داده اید نام گروه می تواند باشد DL_Data_FileSrv1_Read .

نام گروه باید مشخص کننده موارد مهم برای Admin باشد.برای بالا بردن سرعت و کم کردن زمان کار می توانید دیگر افراد که عضو یک Global Groups می باشند را عضو این

گروه که Permission Read دارد کنید تا زمان کمتری برای پیکربندی Permission ها لازم باشد ..
 

Figure 5 :  Effective Permissions for a Particular User

برای مشاهده Property موجود بر روی هر Permission هر فایل و یا Folder می توانید همانند Figure 5 در این قسمت با Select کردن User خاص Permission آن فرد را

بر روی آن Folder/File مشاهده کنید البته فقط می توانید مشاهده کند .برای دیدن این منو مراحل زیر را انجام دهید .

To find the effective permissions for a user to access the property sheet of the file or folder, select the Security tab, click the Advanced button, and then select the Effective Permissions tab. Click the Select button and select the user you want to assess. Click OK and the property sheet will now show you the effective permissions for that user (see Figure 5). You can only read, not change, permissions on the Effective Permissions tab.
Share Permissions

برای دسترسی بصورت Remote دو Permission بنام های Share Permission و NTFS Permission با هم شروع به ارزیابی می کنند که آیا Access وجود دارد یا خیر .

اگر برای یک Share Folder در Share Permission - Full Control و در NTFS Permission - Read باشد دسترسی بصورت Remote به آن فقط دارای Permission Read می باشد .

در واقع می توان گفت کمترین Permission که در هر دو قسمت تعریف شده باشد داده می شود

Sharing Permission NTFS Permission Active Permission
Full Control Read

Only Read
Change Allow Read-Write

Read-Write
Full Control Deny Write

Access denied
Full Control -

Access denied

Figure 6 :  Hierarchy of Shared Folders

در Share Permission چیزی بنام ارثبری وجود ندارد و هر Permission مستقل می باشد از دیگر Share Permission ها و مانند NTFS خاصیت ارث بری ندارد .

در مثال اول یک Folder بنام Test folder وجود دارد که در شکل Figure 5 مشاهده می کنید برای آن Permission - Full control در Sharing تعریف شده

زیر شاخه آن نیز دارای Deny Full Control  می باشد.

در این حالت در زمان دیدن سیستم شما دو Folder را مشاهده می کنید که به اولی Access دارید ولی به دوم دسترسی ندارید . باید بدانید که Folder Inside Test در داخل Testfolder می باشد

و زیر شاخه آن است ولی هر دو نمایش داده می شود .اگر داخل TestFolder شوید بازهم آن Inside Folder را مشاهده می کنید و باز هم Access ندارید .البته در این حالت برای InsideFolder

هیچ NTFS Permission تعریف نشده.
 

 

When I access the computer using a UNC path, I see both TestFolder and InsideTest as top-level shared folders. There is no indication that these are actually nested folders. If I double-click InsideTest, I am denied access, as expected, due to the Deny permission. If I double-click TestFolder and then in the window that opens double-click InsideTest, I have Full Control permission to that folder. I entered the file system through the TestFolder share, so I have the share permission of Full Control throughout that branch of the directory tree (see Figure 7).

In the previous example, the D: drive is being used for departmental files. Each department has managers, workers, and assistants that need specific permissions as well as the administrators who need full control of the entire volume. The administrators group has full control of each drive by default. Inheritance will propagate this to all of the departmental folders, so the NTFS permissions for the administrators group are granted automatically. The root of each drive is also shared as a hidden share (D$ in this case) with administrators having full control. Each departmental folder needs to be shared with department managers getting Change permission, department workers also getting Change permission, and department assistants assigned Read permission.

The first thing I usually do with both share and NTFS permissions is remove the Everyone group. Everyone includes anonymous accounts like Guest and IUSR_computername (the Internet guest account). In Windows NT® and Windows 2000 the Everyone group also includes null sessions. Authenticated Users includes all valid user and computer accounts in the forest, but does not include any guest or anonymous accounts. Most of the time if you want to give permissions to everyone, what you actually mean is Authenticated Users.
 

Figure 7 :  Effective Share Permissions
 
Permissions and Active Directory
Let’s take a quick look at how the processes of authentication and authorization work in Active Directory®. Windows 2000 and later uses Kerberos, a certificate-based secure protocol, for both of these processes.
TechNet Online Resources

For more information on how NTFS permissions work and details about some handy tools to help you manage NTFS, visit these TechNet Online resources.

How Permissions Work

Not sure of the difference between ACE and ACL? Confused by permissions on shared folders? For details on working with NTFS permissions, read this article.

Planning File Server Security

When protecting your organization's data, it's important to plan ahead. Check out these best practices when designing a security strategy for your file servers.
How Security Descriptors and Access Control Lists Work

Get a detailed overview of how security descriptors and access control lists work in Windows Server 2003, so you can start securing objects individually.

Security Descriptors and Access Control Lists Tools and Settings

There are a number of tools available to help you work with security descriptors and access control lists—some are included with Windows Server 2003 and others can be downloaded as part of the Windows Server 2003 Resource Kit Tools. Here's an overview of some of these apps and what you can do with them.

When a user logs on to a domain, a Ticket-Granting-Ticket (TGT) is created. This ticket contains the security identifiers (SIDs) of the user as well as all groups that the user is a member of, including nested groups. If the user is in 25 global groups which are each in 25 domain local groups, that is a total of 650 SIDs on the TGT. A SID looks something like this:    S-1-5-21-3204519953-1226544935-3965933272-1009. The first part of the SID identifies the database to which the account belongs. The last part is the Relative Identifier (RID). The RID of this account is 1009. The RID increments by one for each new account and Active Directory can create literally billions of accounts. The moral of this story is that SIDS can be large and having a TGT containing 650 SIDS will be very large. Most users will have considerably fewer than 650 SIDS on their TGT, but even a small TGT is a fairly substantial object.

The TGT is only part of the story. Every resource a user accesses on a remote computer causes quite a chain of events. Let’s say you try to access \\Computer1 through Explorer. Your computer sends your TGT (with all of the SIDs) to the domain controller with a request to access Computer1. The domain controller verifies the SIDs and puts them on a Session Ticket (ST), also called a Service Ticket, and sends it back to your computer. Your computer sends the ST to Computer1 with the request for access.

Practically speaking, this authentication process means that all of the SIDs hit the network three times for each network access. If you have plenty of bandwidth, this is fine. If you have bandwidth issues, especially when everyone first logs on for the day, consider using local groups instead of domain local groups.

When the ST arrives at the destination, Computer1 extracts the SIDs from the ST and searches the local Security Account Manager (SAM) database and retrieves the SIDs for local groups that the user belongs to. The SIDs of these local groups are added to the Access Token on the computer where they reside. Local groups never hit the wire. The SIDs on the Access Token are measured against the SIDs on the DACL to determine the user’s access level to the requested resource. In the previous example, if I used local groups instead of domain local groups, the tickets would have contained 25 SIDs instead of 650.

Another way to conserve on the number of SIDs on the tickets is to use each domain local group on multiple resources. Unfortunately, security tends to slip when domain local groups are multi-purposed. Say your organization has five administrators and each of these administrators has control of different resources. Administrator Alex creates a domain local group and gives it permission to several resources under her control. The other four administrators do the same. Now this one domain local group has been given access permissions to many resources under different administrators’ control.

Here’s where things come unglued. Some users from a specific department call administrator Alex and complain that they do not have access to one of the resources. Alex solves the problem by adding a global group containing the users in that department to the domain local group that has permissions to the resource. Now those users have access to all of the different resources that each of the administrators have given that domain local group access to. As you can see, it’s just too easy to combine users and groups in ways that affect permissions on many resources unintentionally.

I recommend single-purposing domain local groups (one group for one permission on one resource) unless you have a very organized IT department, or your organization has data that does not require much in the way of security.


Conclusion
 

Physically securing computers that contain sensitive data and establishing a solid authentication methodology such as smart cards or complex passwords are the first steps toward keeping your network secure. Within your network, you can create a group permissions strategy that works for your organization.

The Microsoft strategy is embodied in the cryptic A-G-DL-P. Accounts go into global groups, which go into domain local groups, which are assigned permissions to resources. This method will work for many organizations. Remember to avoid giving domain local groups permissions for multiple resources, which can circumvent your efforts at more granular control over permissions.

Also remember to carefully apply NTFS and share permissions. Give users the level of access that they need to do their job and no more. Permissions can be inherited through shares, so plan your file system and share strategy accordingly. A little foresight and planning will give you better results further down the road.

 

در زیر مشخصات نویسنده این مقاله را مشاهده می کنید .

NTFS Permissions - Part 2
Richard Civil runs Civil Consulting and Training, and is Senior Technical Trainer at New Horizons in Beaverton, OR. A professional trainer since 1992, Richard also holds MCT, MCSE, MCP+I, SCPI, and IC3 certifications. Learn more about Richard at www.rcivil.com.
 

Last Updated: October 01, 2006

Winteacher.com
NTFS Permissions - Part 2

 © 2003-2006 Winteacher.com . All rights reserved