63 Network security: Force logoff when logon hours expire
65 Accounts: Rename administrator account
67 Accounts: Rename guest account
68 Reload\nReloads the local and effective policy tables from the policy database
69 Group Name
70 Event Log
71 Maximum system log size\nkilobytes
72 Retention method for system log
73 Retain system log\ndays
74 Maximum security log size\nkilobytes
75 Retention method for security log
76 Retain security log\ndays
77 Maximum application log size\nkilobytes
78 Retention method for application log
79 Retain application log\ndays
80 Shut down the computer when the security audit log is full
81 Audit Policy
82 Event Auditing Mode
83 Audit system events
84 Audit logon events
85 Audit object access
86 Audit privilege use
87 Audit policy change
88 Audit account management
89 Audit process tracking
90 Security Options
92 Not Defined
95 Cannot add members
96 Cannot display security
97 Cannot add users
98 Cannot add directory object
99 Cannot add a folder
100 -- Members
102 This file name contains some characters that can not be recognized by current system language. Please rename it.
103 Permission
104 Audit
106 Windows cannot add a file.
107 The template name is not valid.
108 An error occurred while exporting the stored template.
109 Windows cannot add a registry key
110 Full Control
111 Modify
112 Read and Execute
113 List Folder Contents
114 Read
115 Write
116 Traverse Folder/Execute File
117 Delete
120 None
121 Full Control
122 Read
123 Write
124 Query Value
125 Set Value
126 Create Subkey
127 Enumerate Subkeys
128 Notify
129 Create Link
130 Execute
131 Cannot create a thread
132 The following accounts could not be validated:\n
141 Log File Name
143 Perform Security Analysis
144 Security policy settings
146 Security Configuration and Analysis\nv1.0
147 Security Configuration and Analysis is an administrative tool used to secure a computer and analyze security aspects. You can create or edit a security template, apply the security template, perform analyses based on a template, and display analysis results.
148 Last analysis was performed on\n
149 Base security configuration description:\n
150 The computer was configured by the following template.\nAnalysis was not performed.
151 The database has not been configured or analyzed using Security Configuration and Analysis.
388 O&pen Database...\nOpen an existing or new database
389 &New Database...\nCreate and open a new database
390 Set Descri&ption...\nCreate a description for the templates in this directory
392 \help\sce.chm
395 All files (*.*)|*.*||
396 Database: %s
397 An unknown error occured when attempting to open the database.
398 Before you can use the database, you must analyze it. On the Database menu, select the option to run an analysis.
399 The database you are attempting to open does not exist. On the Database menu, click Import Template.
400 The database is corrupt. For information about fixing the database, see online Help.
401 There is not enough memory available to load the database. Close some programs and then try again.
402 Access to the database is denied. Unless the permissions on the database have been changed, you must have administrative rights to use it.
403 \Security\Database
404 Do you want to save changes to %s?
405 There is an existing imported template pending. To save, click Cancel, and then run an analysis or configuration before importing another template. To ignore the previous imported template, click OK.\n
406 All Selected Files
407 Deny log on locally
408 Deny access to this computer from the network
409 Deny log on as a service
410 Deny log on as a batch job
411 Add Group
412 &Group:
413 Not Analyzed
414 Error Analyzing
415 Not Defined
416 Suggested Setting
417 Local Policy ...\nCreate template file from the local policy settings
418 Effective Policy ...\nCreate template file from the effective policy settings
419 <H2>Security Configuration and Analysis</H2> <H4>To Open an Existing Database</H4> <OL><LI ALIGN="LEFT" ID="OPEN_DATABASE_1">Right-click the <I>Security Configuration and Analysis</I> scope item <LI ALIGN="LEFT" ID="OPEN_DATABASE_2">Click <B>Open Database</B> <LI ALIGN="LEFT" ID="OPEN_DATABASE_3"> Select a database, and then click <b>Open</b></OL> <H4>To Create a New Database</H4><OL> <LI ALIGN="LEFT" ID="OPEN_DATABASE_4">Right-click the <I>Security Configuration and Analysis </I> scope item <LI ALIGN="LEFT" ID="OPEN_DATABASE_5"> Click <B>Open Database</B> <LI ALIGN="LEFT" ID="OPEN_DATABASE_6"> Type a new database name, and then click <b>Open</b> <LI ALIGN="LEFT" ID="OPEN_DATABASE_7">Select a security template to import, and then click <b>Open</b></OL>
422 The database you are attempting to open does not exist.
423 You can create a new local policy database by choosing <B>Import Policy</B> from the <I>Security Settings</I> menu commands.
424 Access to database has been denied.
425 View Lo&g File\nToggle display of the log file or folder tree when Security Configuration and Analysis node is selected
426 <BR>You can now configure or analyze your computer by using the security settings in this database.<BR> <H4>To Configure Your Computer</H4><OL><LI ALIGN="LEFT" ID="NO_ANALYSIS_1">Right-click the <I>Security Configuration and Analysis</I> scope item<LI ALIGN="LEFT" ID="NO_ANALYSIS_2">Select <B>Configure Computer Now</B><LI ALIGN="LEFT" ID="NO_ANALYSIS_3">In the dialog, type the name of the log file you wish to view, and then click <B>OK</B></OL><B>NOTE:</B> After configuration is complete, you must perform an analysis to view the information in your database<BR><BR><H4>To Analyze Your Computer Security Settings</H4> <OL><LI ALIGN="LEFT" ID="NO_ANALYSIS_4">Right-click the <I>Security Configuration and Analysis</I> scope item<LI ALIGN="LEFT" ID="NO_ANALYSIS_5">Select <B>Analyze Computer Now</B><LI ALIGN="LEFT" ID="NO_ANALYSIS_6">In the dialog, type the log file path, and then click <B>OK</B></OL><BR><B>NOTE:</B> To view the log file created during a configuration or analysis, select <B>View Log File</B> on the <I>Security Configuration and Analysis</I> context menu.
427 <h3> Error Reading Location</h3>
428 Computer Setting
429 Policy Setting
430 Secure &Wizard...\nSecure Server Role Wizard
431 Windows cannot import invalid template %s
432 Accounts: Administrator account status
433 Accounts: Guest account status
434 Properties
435 The username is not valid. It is empty or it may not contain any of the following characters:\n%1
436 No minimum
437 User and group names may not contain any of the following characters:\n%1
438 The system can not find the path specified:\n%1
439 File name may not contain any of the following characters:\n%1
440 A startup mode must be selected.
441 Object "%1" cannot be deleted because an open window is displaying its properties.\nTo delete this object, close that window and select "Delete" again.
442 Configure Membership for %.17s...
443 Reset account lockout counter after
444 Set Descri&ption...\nCreate a description for this template
445 Description may not contain any of the following characters:\n%1
446 Template Setting
447 Policy Setting
449 Make sure that you have the right permissions to this object.
450 Make sure that this object exists.
451 The folder %1 cannot be used. Choose another folder.
697 File name may not only contain any of the following characters:\n%1
698 %1\nThis file name is a reserved device name.\nChoose another name.
699 The file type is not correct.
700 You must be a member of the Administrators group to perform the requested operation.
701 The file name %1 is not valid.\nReenter the file name in the correct format, such as c:\location\file.%2.
702 No mapping between account names and security IDs was done
709 To affect domain accounts, this setting must be defined in default domain policy.
718 Local Security Policy
1900 Enforce password history\n\nThis security setting determines the number of unique new passwords that have to be associated with a user account before an old password can be reused. The value must be between 0 and 24 passwords.\n\nThis policy enables administrators to enhance security by ensuring that old passwords are not reused continually.\n\nDefault:\n\n24 on domain controllers.\n0 on stand-alone servers.\n\nNote: By default, member computers follow the configuration of their domain controllers.\nTo maintain the effectiveness of the password history, do not allow passwords to be changed immediately after they were just changed by also enabling the Minimum password age security policy setting. For information about the minimum password age security policy setting, see Minimum password age.\n\n
1901 Maximum password age\n\nThis security setting determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If the maximum password age is between 1 and 999 days, the Minimum password age must be less than the maximum password age. If the maximum password age is set to 0, the minimum password age can be any value between 0 and 998 days.\n\nNote: It is a security best practice to have passwords expire every 30 to 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to crack a user's password and have access to your network resources.\n\nDefault: 42.\n\n
1902 Minimum password age\n\nThis security setting determines the period of time (in days) that a password must be used before the user can change it. You can set a value between 1 and 998 days, or you can allow changes immediately by setting the number of days to 0.\n\nThe minimum password age must be less than the Maximum password age, unless the maximum password age is set to 0, indicating that passwords will never expire. If the maximum password age is set to 0, the minimum password age can be set to any value between 0 and 998.\n\nConfigure the minimum password age to be more than 0 if you want Enforce password history to be effective. Without a minimum password age, users can cycle through passwords repeatedly until they get to an old favorite. The default setting does not follow this recommendation, so that an administrator can specify a password for a user and then require the user to change the administrator-defined password when the user logs on. If the password history is set to 0, the user does not have to choose a new password. For this reason, Enforce password history is set to 1 by default.\n\nDefault:\n\n1 on domain controllers.\n0 on stand-alone servers.\n\nNote: By default, member computers follow the configuration of their domain controllers.\n\n
1903 Minimum password length\n\nThis security setting determines the least number of characters that a password for a user account may contain. You can set a value of between 1 and 14 characters, or you can establish that no password is required by setting the number of characters to 0.\n\nDefault:\n\n7 on domain controllers.\n0 on stand-alone servers.\n\nNote: By default, member computers follow the configuration of their domain controllers.\n\n
1904 Password must meet complexity requirements\n\nThis security setting determines whether passwords must meet complexity requirements.\n\nIf this policy is enabled, passwords must meet the following minimum requirements:\n\nNot contain the user's account name or parts of the user's full name that exceed two consecutive characters\nBe at least six characters in length\nContain characters from three of the following four categories:\nEnglish uppercase characters (A through Z)\nEnglish lowercase characters (a through z)\nBase 10 digits (0 through 9)\nNon-alphabetic characters (for example, !, $, #, %)\nComplexity requirements are enforced when passwords are changed or created.\n\n\n\nDefault:\n\nEnabled on domain controllers.\nDisabled on stand-alone servers.\n\nNote: By default, member computers follow the configuration of their domain controllers.\n\n
1905 Store passwords using reversible encryption\n\nThis security setting determines whether the operating system stores passwords using reversible encryption.\n\nThis policy provides support for applications that use protocols that require knowledge of the user's password for authentication purposes. Storing passwords using reversible encryption is essentially the same as storing plaintext versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information.\n\nThis policy is required when using Challenge-Handshake Authentication Protocol (CHAP) authentication through remote access or Internet Authentication Services (IAS). It is also required when using Digest Authentication in Internet Information Services (IIS).\n\nDefault: Disabled.\n\n
1906 Account lockout duration\n\nThis security setting determines the number of minutes a locked-out account remains locked out before automatically becoming unlocked. The available range is from 0 minutes through 99,999 minutes. If you set the account lockout duration to 0, the account will be locked out until an administrator explicitly unlocks it.\n\nIf an account lockout threshold is defined, the account lockout duration must be greater than or equal to the reset time.\n\nDefault: None, because this policy setting only has meaning when an Account lockout threshold is specified.\n\n
1907 Account lockout threshold\n\nThis security setting determines the number of failed logon attempts that causes a user account to be locked out. A locked-out account cannot be used until it is reset by an administrator or until the lockout duration for the account has expired. You can set a value between 0 and 999 failed logon attempts. If you set the value to 0, the account will never be locked out.\n\nFailed password attempts against workstations or member servers that have been locked using either CTRL+ALT+DELETE or password-protected screen savers count as failed logon attempts.\n\nDefault: 0.\n\n
1908 Reset account lockout counter after\n\nThis security setting determines the number of minutes that must elapse after a failed logon attempt before the failed logon attempt counter is reset to 0 bad logon attempts. The available range is 1 minute to 99,999 minutes.\n\nIf an account lockout threshold is defined, this reset time must be less than or equal to the Account lockout duration.\n\nDefault: None, because this policy setting only has meaning when an Account lockout threshold is specified.\n\n
1909 Enforce user logon restrictions\n\nThis security setting determines whether the Kerberos V5 Key Distribution Center (KDC) validates every request for a session ticket against the user rights policy of the user account. Validation of each request for a session ticket is optional, because the extra step takes time and it may slow network access to services.\n\nDefault: Enabled.\n\n
1910 Maximum lifetime for service ticket\n\nThis security setting determines the maximum amount of time (in minutes) that a granted session ticket can be used to access a particular service. The setting must be greater than 10 minutes and less than or equal to the setting for Maximum lifetime for user ticket.\n\nIf a client presents an expired session ticket when it requests a connection to a server, the server returns an error message. The client must request a new session ticket from the Kerberos V5 Key Distribution Center (KDC). Once a connection is authenticated, however, it no longer matters whether the session ticket remains valid. Session tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the session ticket that is used to authenticate the connection expires during the connection.\n\nDefault: 600 minutes (10 hours).\n\n
1911 Maximum lifetime for user ticket\n\nThis security setting determines the maximum amount of time (in hours) that a user's ticket-granting ticket (TGT) may be used. When a user's TGT expires, a new one must be requested or the existing one must be "renewed."\n\nDefault: 10 hours.\n\n
1912 Maximum lifetime for user ticket renewal\n\nThis security setting determines the period of time (in days) during which a user's ticket-granting ticket (TGT) may be renewed.\n\nDefault: 7 days.\n\n
1913 Maximum tolerance for computer clock synchronization\n\nThis security setting determines the maximum time difference (in minutes) that Kerberos V5 tolerates between the time on the client clock and the time on the domain controller running Windows Server 2003 that provides Kerberos authentication.\n\nTo prevent "replay attacks," Kerberos V5 uses time stamps as part of its protocol definition. For time stamps to work properly, the clocks of the client and the domain controller need to be in sync as much as possible. In other words, both computers must be set to the same time and date. Because the clocks of two computers are often out of sync, administrators can use this policy to establish the maximum acceptable difference to Kerberos V5 between a client clock and domain controller clock. If the difference between a client clock and the domain controller clock is less than the maximum time difference that is specified in this policy, any time stamp that is used in a session between the two computers is considered to be authentic.\n\nImportant\n\nThis setting is not persistent. If you configure this setting and then restart the computer, this setting reverts to the default value.\n\nDefault: 5 minutes.\n\n
1914 Audit account logon events\n\nThis security setting determines whether to audit each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account. Account logon events are generated when a domain user account is authenticated on a domain controller. The event is logged in the domain controller's security log. Logon events are generated when a local user is authenticated on a local computer. The event is logged in the local security log. Account logoff events are not generated.\n\nIf you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when an account logon attempt succeeds. Failure audits generate an audit entry when an account logon attempt fails.\n\nTo set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.\n\nIf success auditing for account logon events is enabled on a domain controller, an entry is logged for each user who is validated against that domain controller, even though the user is actually logging on to a workstation that is joined to the domain.\n\nDefault: Success.\n\n
1915 Audit account management\n\nThis security setting determines whether to audit each event of account management on a computer. Examples of account management events include:\n\nA user account or group is created, changed, or deleted.\nA user account is renamed, disabled, or enabled.\nA password is set or changed.\nIf you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when any account management event succeeds. Failure audits generate an audit entry when any account management event fails. To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.\n\nDefault:\n\nSuccess on domain controllers.\nNo auditing on member servers.\n\n
1916 Audit directory service access\n\nThis security setting determines whether to audit the event of a user accessing an Active Directory object that has its own system access control list (SACL) specified.\n\nBy default, this value is set to no auditing in the Default Domain Controller Group Policy object (GPO), and it remains undefined for workstations and servers where it has no meaning.\n\nIf you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an Active Directory object that has a SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an Active Directory object that has a SACL specified. To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.\n\nNote that you can set a SACL on an Active Directory object by using the Security tab in that object's Properties dialog box. This is the same as Audit object access, except that it applies only to Active Directory objects and not to file system and registry objects.\n\nDefault:\n\nSuccess on domain controllers.\nUndefined for a member computer.\n\n
1917 Audit logon events\n\nThis security setting determines whether to audit each instance of a user logging on to or logging off from a computer.\n\nAccount logon events are generated on domain controllers for domain account activity and on local computers for local account activity. If both account logon and logon audit policy categories are enabled, logons that use a domain account generate a logon or logoff event on the workstation or server, and they generate an account logon event on the domain controller. Additionally, interactive logons to a member server or workstation that use a domain account generate a logon event on the domain controller as the logon scripts and policies are retrieved when a user logs on. For more information about account logon events, see Audit account logon events.\n\nIf you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a logon attempt succeeds. Failure audits generate an audit entry when a logon attempt fails.\n\nTo set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.\n\nDefault: Success.\n\n
1918 Audit object access\n\nThis security setting determines whether to audit the event of a user accessing an object for example, a file, folder, registry key, printer, and so forth that has its own system access control list (SACL) specified.\n\nIf you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an object that has an appropriate SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an object that has a SACL specified.\n\nTo set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.\n\nNote that you can set a SACL on a file system object using the Security tab in that object's Properties dialog box.\n\nDefault: No auditing.\n\n
1919 Audit policy change\n\nThis security setting determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust policies.\n\nIf you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a change to user rights assignment policies, audit policies, or trust policies is successful. Failure audits generate an audit entry when a change to user rights assignment policies, audit policies, or trust policies fails.\n\nTo set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.\n\nDefault:\n\nSuccess on domain controllers.\nNo auditing on member servers.\n\n
1920 Audit privilege use\n\nThis security setting determines whether to audit each instance of a user exercising a user right.\n\nIf you define this policy setting, you can specify whether to audit successes, audit failures, or not audit this type of event at all. Success audits generate an audit entry when the exercise of a user right succeeds. Failure audits generate an audit entry when the exercise of a user right fails.\n\nTo set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.\n\nDefault: No auditing.\n\nAudits are not generated for use of the following user rights, even if success audits or failure audits are specified for Audit privilege use. Enabling auditing of these user rights tend to generate many events in the security log which may impede your computer's performance. To audit the following user rights, enable the FullPrivilegeAuditing registry key.\n\nBypass traverse checking\nDebug programs\nCreate a token object\nReplace process level token\nGenerate security audits\nBack up files and directories\nRestore files and directories\n\nCaution\n\nIncorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.\n\n
1921 Audit process tracking\n\nThis security setting determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.\n\nIf you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when the process being tracked succeeds. Failure audits generate an audit entry when the process being tracked fails.\n\nTo set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.\n\nDefault: No auditing\n\n
1922 Audit system events\n\nThis security setting determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.\n\nIf you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a system event is executed successfully. Failure audits generate an audit entry when a system event is attempted unsuccessfully.\n\nTo set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.\n\nDefault:\n\nSuccess on domain controllers.\nNo auditing on member servers.\n\n
1923 Access this computer from the network\n\nThis user right determines which users and groups are allowed to connect to the computer over the network. Terminal Services are not affected by this user right.\n\nDefault on workstations and servers:\nAdministrators\nBackup Operators\nUsers\nEveryone\n\nDefault on domain controllers:\nAdministrators\nAuthenticated Users\nEnterprise Domain Controllers\nEveryone\nPre-Windows 2000 Compatible Access\n\n
1924 Act as part of the operating system\n\nThis user right allows a process to impersonate any user without authentication. The process can therefore gain access to the same local resources as that user.\n\nProcesses 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. If your organization only uses servers that are members of the Windows Server 2003 family, you do not need to assign this privilege to your users. However, if your organization uses servers running Windows 2000 or Windows NT 4.0, you might need to assign this privilege to use applications that exchange passwords in plaintext.\n\nCaution\n\nAssigning this user right can be a security risk. Only assign this user right to trusted users.\n\nDefault: None.\n\n
1925 Add workstations to domain\n\nThis security setting determines which groups or users can add workstations to a domain.\n\nThis security setting is valid only on domain controllers. By default, any authenticated user has this right and can create up to 10 computer accounts in the domain.\n\nAdding a computer account to the domain allows the computer to participate in Active Directory based networking. For example, adding a workstation to a domain enables that workstation to recognize accounts and groups that exist in Active Directory.\n\nDefault: Authenticated Users on domain controllers.\n\nNote: Users who have the Create Computer Objects permission on the Active Directory computers container can also create computer accounts in the domain. The distinction is that users with permissions on the container are not restricted to the creation of only 10 computer accounts. In addition, computer accounts that are created by means of Add workstations to domain have Domain Administrators as the owner of the computer account, while computer accounts that are created by means of permissions on the computers container have the creator as the owner of the computer account. If a user has permissions on the container and also has the Add workstations to domain user right, the computer is added, based on the computer container permissions rather than on the user right.\n\n
1926 Adjust memory quotas for a process\n\nThis privilege determines who can change the maximum memory that can be consumed by a process.\n\nThis user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.\n\nNote: This privilege is useful for system tuning, but it can be misused, for example, in a denial-of-service attack.\n\nDefault: Administrators\nLocal Service\nNetwork Service.\n\n
1927 Allow log on locally\n\nThis logon right determines which users can interactively log on to this computer. Logons initiated by pressing CTRL+ALT+DEL sequence on the attached keyboard requires the user to have this logon right. Additionally this logon right may be required by some service or administrative applications that can log on users. If you define this policy for a user or group, you must also give the Administrators group this right.\n\nDefault on workstations and servers: Administrators\nBackup Operators\nUsers.\n\nDefault on domain controllers: Account Operators\nAdministrators\nBackup Operators\nPrint Operators\nServer Operators.\n\n
1928 Allow log on through Terminal Services\n\nThis security setting determines which users or groups have permission to log on as a Terminal Services client.\n\nDefault:\n\nOn workstation and servers: Administrators, Remote Desktop Users.\nOn domain controllers: Administrators.\n\nImportant\n\nThis setting does not have any effect on Windows 2000 computers that have not been updated to Service Pack 2.\n\n
1929 Back up files and directories\n\nThis user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system.\n\nSpecifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system:\n\nTraverse Folder/Execute File\nList Folder/Read Data\nRead Attributes\nRead Extended Attributes\nRead Permissions\n\nCaution\n\nAssigning this user right can be a security risk. Since there is no way to be sure that a user is backing up data, stealing data, or copying data to be distributed, only assign this user right to trusted users.\n\nDefault on workstations and servers: Administrators\nBackup Operators.\n\nDefault on domain controllers:Administrators\nBackup Operators\nServer Operators\n\n
1930 Bypass traverse checking\n\nThis user right determines which users can traverse directory trees even though the user may not have permissions on the traversed directory. This privilege does not allow the user to list the contents of a directory, only to traverse directories.\n\nThis user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.\n\nDefault on workstations and servers:\nAdministrators\nBackup Operators\nUsers\nEveryone\nLocal Service\nNetwork Service\n\nDefault on domain controllers:\nAdministrators\nAuthenticated Users\nEveryone\nLocal Service\nNetwork Service\nPre-Windows 2000 Compatible Access\n\n
1931 Change the system time\n\nThis user right determines which users and groups can change the time and date on the internal clock of the computer. Users that are assigned this user right can affect the appearance of event logs. If the system time is changed, events that are logged will reflect this new time, not the actual time that the events occurred.\n\nThis user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.\n\nDefault on workstations and servers:\nAdministrators\nLocal Service\n\nDefault on domain controllers:\nAdministrators\nServer Operators\nLocal Service\n\n
1932 Create a pagefile\n\nThis user right determines which users and groups can call an internal application programming interface (API) to create a page file. This user right is used internally by the operating system and usually does not need to be assigned to any users.\n\nFor information about how to specify a paging file size for a given drive, see To change the size of the virtual memory paging file.\n\nDefault: Administrators.\n\n
1933 Create a token object\n\nThis security setting determines which accounts can be used by processes to create a token that can then be used to get access to any local resources when the process uses an internal application programming interface (API) to create an access token.\n\nThis user right is used internally by the operating system. Unless it is necessary, do not assign this user right to a user, group, or process other than Local System.\n\nCaution\n\nAssigning this user right can be a security risk. Do not assign this user right to any user, group, or process that you do not want to take over the system.\nDefault: None\n\n
1934 Create global objects\n\nThis user right is required for a user account to create global objects during Terminal Services sessions. Users can still create session-specific objects without being assigned this user right.\n\nCaution\n\nAssigning this user right can be a security risk. Assign this user right only to trusted users.\n\nDefault:\n\nAdministrators\nLocal Service\nNetwork Service\nService\n\n
1935 Create permanent shared objects\n\nThis user right determines which accounts can be used by processes to create a directory object using the object manager.\n\nThis user right is used internally by the operating system and is useful to kernel-mode components that extend the object namespace. Because components that are running in kernel mode already have this user right assigned to them, it is not necessary to specifically assign it.\n\nDefault: None.\n\n
1936 Debug programs\n\nThis user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications to not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.\n\nCaution\n\nAssigning this user right can be a security risk. Only assign this user right to trusted users.\n\nDefault: Administrators\n\n
1937 Deny access to this computer from the network\n\nThis security setting determines which users are prevented from accessing a computer over the network. This policy setting supersedes the Access this computer from the network policy setting if a user account is subject to both policies.\n\nDefault: None.\n\n
1938 Deny log on as a batch job\n\nThis security setting determines which accounts are prevented from being able to log on as a batch job. This policy setting supersedes the Log on as a batch job policy setting if a user account is subject to both policies.\n\nDefault: None.\n\n
1939 Deny log on as a service\n\nThis security setting determines which service accounts are prevented from registering a process as a service. This policy setting supersedes the Log on as a service policy setting if an account is subject to both policies.\n\nNote: This security setting does not apply to the System, Local Service, or Network Service accounts.\n\nDefault: None.\n\n
1940 Deny log on locally\n\nThis security setting determines which users are prevented from logging on at the computer. This policy setting supersedes the Allow log on locally policy setting if an account is subject to both policies.\n\nImportant\n\nIf you apply this security policy to the Everyone group, no one will be able to log on locally.\n\nDefault: None.\n\n
1941 Deny log on through Terminal Services\n\nThis security setting determines which users and groups are prohibited from logging on as a Terminal Services client.\n\nDefault: None.\n\nImportant\n\nThis setting does not have any effect on Windows 2000 computers that have not been updated to Service Pack 2.\n\n
1942 Enable computer and user accounts to be trusted for delegation\n\nThis security setting determines which users can set the Trusted for Delegation setting on a user or computer object.\n\nThe user or object that is granted this privilege must have write access to the account control flags on the user or computer object. A server process running on a computer (or under a user context) that is trusted for delegation can access resources on another computer using delegated credentials of a client, as long as the client account does not have the Account cannot be delegated account control flag set.\n\nThis user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.\n\nCaution\n\nMisuse of this user right, or of the Trusted for Delegation setting, could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.\n\nDefault: Administrators on domain controllers.\n\n
1943 Force shutdown from a remote system\n\nThis security setting determines which users are allowed to shut down a computer from a remote location on the network. Misuse of this user right can result in a denial of service.\n\nThis user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.\n\nDefault:\n\nOn workstations and servers: Administrators.\nOn domain controllers: Administrators, Server Operators.\n\n
1944 Generate security audits\n\nThis security setting determines which accounts can be used by a process to add entries to the security log. The security log is used to trace unauthorized system access. Misuse of this user right can result in the generation of many auditing events, potentially hiding evidence of an attack or causing a denial of service if the Audit: Shut down system immediately if unable to log security audits security policy setting is enabled. For more information see Audit: Shut down system immediately if unable to log security audits\n\nDefault: Local Service\nNetwork Service.\n\n
1945 Impersonate a client after authentication\n\nAssigning this privilege to a user allows programs running on behalf of that user to impersonate a client. Requiring this user right for this kind of impersonation prevents an unauthorized user from convincing a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created and then impersonating that client, which can elevate the unauthorized user's permissions to administrative or system levels.\n\nCaution\n\nAssigning this user right can be a security risk. Only assign this user right to trusted users.\n\nDefault:\n\nAdministrators\nLocal Service\nNetwork Service\nService\n\nNote: By default, services that are started by the Service Control Manager have the built-in Service group added to their access tokens. Component Object Model (COM) servers that are started by the COM infrastructure and that are configured to run under a specific account also have the Service group added to their access tokens. As a result, these services get this user right when they are started.\n\nIn addition, a user can also impersonate an access token if any of the following conditions exist.\n\nThe access token that is being impersonated is for this user.\nThe user, in this logon session, created the access token by logging on to the network with explicit credentials.\nThe requested level is less than Impersonate, such as Anonymous or Identify.\nBecause of these factors, users do not usually need this user right.\n\nFor more information, search for "SeImpersonatePrivilege" in the Microsoft Platform SDK.\n\nWarning\n\nIf you enable this setting, programs that previously had the Impersonate privilege may lose it, and they may not run.
1946 Increase scheduling priority\n\nThis security setting determines which accounts can use a process with Write Property access to another process to increase the execution priority assigned to the other process. A user with this privilege can change the scheduling priority of a process through the Task Manager user interface.\n\nDefault: Administrators.\n\n
1947 Load and unload device drivers\n\nThis user right determines which users can dynamically load and unload device drivers or other code in to kernel mode. This user right does not apply to Plug and Play device drivers. It is recommended that you do not assign this privilege to other users. \n\nCaution\n\nAssigning this user right can be a security risk. Do not assign this user right to any user, group, or process that you do not want to take over the system.\n\nDefault on workstations and servers: Administrators.\n\nDefault on domain controllers:\nAdministrators\nPrint Operators\n\n
1948 Lock pages in memory\n\nThis security setting determines which accounts can use a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk. Exercising this privilege could significantly affect system performance by decreasing the amount of available random access memory (RAM).\n\nDefault: None.\n\n
1949 Log on as a batch job\n\nThis security setting allows a user to be logged on by means of a batch-queue facility and is provided only for compatibility with older versions of Windows.\n\nFor example, when a user submits a job by means of the task scheduler, the task scheduler logs that user on as a batch user rather than as an interactive user.\n\n\nDefault: Administrators\nBackup Operators.\n\n
1950 Log on as a service\n\nThis security setting determines which service accounts can register a process as a service.\n\nDefault: Network Service.\n\n
1951 Manage auditing and security log\n\nThis security setting determines which users can specify object access auditing options for individual resources, such as files, Active Directory objects, and registry keys.\n\nThis security setting does not allow a user to enable file and object access auditing in general. For such auditing to be enabled, the Audit object access setting in Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policies must be configured.\n\nYou can view audited events in the security log of the Event Viewer. A user with this privilege can also view and clear the security log.\n\nDefault: Administrators.\n\n
1952 Modify firmware environment values\n\nThis security setting determines who can modify firmware environment values. Firmware environment variables are settings stored in the nonvolatile RAM of non-x86-based computers. The effect of the setting depends on the processor.\n\nOn x86-based computers, the only firmware environment value that can be modified by assigning this user right is the Last Known Good Configuration setting, which should only be modified by the system.\nOn Itanium-based computers, boot information is stored in nonvolatile RAM. Users must be assigned this user right to run bootcfg.exe and to change the Default Operating System setting on Startup and Recovery in System Properties.\nOn all computers, this user right is required to install or upgrade Windows.\n\nNote: This security setting does not affect who can modify the system environment variables and user environment variables that are displayed on the Advanced tab of System Properties. For information about how to modify these variables, see To add or change the values of environment variables.\n\nDefault: Administrators.\n\n
1953 Perform volume maintenance tasks\n\nDescription\n\nThis security setting determines which users and groups can run maintenance tasks on a volume, such as remote defragmentation.\n\nUse caution when assigning this user right. Users with this user right can explore disks and extend files in to memory that contains other data. When the extended files are opened, the user might be able to read and modify the acquired data.\n\nDefault: Administrators\n\n
1954 Profile single process\n\nThis security setting determines which users can use performance monitoring tools to monitor the performance of nonsystem processes.\n\nDefault: Administrators.\n\n
1955 Profile system performance\n\nThis security setting determines which users can use performance monitoring tools to monitor the performance of system processes.\n\nDefault: Administrators.\n\n
1956 Remove computer from docking station\n\nThis security setting determines whether a user can undock a portable computer from its docking station without logging on.\n\nIf this policy is enabled, the user must log on before removing the portable computer from its docking station. If this policy is disabled, the user may remove the portable computer from its docking station without logging on.\n\nDefault: Administrators.\n\n
1957 Replace a process level token\n\nThis security setting determines which user accounts can call the CreateProcessAsUser() application programming interface (API) so that one service can start another. An example of a process that uses this user right is Task Scheduler. For information about Task Scheduler, see Task Scheduler overview.\n\nDefault: Network Service, Local Service.\n\n
1958 Restore files and directories\n\nThis security setting determines which users can bypass file, directory, registry, and other persistent objects permissions when restoring backed up files and directories, and determines which users can set any valid security principal as the owner of an object.\n\nSpecifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system:\n\nTraverse Folder/Execute File\nWrite\n\nCaution\n\nAssigning this user right can be a security risk. Since users with this user right can overwrite registry settings, hide data, and gain ownership of system objects, only assign this user right to trusted users.\n\nDefault:\n\nWorkstations and servers: Administrators, Backup Operators.\nDomain controllers: Administrators, Backup Operators, Server Operators.\n\n
1959 Shut down the system\n\nThis security setting determines which users who are logged on locally to the computer can shut down the operating system using the Shut Down command. Misuse of this user right can result in a denial of service.\n\nDefault on Workstations: Administrators, Backup Operators, Users.\n\nDefault on Servers: Administrators, Backup Operators.\n\nDefault on Domain controllers: Administrators, Backup Operators, Server Operators, Print Operators.\n\n
1960 Synchronize directory service data\n\nThis security setting determines which users and groups have the authority to synchronize all directory service data. This is also known as Active Directory synchronization.\n\nDefaults: None.\n\n
1961 Take ownership of files or other objects\n\nThis security setting determines which users can take ownership of any securable object in the system, including Active Directory objects, files and folders, printers, registry keys, processes, and threads.\n\nCaution\n\nAssigning this user right can be a security risk. Since owners of objects have full control of them, only assign this user right to trusted users.\n\nDefault: Administrators.\n\n
1962 Accounts: Administrator account status\n\nThis security setting determines whether the local Administrator account is enabled or disabled.\n\nNotes\n\nIf you try to reenable the Administrator account after it has been disabled, and if the current Administrator password does not meet the password requirements, you cannot reenable the account. In this case, an alternative member of the Administrators group must reset the password on the Administrator account. For information about how to reset a password, see To reset a password.\nDisabling the Administrator account can become a maintenance issue under certain circumstances. For example, in a domain environment, if the secure channel that constitutes your join fails for any reason, and there is no other local Administrator account, you must restart in Safe Mode to fix the problem that is causing your join status to be broken.\nUnder Safe Mode boot, the Administrator account is always enabled, regardless of this setting.\n\nDefault: Enabled.\n\n
1963 Accounts: Guest account status\n\nThis security setting determines if the Guest account is enabled or disabled.\n\nDefault: Disabled.\n\nNote: If the Guest account is disabled and the security option Network Access: Sharing and Security Model for local accounts is set to Guest Only, network logons, such as those performed by the Microsoft Network Server (SMB Service), will fail.\n\n
1964 Accounts: Limit local account use of blank passwords to console logon only\n\nThis security setting determines whether local accounts that are not password protected can be used to logon from locations other than the physical computer console. If enabled, then local accounts that are not password protected will only be able to log on at the computer's keyboard.\n\nDefault: Enabled.\n\n\nWarning:\n\nComputers that are not in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the computer can log on using a user account that does not have a password. This is especially important for portable computers.\nIf you apply this security policy to the Everyone group, no one will be able to log on through terminal services.\n\nNotes\n\nThis setting does not affect logons that use domain accounts.\nIt is possible for applications that use remote interactive logons to bypass this setting.\n\n
1965 Accounts: Rename administrator account\n\nThis security setting determines whether a different account name is associated with the security identifier (SID) for the account Administrator. Renaming the well-known Administrator account makes it slightly more difficult for unauthorized persons to guess this privileged user name and password combination.\n\nDefault: Administrator.\n\n
1966 Accounts: Rename guest account\n\nThis security setting determines whether a different account name is associated with the security identifier (SID) for the account "Guest." Renaming the well-known Guest account makes it slightly more difficult for unauthorized persons to guess this user name and password combination.\n\nDefault: Guest.\n\n
1967 Audit: Audit the access of global system objects\n\nThis security setting determines whether to audit the access of global system objects.\n\nIf this policy is enabled, it causes system objects, such as mutexes (mutual exclusive), events, semaphores (locking mechanisms used inside resource managers or resource dispensers) and DOS devices, to be created with a default system access control list (SACL). If the Audit object access audit policy is also enabled, access to these system objects is audited.\n\nNote: When configuring this security setting, changes will not take effect until you restart Windows.\n\nDefault: Disabled.\n\n
1968 Audit: Audit the use of Backup and Restore privilege\n\nThis security setting determines whether to audit the use of all user privileges, including Backup and Restore, when the Audit privilege use policy is in effect. Enabling this option when the Audit privilege use policy is also enabled generates an audit event for every file that is backed up or restored.\n\nIf you disable this policy, then use of the Backup or Restore privilege is not audited even when Audit privilege use is enabled.\n\nNote: When configuring this security setting, changes will not take effect until you restart Windows.\n\nDefault: Disabled.\n\n
1969 Audit: Shut down system immediately if unable to log security audits\n\nThis security setting determines whether the system shuts down if it is unable to log security events.\n\nIf this security setting is enabled, it causes the system to stop if a security audit cannot be logged for any reason. Typically, an event fails to be logged when the security audit log is full and the retention method that is specified for the security log is either Do Not Overwrite Events or Overwrite Events by Days.\n\nIf the security log is full and an existing entry cannot be overwritten, and this security option is enabled, the following Stop error appears:\n\nSTOP: C0000244 {Audit Failed}\nAn attempt to generate a security audit failed.\nTo recover, an administrator must log on, archive the log (optional), clear the log, and reset this option as desired. Until this security setting is reset, no users, other than a member of the Administrators group will be able to log on to the system, even if the security log is not full.\n\nNote: When configuring this security setting, changes will not take effect until you restart Windows.\n\nDefault: Disabled.\n\n
1970 Devices: Allow undock without having to log on\n\nThis security setting determines whether a portable computer can be undocked without having to log on. If this policy is enabled, logon is not required and an external hardware eject button can be used to undock the computer. If disabled, a user must log on and have the Remove computer from docking station privilege to undock the computer.\n\nDefault: Enabled.\n\nCaution\n\nDisabling this policy may tempt users to try and physically remove the laptop from its docking station using methods other than the external hardware eject button. Since this may cause damage to the hardware, this setting, in general, should only be disabled on laptop configurations that are physically securable.\n\n
1971 Devices: Allowed to format and eject removable media\n\nThis security setting determines who is allowed to format and eject removable NTFS media. This capability can be given to:\n\nAdministrators\nAdministrators and Interactive Users\n\nDefault: This policy is not defined and only Administrators have this ability.\n\n
1972 Devices: Prevent users from installing printer drivers\n\nFor a computer to print to a network printer, the driver for that network printer must be installed on the local computer. This security setting determines who is allowed to install a printer driver as part of adding a network printer. If this setting is enabled, only Administrators can install a printer driver as part of adding a network printer. If this setting is disabled, any user can install a printer driver as part of adding a network printer.\n\nDefault on servers: Enabled.\nDefault on workstations: Disabled\n\n\nNotes\n\nThis setting does not affect the ability to add a local printer.\nThis setting does not affect Administrators.\n\n
1973 Devices: Restrict CD-ROM access to locally logged-on user only\n\nThis security setting determines whether a CD-ROM is accessible to both local and remote users simultaneously.\n\nIf this policy is enabled, it allows only the interactively logged-on user to access removable CD-ROM media. If this policy is enabled and no one is logged on interactively, the CD-ROM can be accessed over the network.\n\nDefault: This policy is not defined and CD-ROM access is not restricted to the locally logged-on user.\n\n
1974 Devices: Restrict floppy access to locally logged-on user only\n\nThis security setting determines whether removable floppy media are accessible to both local and remote users simultaneously.\n\nIf this policy is enabled, it allows only the interactively logged-on user to access removable floppy media. If this policy is enabled and no one is logged on interactively, the floppy can be accessed over the network.\n\nDefault: This policy is not defined and floppy disk drive access is not restricted to the locally logged-on user.\n\n
1975 Devices: Unsigned driver installation behavior\n\nThis security setting determines what happens when an attempt is made to install a device driver (by means of Setup API) that has not been tested by the Windows Hardware Quality Lab (WHQL).\n\nThe options are:\n\nSilently succeed\nWarn but allow installation\nDo not allow installation\nDefault: Warn but allow installation.\n\n
1976 Domain controller: Allow server operators to schedule tasks\n\nThis security setting determines if Server Operators are allowed to submit jobs by means of the AT schedule facility.\n\nNote: This security setting only affects the AT schedule facility; it does not affect the Task Scheduler facility.\nDefault: This policy is not defined, which means that the system treats it as disabled.\n\n
1977 Domain controller: LDAP server signing requirements\n\nThis security setting determines whether the LDAP server requires signing to be negotiated with LDAP clients, as follows:\n\nNone: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it.\nRequire signature: Unless TLS\SSL is being used, the LDAP data signing option must be negotiated.\n\nDefault: This policy is not defined, which has the same effect as None.\n\nCaution\n\nIf you set the server to Require Signature, you must also set the client. Not setting the client results in loss of connection with the server.\n\nNotes\n\nThis setting does not have any impact on LDAP simple bind or LDAP simple bind through SSL. No Microsoft LDAP clients that are shipped with Windows XP Professional use LDAP simple bind or LDAP simple bind through SSL to talk to a domain controller.\nIf signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected. No Microsoft LDAP clients running Windows XP Professional or the Windows Server 2003 family use LDAP simple bind or LDAP simple bind through SSL to bind to directory service.\n\n
1978 Domain controller: Refuse machine account password changes\n\nThis security setting determines whether domain controllers will refuse requests from member computers to change computer account passwords. By default, member computers change their computer account passwords every 30 days. If enabled, the domain controller will refuse computer account password change requests.\n\nIf it is enabled, this setting does not allow a domain controller to accept any changes to a computer account's password.\n\nDefault: This policy is not defined, which means that the system treats it as Disabled.\n\n
1979 Domain member: Digitally encrypt or sign secure channel data (always)\n\nThis security setting determines whether all secure channel traffic initiated by the domain member must be signed or encrypted.\n\nWhen a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID/name Lookup etc.\n\nThis setting determines whether or not all secure channel traffic initiated by the domain member meets minimum security requirements. Specifically it determines whether all secure channel traffic initiated by the domain member must be signed or encrypted. If this policy is enabled, then the secure channel will not be established unless either signing or encryption of all secure channel traffic is negotiated. If this policy is disabled, then encryption and signing of all secure channel traffic is negotiated with the Domain Controller in which case the level of signing and encryption depends on the version of the Domain Controller and the settings of the following two policies:\n\nDomain member: Digitally encrypt secure channel data (when possible)\nDomain member: Digitally sign secure channel data (when possible)\n\nDefault: Enabled.\n\nNotes:\n\nIf this policy is enabled, the policy Domain member: Digitally sign secure channel data (when possible) is assumed to be enabled regardless of its current setting. This ensures that the domain member attempts to negotiate at least signing of the secure channel traffic.\nIf this policy is enabled, the policy Domain member: Digitally sign secure channel data (when possible) is assumed to be enabled regardless of its current setting. This ensures that the domain member attempts to negotiate at least signing of the secure channel traffic.\nLogon information transmitted over the secure channel is always encrypted regardless of whether encryption of ALL other secure channel traffic is negotiated or not.\n\n
1980 Domain member: Digitally encrypt secure channel data (when possible)\n\nThis security setting determines whether a domain member attempts to negotiate encryption for all secure channel traffic that it initiates.\n\nWhen a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM passthrough authentication, LSA SID/name Lookup etc.\n\nThis setting determines whether or not the domain member attempts to negotiate encryption for all secure channel traffic that it initiates. If enabled, the domain member will request encryption of all secure channel traffic. If the domain controller supports encryption of all secure channel traffic, then all secure channel traffic will be encrypted. Otherwise only logon information transmitted over the secure channel will be encrypted. If this setting is disabled, then the domain member will not attempt to negotiate secure channel encryption.\n\nDefault: Enabled.\n\nImportant\n\nThere is no known reason for disabling this setting. Besides unnecessarily reducing the potential confidentiality level of the secure channel, disabling this setting may unnecessarily reduce secure channel throughput, because concurrent API calls that use the secure channel are only possible when the secure channel is signed or encrypted.\n\nNote: Domain controllers are also domain members and establish secure channels with other domain controllers in the same domain as well as domain controllers in trusted domains.\n\n
1981 Domain member: Digitally sign secure channel data (when possible)\n\nThis security setting determines whether a domain member attempts to negotiate signing for all secure channel traffic that it initiates.\n\nWhen a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID/name Lookup etc.\n\nThis setting determines whether or not the domain member attempts to negotiate signing for all secure channel traffic that it initiates. If enabled, the domain member will request signing of all secure channel traffic. If the Domain Controller supports signing of all secure channel traffic, then all secure channel traffic will be signed which ensures that it cannot be tampered with in transit.\n\nDefault: Enabled.\n\nNotes:\n\nIf the policy Domain member: Digitally encrypt or sign secure channel data (always) is enabled, then this policy is assumed to be enabled regardless of its current setting.\nDomain controllers are also domain members and establish secure channels with other domain controllers in the same domain as well as domain controllers in trusted domains.\n\n
1982 Domain member: Maximum machine account password age\n\nThis security setting determines how often a domain member will attempt to change its computer account password.\n\nDefault: 30 days.\n\nImportant\n\nThis setting applies to Windows 2000 computers, but it is not available through the Security Configuration Manager tools on these computers.\n\n
1983 Domain member: Require strong (Windows 2000 or later) session key\n\nThis security setting determines whether 128-bit key strength is required for encrypted secure channel data.\n\nWhen a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller within the domain. This secure channel is used to perform operations such as NTLM passthrough authentication, LSA SID/name Lookup, and so on.\n\nDepending on what version of Windows is running on the domain controller that the domain member is communicating with and the settings of the parameters:\n\nDomain member: Digitally encrypt or sign secure channel data (always)\nDomain member: Digitally encrypt secure channel data (when possible)\nSome or all of the information that is transmitted over the secure channel will be encrypted. This policy setting determines whether or not 128-bit key strength is required for the secure channel information that is encrypted.\n\nIf this setting is enabled, then the secure channel will not be established unless 128-bit encryption can be performed. If this setting is disabled, then the key strength is negotiated with the domain controller.\n\nDefault: Disabled.\n\nImportant\n\nIn order to take advantage of this policy on member workstations and servers, all domain controllers that constitute the member's domain must be running Windows 2000 or later.\nIn order to take advantage of this policy on domain controllers, all domain controllers in the same domain as well as all trusted domains must run Windows 2000 or later.\n\n
1984 Domain member: Disable machine account password changes\n\nDetermines whether a domain member periodically changes its computer account password. If this setting is enabled, the domain member does not attempt to change its computer account password. If this setting is disabled, the domain member attempts to change its computer account password as specified by the setting for Domain Member: Maximum age for machine account password, which by default is every 30 days.\n\nDefault: Disabled.\n\nNotes\n\nThis security setting should not be enabled. Computer account passwords are used to establish secure channel communications between members and domain controllers and, within the domain, between the domain controllers themselves. Once it is established, the secure channel is used to transmit sensitive information that is necessary for making authentication and authorization decisions.\nThis setting should not be used in an attempt to support dual-boot scenarios that use the same computer account. If you want to dual-boot two installations that are joined to the same domain, give the two installations different computer names.\n\n
1985 Interactive logon: Do not display last user name\n\nThis security setting determines whether the name of the last user to log on to the computer is displayed in the Windows logon screen.\n\nIf this policy is enabled, the name of the last user to successfully log on is not displayed in the Log On to Windows dialog box.\n\nIf this policy is disabled, the name of the last user to log on is displayed.\n\nDefault: Disabled.\n\n
1986 Interactive logon: Do not require CTRL+ALT+DEL\n\nThis security setting determines whether pressing CTRL+ALT+DEL is required before a user can log on.\n\nIf this policy is enabled on a computer, a user is not required to press CTRL+ALT+DEL to log on. Not having to press CTRL+ALT+DEL leaves users susceptible to attacks that attempt to intercept the users' passwords. Requiring CTRL+ALT+DEL before users log on ensures that users are communicating by means of a trusted path when entering their passwords.\n\nIf this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to Windows (unless they are using a smart card for Windows logon).\n\nDefault on domain-computers: Disabled.\nDefault on stand-alone computers: Enabled.\n\n
1987 Interactive logon: Message text for users attempting to log on\n\nThis security setting specifies a text message that is displayed to users when they log on.\n\nThis text is often used for legal reasons, for example, to warn users about the ramifications of misusing company information or to warn them that their actions may be audited.\n\nDefault: No message.\n\n
1988 Interactive logon: Message title for users attempting to log on\n\nThis security setting allows the specification of a title to appear in the title bar of the window that contains the Interactive logon: Message text for users attempting to log on.\n\nDefault: No message.\n\n
1989 Interactive logon: Number of previous logons to cache (in case domain controller is not available)\n\nAll previous users' logon information is cached locally so that, in the event that a domain controller is unavailable during subsequent logon attempts, they are able to log on . If a domain controller is unavailable and a user's logon information is cached, the user is prompted with a message that reads as follows:\n\nWindows cannot connect to a server to confirm your logon settings. You have been logged on using previously stored account information. If you changed your account information since you last logged on to this computer, those changes will not be reflected in this session.\n\nIf a domain controller is unavailable and a user's logon information is not cached, the user is prompted with this message:\n\nThe system cannot log you on now because the domain <DOMAIN_NAME> is not available.\n\nIn this policy setting, a value of 0 disables logon caching. Any value above 50 only caches 50 logon attempts.\n\nDefault: 10\n\n
1990 Interactive logon: Prompt user to change password before expiration\n\nDetermines how far in advance (in days) users are warned that their password is about to expire. With this advance warning, the user has time to construct a password that is sufficiently strong.\n\nDefault: 14 days.\n\n
1991 Interactive logon: Require Domain Controller authentication to unlock\n\nLogon information must be provided to unlock a locked computer. For domain accounts, this security setting determines whether a domain controller must be contacted to unlock a computer. If this setting is disabled, a user can unlock the computer using cached credentials. If this setting is enabled, a domain controller must authenticate the domain account that is being used to unlock the computer.\n\nDefault: Disabled.\n\nImportant\n\nThis setting applies to Windows 2000 computers, but it is not available through the Security Configuration Manager tools on these computers.\n\n
1992 Interactive logon: Require smart card\n\nThis security setting requires users to log on to a computer using a smart card.\n\nThe options are:\n\nEnabled: Users can only log on to the computer using a smart card.\nDisabled. Users can log on to the computer using any method.\nDefault: Disabled.\n\nImportant\n\nThis setting will apply to any computers running Windows 2000 through changes in the registry, but the security setting is not viewable through the Security Configuration Manager tool set.\n\n
1993 Interactive logon: Smart card removal behavior\n\nThis security setting determines what happens when the smart card for a logged-on user is removed from the smart card reader.\n\nThe options are:\n\n" No Action\n" Lock Workstation\n" Force Logoff\n" Disconnect if a remote Terminal Services session \n\nIf you click Lock Workstation in the Properties dialog box for this policy, the workstation is locked when the smart card is removed, allowing users to leave the area, take their smart card with them, and still maintain a protected session.\n\nIf you click Force Logoff in the Properties dialog box for this policy, the user is automatically logged off when the smart card is removed.\n\nIf you click Disconnect if a remote Terminal Services session, removal of the smart card disconnects the session without logging the user off. This allows the user to insert the smart card and resume the session later, or at another smart card reader-equipped terminal, without having to log on again.\n\nDefault: This policy is not defined, which means that the system treats it as No action.\n\nOn Windows Vista and above: In order for this setting to work, the Smart Card Removal Policy service must be started.\n\n
1994 Microsoft network client: Digitally sign communications (always)\n\nThis security setting determines whether packet signing is required by the SMB client component.\n\nThe server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB server is permitted.\n\nIf this setting is enabled, the Microsoft network client will not communicate with a Microsoft network server unless that server agrees to perform SMB packet signing. If this policy is disabled, SMB packet signing is negotiated between the client and server.\n\nDefault: Disabled.\n\nImportant\n\nFor this policy to take effect on computers running Windows 2000, client-side packet signing must also be enabled. To enable client-side SMB packet signing, set Microsoft network client: Digitally sign communications (if server agrees).\nComputers that have this policy set will not be able to communicate with computers that do not have server-side packet signing enabled. By default, server-side packet signing is enabled only on domain controllers running Windows 2000 and later.\nServer-side packet signing can be enabled on computers running Windows 2000 and later by setting Microsoft network server: Digitally sign communications (if client agrees)\nServer-side packet signing can be enabled on computers running Windows NT 4.0 Service Pack 3 and later by setting the following registry value to 1:\nHKLM\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature\n\nServer-side packet signing cannot be enabled on computers running Windows 95 or Windows 98.\n\nNotes\n\nAll Windows operating systems support both a client-side SMB component and a server-side SMB component. To take advantage of SMB packet signing, both the client-side SMB component and server-side SMB component that are involved in a communication must have SMB packet signing either enabled or required. On Windows 2000 and later operating systems, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:\nMicrosoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing.\nMicrosoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled.\nMicrosoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing.\nMicrosoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled.\nIf server-side SMB signing is required, a client will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.\nIf server-side SMB signing is enabled, SMB packet signing will be negotiated with clients that have client-side SMB signing enabled.\nUsing SMB packet signing can impose up to a 15 percent performance hit on file service transactions.\n\n
1995 Microsoft network client: Digitally sign communications (if server agrees)\n\nThis security setting determines whether the SMB client attempts to negotiate SMB packet signing.\n\nThe server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether the SMB client component attempts to negotiate SMB packet signing when it connects to an SMB server.\n\nIf this setting is enabled, the Microsoft network client will ask the server to perform SMB packet signing upon session setup. If packet signing has been enabled on the server, packet signing will be negotiated. If this policy is disabled, the SMB client will never negotiate SMB packet signing.\n\nDefault: Enabled.\n\nNotes\n\nAll Windows operating systems support both a client-side SMB component and a server-side SMB component. To take advantage of SMB packet signing, both the client-side SMB component and server-side SMB component that are involved in a communication must have SMB packet signing either enabled or required. On Windows 2000 and later, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:\nMicrosoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing.\nMicrosoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled.\nMicrosoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing.\nMicrosoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled.\nIf server-side SMB signing is required, a client will not be able to establish a session with that server unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers.\nSimilarly, if client-side SMB signing is required, that client will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.\nIf server-side SMB signing is enabled, SMB packet signing will be negotiated with clients that have client-side SMB signing enabled.\nUsing SMB packet signing can degrade performance up to 15 percent on file service transactions.\n\n
1996 Microsoft network client: Send unencrypted password to connect to third-party SMB servers\n\nIf this security setting is enabled, the Server Message Block (SMB) redirector is allowed to send plaintext passwords to non-Microsoft SMB servers that do not support password encryption during authentication.\n\nSending unencrypted passwords is a security risk.\n\nDefault: Disabled.\n\n
1997 Microsoft network server: Amount of idle time required before suspending a session\n\nThis security setting determines the amount of continuous idle time that must pass in a Server Message Block (SMB) session before the session is suspended due to inactivity.\n\nAdministrators can use this policy to control when a computer suspends an inactive SMB session. If client activity resumes, the session is automatically reestablished.\n\nFor this policy setting, a value of 0 means to disconnect an idle session as quickly as is reasonably possible. The maximum value is 99999, which is 208 days; in effect, this value disables the policy.\n\nDefault:This policy is not defined, which means that the system treats it as 15 minutes for servers and undefined for workstations.\n\n
1998 Microsoft network server: Digitally sign communications (always)\n\nThis security setting determines whether packet signing is required by the SMB server component.\n\nThe server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent "man-in-the-middle" attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB client is permitted.\n\nIf this setting is enabled, the Microsoft network server will not communicate with a Microsoft network client unless that client agrees to perform SMB packet signing. If this setting is disabled, SMB packet signing is negotiated between the client and server.\n\nDefault:\n\nDisabled for member servers.\nEnabled for domain controllers.\n\nNotes\n\nAll Windows operating systems support both a client-side SMB component and a server-side SMB component. To take advantage of SMB packet signing, both the client-side SMB component and server-side SMB component that are involved in a communication must have SMB packet signing either enabled or required. On Windows 2000 and later, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:\nMicrosoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing.\nMicrosoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled.\nMicrosoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing.\nMicrosoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled.\nIf server-side SMB signing is required, a client will not be able to establish a session with that server unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers.\nSimilarly, if client-side SMB signing is required, that client will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.\nIf server-side SMB signing is enabled, SMB packet signing will be negotiated with clients that have client-side SMB signing enabled.\nUsing SMB packet signing can degrade performance up to 15 percent on file service transactions.\n\nImportant\n\nFor this policy to take effect on computers running Windows 2000, server-side packet signing must also be enabled. To enable server-side SMB packet signing, set the following policy:\nMicrosoft network server: Digitally sign communications (if server agrees)\n\nFor Windows 2000 servers to negotiate signing with Windows NT 4.0 clients, the following registry value must be set to 1 on the Windows 2000 server:\nHKLM\System\CurrentControlSet\Services\lanmanserver\parameters\enableW9xsecuritysignature\n\nComputers that have this policy set will not communicate with computers that do not have client-side packet signing enabled. Client-side packet signing can be enabled on computers running Windows 2000 and later by setting the following policy:\n\n
1999 Microsoft network server: Digitally sign communications (if client agrees)\n\nThis security setting determines whether the SMB server will negotiate SMB packet signing with clients that request it.\n\nThe server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether the SMB server will negotiate SMB packet signing when an SMB client requests it.\n\nIf this setting is enabled, the Microsoft network server will negotiate SMB packet signing as requested by the client. That is, if packet signing has been enabled on the client, packet signing will be negotiated. If this policy is disabled, the SMB client will never negotiate SMB packet signing.\n\nDefault: Enabled on domain controllers only.\n\nImportant\n\nTor Windows 2000 servers to negotiate signing with Windows NT 4.0 clients, the following registry value must be set to 1 on the server running Windows 2000: HKLM\System\CurrentControlSet\Services\lanmanserver\parameters\enableW9xsecuritysignature\n\nNotes\n\nAll Windows operating systems support both a client-side SMB component and a server-side SMB component. To take advantage of SMB packet signing, both the client-side SMB component and server-side SMB component that are involved in a communication must have SMB packet signing either enabled or required. For Windows 2000 and above, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:\nMicrosoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing.\nMicrosoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled.\nMicrosoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing.\nMicrosoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled.\nIf server-side SMB signing is required, a client will not be able to establish a session with that server unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers.\nSimilarly, if client-side SMB signing is required, that client will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.\nIf server-side SMB signing is enabled, SMB packet signing will be negotiated with clients that have client-side SMB signing enabled.\nUsing SMB packet signing can impose up to a 15 percent performance hit on file service transactions.\n\n
2000 Microsoft network server: Disconnect clients when logon hours expire\n\nThis security setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component.\n\nWhen this policy is enabled, it causes client sessions with the SMB Service to be forcibly disconnected when the client's logon hours expire.\n\nIf this policy is disabled, an established client session is allowed to be maintained after the client's logon hours have expired.\n\nDefault on Windows Vista: Enabled.\nDefault on Windows XP: Disabled\n\n
2001 Network access: Allow anonymous SID/name translation\n\nThis security setting determines if an anonymous user can request security identifier (SID) attributes for another user.\n\nIf this policy is enabled, a user with knowledge of an administrator's SID could contact a computer that has this policy enabled and use the SID to get the administrator's name.\n\nDefault on workstations and member servers: Disabled.\nDefault on domain controllers: Enabled.\n\n
2002 Network access: Do not allow anonymous enumeration of SAM accounts\n\nThis security setting determines what additional permissions will be granted for anonymous connections to the computer.\n\nWindows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust.\n\nThis security option allows additional restrictions to be placed on anonymous connections as follows:\n\nEnabled: Do not allow enumeration of SAM accounts. This option replaces Everyone with Authenticated Users in the security permissions for resources.\nDisabled: No additional restrictions. Rely on default permissions.\n\nDefault on workstations: Enabled.\nDefault on server:Disabled.\n\nImportant\n\nThis policy has no impact on domain controllers.\n\n
2003 Network access: Do not allow anonymous enumeration of SAM accounts and shares\n\nThis security setting determines whether anonymous enumeration of SAM accounts and shares is allowed.\n\nWindows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. If you do not want to allow anonymous enumeration of SAM accounts and shares, then enable this policy.\n\nDefault: Disabled.\n\n
2004 Network access: Do not allow storage of credentials or .NET Passports for network authentication\n\nThis security setting determines whether Stored User Names and Passwords saves passwords, credentials, or .NET Passports for later use when it gains domain authentication.\n\nIf it is enabled, this setting prevents the Stored User Names and Passwords from storing passwords and credentials.\n\nNote: When configuring this security setting, changes will not take effect until you restart Windows.\nFor more information about Stored User Names and Passwords, see Stored User Names and Passwords.\n\nDefault: Disabled.\n\n
2005 Network access: Let Everyone permissions apply to anonymous users\n\nThis security setting determines what additional permissions are granted for anonymous connections to the computer.\n\nWindows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. By Default, the Everyone security identifier (SID) is removed from the token created for anonymous connections. Therefore, permissions granted to the Everyone group do not apply to anonymous users. If this option is set, anonymous users can only access those resources for which the anonymous user has been explicitly given permission.\n\nIf this policy is enabled, the Everyone SID is added to the token that is created for anonymous connections. In this case, anonymous users are able to access any resource for which the Everyone group has been given permissions.\n\nDefault: Disabled.\n\n
2006 Network access: Named pipes that can be accessed anonymously\n\nThis security setting determines which communication sessions (pipes) will have attributes and permissions that allow anonymous access.\n\nDefault: None.\n\n
2007 Network access: Remotely accessible registry paths\n\nThis security setting determines which registry paths can be accessed over the network, regardless of the users or groups listed in the access control list (ACL) of the winreg registry key.\n\nDefault:\n\nSystem\CurrentControlSet\Control\ProductOptions\nSystem\CurrentControlSet\Control\Server Applications\nSoftware\Microsoft\Windows NT\CurrentVersion\n\nCaution\n\nIncorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.\n Note: This security setting is not available on earlier versions of Windows. The security setting that appears on computers running Windows XP, "Network access: Remotely accessible registry paths" corresponds to the "Network access: Remotely accessible registry paths and subpaths" security option on members of the Windows Server 2003 family. For more information, see Network access: Remotely accessible registry paths and subpaths.\nDefault:\n\nSystem\CurrentControlSet\Control\ProductOptions\nSystem\CurrentControlSet\Control\Server Applications\nSoftware\Microsoft\Windows NT\CurrentVersion\n\n
2008 Network access: Remotely accessible registry paths and subpaths\n\nThis security setting determines which registry paths and subpaths can be accessed over the network, regardless of the users or groups listed in the access control list (ACL) of the winreg registry key.\n\nDefault:\n\nSystem\CurrentControlSet\Control\Print\Printers\nSystem\CurrentControlSet\Services\Eventlog\nSoftware\Microsoft\OLAP Server\nSoftware\Microsoft\Windows NT\CurrentVersion\Print\nSoftware\Microsoft\Windows NT\CurrentVersion\Windows\nSystem\CurrentControlSet\Control\ContentIndex\nSystem\CurrentControlSet\Control\Terminal Server\nSystem\CurrentControlSet\Control\Terminal Server\UserConfig\nSystem\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration\nSoftware\Microsoft\Windows NT\CurrentVersion\Perflib\nSystem\CurrentControlSet\Services\SysmonLog\nSystem\CurrentControlSet\Services\CertSvc\nSystem\CurrentControlSet\Services\Wins\n\nCaution\n\nIncorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.\n\nNote: On Windows XP, this security setting was called "Network access: Remotely accessible registry paths." If you configure this setting on a member of the Windows Server 2003 family that is joined to a domain, this setting is inherited by computers running Windows XP, but will appear as the "Network access: Remotely accessible registry paths" security option. For more information, see Network access: Remotely accessible registry paths and subpaths.\n
2009 Network access: Restrict anonymous access to Named Pipes and Shares\n\nWhen enabled, this security setting restricts anonymous access to shares and pipes to the settings for:\n\nNetwork access: Named pipes that can be accessed anonymously\nNetwork access: Shares that can be accessed anonymously\nDefault: Enabled.\n\n
2010 Network access: Shares that can be accessed anonymously\n\nThis security setting determines which network shares can accessed by anonymous users.\n\nDefault: None specified.\n\n
2011 Network access: Sharing and security model for local accounts\n\nThis security setting determines how network logons using local accounts are authenticated. If this setting is set to Classic, network logons that use local account credentials authenticate by using those credentials. The Classic model allows fine control over access to resources. By using the Classic model, you can grant different types of access to different users for the same resource.\nIf this setting is set to Guest only, network logons that use local accounts are automatically mapped to the Guest account. By using the Guest model, you can have all users treated equally. All users authenticate as Guest, and they all receive the same level of access to a given resource, which can be either Read-only or Modify.\n\nDefault on domain omputers: Classic.\nDefault on stand-alone computers: Guest only\n\nImportant\n\nWith the Guest only model, any user who can access your computer over the network (including anonymous Internet users) can access your shared resources. You must use the Windows Firewall or other similar device to protect your computer from unauthorized access. Similarly, with the Classic model, local accounts must be password protected; otherwise, those user accounts can be used by anyone to access shared system resources.\n\nNote:\n\nThis setting does not affect interactive logons that are performed remotely by using such services as Telnet or Terminal Services\nThis policy will have no impact on computers running Windows 2000.\nWhen the computer is not joined to a domain, this setting also modifies the Sharing and Security tabs in the Windows Explorer to correspond to the sharing and security model that is being used.\n\n
2012 Network security: Do not store LAN Manager hash value on next password change\n\nThis security setting determines if, at the next password change, the LAN Manager (LM) hash value for the new password is stored. The LM hash is relatively weak and prone to attack, as compared with the cryptographically stronger Windows NT hash. Since the LM hash is stored on the local computer in the security database the passwords can be compromised if the security database is attacked.\n\n\nDefault on Windows Vista: Enabled\nDefault on Windows XP: Disabled.\n\nImportant\n\nWindows 2000 Service Pack 2 (SP2) and above offer compatibility with authentication to previous versions of Windows, such as Microsoft Windows NT 4.0.\nThis setting can affect the ability of computers running Windows 2000 Server, Windows 2000 Professional, Windows XP, and the Windows Server 2003 family to communicate with computers running Windows 95 and Windows 98.\n\n
2013 Network security: Force logoff when logon hours expire\n\nThis security setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component.\n\nWhen this policy is enabled, it causes client sessions with the SMB server to be forcibly disconnected when the client's logon hours expire.\n\nIf this policy is disabled, an established client session is allowed to be maintained after the client's logon hours have expired.\n\nDefault: Enabled.\n\nNote: This security setting behaves as an account policy. For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, and it is enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from the Default Domain Policy Group Policy object (GPO), even if there is a different account policy applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (for example, member computers) also receive the same account policy for their local accounts. However, local account policies for member computers can be different from the domain account policy by defining an account policy for the organizational unit that contains the member computers. Kerberos settings are not applied to member computers.\n\n
2014 Network security: LAN Manager authentication level\n\nThis security setting determines which challenge/response authentication protocol is used for network logons. This choice affects the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers as follows:\n\nSend LM & NTLM responses: Clients use LM and NTLM authentication and never use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2 authentication.\nSend LM & NTLM - use NTLMv2 session security if negotiated: Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.\nSend NTLM response only: Clients use NTLM authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.\nSend NTLMv2 response only: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.\nSend NTLMv2 response only\refuse LM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM (accept only NTLM and NTLMv2 authentication).\nSend NTLMv2 response only\refuse LM & NTLM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM and NTLM (accept only NTLMv2 authentication).\n\nImportant\n\nThis setting can affect the ability of computers running Windows 2000 Server, Windows 2000 Professional, Windows XP Professional, and the Windows Server 2003 family to communicate with computers running Windows NT 4.0 and earlier over the network. For example, at the time of this writing, computers running Windows NT 4.0 SP4 and earlier did not support NTLMv2. Computers running Windows 95 and Windows 98 did not support NTLM.\n\nDefault:\n\nSend LM & NTLM responses on server.\nUndefined on workstations.\n\n
2015 Network security: LDAP client signing requirements\n\nThis security setting determines the level of data signing that is requested on behalf of clients issuing LDAP BIND requests, as follows:\n\nNone: The LDAP BIND request is issued with the options that are specified by the caller.\nNegotiate signing: If Transport Layer Security/Secure Sockets Layer (TLS\SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the options specified by the caller. If TLS\SSL has been started, the LDAP BIND request is initiated with the options that are specified by the caller.\nRequire signature: This is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed.\n\nCaution\n\nIf you set the server to Require signature, you must also set the client. Not setting the client results in a loss of connection with the server.\n\nNote: This setting does not have any impact on ldap_simple_bind or ldap_simple_bind_s. No Microsoft LDAP clients that are shipped with Windows XP Professional use ldap_simple_bind or ldap_simple_bind_s to talk to a domain controller.\n\nDefault: Negotiate signing.\n\n
2016 Network security: Minimum session security for NTLM SSP based (including secure RPC) clients\n\nThis security setting allows a client to require the negotiation of 128-bit encryption and/or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value. The options are:\n\nRequire NTLMv2 session security: The connection will fail if NTLMv2 protocol is not negotiated.\nRequire 128-bit encryption: The connection will fail if strong encryption (128-bit) is not negotiated.\n\nDefault: No requirements.\n\n
2017 Network security: Minimum session security for NTLM SSP based (including secure RPC) servers\n\nThis security setting allows a server to require the negotiation of 128-bit encryption and/or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value. The options are:\n\nRequire NTLMv2 session security: The connection will fail if message integrity is not negotiated.\nRequire 128-bit encryption. The connection will fail if strong encryption (128-bit) is not negotiated.\n\nDefault: No requirements.\n\n
2018 Recovery console: Allow automatic administrative logon\n\nThis security setting determines if the password for the Administrator account must be given before access to the system is granted. If this option is enabled, the Recovery Console does not require you to provide a password, and it automatically logs on to the system.\n\nDefault: This policy is not defined and automatic administrative logon is not allowed.\n\n
2019 Recovery console: Allow floppy copy and access to all drives and all folders\n\nEnabling this security option makes the Recovery Console SET command available, which allows you to set the following Recovery Console environment variables:\n\nAllowWildCards: Enable wildcard support for some commands (such as the DEL command).\nAllowAllPaths: Allow access to all files and folders on the computer.\nAllowRemovableMedia: Allow files to be copied to removable media, such as a floppy disk.\nNoCopyPrompt: Do not prompt when overwriting an existing file.\n\nDefault: This policy is not defined and the recover console SET command is not available.\n\n
2020 Shutdown: Allow system to be shut down without having to log on\n\nThis security setting determines whether a computer can be shut down without having to log on to Windows.\n\nWhen this policy is enabled, the Shut Down command is available on the Windows logon screen.\n\nWhen this policy is disabled, the option to shut down the computer does not appear on the Windows logon screen. In this case, users must be able to log on to the computer successfully and have the Shut down the system user right before they can perform a system shutdown.\n\nDefault on workstations: Enabled.\nDefault on servers: Disabled.\n\n
2021 Shutdown: Clear virtual memory pagefile\n\nThis security setting determines whether the virtual memory pagefile is cleared when the system is shut down.\n\nVirtual memory support uses a system pagefile to swap pages of memory to disk when they are not used. On a running system, this pagefile is opened exclusively by the operating system, and it is well protected. However, systems that are configured to allow booting to other operating systems might have to make sure that the system pagefile is wiped clean when this system shuts down. This ensures that sensitive information from process memory that might go into the pagefile is not available to an unauthorized user who manages to directly access the pagefile.\n\nWhen this policy is enabled, it causes the system pagefile to be cleared upon clean shutdown. If you enable this security option, the hibernation file (hiberfil.sys) is also zeroed out when hibernation is disabled on a portable computer system.\n\nDefault: Disabled.\n\n
2022 System Cryptography: Force strong key protection for user keys stored on the computer\n\nThis security setting determines if users' private keys require a password to be used.\n\nThe options are:\n\nUser input is not required when new keys are stored and used\nUser is prompted when the key is first used\nUser must enter a password each time they use a key\nFor more information, see Public key infrastructure.\n\nDefault: This policy is not defined.\n\n
2023 System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing\n\nThis security setting determines if the Transport Layer Security/Secure Sockets Layer (TL/SS) Security Provider supports only the Transport Layer Security (TLS) protocol as a client and as a server (if applicable). If this setting is enabled, it uses only the Triple DES encryption algorithm for the TLS traffic encryption, only the Rivest, Shamir, and Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hashing Algorithm 1 (SHA-1) for the TLS hashing requirements.\n\nFor Encrypting File System Service (EFS), it supports only the Triple Data Encryption Standard (DES) encryption algorithm for encrypting file data supported by the NTFS file system. By default, EFS uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key in the Windows Server 2003 family and DESX algorithm in Windows XP for encrypting file data. For information about EFS, see Encrypting File System.\n\nFor Terminal Services, it supports only the Triple DES encryption algorithm for encrypting terminal services network communication. For information about Terminal Services, see Terminal Services.\n\nDefault: Disabled.\n\nNote: The Federal Information Processing Standard (FIPS) 140-1 is a security implementation designed for certifying cryptographic software. FIPS 140-1 validated software is required by the U.S. Government and requested by other prominent institutions.\n\n
2024 System objects: Default owner for objects created by members of the Administrators group\nDescription\nThis security setting determines which users and groups have the authority to run volume maintenance tasks, such as Disk Cleanup and Disk Defragmenter.\n\nDefault: Administrators group (on servers).\n\n
2025 System objects: Require case insensitivity for non-Windows subsystems\n\nThis security setting determines whether case insensitivity is enforced for all subsystems. The Win32 subsystem is case insensitive. However, the kernel supports case sensitivity for other subsystems, such as POSIX.\n\nIf this setting is enabled, case insensitivity is enforced for all directory objects, symbolic links, and IO objects, including file objects. Disabling this setting does not allow the Win32 subsystem to become case sensitive.\n\nDefault: Enabled.\n\n
2026 System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)\n\nThis security setting determines the strength of the default discretionary access control list (DACL) for objects.\n\nActive Directory maintains a global list of shared system resources, such as DOS device names, mutexes, and semaphores. In this way, objects can be located and shared among processes. Each type of object is created with a default DACL that specifies who can access the objects and what permissions are granted.\n\nIf this policy is enabled, the default DACL is stronger, allowing users who are not administrators to read shared objects but not allowing these users to modify shared objects that they did not create.\n\nDefault: Enabled.\n\n
2027 System settings: Optional subsystems\n\nThis security setting determines which subsystems are used to support your applications. With this security setting, you can specify as many subsytems to support as your environment demands.\n\nDefault: POSIX.\n\n
2028 System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies\n\nThis security setting determines if digital certificates are processed when a user or process attempts to run software with an .exe file name extension. This security settings is used to enable or disable certificate rules, a type of software restriction policies rule. With software restriction policies, you can create a certificate rule that will allow or disallow software that is signed by Authenticode to run, based on the digital certificate that is associated with the software. In order for certificate rules to take effect, you must enable this security setting.\n\nWhen certificate rules are enabled, software restriction policies will check a certificate revocation list (CRL) to make sure the software's certificate and signature are valid. This may decrease performance when start signed programs. You can disable this feature. On Trusted Publishers Properties, clear the Publisher and Timestamp check boxes. For more information, see Set trusted publisher options.\n\nDefault: Disabled.\n\n
2029 Maximum application log size\n\nThis security setting specifies the maximum size of the application event log, which has a maximum of 4 GB.\n\nNotes\n\nLog file sizes must be a multiple of 64 KB. If you enter a value that is not a multiple of 64 KB, Event Viewer will set the log file size to a multiple of 64 KB.\nThis setting does not appear in the Local Computer Policy object.\nEvent Log size and log wrapping should be defined to match the business and security requirements you determined when designing your enterprise security plan. Consider implementing these Event Log settings at the site, domain, or organizational unit level, to take advantage of Group Policy settings.\nDefault: For the Windows Server 2003 family, 16 MB; for Windows XP Professional Service Pack 1, 8 MB; for Windows XP Professional, 512 KB.\n\n
2030 Maximum security log size\n\nThis security setting specifies the maximum size of the security event log, which has a maximum size of 4 GB.\n\nNotes\n\nLog file sizes must be a multiple of 64 KB. If you enter a value that is not a multiple of 64 KB, Event Viewer will set the log file size to a multiple of 64 KB.\nThis setting does not appear in the Local Computer Policy object.\nEvent Log size and log wrapping should be defined to match the business and security requirements you determined when designing your enterprise security plan. Consider implementing these Event Log settings at the site, domain, or organizational unit level, to take advantage of Group Policy settings.\nDefault: For the Windows Server 2003 family, 16 MB; for Windows XP Professional Service Pack 1, 8 MB; for Windows XP Professional, 512 KB.\n\n
2031 Maximum system log size\n\nThis security setting specifies the maximum size of the system event log, which has a maximum size of 4 GB.\n\nNotes\n\nLog file sizes must be a multiple of 64 KB. If you enter a value that is not a multiple of 64 KB, Event Viewer will set the log file size to a multiple of 64 KB.\nThis setting does not appear in the Local Computer Policy object.\nEvent Log size and log wrapping should be defined to match the business and security requirements you determined when designing your Enterprise Security Plan. Consider implementing these Event Log settings at the site, domain, or organizational unit level, to take advantage of Group Policy settings.\nDefault: For the Windows Server 2003 family, 16 MB; for Windows XP Professional Service Pack 1, 8 MB; for Windows XP Professional, 512 KB.\n\n
2032 Prevent local guests group from accessing application log\n\nThis security setting determines if guests are prevented from accessing the application event log.\n\nNotes\n\nThis setting does not appear in the Local Computer Policy object.\nThis security setting affects only computers running Windows 2000 and Windows XP.\nDefault: Enabled.\n\n
2033 Prevent local guests group from accessing security log\n\nThis security setting determines if guests are prevented from accessing the security event log.\n\nNotes\n\nThis setting does not appear in the Local Computer Policy object.\nThis security setting affects only computers running Windows 2000 and Windows XP.\nA user must possess the Manage auditing and security log user right to access the security log.\nDefault: Enabled.\n\n
2034 Prevent local guests group from accessing system log\n\nThis security setting determines if guests are prevented from accessing the system event log.\n\nNotes\n\nThis setting does not appear in the Local Computer Policy object.\nThis security setting affects only computers running Windows 2000 and Windows XP.\nDefault: Enabled.\n\n
2035 Retain application log\n\nThis security setting determines the number of days' worth of events to be retained for the application log if the retention method for the application log is By Days.\n\nSet this value only if you archive the log at scheduled intervals and you make sure that the Maximum application log size is large enough to accommodate the interval.\n\nNotes\n\nThis setting does not appear in the Local Computer Policy object.\nA user must possess the Manage auditing and security log user right to access the security log.\nDefault: None.\n\n
2036 Retain security log\n\nThis security setting determines the number of days' worth of events to be retained for the security log if the retention method for the security log is By Days.\n\nSet this value only if you archive the log at scheduled intervals and you make sure that the Maximum security log size is large enough to accommodate the interval.\n\nNote: This setting does not appear in the Local Computer Policy object.\nDefault: None.\n\n
2037 Retain system log\n\nThis security setting determines the number of days' worth of events to be retained for the system log if the retention method for the system log is By Days.\n\nSet this value only if you archive the log at scheduled intervals and you make sure that the Maximum system log size is large enough to accommodate the interval.\n\nNote: This setting does not appear in the Local Computer Policy object.\nDefault: None.\n\n
2038 Retention method for application log\n\nThis security setting determines the "wrapping" method for the application log.\n\nIf you do not archive the application log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events as needed.\n\nIf you archive the log at scheduled intervals, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events by days and specify the appropriate number of days in the Retain application log setting. Make sure that the Maximum application log size is large enough to accommodate the interval.\n\nIf you must retain all the events in the log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Do not overwrite events (clear log manually). This option requires that the log be cleared manually. In this case, when the maximum log size is reached, new events are discarded.\n\nNote: This setting does not appear in the Local Computer Policy object.\n\nDefault: None.\n\n
2039 Retention method for security log\n\nThis security setting determines the "wrapping" method for the security log.\n\nIf you do not archive the security log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events as needed.\n\nIf you archive the log at scheduled intervals, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events by days and specify the appropriate number of days in the retain security log setting. Make sure that the Maximum security log size is large enough to accommodate the interval.\n\nIf you must retain all the events in the log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Do not overwrite events (clear log manually). This option requires that the log be cleared manually. In this case, when the maximum log size is reached, new events are discarded.\n\nNote: This setting does not appear in the Local Computer Policy object.\n\nDefault: None.\n\n
2040 Retention method for system log\n\nThis security setting determines the "wrapping" method for the system log.\n\nIf you do not archive the system log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events as needed.\n\nIf you archive the log at scheduled intervals, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events by days and specify the appropriate number of days in the Retain system log setting. Make sure that the Maximum system log size is large enough to accommodate the interval.\n\nIf you must retain all the events in the log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Do not overwrite events (clear log manually). This option requires that the log be cleared manually. In this case, when the maximum log size is reached, new events are discarded.\n\nNote: This setting does not appear in the Local Computer Policy object.\n\nDefault: None.\n\n
2041 Restricted Groups\n\nThis security setting allows an administrator to define two properties for security-sensitive groups ("restricted" groups).\n\nThe two properties are Members and Member Of. The Members list defines who belongs and who does not belong to the restricted group. The Member Of list specifies which other groups the restricted group belongs to.\n\nWhen a Restricted Groups Policy is enforced, any current member of a restricted group that is not on the Members list is removed. Any user on the Members list who is not currently a member of the restricted group is added.\n\nYou 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 that are specified in the Member Of column.\n\nFor 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.\n\nThere are two ways to apply Restricted Groups policy:\n\nDefine the policy in a security template, which will be applied during configuration on your local computer.\nDefine the setting on a Group Policy object (GPO) directly, which means that the policy goes into effect with every refresh of policy. The security settings are refreshed every 90 minutes on a workstation or server and every 5 minutes on a domain controller. The settings are also refreshed every 16 hours, whether or not there are any changes.\nDefault: None specified.\n\nCaution\n\nIf 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.\n\nNotes\n\nRestricted Groups should be used primarily to configure membership of local groups on workstation or member servers.\nAn empty Members list means that the restricted group has no members; an empty Member Of list means that the groups to which the restricted group belongs are not specified.\n\n
2042 System Services security settings\n\nAllows an administrator to define the startup mode (manual, automatic, or disabled) as well as the access permissions (Start, Stop, or Pause) for all system services.\n\nDefault: Undefined.\n\nNotes\n\nThis setting does not appear in the Local Computer Policy object.\nIf you choose to set system service startup to Automatic, perform adequate testing to verify that the services can start without user intervention.\nFor performance optimization, set unnecessary or unused services to Manual.\n\n
2043 Registry security settings\n\nAllows an administrator to define access permissions (on discretionary access control lists (DACLs)) and audit settings (on system access control lists (SACLs)) for registry keys using Security Configuration Manager.\n\nDefault: Undefined.\n\nNote: This setting does not appear in the Local Computer Policy object.\n\n
2044 File System security settings\n\nAllows an administrator to define access permissions (on discretionary access control lists (DACLs)) and audit settings (on system access control lists (SACLs)) for file system objects using Security Configuration Manager.\n\nDefault: Undefined.\n\nNote: This setting does not appear in the Local Computer Policy object.\n
2045 Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.\n\nWindows Vista and later versions of Windows allow audit policy to be managed in a more precise way using audit policy subcategories. Setting audit policy at the category level will override the new subcategory audit policy feature. To allow audit policy to be managed using subcategories without requiring a change to Group Policy, there is a new registry value in Windows Vista and later versions, SCENoApplyLegacyAuditPolicy, which prevents the application of category-level audit policy from Group Policy and from the Local Security Policy administrative tool.\n\nIf the category level audit policy set here is not consistent with the events that are currently being generated, the cause might be that this registry key is set.\n\nDefault: Disabled\n
2046 User Account Control: Admin Approval Mode for the Built-in Administrator account\n\nThis security setting determines the behavior of Admin Approval mode for the Built-in Administrator account.\n\nThe options are:\n\n" Enabled: The Built-in Administrator will logon in Admin Approval Mode. By default any operation that requires elevation of privilege will prompt the Consent Admin to choose either Permit or Deny.\n\n" Disabled: The Built-in Administrator will logon in XP compatible mode and run all applications by default with full administrative privilege.\n\nDefault: Disabled\n
2047 DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax\n\nThis policy setting determines which users or groups can access DCOM application remotely or locally. This setting is used to control the attack surface of the computer for DCOM applications.\n\nYou can use this policy setting to specify access permissions to all the computers to particular users for DCOM applications in the enterprise. When you specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. If the security descriptor is left blank, the policy setting is defined in the template, but it is not enforced. Users and groups can be given explicit Allow or Deny privileges on both local access and remote access.\n\nThe registry settings that are created as a result of enabling the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting take precedence over (have higher priority) the previous registry settings in this area. Remote Procedure Call Services (RpcSs) checks the new registry keys in the Policies section for the computer restrictions, and these registry entries take precedence over the existing registry keys under OLE. This means that previously existing registry settings are no longer effective, and if you make changes to the existing settings, computer access permissions for users are not changed. Use care in configuring their list of users and groups.\n\nThe possible values for this policy setting are:\n\n" Blank. This represents the local security policy way of deleting the policy enforcement key. This value deletes the policy and then sets it as Not defined state. The Blank value is set by using the ACL editor and emptying the list, and then pressing OK.\n\n" SDDL. This is the Security Descriptor Definition Language representation of the groups and privileges you specify when you enable this policy.\n\n" Not Defined. This is the default value.\n\nNote\nIf the administrator is denied permission to access DCOM applications due to the changes made to DCOM in Windows, the administrator can use the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting to manage DCOM access to the computer. The administrator can specify which users and groups can access the DCOM application on the computer both locally and remotely by using this setting. This will restore control of the DCOM application to the administrator and users. To do this, open the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax setting, and click Edit Security. Specify the groups you want to include and the computer access permissions for those groups. This defines the setting and sets the appropriate SDDL value.\n\n\n\n
2048 DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax\n\nThis policy setting determines which users or groups can launch or activate DCOM applications remotely or locally. This setting is used to control the attack surface of the computer for DCOM applications.\n\nYou can use this setting to grant access to all the computers to users of DCOM applications. When you define this setting, and specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. If the security descriptor is left blank, the policy setting is defined in the template, but it is not enforced. Users and groups can be given explicit Allow or Deny privileges on local launch, remote launch, local activation, and remote activation.\n\nThe registry settings that are created as a result of this policy take precedence over the previous registry settings in this area. Remote Procedure Call Services (RpcSs) checks the new registry keys in the Policies section for the computer restrictions; these entries take precedence over the existing registry keys under OLE.\n\nThe possible values for this Group Policy setting are:\n\n" Blank. This represents the local security policy way of deleting the policy enforcement key. This value deletes the policy and then sets it to Not defined state. The Blank value is set by using the ACL editor and emptying the list, and then pressing OK.\n\n" SDDL. This is the Security Descriptor Definition Language representation of the groups and privileges you specify when you enable this policy.\n\n" Not Defined. This is the default value.\n\nNote\nIf the administrator is denied access to activate and launch DCOM applications due to the changes made to DCOM in this version of Windows, this policy setting can be used for controlling the DCOM activation and launch to the computer. The administrator can specify which users and groups can launch and activate DCOM applications on the computer both locally and remotely by using the DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting. This restores control of the DCOM application to the administrator and specified users. To do this, open the DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax setting, and click Edit Security. Specify the groups you want to include and the computer launch permissions for those groups. This defines the setting and sets the appropriate SDDL value.\n\n\nUser Account Control: Admin Approval Mode for the Built-in Administrator account\n\nThis security setting determines the behavior of Admin Approval mode for the Built-in Administrator account.\n\nThe options are:\n\n" Enabled: The Built-in Administrator will logon in Admin Approval Mode. By default any operation that requires elevation of privilege will prompt the Consent Admin to choose either Permit or Deny.\n\n" Disabled: The Built-in Administrator will logon in XP compatible mode and run all applications by default with full administrative privilege.\n\nDefault: Disabled\n\n
2049 User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode\n\nThis security setting determines the behavior of the elevation prompt for administrators\n\nThe options are:\n\n" Prompt for consent: An operation that requires elevation of privilege will prompt the Consent Admin to select either Permit or Deny. If the Consent Admin selects Permit the operation will continue with their highest available privilege. This option allows users to enter their name and password to perform a privileged task.\n\n" Prompt for credentials: An operation that requires elevation of privilege will prompt the Consent Admin to enter their user name and password. If the user enters valid credentials the operation will continue with the applicable privilege.\n\n" Elevate without prompting: This option allows the Consent Admin to perform an operation that requires elevation without consent or credentials. Note: this scenario should only be used in the most constrained environments.\n\nDefault: Prompt for consent\n\n
2050 User Account Control: Behavior of the elevation prompt for standard users\nThis security setting determines the behavior of the elevation prompt for standard users\n\nThe options are:\n\n" Prompt for credentials: An operation that requires elevation of privilege will prompt the user to enter an administrative user name and password. If the user enters valid credentials the operation will continue with the applicable privilege.\n\n" Automatically deny elevation requests: This option results in an access denied error message being returned to the standard user when they try to perform an operation that requires elevation of privilege. Most enterprises running desktops as standard user will configure this policy to reduce help desk calls.\n\nDefault: Prompt for credentials (home) / Automatically deny elevation requests (enterprise)\n\n
2051 User Account Control: Detect application installations and prompt for elevation\n\nThis security setting determines the behavior of application installation detection for the entire system.\n\nThe options are:\n\n" Enabled: Application installation packages that require an elevation of privilege to install will be heuristically detected and trigger the configured elevation prompt UX.\n\n" Disabled: Enterprises running standard users desktops that leverage delegated installation technologies like Group Policy Software Install (GPSI) or SMS will disable this feature. In this case, installer detection is unnecessary and thus not required.\n\nDefault: Enabled (home) / Disabled (enterprise)\n\n
2052 User Account Control: Only elevate executables that are signed and validated\n\nThis security setting will enforce PKI signature checks on any interactive application that requests elevation of privilege. Enterprise administrators can control the admin application allowed list thru the population of certificates in the local computers Trusted Publisher Store.\n\nThe options are:\n\n" Enabled: Enforces the PKI certificate chain validation of a given executable before it is permitted to run.\n\n" Disabled: Does not enforce PKI certificate chain validation before a given executable is permitted to run.\n\nDefault: Disabled\n\n
2053 User Account Control: Only elevate UIAccess applications that are installed in secure locations\n\nThis security setting will enforce the requirement that applications that request execution with a UIAccess integrity level (via a marking of UIAccess=true in their application manifest), must reside in a secure location on the file system. Secure locations are limited to the following directories:\n\n- & \Program Files\, including subdirectories\n- & \Windows\system32\r\n- & \Program Files (x86)\, including subdirectories for 64 bit versions of Windows\n\nNote: Windows enforces a PKI signature check on any interactive application that requests execution with UIAccess integrity level regardless of the state of this security setting.\n\nThe options are:\n\n" Enabled: An application will only launch with UIAccess integrity if it resides in a secure location in the file system.\n\n" Disabled: An application will launch with UIAccess integrity even if it does not reside in a secure location in the file system.\n\nDefault: Enabled\n\n
2054 User Account Control: Run all users, including administrators, as standard users.\n\nThis security setting determines the behavior of all UAC policies for the entire system.\n\nThe options are:\n\n" Enabled: Admin Approval Mode and all other UAC policies are dependent on this option being enabled. Changing this setting requires a system reboot.\n\n" Disabled: Admin Approval Mode user type and all related UAC policies will be disabled. Note: the Security Center will notify that the overall security of the operating system has been reduced.\n\nDefault: Enabled\n\n
2055 User Account Control: Switch to the secure desktop when prompting for elevation\n\nThis security setting determines whether the elevation request will prompt on the interactive users desktop or the Secure Desktop.\n\nThe options are:\n\n" Enabled: All elevation requests by default will go to the secure desktop\n\n" Disabled: All elevation requests will go to the interactive users desktop\n\nDefault: Enabled\n\n
2056 User Account Control: Virtualizes file and registry write failures to per-user locations\n\nThis security setting enables the redirection of legacy application write failures to defined locations in both the registry and file system. This feature mitigates those applications that historically ran as administrator and wrote runtime application data back to either %ProgramFiles%, %Windir%; %Windir%\system32 or HKLM\Software\....\n\nVirtualization facilitates the running of pre-Vista (legacy) applications that historically failed to run as Standard User. An administrator running only Windows Vista compliant applications may choose to disable this feature as it is unnecessary.\n\nThe options are:\n\n" Enabled: Facilitates the runtime redirection of application write failures to defined user locations for both the file system and registry.\n\n" Disabled: Applications that write data to protected locations will simply fail as they did in previous versions of Windows.\n\nDefault : Enabled\n\n
2057 Create Symbolic Links\n\nThis privilege determines if the user can create a symbolic link from the computer he is logged on to.\n\nDefault: Administrator\n\nWARNING: This privilege should only be given to trusted users. Symbolic links can expose security vulnerabilities in applications that aren t designed to handle them.\n\nNote\nThis setting can be used in conjunction a symlink filesystem setting that can be manipulated with the command line utility to control the kinds of symlinks that are allowed on the machine. Type fsutil behavior set symlinkevalution /? at the command line to get more information about fsutil and symbolic links.\n\n
2058 Modify an object label\n\nThis privilege determines which user accounts can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. Processes running under a user account can modify the label of an object owned by that user to a lower level without this privilege.\n\nDefault: None\n\n
2080 User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop.\n\nThis security setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts being used by a standard user.\n\nIf you enable this setting, UIA programs including Windows Remote Assistance can automatically disable the secure desktop for elevation prompts. Unless you have also disabled elevation prompts, the prompts will appear on the interactive user's desktop instead of the secure desktop.\n\nIf you disable or do not configure this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the "User Account Control: Switch to the secure desktop when prompting for elevation" setting.\n\nUIA programs are designed to interact with Windows and application programs on behalf of a user. This setting allows UIA programs to bypass the secure desktop to increase usability in certain cases, but allowing elevation requests to appear on the regular interactive desktop instead of the secure desktop increases your security risk.\n\nSince UIA programs must be able to respond to prompts regarding security issues, such as the UAC elevation prompt, UIA programs must be highly trusted. In order to be considered trusted, a UIA program must be digitally signed. By default, UIA programs can be run only from the following protected paths:\n ..\Program Files\ (and subfolders)\n ..\Program Files (x86)\ (and subfolders, in 64-bit versions of Windows only)\n ..\Windows\System32\\n\nThe requirement to be in a protected path can be disabled by the "User Account Control: Only elevate UIAccess applications that are installed in secure locations" setting.\n\nWhile this setting applies to any UIA program, it will be used primarily in certain Windows Remote Assistance scenarios. The Windows Remote Assistance program in Windows Vista is a UIA program.\n\nIf a user requests remote assistance from an administrator and the remote assistance session is established, any elevation prompts appear on the interactive user's secure desktop and the administrator's remote session is paused. To avoid pausing the remote administrator s session during elevation requests, the user may select the "Allow IT Expert to respond to User Account Control prompts" check box when setting up the remote assistance session. However, selecting this check box itself requires that the interactive user respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow elevation.\n\nIf you enable this setting, ("User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop ), requests for elevation are automatically sent to the interactive desktop (not the secure desktop) and also appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator is able to provide the appropriate credentials for elevation.\n\nThis setting does not change the behavior of the UAC elevation prompt for administrators.\n\nIf you plan to enable this setting, you should also review the effect of the "User Account Control: Behavior of the elevation prompt for standard users" setting. If it is configured as "Automatically deny elevation requests" elevation requests will not be presented to the user.\n
57344 Security Templates
57345 You are about to import new template information into the local computer policy for this computer. Doing so will change your computer security settings. Do you want to continue?
57346 Configuring Computer Security
57350 Current Security Configuration Database: Local Policy Database
57351 Current Security Configuration Database: Private Database %s
57352 Generating analysis information
57353 Import Failed
57354 Subitems defined
57355 Not Available
57356 New Service
57357 Configuring:
57358 Add &File...\nAdds a new file or folder to this template
57359 Add this file or folder to the template:
57360 Add a file or folder
57361 Microsoft Corporation
57362 6.0
57363 Security Templates is an MMC snap-in that provides editing capabilities for security template files.
57364 Security Configuration and Analysis is an MMC snap-in that provides security configuration and analysis for Windows computers using security template files.
57365 The Security Settings Extension snap-in extends the Group Policy snap-in and helps you define security policies for computers in your domain.
57366 &Import Policy...\nImport a template file into this policy object.
57367 E&xport policy...\nExport template from this policy to a file.
57368 File %s already exists.\nDo you want to overwrite it?
57369 Success
57370 Failure
57371 No auditing
57372 Windows cannot update the policies.
57373 Windows cannot copy the section
57374 Select File to Add
57375 Open database
57376 Create Database
57377 Export Policy To
57378 Import Policy From
57380 Import Template
57381 Export Template To
57382 Security Setting
57384 Windows cannot open the local policy database.
57385 Local Policy Database
57386 The local security settings database cannot be edited from the Security Configuration and Analysis snap-in. Use the Group Policy snap-in to edit the local security settings.
57394 There are new policy settings on your computer. Do you want to update your view of the effective policy?
57395 Computer setting on %s
57396 This database couldn't be created because no template file was selected.\n<H4>To Open an Existing Database</H4><OL><LI ALIGN="LEFT" ID="NO_TEMPLATE_GIVEN_1">Right click on the <I>Security Configuration and Analysis</I> scope item. <LI ALIGN="LEFT" ID="NO_TEMPLATE_GIVEN_2">Choose <B>Open Database</B> <LI ALIGN="LEFT" ID="NO_TEMPLATE_GIVEN_3"> Choose a database and press OPEN</OL> <H4>To Create a New Database</H4><OL> <LI ALIGN="LEFT" ID="NO_TEMPLATE_GIVEN_4">Right click on the <I>Security Configuration and Analysis </I> scope item. <LI ALIGN="LEFT" ID="NO_TEMPLATE_GIVEN_5"> Choose <B>Open Database</B>. <LI ALIGN="LEFT" ID="NO_TEMPLATE_GIVEN_6"> Type in a new database name and press OPEN. <LI ALIGN="LEFT" ID="NO_TEMPLATE_GIVEN_7">Choose a security configuration file to import and press OPEN.</OL>
57397 &Replace existing permissions on all subkeys with inheritable permissions
57398 &Propagate inheritable permissions to all subkeys
57399 &Do not allow permissions on this key to be replaced
57400 Configure Membership for %s
57401 Ticket expires in:
57402 Ticket doesn't expire.
57403 Ticket renewal expires in:
57404 Ticket renewal is disabled.
57405 Maximum tolerance:
57406 Maximum tolerance:
57407 Not Applicable
57408 <This group should contain no members>
57409 <The groups to which this group belongs should not be modified>
57410 User and group names
57411 Add User or Group
57412 Do not disconnect clients:
57413 Disconnect when idle time exceeds:
57414 Do not cache logons:
57415 Cache:
57416 Begin prompting this many days before password expires:
57417 Begin prompting this many days before password expires:
57431 The RSOP Security Settings Extension snap-in extends the RSOP snap-in and helps you view resultant security policies for computers in your domain.
57435 &Apply
57436 The Group Policy security settings that apply to this machine could not be determined.\nThe error returned when trying to retreive these settings from the local security policy database (%%windir%%\security\database\secedit.sdb) was: %s\nAll local security settings will be displayed, but no indication will be given as to whether or not a given security setting is defined by Group Policy.\nAny local security setting modified through this User Interface may subsequently be overriden by domain-level policies.
57437 The Group Policy security settings that apply to this machine could not be determined.\nThe error received when trying to retreive these settings from the local policy database (%%windir%%\security\database\secedit.sdb) was: %s\nAll local security settings will be displayed, but no indication will be given as to whether or not a given security setting is defined by Group Policy.
57438 Log file:
57439 Policy Name
57440 Setting
57441 The policy %1 was correctly applied.
57442 There was an error configuring a child of this object. (or The policy engine attempted and failed to configure the child of a specific policy setting.) For more information, see %windir%\security\logs\winlogon.log
57443 The policy %1 resulted in the following error %2. For more information, see %windir%\security\logs\winlogon.log on the target machine.
57444 The policy %1 resulted in an invalid status and was logged. See %%windir%%\security\logs\winlogon.log on the target machine for more information.
57445 The policy engine did not attempt to configure the setting. For more information, see %windir%\security\logs\winlogon.log on the target machine.
57446 &View Security...
57447 Couldn't export template to %1.\nThe error returned was: %2
57448 Save changes to Security Database?
57449 Deny log on through Terminal Services
57450 Allow log on through Terminal Services
57451 Couldn't add template search path
57453 \Security\Logs
57454 The security portion of this group policy may only be edited on the PDC Emulator.
57455 This setting is not compatible with computers running Windows 2000 Service Pack 1 or earlier. Apply Group Policy objects containing this setting only to computers running a later version of the operating system.
57469 This setting affects only operating systems earlier than Windows Server 2003.
57470 Modifying this setting may affect compatibility with clients, services, and applications.\n%1
57471 For more information, see <A>%1</A>. (Q%2!lu!)
57472 You are about to change this setting to a value that may affect compatibility with clients, services, and applications.\n\n%1\n\nDo you want to continue with the change?
57473 Administrators and SERVICE must be granted the impersonate client after authentication privilege
57474 This setting might not be enforced if other policy is configured to override category level audit policy.\n%1
58000 No explain text for this action
59001 Accounts: Limit local account use of blank passwords to console logon only
59002 Audit: Audit the access of global system objects
59003 Audit: Audit the use of Backup and Restore privilege
59004 Audit: Shut down system immediately if unable to log security audits
59005 Devices: Prevent users from installing printer drivers
59010 Devices: Allow undock without having to log on
59011 Domain controller: Allow server operators to schedule tasks
