DOCUMENT:Q143474 [winnt]
TITLE :Restricting Information Available to Anonymous Logon Users
PRODUCT :Microsoft Windows NT
PROD/VER:4.00
OPER/SYS:WINDOWS
KEYWORDS:kbenv kbnetwork ntsecurity NTSrvWkst
--------------------------------------------------------------------------
The information in this article applies to:
- Microsoft Windows NT Workstation version 4.0
- Microsoft Windows NT Server version 4.0
--------------------------------------------------------------------------
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. A Windows
NT 4.0 hotfix provides 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 the
hotfix.
After installation of the 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\Control\CurrentControlSet\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 the 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\Control\CurrentControlSet
\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 more information on the winreg key, please see the following
article in the Microsoft Knowledge Base:
ARTICLE-ID: Q155363
TITLE : How To Regulate Network Access to the Windows NT Registry
Authenticated Users Built-in Group
----------------------------------
A new built-in group known as "Authenticated Users"is created when
installing the hotfix. 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. The hotfix does not modify any access control lists to change
access rights granted to Everyone to use Authenticated Users.
KBCategory: kbenv
KBSubcategory: NTSrvWkst ntprotocol
Additional reference words: prodnt 4.00
============================================================================
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.
Copyright Microsoft Corporation 1996.
~