If the "Microsoft Smartcard Logon" extendedKeyUsage *is part* of your client certificates they might not work with Windows build-in supplicant.
This is not surprising, if that is the only EKU in the cert. In fact, in that situation, no correct server should accept the certificate for EAP-TLS, because the presence of any EKU means the certificate may _only_ be used for listed usages, and EAP-TLS is not smartcard-based logon. If you want to use a certificate for both purposes, then it must have both id-kp-ms-sc-logon and one of anyExtendedKeyUsage (2.5.29.37.0) or [sigh] id-kp-clientAuth (1.3.6.1.5.5.7.3.2). Unfortunately, RFC2716 does not discuss the details of certificate validation, but the rules for handling extended key usages are the same for all uses of PKIX; for details, see RFC3280 section 4.2.1.13. The replacement for RFC2716 is draft-simon-emu-rfc2716bis-13.txt, which was just approved as a Proposed Standard in the past week. It does discuss the details of certificate validation for EAP-TLS, in section 5.3.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu> Carnegie Mellon University - Pittsburgh, PA