Archived from groups: microsoft.public.windows.networking.wireless (
More info?)
"Robert Irwin" <catfishpcAThotmailDOTcom> wrote in
news:uBPKv4fZEHA.2340@TK2MSFTNGP09.phx.gbl:
>
> "Wayne Tilton" <Wayne_Tilton@NoSpam.Yahoo.com> wrote in message
> news:Xns95206D2BBAE57NWDCLMIT@207.46.248.16...
>> "Robert Irwin" <catfishpcAThotmailDOTcom> wrote in
>> news:OkuTh#GZEHA.2840@TK2MSFTNGP11.phx.gbl:
>>
>> > 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
>>
>> --
>> Standard Disclaimer: I said it, they didn't, so blame me, not them!
>> Spam Avoidance: My reply address is invalid to confuse the spambots.
>> You can reach me at 'Wayne_Tilton at yahoo dot com'
>
>
> 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
Facebook
Twitter
Instagram