صفحه 1 از 2 1 2 آخرینآخرین
نمایش نتایج: از شماره 1 تا 15 از مجموع 18

موضوع: lock شدن ویندوز

  
  1. #1
    نام حقيقي: محمد

    عضو عادی
    تاریخ عضویت
    Dec 2008
    محل سکونت
    ایران
    نوشته
    223
    سپاسگزاری شده
    36
    سپاسگزاری کرده
    16

    lock شدن ویندوز

    با سلام
    برخی از وبندوزهای شبکه دومین بدون اینکه بهش ریموت کانکت شن و یا تو تنظیمات screen saver تیک on resume password protect زده شده باشد بصورت ناگهانی lock می گردد.در ضمن چطور می تونم بفهم کی به اون کامپیوتر ریموت شده یا به درایوهای اون از طریق $ وارد شده تو event viewer دومین کنترلر هر چی گشتم نبود.ممنون میشم راهنمایی کنین



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

  2. #2
    نام حقيقي: محمد

    عضو عادی
    تاریخ عضویت
    Dec 2008
    محل سکونت
    ایران
    نوشته
    223
    سپاسگزاری شده
    36
    سپاسگزاری کرده
    16
    کسی نمی تونه کمک کنه



  3. #3
    نام حقيقي: محمد

    عضو عادی
    تاریخ عضویت
    Dec 2008
    محل سکونت
    ایران
    نوشته
    223
    سپاسگزاری شده
    36
    سپاسگزاری کرده
    16
    خواهش می کنم یکی منو راهنمایی کنه چطور می تونم بدونم چه اتفاقی برای اون کامپیوتر افتاده تو event viewer تو security هیچی نشون داده نمیشه از رو سرور چه جوری می تونم ببینم؟



  4. #4
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    دوست عزیز شما باید Audit را در Group Policy فعال کنید
    Computer Configuration
    Windows Settings
    Security Settings
    Audit Policy




  5. #5
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    تنظیم زمان Screen Saver از طریق Group Policy

    User Configuration
    Administrative Templates
    Control Panel
    Display
    Screen Saver timeout

    برای فعال یا غیر فعال کردن Screen Saver از طریق Group Policy

    User Configuration
    Administrative Templates
    Control Panel
    Display
    Screen Saver



    ویرایش توسط patris1 : 2009-10-12 در ساعت 03:29 PM

  6. #6
    نام حقيقي: محمد

    عضو عادی
    تاریخ عضویت
    Dec 2008
    محل سکونت
    ایران
    نوشته
    223
    سپاسگزاری شده
    36
    سپاسگزاری کرده
    16
    ممنون از راهنمایی تون پس من اگه اون پالیسی رو تو dc فعال کنم تو event viewer کامپیوترهای یوزرا می تونم ببنین ؟



  7. #7
    نام حقيقي: محمد

    عضو عادی
    تاریخ عضویت
    Dec 2008
    محل سکونت
    ایران
    نوشته
    223
    سپاسگزاری شده
    36
    سپاسگزاری کرده
    16
    من تو group policy دومین کنترلر audit policy رو فعال کردم اما باز نمی تونم ببینم.



  8. #8
    نام حقيقي: محمد

    عضو عادی
    تاریخ عضویت
    Dec 2008
    محل سکونت
    ایران
    نوشته
    223
    سپاسگزاری شده
    36
    سپاسگزاری کرده
    16
    خواهشاً یکی کمکم کنه



  9. #9
    نام حقيقي: محمد

    عضو عادی
    تاریخ عضویت
    Dec 2008
    محل سکونت
    ایران
    نوشته
    223
    سپاسگزاری شده
    36
    سپاسگزاری کرده
    16
    یعنی من نمی تونم از طریق GP برای تمامی کامپیوترهای شبکه Audit policy را فعال کنم که بتونم event های مربوط به security هر کامپیوتر را تو event viewer خودش ببینم.ممنون می شم راهنماییم کنین



  10. #10
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    ویرایش توسط patris1 : 2009-10-13 در ساعت 10:05 AM

  11. #11
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    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 A



    You 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







  12. #12
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    What is auditing


    In its simplest form, auditing is nothing more than creating a record of events. These events can be performed by users or by the servers themselves. An example of such an event might be a user logging in to the network. If you wanted to audit logins, you could actually create a record of every time that each user logged in to the network. All of the events you monitor are documented in Windows Server 2003's security log.

    Okay, so auditing provides a method for documenting system and user events, but how can you make the security log useful? After all, if you audit every user and every system event, it's possible that the server will log hundreds of events every minute. I've lost count of the number of times that I've seen administrators log every single event in the name of good security. In such situations, the security log can quickly fill up, meaning that no more events will be logged until the log has been cleared out.

    Excessive logging can also cause performance problems for the server since logging consumes disk and processor time. Another downside to logging every event is that the logs cease to be meaningful. If you suspect that a security breach may have occurred, locating a record of it can be like looking for the proverbial needle in a haystack.

    As you can imagine, a better process is to audit only meaningful events rather than every single event in the entire system. After all, who cares if Fred in Accounting created a new spreadsheet this morning? Instead, you should look for and create logs of things that could potentially damage your network or its data, such as someone being granted administrative privileges or files being deleted from an important directory. In the sections that follow, I'll show you some guidelines you can follow to create an effective audit policy.
    Success or failure


    Before you audit anything, you should understand a little bit about how the auditing process works. When you audit an event, you can audit it by success, failure, or both. For example, suppose that you wanted to audit logins to the network. Depending on the size of your network, success audits may be overkill because they would create a security log entry every time that someone logged in. As alluded to above, this would create log files that grow quickly and become cumbersome to work with.

    A more effective technique might be to use a failure audit for network logins. A failure audit would create a security log entry only if a user tried to log in and was unsuccessful. You could then review the audit log to see who had trouble logging in to the network. If a user's name appears only once in the security log, then you could probably assume that the user simply typed their password incorrectly. If you discover that a particular user has tried to log in unsuccessfully a number of times--especially after business hours--then you may want to investigate the invalid login as a possible hack attempt.

    If you make such a discovery, you can take steps to counteract the hack attempt. These steps might include things like creating a policy that disables user accounts after three bad login attempts within a few minutes. If the hack attempts continue, you might look at what time the attempts are made each night and try to catch the hacker red-handed.
    Enabling auditing


    Now that you have a basic idea of what auditing is and how it works, it's time to begin building an audit policy. I'll start by showing you how to audit an event. Once I've done so, I'll explain which events that I recommend auditing.

    As I mentioned earlier, auditing is configured through the use of an audit policy. You can set an audit policy to be applied to domain controllers, member servers, stand-alone servers, or workstations. If you apply a non-local audit policy to a domain controller, all other domain controllers within the domain will share that audit policy. I strongly recommend auditing all domain controllers because they are so crucial to your organization's security. It's also not a bad idea to audit member servers or stand-alone servers too if they contain any sensitive or confidential data. I don't recommend auditing Windows XP Professional workstations, unless you have a very specific reason for doing so. It's simply too time-consuming and inconvenient to constantly review the audit logs on every single workstation.

    Before you begin to build an audit policy, I should point out that to do so you must have the Manage Auditing And Security Log user right. The Administrator account has this right by default, but if you want a nonadministrator to manage the auditing, you'll have to grant them the appropriate permissions. In actuality, having a nonadministrator to do the auditing isn't a bad idea. You can remove the Manage Auditing And Security Log user right from the administrator's group to ensure that only one person has rights to the audit log. This is one way to keep administrators honest, since they won't be able to clear the security log after a misdeed.

    The process of enabling auditing is similar for domain controllers and non-domain controllers. The biggest difference is that you use a different tool to get the job done. To set up an audit policy for your domain controllers, open the Active Directory Users And Computers console and navigate through the tree to Domain Controllers. Right-click Domain Controllers and select the Properties command from the resulting context menu.

    When you do, you'll see the Domain Controllers properties sheet. Now, go to the Group Policy tab, select the group policy that you want to audit, click Edit, and Windows will load the Group Policy console. Navigate through the group policy console to Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy, as shown in Figure A. You're now at a point where the basic auditing technique is the same for both domain controllers and non-domain controllers.
    Figure A
    Navigate to Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy.
    To set up auditing for a non-domain controller, open the Local Security Policy console and navigate through the tree structure to Security Settings | Local Policies | Audit Policy. You can see an example of this screen in Figure B.
    To set up auditing for a nondomain controller, open the Local Security Policy console and navigate to Security Settings | Local Policies | Audit Policy.

    From this point, the technique is the same whether you're on a domain controller or not. Let's audit an event. For demonstration purposes, we'll audit failed login attempts. As you can see in Figures A and B, Windows lists several different types of events that can be audited. One of these events is Audit Account Logon Events.

    To audit a logon failure, right-click Audit Logon Events and select the Properties from the resulting context menu. When you do, you'll see a dialog box that will allow you to audit the events. The dialog box will vary slightly depending on whether or not you're auditing a domain controller.

    If you're auditing a domain controller, you must select the Define These Policy Settings check box before you'll be able to audit an event. This check box doesn't exist when auditing nondomain controllers. At any rate, you'll now be able to audit an event success, failure, or both. For the purpose of auditing login failures, select the Failure check box, as shown in Figure C, and click OK.
    Figure C
    You can audit the success or failure of an event by simply selecting a check box.

    Once you've set up the audit policy, you must apply it. To do so, you must either type a command at the command prompt, reboot your server, or wait until the next propagation cycle, which is usually every eight hours. If you decide that typing the command is the easiest method, open a command prompt window, type GPUPDATE /target:computer and press [Enter].
    What needs to be audited?


    Now that you know how auditing works, the first question that you should ask yourself is what really needs to be audited? As I mentioned, I always recommend auditing domain controllers, and if the situation applies, member servers and stand-alone servers. But what should you audit on those servers? I recommend that you audit the following items:

    • Logon failures
    • Policy changes
    • Privilege use
    • Account management
    • Any directories that are confidential or sensitive (a file-level audit)


    Before I get into file-level auditing, there are a couple of helpful hints that I should point out. First, it's a good idea to audit just about everything that members of the Administrator's group do. The reason for this is that a hacker will typically try to gain administrative access before attacking your system. Therefore, such an attack would likely show up as an administrative action.

    Another tip is that when auditing users, you should audit the Everyone group instead of the Users group. The reason for this is that the Users group includes only authenticated users. It doesn't cover anonymous users who may have slipped through your Internet firewall. The Everyone group, on the other hand, covers all users whether or not they are authenticated.
    File-level auditing


    Before you can audit a file, directory, or other object, you must enable Object Access auditing by using the method that I demonstrated earlier. Once you've enabled object auditing, go into Windows Explorer and navigate to the object that you want to audit. Right-click the object and select the Properties command from the resulting context menu.

    When you see the object's properties sheet, navigate to the Security tab and click the Advanced button. You'll now see the Access Control Settings For dialog box. Next, select the Auditing tab, click the Add button, and select the users or groups that you want to audit. Click OK to continue. You'll now see a long list of auditable actions related to the object. You can perform a success and/or failure audit on any of these objects by selecting the appropriate check boxes. Click OK to enable the auditing.
    Review the security logs


    One of the most important things that you need to know about auditing is that the simple act of auditing won't alert you to a security breach or an attempted break-in. It's up to you to read and understand what the security log entries mean. I recommend reading the security log the first thing in the morning, right after you change the backup tape. By doing so, you'll get into a routine, and you'll always be aware of your network's security.




  13. #13
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    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.




  14. #14
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Enabling audit logging

    To enable audit logging on a Windows XP system, you will have to log in as a user with local administrative privileges. After doing so, open Control Panel and then click the Performance And Maintenance link, followed by the Administrative Tools link. Next, double-click the Local Security Policy icon to open the Local Security Settings container. Now, navigate through the console tree to Security Settings | Local Policies | Audit Policy. When you do, you will see the screen shown in Figure A.
    Figure A
    This is where you set the local audit policy. When you double-click on any of the audit policy elements, you'll see a screen similar to the one shown in Figure B that allows you to audit successes, failures, or both. The first audit policy element is Account Logon Events. If you were to do a success audit, a log entry would be created every time someone successfully logged in to the machine. A failure audit would be generated any time that someone attempted to log in to the machine, but was not able to successfully authenticate.
    Figure B
    You can audit success or failure events. There are also a few other audit options available within the console at Security Settings | Local Policies | Security Options. These additional audit policies work a little bit differently from the other audit policy elements I mentioned above. These settings are either enabled or disabled. There is no success or failure option associated with them. The reason these objects behave differently is because they are global in scope. For example, you can audit the access of global system objects, as well as the use of backup and restore privileges. You can also set an option to shut down the system if it is unable to log auditing information, although I don't recommend using this option.
    The Event Viewer

    All of this audit information is logged to the Security container within the Event Viewer, as shown in Figure C. You can access the log by opening Control Panel and clicking the Performance And Maintenance link, then the Administrative Tools link. Next, double-click the Event Viewer icon. Once the Event Viewer opens, select the Security container to view your audit log. To view more detailed information about a log entry, double-click the entry. This will open the Event properties sheet, as shown in Figure D.
    Figure C
    The Event Viewer contains all of your computer's security audit logs. Figure D
    Double-clicking an event causes Windows to display additional information about the event. Pitfalls of auditing

    I would be negligent if I didn't explain that it takes a certain skill to properly set up auditing events. As you've seen, it is extremely easy to enable auditing for an event. You've also seen that there are only a handful of event types that you can audit. It might seem as though the most appropriate thing to do is to enable success and failure auditing for all types of events.
    However, selecting all events is actually a really bad idea. The success and failure of every available event can quickly fill up the audit logs. There is a finite amount of space that is set aside for the audit logs. By default, that amount of space is 512 KB. You can change the default log size by right-clicking the Security container within the Event Viewer and selecting the Properties command from the resulting shortcut menu. For now though, let's just assume that you have a maximum log file size of 512 KB.
    For instance, if you select the audit option that tells Windows XP to shut down the system if it can't write data to the log files, and the log file reaches 512 KB, then you won't be able to boot the system. This is why I recommend not using that option. It's better to allow Windows to simply overwrite old events as needed.
    Whichever option you choose, it's conceivable that the event logs will eventually reach 512 KB in size. Since audit log data is text based, a 512-KB file can store a large number of log entries. This can present a particular problem when searching for a particular event. Events are organized by date and time. Therefore, if the audit log is 512 KB in size and contains entries from the last month, and you're looking for an event that happened yesterday, finding that event will be relatively easy. Imagine how hard it would be to find the event that you are looking for, however, if you had hundreds of log entries for every single day. Worse yet, imagine what it would be like to try to find an event that just happened if Windows is logging over a thousand events per hour.
    So, if you enable every possible auditing option, Windows can bombard the log file with thousands of entries. The vast majority of these entries will likely be irrelevant to your search. It's therefore best to limit the scope of the objects being audited. By auditing only the really important events, you are much more likely to be able to find the events that really matter to you.
    What to audit

    What are the really important events that you should be auditing? The truth is that it varies depending on your situation. At a minimum, I would suggest auditing the success and failure of account logon events, account management, and policy changes. You may want to audit additional event types, but that's up to you. Generally, I would not audit directory service access or system events, because these are the options that tend to really flood your audit logs. When deciding what to audit, remember that if an event has already occurred, it's too late to go back and audit it. So you need to anticipate the types of events that could occur and be set up to audit them.




  15. #15
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Solutions

    The server capacity problem is an easy one on the surface, but the answer depends on your circumstances. There are really three things you can do to try to address this issue.
    First, the most obvious solution is to increase the capacity of the server, if possible. This is commonly known as the "throw more horsepower at it" solution. It may solve the problem, but it can be expensive and might not be necessary.
    The second solution requires some analysis, but is a better longer term solution and will probably cost less in the long run. Basically, watch how your terminal server operates and make note of certain findings, such as the amount of RAM used by a user's applications. You may find that certain applications simply use too much RAM or too much horsepower to be served up using a terminal server. To see how much RAM a particular user is using for applications, open Start | Administrative Tools | Terminal Services Manager and select the connection you'd like to get information about. On the processes tab—see Figure A—you'll get a list of that connection's active processes. Make note of the process IDs (PIDs) for each process.
    Figure A
    Use the Processes tab to show what the user is doing. Open Task Manager and check the box at the bottom of the Processes tab marked Show Processes From All Users. Find the PIDs from your list. You may need to add the PID column to the Task Manager view. You can do this by choosing View | Select Columns and adding the PID (Process ID) column. See Figure B for a sample, and notice that Paint Shop Pro is using five percent of the CPU and quite a lot of RAM.
    Figure B
    Paint Shop Pro is being run by two users and using five percent of the CPU. (In the real world, programs such as Paint Shop Pro use a whole lot of CPU time and aren't usually suitable for Terminal Services. It was used here solely as an example and definitely is not recommended.)
    How does investigating individual processes help? With some applications, you can disable certain CPU-intensive features, allowing them to act a little more friendly in a Terminal Services environment. For example, Microsoft Word has a background spell and grammar checker that consumes significant resources. Before deploying applications, or when you start to see terminal server performance degradation, audit your particularly heavy applications to see if you can make them a little easier on the power.
    Finally, if you're truly maxed or don't have time to audit your applications, you can always add a different kind of horsepower in the form of additional servers. Consider moving a few of your power users to a separate box to ease up on the others.
    Open, Sesame!

    Do you have a user who can't log in to the terminal server? Windows might be so kind as to provide you with an error message along the lines of "The local policy of this system does not permit you to log on interactively." This is Microsoft's way of saying that you don't have permission to use the services. It basically boils down to an access problem.
    Solutions

    These errors can be more difficult to troubleshoot. The most common problem is that the user isn't a member of the Remote Desktop Users group. However, beyond that, you may need to track down file system and/or registry keys to which an application needs access, and then either grant that access or find a way around it.
    If, for some reason, you don't want to use the Remote Desktop Users group, you can also change the local computer policy or the group policy for the domain. To do this, open the Group Policy Object Editor (gpedit.msc). Alternatively, you can open Start | Administrative Tools | Local Security Policy. Browse to Local Computer Policy | Computer Configuration | Windows Settings | Security Settings | Local Policies | User Rights Assignment, and add the appropriate user or group to the Allow Log On Locally policy, as shown in Figure C.
    Figure C
    Change the local (or domain) security policy. Some applications require fairly significant modification in order to work properly. Look in the C:\WINDOWS\Application Compatibility Scripts directory for installation, logon, and uninstall scripts for certain programs.
    Another common problem lies in the failure to initialize an application before deploying it to your users. For some applications, you should start the program and answer any configuration questions it asks before ending the Add/Remove Programs installation shell. (See the article "Implementing Terminal Services in Windows Server 2003" for more information.)
    Next, keep this in mind: Someone has probably already made it work. Look for those resources to see what they did. Sure, this is an easy answer, but guess what? It works! For example, some folks have taken significant time to compile a list of applications that work under Terminal Services and provide instructions on how to make them work. Microsoft also has a list of popular applications that are known to have problems under Terminal Services for Windows 2000. Take a look at Microsoft's list to see if your application appears, and follow the instructions to attempt to correct the situation.
    Finally, bear in mind that Terminal Services can run in two security modes—relaxed and full. Full security is preferred, but not always possible. If you have an application that you need and it doesn't work under full security mode, try it under relaxed mode. Go to Start | Administrative Tools | Terminal Services Configuration. Select Server Settings and change Compatibility Mode to Relaxed. (Learning how to write scripts to solve some of these problems is probably a good idea.)
    Mac and Linux

    Here's a short one: You have users with Macs or Linux machines and want them to be able to use your new terminal server.
    Solution

    There are perfectly usable clients out there that let you make full use of Terminal Services on non-Microsoft platforms. For Linux, take a look at rdesktop, an open source client for NT/2000/2003-based terminal servers. Rdesktop requires no additional software to be installed on the terminal server.
    For Mac OS X users, Microsoft provides a free Terminal Services client available for download from its Web site. This client requires Mac OS X 10.2.8 or better.
    Using either of these clients, you can also connect to Windows XP-based machines that allow remote desktop connections. This could be a great option for a help desk that uses Macs but has to support PCs.
    Can't find remote administration mode

    If you're coming to Terminal Services in Windows Server 2003 right from a Windows 2000 installation, you might be trying to use it the way it was always used previously. Windows 2000 supported the installation of Terminal Services in remote administration mode, which provided you with a built-in method to remotely manage the server.
    Solution

    Microsoft has seriously revamped the multiuser capabilities of Windows in both XP and Server 2003. Both operating systems include the same functionality as Windows 2000 Terminal Services in remote administration mode without your having to install additional software components. To enable this feature, go to Start, right-click My Computer and select Properties, then select the Remote tab. Enable the Allow Users To Connect Remotely To Your Computer check box.
    Speed problems

    Besides hardware sizing issues, you might run into situations in which users complain about a connection to a terminal server being especially slow. This is particularly true for low-bandwidth connections. If you're sure that the hardware is not to blame, there are probably things you can do to help them out.
    Solutions

    A prime culprit for this problem is the remote desktop background. Redrawing a background on the screen can require a tremendous amount of bandwidth. Disable the remote background, and performance will noticeably improve. Furthermore, for very slow connections, consider lowering the screen resolution so there is less to draw.
    It's not all that bad

    A Terminal Services server can be your friend most of the time, but definitely requires more care and feeding than a stand-alone file and print server or locally installed applications on a single PC. Fortunately, it can reduce administration, save staff time, and provide a more secure environment once you get past some of the problems that can pop up.



    katsi_ppp و IPHON سپاسگزاری کرده‌اند.

صفحه 1 از 2 1 2 آخرینآخرین

کلمات کلیدی در جستجوها:

1

2

3

the local policy of this system does not permit you to logon interactively

10دلیل ارورthe windows installer service could not be accessed. this can occur if the windows installer is not correctly installed. terminal serverthe local policy of the system does not permit you to logon interactively windows server 2003locked شدن computerغیر فعال کردن locked شدن در ویندوزwan تنظيمات WIN XPIcon for failure audit in windows server 2008shutdown event tracker مشکل در کانکت شدن به سرور غیر فعال بودن تیک remote desktop در ویندوز سرور 2008lock شدن صفحه httpارور the system has been shut down در ویندوزdomain controller security policy picturesمعنی خطا an error has been loged to the system event logaudit account logon events توcmslog complaint.doparam=saveLog complaintaudit success event viewerعلت غیر فعال شدن وردعلت غیر فعال شدن wordارورthe widows installer service could not be accessedانواع برنامه های کاربردی در اکتیو دایرکتوری مثل user lock

برچسب برای این موضوع

مجوز های ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •