KnowledgeBase Archive

An Archive of Early Microsoft KnowledgeBase Articles

View on GitHub
Q143474: Restricting Information Available to Anonymous Logon Users

Article: Q143474
Product(s): Microsoft Windows NT
Version(s): 3.51,4.0 SP3
Operating System(s): 
Keyword(s): kbenv kbnetwork
Last Modified: 08-AUG-2001

-------------------------------------------------------------------------------
The information in this article applies to:

- Microsoft Windows NT Workstation versions 4.0 SP3, 3.51 
- Microsoft Windows NT Server versions 4.0 SP3, 3.51 
-------------------------------------------------------------------------------

SUMMARY
=======

Windows 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.

There are similar situations where obtaining account names using an anonymous
connection allows the user interface tools, including Windows NT Explorer, User
Manager, and ACL editor, to administer and manage access control information
across multiple Windows NT domains. Another example is using User Manager in the
resource domain to add users from the trusted account domain to a local group.
One way to add the account domain user to a local group in the resource domain
is to manually enter a known domain\username to add access without getting the
complete list of names from the account domain. Another approach is to logon to
the system in the resource domain using an account in the trusted account
domain.

Windows NT environments that want to restrict anonymous connections from listing
account names can control this operation after installing Windows NT 4.0 Service
Pack 3 or the Windows NT 3.51 hotfix.

After installation of Windows NT 4.0 Service Pack 3 or the Windows NT 3.51
hotfix, administrators who want to require only authenticated users to list
account names, and exclude anonymous connections from doing so, need to make the
following change to the registry:

WARNING: Using Registry Editor incorrectly can cause serious, system-wide
problems that may require you to reinstall Windows NT to correct them. Microsoft
cannot guarantee that any problems resulting from the use of Registry Editor can
be solved. Use this tool at your own risk.

1. Run Registry Editor (Regedt32.exe).

2. Go to the following key in the registry:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

3. On the Edit menu, click Add Value and use the following entry:

  Value Name: RestrictAnonymous
  Data Type: REG_DWORD
  Value: 1

4. Exit the Registry Editor and restart the computer for the change to take
  effect.


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 Names
-----------------------------------------

The 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 Access
--------------------------------------------

Installation 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\winreg

The 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 additional information
on the winreg key, click the article number below to view the article in the
Microsoft Knowledge Base:

  Q153183 How to Restrict Access to NT Registry from a Remote Computer


Authenticated Users Built-in Group
----------------------------------

A 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 Hotfix
----------------------

The 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 
Technology        : kbWinNTsearch kbWinNTWsearch kbWinNTW400search kbWinNT351search kbWinNT400search kbWinNTW351search kbWinNTW351 kbWinNTW400sp3 kbWinNTSsearch kbWinNTS400sp3 kbWinNTS400search kbWinNTS351 kbWinNTS351search
Version           : :3.51,4.0 SP3
Issue type        : kbinfo

=============================================================================
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.