Unauthenticated Access

Applies To: Windows Server 2008, Windows Server 2008 R2

With unauthenticated access, user credentials (a user name and password) are not required. There are some situations where unauthenticated access is useful, although in most cases it is not recommended that you deploy unauthenticated access to your organization network.

When you enable unauthenticated access, users are allowed access to your network without sending user credentials. In addition, unauthenticated access clients do not negotiate the use of a common authentication protocol during the connection establishment process and do not send a user name or password to Network Policy Server (NPS).

If you permit unauthenticated access on your network, clients can connect without being authenticated if the authentication protocols configured on the access client do not match the authentication protocols that are configured on the network access server (NAS). In this case, the use of a common authentication protocol is not negotiated and the access client does not send a user name and password. This circumstance creates a severe security problem and unauthenticated access should not be allowed on most networks.

In the circumstances where you must use unauthenticated access, you can use one of the following solutions:

• Dialed Number Identification Service (DNIS) authorization

• Automatic Number Identification/Calling Line Identification (ANI/CLI) authentication

• Guest authentication

The following sections provide detail on each of these access methods.

DNIS authorization

DNIS enables the authorization of a connection attempt by NPS based on the number that the client computer called to initialize the connection. DNIS identifies the number that was called to the receiver of the call and is provided by most standard telephone companies. For example, you can allow all connections that connect through a specific toll-free number. To identify DNIS-based connections and apply the appropriate connection settings, you must do the following:

1. Enable unauthenticated access on the network access server.

2. Create a network policy on the NPS server for DNIS-based authorization with the Called-Station-Id condition set to the phone number that client computers must call to initiate the connection.

3. Enable unauthenticated access on the network policy in NPS for DNIS-based authorization.

Additional considerations

Following are additional things to consider before deploying DNIS:

• If your phone service or hardware does not support DNIS, the passing of the number that was called, you can manually set the phone number of the port.

• NPS does not support proxied DNIS access requests.

ANI/CLI authentication

ANI/CLI) authentication is the authentication of a connection attempt based on the phone number of the caller. ANI/CLI service returns the number of the caller to the receiver of the call and is provided by most standard telephone companies.

ANI/CLI authentication is different from caller ID authorization. In caller ID authorization, the caller sends a valid user name and password. The caller ID that is configured for the dial-in property on the user account must match the connection attempt; otherwise, the connection attempt is rejected. With ANI/CLI authentication, a user name and password are not sent.

To identify ANI/CLI-based connections and apply the appropriate connection settings, you must do the following:

1. Enable unauthenticated access on the network access server.

2. Enable unauthenticated access on the appropriate network policy in NPS for ANI/CLI-based authentication.

3. Create a user account in Active Directory Domain Services (AD DS) or the local Security Accounts Manager (SAM) database on the NPS server for each number for which you want to provide ANI/CLI authentication. The name of the user account must match the number that the user is dialing from. For example, if a user is dialing in from 555-0100, create a "5550100" user account.

4. Set the following registry value to 31 on the NPS server:

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\User Identity Attribute

   This registry setting tells the authenticating server to use the calling number (RADIUS attribute 31, Calling-Station-ID) as the identity of the calling user. The user identity is set to the calling number only when there is no user name being supplied in the connection attempt.

   To always use the calling number as the user identity, set the following registry value to 1 on the authenticating server:

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Override User-Name

   However, if you set Override User-Name to 1 and the User Identity Attribute to 31, the authenticating server can only perform ANI/CLI-based authentication. Normal authentication by using authentication protocols such as MS-CHAP, CHAP, and EAP is disabled.

Guest authentication

By default, AD DS includes a user account called Guest. By default, this account is disabled, but if you want to provide unauthenticated access you can enable the Guest account. With guest authentication, during the authentication process, the user does not provide a user name or password. If unauthenticated access is enabled, by default the Guest account is used as the identity of the caller.

To enable Guest account access, you must do the following:

1. Enable unauthenticated access on the network access server.

2. Enable unauthenticated access on the appropriate network policy in NPS.

3. Enable the Guest account in the Active Directory Users and Computers snap-in.

4. Set the remote access permission on the Guest account to either Allow access or Control access through NPS Network Policy depending on your network access administrative model.

If you want to enable a guest account that is not named Guest, create a user account and set the remote access permission to either Allow access or Control access through NPS Network Policy. Then, set the following registry value on the authenticating server (either the network access server or the NPS server) to the name of the account:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Default User Identity