Methods of Restricting Registry Access phần 3

Chia sẻ: Nghia Tuan | Ngày: | Loại File: PDF | Số trang:7

Thêm vào BST

Báo xấu

78
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Windows Server 2003 built-in local security groups (the screenshot is taken on the domain controller) Standard security settings are applied by Security Configuration Manager during the operating system installation,

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Methods of Restricting Registry Access phần 3

Figure 9.10: Windows Server 2003 built-in local security groups (the screenshot is taken on the domain controller) Standard security settings are applied by Security Configuration Manager during the operating system installation, when the GUI setup starts. For this purpose, the Security Configuration Manager uses security templates located in the %SystemRoot%\inf folder. Naturally, the template used for applying default security settings depends on the OS being installed and the computer's role in your network environment. When you perform a clean installation of workstations running Windows XP Professional, the %SystemRoot%\inf\defltwk.inf security template will be used (notice that upgrades from Windows 9x platforms are treated as clean installs). If you are upgrading to Windows XP from Windows NT/2000, Security Configuration Manager will use the %SystemRoot%\inf\DWUp.inf security template. When you perform a clean installation of Windows Server 2003 member server, default security settings are taken from the %SystemRoot%\inf\defltsw.inf security template, while for upgrades-from the %SystemRoot%\inf\dsup.inf template. For domain controllers, the %SystemRoot%\inf\defltdc.inf template is used. When you upgrade domain controllers from Windows NT 4.0, the Security Configuration Manager will use the %SystemRoot%\inf\dcup.inf template. Note If you want to affect the security settings that are applied by default during installation, you can modify the above-mentioned security templates in the installation files folder. As was already discussed, for standalone computers or computers participating in a workgroup, users belonging to the Administrators group have unlimited access to all file system and registry objects. Users and Power Users have a more restricted set of access rights. Note Windows XP and Windows Server 2003 include a new root ACL, which is also implemented by Format and Convert commands. In addition to previous releases,
the Security Configuration Manager now secures the root directory during setup, if the current root security descriptor grants the Everyone group Full Control permission. This provides increased security for non-Windows directories. The new root ACL is as follows: • Administrators, System: Full Control (Container Inherit, Object Inherit) • Creator Owner: Full Control (Container Inherit, Object Inherit, Inherit Only) • Everyone: Read\Execute (No Inheritance) • Users: Read\Execute (Container Inherit, Object Inherit) • Users: Create Directory (Container Inherit) • Users: Add File (Container Inherit, Inherit Only) Power Users can write new files into directories (the list is provided below), but can't modify files that were written to these directories during installation. All members of the Power Users group inherit Modify access to all the files created in these directories by a member of their group. %SystemRoot% %SystemRoot%\inf %SystemRoot%\Config %SystemRoot%\media %SystemRoot%\cursors %SystemRoot%\system %SystemRoot%\fonts %SystemDir% %SystemRoot%\help %SystemDir%\RAS Maintaining Proper System File and Registry Permissions across All Windows Server 2003 Computers within a Domain Although standard system file and registry permissions for Windows Server 2003 seem fairly secure, a wise administrator doesn't assume that the default permissions on system folders, files, and registry keys are always going to be the best possible settings. For example, the installation of new software always adds folders and files, and sometimes services, for which you'll also need to consider permissions set automatically, as well as changes to the inherited permissions. Note When a Windows Server 2003 computer is promoted to a domain controller, an additional set of permissions is applied. If you need to return to the settings applied at install time after having changed the default permissions, proceed as follows: 1. From the Start menu, select Run, and type mmc into the Open field. When the MMC console window opens, select the Add/Remove snap-in command from the File menu. The Add/Remove Snap-in window opened at the Standalone tab will
open. Click the Add button, and select the Security Configuration and Analysis option from the list of available snap-ins (Fig. 9.11). Click Add, then Close, then OK. Figure 9.11: Adding the Security Configuration and Analysis standalone snap-in 2. Right-click the Security Configuration and Analysis item and select the Open Database … command from the context menu (Fig. 9.12). The Open Database dialog will appear (Fig. 9.13), where you will be prompted to select a database, and then click Open. By default, security templates are stored at %SystemRoot%\security\templates. Navigate to this folder and select the required template. To reapply the default server security settings, select the setup security.inf file. To reapply the settings applied when a server is promoted to a domain controller, use the DC security.inf security template. If you only want to reapply the system drive root security settings, select the rootsec.inf security template, which implements the above-mentioned new Windows Server 2003 root ACL. Notice that this template can also be used to apply similar settings to the root of other disks.
Figure 9.12: Opening the Security Configuration Database Figure 9.13: The Open database dialog Note You must realize that after you reapply the default permissions using these security templates, any configuration settings that you may have applied either manually or using Group Policy will be overwritten by the default settings. Therefore, if you need to preserve your changes, create a copy of the default template(s), introduce officially approved changes into it, and maintain these copies as well as default security templates. Proceeding in such a way, you'll have a backup of your current security settings as well as the original default template. Using Group Policy to Maintain File and Registry Permission Settings Similar to Group Policy in Windows 2000, Group Policy in Windows Server 2003 allows administrators to centrally manage, configure, and push security policy and other administrative settings to an entire site, domain, or organizational unit. Policies, officially named Group Policy Objects (GPOs), are linked to these containers.
Note Most policies are implemented at the domain or OU level, since it is not practical to implement site policies. In addition to domain policies, a local Group Policy is configured and can be adjusted on individual workstations or servers. More detailed information on Group Policies will be provided in Chapters 10 and 11. File and registry permission settings can only be configured within the Computer Settings portion of the Group Policy (Fig. 9.14). To add registry path to the policy, expand the console tree as shown in this screenshot, right-click the Registry item, and select the Add Key command from the context menu. After you add new registry keys to the policy, the Discretionary Access Control Lists (DACLs) applied to them propagate to the objects on the computer when the policy is applied. Figure 9.14: Configuring registry permission settings within the Computer Settings portion of the Group Policy Using Secedit to Maintain File and Registry Permission Settings Besides Group Policy, you can use the Secedit.exe command-line tool to maintain file and registry permission settings. The Secedit.exe is the command-line version of the Security and Analysis Configuration tool. The secedit.exe tool uses the following command-line syntax: secedit [/configure | /analyze | /import | /export | /validate | /generaterollback] where: Secedit /configure-this command configures a system with security settings stored in a database. The syntax used by this command option is as follows:
secedit /configure /db db_filename [/cfg cfg_filename] [/overwrite][/areas area1 area2 ...] [/log log_filename] [/quiet] /db db_filename-specifies the db_filename database used to perform the security configuration. /cfg cfg_filename-specifies the cfg_filename security template that needs to be imported into the database prior to configuring the computer. Security templates are created using the Security Templates MMC snap-in. /overwrite-this option instructs the secedit tool to empty the database before importing the specified security template. If this parameter is missing, the settings in the security template are accumulated into the database. If this parameter is not specified and there are conflicting settings in the database and the template being imported, the template settings will take priority. /areas-specifies the security areas to be applied to the system. If this parameter is omitted, all security settings defined in the database are applied to the system. To configure multiple areas, separate each area by a space. The following security areas are supported: SECURITYPOLICY-Account Policies, Audit Policies, Event Log Settings, and Security Options. GROUP_MGMT-Restricted Group settings USER_RIGHTS-User Rights Assignment REGKEYS-Registry Permissions FILESTORE-File System permissions SERVICES-System Service settings /log log_filename-specifies a file in which to log the status of the configuration process (log_filename). If this parameter is missing, the configuration-processing information is logged in the Scesrv.log file, which is located in the %windir%\security\logs directory. /quiet-specifies that the configuration process should take place without prompting the user for any confirmation. Secedit /analyze-this option analyzes current systems settings against baseline settings that are stored in a database. The analysis results are stored in a separate area of the database and can be viewed in the Security Configuration and Analysis snap-in. The syntax for this command is as follows: secedit /analyze /db db_filename [/cfg cfg_filename ] [/overwrite] [/log log_filename] [/quiet] /db db_filename-specifies the database used to perform the analysis. /cfg cfg_filename-specifies a security template to import into the database prior to performing the analysis. Security templates are created using the Security Templates snap-in.
/log log_filename-specifies a file in which to log the status of the configuration process. If not specified, the configuration-processing information is logged in the Scesrv.log file, which is located in the s%windir%\security\logs directory. /quiet-specifies that the analysis process should take place without prompting the user for any confirmation. Secedit /import-allows you to import a security template into a database so that the settings specified in the template can be applied to a system or analyzed against a system. This command uses the following syntax: secedit /import /db db_filename /cfg cfg_filename [/overwrite][/areas area1 area2 ...] [/log log_filename] [/quiet] /db db_filename-specifies the database that the security template settings will be imported into. /cfg cfg_filename-specifies a security template to import into the database. Security templates are created using the Security Templates snap-in. /overwrite-specifies that the database should be emptied prior to importing the security template. If this parameter is not specified, the settings in the security template are accumulated into the database. If this parameter is not specified and there are conflicting settings in the database and the template being imported, the template settings win. /areas-specifies the security areas to export. If this parameter is not specified, all security settings defined in the database are exported. To export specific areas, separate each area by a space. The following security areas are exported: SECURITYPOLICY-Account Policies, Audit Policies, Event Log Settings, and Security Options. GROUP_MGMT-Restricted Group settings USER_RIGHTS-User Rights Assignment REGKEYS-Registry Permissions FILESTORE-File System permissions SERVICES-System Service settings