ISE EAP-FAST chaining EAP-TLS inner method - authorizing against AD

Question

Just a question surrounding EAP-FAST chaining (EAP-TLS inner)  and the ability to authorize the username in the CN field of the certificate against AD. As an example for standard EAP-TLS I am able to specifiy that the username should be in a specific AD group. WIth EAP-FAST I seem unable to get the same functionality working - I suspect it is using the combined Chained username to poll with. Any advice would be much appreciated as I would like to differentiate users in different groups whilst retaining the EAP-TLS inner method.

Answer 1

I have found the answer to my own question. In short my issues came down to the way that Microsoft populates the certificate subject fields in particular user certificates and the CN field.
In my deployment I am using a single SSID with the following protocols:
EAP-FAST (EAP-TLS inner) - Certs deployed via AD GPO
EAP-TLS Machine Certs - Certs deploted via AD GPO
EAP-TLS User Certs - Certs deployed via ISE and SCEP (utilising PEAP to auth the user)
EAP-PEAP for Guest and onboarding purposes (no guest portal or MAB - not using the guest portal and CWA is awesome in my opinion).
My certificate profile, created in ISE, utilised the CN field in the subject for principle username. This configuration works fine for machine certs and user certifcates generated via ISE as the CN field is acceptable for matching against AD. The problem however is that the user certs issued by AD GPO etc utilise the AD CN which as I understand cannot be used to ascertain group membership in AD.
The solution seemed obvious - create a new cert profile that utilises the SAN field of the certifcate which is populated with "other name" attributes that can be matched against AD groups. The problem however is that my authentication policy for EAP protocols only allows the selection of one cert profile.... By using the SAN cert profile my EAP-TLS authentications broke but allowed successful auth of the EAP-FAST clients - not a good result.
I figured that the a failure to match the first authentication policy (based on not matching allowed protocol) would then carry on to the next authentication policy allowing me to specifiy a different cert profile - again no dice as the first policy is matched on the wireless 802.1x condition but EAP-FAST protocol was not specified as an allowed protocol and it fails.
The way around this was, lucky in my mind, basically I now match wireless 802.1x condition and Network Access Type:EAP-Chaining which allows me to specify the SAN cert profile for EAP-FAST connections. EAP-TLS obviously does not match the first authentication policy at all as it is not chaining. The subsequent policy is matched for EAP-TLS which specifies the CN cert profile.
I know this explantion is long winded and perhaps obvious to some so for that I apologise. For those of you who are undertaking this and run into the same drama I hope it helps. Feel free to contact me for more information or clarification as this explanation is a mouthful to say the least.