Windows System Group Policy application latest tips _windowsxp

System Group Policy is almost a network management personnel to manage the network, one of the necessary tools, the conventional application of the tool skills, I believe many people have been familiar with. But the author has always believed that as long as we are careful and attentive, we will continue to explore new application techniques from the System group strategy. If you don't believe it, take a look at the following, and believe that they will help you enter a new realm of application.

　　 skillful limit procedure, beware of "self-locking"

There is a Group Policy project in the Windows Server named "Allow only Windows applications to run", once you have enabled the project and restricted the specified program to run, whether or not you have added the Gpedit.msc command in the "Allow only running programs list", as long as " Only the Group Policy project that is allowed to run Windows applications is in effect, and the system's Group Policy is automatically "self-locking", and even if you use the "gpedit.msc" command under the Super Administrator account, you cannot open the system's Group Policy editing window! So is there a way to limit the operation of the application, Can prevent system Group Policy from appearing "self-locking" phenomenon? The answer is yes, you can follow the steps below:

First click the start/Run command, and in the system Run box that pops up, enter the string command "Gpedit.msc", and then click OK to open the System Group Policy editing window;

Expand the User Configuration/Administrative Templates/System items in the window, and in the child window to the right of the corresponding system item, double-click the run only licensed Windows Application option, and in the interface that pops up, select the Enabled option. You will then see the display button automatically activated in the corresponding window, click the "Show" button, and then continue to click the "Add" button in the window, and then enter the name of the application you want to run in the Add Settings box, and then click OK.

Below, please do not close the Group Policy editing window immediately, and then open the System Run dialog box, and execute the "gpedit.msc" command, you will find that the System Group Policy Editor has not been able to run! However, thanks to the failure to close the Group Policy editing window before, Now you can go ahead. In the Group Policy editing window, double-click the "Allow only Windows applications" project that you just set up, and then in the Policy Settings window that pops up, select the Not Configured option, and then click OK, so that you can limit the purpose of running your application. can also prevent system Group Policy from appearing "self-locking" phenomenon.

Tip: If you add the specified application name to the "Allow Windows applications only" list, you can restore the Group Policy editing window directly by following these steps:

Reboot the server system, press the F8 function key during the boot process until the System boot menu appears, and then execute the "Safe Mode with Command Prompt" command, and switch the server system to the command prompt state;

Next, execute the mmc.exe string command directly from the command prompt, in the system console interface that pops up, click the File menu item, click the Add/Remove snap-in option from the pop-up Drop-down menu, click the Standalone tab in the window below, and then, in the label page shown in Figure 1, click Add "button;

Next, click Group Policy, and then clicking Add, Finish, close, OK, so that you can successfully add a new Group Policy console; Later, you can reopen the Group Policy editing window, and then follow the settings above to achieve the purpose of restricting the running of the application. can also prevent system Group Policy from appearing "self-locking" phenomenon.

　　 free from "self-locking"

In addition to restricting the application's running policies, there are a number of actions that can cause Group policy to inadvertently occur as a "self-locking" phenomenon. If there are other factors that cause Group Policy to "self-locking" phenomenon, how can we easily lift it? In fact, all settings for Group Policy are based on the system registry >, so the settings for any branch of Group Policy are reflected in the corresponding branch of the registry; so we just start by modifying the registry, You can easily break the "self-locking" behavior of Group Policy:

Click the start/Run command, in the pop-up System Run dialog box, enter the string command "regedit", and then click OK to open the System's Registry editing window;

In the window, expand the registry branch Hkey_current_user\software\policies\microsoft\mmc\{8fc0b734-a0e1-11d1-a7d3-0000f87571e3} in turn, In the right area of the window that pops up as shown in Figure 2, you'll see a "restrict_run" key value;
With the mouse double-click the key value, open a Numeric Settings window, enter the number "0", and then click OK, and then when you open the System Run dialog again and execute the "gpedit.msc" command, you will find that the Self-Locking Group Policy editing window can now be easily opened.

　　 policy changes, immediate effect

For Windows 2003 domains or Windows 2000 domains, once the default security policy for a domain has been modified, the new security policy does not take effect immediately, and it typically takes about 5-15 minutes for Windows systems to automatically update the settings in System Group Policy. Is there any way to make the modified security policy effective immediately to the user or client? The answer is yes, you can follow the steps below to achieve:

For Windows 2000 domains, if you want the newly modified computer policy to take effect immediately, click the start/Run command, open the System Run dialog box, enter the string command "cmd", and then click OK. Switch the Windows system to MS-DOS mode;

Then at the DOS command prompt, the input string command "Secedit/refreshpolicy Machine_policy/enforce", the new modified security policy will take effect immediately after clicking the ENTER key;

If you want the newly modified user policy to take effect immediately, just execute the string command "Secedit/refreshpolicy User_policy/enforce" at the DOS command prompt.

For Windows 2003 domains, if you want the newly modified computer policy to take effect immediately, click the start/Run command, open the System Run dialog box, enter the string command "cmd", and then click OK. Switch the Windows system to MS-DOS mode;

Then at the DOS command prompt, the input string command "Gpupdate/target:computer" and the new modified security policy will take effect immediately after you click Enter.

If you want the newly modified user policy to take effect immediately, just execute the string command "Gpupdate/target:user" at the DOS command prompt. If you want to update the computer policy and the user policy at the same time, you can simply execute the string command "gpupdate" on the line.

　 different users, different permissions

Maybe your server contains a lot of users, but in order to protect the security of the server, you want these users to the server's access control permissions are different, so that in the future when the server encountered an accident, you can, depending on the level of authority, you can quickly find "from the chaos" users. To assign different access control rights to different users, you only need to set up the server Group Policy, the following is the specific setup steps:

Click the start/Run command, and in the system Run box that pops up, enter the string command "Gpedit.msc" and open the System Group Policy Editing window when you click OK.

In the window, expand the Computer Configuration/Windows Settings/Security Settings/Local Policies/user rights Assignment items in the box;

In the right window area corresponding to the User Rights Assignment project, you will see multiple rights to assign, as shown in Figure 3. For example, if you only want AAA users to remotely access content on the server via a network connection, rather than allowing them to write content or execute applications in the local login server, you can double-click the "Deny local logon" right first;
In the Settings window that opens, click Add, and then select the account name for the AAA user, then click Add, so that AAA users will be able to access the contents of the server from the remote network later.

Similarly, you can assign local login control rights to BBB users, assign ownership of files or other objects to CCC users, etc. once you have assigned different control rights to different users, you will be able to manage and control users in the future according to the different levels of authority. For example, if you find that the server is not connected to the network time, someone at random to upload illegal information to the server and need to be investigated, you can easily exclude AAA users, after all, AAA users do not have such "criminal ability"!

　　 protection settings, avoiding conflicts

In the local area network, the workstation IP address is often changed randomly, resulting in the occurrence of IP conflict, which affects the operation efficiency of LAN. Although there are many ways to avoid IP address conflicts, but carefully, you can not find some of these methods for some novice users to bear the  of the 隳 from the armed? In fact, with the help of Group Policy, you can easily limit the network configuration parameters of LAN workstations to be arbitrarily modified, To effectively avoid conflicts with IP addresses in your network:

Click the start/Run command, and in the system Run box that pops up, enter the string command "Gpedit.msc" and open the System Group Policy Editing window when you click OK.

Expand the User Configuration/Administrative Templates/Network/network and dial-up connections policy items in the window, and in the right window area for the network and dial-up connections policy, double-click the Allow TCP/IP advanced Settings project;

In the Settings window that pops up as shown in Figure 4, select the Disable option and click the OK button so that any workstation user who opens the TCP/IP Properties Settings window will find it impossible to go to the Advanced Settings window to modify the workstation's IP address or other network parameters. So the IP address in the LAN is not easy to conflict.
　　 enhanced audits, away from attacks

By default, Windows 2003 servers do not have any security auditing enabled to secure the server, which obviously poses a significant security risk to the server. To prevent the server from being attacked, you can enable security audit policy and secure the server by simply "moving hands and feet" on Group Policy in the server:

Click the start/Run command, and in the system Run box that pops up, enter the string command "Gpedit.msc" and open the System Group Policy Editing window when you click OK.

Positioning the mouse over the computer Configuration/Windows Settings/Security Settings/Local Policy/Audit Policy Group Policy Branch, under the Audit Policy Branch, you will see a number of audit events that require you to specify, as shown in Figure 5;
Double-click the policy change project in the pop-up Settings window, if the "Success" option is selected, then the server will review the success of all events at a later date, if the "Failure" option is selected, then the server will be the failure of all events to audit;

In order to be able to know the security potential of the server early, we typically need to audit the successful operations and failures of system events, logon events, account logon events, account management events, and so on, even if some of the operational records that have been implemented have not been successfully attacked, will be automatically recorded by the server, after careful analysis of the records, we can find out the security risks, and take timely remedial measures to ensure the security of the server; For object access events, directory service access events, privilege usage events, and so on, you typically simply audit their failure operations. Can achieve the goal of capturing the attack record.

Once the auditing function is enabled for the related events individually through Group Policy, the server will save the audit records of related events to the system "Event Viewer" in the future, if you open the log content in time, and carefully analyze the records, you can find out if the server is under attack at this time.