Tài liệu Methods of Restricting Registry Access phần 3 ppt

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.

N
ote 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.

N
ote 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.

N

ote 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

N
ote 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.

N
ote 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