Managing Security Templates

Microsoft Windows graphic

Security Templates

A security template is a file which represents a security configuration. Security templates are representations of may be applied to a local computer, imported to a Group Policy object or used to analyze security.

  • Before proceeding, see Checklist: Securing your computers using Security Configuration Manager.
  • For help with specific tasks, see How To.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.
  • Other security policy tools:
Security Configuration Manager Tool | Description
Security Configuration and Analysis | You can use this tool to analyze or configure computer security using a security template.
Security Settings extension to Group Policy | You can use this tool to edit individual security settings on a domain, site, or organizational unit in Active Directory.
Local Security Policy | You can use this tool to edit individual security settings for your local computer.
Secedit.exe Command-line tool | You can use this tool for automating security configuration tasks.

For more information on the individual security settings, see Security setting descriptions.


Checklist: Securing your computers using Security Configuration Manager

Step | Reference
Preparing to set up security policy
Review the descriptions of individual settings. | Security setting descriptions
Review default security settings, security groups, and Windows XP changes to default security settings | Default security settings, Differences in Windows XP default security settings
Review default User Rights | Logon Rights, Privileges
Use Windows certified applications | Certified for Windows Program at the Microsoft Web site. (http://msdn.microsoft.com)
Analyze your current settings
Review Security Templates | Security Templates
Select a predefined security template or create a new security template to use for your computers | Predefined security templates, Define a new security template
Perform a security analysis on your local computer. | Analyze system security
Modify security settings
Apply the appropriate template. | To import a security template to a Group Policy object, To apply a security template to local policy
Modifying security settings on your local computer | To edit local security settings
Modifying security settings for a domain or organizational unit. | To edit a security setting on a Group Policy object


Best practices for using Security Templates

Microsoft Windows graphic

Best practices

Use templates properly

  • Never edit the Setup security.inf template, since it gives you the option to reapply the default security settings.
  • The Setup security.inf template should never be applied through Group Policy. The Setup security.inf template should only be applied to the local computer through Security Configuration and Analysis. The Setup security.inf template is modified during installation and is unique for each computer. It contains a large amount of data and can degrade performance if is applied through Group Policy, because it periodically refreshes policy.
  • The Compatible template should not be applied to domain controllers. For example, do not import the Compatible template to the Default Domain or Default Domain Controller Group Policy object.

Use caution when modifying predefined templates

  • Instead of just modifying a predefined template, customize the predefined template and then save the changes under a different template name.
  • Predefined or newly-created security templates should not be applied to your computer or network without testing to ensure that the right level of application functionality is maintained.

Choose the appropriate default level of computer access

  • When deciding on the default level of computer access that end users will have, the determining factor is the installed base of applications that need to be supported. For more information, see Default security settings.

For more information, see Best practices for Security Configuration and Analysis and Best practices for Security Settings.


How to...

Microsoft Windows graphic

How to ...

  • Install Security Templates
  • Customize a predefined security template
  • Create a security template
  • Create a new security template path
  • Create a Restricted Groups policy
  • Apply a security template to local policy
  • Import a security template to a Group Policy object
  • Delete a security template


Add Security Templates to an MMC console

Microsoft Windows graphic

To add Security Templates to an MMC console

  1. Click Start, click Run, then type mmc, then click OK.
  2. (Optional) To open an existing console, on the File menu, click Open, click the console you wish to open, and then click Open.
  3. On the File menu, click Add/Remove Snap-in.
  4. In Add/Remove Snap-in, click Add.
  5. In Available Standalone Snap-ins, click Security Templates, click Add, click Close, then click OK.
  6. On the File menu, click Save.

Notes

  • XOX

  • For more information, see Working with MMC console files.

Related Topics


Customize a predefined security template

Microsoft Windows graphic

To customize a predefined security template

  1. Open Security Templates.
  2. In the console tree, double-click the default path folder (systemroot\Security\Templates), and in the details pane, right-click the predefined template you want to modify.
  3. Click Save As, type a new file name for the security template, and click Save.
  4. In the console tree, double-click the new security template to display the security policies, and navigate until the security attribute you want to modify appears in the details pane.
  5. Right-click the security attribute and click Properties.
  6. Select the Define this policy setting in the template check box, make your changes, then click OK.

Notes

  • To open Security Templates, click Start, and click Run, then type mmc and click OK. On the File menu, click Open, click the console that you want to open, then click Open. Then, in the console tree, click Security Templates.
  • Only administrators have the permissions to make any changes to the default security template folder, which is:

    systemroot\Security\Templates

Related Topics


Define a security template

Microsoft Windows graphic

To define a new security template

  1. Open Security Templates.
  2. Right-click the folder where you want to store the new template and click New Template.
  3. In Template name, type the name for your new security template.
  4. In Description, type a description of your new security template, and then click OK.
  5. In the console tree, double-click the new security template to display the security areas and navigate until the security setting you want to configure is in the details pane.
  6. In the details pane, right-click the security setting you want to configure and click Properties.
  7. Select the Define this policy setting in the template check box, edit the settings, and then click OK.

Notes

  • To open Security Templates, click Start, click Run, type mmc, and then click OK. On the File menu, click Open, click the console that you want to open, then click Open. In the console tree, click Security Templates.
  • Only administrators have the permissions to make any changes to the default security template folder, which is:

    systemroot\Security\Templates

    If you would like to create a new folder for new security templates, see To set a new security template path.
  • For more information on the different policy settings, see Security setting descriptions.

Related Topics


Set a new security template path

Microsoft Windows graphic

To set a new security template path

  1. Open Security Templates.
  2. In the console tree, right-click Security Templates, click New Template Search Path, and select the new location.

    3. A folder with the path of the new location appears in the console tree.

  3. (Optional) To add a description to the new template path (in addition to the name), right-click the new template folder, click Set Description, and then type the description you want to add.

Notes

  • To open Security Templates, click Start, and click Run, then type mmc and click OK. On the File menu, click Open, click the MMC console that you want to open, then click Open. Then, in the console tree, click Security Templates.
  • XOX

Related Topics


Create a Restricted Groups policy

Microsoft Windows graphic

To create a Restricted Groups policy

  1. Open Security Templates.
  2. In the console tree, right-click Restricted Groups.

    Where?

    • Security Templates
    • Template path folder
    • Security template
    • Restricted Groups
  3. Click Add Group.
  4. In Group, type the name of the group for which you would like restricted policy and click OK.
  5. To add members to the group, in the details pane, right-click the group you added and click Properties.
  6. In NewGroup Properties, in the Members of this group box, click Add, and then type the member you would like to add. Repeat this step for each member you would like to add.
  7. To add this group as a member of any other groups, in NewGroup Properties, in the This group is a member of box, click Add, type the name of the group, and click OK. Repeat this step for each group you want to add.

Notes

  • To open Security Templates, click Start, and click Run, then type mmc and click OK. On the File menu, click Open, click the console that you want to open, then click Open. Then, in the console tree, click Security Templates.
  • XOX
  • Restricted Groups policy states that only the members that you have added can belong to that group. When the security template is used to configure a system, during the configuration, only members specified in Restricted Groups policy will remain members. Similarly, at the time of configuration, if the member does not belong to the group, they will be added to the group.
  • If there are no users in a defined restricted group, then all current members of that group are removed when you use the template to configure a system.
  • If a restricted group does not belong to other groups, no action is taken to adjust membership in other groups.
  • To copy all of the restricted group entries from one template to another, in the console tree, right-click Restricted Groups, click Copy, right-click Restricted Groups in the other template, and then click Paste.

Related Topics


Apply a security template to local policy

Microsoft Windows graphic

To apply a security template to local policy

  1. Open Security Configuration and Analysis.
  2. In the console tree, right-click Security Configuration and Analysis, and then click Open Database.

    Where?

    • ConsoleRoot
    • Security Configuration and Analysis
  3. In Open database, in File name, type a file name and then click Open.
  4. In Import Template, click a template, and then click Open.
  5. In the console tree, right-click Security Configuration and Analysis, and then click Configure Computer Now.
  6. Do one of the following:
    • To use the default log, in Error log file path, click OK.
    • To specify a different log, in Error log file path, type a valid path and file name.

Notes

  • To open Security Configuration and Analysis, click Start, and click Run, then type mmc and click OK. On the File menu, click Open, click the console that you want to open, then click Open. Then, in the console tree, click Security Configuration and Analysis.
  • XOX
  • To check the log file, right click Security Configuration and Analysis and then click View Log File.
  • The default path for the log file is:

    systemroot\Documents and Settings\UserAccount\My Documents\Security\Logs\

  • The security settings on the local computer take effect immediately.
  • To import more than one template to your computer policy, see To import a security template.

Related Topics


Import a security template to a Group Policy object

Microsoft Windows graphic

To import a security template to a Group Policy object

  1. Perform one of these steps
    2. If Do this
    You are on a workstation or server which is joined to a domain and you would like to import a security template for a Group Policy object.
    • Click Start, point to Run, type mmc and click OK.
    • On the File menu, click Add/Remove snap-in.
    • In Add/Remove Snap-in, click Add, in Add Standalone Snap-in, double-click Group Policy.
    • In Select Group Policy Object, click Browse, browse to the policy object you would like to modify, and click Finish.
    • Click Close and then click OK.
    You are on a domain controller and you would like to import a security template for a domain or organizational unit.
    • Open Active Directory Users and Computers.
    • In the console tree, right-click the domain or organizational unit you want to set Group Policy for.
    • Click Properties, and then click the Group Policy tab.
    • Click Edit to open the Group Policy object you want to edit or click New to create a new Group Policy object, and then click Edit.
  2. In the Group Policy console tree, right-click Security Settings.

    3. Where?

    • Group Policy Object Policy
    • Computer Configuration
    • Windows Settings
    • Security Settings
  3. Click Import Policy.
  4. Click the security template you want to import and click Open.

Note

  • Importing a security template to a Group Policy object ensures that any accounts to which the Group Policy object is applied will automatically receive the template's security settings when the Group Policy settings are refreshed. For domain controllers running Windows NT 4.0, you must configure the Primary Domain Controller policies to enable this replication. The security settings are applied at system start time or as the Group Policy settings dictate.

  • Do not import Setup security.inf to a Group Policy object.
  • XOX

Related Topics


Delete a security template

Microsoft Windows graphic

To delete a security template

  1. Open Security Templates.
  2. In the console tree, right-click the security template you want to delete.

    3. Where?

    • ConsoleRoot
    • Security Templates
    • Template Path
    • SecurityTemplate
  3. Click Delete.

Notes

  • To open Security Templates, click Start, and click Run, then type mmc and click OK. On the File menu, click Open, click the console that you want to open, then click Open. Then, in the console tree, click Security Templates.
  • XOX

Related Topics


Concepts

This section provides general background information on using Security Templates to manage system security:

  • Security Templates overview
  • Predefined security templates
  • Understanding Security Templates
  • Security Setting Descriptions
  • Resources
  • Troubleshooting


Security Templates overview

With Security Templates, you can create a security policy for your computer or network. It is a single point of entry where the full range of system security can be taken into account. Security Templates does not introduce new security parameters; it simply organizes all existing security attributes into one place to ease security administration.

Importing a security template to a Group Policy object eases domain administration by configuring security for a domain or organizational unit at once. For more information, see To import a security template to a Group Policy object.

In order to apply a security template to your local computer, you can use Security Configuration and Analysis. For more information, see To configure local computer security.

Security templates can be used to define:

Security area | Description
Account Policies | Password Policy, Account Lockout Policy, and Kerberos Policy
Local Policies | Audit Policy, User Rights Assignment, and Security Options
Event Log | Application, system, and security Event Log settings
Restricted Groups | Membership of security-sensitive groups
System Services | Startup and permissions for system services
Registry | Permissions for registry keys
File System | Permissions for folders and files

Each template is saved as a text-based .inf file. This enables you to copy, paste, import, or export some or all of the template attributes. With the exceptions of IP Security and public key policies, all security attributes can be contained in a security template.

New and predefined templates

You can create a new security template with your own preferences or use one of the predefined security templates. Before making any changes to your security settings you should understand what the default settings of your system are and what they mean. For more information, see Default security settings.

There are several predefined templates that can help you to secure your system based on your needs, these templates are for:

  • Reapplying default settings. (Setup security.inf)
  • Implementing a highly secure environment. (Hisecws.inf)
  • Implementing a less secure but more compatible environment. (Compatws.inf)
  • Securing the system root. (Rootsec.inf)

For more information, see Predefined security templates.


Predefined security templates

The predefined security templates are provided as a starting point for creating security policies that are customized to meet different organizational requirements. You can customize the templates with the Security Templates snap-in. Once you customize the predefined security templates, you can use them to configure an individual computer or thousands of computers. You can configure individual computers with the Security Configuration and Analysis snap-in, the Secedit.exe command prompt tool, or by importing the template into Local Security Policy. You can configure multiple machines by importing a template into Security Settings, which is an extension to Group Policy. You can also use a security template as a baseline for analyzing a system for potential security holes or policy violations by using the Security Configuration and Analysis snap-in. By default, the predefined security templates are stored in:

systemroot\Security\Templates

  • Default security (Setup security.inf)

    • Setup security.inf is a computer-specific template that represents the default security settings that are applied during installation of the operating system, including the file permissions for the root of the system drive. You can use this template, or portions of it can be used for disaster recovery purposes. Setup security.inf should never be applied using Group Policy.

  • Compatible (Compatws.inf)

    • Default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Administrators have the most privileges while Users have the least. Because of this, you can significantly improve the security, reliability, and total cost of system ownership by:

    • Making sure that end-users are members of the Users group.
    • Deploying applications that can be run successfully by members of the Users group.

    People with User privileges can successfully run applications that take part in the Certified for Windows program. However, you probably cannot run applications that are not certified in a User context. If non-certified applications must be supported, there are two options:

    1. Allow members of the Users group to be members of the Power Users group.
    2. Relax the default permissions that are granted to the Users group.

    Since Power Users have inherent capabilities, such as creating users, groups, printers and shares, some administrators would rather relax the default User permissions than allow end-users to be members of the Power Users group. This is precisely what the Compatible template is for. The Compatible template changes the default file and registry permissions that are granted to Users in a manner that is consistent with the requirements of most non-certified applications. Additionally, since it is assumed that the administrator that is applying the Compatible template does not want end users to be Power Users, the Compatible template also removes all members of the Power Users group. For more information, see Default security settings.

    For more information on the Certified for Windows Program, see the Microsoft Web site. (http://msdn.microsoft.com)

    The Compatible template should not be applied to domain controllers. For example, do not import the Compatible template to the Default Domain policy or Default Domain Controller policy.

  • Secure (Secure*.inf)

    • The Secure templates define enhanced security settings that are least likely to impact application compatibility. For example, the Secure templates define stronger password, lockout, and audit settings.

    Additionally, the Secure templates limit the use of LAN Manager and NTLM authentication protocols by configuring clients to send only NTLMv2 responses and configuring servers to refuse LAN Manager responses.

    • In order to apply Securews.inf to a member machine, all of the domain controllers that contain the accounts of all users that log on to the client must run Windows NT 4.0 Service Pack 4 or higher.
    • If a server is configured with Securews.inf, then a client with a local account on that server will not be able to connect to it from a client computer running LAN Manager that is using that local account.
    • If a domain controller is configured with Securedc.inf, then a user with an account in that domain will not be able to connect to any member server from a client computer running LAN Manager that uses their domain account.
    • Clients that run LAN Manager include Windows for Workgroups as well as Windows 95 and Windows 98 platforms that do not have the DS Client Pack installed. If the DS Client Pack is installed on Windows 95 or Windows 98, then those clients will be able to use NTLMv2. Windows Millennium Edition supports NTLMv2 without additional modification.

    The Secure templates also provide further restrictions for anonymous users by preventing anonymous users (such as users from untrusted domains) from:

    • Enumerating account names and shares.
    • Performing SID-to-name or name-to-SID translations.

    Finally, the Secure templates enable server-side SMB packet signing, which is disabled by default for workstations and servers. Since client-side SMB packet signing is enabled by default, SMB packet signing is always be negotiated when workstations and servers are operating at the Secure level.

  • Highly Secure (hisec*.inf)

    • The Highly Secure templates are supersets of the secure templates that impose further restrictions on the levels of encryption and signing that are required for authentication and for the data that flows over secure channels and between SMB clients and servers. For example, while the Secure templates cause servers to refuse LAN Manager responses, the Highly Secure templates cause servers to refuse both LAN Manager and NTLM responses. While the Secure template enables server-side SMB packet signing, the Highly Secure template requires it. Additionally, the Highly Secure templates require strong encryption and signing for the secure channel data that constitutes domain-to-member and domain-to-domain trust relationships.

    • In order to apply Hisecws.inf to a computer:
      • All of the domain controllers that contain the accounts of all users that will log on to the client must run Windows NT 4.0 Service Pack 4 or later.
      • All of the domain controllers for the domain that the client is joined to must run Windows 2000.
    • In order to apply Hisecdc.inf to a domain controller, all of the domain controllers in all trusted or trusting domains must run Windows 2000.
    • If a server is configured with Hisecws.inf, then a client with a local account on that server will not be able to connect to it from a client that does not support NTLMv2.
    • If a server is configured with Hisecws.inf, then all clients that want to use SMB to connect to that server must enable client-side SMB packet signing. All computers running Windows 2000 and Windows XP Professional enable client-side SMB packet signing by default.
    • If a domain controller is configured with Hisecdc.inf, then a user with an account in that domain cannot connect to any member server from a client that does not support NTLMv2.
    • If a domain controller is configured with Hisecdc.inf, then Lightweight Directory Access Protocol (LDAP) clients will not be able to bind with the Active Directory LDAP server unless data signing is negotiated. Bind requests using ldap_simple_bind or ldap_simple_bind_s are rejected. By default, all Microsoft LDAP clients that ship with Windows XP Professional will request data signing if TLS\SSL is not already being used. If TLS\SSL is being used then data signing is considered to be negotiated.

    Clients that do not support NTLMv2 include Windows for Workgroups, Windows NT clients prior to Service Pack 4, and Windows 95 and Windows 98 platforms that do not have the DS Client Pack installed.

    In addition to further restrictions on the use of LAN Manager protocols and the requirements for encryption and signing of secure channel and SMB traffic, the Highly Secure templates also limit the use of cached logon data, such as data stored by Winlogon and Stored User Names and Passwords.

    Finally, Hisecws.inf uses restricted group settings to:

    • Remove all members of the Power Users group.
    • Ensure that only Domain Admins and the local Administrator account are members of the local Administrators group.
    Hisecws defines these group restrictions under the assumption that only applications that are certified for Windows 2000 are deployed. With certified applications in place, neither the insecure Compatible template nor the insecure Power Users group is needed. Instead, users can run certified applications successfully under the secure context of a normal User which is defined by the default security settings of the file system and registry.

  • System root security (Rootsec.inf)

    • Rootsec.inf specifies the new root permissions introduced with Windows XP Professional. By default, Rootsec.inf defines these permissions for the root of the system drive. This template can be used to reapply the root directory permissions if they are inadvertently changed, or the template can be modified to apply the same root permissions to other volumes. As specified, the template does not overwrite explicit permissions that are defined on child objects; it propagates only the permissions that are inherited by child objects.

  • No Terminal Server user SID (Notssid.inf)

    • The default file system and registry access control lists that are on servers grant permissions to a Terminal Server SID. The Terminal Server SID is used only when Terminal Server is running in application compatibility mode. If Terminal Server is not being used, this template can be applied to remove the unnecessary Terminal Server SIDs from the file system and registry locations. However, removing the access control entry for the Terminal Server SID from these default file system and registry locations does not increase the security of the system. Instead of removing the Terminal Server SID, simply run Terminal Server in Full Security mode. When running in Full Security mode, the Terminal Server SID is not used.

Caution

  • These security templates are constructed with the assumption that they will be applied to computers that use the default security settings. In other words, these templates incrementally modify the default security settings, if they are on the computer. They do not install the default security settings before performing the modifications.
  • Predefined security templates should not be applied to production systems without testing to ensure that the right level of application functionality is maintained for your network and system architecture.

Security template settings can be viewed through Security Templates. The *.inf files can also be viewed as text files. These files are located in:

%windir%\Security\Templates

You cannot secure Windows XP Professional systems that are installed on FAT file systems.

Related Topics


Understanding Security Templates

Security Templates enables you to define file representations of a security policy. You can configure security for:

  • Account and local policies
  • Event log
  • Restricted groups
  • File system, registry, system services


Account and local policies

Account policies

All security policies are computer-based policies. Account policies are defined on computers, yet they affect how user accounts can interact with the computer or domain. Account policies contain three subsets:

  • Password policy. Used for domain or local user accounts. Determines settings for passwords, such as enforcement and lifetimes.
  • Account lockout policy. Used for domain or local user accounts. Determines the circumstances and length of time that an account will be locked out of the system.
  • Kerberos policy. Used for domain user accounts. Determines Kerberos-related settings, such as ticket lifetimes and enforcement. Kerberos policies do not exist in local computer policy.

For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain policy and is enforced by the domain controllers that make up the domain. A domain controller always obtains the account policy from the Default Domain Policy Group Policy object, even if there is a different account policy applied to the organizational unit that contains the domain controller. By default, workstations and servers joined to a domain (such as member computers) will also receive the same account policy for their local accounts. However, local account policies can be different from the domain account policy, such as when you define an account policy specifically for the local accounts.

There are two policies in Security Options that also behave like account policies. These are:

  • Network Access: Allow anonymous SID/NAME translation
  • Network Security: Force Logoff when Logon Hours expire

Local policies

These policies apply to a computer and contain these subsets:

  • Audit policy. Determines whether security events are logged into the Security log on the computer. Also determines whether to log successful attempts, failed attempts or both. (The Security log is part of Event Viewer.)
  • User rights assignment. Determines which users or groups have logon rights or privileges on the computer.
  • Security options. Enables or disables security settings for the computer, such as digital signing of data, Administrator and Guest account names, floppy drive and CD-ROM access, driver installation, and logon prompts.

Because a computer can have more than one policy applied to it, there can be conflicts in security policy settings. The order of precedence from highest precedence to lowest precedence is organizational unit, domain, and local computer. For more information, see Applying security policy.


Event log

This security area defines attributes that are related to the application, security, and system logs: maximum log size, access rights for each log, and retention settings and methods. The application log records events generated by programs; the security log records security events, including logon attempts, object access, and changes to security, depending on what is audited; and the system log records operating system events. For more information, see Event Viewer.

For more information on event log policies, see Settings for Event Logs.


Restricted Groups policy

You can use Restricted Groups policy to control group membership. Using the policy, you can specify what members are part of a group. Any members that are not specified in the policy are removed during configuration or refresh. In addition, the reverse membership configuration option ensures that each Restricted Group is a member of only those groups specified in the Member Of column.

For example, you can create a Restricted Groups policy to only allow specified users (for example, Alice and John) to be members of the Administrators group. When policy is refreshed, only Alice and John will remain as members of the Administrators group.

There are two ways to apply Restricted Groups policy:

  • Define the policy in a security template which will be applied during configuration on your local computer or when you import the security template to a Group Policy object.
  • Define the setting on a Group Policy object directly which would mean the policy would go into effect with the next refresh of policy. XOX

Caution

  • If a Restricted Groups policy is defined and Group Policy is refreshed, any current member not on the Restricted Groups policy members list is removed. This can include default members, such as administrators.

Important

  • Restricted Groups should be used primarily to configure membership of local groups on workstation or member servers.

Related Topics


File system, registry, system services

File system and registry keys

You can configure security attributes using Security Configuration Manager for all existing files, folders, and registry keys in the local file system:

  • Propagate inheritable permissions to all subfolders and files (or subkeys). Any child objects of this object inherit the parent object's security settings, provided the child object is not protected from inheritance. If there is a conflict, the explicit permissions on the child object will override the permissions inherited from the parent object.
  • Replace existing permissions on all subfolders and files (or subkeys) with inheritable permissions. The parent object's permission entries will override any security settings on the child object, regardless of the child object's settings. The child object will have identical access control entries as the parent object.

    Caution

    • If you select this option and then click Apply, you will override all child object security settings. You will not be able to reset the child object security settings by clearing the check box.
  • Do not allow permissions on this file or folder (or key) to be replaced. Use this setting if you do not want to configure or analyze security for this object or any of its child objects.

For more information on file and folder permissions, see Permissions for files and folders.

System services

You can select this if the startup mode is:
  • Automatic: Automatically starts when computer is restarted.
  • Manual: Does not start unless someone starts it.
  • Disabled: The service cannot be started.

Notes

  • You can also edit the security properties of the object, such as which user or group accounts have permission to read, write, delete, or execute inheritance settings or auditing and ownership permission by clicking Edit Security.
  • If you choose to set system service startup to Automatic, perform adequate testing to verify that the services can start without user intervention.
  • You should track the system services used on a computer. For performance optimization, set unnecessary or unused services to Manual.


Resources

For more information about security, see the Microsoft Windows Resource Kits Web site.(http://www.microsoft.com/)

For information and the latest recommendations on security, see the Microsoft Security page on the Microsoft Web site (http://www.microsoft.com).


Troubleshooting

What problem are you having?

The security database is corrupted.

Cause: A hardware problem if the computer is improperly shut down or a software error.

Run esentutl /g to check the integrity of the security database at %windir%\Security\Database\Secedit.sdb.

If the database is corrupt:

  1. Attempt to recover it by running esentutl /r on the %windir%\Security folder. If this fails, attempt to repair it by running with esentutl /p on %windir%\Security\Database\Secedit.sdb.
  2. After that, delete the log files in %windir%\Security.

Security policy is not propagating correctly.

Cause: Any.

Solution: Use Resultant Set of Policy to check what Group Policy object is affecting your computer.

Check the log file. The log file is located in systemroot\Security\Logs\Winlogon.log. You can examine this log file to identify specific errors that occur during policy propagation to the computer.

Security policies are propagated with the following warning: 0x534 : No mapping between account names and security IDs was done.

Cause: This is usually caused because the security policy grants rights to user or group accounts which no longer exist.

Solution: Find out which accounts are invalid.

  1. Open Notepad and open the file at %systemroot%\security\logs\winlogon.log. Windows XP creates this file by default during policy propagation.
  2. Search for error 1332. This indicates the account names that could not be resolved.
  3. Remove the unresolved account names from policies in your domain.

If the accounts are in the Default Domain or Domain Controller Group Policy objects, you can edit the policies in the Security Settings node of Group Policy to remove these account names. If the accounts exist elsewhere, you may have to browse through all Group Policy objects that are defined in the domain and remove them individually.


Security Configuration Manager Tools

You can use these tools to manage security policy on your computer, organizational unit, or domain.
Security Configuration Manager Tool | Description
Security Templates | A security template is a file which represents a security configuration or security policy. These templates can then be applied to your local computer policy or imported to a Group Policy object.
Security Configuration and Analysis | You can use this tool to analyze or configure computer security using a security template.
Security Settings extension to Group Policy | You can use this tool to edit individual security settings on a domain, site, or organizational unit.
Local Security Policy | You can use this tool to edit individual security settings for your local computer.
Secedit.exe Command-line tool | You can use this tool for automating security configuration tasks.


Logon rights

The following table lists and describes logon rights. These default settings are for Windows XP Professional.

Logon Right | Description
Access this computer from a network | Allows a user to connect to the computer over the network. Default setting: Administrators, Everyone, Users, Power Users, and Backup Operators.
Allow logon through terminal services | Allows a user to log on to this computer through a Remote Desktop connection. Default setting: Administrators and Remote Desktop Users
Log on as a batch job | Allows a user to log on using a batch-queue facility. Default setting: No one. If Internet Information Services (IIS) are installed, the right is automatically assigned to a built-in account for anonymous access to IIS.
Log on as a service | Allows a security principal to log on as a service. Services can be configured to run under the LocalSystem, LocalService, or NetworkService accounts, which have a built?in right to log on as a service. Any service that runs under a separate user account must be assigned the right Default setting: No one
Log on locally | Allows a user to log on at the computer's keyboard. Default setting: Administrators, Power Users, Users, Guest, and Backup Operators.
Log on as a service | Allows a security principal to log on as a service. Services can be configured to run under the LocalSystem, LocalService, or NetworkService accounts, which have a built-in right to log on as a service. Any service that runs under a separate user account must be assigned the right. Default setting: No one
Deny access to this computer from network | Prohibits a user or group from connecting to the computer from the network. Default setting: No one
Deny local logon | Prohibits a user or group from logging on directly at the keyboard. Default setting: No one
Deny logon as a batch job | Prohibits a user or group from logging on through a batch-queue facility. Default setting: No one
Deny logon as a service | Prohibits a user or group from logging on as a service. Default setting: No one
Deny logon through terminal services | Prohibits a user or group from logging on as a Terminal Services client. Default setting: No one

The special user account LocalSystem has almost all privileges and logon rights assigned to it, because all processes that are running as part of the operating system are associated with this account and these processes require a complete set of user rights.

Related Topics


Privileges

To ease the task of user account administration, you should assign privileges primarily to group accounts, rather than to individual user accounts. When you assign privileges to a group account, users are automatically assigned those privileges when they become a member of that group. This method of administering privileges is far easier than assigning individual privileges to each user account when the account is created.

The following table lists and describes the privileges that can be granted to a user.

Privilege Description
Act as part of the operating system

Allows a process to authenticate like a user and thus gain access to the same resources as a user. Only low-level authentication services should require this privilege. Note that potential access is not limited to what is associated with the user by default; the calling process might request that arbitrary additional privileges be added to the access token. The calling process might also build an access token that does not provide a primary identity for tracking events in the audit log.

Processes that require this privilege should use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned.

Default setting: No one

Add workstations to a domain

Allows the user to add a computer to a specific domain. For the privilege to be effective, it must be assigned to the user as part of the Default Domain Controllers Policy for the domain. A user who has this privilege can add up to 10 workstations to the domain.

Users can also be allowed to join a computer to a domain by giving them Create Computer Objects permission for an organizational unit or for the Computers container in Active Directory. Users who have the Create Computer Objects permission can add an unlimited number of computers to the domain, regardless of whether they have been assigned the Add workstations to a domain privilege.

Default setting: No one
Adjust memory quotas for a process Determines which accounts can use a process with Write Property access to another process to increase the processor quota assigned to the other process.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Default setting: Administrators
Back up files and directories

Allows the user to circumvent file and directory permissions to back up the system. The privilege is selected only when an application attempts access through the NTFS backup application programming interface (API). Otherwise, normal file and directory permissions apply.

Default setting: Administrators and Backup Operators.
Bypass traverse checking

Allows the user to pass through folders to which the user otherwise has no access while navigating an object path in the NTFS file system or in the registry. This privilege does not allow the user to list the contents of a folder; it allows the user only to traverse its directories.

Default setting: Administrators, Backup Operators, Power Users, Users, and Everyone on member servers and workstations. On domain controllers, it is assigned to Administrators, Authenticated Users, and Everyone.
Change the system time

Allows the user to set the time for the internal clock of the computer.

Default setting: Administrators, Power Users, LocalService, and NetworkService on member servers and workstations. On domain controllers, it is assigned to Administrators, Server Operators, LocalService, and NetworkService.
Create a token object

Allows a process to create a token which it can then use to get access to any local resources when the process uses NtCreateToken() or other token-creation APIs.

It is recommended that processes requiring this privilege use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned

Default setting: No one

Create a pagefile

Allows the user to create and change the size of a pagefile. This is done by specifying a paging file size for a particular drive under Performance Options on the Advanced tab of System Properties.

Default setting: Administrators
Create permanent shared objects

Allows a process to create a directory object in the Windows XP Professional object manager. This privilege is useful to kernel-mode components that extend the object namespace. Components that are running in kernel mode already have this privilege inherently; it is not necessary to assign them the privilege.

Default setting: No one
Debug programs Allows the user to attach a debugger to any process. This privilege provides powerful access to sensitive and critical operating system components.

Default setting: Administrators
Enable computer and user accounts to be trusted for delegation Allows the user to change the Trusted for Delegation setting on a user or computer object in Active Directory. The user or computer that is granted this privilege must also have write access to the account control flags on the object. Delegation of authentication is a capability that is used by multi-tier client/server applications. It allows a front-end service to use the credentials of a client in authenticating to a back-end service. For this to be possible, both client and server must be running under accounts that are trusted for delegation. Misuse of this privilege or the Trusted for Delegation settings can make the network vulnerable to sophisticated attacks on the system that use Trojan horse programs, which impersonate incoming clients and use their credentials to gain access to network resources.

Default setting: This privilege is not assigned to anyone on member servers and workstations, as it has no meaning in those contexts. On domain controllers, it is assigned by default to Administrators.
Force shutdown from a remote system Allows a user to shut down a computer from a remote location on the network. See also the Shut Down the System privilege.

Default setting: Administrators on member servers and workstations. On domain controllers, it is assigned to Adminstrators and Server Operators.
Generate security audits Allows a process to generate entries in the security log. The security log is used to trace unauthorized system access. See also the privilege Manage auditing and security log.

Default setting: LocalService and NetworkService.

Increase scheduling priority Allows a process that has Write Property access to another process to increase the execution priority of the other process. A user with this privilege can change the scheduling priority of a process in Task Manager.

Default setting: Administrators
Load and unload device drivers Allows a user to install and uninstall Plug and Play device drivers. This privilege does not affect the ability to install drivers for devices that are not Plug and Play. Drivers for non-Plug and Play devices can be installed only by Administrators.

Default setting: Administrators. It is recommended that you not assign this privilege to any other user. Device drivers run as trusted (or highly privileged) programs. A user who has the Load and Unload Device Drivers privilege could unintentionally misuse it by installing malicious code masquerading as a device driver. It is assumed that administrators will exercise greater care and install only drivers with verified digital signatures
Lock pages in memory Allows a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk. Assigning this privilege can result in significant degradation of system performance.

Default setting: Not assigned to anyone. Certain system processes have the privilege inherently.
Manage auditing and security log Allows a user to specify object access auditing options for individual resources such as files, Active Directory objects, and registry keys. Object access auditing is not actually performed unless you have enabled it in Audit Policy (under Security Settings, Local Policies). A user who has this privilege also can view and clear the security log from Event Viewer.

A user with this privilege can also view and clear the security log from the Event Viewer.

Default setting: Administrators
Modify firmware environment values Allows modification of system environment variables either by a process through an API or by a user through System Properties.

Default setting: Administrators
Profile a single process Allows a user to run Windows XP Professional performance-monitoring tools to monitor the performance of nonsystem processes.

Default setting: Administrators and Power Users on member servers and workstations. On domain controllers, it is assigned only to Administrators
Profile system performance Allows a user to run performance-monitoring tools to monitor the performance of system processes.

Default setting: Administrators
Remove computer from docking station Allows the user of a portable computer to undock the computer by clicking Eject PC on the Start menu.

Default setting: Administrators, Power Users, and Users.
Relace a process level token Determines which user accounts can initiate a process to replace the default token associated with a started subprocess.

This user right is defined in the Default Domain Controller Group Policy object and in the local security policy of workstations and servers.

Default setting: Local Service and Network Service.

Restore files and directories Allows a user to circumvent file and directory permissions when restoring backed-up files and directories and to set any valid security principal as the owner of an object. See also the Back up files and directories privilege.

Default setting: Administrators and Backup Operators.

Shut down the system Allows a user to shut down the local computer.

Default setting: Administrators, Backup Operators, Power Users, and Users on workstations. On member servers, it is assigned to Administrators, Power Users, and Backup Operators. On domain controllers, it is assigned to Administrators, Account Operators, Backup Operators, Print Operators, and Server Operators.
Synchronize directory service data Allows a process to provide directory synchronization services. This privilege is relevant only on domain controllers.

Default setting: No one
Take ownership of files or other objects Allows a user to take ownership of any securable object in the system, including Active Directory objects, NTFS files and folders, printers, registry keys, services, processes, and threads.

Default setting: Administrators

Some privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the ability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A user right, in this case, the right to perform a backup, takes precedence over all file and directory permissions.

Related Topics


User rights

User rights grant specific privileges and logon rights to users and groups in your computing environment. For information on user rights, see the following:

  • Introduction to user rights
  • Privileges
  • Logon rights


Introduction to user rights

Administrators can assign specific rights to group accounts or to individual user accounts. These rights authorize users to perform specific actions, such as logging on to a system interactively or backing up files and directories. User rights are different from permissions because user rights apply to user accounts, and permissions are attached to objects. For information on permissions, see How inheritance affects file and folder permissions.

User rights define capabilities at the local level. Although user rights can apply to individual user accounts, user rights are best administered on a group account basis. This ensures that a user logging on as a member of a group automatically inherits the rights associated with that group. By assigning user rights to groups rather than individual users, you simplify the task of user account administration. When users in a group all require the same user rights, you can assign the set of user rights once to the group, rather than repeatedly assigning the same set of user rights to each individual user account.

User rights that are assigned to a group are applied to all members of the group while they remain members. If a user is a member of multiple groups, the user's rights are cumulative, which means that the user has more than one set of rights. The only time that rights assigned to one group might conflict with those assigned to another is in the case of certain logon rights. In general, however, user rights assigned to one group do not conflict with the rights assigned to another group. To remove rights from a user, the administrator simply removes the user from the group. In this case, the user no longer has the rights assigned to that group.

There are two types of user rights: privileges, such as the right to back up files and directories, and logon rights, such as the right to log on to a system locally.

For more information, see Privileges and Logon rights.


Default security settings

For Windows XP, there are three fundamental levels of security granted to users. These are granted to end users through membership in the Users, Power Users, or Administrators groups.

  • The Users group is the most secure, because the default permissions allotted to this group do not allow members to modify operating system settings or other users' data. However, user level permissions often do not allow the user to successfully run legacy applications. The members of the Users group are only guaranteed to be able to run programs which have been certified for Windows. For more information on the Certified for Windows Program, see the Microsoft Web site. (http://msdn.microsoft.com)
  • The Power Users group primarily provides backward compatibility for running non-certified applications. The default permissions allotted to this group allow this group's members to modify computerwide settings. If non-certified applications must be supported, then end users will need to be part of the Power Users group.
  • The Administrators group is provided to perform computer maintenance tasks. The default permissions allotted to this group allows complete control over the entire system. As a result, only trusted personnel should be members of this group.
By default, any user who logs on interactively is at least a member of the Users group. For computers that were upgraded from Windows NT 4.0, any user that logs on interactively is at least a member of the Power Users group.

Note

  • Security Configuration Manager allows you to control membership of the Administrators (or any other group) with Restricted groups policy.


Security features

You can use these features to manage security on your computer, organizational unit, or domain.
Feature | Description
Access Control | Access control allows you to secure objects so that only authorized users and groups can have access to them.
Auditing security events | Security auditing monitors various security-related events. Monitoring system events is necessary to detect intruders and to detect attempts to compromise data on the system. An example of an event that can be audited is a failed logon attempt.
Certificates | You can use this to manage certificates for yourself, for a computer, or for a service. Typical tasks include requesting certificates, viewing certificate information, importing certificates, and exporting certificates.
Encrypting File System | This feature encrypts files on a hard drive or file server so that only the specified user or users can access the contents.
Smart Cards | These devices provide additional security by storing a user's credentials on a portable smart card. The user must provide both the card and a Personal Identification Number to use the credentials.
Stored User Names and Passwords | This tool provides secure storage for user names and passwords that can be reused. This allows the user to use tools and connect to resources with different security credentials without providing those credentials every time.
Security Configuration Manager | This collection of tools is used for creating, modifying, and configuring security policy.
Security Templates | A security template is a file which represents a security configuration or security policy. These templates can then be applied to your local computer policy or imported to a Group Policy object.
Security Configuration and Analysis | You can use this tool to analyze or configure computer security using a security template.
Security Settings extension to Group Policy | You can use this tool to edit individual security settings on a domain, site, or organizational unit.
Local Security Policy | You can use this tool to edit individual security settings for your local computer.
Secedit.exe (command-line tool) | You can use this tool for automating security configuration tasks.

For the latest security updates, tips and tools see Microsoft Security on the Microsoft Web site (http://www.microsoft.com/).


Groups and default security settings

Microsoft Windows graphic

Default security settings

Before modifying any security settings, it is important to take into consideration the default settings.

There are three fundamental levels of security granted to users. These are granted to end users through membership in the Users, Power Users, or Administrators groups.

Administrators

Adding users to the Users group is the most secure option, because the default permissions allotted to this group do not allow members to modify operating system settings or other user's data. However, user level permissions often do not allow the user to successfully run legacy applications. The members of the Users group are only guaranteed to be able to run programs that have been certified for Windows. For more information on the Certified for Windows Program, see the Microsoft Web site.(http://msdn.microsoft.com) As a result, only trusted personnel should be members of this group.

Ideally, administrative access should only be used to:

  • Install the operating system and components (such as hardware drivers, system services, and so on).
  • Install Service Packs and Windows Packs.
  • Upgrade the operating system.
  • Repair the operating system.
  • Configure critical operating system parameters (such as password policy, access control, audit policy, kernel mode driver configuration, and so on).
  • Take ownership of files that have become inaccessible.
  • Manage the security and auditing logs.
  • Back up and restore the system.

In practice, Administrator accounts often must be used to install and run programs written for versions of Windows prior to Windows 2000.

Power Users

The Power Users group primarily provides backward compatibility for running non-certified applications. The default permissions that are allotted to this group allow this group's members to modify computerwide settings. If non-certified applications must be supported, then end users will need to be part of the Power Users group.

Members of the Power Users group have more permissions than members of the Users group and fewer than members of the Administrators group. Power Users can perform any operating system task except tasks reserved for the Administrators group. The default Windows 2000 and Windows XP Professional security settings for Power Users are very similar to the default security settings for Users in Windows NT 4.0. Any program that a user can run in Windows NT 4.0, a Power User can run in Windows 2000 or Windows XP Professional.

Power Users can:

  • Run legacy applications, in addition to Windows 2000 or Windows XP Professional certified applications.
  • Install programs that do not modify operating system files or install system services.
  • Customize systemwide resources including printers, date, time, power options, and other Control Panel resources.
  • Create and manage local user accounts and groups.
  • Stop and start system services which are not started by default.

Power Users do not have permission to add themselves to the Administrators group. Power Users do not have access to the data of other users on an NTFS volume, unless those users grant them permission.

Caution

  • Running legacy programs on Windows 2000 or Windows XP Professional often requires you to modify access to certain system settings. The same default permissions that allow Power Users to run legacy programs also make it possible for a Power User to gain additional privileges on the system, even complete administrative control. Therefore, it is important to deploy certified Windows 2000 or Windows XP Professional programs in order to achieve maximum security without sacrificing program functionality. Programs that are certified can run successfully under the Secure configuration provided by the Users group. For more information, see the Security page on the Microsoft Web site (http://www.microsoft.com).
  • Since Power Users can install or modify programs, running as a Power User when connected to the Internet could make the system vulnerable to Trojan horse programs and other security risks.
Users

The Users group is the most secure, because the default permissions allotted to this group do not allow members to modify operating system settings or other users' data.

The Users group provides the most secure environment in which to run programs. On a volume formatted with NTFS, the default security settings on a newly installed system (but not on an upgraded system) are designed to prevent members of this group from compromising the integrity of the operating system and installed programs. Users cannot modify systemwide registry settings, operating system files, or program files. Users can shut down workstations, but not servers. Users can create local groups, but can manage only the local groups that they created. They can run certified Windows 2000 or Windows XP Professional programs that have been installed or deployed by administrators. Users have Full Control over all of their own data files (%userprofile%) and their own portion of the registry (HKEY_CURRENT_USER).

However, user-level permissions often do not allow the user to successfully run legacy applications. Only the members of the Users group are guaranteed to be able to run Certified for Windows applications. (For more information, see the Certified for Windows Program on the Microsoft Web site. (http://msdn.microsoft.com)

To secure a Windows 2000 or Windows XP Professional system, an administrator should:

  • Make sure that end users are members of the Users group only.
  • Deploy programs that members of the Users group can run successfully, such as certified Windows 2000 or Windows XP Professional programs.

Users will not be able to run most programs written for versions of Windows prior to Windows 2000, because they did not support file system and registry security (Windows 95 and Windows 98) or shipped with lax default security settings (Windows NT). If you have problems running legacy applications on newly-installed NTFS systems, then do one of the following:

  1. Install new versions of the applications that are certified for Windows 2000 or Windows XP Professional.
  2. Move end users from the Users group into the Power Users group.
  3. Decrease the default security permissions for the Users group. This can be accomplished by using the Compatible security template.
Backup Operators

Members of the Backup Operators group can back up and restore files on the computer, regardless of any permissions that protect those files. They can also log on to the computer and shut it down, but they cannot change security settings.

Caution

  • Backing up and restoring data files and system files requires permissions to read and write those files. The same default permissions granted to Backup Operators that allow them to back up and restore files also make it possible for them to use the group's permissions for other purposes, such as reading another user's files or installing Trojan horse programs. Group Policy settings can be used to create an environment in which Backup Operators only can run a backup program. For more information, see the Microsoft Security page on the Microsoft Web site (http://www.microsoft.com).

Special Groups

Several additional groups are automatically created by Windows 2000 and Windows XP Professional.

When a Windows 2000 system is upgraded to Windows XP Professional, resources with permission entries for the Everyone group (and not explicitly to the Anonymous Logon group) will no longer be available to Anonymous users after the upgrade. In most cases, this is an appropriate restriction on anonymous access. you may need to permit anonymous access in order to support pre-existing applications that require it. If you need to grant access to the Anonymous logon group, you should explicitly add the Anonymous Logon security group and its permissions.

However, in some situations where it might be difficult to determine and modify the permission entries on resources hosted on Windows XP Professional computers, you can change the Network access: Let Everyone permissions apply to anonymous users security setting.

  • Interactive. This group contains the user who is currently logged on to the computer. During an upgrade to Windows 2000 or Windows XP Professional, members of the Interactive group will also be added to the Power Users group, so that legacy applications will continue to function as they did before the upgrade.
  • Network. This group contains all users who are currently accessing the system over the network.
  • Terminal Server User. When Terminal Servers are installed in application serving mode, this group contains any users who are currently logged on to the system using Terminal Server. Any program that a user can run in Windows NT 4.0 will run for a Terminal Server User in Windows 2000 or Windows XP Professional. The default permissions assigned to the group were chosen to enable a Terminal Server User to run most legacy programs.

Caution

  • Running legacy programs in Windows 2000 or Windows XP Professional requires permission to modify certain system settings. The same default permissions that allow a Terminal Server User to run legacy programs also make it possible for a Terminal Server User to gain additional privileges on the system, even complete administrative control. Applications that are certified for Windows 2000 or Windows XP Professional can run successfully under the secure configuration provided by the Users group. For more information, see the Microsoft Security page on the Microsoft Web site (http://www.microsoft.com).
  • Local accounts created on the local computer are created without passwords and are added to the Administrators group by default. If this is a concern, Security Configuration Manager allows you control membership of the Administrators (or any other group) with Restricted Groups policy. For more information, see Restricted Groups.

When Terminal Server is installed in remote administration mode, users logged on using Terminal Server will not be members of this group.

Related Topics


Difference in default security settings

Microsoft Windows graphic

Differences in default security settings

The Anonymous Logon group is no longer a member of the Everyone group. This change will impact anonymous users attempting to access resources hosted on computers running Windows XP Professional.

Anyone who accesses a computer and its resources through the network without an account name, password, or domain is a member of the Anonymous Logon built-in security group. In previous versions of Windows, members of the Anonymous Logon security group had access to many resources due to membership of the Everyone group. Because Administrators did not realize that anonymous users were members of the Everyone group, they might have inadvertently granted them access to resources only intended for authenticated users.

When a Windows 2000 system is upgraded to Windows XP Professional, resources with permission entries for the Everyone group (and not explicitly to the Anonymous Logon group) will no longer be available to anonymous users after the upgrade. In most cases, this is an appropriate restriction on anonymous access. You may need to permit anonymous access in order to support pre-existing applications that require it. If you need to grant access to the Anonymous logon group, you should explicitly add the Anonymous Logon security group and its permissions.

However, in some situations where it might be difficult to determine and modify the permission entries on resources hosted on Windows XP Professional computers you can change the security setting, Network access: Let Everyone permissions apply to anonymous users.

For more information, see To edit a security setting on a Group Policy object or To edit local computer security.

Important differences between Windows NT 4.0 and Windows XP Professional

Windows XP Professional provides three groups whose membership is controlled by the administrator: Users, Power Users, and Administrators. The group whose membership is controlled by the operating system or domain is Authenticated Users. It is the same as the Everyone group, except that it does not contain anonymous users or guests.

Unlike the Everyone group in Windows NT 4.0, the Authenticated Users group is not used to assign permissions. Only groups controlled by the administrator—primarily Users, Power Users, and members of the Administrators group—are used to assign permissions.

By default, any authenticated user is a member of the Users group. Power Users have all the capabilities that Windows NT 4.0 Users had. This ensures backward compatibility with Windows NT 4.0. If an administrator wants to implement higher security on a computer, Authenticated Users should be made members of the Users group only.

When a Professional or Server computer joins a domain, the same domain groups are added to the computer that were added to a Windows NT 4.0 computer. Domain Administrators are added to the local Administrators group and Domain Users are added to the local Users group.

Default owner for objects created by members of the administrators group

You can set whether the Administrators group or an object creator will be the default owner of any system objects created. In Windows XP Professional, the default is that the creator is the owner.

Related Topics