On 11/8/05, <b class="gmail_sendername">Michael Griego</b> <<a href="mailto:mgriego@utdallas.edu">mgriego@utdallas.edu</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>Ben Walding wrote:<br>> We've found in testing that the XP supplicant (with certain patches)<br>> will read the certificate and send a User-Name that is constructed<br>> from the certificate CN (host/ + cert CN); thus rendering the whole

<br>> "checking the CN process" fairly pointless for XP supplicants.<br><br>This is only true when a certificate is used for machine authentication,<br>not for user authentication.</blockquote><div><br>Ahh, this explains a thing or two!  We knew we'd seen behaviour where it sent the machine name rather than the name of the certificate earlier in our testing.  But couldn't replicate it  (since we had locked everything down to machine auth by the final stages). 

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">To get around the the problem stated above, all you have to do is create<br>two instances of the EAP module.  In cases where the User-Name attribute

<br>begins with "host/", just send those authentications to the second EAP<br>module, and have the check_cert_cn parameter set to check for<br>"host/%{User-Name}".  This way you can still be assured of proper

<br>authorization.<br></blockquote></div><br>We added a few lines into hints - <br><br>DEFAULT Prefix == "host/"<br>        Hint = "Wireless-Workstation"<br><br>DEFAULT Prefix == "host\\"<br>

Hint = "Wireless-Workstation" DEFAULT Prefix == "\\"         Hint = "Wireless-PDA" This resolved the issues we saw with prefixes and let us identify PDAs as they authenticated into the system (not that we do anything with this piece of information).

<br><br><br>Cheers,<br><br>Ben<br><br>