11. marts 2003 - 16:20
#1
kan du bruge dette *GG*
Internet Authentication Service
Authentication Methods
There are a number of PPP authentication protocols that are supported by the RADIUS protocol. Each protocol has advantages and disadvantages in terms of security, usability, and breadth of support. The protocol used is determined by the configuration of the NAS device. See your NAS documentation if you are configuring a dial-up network, or consult your ISP if you are using an ISP for dial-up access to your LAN.
The following sections focus on the advantages and disadvantages of the authentication protocols currently supported by IAS. The information is also useful in configuring a particular authentication method for remote access.
Password Authentication Protocol
Password Authentication Protocol (PAP) passes a password as a string from the user's computer to the NAS device. When the NAS forwards the password, it is encrypted using the RADIUS shared secret as an encryption key. PAP is the most flexible protocol because passing a plaintext password to the authentication server enables that server to compare the password with nearly any storage format. For example, UNIX passwords are stored as one-way encrypted strings that cannot be decrypted. PAP passwords can be compared to these strings by reproducing the encryption method.
Because it uses a plaintext version of the password, PAP has a number of security vulnerabilities. Although the RADIUS protocol encrypts the password, it is transmitted as plaintext across the dial-up connection.
Enabling PAP
To enable PAP-based authentication, you must do the following:
Enable PAP as an authentication protocol on the remote access server. For information about a default setting on a particular NAS, see your NAS documentation. On the Routing and Remote Access service, PAP is disabled by default.
Enable PAP on the appropriate remote access policy. PAP is disabled by default.
Enable PAP on a remote access client.
Note
Enabling PAP as an authentication protocol means that user passwords are sent from a client to a NAS in plaintext form. The NAS encrypts the password using the shared secret and sends it in an Access-Request packet. Because a RADIUS proxy must encrypt the PAP password using the shared secret of its forwarding RADIUS server, a RADIUS proxy must decrypt the PAP password using the shared secret between the RADIUS proxy and the NAS. A malicious user at a RADIUS proxy can record user names and passwords for PAP connections. For this reason, the use of PAP is highly discouraged, especially for virtual private network connections.
Challenge Handshake Authentication Protocol
Challenge Handshake Authentication Protocol (CHAP) is designed to address the concern of passing passwords in plaintext. By using CHAP, the NAS sends a random number challenge to the user's computer. The challenge and the user's password are then hashed by using MD5. The client computer then sends the hash as a response to the NAS challenge and the NAS forwards both the challenge and response in the RADIUS Access-Request packet.
When the authenticating server receives the RADIUS packet, it uses the challenge and the user's password to create its own version of the response. If the version of the server matches the response supplied by the user's computer, the access request is accepted.
CHAP responses cannot be reused because NAS devices send a unique challenge each time a client computer connects to them. Because the algorithm for calculating CHAP responses is well known, it is very important that passwords be carefully chosen and sufficiently long. CHAP passwords that are common words or names are vulnerable to dictionary attacks if they can be discovered by comparing responses to the CHAP challenge with every entry in a dictionary. Passwords that are not sufficiently long can be discovered by brute force by comparing the CHAP response to sequential trials until a match to the user's response is found.
Historically, CHAP is the most common dial-up authentication protocol used. When the server does not store the same password that was used to calculate the CHAP response, it cannot calculate an equivalent response. Because standard CHAP clients use the plaintext version of the password to create the CHAP challenge response, passwords must be stored in plaintext on the server to calculate an equivalent response.
Although the IAS server supports CHAP, a Windows NT 4.0–based domain controller cannot validate CHAP requests without support for storing reversibly encrypted passwords. This support is available in Windows 2000; in Windows NT 4.0, this support is available through an update to the Windows NT 4.0–based domain controller.
Enabling CHAP
To enable CHAP-based authentication, you must do the following:
Enable CHAP as an authentication protocol on the remote access server. For information about a default setting on a particular NAS, see your NAS documentation. For the Routing and Remote Access service, CHAP is enabled by default.
Enable CHAP on the appropriate remote access policy. CHAP is enabled by default.
Enable storage of a reversibly encrypted form of the user's password. For a Windows 2000–based stand-alone server, use machine Group Policy to enable storage of reversibly encrypted passwords for all users of the computer. For Windows 2000 domains, Group Policy at the domain or Organizational Unit (OU) level can be used. For information about enabling reversibly encrypted passwords in a Windows 2000 domain, see Windows 2000 Server Help.
Force a reset of user's passwords so that the new password is in a reversibly encrypted form. When you enable passwords to be stored in a reversibly encrypted form, the current passwords are in a nonreversibly encrypted form and are not automatically changed. You must either reset user passwords or set user passwords to be changed the next time you log on. After the password is changed, it is stored in a reversibly encrypted form.
If you set user passwords to be changed at the next attempt to log on, the user must log on using a LAN connection and change their password before they attempt to log on with a remote access connection using CHAP. CHAP does not support the changing of passwords during the authentication process and the logon attempt fails. One workaround for the remote access user is to temporarily log on using MS-CHAP to change their password.
Enable CHAP on the remote access client.
Microsoft Challenge Handshake Authentication Protocol
Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) is a variant of CHAP that does not require a plaintext version of the password on the authenticating server. In MS-CHAP the challenge response is calculated with an MD4 hashed version of the password and the NAS challenge. This enables authentication over the Internet to a Windows 2000 domain controller (or a Windows NT 4.0 domain controller on which the update has not been installed).
MS-CHAP passwords are stored more securely at the server but have the same vulnerabilities to dictionary and brute force attacks as CHAP. When using MS-CHAP, it is important to ensure that passwords are well chosen (not found in a standard dictionary) and long enough that they cannot be calculated readily. Many large customers require passwords to be at least six characters long with upper and lower case characters and at least one numeral.
See your NAS documentation, or consult your ISP to see whether the ISP currently supports MS-CHAP.
Note
By default, MS-CHAP v1 for Windows 2000 supports LAN Manager authentication. If you want to prohibit the use of LAN Manager authentication with MS-CHAP v1 for older Microsoft operating systems such as Windows NT 3.5x and Windows 95, you must set Allow LM Authentication (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \RemoteAccess\Policy) to 0 on the authenticating server.
If a user attempt authenticates using MS-CHAP using an expired password, MS-CHAP prompts the user to change the password while connecting to the server. Other authentication protocols do not support this feature effectively locking out the user who used the expired password.
Enabling MS-CHAP
To enable MS-CHAP-based authentication, you must do the following:
Enable MS-CHAP as an authentication protocol on the remote access server. MS-CHAP is enabled by default on the Routing and Remote Access service. For information about default settings on other NASs, see your NAS documentation.
Enable MS-CHAP on the appropriate remote access policy. MS-CHAP is enabled by default.
Enable MS-CHAP on a remote access client.
Microsoft Challenge Handshake Authentication Protocol Version 2
Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) provides mutual authentication, stronger initial data encryption keys, and different encryption keys for sending and receiving. For VPN connections, Windows 2000 servers offer MS-CHAP v2 before offering the legacy MS-CHAP. Updated Windows clients accept MS-CHAP v2 when it is offered.
MS-CHAP v2 is a one-way encrypted password, mutual authentication process that works as follows:
The remote access server sends a challenge to the remote access client that consists of a session identifier and an arbitrary challenge string.
The remote access client sends a response that contains:
The user name.
An arbitrary peer challenge string.
A one-way encryption of the received challenge string, the peer challenge string, the session identifier, and the user's password.
The remote access server checks the response from the client and sends back a response containing:
An indication of the success or failure of the connection attempt.
An authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user's password.
The remote access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the remote access client terminates the connection.
If a user authenticates by using MS-CHAP v2 and attempts to use an expired password, MS-CHAP prompts the user to change the password while connecting to the server. Other authentication protocols do not support this feature effectively locking out the user who used the expired password.
Enabling MS-CHAP v2
To enable MS-CHAP v2–based authentication, you must do the following:
Enable MS-CHAP v2 as an authentication protocol on the remote access server. MS-CHAP v2 is enabled by default on the Routing and Remote Access service. For information about default settings on other NASs, see your NAS documentation.
Enable MS-CHAP v2 on the appropriate remote access policy. MS-CHAP v2 is enabled by default.
Enable MS-CHAP v2 on the Windows 2000 remote access client.
Note
Windows 95 and Windows 98 support MS-CHAP v2 only for virtual private network (VPN) connections. Windows 95 and Windows 98 do not support MS-CHAP v2 for dial-up connections.
Extensible Authentication Protocol
Extensible Authentication Protocol (EAP) is an extension to the Point-to-Point protocol (PPP) that works with dial-up, PPTP, and L2TP clients. EAP allows the addition of new authentication methods known as EAP types. Both the dial-in client and the remote access server must support the same EAP type for successful authentication to occur.
Windows 2000 includes an EAP infrastructure and two EAP types, EAP-MD5 CHAP and EAP-TLS. The IAS implementation in Windows 2000 has the ability to pass EAP messages to a RADIUS server (EAP-RADIUS).
EAP-MD5 CHAP
Message Digest 5 Challenge Handshake Authentication Protocol (EAP-MD5 CHAP) is a required EAP type that uses the same challenge-handshake protocol as PPP-based CHAP, but the challenges and responses are sent as EAP messages. A typical use for EAP-MD5 CHAP is to authenticate the credentials of remote access clients by using user name and password security systems. You can use EAP-MD5 CHAP to test EAP interoperability.
EAP-TLS
EAP-Transport Level Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. If you are using smart cards for remote access authentication, you must use the EAP-TLS authentication method. The EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and secured private key exchange between the remote access client and the authenticating server. EAP-TLS provides the strongest authentication and key exchange method. EAP-TLS is supported only on a remote access server that is running Windows 2000 and is a member of a Windows 2000 mixed or native domain.
EAP-RADIUS
EAP-RADIUS is not an EAP type, but the passing of EAP messages of any EAP type by a remote access server to a RADIUS server for authentication. The EAP messages sent between the remote access client and remote access server are encapsulated and formatted as RADIUS messages between the remote access server and the RADIUS server.
EAP-RADIUS is used in environments where RADIUS is used as the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each remote access server, only at the RADIUS server. In a typical use of EAP-RADIUS, a remote access server is configured to use EAP and to use RADIUS as its authentication provider. When a connection is made, the remote access client negotiates the use of EAP with the remote access server. When the client sends an EAP message to the remote access server, the remote access server encapsulates the EAP message as a RADIUS message and sends it to its configured RADIUS server. The RADIUS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the remote access server. The remote access server then forwards the EAP message to the remote access client. In this configuration, the remote access server is only a pass-through device. All processing of EAP messages occurs at the remote access client and the RADIUS server.
Enabling EAP
To enable EAP-based authentication, you must do the following:
Enable EAP as an authentication protocol on the remote access server.
Enable EAP; if needed, configure the EAP type on the appropriate remote access policy.
Enable and configure EAP on a remote access client.
In addition to the EAP types defined and supported in Windows 2000, new EAP authentication methods can be included through the use of EAP Software Development Kit.
Unauthenticated Access
The unauthenticated access method allows remote access users to log on without checking their credentials. For example, IAS does not verify the user's name and password. The only user validation performed in the unauthenticated access method is authorization. Enabling unauthenticated access presents security risks that must be carefully considered when deciding whether to enable this authentication method.
This section discusses three scenarios of unauthenticated access:
Guest Access
Dialed Number Identification Service (DNIS) authorization
Automatic Number Identification/Calling Line Identification (ANI/CLI) authorization
Guest Access for PPP Users
Guest access is the ability to log on to a domain without a user name and/or a password. Both Routing and Remote Access service and IAS must be configured to support unauthenticated access.
When a remote access server receives a connection attempt, it negotiates with the user different authentication types enabled at the server. If the client accepts one of them, it sends the appropriate credentials for the accepted authentication type. It the user refuses authentication, Routing and Remote Access service checks its properties to verify if unauthenticated access is enabled and, if enabled, forwards the Access-Request packet to IAS. This Access-Request packet does not contain a User-Name attribute or any other credentials.
When IAS receives the packet without a User-Name attribute, it assumes that the user wants to dial in using guest access. In this case, IAS uses the name of the guest account in a domain as the user identity. It proceeds to evaluate policies in order to determine the right profile. If a match is found, and unauthenticated access is enabled in the profile, other authorizations are validated, and an Access-Accept packet is returned. The accounting log file logs the user identity and authentication type, which can be used to determine whether the user was logged on with guest access.
Enabling Guest Access
To enable Guest access, perform the following steps:
Enable unauthenticated access on the remote access server.
Enable unauthenticated access on the appropriate remote access policy.
Enable the Guest account.
Set the remote access permission on the Guest account to either Allow access or Control access through Remote Access Policy depending on your remote access policy administrative model.
If you do not want to enable the Guest account, create a user account and set the remote access permission to either Allow access or Control access through Remote Access Policy. Then set the Default User Identity registry value (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy) on the authenticating server (either the remote access server or the IAS server) to the name of the account.
For more information about enabling authentication protocols, configuring authentication, and enabling a disabled user account, see Windows 2000 Server Help.
Guest Access Example
During PPP negotiation, the dial-in client rejects all of the PPP authentication protocols of the NAS.
If the NAS is configured to allowed unauthenticated access, the NAS sends an Access-Request packet without the User-Name attribute and without a password. For the Windows 2000 Routing and Remote Access service, unauthenticated access is enabled from the Authentication tab on the properties of a server in the Routing and Remote Access snap-in.
Because the User-Name attribute is not included in the Access-Request packet and by default the IAS user identity is using the User-Name attribute, the user identity is set to Guest (or the value of Default User Identity).
With the user identity of Guest and an unauthenticated connection attempt, the authentication and authorization process as discussed earlier in the chapter is performed. If the connection attempt matches a policy whose profile settings have unauthenticated access enabled and the Guest account is enabled and has the appropriate remote access permission, IAS sends an Access-Accept packet to the NAS.
DNIS Authorization
Dialed Number Identification Service (DNIS) authorization is the authorization of a connection attempt based on the number called. This attribute is referred to as Called Station ID. DNIS is used by standard telecommunication companies. This service returns the number called to the called party. Based on the Called Station ID attribute, IAS can deliver different services to dial-up/remote access users.
Enabling DNIS Authorization
The following steps are required in order to enable DNIS authorization:
Enable unauthenticated access on the remote access server.
Create a remote access policy on the authenticating server (remote access server or IAS server) for DNIS-based authorization with the Called-Station-ID condition set to the phone number.
Enable unauthenticated access on the remote access policy for DNIS-based authorization.
ANI Authorization
ANI authorization is based on the number the user called from. This attribute is referred to as Calling Station ID, or Caller ID. Based on the Calling-Station-ID attribute, IAS can deliver different services to dial-up/remote access users.
Using ANI authorization is different from using the Caller ID dial-in property of a user account. ANI authorization is performed when the user does not type in any user name or password, and refuses to use any valid authentication method. In this case, IAS receives Calling-Station-ID, and no user name and password. To support ANI authorization, the Active Directory must have user accounts with Caller IDs as user names. This kind of authentication is used with the cellular phone authentication and by ISPs in Germany and Japan.
When using the Caller ID property on a user account, the user types in his credentials, such as a user name and password, and uses a valid authentication method to log on. IAS uses the user name and password to authenticate the user, and then compares the Calling-Station-ID attribute in the Access-Request to the Caller ID property of the user account as a way of authorizing the connection attempt.
Enabling ANI Authorization
Enable unauthenticated access on the remote access server.
Enable unauthenticated access on the appropriate remote access policy for ANI/CLI-based authentication.
Create a user account for each number calling, for which you want to provide ANI/CLI authorization. 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.
Set the User Identity Attribute registry value (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ RemoteAccess\Policy) to 31 on the authenticating server.
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 Override User-Name registry value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \RemoteAccess\Policy
to 1 on the authenticating server.
However, if you set Override User-Name to 1 and the User Identity Attribute to 31, the authenticating server can perform only ANI/CLI-based authentication. Normal authentication by using authentication protocols such as MS-CHAP, CHAP, and EAP is disabled.
ANI Example
The following example explains how ANI/CLI authorization works for an dial-up client dialing in from the phone number 555-0100 and a user account called 5550100 exists.
During PPP negotiation, the dial-in client rejects all of the PPP authentication protocols of the NAS.
If the NAS is configured to allowed unauthenticated access, the NAS sends an Access-Request packet without the User-Name attribute and without a password. For the Windows 2000 Routing and Remote Access service, unauthenticated access is enabled from the Authentication tab on the properties of a server in the Routing and Remote Access snap-in.
Because the User-Name attribute is not included in the Access-Request packet and the IAS user identity is set to use the Calling-Station-ID attribute, the user identity is set to 5550100.
With the user identity of 5550100 and an unauthenticated connection attempt, the authentication and authorization process as discussed earlier in the chapter is performed. If the connection attempt matches a policy whose profile settings have unauthenticated access enabled and the 550100 account has the appropriate remote access permission, IAS sends an Access-Accept packet to the NAS.
© 1985-2000 Microsoft
Ny bruger
Nybegynder
Opret
Preview
