PEAP Wireless Access for Mac OS X

We are using a Micrsoft IAS server as our Radius authority, and are
attempting to set up PEAP authentication for our wireless network. On a PC,
the setup seems to work perfectly: the computer sees the wireless network,
attempts to authenticate, accepts our certificate and the user is prompted
for their network username and password.

On a Mac OS 10.3.7 computer, however, the computer sees the wireless network
and although we specify an 802.1x connection, the Mac does not prompt to
accept the certificate but rather immediately rejects the computer. This is
the error that shows up in the Event Log for the IAS server:

*************************************
User username was denied access.
Fully-Qualified-User-Name = GARNET\username
NAS-IP-Address = 10.10.10.10
NAS-Identifier = ap
Called-Station-Identifier = xxxx.xxxx.xxxx
Calling-Station-Identifier = xxxx.xxxx.xxxx
Client-Friendly-Name = AP PEAP Test
Client-IP-Address = 10.10.10.10
NAS-Port-Type = Wireless - IEEE 802.11
NAS-Port = 266
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = Allow Wireless PEAP Access (Test 1)
Authentication-Type = PEAP
EAP-Type = <undetermined>
Reason-Code = 16
Reason = Authentication was not successful because an unknown user name or
incorrect password was used.
*******************************************

We are using a self-signed certificate, and the goal is to get the Mac to
prompt users to accept the certificate and then authenticate to our IAS
server. The Mac does work when we download the certificate, transfer it to
the computer, and import it into the keychain, but we are trying to avoid
forcing the user to connect to the wired network before using the wireless
network.

If anyone has any suggestions, we would love to hear about them.

On 2005-01-17 11:01:07 -0500, "=?Utf-8?B?U3RldmVuIEthbmU=?="
<(E-Mail Removed)> said:

> We are using a self-signed certificate, and the goal is to get the Mac
> to prompt users to accept the certificate and then authenticate to our
> IAS server. The Mac does work when we download the certificate,
> transfer it to the computer, and import it into the keychain, but we
> are trying to avoid forcing the user to connect to the wired network
> before using the wireless network.

Based on my own experience with Mac OS X 10.3 and self-signed
certificates (or internally generated certificates from an internal
CA), I would say that you will have to get the Mac OS X clients to add
the root certificate to their keychain first. I have not personally
tested this with 802.1x, but I have seen identical behavior with SSL
certificates.

--
Scott Lowe

Right. the client computer must trust the issuer of the RADIUS server's certificate.
If the Mac in question has never seen any certificates from the issuing CA,
it will reject the RADIUS server's certificate. You need to import the CA's
certificate into the Mac.

Steve Riley
(E-Mail Removed)



> On 2005-01-17 11:01:07 -0500, "=?Utf-8?B?U3RldmVuIEthbmU=?="
> <(E-Mail Removed)> said:
>
>> We are using a self-signed certificate, and the goal is to get the
>> Mac to prompt users to accept the certificate and then authenticate
>> to our IAS server. The Mac does work when we download the
>> certificate, transfer it to the computer, and import it into the
>> keychain, but we are trying to avoid forcing the user to connect to
>> the wired network before using the wireless network.
>>
> Based on my own experience with Mac OS X 10.3 and self-signed
> certificates (or internally generated certificates from an internal
> CA), I would say that you will have to get the Mac OS X clients to add
> the root certificate to their keychain first. I have not personally
> tested this with 802.1x, but I have seen identical behavior with SSL
> certificates.
>

Automatic certificate deployment is something that only works with Windows
clients. With those clients group policy and a Windows 2003 server you can
automate certificate enrollment but this is not supported for third party
clients.

--
Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Steven Kane" <(E-Mail Removed)> wrote in message
news:CCBD3066-6302-4384-B2AE-(E-Mail Removed)...
> We are using a Micrsoft IAS server as our Radius authority, and are
> attempting to set up PEAP authentication for our wireless network. On a
> PC,
> the setup seems to work perfectly: the computer sees the wireless network,
> attempts to authenticate, accepts our certificate and the user is prompted
> for their network username and password.
>
> On a Mac OS 10.3.7 computer, however, the computer sees the wireless
> network
> and although we specify an 802.1x connection, the Mac does not prompt to
> accept the certificate but rather immediately rejects the computer. This
> is
> the error that shows up in the Event Log for the IAS server:
>
> *************************************
> User username was denied access.
> Fully-Qualified-User-Name = GARNET\username
> NAS-IP-Address = 10.10.10.10
> NAS-Identifier = ap
> Called-Station-Identifier = xxxx.xxxx.xxxx
> Calling-Station-Identifier = xxxx.xxxx.xxxx
> Client-Friendly-Name = AP PEAP Test
> Client-IP-Address = 10.10.10.10
> NAS-Port-Type = Wireless - IEEE 802.11
> NAS-Port = 266
> Proxy-Policy-Name = Use Windows authentication for all users
> Authentication-Provider = Windows
> Authentication-Server = <undetermined>
> Policy-Name = Allow Wireless PEAP Access (Test 1)
> Authentication-Type = PEAP
> EAP-Type = <undetermined>
> Reason-Code = 16
> Reason = Authentication was not successful because an unknown user name or
> incorrect password was used.
> *******************************************
>
> We are using a self-signed certificate, and the goal is to get the Mac to
> prompt users to accept the certificate and then authenticate to our IAS
> server. The Mac does work when we download the certificate, transfer it
> to
> the computer, and import it into the keychain, but we are trying to avoid
> forcing the user to connect to the wired network before using the wireless
> network.
>
> If anyone has any suggestions, we would love to hear about them.