Anonymous Connections

Why protect against anonymous connections

Back in the days when security was a secondary and even tertiary concern, computers used anonymous connections to do a variety of different tasks. The problem is that these tasks have been secured, even though the access has not been denied or removed. Therefore, there are many avenues into your computer from quite a few different angles that you might not even be aware of.

What can an Anonymous Connection Accomplish?

I am sure I have your attention now! The question that must be on the tip of your tongue must be, “What can someone do if they gain anonymous access to my computer?” Of course the answer is “it depends!” It depends because it is based on not only what they acquire from your computer, but what they can do with it.

The basic information that someone can glean from your computer from an anonymous connection includes:

  • List of users from your computer, including Active Directory  
  • List of groups from your computer, including Active Directory
  • SIDs for user accounts
  • User accounts for SIDs
  • List of shares from your computer
  • Account policies from your computer
  • NetBIOS name from your computer
  • Domain name that your computer is associated with
  • List of domains that your domain trusts

How to Make an Anonymous Connection

An anonymous connection is not something that you can make by accident. The syntax is not so simple that just anyone can make the connection. The point here is that if you have anonymous connections being made to your servers, someone is deliberately trying to gather information and you need to take immediate action.

The method that is mostly used to create an anonymous connection is to use the net use command. The net use command allows you to make a connection to a specific share on a server. The syntax would look something like this:

Net use \\\ipc$ /u:”” “”

Here, you can replace the IP address with the IP address of the server that you are accessing, or the NetBIOS name of the computer. In some instances, you can even get a list of all the computers that you could possibly connect to by running the following command:

Net view /domain:domainname

Once you have the computer names or IP addresses of the computers, you can attempt to make anonymous connections using the command above, or any “hacker” tool that exploits the anonymous access.

How Windows 2000 protected against anonymous connections

Microsoft has been aware of the anonymous access problem for quite some time. For Windows 2000, they implemented a Group Policy Object setting which allowed you to control how and if a user could create an anonymous connection to your computer. The setting is located in the Computer Configuration portion of any GPO. If you go below the Computer Configuration to the Windows Settings | Security Settings | Local Policies | Security Options, you will see the first GPO policy is related to anonymous connections, as shown in the figure.

Figure 1: GPO policy relating to anonymous connections

This policy can be configured to three different levels: 0, 1, and 2. These levels are displayed in the policy editor a bit differently, which is explained below. The Registry value that is being modified is HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous. Here is an explanation of the settings and what they protect against.

Level 0: “None. Rely on default permission”
This does not restrict any anonymous connections. This is a very insecure setting, but it is also the default on a Windows 2000 computer or domain.

Level 1: “Do not allow enumeration of SAM accounts or shares”
This is designed to not allow any anonymous access list the SAM or shares. However, there is a small problem here that this does not protect against all methods of accessing the SAM or shares from an anonymous connection. This setting is in essence no more secure than the Level 0 setting.

Level 2: “No access without explicit anonymous permissions”
This will deny all access for anonymous connections gaining access to the SAM or shares. This setting is not suggested, due to the impact it has on down level clients and applications that rely on anonymous connections.

A note about the level 2 access in Windows 2000 is that it is not designed for a mixed-mode domain. If this policy is set to 2 for a mixed mode domain, you will see problems with the following areas:

  • Windows 9x and Windows NT computers will not be able to establish a netlogon secure channel.
  • Windows NT trusted domains will not be able to establish a netlogon secure channel.
  • Users of Windows NT computers will not be able to change their passwords.
  • The browser service will fail on all computers where this level is set to 2.            

How Windows 2003 protects against anonymous connections    

When Server 2003 arrived, there were some distinct changes with regard to the control of anonymous connections. The old Windows 2000 anonymous GPO policy was still there (in a round about way), but it was accompanied with many more policy settings. The settings are welcomed, especially with the poor control over anonymous connections that Windows 2000 provided. The main problem is that the descriptions, documentation, and features of each setting were not very clear.

Figure 2 shows the anonymous control settings in a Group Policy Object from a Windows Server 2003 environment. The following is a list of each setting that directly controls anonymous connections, as well as a description as to what the policy controls.

Figure 2: Windows Server 2003 has better control over anonymous connections

Network access: Allow anonymous SID/Name translation – This policy controls an anonymous user’s capability of obtaining the SID of a user by knowing the name, or vice versa. With tools such as user2sid and sid2user, allowing this access can quickly give away the built-in administrators name.

Network access: Let everyone’s permissions apply to anonymous users – This policy controls the access that anonymous users have once connected. In previous versions of Windows, anonymous users were provided with the SID for the Everyone group on the authentication token, allowing them to access everything that the Everyone group had access to. In Server 2003, the default configuration is to remove the Everyone group SID from the token generated for an anonymous user. This provides added protection for anonymous users attempting to access resources. Once this policy is set, anonymous users will only be able to access resources for which the anonymous user has been explicitly given permission.

Network access: Do not allow anonymous enumeration of SAM accounts – This policy is designed to negate anonymous connections from enumerating the list of user accounts from the local SAM (member servers and desktops) and Active Directory domain controllers.

Network access: Do not allow anonymous enumeration of SAM accounts and shares – This policy takes the previous policy one step further, by not only negating enumeration of user accounts from the SAM, but also shares on the targeted computer. The shares that are negated include standard, hidden, and hidden administrative shares.

There are other settings that control anonymous connections to specific shares, named pipes, etc. These are typically not as powerful as the settings described above in negating anonymous connectivity to a Windows computer.


By default your Windows computers are not safe from anonymous connections. Settings do exist to help you control these connections, but they are more effective on a Windows Server 2003 computer. If you do your due diligence and test these settings in your production network, you will find that you have quite a bit of control over these anonymous connections. If you still run Windows 2000 computers, you might want to consider moving up to Windows Server 2003, if for no other reason, to help restrict these anonymous connections.

About The Author

1 thought on “Anonymous Connections”

  1. Sorry for replying to an old post, but how can I see the list of anonymous connections from command lines.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top