The security of a network depends on the security configuration of the computers that make up the network. Any breach of security on a single computer can jeopardize the security of all computers in the network, thereby jeopardizing the security of the network itself. To secure a Microsoft® Windows® 2000 network, it is essential to plan the security for each Windows 2000-based computer in the network.
At the end of this module, you will be able to: Plan physical measures to secure Windows 2000-based computers. Evaluate the security requirements for Windows based computers with respect to their roles in the network. Design security configuration templates to enforce security settings. Evaluate the existing security configuration of a Windows 2000-based computer. Determine how to deploy security templates in a Windows 2000 network.
Planning Physical Security for Windows 2000– based Computers Planning Physical Network Security Securing Passwords in Active Directory Planning Hardware Configuration Security
Planning Physical Security for Windows 2000 Computers Windows 2000-based computers containing critical data must be protected from threats such as unauthorized physical access, theft, or destruction. You must determine which computers contain critical data, and therefore require additional security. In this lesson you will learn the following topics: Planning physical network security Securing passwords in Active Directory Planning hardware configuration security
Physical security includes both the actual placement of hardware, such as servers placed within an office, and the configuration of the hardware that is enforced prior to loading an operating system. Planning physical security in a Windows 2000 environment includes planning the placement of the server, the method of using the system key (SYSKEY) utility for password encryption in the Active Directory™ directory service, and the use of hardware configuration security methods, such as smart cards and basic input/output system (BIOS) passwords.
Planning Physical Network Security Placing Servers in Locked Rooms Securing Network Devices Configuring Network Devices As RADIUS Clients
Planning Physical Network Security Windows 2000-based computers that are being used as servers in a network are vulnerable to risks of unauthorized access, physical damage, and theft. Interruption of service as a result of damage or theft will have a significant impact on an organization that depends on server resources for daily operations. To counteract these risks, you can place Windows based servers at locations where physical resources are protected.
Planning Physical Network Security To protect Windows 2000-based servers against physical risk, you can: Place servers in locked rooms to which only authorized personnel have access. Secure network devices such as routers, switches, and bridges to ensure that an attacker cannot physically connect to them. Many devices will allow a network data analysis tool, or network sniffer, connected directly to the network device, to view traffic on all segments connected to the network device. Ensure that complex passwords are implemented at all network devices. If supported, configure routers and switches to be Remote Authentication Dial-In User Service (RADIUS) clients with Internet Authentication Service (IAS) providing Active Directory authentication.
Planning Physical Network Security By placing servers in protected locations, physical access is restricted to approved personnel. If servers are not protected, and physical access is obtained, the server can be started by using a floppy disk with a utility that bypasses local file security such as NTFSDOS. Such utilities allow the local user to access files on an NTFS file system partition without any of the NTFS permissions being applied to that user.
Securing Passwords in Active Directory NTFS Passwords The Password Encryption Key Encrypts All Passwords SYSKEY Encrypts the Password Encryption Key
Securing Passwords in Active Directory Passwords that are not adequately encrypted are at risk of being decrypted by password determination software. You can use the SYSKEY utility to change the mode in which strong encryption (encryption at an increased level) is applied to all password information stored within Active Directory. The SYSKEY utility uses a 128-bit cryptographically random key, known as a password encryption key. The SYSKEY utility then generates a system key that is used to encrypt the password encryption key. The password encryption key is used to encrypt the password information within Active Directory. Note: Encrypting the password information within Active Directory protects against a brute force attack (a word-based or character- based attempt to discover a password) if the hard drive is stolen from a Windows 2000 domain controller.
Securing Passwords in Active Directory When the domain controller is started, the system key is used to decrypt the password encryption key, which then decrypts the passwords as required. Caution: Strong encryption can reduce the likelihood that password determination software will succeed. It does not, however, guarantee prevention when guidelines for creating strong passwords are not followed.
Securing Passwords in Active Directory The SYSKEY utility allows the system key to be stored in different modes to meet the needs of different Windows 2000 environments. To set the location of the system key, you can choose from: Computer-generated key stored on local system Computer-generated key stored on floppy disk Administrator-chosen password
Computer-generated key stored on local system Use a computer-generated random key as the system key and store the key on the local system by using a complex encryption algorithm. This option provides strong encryption of password information in the registry and allows for unattended system restart.
Computer-generated key stored on floppy disk Use a computer-generated random key and store the key on a floppy disk. The floppy disk with the system key is required for the system to start. Windows 2000 prompts for the floppy disk before the system is available for users to log on. The system key is not stored anywhere on the local system.
Administrator-chosen password Use a password chosen by the system administrator to derive the system key. Windows 2000 will prompt for the system key password when the system is in the initial startup sequence, before the system is available for users to log on. The system key password is not stored anywhere on the system. A Message Digest 5 (MD5) version of the password is used to protect the password encryption key. Note: Windows 2000 enables the strong encryption of Active Directory and stores the system key as a computer-generated key stored on the local system.
Planning Hardware Configuration Security If you establish that default security is inadequate for your security requirements, you can use additional strategies that will help ensure the comprehensive physical security of Windows 2000-based computers. You can use any combination of the following strategies: Lights-out configuration. Computer locks. Power-on passwords. Biotechnology. Smart card logon. BIOS passwords.
Lights-out configuration. Preventing physical access to the server by removing devices. Lights-out configuration strategies include using removable floppy drives, keyboards, and monitors, and disabling all ports on the computer.
Computer locks. Preventing theft of computers by using physical measures.
Power-on passwords. Preventing unauthorized users from displaying the Start menu. Do not consider the power-on password to be a strong form of security if the computer stores the BIOS information in nonvolatile RAM. This storage of the BIOS information allows the password to be reset by following the procedure described by the manufacturer.
Biotechnology. Enforcing additional verification of the personnel authorized to access a computer, by using biotechnologies such as fingerprint devices or retinal scanners. You can combine biotechnologies with smart card logon to provide increased security.
Smart card logon. Reducing duplication of card-access-controlled services by using smart cards as employee cards. Computers configured with smart card readers require users to log on with smart cards and personal identification numbers (PINs) for authentication.
BIOS passwords Preventing unauthorized users from making changes to the BIOS settings of a computer. As with the power-on password, the BIOS password can be reset on computers that store the BIOS information in non- volatile RAM by following the procedures described by the manufacturer.
Evaluating Security Requirements ClassRequirements Domain controllersMaximum security settings Application serversApplication-specific security settings File and print serversSpecific DACL settings using templates KiosksLocked for only single applications WorkstationsSpecific configuration based on interaction in a domain Portable computersHigher local file security
Evaluating Security Requirements The security requirements for a Windows 2000-based computer in a network depend on the role that the computer is performing in the network. Different roles require different levels of security.
Before defining the security configurations of the Windows 2000-based computer, you need to identify the role that the computer performs. The different roles of Windows 2000-based computers in a network, and their security requirements, include: Domain controllers. Windows 2000-based computers storing Active Directory. These computers will require the maximum security configuration settings. Application servers. Windows 2000-based computers that host client/server applications (such as Web servers and mail servers). These servers will require application-specific security configuration settings. File and print servers. Windows 2000-based computers that serve as file and print servers on the network. These servers may require specific discretionary access control list (DACL) settings that can be propagated by using security configuration templates. Kiosks. Windows 2000-based computers commonly deployed at trade shows, malls, and libraries made available for public use. These computers are configured to allow only a single application to run. Workstations. Windows 2000-based client computers that may require a specific security configuration for interaction in the domain environment. Portable computers. Windows 2000-based client computers that may be used in more than one location, inside and outside the corporate network. Because these computers are periodically used outside the corporate network they require a higher level of local file security.
Designing Security Configuration Templates Analyzing Windows 2000 Default Security Providing Security to Upgraded Computers Ensuring Compatibility with Non–Windows 2000 Certified Applications Elevating Security Using Incremental Security Templates Configuring Security Templates Customizing Security Templates
Designing Security Configuration Templates A security template is a physical file representation of a security configuration. The template can be applied to a local computer or imported to a Group Policy object (GPO) in Active Directory. Security Templates is a tool that can be used to create security templates for one or more computers to ensure consistent security configuration. Designing security templates involves using an appropriate template for a given scenario and configuring the template for the required security setting. An effective design ensures that the appropriate security settings are applied to all Windows 2000-based computers in the network.
To design security configuration templates: Analyze the default security provided in Windows 2000 when installed on a workstation, server, or domain controller. Provide security to any computers that have been upgraded. Ensure compatibility with any non-Windows 2000 applications. Use incremental security templates to elevate security. Configure the security templates. Customize the templates as required.
Analyzing Windows 2000 Default Security defltdc.infdefltsv.infdefltwk.inf Workstation Member Server Domain Controller Default Security Templates Applied to All New Windows 2000 Installations Except: Upgrades from Windows NT 4.0 FAT File System–only Computers
Analyzing Windows 2000 Default Security The default security setting of Windows 2000-based computers provides a significant increase in security over previous versions of Microsoft Windows NT®. The settings are applied by using predefined default security templates. These templates provide a secure system from the outset. No additional configuration is required after installation. Windows 2000 default security settings are applied only to Windows 2000 systems that have a clean installation to an NTFS file system partition. The security template used on a Windows based computer depends on the type of Windows 2000 installation selected. The template will vary based on whether the Windows 2000-based computer is running Windows 2000 Professional, running Windows 2000 Server, or functioning as a domain controller.
Analyzing Windows 2000 Default Security The following table lists the default security template files applied to the three defined roles for Windows 2000-based computers. Template file Role of the Windows 2000-based computer defltwk.infWindows 2000-based Professional workstations defltsv.infWindows 2000-based servers defltsv.infWindows 2000-based domain controllers
Analyzing Windows 2000 Default Security Copies of these template files are stored in the systemroot\inf directory. The applied template is stored in systemroot\security\templates as "Setup security.inf" and can be reviewed to determine the settings that were applied, or to reapply the initial security settings if the settings have been modified.
The default security settings will not be applied in the following circumstances: Windows 2000-based computers that were upgraded from Windows NT version 4.0. Systems using only the file allocation table (FAT) file system. The security settings require that the NTFS file system be in place because the FAT file system does not provide local file security. Note: Windows 2000-based computers that have been upgraded from Microsoft Windows 95 and Microsoft Windows 98 do have the default security settings applied, with the exception that all local user accounts are configured to be members of the local Administrators group.
Providing Security to Upgraded Computers Equivalent Security Settings Windows 2000 Upgrade Basic Template Default Template Windows 2000 New Installation
Providing Security to Upgraded Computers The default security templates are not applied to computers that have been upgraded to Windows 2000 from earlier versions of Windows NT. To provide security settings that are equivalent to those of a clean installation of Windows 2000, you can use basic security templates. You can also use the basic security templates to reapply default security settings.
The following table lists the appropriate basic security template for upgraded Windows 2000-based computers according to the role of the computer. Template file Role of the Windows 2000-based computer basicwk.infWindows 2000-based Professional workstations basicsv.infWindows 2000-based servers basicdc.infWindows 2000-based domain controllers
Providing Security to Upgraded Computers These basic security templates specify default Windows 2000 security settings for all security areas with the exception of User Rights and Groups. These security settings ensure that existing group memberships and defined user rights are not modified. Note: Upgrades to Windows 95 and Windows 98 will not require the implementation of the Basic template because there will be no current local security settings to be maintained. The default security template will be applied for these upgrades.
Ensuring Compatibility with Non-Windows 2000 Certified Applications Basic Template Domain Users Power Users Group Apply the Basic Template Add Domain Users to Power Users, Or Apply the Compatible Template Upgrade to Windows 2000 Certified Applications Non-Windows 2000 Certified Applications Compatws.inf Template
Ensuring Compatibility with Non-Windows 2000 Certified Applications Because of the increased default security in Windows 2000, some applications will not function correctly. If your Windows 2000-based computers will run applications that are not certified for Windows 2000, your security settings must ensure that the computers are compatible with the Windows NT applications. The Windows 2000 logo program certifies applications tested with Windows Certified applications must meet the Windows 2000 logo program specification, which defines how the application must interact with the Windows 2000 operating system. Tip: For more information about the Windows 2000 logo program, go to upgrading/compat/default.asp. upgrading/compat/default.asp
Ensuring Compatibility with Non-Windows 2000 Certified Applications Non-certified applications can only run on a Windows 2000-based computer if the user running the application has sufficient rights on the computer. The Windows 2000 group membership of the user determines the user's rights.
Ensuring Compatibility with Non-Windows 2000 Certified Applications The following table shows the Windows 2000 groups, their permissions, and their restrictions. Windows 2000 group PermissionsRestrictions Power Users (permissions same as Windows NT 4.0 Users group) Create shares Change system time Create local accounts None UsersWrite access only to: HKEY_CURRENT_USER portion of the registry User's profile directory Shared document location Their own files Cannot write to any other system location
Ensuring Compatibility with Non-Windows 2000 Certified Applications By default, the members of the Windows 2000 Users group have permissions that are stricter than the permissions granted to members of the Windows NT Users group. The Windows NT applications that are not certified for Windows 2000 cannot run under the security context of the Windows 2000 Users group. To run non-Windows 2000 certified applications on a Windows 2000-based computer, you can use the following methods: Add all user accounts to the Power Users group. Apply the compatible security template. Upgrade to a Windows 2000-certified version of the software.
Add all user accounts to the Power Users group. Adding user accounts to the Power Users group will enable users to access non-Windows 2000 certified applications. Caution: The decision to make all user accounts members of the Power Users group is considered a security weakness because additional rights are given to members of the Power Users group.
Apply the compatible security template. If you want to enable users to access applications that are non-Windows 2000 certified, without adding their user accounts to the Power Users group, you can use the compatible template, Compatws.inf. The compatible template lowers the security levels on specific files, folders, and registry keys that applications commonly access. For example, Microsoft Office 97 runs successfully when you are logged on as a user to a Windows 2000-based computer that has had the compatible security template applied over the default settings. Note: A user can install non-Windows logo programs if he or she installs to the user's profile directory and only makes changes to the HKEY_CURRENT_USER section of the registry.
Upgrade to a Windows 2000-certified version of the software. Many software publishers will be releasing updated versions of their software that are Windows 2000 certified and will fully integrate with Active Directory.
Elevating Security Using Incremental Security Templates notssid.inf DC security.inf securews.inf securedc.inf No Terminal server SID Initial Domain Controller Configuration Secure High Secure High Secure File(s)Template hisecws.inf hisecdc.inf hisecws.inf hisecdc.inf Description Description Removes the terminal server SID from all file systems and registry objects Contains registry and file settings used for Windows 2000 domain controllers Provides increased security for areas of the operating system not covered by permissions Increases the security defined by parameters in the secure template Optional Components Optional Components ocfilesw.inf ocfiles.inf ocfilesw.inf ocfiles.inf Increases the local security for optional components Increases the local security for optional components
Elevating Security Using Incremental Security Templates To elevate the baseline security of Windows 2000-based computers, you can use incremental security templates. These templates are shipped with Windows 2000, and include additional file, registry, and service settings that can be configured in networks that require high levels of security. Note: The incremental security templates are stored in the systemroot \security\templates folder.
Elevating Security Using Incremental Security Templates
The incremental security templates assume that the Windows default security settings already exist on the computer. Default security is applied to Windows based computers with a clean installation, and on upgraded computers on which the basic security template has been applied.
The following incremental security templates are provided with Windows 2000: No Terminal Server SID template (notssid.inf) Initial Domain Controller Configuration template (DC security.inf) Secure templates (securews.inf and securedc.inf) High Secure templates (hisecws.inf and hisecdc.inf) Optional Components templates (ocfilesw.inf and ocfiles.inf)
No Terminal Server SID template (notssid.inf) Removes the Terminal server security identifier (SID) from all file systems and registry objects. If this template is applied, all terminal server users will have their access rights defined through membership in Users or Power Users, rather than using the Terminal server account SID for resource access rights.
Initial Domain Controller Configuration template (DC security.inf) Contains registry and file settings that were initially applied to a Windows 2000 domain controller.
Secure templates (securews.inf and securedc.inf) Provides increased security for areas of the operating system not covered by permissions. The secure template modifies settings (such as Password Policy, Audit Policy, and Registry Values) that have an impact on the operational behavior of the operating system and its network protocols. The secure template provides recommendations that are distinct from the defined default access control policy. The secure template does not modify any DACLs, but does remove all members of the Power Users group.
High Secure templates (hisecws.inf and hisecdc.inf) Increases the security defined by several parameters in the secure template. For example, whereas the secure template might enable Server Message Block (SMB) packet signing, the high secure template would require SMB packet signing. The high secure template configures many operational parameters to their extreme values without regard for other performance issues. Similar to the secure template, the high secure template also removes all members of the Power Users group and, in addition, removes the terminal server SID from the system. The highly secure configuration is provided for Windows based computers that operate in a network where all computers are Windows 2000-based computers. In this highly secure configuration, all network communications must be digitally signed and encrypted at a level that only Windows 2000 can provide. Thus, communications between a Windows 2000 highly secure computer and a client running a previous version of Windows, cannot be performed.
Optional Components templates (ocfilesw.inf and ocfiles.inf) Increases the local security for optional components that may be installed on Windows 2000 Professional or Windows 2000 Server-based computers. Note: Previous Windows clients include all Windows NT, Windows 95, Windows 98, and Microsoft Windows 3.1 clients.
Configuring Security Templates File System Restricted Groups Event Log IPSec Account Public Key System Services Registry Local Security Template
Configuring Security Templates A security template contains nine different categories of security settings. You can configure these settings by using security templates in Microsoft Management Console (MMC).
Configuring Security Templates You can configure the following settings in a security template: Account Policies. Restricted Groups. File System. Registry. System Services. Public Key Policies. IPSec Policies on Active Directory. Event Log. Local Policies.
Account Policies Defines security settings that primarily deal with account authentication issues. Account Policies include: Password Policy. Configures settings, such as minimum password length or requiring password complexity. Account Lockout Policy. Locks out users after a specified number of failed logon attempts, and sets the period of time for which accounts are frozen. Kerberos Policy. Sets default Kerberos Version 5 protocol settings for each domain; for example, the maximum lifetime of a service ticket.
Restricted Groups Manage and enforce the membership of built-in or user- defined groups that have special rights and permissions. This policy will not allow local variations on each computer. Restricted Groups will reduce the need to audit group membership.
File System Configures security and control security auditing of files and folders.
Registry Configures security and control security auditing for registry keys and their subtrees. For example, to ensure that only administrators can change certain registry keys, you can grant administrators full control over the registry keys and their subtrees, and grant read-only permission to other users. When auditing is enabled, you can use registry policies to audit user activity in the computer's registry. You can specify the users and user events that are logged for both failed and successful events.
System Services Configures service startup settings, permissions and rights, and auditing settings.
Public Key Policies Provides settings that enable security by using certificates. This setting enables the submission of certificate requests, the creation and distribution of certificate trust lists, the establishment of common and trusted root certification authorities, and the addition of encrypted data-recovery agents. Note: Public Key policies cannot be set in local security templates. They can only be applied by using Group Policy.
IPSec Policies on Active Directory Includes three predefined Internet Protocol Security (IPSec) policies—Client, Server, and Secure Server-as a model for creating your own policies. These policies eliminate the need for you to create other policies, except in situations in which special requirements are necessary. Note: IPSec policies cannot be set in local security templates. They can only be applied by using Group Policy.
Event Log Controls the settings of the application, system, and security event logs on local computers. You can specify options, such as maximum log sizes and log retention methods.
Local Policies Determines security settings that can be set on individual Windows 2000-based computers. Local computer policies are applied to the local computer account database. Local policies include: Audit Policy. Can configure security events for auditing to the security log. Includes auditing for both successes and failures. User Rights Assignment. Defines specific users and security groups that have rights to perform tasks that affect system security. Security Options. Allows for the setting of a wide variety of security options, such as requiring smart card logon, enforcing users to log off when logon hours expire, and displaying logon banner messages
Customizing Security Templates Creating New Templates Use Security Templates in MMC Extending the Interface Include additional registry settings to define the Local Settings security policy
Customizing Security Templates Your organization may have security requirements that the preconfigured security templates do not meet. For example, if you need to enforce new user passwords every 10 days, you need to have a custom template. You can create a custom template by exporting the security information to a new security configuration template, or by extending the interface to add new registry values.
Creating New Templates You can create new templates by using the Security Templates tool in MMC. To configure a new template, you first create the template, then define all required security settings, and finally extend the registry values in the template as required.
Extending the Interface You can extend the current toolset to include additional registry settings that you want to define for Local Settings security policy. You extend the toolset by editing the Sceregvl.inf configuration file stored in the systemroot\inf folder.
Within this configuration file, new registry entries can be added by using the following syntax: regpath,type,displayname,displaytype Where: regpath represents the path for the registry value that requires configuration. typ represents the data type of the registry entry. The supported types include: REG_SZ (1), REG_EXPAND_SZ(2), REG_BINARY(3), REG_DWORD(4), REG_MULTI_SZ(7) display name indicates the name that will be displayed for the setting in Security Configuration Tools and Analysis. display type configures how the interface will display a registry setting to a user for input. Display types include Boolean(0), Number(1), String(2), or Choices(3). Tip: If the display type is 3, provide choices in the format of, where value is the registry value that will be set, and display is the value displayed in the user interface.
After you have edited the Sceregvl.inf file, you will need to re-register the Scecli.dll dynamic link library so that the settings that you have configured appear within the Security Configuration Tool Set. Running the command Regsvr32 scecli.dll accomplishes this.
Lab A: Analyzing a Security Template
Evaluating Security Configuration Defining Required Security Baselines Verifying Effectiveness of a Security Baseline Comparing Current Configuration with a Security Baseline Automating Analysis of Security Baselines
After designing and standardizing security templates, it is important to constantly re-evaluate the security configuration. Evaluation of the security configuration ensures that the security settings are neither so low that the configuration opens the network to unauthorized access, nor so high that it restricts authorized users.
The tasks required for evaluating the security configuration of a Windows 2000 network are: Defining the security baseline for a Windows based computer. Verifying the security effectiveness and functionality of a security baseline. Comparing the current security configuration of a Windows 2000-based computer with a security baseline. Automating continued analysis of the security baseline.
Defining Required Security Baselines Security Baselines Must Be: Reproducible Fully tested Set to the required level of security
A security baseline is defined as the minimum security settings that must be applied to a computer. The security baseline will depend on the current security risks faced by the network and must include features whose configuration would minimize these risks. The security baseline must: Be reproducible. The default security settings must be capable of being reproduced on required Windows 2000-based computers. Only settings that can be reproduced can be deemed a baseline configuration. Be fully tested. The defined baseline must go through several tests to ensure that the configuration provides the required level of security for the Windows 2000-based computer. Meet security requirements. The baseline must be configured to provide the required level of security. The baseline must not be set higher than the required security setting. Configuring excessive security settings can lead to bad practices, such as users keeping written copies of their passwords at their desks. Defining the security at too low a level can result in unwanted access to resources. The security baseline must be defined in a lab environment by using computers that duplicate the configurations that will be applied in the network.
Verifying Effectiveness of a Security Baseline Repeat until baseline satisfies all requirements Ensure settings can be reproduced Ensure the presence of required configuration options Ensure testing is unbiased
After the security baseline is defined, and before it is applied, you must test and verify the effectiveness and functionality of your security design. An iterative method, such as that used in Microsoft Solutions Framework (MSF), can be used for verifying and testing a security baseline. MSF is based on Microsoft's recommended methods for planning, building, and managing distributed computing systems. Note: To learn more about the MSF iterative method, see course 1517A, Principles of Infrastructure Deployment.
For an effective and fully functional security baseline: Ensure settings can be reproduced Ensure testing is unbiased Ensure the presence of required configuration options Note: For more information, please see the white paper Security Configuration Tool Set on the Student Materials compact disc.
Comparing Current Configuration with a Security Baseline Current Configuration Does Not Match Baseline Current Configuration Meets or Exceeds Baseline
After the security configuration template has been defined and tested, you need to compare it with the current security configuration of the Windows based computers. An analysis of the results of the comparison will allow you to identify: Security weaknesses that may exist in the current configuration. Configuration settings applied to the Windows based computer that are not included in the security template, but need to be reproduced for deployment to other computers. Configuration changes that have been made to a system since the original template was deployed.
The Security Configuration and Analysis tool in MMC performs the comparison of the actual settings with the required settings. After the analysis has been completed, the tool will indicate whether the current configuration matches the required configuration. After performing the analysis, the network administrator can choose to apply the baseline security settings to the target system or leave the current security configuration as is.
Automating Analysis of Security Baselines secedit /analyze /db secure.sdb /cfg baseline.inf Performed every Friday
Automating Analysis of Security Baselines
Automating continued analysis of security baselines ensures that the security settings of Windows 2000-based computers in a network remain consistent. This consistency will ensure that the network remains secure. The secedit command-line tool can be used to automate periodic analysis of the security baseline. The secedit command is used with the /analyze options to configure a batch. The syntax of the secedit command line is: secedit /analyze [/DB filename ] [/CFG filename ] [/log logpath] [/verbose] [/quiet ]
Automating Analysis of Security Baselines The various options that are used with the secedit /analyze command line are: / DB filename. Provides the path to a database that contains the stored configuration against which the analysis will be performed. This is a required option. If filename specifies a new database, the /CFG filename argument must also be specified. / CFG filename. Provides the path to the security template that will be imported into the database for analysis. This option is only valid when used with the /DB parameter. If the /CFG option is not specified, the analysis is performed against a configuration that is already stored in the database. /log logpath. Provides the path that will be used to log the reports of the analysis. If this option is not used in the command-line statement, the default file is used. / verbose. Requests for more detailed progress information to be logged during the analysis. / quiet. Suppresses screen and log output. The output can only be viewed in Security Configuration and Analysis in MMC.
The secedit command-line tool can be combined with the Scheduled Tasks Control Panel Applet to allow you to configure a regular analysis of the security configuration of select computers. The resulting log files can be examined for security nonmatches. Tip: To find the areas of security configuration that are not configured as the security template expects, you can use the find command against your produced log file and search for the phrase "Mismatch." You then redirect the output to a predetermined file name where Microsoft Systems Management Server collects the file for analysis at a centralized location.
Deploying Security Baselines Local Policies Applied in a Workgroup Environment Group Policies Applied in an Active Directory Environment OU OU Domain OU
Deploying Security Configuration Templates Deploying Security Configurations with Local Security Templates Deploying Security Configurations with Group Policy Objects Combining Local Policy and Group Policy Discussion: Applying Security Configuration Templates
Deploying Security Configuration Templates You can prevent security configuration errors and easily troubleshoot any security-related problems by deploying security templates. You can deploy security templates to all Windows 2000-based computers in a forest by applying security templates at the site, domain, and OU levels.
To deploy security templates, you can use: Direct application to computers by using local policies. Application to computers grouped by their roles by using Group Policy. Application of a combination of local policies and Group Policy. When local policy and Group Policy are combined, it is important to know how they interact to result in an effective policy for a computer.
Deploying Security Configurations with Local Security Templates Baseline Configuration Differing Configurations Manually Apply Security Template
Local policies are the only way to deploy consistent security settings to Windows 2000—based computers in workgroup environments, non-Microsoft networks, and networks that do not use Active Directory. The application of local security templates at installation ensures that all Windows 2000-based computers will be configured with identical security. Local security templates are applied to the local computer system directly. Manually Apply Security Template
Local templates need to be configured in a way that matches the security requirements of the categories of computers that have been defined for a network. A security template must exist for each of the configurations that you require. When installing a new configuration, application of the security template must be the final stage of setup. Applying the template at the final stage ensures consistent application of security on each Windows 2000-based computer. Note: Local policies must also be used when a Windows 2000-based computer is part of a Novell network environment.
Deploying Security Configurations with Group Policy Objects Site Domain 1 GPO Domain 2 OU OU OU OU OU GPO Create OUs for Each Computer Role Minimize Number of GPOs Child OU GPOs Override Parent OU GPOs
A GPO is a collection of policy settings that enables the deployment of uniform security policies to specific classes of Windows 2000-based computers, such as domain controllers. You can import your defined security templates into GPOs so that uniform security configuration can be applied to a group of computers contained within an OU, domain, or site. Deploying Security Configurations with Group Policy Objects
When you create an OU structure to support the deployment of security policies, consider: Creating OUs that contain computers with similar roles in the network. Apply a single GPO to each of these groups to implement consistent security settings. Minimizing the number of GPOs that apply to users and computers. Application of multiple group policies can create policy conflicts that are difficult to troubleshoot. Specifying separate group policies for child OUs in Active Directory if you want the Group Policy of the parent domain or OU to be overridden. Moreover, if a policy configured for a parent OU is incompatible with the child OU, the child OU does not inherit the policy setting from the parent OU. The setting in the child OU is applied. Note: By default, security settings deployed by using GPOs are deployed every five minutes for domain controllers and every 90 minutes for Windows 2000 Professional and member servers. You can force the deployment of security settings by using the command secedit /refreshpolicy MACHINE_POLICY /enforce.
Combining Local Policy and Group Policy Local Policy Site Policy Domain Policy Child OU Policy Parent OU Policy Effective Policy
The effective policy of a computer is the combination of local policy and all group policies that are applied to that computer. The policies on a Windows 2000–based computer are processed in the following order: 1. Local policy set to the computer 2. Site policy defined in Active Directory Sites and Services 3. Domain policy 4. Parent OU Policy 5. Child OU Policy Combining Local Policy and Group Policy
This processing order ensures that GPOs set at an OU level will override any policy settings defined in the local policy, allowing centralized management of the effective policy on all Windows 2000-based computers. The security policy settings are configured as computer settings and are not applied directly to users, but to the computers at which the users are working. Important: Domain controllers are an exception to the above processing order. Domain controllers use the Account Policies defined in the Default Domain Policy regardless of the Account Policies set on the OU that contains the domain controller.
Effective policy is the sum effect of applied Group Policy. When local policy does not match this effective policy, it is possible that Group Policy has been applied at one or more levels of Active Directory. You can view the local and effective settings by using Local Security Settings from the Administrative Tools menu.
When troubleshooting security settings, it is important to locate where Group Policy has been applied in the Active Directory hierarchy. The following guidelines can be used to determine where Group Policy is applied: Analyzing the OU structure where the computer object exists. This will identify potential containers where Group Policy might be applied. Using the gpresult resource kit tool to further filter the list of potential locations of the application of a GPO by determining the group policies that were applied to a computer or user.
Discussion: Applying Security Configuration Templates Site OU Northwind Traders Domain Northwind Traders Domain Site Account Policy Audit Policy Default Domain Controllers OU Domain Controllers
When you are deciding where to apply security configuration templates, you must determine where in the Active Directory hierarchy the templates must be applied. You base this decision on the security settings for the computers on which you want to apply the template. This scenario describes an organization's requirements for deploying a baseline security configuration.
Scenario Northwind Traders has defined the baseline security requirements for a domain controller configuration. A consulting firm has created two security templates that can be applied to domain controllers. The first template defines Account Policies and the second template defines Audit Policy. Testing of the security templates has proved that the security templates meet security requirements. Now a decision must be made on how to deploy the security templates to all domain controllers in the nwtraders.msft domain.
Objectives After completing this lab, you will be able to: Extend a security template to use a customized security option. Analyze the current security configuration against a security template. Configure the current security to match a security template. Import an extended security template into a GPO. Apply a security template by using Group Policy.
Prerequisites Before working on this lab, you must have: Knowledge of security configuration and how to apply security templates. Experience working with the Windows 2000 Security Configuration Tool Set.
Lab Setup This lab environment includes the following resources: A computer running Windows 2000 Server configured as a domain controller.
Exercise 1: Verifying Current Settings for DNS Dynamic Updates Scenario Northwind Traders wants to prevent the Windows 2000 Professional workstations from registering A (host) and PTR (pointer) resource records with the Berkeley Internet Name Domain (BIND) DNS server. You have determined that by configuring the following registry entry, you will prevent all installed adapters from performing dynamic updates: HKLM\System\CurrentControlSet \Services\Tcpip\Parameters \DisableDynamicUpdate
Goal In order to verify current settings for DNS dynamic updates, the registry entry will be verified to see it is not currently implemented within the Security Configuration Tool Set or within the registry.
Online Demo Exercise 1: Verifying Current Settings for DNS Dynamic Updates
Exercise 2: Extending the Security Configuration Tool Set Scenario The decision has been made to extend the Security Configuration Tool Set to include the registry setting to disable dynamic DNS updates. This will prevent the Windows 2000 Professional-based computers from causing excessive events by attempting to dynamically update the DNS servers. By extending the Security Configuration Tool Set, you allow the registry value to be applied by using either local security templates or by using Group Policy. An outside consultant has provided the updated configuration file to you.
Goal In this exercise, the Security Configuration Tool Set will be extended by adding the option to disable dynamic DNS updates for all TCP/IP interfaces.
Online Demo Exercise 2: Extending the Security Configuration Tool Set
Exercise 3 Configuring the Security Template Scenario After extending the Security Configuration Tool Set to include a registry key to prevent a Windows 2000-based computer from dynamically registering A and PTR resource records with a DNS server, you need to configure a security template to implement this policy.
Goal In this exercise, the DNS Update template will be modified to have the Disable Dynamic DNS Updates policy enabled.
Online Demo Exercise 3: Configuring the Security Template
Exercise 4: Applying the DNS Update Security Template Scenario After extending the Security Configuration Tool Set to prevent a Windows 2000-based computer from dynamically registering A and PTR resource records with a DNS server, you now need to determine whether your computer meets the security configuration settings of your new security template.
Goal In this exercise, you will analyze your current security settings against the newly created security template and then configure the computer to match the security template.
Online Simulation Exercise 4: Applying the DNS Update Security Template
Exercise 5: Reversing the Dynamic Update Setting in the Security Template Scenario Now that a security template has been created to ensure that dynamic updates are not performed, a reverse template must be created to ensure that domain controllers continue to perform dynamic updates of their A and PTR resource records.
Goal In this exercise, you will create a new template that reverses the policy to prevent dynamic DNS updates.
Online Simulation Exercise 5: Reversing the Dynamic Update Setting in the Security Template
Exercise 6: Importing a Security Template into Group Policy Scenario Now that a security template has been created to ensure that dynamic updates are not performed, a reverse template must be created to ensure that domain controllers continue to perform dynamic updates of their A and PTR resource records.
Goal In this exercise, you will import the newly created Enable DNS Update security template into the Default Domain Controllers Policy to ensure that domain controllers perform dynamic DNS updates.
Online Simulation Exercise 6: Importing a Security Template into Group Policy