كي فايل رو پاك كرده

[hashemie]

سلام
يه پوشه روي سرور شير شده و 20 نفر بهش دسترسي دارند
يك نفر همه فايلهاي موجود روي ساب فولدرها رو پاك ميكنه
چه جوري ميشه فهميد كي بوده؟

---

موضوعات مشابه:

• لطفا هر كي امتحان MCSE داده بیاد اینجا!!
• مشكي در اينترنت اكسپلور 7
• اينترنت مجاني كي داره؟

---

[javad_1368]

سلام
يه پوشه روي سرور شير شده و 20 نفر بهش دسترسي دارند
يك نفر همه فايلهاي موجود روي ساب فولدرها رو پاك ميكنه
چه جوري ميشه فهميد كي بوده؟

خوب چرا دسترسی به پوشه share شده رو محدود نمیکنید(readonly)؟

بستگی به شبکتون داره که server based هست یا اینکه peer to peer؟
اگه server based باشه همه چیز log میشه
و نظارت کرد که چه کاربری با اکانت کاربریش چه کار هایی توی شبکه انجام داده

[!!!!!!!!!!!!!!!]

auditing باید فعال باشه.

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-1055140.html?tag=btxcsim

Auditing resources on Windows 2000 Professional, part 1

System auditing can be a processor-intensive activity. In this three-part Daily Feature series, Tom Shinder provides an excellent tutorial to ensure you get the right balance of audit information. This article deals with setting the policy.
The job of the network administrator has its ups and downs. Sometimes you get to do really fun things like set up a VPN or a firewall. Other times you get to do less fun, but vitally important, things like configure auditing on your Windows 2000 Professional computers.

The term audit is typically used in the financial world. A financial audit is a formal examination, correction, and official endorsement of financial accounts. An accountant sophisticated in auditing procedures typically undertakes an audit. When we audit something, we make sure things have been done properly and with the proper authority.

In a similar fashion, we can audit events on Windows 2000 Professional machines. When we enable auditing in Windows 2000, we are interested in a formal examination of the activities that take place on that machine. We are also concerned that the activities were performed with the proper authority. Like in a financial audit, we want to be able to endorse the results of our audit by confirming that all activities performed on a particular computer are legitimate.

Daily Feature series
In this Daily Feature series, we’ll examine the auditing process on a Windows 2000 Professional machine. The auditing and certifying process includes the following components, which will be covered in three Daily Features:

• Setting an audit policy—part 1
• Deciding which objects and which users to audit—part 2
• Using the Security log to examine the results of the audit policy—part 3

By configuring an audit policy, you can enable the auditing of system events and object access. After the policy and object access properties have been configured, you can use the Event Viewer’s Security log to examine the results of your auditing activities.

Setting an audit policy
The default policy on a Windows 2000 Professional computer is not set to audit. The reason for this is that auditing can be both disk- and processor-intensive. If there is no need to perform auditing on the computer, then it is a waste of hardware resources to have it enabled. Therefore, to begin your auditing adventure, you must first enable auditing.

Tip
Be careful about how much information you choose to audit. Many inexperienced administrators who are concerned about security audit every activity and file on a machine. While this policy allows you to obtain the most auditing information available, the auditing process consumes a large number of processor cycles. Disk-write activity will become so intense that it will be difficult to get any work done.

To set the audit policy on a Windows 2000 Professional computer, perform the following steps:

1. From the Start menu, open the Administrative Tools menu and click on the Local Security Policy command.
2. The Local Security Settings console will appear (Figure A). In the left pane, expand the Security Settings node, and then expand the Local Policies node. Finally, click on the Audit Policy node. You will see the available Audit Policies in the right pane.

Figure A
Note the Local Settings for each policy in the console are set to No Auditing.

Local and Effective Settings
Notice in the right pane of the Local Security Settings console that there are two columns for the settings: Local Setting and Effective Setting. If the Windows 2000 Professional computer is a standalone computer (not a member of a domain), then only the local settings will apply. If the computer is a member of a domain, then the settings in the Effective Setting column are applied. Local settings can be overwritten (such as when there is a conflict) by Domain or Organizational Unit (OU) policies.

Table A provides descriptions of each of these policy settings.

Table A Policy Description Audit Account Logon Events An event will be logged when a Domain Controller receives a logon request. The event will also be logged if a user logs on with an account contained in the Windows 2000 Professional’s Security Account Manager (SAM) database. Audit Account Management An event will be logged when a user or group account is changed. Audit Directory Service Access An event will be logged when an Active Directory object is accessed. Audit Logon Events An event will be logged when a user logs on or off. Audit Object Access* An event will be logged when an object on the machine is accessed. This is dependent on the auditing configuration of the particular object. Audit Policy Change An event will be logged when a policy affecting security, user rights, or auditing is modified. Audit Privilege Use An event will be logged when a user right is exercised to perform an action. Audit Process Tracking* An event will be logged when an application or executable file is launched. This is dependent on the auditing configuration of the particular executable. Audit System Events An event will be logged when a computer is rebooted or when a shutdown or another system-wide event takes place. Audit policies and descriptions (Policies marked with an asterisk require further configuration before events are logged.)

Note that audit policies can be placed into two categories:

• Standalone policies
• Policies that require further configuration

The standalone policies do not require any further configuration once the settings are made in the Local Security Settings console. The other policies (denoted with an asterisk in Table A) require further configuration before events are logged.

To enable one of the policies, double-click on it. You will see the screen that appears in Figure B.

Figure BSelect the Success and/or Failure check boxes to configure a policy.

By default, no auditing is performed. You can select Success and/or Failure for each policy. As shown in Figure B, we can choose to audit successful object access or unsuccessful object access. The objects can be files, folders, or printers. After selecting the type of attempt you wish to audit, click OK to enable the policy.

Be mindful of what you audit. For example, if you configure the Audit Account Logon Events to log an event for Success attempts, your Security log may grow very large, very quickly. Do you need to know all the successful logon events, which include computer and process authentications? If you are concerned about hackers trying to break into the system, you should consider auditing only Failure attempts. If you note a number of failed logon attempts, then you have a good indication that someone is trying to strong-arm his or her way into your system.

Conclusion
In this Daily Feature, I have given you an overview of setting the audit policy for your Windows 2000 Professional machine. Auditing can be a processor-intensive feature in Windows 2000. Take care in what you choose to audit to strike a balance between optimal system performance and informative audit logs. Look for part two of this series to cover auditing access and part three to handle best practices

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-5033683.html?tag=content;leftCol

Auditing resources on Windows 2000 Professional, part 2

Part two of this three-part Daily Feature series deals with configuring the audit policies of files, folders, and printers using Windows 2000 Professional. Tom Shinder shows you just which boxes to check for optimum performance.

In part one of my three-part series on auditing with Windows 2000 Professional, I showed you how to set the audit policy. In part two, my focus centers on enabling and configuring the auditing of files, folders, and printers on your computer. The lesson here is “what you keep track of is much more important than how you track it.”

Auditing object access
If you want to keep track of who is accessing or trying to access a file, folder, or printer on your computer, then you need to enable the Audit Object Access policy. However, enabling the policy is only the first step. The second step is to configure auditing on the object of interest.

Microsoft approaches object access auditing in this way because it saves system resources. If you were to enable object access auditing and then have the system automatically audit and log all access attempts to all objects, the logs would fill up quickly, and important information would be lost in the morass of a full Security log.

There are two types of objects you’ll frequently want to audit:

• Files and folders
• Printers

The auditing features are slightly different for each type.

Auditing files and folders
To enable auditing for a particular object, perform the following steps:

1. Right-click on the object (such as a file or folder) and click Properties. In the object’s Properties dialog box, click on the Security tab (Figure A).

Figure ACheck the Security tab in the Properties dialog box to see who has permissions.

1. In Figure A, you can see who has permissions to this file. Click on the Advanced button and the Auditing tab. You will see the dialog box shown in Figure B.

Figure BThe Auditing tab in the Access Control Settings dialog box

1. Note the two check boxes on this page:

• Allow Inheritable Auditing Entries From Parent To Propagate To This Object
• Reset Auditing Entries On All Child Objects And Enable Propagation Of Inheritable Auditing Entries

The first setting allows the audit settings from a parent folder to be applied to subfolders and objects contained in the subfolders. If you want custom audit settings on a subfolder or file, you need to remove the check mark from this check box.

The second option allows you to make a change on the parent folder and have that change applied to all subfolders and files contained in those subfolders. This removes the previous audit settings on the child objects and applies the settings configured on the parent object. This makes life a lot easier because if you select this option, you don’t have to go to each subfolder and file and make manual changes to the audit properties.

Click the Add button to add users to audit. In the Select User, Computer, Or Group dialog box, click on the user or group and then click OK. You will see the dialog box shown in Figure C.

Figure CUser properties displayed in the Auditing Entry dialog box

1. In the Auditing Entry dialog box (Figure C), you set the types of actions you want to be audited for a particular user or group. Table A includes explanations for each of these access options. For each action (type of access) you configure auditing for success or failure. Note the check box at the bottom of the dialog box. If you select the Apply These Auditing Entries To Objects And/Or Containers Within This Container Only option, the auditing configuration set here will not propagate to subfolders and files. After making your selections, click OK.

Table A Access option Description Traverse Folder/Execute File Logs an event when a user moves through folders to reach other files and folders, even if the user doesn’t have permission to access the traversed folders or running program files. List Folder/Read Data Logs an event when a user views folder names and files and when a user opens a file. Read Attributes and Read Extended Attributes Logs an event when a user reads the attributes of a file or folder. Create Files/Write Data Logs an event when a user creates a new file within a folder and when he or she changes the content of a file. Create Folders/Append Data Logs an event when a user creates a folder within another folder or when the user adds data to the end of a file, while not changing any of the existing data to the file. Write Attributes and Write Extended Attributes Logs an event when a user changes the attributes of a file or folder. Delete Subfolders And Files Logs an event when a user deletes subfolders and files. Delete Logs an event when a user deletes a folder or file. Read Permissions Logs an event when a user views the permissions on a file or folder. Change Permissions Logs an event when a user changes the permissions on a file or folder. Take Ownership Logs an event when a user takes ownership of a file or folder.
Descriptions of file and folder access options

1. Notice that the appearance of the Access Control Settings dialog box changes after making the change (Figure D). Our selections have created three lines in the dialog box: one for Fail, one for Success, and one for All (Fail and Success). In this example, we have chosen to disable the Allow Inheritable Auditing Entries From Parent To Propagate To This Object option. This allows us to create custom settings to be applied to this folder. We also want to replace the audit settings on the objects contained in this folder, so we select the Reset Auditing Entries On All Child Objects And Enable Propagation Of Inheritable Auditing Entries check box. Click Apply and then click OK.

Figure DThe Access Control Settings dialog box after setting the type of actions to be audited for a particular group

1. Click Apply and then OK one more time to close the Properties dialog box.

You do not need to restart the computer for auditing of the objects to begin. The only time you need to restart the computer to support auditing is after you have configured the audit policy in the Local Security Settings console.

Auditing printer access
A printer is also an object, and therefore, it can be audited. Enabling auditing of a printer object is virtually the same as enabling auditing on a file or folder. However, there are differences in the types of events you can audit.

To audit a printer object, perform the following steps:

1. Open the Printers folder from the Control Panel.
2. Right-click on the printer object you wish to audit, and then click the Properties command.
3. After the Properties dialog box opens, click on the Security tab and then click on the Advanced button.
4. In the Access Control Settings dialog box for the printer object, click the Add button to add a user or group to audit. In the Select User, Computer, Or Group dialog box, select the user or group to audit, and then click OK.
5. The Auditing Entry dialog box will appear (Figure E).

Figure EThe Auditing Entry dialog box for a printer object

Table B explains the meanings of the various access settings. In the case of auditing a sensitive printer (such as a costly high-quality color laser printer), you will want to audit successful print jobs so that the department can be charged for usage. Click Apply and then click OK. Click OK one more time to close the Printer Properties dialog box.

Table B Access option Description Print Logs an event when a user tries to print a file. Manage Printers Logs an event when a user attempts to change printer settings or when the user attempts to pause, share, or remove a printer. Manage Documents Logs an event when a user changes a job setting such as restarting, pausing, moving, or deleting a document or when the user attempts to share the printer or change any of the settings in the printer’s Properties dialog box. Read Permissions Logs an event when a user attempts to view the printer permissions. Change Permissions Logs an event when a user attempts to change permissions on the printer. Take Ownership Logs an event when a user attempts to take ownership of the printer.
Descriptions of printer access options

Conclusion
In part one of this Daily Feature series, I discussed how to set the audit policy. This Daily Feature focused on how to set up your audit policies for your files, folders, and printers. Keep in mind that an overabundance of audit information can slow system performance and ultimately become too cumbersome to work with. When defining file, folder, and printer policies, use the Failure and Success check boxes sparingly to avoid excessive audit logs. In part three of this series, I will finish up with a discussion on best practices.

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-5033684.html?tag=btxcsim

Auditing resources on Windows 2000 Professional, part 3

This last installment of our three-part Daily Feature series on auditing using Windows 2000 Pro deals with setting up best practices for viewing your results. Tom Shinder explains how to analyze the data.
In part one of my series on auditing with Windows 2000 Professional, I showed you how to set the audit policy. Part two focused on enabling and configuring the audit of files, folders, and printers on your computer. This final lesson will deal with auditing best practices to ensure you get the desired results from your audit policy.

Auditing best practices
Consider your motivations for enabling auditing before implementing it. Do not enable auditing just because you can. The auditing process takes processor cycles and disk time and therefore can have a negative impact on overall system performance.

Consider auditing sensitive files and folders that contain material users may need to answer for in the future. Such files may include personnel files or payroll records. All companies have a rich store of sensitive memos and reports that contain proprietary information. You might want to audit all users that have permission to access these files so that you have a chronological account of when they were accessed and by whom.

Printer auditing is done more for accounting purposes than for security reasons. While you might find yourself in a situation where you wish to audit print jobs for users suspected of mass printings of their resumes or protected material, auditing is typically done to charge departments based on usage. Some printers have a very high per-page printing cost. The audit log provides a method to charge the department based on usage.

Table A includes some examples of security considerations and audit events you might want to implement for them.

Table A Security consideration Type of event to audit Possible virus infection Object Access: Success/Failure: Program Files (.exe & .dll) Process Tracking: Success/Failure Illegitimate access to confidential files Object Access: Success/Failure (on sensitive files) Object Access: Success/Failure (on printers that suspicious users may use to print sensitive material) Dictionary password attack Logon/Logoff: Failure Casual snooping or stolen passwords Logon/Logoff: Success/Failure Suggested audit schemes for different security scenarios

Using the Security log
To view the results of auditing, you must use the Security log in the Event Viewer. To view the Security log entries, perform the following steps:

1. From the Start menu, open the Administrative Tools menu and click on Event Viewer.
2. In the Event Viewer window, click on the Security Log node in the left pane (see Figure A).

Figure AThe Security log seen in the Event Viewer

Note in Figure A that there are a number of Success Audit entries. These entries indicate that an audited event was performed successfully. In the Category column, you can see that the success event was generated by an Object Access audit policy.

Double-click on one of these entries; you will see something like the dialog box that appears in Figure B.

Figure BViewing the details of an audited event

The Event Properties dialog box makes it easy to see some characteristics of the audited event. However, you must scroll through the Description section to see the full details. The Copy button (the button just under the down arrow) will copy the contents of the Description section to the clipboard. The full description for this event looks like this:

Full description of event
Event Type: Success Audit
Event Source: Security
Event Category: Object Access
Event ID: 560
Date: 4/27/2001
Time: 4:42:17 PM
User: TACTEAM\tshinder
Computer: EXETER
Description:
Object Open:
Object Server: Security
Object Type: File
Object Name: C:\Documents and Settings\tshinder\Desktop\Audit Me\~$dit Me.doc
New Handle ID: 808
Operation ID: {0,839900}
Process ID: 476
Primary User Name: tshinder
Primary Domain: TACTEAM
Primary Logon ID: (0x0,0x11764)
Client User Name: -
Client Domain: -
Client Logon ID: -
Accesses READ_CONTROL
SYNCHRONIZE
ReadData (or ListDirectory)
WriteData (or AddFile)
AppendData (or AddSubdirectory or CreatePipeInstance)
ReadEA
WriteEA
ReadAttributes
WriteAttributes
Privileges -

Saving Security log data for further analysis
You will amass a large amount of data in the Security log over time. The Event Viewer is not very functional when you need to collect and analyze the data gathered from your audit policies. You can get around this limitation by saving the Security log data as a delimited text file. These delimited text files can be either comma delimited or tab delimited. It becomes easy to import the data into a database or spreadsheet program after saving the Security log as a delimited text file. Data analysis using database and spreadsheet tools makes it much easier to view patterns and trends in your data.

Perform the following steps to save the Security log data as a delimited text file:

1. Right-click on the Security Log node in the left pane of the Event Viewer and click on the Save Log File As command.
2. In the Save Security Log As dialog box, click the down arrow in the Save As Type drop-down list box. Select either the Text (Tab Delimited) (*.txt) or CSV (Comma Delimited) (*.csv) option. Type in a file name and then click Save.

Importing log files into Excel
If you plan to use Microsoft Excel to analyze your data, export the data as Tab Delimited. The File Conversion Wizard brings the Tab Delimited text files into Excel in a more usable format. The Wizard converts .csv files into Excel in a way that puts a single event on multiple rows, which makes analysis using Excel tools difficult.

Summary
In this Daily Feature series, you’ve learned about the auditing features included with Windows 2000 Professional. You learned how to audit resources on Windows 2000 Professional computers by creating local audit policies. Some audit policies will allow auditing of events to take place immediately, without any other configuration. Object auditing requires that you configure a specific auditing parameter on a particular file, folder, or printer object. After you have configured your audit policies and object configuration, you can view the results of your auditing activities in the Security log in the Event Viewer. Large Security logs are difficult to use if you wish to analyze a large amount of data. To simplify data analysis, save the Security log as a delimited text file and import the file into a database or spreadsheet program.

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-5034308.html?tag=rbxccnbtr1

Step-By-Step: How to audit file and folder access to improve Windows 2000 Pro security

While auditing file and folder access on a client's home computer or a networked office machine is probably overkill, I recommend auditing any publicly accessible computer, whether it’s networked or not. Auditing file and folder access allows you to test your security policy and determine whether any users are trying to use the machine in an unauthorized manner.

For example, fellow TechRepublic contributor and friend Troy Thompson teaches high school computing courses. Since a classroom full of high school kids is about as hostile an environment as you're going to find, Troy audits each machine to detect any unauthorized use.

Enabling auditing
Before you can audit file and folder access, you must enable the Audit Object Access setting in the machine’s group policy. Log on to the machine with a local administrative account and open the Control Panel. Double-click the Administrative Tools icon and then the Local Security Policy icon. Doing so will display the machine’s group policy settings.

Navigate through the console tree to Security Settings | Local Policies | Audit Policy. When you select the Audit Policy container, the column to the right will display a number of different events that you can audit, as shown in Figure A.

Figure AYou can audit a number of events.

As you can imagine, it’s easy to get carried away with the idea of an ultrasecure machine by auditing absolutely everything. But this is a bad idea for several reasons. First, the audit process builds log files. Each entry in the log consumes a small amount of hard disk space. If too many audited events occur, your machine could run out of hard disk space. Second, each audit also consumes a small amount of CPU time and memory. So excessive auditing can negatively affect system performance.

Perhaps the best reason for not auditing everything is information overload. I have seen situations in which several hundred events are audited every minute. This makes it virtually impossible to locate anything useful within the logs because the useful log entries blend in with the garbage entries. My advice is to use discretion when creating an audit policy. Don’t audit anything that you don’t absolutely need to know about. The more you refine which events are audited, the more meaningful each audited event will become.

Let’s take a look at some of the available auditing options. Obviously, which audits are appropriate for your needs will vary depending on your environment. For general purpose auditing, though, I recommend auditing logon events so that you can tell when users have logged on or off. I also recommend auditing object access (i.e., files and folders). Auditing object access will allow you to see who does what to designated files and folders. Finally, I recommend auditing policy changes. This is a big one, because if someone is tampering with the machine’s security policy, you really need to know about it.

To enable these types of auditing, double-click the appropriate option within the Local Security Policy Settings console. You will then see a dialog box similar to the one shown in Figure B. As you can see in this figure, you can implement a failure audit and/or a success audit for each event.

Figure BYou can perform success and/or failure audits for each event.

So how do you know whether to perform a success or a failure audit? Well, that’s really up to you. For logins and policy changes, I recommend auditing both success and failures. For example, a success audit of login actions would create an audit log entry every time someone logged in successfully. A failure audit of the same event would write an audit log entry every time someone entered a password incorrectly. Likewise, a success audit on policy changes would let you know that someone changed a security policy, while a failure audit would tell you that someone tried to change a security policy but didn’t actually manage to make the change happen.

When it comes to auditing object access, I recommend also enabling success and failure audits. Just because success and failure audits are enabled for object access, though, it doesn’t mean that you actually have to use them. Every object that you audit access for has an entire range of audit options. Enabling success and failure audits simply make these options available to you.

Auditing object access
You must be careful which objects you audit or you will end up with the information overload problems. It's very easy to end up with information overload because if you audit a folder, the audit applies to every object within the folder and within any subfolders. The audit applies to child objects, grandchild objects, and so on. So when possible, I recommend auditing objects at the file level. For example, if you needed to know who made the most recent changes to an Excel spreadsheet, it would be better to audit the actual XLS file than the folder containing it.

I also recommend that you avoid auditing system files and folders. Doing so can also result in information overload. For example, if you were to audit the Windows folder, you would end up with countless audit log entries because the system is constantly accessing files found in this folder. If you really wanted to audit Windows, a better solution might be to audit the registry files.

To audit a file or folder, right-click it and select the Properties command from the resulting menu. You’ll see the object’s Properties sheet. Select the Properties sheet’s Security tab, and click the Advanced button to display the Access Control Settings Properties sheet for the object. Select the Auditing tab. Then, click the Add button, and you’ll be presented with a list of users and groups. Select the users or groups that you wish to audit, and click OK.

For example, years ago, I worked for a large insurance company. At the company, a woman on the administrative staff was deliberately doing things to sabotage the system. Before we confronted her with this information, we needed to build a case against her. So we created audit policies that applied only to her. This way, we could watch every move she made without being flooded with thousands of log entries pertaining to other users.

Once you have selected a user or group, you’ll see the dialog box shown in Figure C. As you can see, you can enable success and/or failure audits for many types of access to the file or folder on a user or group basis.

Figure CYou can audit a number of different access types for files and folders.

Viewing audit results
You might be curious to know how to view the audit results. Open the Control Panel and double-click the Administrative Tools icon and then the Event Viewer icon. When the Event Viewer opens, click the Security container to see the security logs, as shown in Figure D. In the figure, you’ll notice how many log entries were applied in a matter of a few seconds. This is why it’s so important to use discretion when creating an audit policy. If you want to get more information on a particular event, simply double-click it.

Figure D