Question: Can SBR make any auth flow decisions off of intermediate certificates presented to it by supplicants when running EAP-TLS?
Problem or Goal
For example: User certificates for Windows machines are signed by Subordinate CA(S1) and the Subordinate CA(S1) is signed by the Root (CA) User certificates for Apple devices are signed by Subordinate CA(S2) and the Subordinate CA(S2) is signed by the same Root (CA).
Can SBR be configured to reject S2 supplicants and accept S1 supplicants based on the intermediate certificate information?
The answer is it cannot.
SBR is designed to validate entire certificate chains using root certificates which is strict adherence to the EAP-TLS RFC. It does not have the ability to parse a certificate chain presented during the authentication for information. It only can validate the keying material and if it is valid.
It is required that the client/supplicant provide the entire certificate chain below the CA to SBR in order for validation to work properly. Using the above example the supplicant would have to provide their client certificate as well as the the S1 or S2 intermediate depending upon which one it's client cert was generate from.
If you need more advanced parsing of your certificate infrastructure during authentication, look at Pulse Policy Secure. It is a much more feature dense product that has the ability to parse intermediate certificates and assign role mapping based of that information.