Partilhar via


Troubleshooting IAS as a RADIUS server

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Troubleshooting IAS as a RADIUS server

What problem are you having?

  • A connection attempt fails.

  • Connection attempts using Protected Extensible Authentication Protocol (PEAP) fail.

  • Computers newly joined to the domain cannot enroll certificates.

  • Connection attempts using Password Authentication Protocol (PAP) fail.

  • Connection attempts using Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) fail.

  • Users with 802.1x authenticated switch client connections with EAP or PEAP are not prompted to input credentials and cannot log on.

  • Users who should not have remote access permission can log on

  • Users can log on successfully, but their logon attempts do not appear in the log files.

  • You have just changed your Active Directory domain from a Windows 2000 mixed domain to a Windows 2000 native domain or a Windows Server 2003 domain, and IAS servers can no longer authenticate valid connection requests.

  • Interim accounting messages are not being recorded in the remote access log file

  • Third-party network access servers (NASs) drop connections and IAS sends a Microsoft vendor-specific attribute (MS-RAS-MPPE-Encryption-Policy) to the network access server instead of the NAS's vendor ID.

  • MS-CHAP v2 or EAP-TLS authentications are being rejected for valid connection attempts.

  • You can no longer see the Remote Access Policies node in Routing and Remote Access.

  • When you try to open the IAS console, you receive an error message and the console does not open.

A connection attempt fails.

Cause: IAS has either rejected or discarded the connection attempt for a variety of reasons.

Solution: Verify that IAS is configured for the logging of rejected authentication attempts to the event log. Try the connection again, and then check the system event log for an IAS event for the connection attempt. Use the information in the log to determine the reason the connection attempt was either rejected or discarded and the way to fix the problem.

See also: Event logging for IAS; Configure event logging for IAS

Connection attempts using Protected Extensible Authentication Protocol (PEAP) fail.

Cause: The wireless remote access policy on the IAS server is not configured to use PEAP as the authentication method.

Solution: Create a wireless remote access policy on the IAS server that is configured with PEAP-EAP-MS-CHAPv2 or PEAP-EAP-TLS.

See also: Configure Remote Access Policies; Configure PEAP and EAP methods; Wireless access with secure password authentication

Cause: Remote access policy on the IAS server is configured to reject the user or computer.

Solution: Make sure that your remote access policy and user account settings are not configured to reject user authentication and authorization attempts. For example, if the user belongs to a group that is restricted in remote access policies to accessing the network between 9 A.M. and 5 P.M., any attempt by the user to log on between 5:01 P.M. and 8:59 A.M. will fail. To resolve the issue, change the day and time restrictions in remote access policies, or move the user to another group with different or no day and time restrictions. In addition, user account settings in Active Directory might prevent the user from accessing the network.

See also: Introduction to remote access policies; Elements of a remote access policy; Dial-in properties of a user account

Cause: You are using PEAP-EAP-MS-CHAPv2 as the authentication method and the IAS server does not have a certificate to use for server authentication to the client.

Solution: If the IAS server is a domain member computer, auto-enroll a certificate that contains the Server Authentication purpose in Enhanced Key Usage extensions and is configured according to minimum server certificate requirements. If the IAS server is not a domain member computer, enroll a certificate that contains the Server Authentication purpose in Enhanced Key Usage extensions (and which is configured according to minimum server certificate requirements) using the CA Web enrollment tool, or install a certificate on the IAS server using a floppy disk.

See also: The section "Certificate requirements for EAP" in Network access authentication and certificates.

Cause: You are using PEAP-EAP-MS-CHAPv2 as the authentication method and when prompted to make a decision whether or not to trust the server certificate, the user has chosen not to trust the server certificate.

Solution: Instruct users to trust the server certificate at next log on.

Cause: You are using PEAP-EAP-TLS as the authentication method and the client computer does not have a certificate that contains the Client Authentication purpose in Enhanced Key Usage extensions and is configured according to minimum client certificate requirements.

Solution: If the client is a domain member computer, auto-enroll a certificate that contains the Client Authentication purpose in Enhanced Key Usage extensions and is configured according to minimum client certificate requirements. If the client is not a domain member computer, enroll a certificate that contains the Client Authentication purpose in Enhanced Key Usage extensions (and which is configured according to minimum client certificate requirements) using the CA Web enrollment tool, or install a certificate on the IAS server using a floppy disk.

See also: The section "Certificate requirements for EAP" in Network access authentication and certificates.

Cause: The client computer does not trust the CA that issued the server certificate.

Solution: Add your organization's root certification authority certificate to the Trusted Root Certification Authorities folder in the computer certificate store.

Cause: You are using PEAP-EAP-TLS as the authentication method and the IAS server does not have a certificate to use for server authentication to the client.

Solution: If the IAS server is a domain member computer, auto-enroll a certificate that contains the Server Authentication purpose in Enhanced Key Usage extensions and is configured according to minimum server certificate requirements. If the IAS server is not a domain member computer, enroll a certificate that contains the Server Authentication purpose in Enhanced Key Usage extensions (and which is configured according to minimum server certificate requirements) using the CA Web enrollment tool, or install a certificate on the IAS server using a floppy disk.

See also: The section "Certificate requirements for EAP" in Network access authentication and certificates.

Cause: Group Policy on domain member computers has not been refreshed after the configuration of certificate auto-enrollment.

Solution: Refresh Group Policy on domain member computers. After auto-enrollment is configured and enabled, all domain member computers will receive computer certificates at the next refresh of Group Policy, whether the refresh is triggered manually with the gpupdate command or when the computer next logs on to the domain.

See also: Network access authentication and certificates; Configure automatic certificate allocation from an enterprise CA; Use Windows Server 2003 Certificate Services Web Pages; Manage certificates for a computer; and Request a certificate

Computers newly joined to the domain cannot enroll certificates.

Cause: When a Public Key Infrastructure (PKI) is deployed and autoenrollment is configured for the domain, Active Directory replication latency can temporarily affect the ability of a client or server to obtain a certificate from a certification authority.

Solution: Verify that Active Directory has replicated to all domain controllers, and then refresh Group Policy to enroll a certificate on the computer. You can refresh Group Policy by running the gpupdate command or by logging on to the domain.

See also: Checklist: Configuring certificate autoenrollment; Authentication methods; Troubleshooting replication

Connection attempts using Password Authentication Protocol (PAP) fail.

Cause: The password is incorrect.

Solution: Try the connection again and verify that the password is correct.

Cause: Mismatched shared secrets.

Solution: Verify that the same shared secret is configured on the access server and for the RADIUS client in Internet Authentication Service.

See also: Edit RADIUS client configuration; Shared secrets

Connection attempts using Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) fail.

Cause: The password is incorrect.

Solution: Try the connection again and verify that the password is correct.

Cause: The access client is using LAN Manager authentication.

Solution: By default, MS-CHAP for Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition does not support LAN Manager authentication. If you want to allow the use of LAN Manager authentication with MS-CHAP for older Microsoft operating systems such as Windows NT 3.5x and Windows 95, you must set the following registry value to 1 on the IAS server: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Allow LM Authentication

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

See also: MS-CHAP; Add a value to a registry key entry

Users with 802.1x authenticated switch client connections with EAP or PEAP are not prompted to input credentials and cannot log on.

Cause: The icon for the network connection must be displayed in the notification area on the client.

Solution: Configure the network connection properties on the client so that the network connection icon is displayed in the notification area when connected.

See also: Show a network connection icon in the notification area

Cause: The switch is not configured to initiate authentication with an EAP-Request-Identity packet when it detects that a client is active on the port.

Solution: Configure the switch to initiate authentication.

Users who should not have remote access permission can log on.

Cause: A remote access policy might be granting access to these users.

Solution: Check the policy list to ensure that you have not included groups in which the user is a member that should be denied access.

Cause: The remote access permission on the user account dial-in properties is set to Grant access, which overrides the remote access permission of the remote access policy.

Solution: Check the dial-in properties for the user object.

See also: Configure remote access permission for a user; Dial-in properties of a user account

Cause: Remote access policies might be evaluated in the wrong order.

Solution: Authorization is granted or denied by the first policy with conditions that match the connection attempt. Use Move Up to move the policy that denies access to these users, so that it is higher in the list.

See also: Configure remote access permission for a user; Dial-in properties of a user account

Users can log on successfully, but their logon attempts do not appear in the log files.

Cause: IAS is not configured to log successful authentication attempts.

Solution: Configure IAS to log successful authentication attempts in the event log.

See also: Event logging for IAS; Configure event logging for IAS

You have just changed your Active Directory domain from a Windows 2000 mixed domain to a Windows 2000 native domain or a Windows Server 2003 domain, and IAS servers can no longer authenticate valid connection requests.

Cause: After you change a domain from a Windows 2000 mixed domain to a Windows 2000 native domain or a Windows Server 2003 domain, every domain controller in the domain must be restarted in order for the change to replicate.

Solution: Restart the domain controllers so that the IAS servers can authenticate valid connection requests.

Interim accounting messages are not being recorded in the remote access log file.

Cause: Remote access logging is not configured to record periodic status.

Solution: Configure remote access logging to record periodic status.

Cause: You have not added and configured the Acct-Interim-Interval RADIUS accounting attribute on the Advanced tab of the appropriate remote access policy.

Solution: Add and configure the Acct-Interim-Interval RADIUS accounting attribute on the Advanced tab of the appropriate remote access policy. The value of the Acct-Interim-Interval attribute is the number of seconds between interim accounting updates.

Cause: The access server does not support interim accounting or is not configured to send interim accounting messages.

Solution: Verify that the access server supports interim accounting and the Acct-Interim-Interval attribute. If so, consult the access server documentation for instructions about how to enable interim accounting. The Routing and Remote Access service supports sending interim accounting messages and is enabled from the properties of a RADIUS server when configuring the RADIUS accounting provider.

See also: Logging user authentication and accounting requests; Add RADIUS attributes to a remote access policy; Use RADIUS accounting

Third-party network access servers (NASs) drop connections and IAS sends a Microsoft vendor-specific attribute (MS-RAS-MPPE-Encryption-Policy) to the network access server instead of the NAS's vendor ID.

Cause: The encryption policy as configured in remote access policies is not set to the default.

Solution: The Microsoft VSA MS-RAS-MPPE-Encryption-Policy is sent to third-party network access servers if the encryption policy as configured in remote access policies is not set to the default. The default encryption policy allows all encryption levels and does not contain any attributes specific to the Routing and Remote Access service, so applying default encryption settings will prevent IAS from sending any Microsoft VSAs to third-party NASs. Take the following steps in the profile of the remote access policy:

  • On the Encryption tab, return the encryption policy to the default. Select all encryption levels except No encryption.

  • On the Advanced tab, remove all attributes specific to the Routing and Remote Access service from the list of attributes for the remote access policy.

  • On the IP tab, remove all IP filters.

  • On the Multilink tab, select Server settings determine Multilink usage. Return all other settings to the default (not selected).

See also: Configure encryption; Configure vendor-specific attributes for a remote access policy; Vendor-specific attribute overview; Recreate the default remote access policy; Configure IP options

MS-CHAP v2 or EAP-TLS authentications are being rejected for valid connection attempts.

Cause: The authentication method (in the profile settings of the connection request policy) that matched the connection request is configured for the Accept the connection attempt without performing authentication or authorization setting. MS-CHAP v2 and EAP-TLS are mutual authentication protocols. In mutual authentication, the access client proves that it is a valid access client to the authenticating server and the authenticating server proves that it is a valid authenticating server to the access client. When this authentication option is used, although the connect request is granted, the authenticating server does not provide validation to the access client. As the result, mutual authentication fails.

Solution: Reconfigure connection request policies so that MS-CHAP v2 and EAP-TLS connections are not being accepted without authentication and authorization.

See also: Connection request policies

You can no longer see the Remote Access Policies node in Routing and Remote Access.

Cause: When a Routing and Remote Access server is configured to use RADIUS authentication, the remote access policies on the Routing and Remote Access server are never evaluated for authorization.

Solution: This is intended behavior. If the RADIUS server of the server running the Routing and Remote Access service is an IAS server, remote access policies are configured through Internet Authentication Service.

When you try to open the IAS console, you receive an error message and the console does not open.

Cause: To administer IAS, you must have Administrative credentials.

Solution: You can use the Runas command to perform tasks (for example, opening the IAS console), when you are logged on as a member of a group that does not have administrative credentials (such as Users or Power Users). Alternately, you can log on as Administrator to open the console.

See also: Run a program with administrative credentials; Create a shortcut using the runas command; Runas

Note

  • You can configure IAS in Windows Server 2003, Standard Edition, with a maximum of 50 RADIUS clients and a maximum of 2 remote RADIUS server groups. You can define a RADIUS client using a fully qualified domain name or an IP address, but you cannot define groups of RADIUS clients by specifying an IP address range. If the fully qualified domain name of a RADIUS client resolves to multiple IP addresses, the IAS server uses the first IP address returned in the DNS query. With IAS in Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, you can configure an unlimited number of RADIUS clients and remote RADIUS server groups. In addition, you can configure RADIUS clients by specifying an IP address range.