Ben Walding wrote:
We've found in testing that the XP supplicant (with certain patches) will read the certificate and send a User-Name that is constructed from the certificate CN (host/ + cert CN); thus rendering the whole "checking the CN process" fairly pointless for XP supplicants.
This is only true when a certificate is used for machine authentication, not for user authentication. The true point of the check_cert_cn option is to ensure that any attributes added during authorization are ensured to be matched to the certificate. This way, you can be sure that, for instance, a user that has a bandwidth-limiting attribute added to the reply us truly authenticating as that user, not just presenting an identity with greater privileges and authenticating as a user with lower privileges. To get around the the problem stated above, all you have to do is create two instances of the EAP module. In cases where the User-Name attribute begins with "host/", just send those authentications to the second EAP module, and have the check_cert_cn parameter set to check for "host/%{User-Name}". This way you can still be assured of proper authorization. --Mike