Hi Simon,
Unfortunately ACS does not support wildcard certs. Here is the bug id,
Regards,
~JG
ACS 5 does not support wild card certificate I need some suggestions or solutions to this issue
Basically If you configure acs to use LDAP as the identity store, then the microsoft supplicant can not use the EAP/MSCHAP2.
You can select PEAP and configure Trusted Root CA with an imported CERT but there are no options to send the true USERNAME to the acs - instead the MS client sends the organization the cert was issued to
If you choose not to verify the cert the MS client sends the computername/user as the USERNAME
The only way around this is not to use the MS supplicant
You must use a 3rd party - which most are not free and depending on the version of windows may be different versions
It seems to me that others must have experienced this issue.
Overview of PEAP
PEAP is a client-server security architecture that you use to encrypt EAP transactions, thereby protecting the contents of EAP authentications. PEAP uses server-side public key certificates to authenticate the server.
It then creates an encrypted SSL/TLS tunnel between the client and the authentication server. The ensuing exchange of authentication information to authenticate the client is then encrypted and user credentials are safe from eavesdropping.
PEAP is similar to EAP-TLS but uses a different client authentication method. PEAP provides authentication, by using server certificates, a TLS tunnel and client authentication through that encrypted tunnel. Unlike EAP-TLS, PEAP requires the client to use another EAP type, like EAP-MSCHAPv2.
PEAP authentications always involve two phases:
•
In phase1, the end-user client authenticates ACS. This action requires a server certificate and authenticates ACS to the end-user client, ensuring that the user or machine credentials sent in phase two are sent to a AAA server that has a certificate issued by a trusted CA. The first phase uses a TLS handshake to establish an SSL tunnel between the end-user client and the AAA server.
Note Depending on the end-user client involved, the CA certificate for the CA that issued the ACS server certificate is likely to be required in local storage for trusted root CAs on the end-user client computer.
•In the second phase, ACS authenticates the user or machine credentials by using an EAP authentication protocol. The SSL tunnel that was created in phase1 protects the EAP authentication.
The inner-method authentication type that is negotiated during phase 2 can be either EAP-MSCHAPv2, EAP-GTC or EAP-TLS. The combination of the outer PEAP method with a specific inner EAP method is denoted using brackets (); for example, PEAP(EAP-MSCHAPv2) or PEAP(EAP-GTC).
An improvement in security that PEAP offers is identity protection. This improvement is the potential for protecting the username in all PEAP transactions. After phase one of PEAP, all data is encrypted, including username information that is usually sent in clear text.
The Microsoft PEAPv0 client does not provide identity protection; the Microsoft PEAPv0 client sends the username in clear text in phase one of PEAP authentication.
In ACS 5.3, PEAP is encapsulated in RADIUS protocol. Inner-method EAP messages are encapsulated in an EAP-TLV method.
ACS 5.3 supports these PEAP supplicants:
•Microsoft Built-In Clients 802.1x XP (PEAPv0 only)
•Microsoft Built-In Clients 802.1x Vista (PEAPv0 only)
•Microsoft Built-In Clients 802.1x Windows 7
•CSSC v.4.0
•CSSC v.5
•Funk Odyssey access client (latest version)
•Intel Supplicant 12.4.x
acs using LDAP DB Store does not support EAP/MSCHAP2
