Does EAP-TLS *NEED* Windows 2003 server?

Does EAP-TLS work with Windows 2000 server, or do I need Windows server
2003?

If it should work on Windows 2000 server, where should I look to
troubleshoot if I can connect using PEAP using password authentication, but
PEAP won't work with certificates.

....which is no use to me as it is a primary school network and half my users
have no password or a 2 letter one. I'm fully aware this is bad.

Logically I should be looking at certificate server of course ( using Cert
authority on 2000 server, has its own key) - clients are XP SP1 with wifi
rollup patch.

Autoenrollment is on in group policy - seems working as machine and user
both have certificates according to CA

AP is a Dlink 2100AP access point set on WPA (non-PSK mode)

IAS server logs are extremely vague.



Robert Irwin

 

EAP-TLS works under Windows 2000 as long as you have Q313664 installed (or
SP4). The hotfix needs to be installed on the RADIUS (IAS) server as well
as any Win2k clients, if you have them. WinXP w/SP1 doesn't require
anything extra.

PEAP (Protected EAP) uses Windows credentials for authentication; it
doesn't use certificates (other than the one on the RADIUS server), so
you're correct, PEAP won't work with certificates because it's not supposed
to.

EAP/TLS uses certificates; one for the RADIUS server, one for the user and
if machine authentication is used, one for the machine. There are some
(poorly documented) requirements for the certificates, specifically for the
machine certificate the Subject Alternate Name must contain the fully
qualified DNS host name, as stored in the dnsHostName attribute of the
computer object, and for the user certs, the Subject Alternate Name must
contain the userPrincipalName from the user object.

Debugging can get quite tricky but the two places you're likely to get the
most information from are the IAS logs and the event log on the IAS server.
The certificate servers don't come in to play here. The Win2k ResKit
contains the IASPARSE.EXE utility which makes reading the logs much easier.
It's also possible to enable client side tracing using the NETSH command
and, depending on the capabilites of your AP, it may have some useful
logging information, too.

Hope that helps,

Wayne Tilton

 

I'm a little confused by you saying PEAP doesn't support certificates - in
the Windows XP client authentication setup you can choose to authenticate
either MSCHAP or 'Smart card or certificate' in the menus. Is this just a
red-herring then? I have read several documents saying explicitly that PEAP
does support certificates - just that it isn't the nromal way it works.


The FQDN bit could be part of my problem though - I have inherited a single
name (no suffix) domain because of upgrading from NT - I already had grief
with this as SP4 disabled such domains to be registered in DNS. I had only
got as far as fixing it on the servers so they could talk to each other and
left the clients chatting over Windows networking.


Robert

 

Robert,

I stand corrected...I did all my PEAP testing on a Win2k machine and
never noticed that the dropdown had more than 1 option (the dialog box is
scrunched on Win2k and you can barely see the scroll controlls).

But I suspect the requirements are the same, DNS wise. I also realized I
left out one little detail. The Primary DNS Suffix (Right click My
Computer, Select Properties, Computer Name, Change, More...) must match
the value stored in the dnsHostName attribute on the computer object in
AD which must be stored in the Subject Alternate Name in the certificate.
This is different than connection specific DNS settings made on the NIC,
which doesn't come into play here.

I suspect, although I haven't verified, that as long as those two match,
the certificate will be usable, even if they don't match the FQDN of the
AD domain. The event log on the IAS server should note this as 'The
specified user does not exist' if it doesn't like the user. The trick is
that the dnsHostName attribute is a 'validated write' and AD won't let
the computer put an abritrary value in there. There is nothing to stop
you from updating it manually (e.g. ADSIEDIT) or using an ADSI script, as
long as it is done before the cert is requested and they match, it just
might work.

Good luck!

Wayne