Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments (823659)
The information in this article applies to:
- Microsoft Windows Server 2003, Standard Edition
- Microsoft Windows Server 2003, Datacenter Edition
- Microsoft Windows Server 2003, Enterprise Edition
- Microsoft Windows Server 2003, 64-Bit Datacenter Edition
- Microsoft Windows Server 2003, 64-Bit Enterprise Edition
- Microsoft Windows XP Professional
- Microsoft Windows 2000 Server
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Datacenter Server
- Microsoft Windows 2000 Professional
- Microsoft Windows NT Server 4.0
- Microsoft Windows NT Workstation 4.0
- Microsoft Windows 98
- Microsoft Windows 98 Second Edition
- Microsoft Windows 95
- Microsoft Network Client for MS-DOS 3.0
- Microsoft LAN Manager
- the operating system: Mac OS (all versions)
Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft
Knowledge Base: 256986 Description of the Microsoft Windows registry SUMMARY This article describes incompatibilities that may occur on
client computers that are running Microsoft Windows 95, Microsoft Windows 98,
Microsoft Windows NT 4.0, Microsoft Windows 2000, Microsoft Windows XP
Professional, or Microsoft Windows Server 2003 when you modify specific
security settings and user rights assignments in Windows NT 4.0 domains, in
Windows 2000 domains, and in Windows Server 2003 domains. By configuring these
settings and assignments in local policies and in group policies, you can help
tighten the security on domain controllers and on member computers. The
downside of increased security is the introduction of incompatibilities with
clients, with services, and with programs. To increase the awareness of
misconfigured security settings, use the Group Policy Object Editor tool to
modify security settings. When you use Group Policy Object Editor, user rights
assignments are enhanced on the following operating systems:
- Microsoft Windows XP Professional Service Pack 2
(SP2)
- Microsoft Windows Server 2003 Service Pack 1
(SP1)
The enhancement includes a dialog box that contains a link
to this article that pops up whenever you change a security setting or a user
rights assignment to a setting that offers less compatibility and is more
restrictive. If you directly modify the same security setting or user rights
assignment by using the registry or by using security templates, the effect is
the same as modifying the setting in Group Policy Object Editor; however, the
dialog box that contains the link to this article does not appear.
This article contains examples of clients, of
programs, and of operations that are affected by specific security settings or
user rights assignments. However, the examples are not authoritative for all
Microsoft operating systems, for all third-party operating systems, or for all
program versions that are affected. Not all security settings and user rights
assignments are included in this article. Microsoft recommends that
you validate the compatibility of all security-related configuration changes in
a test forest before you introduce them in a production environment. The test
forest must mirror the production forest in the following ways:
- Client and server operating system versions, client and
server programs, service pack versions, hotfixes, schema changes, security
groups, group memberships, permissions on objects in the file system, shared
folders, the registry, Active Directory directory service, local and Group
Policy settings, and object count type and location
- Administrative tasks that are performed, administrative
tools that are used, and operating systems that are used to perform
administrative tasks
- Operations that are performed, including computer and user
logon authentication; password resets by users, by computers, and by
administrators; browsing; setting permissions for the file system, for shared
folders, for the registry, and for Active Directory resources by using ACL
Editor in all client operating systems in all account or resource domains from
all client operating systems from all account or resource domains; printing
from administrative and non-administrative accounts
Windows Server 2003 SP1Warnings in Gpedit.msc To help make customers aware that they are editing a user right or security option that could have adverse affects on their network, two warning mechanisms have been added to gpedit.msc. When administrators edit a user right that can negatively affect the entire enterprise, they will see a new an icon that looks like a yield sign. They will also receive a warning message that has a link to Microsoft Knowledge Base article 823659. The text of this message is as follows: Modifying this setting may affect compatibility with clients, services, and applications. For more information see <user right or security option being modified> (Q823659) If you have been directed to this KB from a link in GPEDIT.MSC make sure that you read and understand the explanation provided and the possible effect of modifying this setting. What follows is a list of User Rights that contain the new warning text: - Access this computer from network
-
Log on locally
- Bypass traverse checking
- Enable computers and users for trusted delegation
What follows is a list of Security Options that have the warning and a popup: - Domain Member: Digitally encrypt or sign secure channel data (always)
- Domain Member: Require strong (Windows 2000 or later) session key
- Domain Controller: LDAP server signing requirements
- Microsoft network server: Digitally sign communications (always)
- Network Access: Allows Anonymous Sid / Name translation
- Network Access: Do not allow anonymous enumeration of SAM accounts and shares
- Network security: LAN Manager Authentication level
- Audit: Shut down system immediately if unable to log security audits
- Network Access: LDAP client signing requirements
MORE INFORMATIONThe following sections describe incompatibilities that may
occur when you modify specific settings in Windows NT 4.0 domains, Windows 2000
domains, and in Windows Server 2003 domains. User rights- Access this computer from network
- Background
The ability to interact with remote Windows computers
requires the Access this computer from network user right. Examples of such network operations include the
replication of Active Directory between domain controllers in a common domain
or forest, authentication requests to domain controllers from users and from
computers, and access to shared folders, to printers, and to other system
services that are located on remote computers on the network.
Users,
computers, and service accounts gain or lose the Access this computer from network user right by being explicitly or implicitly added or removed
from a security group that has been granted this user right. For example, a
user account or a computer account may be explicitly added to a custom or a
built-in security group by an administrator or may be implicitly added by the
operating system to a computed security group such as Domain Users,
Authenticated Users, or Enterprise Domain Controllers.
By default,
user accounts and computer accounts are granted the Access this computer from network user right when computed groups such as Everyone or, preferably,
Authenticated Users and, for domain controllers, the Enterprise Domain
Controllers group, have been defined in the default domain controllers Group
Policy object (GPO). - Risky configurations
The following are risky configurations:
- Removing the Enterprise Domain Controllers security
group from this user right
- Removing the Authenticated Users group or an
explicit group that allows users, computers, and service accounts the user
right to connect to computers over the network
- Removing all users and computers from this user
right
- Reasons to grant this user right
- Granting the Enterprise Domain Controllers group
the Access this computer from network user right satisfies authentication requirements that Active
Directory replication must have for replication to occur between domain
controllers in the same forest.
- This user right allows users and computers to
access shared files, printers, and system services, including Active
Directory.
- This user right is required for users to access
mail by using early versions of Microsoft Outlook Web Access (OWA).
- Reasons to remove this user right
- Users who can connect their computers to the
network can access resources on remote computers that they have permissions
for. For example, this user right is required for a user to connect to shared
printers and to folders. If this user right is granted to the Everyone group,
and if some shared folders have both share and NTFS file system permissions
configured so that the same group has read access, anyone can view files in
those shared folders. However, this is an unlikely situation for fresh
installations of Windows Server 2003 because the default share and the NTFS
permissions in Windows Server 2003 do not include the Everyone group. For
systems that are upgraded from Microsoft Windows NT 4.0 or Windows 2000, this
vulnerability may have a higher level of risk because the default share and the
file system permissions for these operating systems are not as restrictive as
the default permissions in Windows Server 2003.
- There is no valid reason for removing Enterprise
Domain Controllers group from this user right.
- The Everyone group is generally removed in favor of
the Authenticated Users group. If the Everyone group is removed, the
Authenticated Users group must be granted this user right.
- Windows NT 4.0 domains that are upgraded to Windows
2000 do not explicitly grant the Everyone, the Authenticated Users, or the
Enterprise Domain Controllers group the Access this computer from network user right. Therefore, when you remove the Everyone group from
Windows NT 4.0 domain policy, Active Directory replication will fail with an
"Access Denied" error message after you upgrade to Windows 2000. Winnt32.exe in
Windows Server 2003 avoids this misconfiguration by granting the Enterprise
Domain Controllers group this user right when you upgrade Windows NT 4.0
primary domain controllers (PDCs). Grant the Enterprise Domain Controllers
group this user right if it is not present in the Group Policy Object
Editor.
- Examples of compatibility problems
- Windows 2000 and Windows Server 2003: Replication of Active Directory Schema, of Configuration, of
Domain, of global catalog, or of Application Partitions will fail with "Access
Denied" errors as reported by monitoring tools such as REPLMON and REPADMIN or
replication events in the event log.
- All Microsoft network operating systems: User Account authentication from remote network client computers
will fail unless the user or a security group that the user is a member of has
been granted this user right.
- All Microsoft network operating systems: Account authentication from remote network clients will fail
unless the account or a security group the account is a member of has been
granted this user right. This scenario applies to user accounts, to computer
accounts, and to service accounts.
- All Microsoft network operating systems: Removing all accounts from this user right will prevent any
account from logging on to the domain or from accessing network resources. If
computed groups such as Enterprise Domain Controllers, Everyone, or
Authenticated Users are removed, you must explicitly grant this user right to
accounts or to security groups that the account is a member of to access remote
computers over the network. This scenario applies to all user accounts, to all
computer accounts, and to all service accounts.
- All Microsoft network operating systems: The local administrator account uses a "blank" password. Network connectivity with blank passwords is not permitted for administrator accounts in a domain environment. With this configuration, you can expect to receive an "Access Denied" error message.
- Allow log on locally
- Background
Users who are trying to log on at the console of a
Microsoft Windows-based computer (by using the CTRL+ALT+DELETE logon key
sequence) and accounts who are trying to start a service must have local logon
privileges on the hosting computer. Examples of local logon operations include
administrators who are logging on to the consoles of member computers, or
domain controllers throughout the enterprise and domain users who are logging
on to member computers to access their desktops by using non-privileged
accounts. Users who use a Remote Desktop connection or Terminal Services must
have the Allow log on locally user right on destination computers that are running Windows 2000
or Windows XP
because these logon modes are considered local to the hosting computer. Users
who are logging on to a server that has Terminal Server enabled and who do not
have this user right can still start a remote interactive session in Windows
Server 2003 domains if they have the Allow logon through Terminal Services user right. - Risky configurations
The following are risky configurations:
- Removing administrative security groups, including
Account Operators, Backup Operators, Print Operators or Server Operators, and
the built-in Administrators group from the default domain controllers
policy.
- Removing service accounts that are used by
components and by programs on member computers and on domain controllers in the
domain from the default domain controllers policy.
- Removing users or security groups that log on to
the console of member computers in the domain.
- Removing service accounts that are defined in the
local Security Accounts Manager (SAM) database of member computers or of
workgroup computers.
- Removing non-built-in administrative accounts that
are authenticating over Terminal Services that is running on a domain
controller.
- Adding all user accounts in the domain explicitly
or implicitly through the Everyone group to the Deny logon locally logon right. This configuration will prevent users from logging
on to any member computer or to any domain controller in the domain.
- Reasons to grant this user right
- Users must have the Allow log on locally user right to access the console or the desktop of a workgroup
computer, a member computer, or a domain controller.
- Users must have this user right to log on over a
Terminal Services session that is running on a Window 2000-based
member computer or domain controller.
- Reasons to remove this user right
- Failure to restrict console access to legitimate
user accounts could result in unauthorized users downloading and executing
malicious code to change their user rights.
- Removal of the Allow log on locally user right prevents unauthorized logons on the consoles of
computers, such as domain controllers or application servers.
- Removal of this logon right prevents non-domain
accounts from logging on at the console of member computers in the
domain.
- Examples of compatibility problems
- Windows 2000 terminal servers: The Allow log on locally user right is required for users to log on to Windows 2000
terminal servers.
- Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003: User accounts must be granted this user right to log on at the
console of computers that are running Windows NT 4.0, Windows 2000, Windows XP,
or Windows Server 2003.
- Windows NT 4.0 and later: On computers that are running Windows NT 4.0 and later, if you
add the Allow log on locally user right, but you implicitly or explicitly also grant the Deny logon locally logon right, the accounts will not be able to log on to the
console of the domain controllers.
- Bypass traverse checking
- Background
The Bypass traverse checking user right allows the user to browse through folders in the NTFS
file system or in the registry without checking for the Traverse Folder special access permission. The Bypass traverse checking user right does not allow the user to list the contents of a
folder; it allows the user to traverse its folders only. - Risky configurations
The following are risky configurations:
- Removing non-administrative accounts that log on
to Windows 2000-based or Windows Server 2003-based Terminal Services computers
that lack permissions to access files and folders in the file
system.
- Removing the Everyone group from the list of
security principals who, by default, have this user right. The Windows
operating systems, and also many programs, have been designed with the
expectation that anyone who can legitimately access the computer will have the Bypass traverse checking user right. Therefore, removing the Everyone group from the list
of security principals who, by default, have this user right could lead to
operating system instability or to program failure. It is better that you leave
this setting at its default.
- Reasons to grant this user right
The default setting for the Bypass traverse checking user right is to allow anyone to bypass traverse checking. For
experienced Windows system administrators, this is the expected behavior, and
they configure file system access control lists (SACLs) accordingly. The only
scenario where the default configuration may lead to a mishap is if the
administrator who configures permissions does not understand the behavior and
expects that users who cannot access a parent folder will not be able to access
the contents of any child folders. - Reasons to remove this user right
Organizations that are extremely concerned about
security may be tempted to remove the Everyone group, or even perhaps to remove
the Users group, from the list of groups that have the Bypass traverse checking user right to try to prevent access to the files or the folders
in the file system. - Examples of compatibility problems
Security Settings- Audit: Shut down system immediately if unable to log security audits
- Background
- The Audit: Shut down system immediately if unable to log security audits setting determines whether the system shuts down if you cannot
log security events. This setting is required for the Trusted Computer Security
Evaluation Criteria (TCSEC) program's C2 evaluation and for the Common Criteria
for Information Technology Security Evaluation to prevent auditable events if
the audit system cannot log those events. If
the auditing system fails, the system is shut down, and a Stop error message
appears.
- If the computer cannot record events to the
security log, critical evidence or important troubleshooting information may
not be available for review after a security incident.
- Risky configuration
The following is a risky configuration: The Audit: Shut down system immediately if unable to log security audits setting is turned on, and the size of the security event log is constrained by the Do not overwrite events (clear log manually) option, the Overwrite Events as needed option, or the Overwrite Events older than number days option in Event Viewer. See the "Examples of Compatibility
Problems" section for information about specific risks for computers that are
running the original released version of Windows 2000, Windows 2000 Service
Pack 1 (SP1), Windows 2000 SP2, or Windows 2000 SP3. - Reasons to enable this setting
If the computer cannot record events to the security
log, critical evidence or important troubleshooting information may not be
available for review after a security incident. - Reasons to disable this setting
- Enabling the Audit: Shut down system immediately if unable to log security audits setting stops the system if a security audit cannot be logged for
any reason. Typically, an event cannot be logged when the security audit log is
full and when its specified retention method is either the Do not overwrite events (clear log manually) option or the Overwrite Events older than number days option.
- The administrative burden of enabling the Audit: Shut down system immediately if unable to log security audits setting can be very high, especially if you also turn on the Do not overwrite events (clear log manually) option for the security log. This setting provides for individual
accountability of operator actions. For example, an administrator could reset
permissions on all users, computers, and groups in an organizational unit (OU)
where auditing was enabled by using the built-in administrator account or other
shared account and then deny that they reset such permissions. However,
enabling the setting does reduce the robustness of the system because a server
may be forced to shut down by overwhelming it with logon events and with other
security events that are written to the security log. Additionally, because the
shutdown is not graceful, irreparable damage to the operating system, to
programs, or to data may result. While NTFS guarantees that the file system's
integrity is maintained during an ungraceful system shutdown, it cannot
guarantee that every data file for every program will still be in a usable form
when the system restarts.
- Symbolic Name: CrashOnAuditFail
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD) - Examples of compatibility problems
- Windows 2000: Because of a bug, computers that are running the original
released version of Windows 2000, Windows 2000 SP1, Windows 2000 SP2, or
Windows Server SP3 may stop logging events before the size that is specified in the Maximum log size option for the security event log is reached. This bug is fixed
in Windows 2000 Service Pack 4 (SP4). Make sure that your Windows 2000 domain
controllers have Windows 2000 Service Pack 4 installed before you consider
enabling this setting.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
312571
The event log stops logging events before reaching the maximum log size
- Windows 2000, Windows Server 2003: Computers that are running Windows 2000 or Windows Server 2003 may
stop responding and then may spontaneously restart if the Audit: Shut down system immediately if unable to log security audits setting is turned on and if the security log is full and if an
existing event log entry cannot be overwritten. When the computer restarts, the
following Stop error message appears:
STOP: C0000244
{Audit Failed}
An attempt to generate a security audit failed.
To recover, an administrator must log on, archive the security log (optional),
clear the security log, and then reset this option (optional and as-needed).
- Microsoft Network Client for MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Non-administrators who try to log on to a domain will receive the
following error message:
Your account is configured to
prevent you from using this computer. Please try another
computer.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
160783
Error message: Users cannot log on to a workstation
- Windows 2000: On Windows 2000-based computers, non-administrators will not be
able to log on to remote access servers, and they will receive an error message
that is similar to the following:
Unknown user or bad
password
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
285665
Error message: Your account is configured to prevent you from using this computer
- Windows 2000: On Windows 2000 domain controllers, the Intersite Messaging
service (Ismserv.exe) will stop and will not be able to be restarted. DCDIAG
will report the error as "failed test services ISMserv," and event ID 1083 will
be registered in the event log.
- Windows 2000: On Windows 2000 domain controllers, Active Directory replication
will fail, and an "Access Denied" message will appear if the security event log
is full.
- Microsoft Exchange 2000: Servers that are running Exchange 2000 will not be able to mount
the information store database, and event 2102 will be registered in the event
log.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
314294
Exchange 2000 error messages are generated because of SeSecurityPrivilege Right and Policytest issues
- Outlook, Outlook Web Access: Non-administrators will not be able to access their mail through
Microsoft Outlook or through Microsoft Outlook Web Access, and they will
receive a 503 error.
- Domain controller: LDAP server signing requirements
- Background
The Domain controller: LDAP server signing requirements security setting determines whether the Lightweight Directory
Access Protocol (LDAP) server requires LDAP clients to negotiate data signing.
The possible values for this policy setting are:
- None: Data signing is not required to bind with the server. If the
client requests data signing, the server supports it.
- Require signing: The LDAP data-signing option must be negotiated unless Transport
Layer Security/Secure Socket Layer (TLS/SSL) is being used.
- not defined: This setting is not enabled or disabled.
- Risky configurations
The following are risky configurations:
- Enabling Require signing in environments where clients do not support LDAP signing or
where client-side LDAP signing is not enabled on the client
- Applying the Windows 2000 or the Windows Server
2003 Hisecdc.inf security template in environments where the clients do not
support LDAP signing or where client-side LDAP signing is not
enabled
- Applying the Windows 2000 or the Windows Server
2003 Hisecws.inf security template in environments where the clients do not
support LDAP signing or where client-side LDAP signing is not
enabled
- Reasons to enable this setting
Unsigned network traffic is susceptible to
man-in-the-middle attacks where an intruder captures packets between the client
and the server, modifies the packets, and then forwards them to the server.
When this behavior occurs on an LDAP server, an attacker could cause a server
to make decisions that are based on false queries from the LDAP client. You can
lower this risk in a corporate network by implementing strong physical security
measures to help protect the network infrastructure. Internet Protocol security
(IPSec) authentication header mode can make man-in-the-middle attacks extremely
difficult. Authentication header mode performs mutual authentication and packet
integrity for IP traffic. - Reasons to disable this setting
- Clients that do not support LDAP signing will not
be able to carry out LDAP queries against domain controllers and against global
catalogs if NTLM authentication is negotiated and if the correct service packs
are not installed on Windows 2000 domain controllers.
- Network traces of LDAP traffic between clients and
servers will be encrypted, making it difficult to examine LDAP
conversations.
- Windows 2000-based servers must have Windows 2000
Service Pack 3 (SP3) or later installed when they are administered with
programs that support LDAP signing that are run from client computers that run
Windows 2000 SP4, Windows XP, or Windows Server 2003.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
325465
Windows 2000 domain controllers require Service Pack 3 or later when using Windows Server 2003 administration tools
- Symbolic Name: LDAPServerIntegrity
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD) - Examples of compatibility problems
- Domain member: Require strong (Windows 2000 or later) session key
- Background
- The Domain member: Require strong (Windows 2000 or later) session key setting determines whether a secure channel can be established
with a domain controller that cannot encrypt secure channel traffic with a
strong, 128-bit session key. Enabling this setting prevents establishing a
secure channel with any domain controller that cannot encrypt secure channel
data with a strong key. Disabling this setting allows 64-bit session keys.
- Before you can enable this setting on a member
workstation or on a server, all domain controllers in the domain that the
member belongs to must be able to encrypt secure channel data with a strong,
128-bit key. This means that all such domain controllers must be running
Windows 2000 or later.
- Risky configuration
Enabling the Domain member: Require strong (Windows 2000 or later) session key setting is a risky configuration. - Reasons to enable this setting
- Session keys that are used to establish secure
channel communications between member computers and domain controllers are much
stronger in Windows 2000 than they are in earlier versions of Microsoft
operating systems.
- Whenever possible, it is a good idea to take
advantage of these stronger session keys to help protect secure channel
communications from eavesdropping and from session hijacking network attacks. Eavesdropping is a form of malicious attack where network data is read or is
altered in transit. The data can be modified to hide or to change the sender,
or to redirect it.
- Reasons to disable this setting
The domain contains member computers that are running
operating systems other than Windows 2000, Windows XP, or Windows Server
2003. - Symbolic Name: StrongKey
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD) - Examples of compatibility problems
Windows NT 4.0: On Windows NT 4.0-based computers, resetting secure channels of
trust relationships between Windows NT 4.0 and Windows 2000 domains with NLTEST
fails with "Access Denied" error message:The trust
relationship between the primary domain and the trusted domain
failed.
- Domain member: Digitally encrypt or sign secure channel data (always)
- Background
- Enabling Domain member: Digitally encrypt or sign secure channel data (always) prevents establishing a secure channel with any domain controller
that cannot sign or encrypt all secure channel data. To help protect
authentication traffic from man-in-the-middle attacks, from replay attacks, and
from other types of network attacks, Windows-based computers create a
communication channel that is known as a secure channel through the Net Logon service to authenticate computer accounts.
Secure channels are also used when a user in one domain connects to a network
resource in a remote domain. This multi-domain authentication, or pass-through authentication, allows a Windows-based computer that has joined a domain to have
access to the user account database in its domain and in any trusted domains.
- To enable the Domain member: Digitally encrypt or sign secure channel data (always) setting on a member computer, all domain controllers in the
domain that the member belongs to must be able to sign or to encrypt all secure
channel data. This means that all such domain controllers must be running
Windows NT 4.0 with Service Pack 6a (SP6a) or later.
- Enabling the Domain member: Digitally encrypt or sign secure channel data (always) setting automatically enables the Domain member: Digitally encrypt or sign secure channel data (when possible) setting.
- Risky configuration
Enabling the Domain member: Digitally encrypt or sign secure channel data (always) setting in domains where not all domain controllers can sign or
encrypt secure channel data is a risky configuration. - Reasons to enable this setting
Unsigned network traffic is susceptible to
man-in-the-middle attacks, where an intruder captures packets between the
server and the client and then modifies them before forwarding them to the
client. When this behavior occurs on an Lightweight Directory Access Protocol
(LDAP) server, the intruder could cause a client to make decisions that are
based on false records from the LDAP directory. You can lower the risk of such
an attack on a corporate network by implementing strong physical security
measures to help protect the network infrastructure. Additionally, implementing
Internet Protocol security (IPSec) authentication header mode can make all
kinds of man-in-the-middle attacks extremely difficult. This mode performs
mutual authentication and packet integrity for IP traffic. - Reasons to disable this setting
- Computers in local or in external domains do
support encrypted secure channels.
- Not all domain controllers in the domain have the
appropriate service pack revision levels to support encrypted secure
channels.
- Symbolic Name: StrongKey
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD) - Examples of compatibility problems
- Windows NT 4.0: Windows 2000-based member computers will not be able to join
Windows NT 4.0 domains and will receive the following error message:
The account is not authorized to log in from this
station.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
281648
Error message: The account is not authorized to login from this station
- Windows NT 4.0: Windows NT 4.0 domains will not be able to establish a down-level
trust with a Windows 2000 domain and will receive the following error message:
The account is not authorized to log in from this
station. Existing down-level trusts may also not authenticate users
from the trusted domain. Some users may have difficulty logging on to the
domain, and they may receive an error message that states that the client
cannot find the domain. - Windows XP: Windows XP clients that are joined to Windows NT 4.0 domains will
not be able to authenticate logon attempts and may receive the following error
message, or the following events may be registered in the event log:
Windows cannot connect to the domain either because the
domain controller is down or is otherwise unavailable or because your computer
account was not found Event
5723: The session setup from computer ComputerName
failed to authenticate. The name of the account referenced in the security
database is ComputerName. The following error
occurred: Access is denied.Event 3227: The session setup to the Windows NT or the Windows
2000 domain controller Server Name for the domain
Domain Name failed because Server
Name does not support signing or sealing the Netlogon session.
Upgrade the domain controller, or set the RequireSignOrSeal registry entry on
this computer to 0.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
318266
A Windows XP client cannot log on to a Windows NT 4.0 domain
- Microsoft Network: Microsoft Network clients will receive one of the following error
messages:
Logon failure: unknown username or bad
password. There is no user session key for the
specified logon session.
- Microsoft network client: Digitally sign communications (always)
- Background
Server Message Block (SMB) is the resource-sharing protocol that is supported by many
Microsoft operating systems; it is the basis of network basic input/output
system (NetBIOS) and of many other protocols. SMB signing authenticates both
the user and the server that hosts the data. If either side fails the
authentication process, data transmission will not occur.
Enabling SMB signing starts during SMB protocol negotiation. The SMB signing policies determine whether the computer always digitally signs client communications.
The Windows 2000 SMB authentication protocol supports mutual authentication. Mutual authentication closes a "man-in-the-middle" attack. The Windows 2000 SMB authentication protocol also supports
message authentication. Message authentication helps prevent active message attacks.
To give you this authentication, SMB signing puts a digital signature into each SMB. The client and the server each verify the digital signature.
To use SMB signing, you must enable SMB signing or require SMB signing on both the SMB client and the SMB server.
If SMB signing is enabled on a server, clients that are also enabled for SMB signing use the packet signing protocol during all subsequent sessions.
If SMB signing is required on a server, a client cannot establish a session unless the client is enabled or required for SMB signing.
Enabling digital signing in high-security networks
helps to prevent the impersonation of clients and of servers. This type of
impersonation is known as session hijacking. An attacker who has access to the same network as the client or
the server uses session hijacking tools to interrupt, end, or steal a session
in progress. An attacker could intercept and modify unsigned SMB packets, modify the traffic, and then forward it so that the
server might perform unwanted actions. Alternatively, the attacker could pose
as the server or as the client after a legitimate authentication and then gain
unauthorized access to data.
The SMB protocol that is used for
file sharing and for print sharing in computers that are running Windows 2000
Server, Windows 2000 Professional, Windows XP Professional, or Windows Server
2003 supports mutual authentication. Mutual authentication closes session
hijacking attacks and supports message authentication. Therefore, it prevents
man-in-the-middle attacks. SMB signing provides this authentication by placing
a digital signature in each SMB. The signature is then verified by both the
client and the server.
Notes- An alternative countermeasure that may help protect all network
traffic is to enable digital signatures with IPSec. There are hardware-based
accelerators for IPSec encryption and signing that can be used to minimize the
performance impact from the server's CPU. There are no such accelerators that
are available for SMB signing.
For more information, see the "Digitally sign server communications" chapter on the following Microsoft MSDN Web site:Configure SMB signing through Group Policy Object Editor because a change to a local registry value has no effect if there is an overriding domain policy. - In Windows 95, Windows 98, and Windows 98 Second Edition, the Directory Services Client uses SMB signing when it authenticates with Windows Server 2003 servers by using NTLM authentication. However, these clients do not use SMB signing when they authenticate with these servers by using NTLMv2 authentication. Additionally, Windows 2000 servers do not respond to SMB signing requests from these clients. See item 10: "Network security: Lan Manager authentication level."
- Risky configuration
The following is a risky configuration: Leaving both
the Microsoft network client: Digitally sign communications (always) setting and the Microsoft network client: Digitally sign communications (if server agrees) setting set to "Not Defined" or disabled. These settings allow
the redirector to send plain text passwords to non-Microsoft SMB servers that
do not support password encryption during authentication. - Reasons to enable this setting
Enabling Microsoft network client: Digitally sign communications (always) requires clients to sign SMB traffic when contacting servers that
do not require SMB signing, making clients less vulnerable to session hijacking
attacks. - Reasons to disable this setting
- Enabling Microsoft network client: Digitally sign communications (always) prevents clients from communicating with target servers that do
not support SMB signing
- Configuring computers to ignore all unsigned SMB
communications prevents earlier programs and operating systems from
connecting.
- Symbolic Name: RequireSMBSignRdr
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature - Examples of compatibility problems
- Restart requirements
Restart the computer, or restart the Workstation service. To do this, type the following commands at a command prompt. Press ENTER after you type each command. net stop workstation
net start workstation
- Microsoft network server: Digitally sign communications (always)
- Background
- Server Messenger Block (SMB) is the resource-sharing protocol that is supported by many
Microsoft operating systems; it is the basis of network basic input/output
system (NetBIOS) and of many other protocols. SMB signing authenticates both
the user and the server that hosts the data. If either side fails the
authentication process, data transmission will not occur.
Enabling SMB signing starts during SMB protocol negotiation. The SMB signing policies determine whether the computer always digitally signs client communications.
The Windows 2000 SMB authentication protocol supports mutual authentication. Mutual authentication closes a "man-in-the-middle" attack. The Windows 2000 SMB authentication protocol also supports
message authentication. Message authentication helps prevent active message attacks.
To give you this authentication, SMB signing puts a digital signature into each SMB. The client and the server each verify the digital signature.
To use SMB signing, you must enable SMB signing or require SMB signing on both the SMB client and the SMB server.
If SMB signing is enabled on a server, clients that are also enabled for SMB signing use the packet signing protocol during all subsequent sessions.
If SMB signing is required on a server, a client cannot establish a session unless the client is enabled or required for SMB signing.
Enabling digital signing in high-security networks
helps to prevent the impersonation of clients and of servers. This type of
impersonation is known as session hijacking. An attacker who has access to the same network as the client or
the server uses session hijacking tools to interrupt, end, or steal a session
in progress. An attacker could intercept and modify unsigned Subnet Bandwidth
Manager (SBM) packets, modify the traffic, and then forward it so that the
server might perform unwanted actions. Alternatively, the attacker could pose
as the server or as the client after a legitimate authentication and then gain
unauthorized access to data.
The SMB protocol that is used for
file sharing and for print sharing in computers that are running Windows 2000
Server, Windows 2000 Professional, Windows XP Professional, or Windows Server
2003 supports mutual authentication. Mutual authentication closes session
hijacking attacks and supports message authentication. Therefore, it prevents
man-in-the-middle attacks. SMB signing provides this authentication by placing
a digital signature in each SMB. The signature is then verified by both the
client and the server. - An alternative countermeasure that may help protect
all network traffic is to enable digital signatures with IPSec. There are
hardware-based accelerators for IPSec encryption and signing that can be used
to minimize the performance impact from the server's CPU. There are no such
accelerators that are available for SMB signing.
- In Windows 95, Windows 98, and Windows 98 Second Edition, the Directory Services Client uses SMB signing when it authenticates with Windows Server 2003 servers by using NTLM authentication. However, these clients do not use SMB signing when they authenticate with these servers by using NTLMv2 authentication. Additionally, Windows 2000 servers do not respond to SMB signing requests from these clients. See item 10: "Network security: Lan Manager authentication level."
- Risky configuration
The following is a risky configuration: Enabling the Microsoft network server: Digitally sign communications (always) setting on servers and on domain controllers that are accessed by
incompatible Windows-based and third-party operating system-based client
computers in local or in external domains. - Reasons to enable this setting
- All client computers that enable this setting
directly through the registry or through the Group Policy setting support SMB
signing. In other words, all client computers that have this setting enabled
run either Windows 95 with the DS client installed, Windows 98, Windows NT 4.0,
Windows 2000, Windows XP Professional, or Windows Server 2003.
- If Microsoft network server: Digitally sign communications (always) is disabled, SMB signing is completely disabled. Completely
disabling all SMB signing leaves computers more vulnerable to session hijacking
attacks.
- Reasons to disable this setting
- Enabling this setting may cause slower file copy
and network performance on client computers.
- Enabling this setting will prevent clients that
cannot negotiate SMB signing from communicating with servers and with domain
controllers. This causes operations such as domain joins, user and computer
authentication, or network access by programs to fail.
- Symbolic Name: RequireSMBSignServer
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD) - Examples of compatibility problems
- Windows 95: Windows 95 clients that do not have the Directory Services (DS)
Client installed will fail logon authentication and will receive the following
error message:
The domain password you supplied is not
correct, or access to your logon server has been denied.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
811497
Error message when Windows 95 or Windows NT 4.0 client logs on to Windows Server 2003 domain
- Windows NT 4.0: Client computers that are running versions of Windows NT 4.0 that
are earlier than Service Pack 3 (SP3) will fail logon authentication and will
receive the following error message:
The system could not
log you on. Make sure your username and your domain are correct, then type your
password again. Some non-Microsoft SMB servers support only unencrypted password exchanges during authentication. (These exchanges also known as "plain text" exchanges.) Beginning with Windows NT 4.0 SP3, the SMB redirector does not send an unencrypted password during authentication to an SMB server unless you add a specific registry entry.
To enable unencrypted passwords for the SMB client on Windows NT 4.0 SP 3 and newer systems, modify the registry as follows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters
Value Name: EnablePlainTextPassword
Data Type: REG_DWORD
Data: 1
For more information about related topics, click the following article numbers to view the articles in the Microsoft Knowledge Base:
224287
Error message: System error 1240 has occurred. The account is not authorized to login from this station.
166730 Unencrypted passwords may cause Service Pack 3 to fail to connect to SMB servers
- Windows Server 2003: By default, security settings on domain controllers that run Windows Server 2003 are configured to help prevent domain controller communications from being intercepted or tampered with by malicious users. For users to successfully communicate with a domain controller that runs Windows Server 2003, client computers must use both SMB signing and encryption or secure channel traffic signing. By default, clients that run Windows NT 4.0 with Service Pack 2 (SP2) or earlier installed and clients that run Windows 95 do not have SMB packet signing enabled. Therefore, these clients may not be able to authenticate to a Windows Server 2003-based domain controller.
- Windows 2000 and Windows Server 2003 policy settings: Depending on your specific installation needs and configuration, we recommend that you set the following policy settings at the lowest entity of necessary scope in the Microsoft Management Console Group Policy Editor snap-in hierarchy:
- Computer Configuration\Windows Security Settings\Security Options
- Send unencrypted password to connect to third-party SMB servers (This setting is for Windows 2000.)
- Microsoft network client: Send unencrypted password to third-party SMB servers (This setting is for Windows Server 2003.)
Note In some third-party CIFS servers, such as older Samba versions, you cannot use encrypted passwords. - The following clients are incompatible with the Microsoft network server: Digitally sign communications (always) setting:
- Apple Computer, Inc., Mac OS X
clients
- Microsoft MS-DOS network clients (for example,
Microsoft LAN Manager)
- Microsoft Windows for Workgroups
clients
- Microsoft Windows 95 clients without the DS
Client installed
- Microsoft Windows NT 4.0-based computers
without SP3 or later installed
- Novell Netware 6 CIFS clients
- SAMBA SMB clients that lack support for SMB
signing
- Restart requirements
Restart the computer, or restart the Server service. To do this, type the following commands at a command prompt. Press ENTER after you type each command. net stop server
net start server
- Network access: Allow anonymous SID/Name translation
- Background
The Network access: Allow anonymous SID/Name translation security setting determines whether an anonymous user can request
Security Identification Number (SID) attributes for another user. - Risky configuration
Enabling the Network access: Allow anonymous SID/Name translation setting is a risky configuration. - Reasons to enable this setting
If the Network access: Allow anonymous SID/Name translation setting is disabled, earlier operating systems or applications
may not be able to communicate with Windows Server 2003 domains. For example,
the following operating systems, services, or applications may not work:
- Windows NT 4.0-based Remote Access Service
servers
- Microsoft SQL Server that are running on Windows NT
3.x-based or on Windows NT 4.0-based computers
- Remote Access Service that is running on Windows
2000-based computers that are located in Windows NT 3.x domains or in Windows
NT 4.0 domains
- SQL Server that is running on Windows 2000-based
computers that are located in Windows NT 3.x domains or in Windows NT 4.0
domains
- Users in Windows NT 4.0 resource domain who want to
grant permissions to access files, shared folders, and registry objects to user
accounts from account domains that contain Windows Server 2003 domain
controllers
- Reasons to disable this setting
If this setting is enabled, a malicious user could use
the well-known Administrators SID to obtain the real name of the built-in
Administrator account, even if the account has been renamed. That person could
then use the account name to initiate a password-guessing attack. - Symbolic Name: N/A
- Registry Path: None. The path is specified in UI code.
- Examples of compatibility problems
Windows NT 4.0: Computers in Windows NT 4.0 resource domains will display the
"Account Unknown" error message in ACL Editor if resources, including shared
folders, shared files, and registry objects, are secured with security
principals that reside in account domains that contain Windows Server 2003
domain controllers.
- Network access: Do not allow anonymous enumeration of SAM accounts
- Background
- The Network access: Do not allow anonymous enumeration of SAM accounts setting determines which additional permissions will be granted
for anonymous connections to the computer. Windows allows anonymous users to
perform certain activities, such as enumerating the names of domain Security
Accounts Manager (SAM) accounts and of 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, an anonymous user
has the same access that is granted to the Everyone group for a particular
resource. Typically, anonymous connections are requested by earlier-version, or downlevel, clients during SMB session setup. In these cases, a network trace shows that the SMB Process ID (PID) is the client redirector, 0xFEFF in Windows 2000 or 0xCAFE in Windows NT. RPC may also try to make anonymous connections.
- This setting has no impact on domain
controllers.
- In Windows 2000, a similar setting, Additional Restrictions for Anonymous Connections, manages the RestrictAnonymous registry value. The
location of this value is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
For more information about the RestrictAnonymous registry value, click the following article numbers to view the articles in the Microsoft Knowledge Base:
246261
How to use the RestrictAnonymous registry value in Windows 2000
143474 Restricting information available to anonymous logon users
- Risky configurations:
Enabling the Network access: Do not allow anonymous enumeration of SAM accounts setting is a risky configuration from a compatibility
perspective; disabling it is a risky configuration from a security
perspective. - Reasons to enable this setting
An unauthorized user could anonymously list account
names and then use the information to try to guess passwords or to perform social engineering attacks. Social engineering is jargon that means tricking people into revealing their
passwords or some form of security information. - Reasons to disable this setting
If this setting is enabled, it is impossible to
establish trusts with Windows NT 4.0 domains. This setting will also cause
problems with down-level clients such as Windows NT 3.51 clients and Windows 95
clients that are trying to use resources on the server. - Symbolic Name: RestrictAnonymousSAM
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD) - Examples of compatibility problems
- SMS Network Discovery will not be able to obtain
operating system information and will write "Unknown" in the
OperatingSystemNameandVersion property.
- Windows 95, Windows 98: Windows 95 clients and Windows 98 clients will not be able to
change their passwords.
- Windows NT 4.0: Windows NT 4.0-based member computers will not be able to be
authenticated.
- Windows 95, Windows 98: Windows 95-based and Windows 98-based computers will not be able
to be authenticated by Microsoft domain controllers.
- Windows 95, Windows 98: Users on Windows 95-based and Windows 98-based computers will not
be able to change the passwords for their user accounts.
- Network access: Do not allow anonymous enumeration of SAM accounts and shares
- Background
- The Network access: Do not allow anonymous enumeration of SAM accounts and shares setting (also known as RestrictAnonymous) determines whether anonymous enumeration of Security Accounts
Manager (SAM) accounts and shares is allowed. Windows allows anonymous users to
perform certain activities, such as enumerating the names of domain accounts
(users, computers, and groups) and of 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 of shares, enable this setting.
- In Windows 2000, a similar setting, Additional Restrictions for Anonymous Connections, manages the RestrictAnonymous registry value. The
location of this value is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
- Risky configuration
Enabling the Network access: Do not allow anonymous enumeration of SAM accounts and shares setting is a risky configuration. - Reasons to enable this setting
- Enabling the Network access: Do not allow anonymous enumeration of SAM accounts and shares setting prevents enumeration of SAM accounts and shares by users
and computers that are using anonymous accounts.
- Reasons to disable this setting
- If this setting is enabled, an unauthorized user
could anonymously list account names and then use the information to try to
guess passwords or to perform social engineering attacks. Social engineering is jargon that means tricking people into revealing their
password or some form of security information.
- If this setting is enabled, it will be impossible
to establish trusts with Windows NT 4.0 domains. This setting will also cause
problems with down-level clients such as Windows NT 3.51 and Windows 95 clients
that are trying to use resources on the server.
- It will be impossible to grant access to users of
resource domains because administrators in the trusting domain will not be able
to enumerate lists of accounts in the other domain. Users who access file and
print servers anonymously will not be able to list the shared network resources
on those servers; the users must authenticate before they can view the lists of
shared folders and printers.
- Symbolic Name: RestrictAnonymous
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous - Examples of compatibility problems
- Network security: Lan Manager authentication level
- Background
LAN Manager (LM) authentication is the protocol that is
used to authenticate Windows clients for network operations, including domain
joins, accessing network resources, and user or computer authentication. The LM
authentication level determines which challenge/response authentication
protocol is negotiated between the client and the server computers.
Specifically, the LM authentication level determines which authentication
protocols that the client will try to negotiate or that the server will accept. The value that is set for LmCompatibilityLevel determines which challenge/response authentication protocol is used for network logons. This value affects the level of authentication protocol that clients use, the level of session security negotiated, and the level of authentication accepted by servers, according to the following table:
Possible settings include the following.|
| 0 | Send LM & NTLM responses | Clients use LM and NTLM authentication and never use NTLMv2
session security; domain controllers accept LM, NTLM, and NTLMv2
authentication. | | 1 | Send 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. | | 2 | Send 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. | | 3 | Send 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. | | 4 | Send NTLMv2 response only/refuse LM | Clients use NTLMv2 authentication only and use NTLMv2 session
security if the server supports it. Domain controllers refuse LM and accept
only NTLM and NTLMv2 authentication). | | 5 | Send 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 (they
accept only NTLMv2 authentication). |
Note In Windows 95, Windows 98, and Windows 98 Second Edition, the Directory Services Client uses SMB signing when it authenticates with Windows Server 2003 servers by using NTLM authentication. However, these clients do not use SMB signing when they authenticate with these servers by using NTLMv2 authentication. Additionally, Windows 2000 servers do not respond to SMB signing requests from these clients.
Check the LM authentication level You must change the policy on the server to permit NTLM, or you must configure the client computer to support NTLMv2.
If the policy is set to (5) Send NTLMv2 response only\refuse LM & NTLM on the target computer that you want to connect to, you must either lower the setting on that computer or set the security to the same setting that is on the source computer that you are connecting from.
Find the correct location where you can change the LAN manager authentication level to set the client and the server to the same level. After you find the policy that is setting the LAN manager authentication level, if you want to connect to and from computers that are running earlier versions of Windows, lower the value to at least (1) Send LM & NTLM - use NTLM version 2 session security if negotiated.
For example, you may have to look on the domain controller, or you may have to look at the domain controller's policies.
Look on the domain controller
Note You may have to repeat the following procedure on all the domain controllers.- Click Start, point to Programs, and then click Administrative Tools.
- Under Local Security Settings, expand Local Policies.
- Click Security Options.
- Double-click Network Security: LAN manager authentication level, and then click an appropriate value in the list.
If the Effective Setting and the Local Setting are the same, the policy has been changed at this level. If the settings are different, you must check the domain controller's policy to find out whether the Network Security: LAN manager authentication level setting is defined there. If it is not defined there, look at the domain controller's policies.
Look at the domain controller's policies- Click Start, point to Programs, and then click Administrative Tools.
- In the Domain Controller Security policy, expand Security Settings, and then expand Local Policies.
- Click Security Options.
- Double-click Network Security: LAN manager authentication level, and then click an appropriate value in the list.
Note- You may also have to check policies that are linked at the site level, at the domain level, or at the organizational unit (OU) level to determine where you must configure the LAN manager authentication level.
- If you implement a Group Policy setting as the default domain policy, the policy is applied to all the computers in the domain.
- If you implement a Group Policy setting as the default domain controller's policy, the policy applies only to the servers in the domain controller's OU.
- It is a good idea to set the LAN manager authentication level in the lowest entity of necessary scope in the policy application hierarchy.
Refresh the policy after you make any changes. (If the change is at the local security settings level, the change is immediate. However, you must restart the clients before you test.)
By default, Group Policy settings are updated on domain controllers every five minutes. To immediately force the update of the policy settings on Windows 2000 or later, use the gpupdate command.
The gpupdate /force command updates local Group Policy settings and Group Policy settings that are based on Active Directory directory service, including security settings. This command supersedes the now obsolete /refreshpolicy option for the secedit command.
The gpupdate command uses the following syntax:
gpupdate [/target:{computer|user}] [/force] [/wait:value] [/logoff] [/boot]
Apply the new Group Policy object (GPO) by using the gpupdate command to manually reapply all policy settings. To do this, type the following at the command prompt, and then press ENTER:
GPUpdate /Force
Look at the application event log to make sure that the policy setting was applied successfully.
On Windows XP and Windows Server 2003, you can use the Resultant Set of Policy snap-in to see the effective setting. To do so, click Start, click Run, type rsop.msc, and then click OK.
If the issue persists after you make the change to the policy, restart the Windows-based server, and then verify that the issue is resolved.
Note If you have multiple Windows 2000-based domain controllers, Windows Server 2003-based domain controllers, or both, you may have to replicate the Active Directory to make sure that these domain controllers have the updated changes immediately.
Alternatively, the setting may appear to be set to the lowest setting in the local security policy. If you can enforce the setting by means of a security database, you can alternatively set the LAN manager authentication level in the registry by editing the LmCompatibilityLevel entry in the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
Windows Server 2003 has a new default setting to use NTLMv2 only. By default, Windows Server 2003 and Windows 2000 Server SP3-based domain controllers have enabled the "Microsoft network server: Digitally sign communications (always)" policy. This setting requires the SMB server to perform SMB packet signing.
Changes to Windows Server 2003 were made because domain controllers, file servers, network infrastructure servers, and Web servers in any organization require different settings to maximize their security.
If you want to implement NTLMv2 authentication in your network, you must make sure that all the computers in the domain are set to use this authentication level. If you apply Active Directory Client Extensions for Windows 95 or Windows 98 and Windows NT 4.0, the client extensions use the improved authentication features that are available in NTLMv2.
Because client computers that are running any of the following operating system are not affected by Windows 2000 Group Policy objects, you may have to manually configure these clients:- Microsoft Windows NT 4.0
- Microsoft Windows Millennium Edition
- Microsoft Windows 98
- Microsoft Windows 95
Note If you enable the Network security: Do not store LAN manager hash value on next password change policy or set the NoLMHash registry key, Windows 95-based and Windows 98-based clients that do not have the Directory Services Client installed cannot log on to the domain after a password change.
Many third-party CIFS servers, such as Novell Netware 6, are not aware of NTLMv2 and use NTLM only. Therefore, levels greater than 2 do not permit connectivity.
For more information about how to manually configure the LAN manager authentication level, click the following article numbers to view the articles in the Microsoft Knowledge Base:
147706
How to disable LM authentication on Windows NT
175641 LMCompatibilityLevel and its effects
299656 How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases
312630 Outlook continues to prompt you for logon credentials
239869
How to enable NTLM 2 authentication
- Risky configurations
The following are risky configurations:
- Reasons to Modify This Setting
- You want to increase the lowest common
authentication protocol that is supported by clients and domain controllers in
your organization.
- Where secure authentication is a business
requirement, you want to disallow negotiation of the LM and the NTLM
protocols.
- Reasons to disable this setting
Client or server authentication requirements, or both,
have been increased to the point where authentication over a common protocol
cannot occur. - Symbolic Name: LmCompatibilityLevel
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel - Examples of compatibility problems
- Windows Server 2003: By default, the Windows Server 2003 NTLMv2 Send NTLM responses setting is enabled. Therefore, Windows Server 2003 receives the "Access Denied" error message after the initial installation when you try to connect to a Windows NT 4.0-based cluster or to LanManager V2.1-based servers, such as OS/2 Lanserver. This issue also occurs if you try to connect from an earlier-version client to a Windows Server 2003-based server.
- You install Windows 2000 Security Rollup Package 1 (SRP1).SRP1 forces NTLM version 2 (NTLMv2). This rollup package was released after the release of Windows 2000 Service Pack 2 (SP2). For more information about SRP1, click the following article number to view the article in the Microsoft Knowledge Base:
311401 Windows 2000 Security Rollup Package 1 (SR311401 ), January 2002
- Microsoft Outlook clients may be prompted for credentials even though they are already logged on to the domain. When users supply their credentials, they receive the following error message:
The logon credentials supplied were incorrect. Make sure your username and domain are correct, then type your password again.
When you start Outlook, you may be prompted for your credentials even if your Logon Network Security setting is set to Passthrough or to Password Authentication. After you type your correct credentials, you may receive the following error message:
The login credentials supplied were incorrect.
A Network Monitor trace may show that the global catalog issued a remote procedure call (RPC) fault with a status of 0x5. A status of 0x5 means "Access Denied." - Windows 2000: A Network Monitor capture may show the following errors in the NetBIOS over TCP/IP (NetBT) server message block (SMB) session:
SMB R Search Directory Dos error, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Invalid user identifier
- Windows 2000: If a Windows 2000 domain with NTLMv2 Level 2 or later is trusted
by a Windows NT 4.0 domain, Windows 2000-based member computers in the resource
domain may experience authentication errors.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
305379
Authentication problems in Windows 2000 with NTLM 2 levels above 2 in a Windows NT 4.0 domain
- Windows 2000 and Windows XP: By default, Windows 2000 and Windows XP set the LAN Manager Authentication Level Local Security Policy option to 0. A setting of 0 means "Send LM and NTLM responses."
Note Windows NT 4.0-based clusters must use LM for administration. - Windows 2000: Windows 2000 clustering does not authenticate a joining node if
both nodes are part of a Windows NT 4.0 Service Pack 6a (SP6a) domain.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
305379
Authentication problems in Windows 2000 with NTLM 2 levels above 2 in a Windows NT 4.0 domain
- The IIS Lockdown Tool (HiSecWeb) sets the LMCompatibilityLevel value to 5 and the RestrictAnonymous value to 2.
- Services for Macintosh
User Authentication Module (UAM)The Microsoft UAM (User Authentication Module) provides a method for encrypting the passwords that you use to log on to Windows AFP (AppleTalk Filing Protocol) servers.
The Apple User Authentication Module (UAM) provides only minimal or no encryption. Therefore, your password could easily be intercepted on the LAN or on the Internet.
Although the UAM is not required, it does provide encrypted authentication to Windows 2000 Servers that run Services For Macintosh.
This version includes support for NTLMv2 128-bit encrypted authentication and a MacOS X 10.1-compatible release.
By default, the Windows Server 2003 Services for Macintosh server permits only Microsoft Authentication.
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
834498
Macintosh client cannot connect to Services for Mac on Windows Server 2003
838331 Mac OS X users cannot open Macintosh shared folders on a Windows Server 2003-based server
- Network security: LDAP client signing requirements
- Background
The Network security: LDAP client signing requirements setting determines the level of data signing that is requested on
behalf of clients that issue Lightweight Directory Access Protocol (LDAP) BIND
requests as follows:
- None: The LDAP BIND request is issued with the caller-specified
options.
- Negotiate signing: If the Secure Sockets Layer/Transport Layer Security (SSL/TLS)
has not been started, the LDAP BIND request is initiated with the LDAP data
signing option set in addition to the caller-specified options. If SSL/TLS has
been started, the LDAP BIND request is initiated with the caller-specified
options.
- Require signing: 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.
- Risky configuration
Enabling the Network security: LDAP client signing requirements setting is a risky configuration. If you set the server to
require LDAP signatures, you must also configure LDAP signing on the client.
Not configuring the client to use LDAP signatures will prevent communication
with the server; this will cause user authentication, Group Policy settings,
logon scripts, and other features to fail. - Reasons to Modify This Setting
Unsigned network traffic is susceptible to
man-in-the-middle attacks where an intruder captures packets between the client
and the servers, modifies them, and then forwards them to the server. When this
occurs on an LDAP server, an attacker could cause a server to respond based on
false queries from the LDAP client. You can lower this risk in a corporate
network by implementing strong physical security measures to help protect the
network infrastructure. Additionally, all kinds of man-in-the-middle attacks
can be made extremely difficult by requiring digital signatures on all network
packets by means of IPSec authentication headers. - Symbolic Name: LDAPClientIntegrity
- Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
- Event Log: Maximum security log size
- Background
The Event Log: Maximum security log size security setting specifies the maximum size of the security event
log. This log has a maximum size of 4 GB. To locate this setting, expand
Windows Settings, and then expand Security
Settings. - Risky configurations
The following are risky configurations:
- Restricting the security log size and the security
log retention method when the Audit: Shut down system immediately if unable to log security audits setting is enabled. See the "Audit: Shut down system immediately if unable to log security audits" section of this article for more details.
- Restricting the security log size so that security
events of interest are overwritten.
- Reasons to Increase This Setting
Business and security requirements may dictate that you
increase the security log size to handle additional security log detail or to
retain security logs for a longer period of time. - Reasons to Decrease This Setting
Event Viewer logs are memory mapped files. The maximum
size of an event log is constrained by the amount of physical memory in the
local computer and by the virtual memory that is available to the event log
process. Increasing the log size beyond the amount of virtual memory that is
available to Event Viewer does not increase the number of log entries that are
maintained. - Examples of compatibility problems
Windows 2000: Computers that are running versions of Windows 2000 that are
earlier than Service Pack 4 (SP4) may stop logging events in the event log before
reaching the size that is specified in the Maximum log size setting in Event Viewer if the Do not overwrite events (clear log manually) option is turned on.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
312571
The Event Log stops logging events before reaching the maximum log size
- Event Log: Retain security log
- Background
The Event Log: Retain security log security setting determines the "wrapping" method for the
security log. To locate this setting, expand Windows Settings,
and then expand Security Settings. - Risky configurations
The following are risky configurations:
- Failing to retain all logged security events before
they are overwritten
- Configuring the Maximum security log size setting too small so that security events are
overwritten
- Restricting the security log size and retention
method while the Audit: Shut down system immediately if unable to log security audits security setting is enabled
- Reasons to enable this setting
Unsigned network traffic is susceptible to
man-in-the-middle attacks where an intruder captures packets between the client
and the servers, modifies them, and then forwards them to the server. When this
occurs on an LDAP server, an attacker could cause a server to respond based on
false queries from the LDAP client. You can lower this risk in a corporate
network by implementing strong physical security measures to help protect the
network infrastructure. Additionally, all kinds of man-in-the-middle attacks
can be made extremely difficult by requiring digital signatures on all network
packets by means of IPSec authentication headers.
- Network access: Let Everyone permissions apply to anonymous users
- Background
By default, the Network access: Let Everyone permissions apply to anonymous users setting is set to Not Defined on Windows Server 2003. By default, Windows Server 2003 does not include the Anonymous Access token in the Everyone group. - Example of Compatibility Problems
The following value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous - Reasons to Modify This Setting
The value must be set to 0x1 or set by using a GPO on the domain controller's OU to be: Network access: Let Everyone permissions apply to anonymous users - Enabled to make the trust creations possible.
Note Most other security settings go up in value instead of down to 0x0 in their most secured state. A more secure practice would be to change the registry on the primary domain controller emulator instead of on all the domain controllers. If the primary domain controller emulator role is moved for any reason, the registry must be updated on the new server.
A restart is required after this value is set. - Registry Path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
NTLMv2 authenticationSession securitySession security determines the minimum security standards for client and server sessions. It is a good idea to verify the following security policy settings in the Microsoft Management Console Group Policy Editor snap-in:- Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options
- Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers
- Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients
The options for these settings are:- Require message integrity
- Require message confidentiality
- Require NTLM version 2 session security
- Require 128-bit encryption
The default setting is No requirements.
These policies determine the minimum security standards for an application-to-application communications session on a serverfor a client.
Historically, Windows NT has supported the following two variants of challenge/response authentication for network logons: - LM challenge/response
- NTLM version 1 challenge/response
LM allows interoperability with the installed base of clients and servers. NTLM provides improved security for connections between clients and servers.
The corresponding registry keys are the following:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"
Time synchronizationTime synchronization failed. The time is off by more then 30 minutes on an affected computer. Make sure that the client computer's clock is synchronized with the domain controller's clock. Workaround for SMB signingIf Windows NT 4.0-based clients do not have Windows NT 4.0 Service Pack 6 (SP6) installed or if Windows 95,98, 98SE-based clients do not have the Directory Service Client installed, you can disable SMB signing in the default domain controller's policy setting on the domain controller's OU and then link this policy to all OUs that host domain controllers. We recommend that you install Service Pack 6a (SP6a) on Windows NT 4.0 clients that interoperate in a Windows Server 2003-based domain. Windows 98 Second Edition, Windows 98 and Windows 95 clients must run the Directory Services Client to perform NTLMv2. The Directory Services Client for Windows 98 Second Edition, Windows 98 and Windows 95 will perform SMB Signing with Windows 2003 servers under NTLM authentication, but not under NTLMv2 authentication. Additionally, Windows 2000 servers will not respond to SMB Signing requests from these clients. Although Microsoft does not recommend it, you can prevent SMB signing from being required on all domain controllers that run Windows Server 2003 in a domain. To configure this security setting, follow these steps: - Open the default domain controller's policy.
- Open the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options folder.
- Locate and then click the Microsoft network server: Digitally sign communications (always) policy setting, and then click Disabled.
Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk. Alternatively, turn off SMB signing on the server by modifying the registry. To do this, follow these steps: - Click Start, click Run, type regedit, and then click OK.
- Locate and then click the following subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters - Click the enablesecuritysignature entry.
- On the Edit menu, click Modify.
- In the Value data box, type 0, and then click OK.
- Quit Registry Editor.
- Restart the computer, or stop, and then restart the Server service. To do so, type the following commands at a command prompt, and press ENTER after you type each command:
net stop server
net start server
Note The corresponding key on the client computer is in the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters The following lists the translated the error code numbers to status codes and to the verbatim error message text that are mentioned earlier: error 5
ERROR_ACCESS_DENIED
Access is denied. error 1326
ERROR_LOGON_FAILURE
Logon failure: unknown user name or bad password. error 1788
ERROR_TRUSTED_DOMAIN_FAILURE
The trust relationship between the primary domain and the trusted domain failed. error 1789
ERROR_TRUSTED_RELATIONSHIP_FAILURE
The trust relationship between this workstation and the primary domain failed.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
324802
How to configure Group Policies to set security for system services in Windows Server 2003
306771 "Access denied" error message after you configure a Windows Server 2003 cluster
101747 How to install Microsoft authentication on a Macintosh
161372 How to enable SMB signing in Windows NT
236414 Cannot use shares with LMCompatibilityLevel set to only NTLM 2 authentication
241338 Windows NT LAN Manager version 3 client with first logon prevents subsequent logon activity
262890 Unable to obtain home directory drive connection in a mixed environment
308580 Home folder mappings to down-level servers may not work during logon
285901 Remote access, VPN, and RIS clients cannot establish sessions with a server that is configured to accept only NTLM version 2 authentication
323455 Directory Services Client update for Windows 98
816585 How to apply predefined security templates in Windows Server 2003
820281 You must provide Windows account credentials when you connect to Exchange Server 2003 by using the Outlook 2003 RPC over HTTP feature
| Modification Type: | Minor | Last Reviewed: | 10/3/2006 |
|---|
| Keywords: | kbinfo KB823659 kbAudITPRO |
|---|
|
|
|
©2004 Microsoft Corporation. All rights reserved.
|
|