The information in this article applies to:
SUMMARYWindows NT has a feature where anonymous logon users can list domain user names and enumerate share names. Customers who want enhanced security have requested the ability to optionally restrict this functionality. Windows NT 4.0 Service Pack 3 and a hotfix for Windows NT 3.51 provide a mechanism for administrators to restrict the ability for anonymous logon users (also known as NULL session connections) to list account names and enumerate share names. Listing account names from Domain Controllers is required by the Windows NT ACL editor, for example, to obtain the list of users and groups to select who a user wants to grant access rights. Listing account names is also used by Windows NT Explorer to select from list of users and groups to grant access to a share. MORE INFORMATION
Windows NT networks based on a single Windows NT domain will always be
able to authenticate connections to list domain account information.
Windows NT networks that use multiple domains may require anonymous user
logon to list account information. A brief example shows how anonymous
connections are used. Consider two Windows NT domains, an account domain
and a resource domain. The resource domain has a one-way trust
relationship with the account domain. That is, the resource domain
"trusts" the account domain, but the account domain does not trust the
resource domain. Users from the account domain can authenticate and access
resources in the resource domain based on the one-way trust. Suppose an
administrator in the resource domain wants to grant access to a file to a
user from the account domain. They will want to obtain the list of users
and groups from the account domain to select a user/group to grant access
rights. Since the account domain does not trust the resource domain, the
administrator request to obtain the list of users and groups from the
resource domain cannot be authenticated. The connection is made using a
NULL session to obtain the list of account domain users.
The purpose of the registry value is to configure local system policy for whether authentication is required to perform common enumeration functions. Requiring authentication to obtain the account name list is an optional feature. When the RestrictAnonymous value is set to 1, anonymous connections from the Graphical User Interface tools for security management will receive an access denied error when attempting to get the list of account names. When the RestrictAnonymous value is set to 0, or the value is not defined, anonymous connections will be able to list account names and enumerate share names. It should be noted that even with the value of RestrictAnonymous set to 1, although the user interface tools with the system will not list account names, there are Win32 programming interfaces to support individual name lookup that do not restrict anonymous connections. Windows NT networks using a multiple domain model can restrict anonymous connections without loss of functionality. The initial steps in planning to disable anonymous connections is for administrators in resource domains to add members of trusted account domains to specific local groups as needed before changing the value for the LSA RestrictAnonymous registry entry. Users logged on using accounts from trusted account domains will continue to use authenticated connections to obtain list of account names to manage security access control. Restricting Anonymous List of Share NamesThe Server service that provides remote file access to share resources will also use the LSA registry value, RestrictAnonymous, to control whether anonymous connections can obtain a list of share names. Therefore, administrators can set the value of a single registry configuration entry to define how the system responds to enumeration requests by anonymous logons.Restricting Anonymous Remote Registry AccessInstallation of Windows NT 4.0 Service Pack 3 or the Windows NT 3.51 hotfix removes the ability for anonymous users to connect to the registry remotely. Anonymous users cannot connect to the registry and cannot read or write any registry data. As a reminder, Windows NT 4.0 restricts remote access to the registry by domain users using the access control list on the registry key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winregThe ACL on this key identifies the authenticated users allowed to remotely connect to the registry. Windows NT 4.0 Server, by default, only allows Administrators remote registry access. The winreg\AllowedPaths subkey identifies specific portions of the registry that authenticated users who are not explicitly granted access by the winreg ACL can use for printer access and other system operations. The winreg key may be defined on Windows NT 4.0 Workstations to restrict remote registry access to those systems. For more information on the winreg key, please see the following article in the Microsoft Knowledge Base: ARTICLE-ID: Q155363 Authenticated Users Built-in GroupA new built-in group is created when installing Windows NT 4.0 Service Pack 3 or the Windows NT 3.51 hotfix known as "Authenticated Users." The Authenticated Users group is similar to the "Everyone" group, except for one important difference: anonymous logon users (or NULL session connections) are never members of the Authenticated Users group. The built-in Security Identifier for Authenticated Users is S-1-5-11. Authenticated network connections from any account in the server's Windows NT domain, or any domain trusted by the server's domain, is identified as an Authenticated User. The Authenticated Users group is available for granting access rights to resources in the security ACL editor. Windows NT 4.0 Service Pack 3 and the Windows NT 3.51 hotfix do not modify any access control lists to change access rights granted to Everyone to use Authenticated Users.Windows NT 3.51 HotfixThe Windows NT 3.51 hotfix has been posted to the following Internet location:ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT351/ hotfixes-postSP5/sec-fix Additional query words: 4.00 3.51 sp3 sid
Keywords : kbenv kbnetwork ntsecurity NTSrvWkst |
Last Reviewed: July 15, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |