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

Trang 1

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,

Trang 2

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

Trang 3

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

Trang 4

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

Trang 5

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:

/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:

Trang 6

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

Trang 7

/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: