AD Auth Question

[Alan DeKok]

On Jan 1, 2018, at 9:04 AM, Martin, Jeremy <jmartin at emcc.edu> wrote:
> 
> So at this point I am beyond certain that I have valid certificates and that those are trusted.  The ca is the ca for the domain and the server certificate has the correct oid attributes to support the authentication, they paths on the server have been verified and as previously mentioned I have even used certs from my Windows NPS server on this server to make sure trust and certs were good.  

  Then something else is going on.  Maybe OpenSSL / TLS related?

> I think there is little disagreement that the issues on the challenge response part as comparing the trace and the event log of the client has the client generating the “Explicit Eap failure received”.

  The client is lying to you.  If FreeRADIUS had sent an EAP failure, you would see the EAP failure in the debug log.

> When I mentioned disabling validation on the client I am referring to the need for the client to validate the trust of the certificates being used by the server i.e under the clients 802.1x profile on the security tab, properties and then the “Verify the server’s identity by validating the certificate”.  In this case I know the certificate I have specified is valid and issued from a trusted ca, my question really is how to I validate that FR is actually using the certificate and is generating valid data using the specified certificate

  If it's the only certificate you configured in FreeRADIUS... FreeRADIUS is using it.

  As for "generating valid data", that's a larger problem.  The TLS portions of EAP-TLS or PEAP is implemented by OpenSSL.  It has more code than FreeRADIUS.  It's also full of what can only be described as TLS magic...

  There are a LOT of things going on in TLS.  FreeRADIUS tells you all of that in the debug log.

  Windows doesn't.  So people blame FreeRADIUS.

> as the behavior of the client seems to indicate that it is not as I know the following:
> 
> 1. The behavior of the client is correct using NPS
> 2. The client has a trust of the ca
> 3. The FR certificates validate against the ca
> 4. When viewing the certificate of FR on the client (file copy) the certificate indicates that it is trusted and has the correct extended use attributes
> 5. The client has the same behavior against FR when both) A. the certificates created for FR or; B) the certificates and private key from NPS are loaded on the FR are used

  Then it's a TLS / OpenSSL issue.

  Try disabling tls 1.2.  That might help.  There have been a lot of interoperability issues there.

> I would use the certificates on NPS that I generated for FR to prove but the system would not use them as the name of that host does not match the certificate

  EAP doesn't use host names.  FreeRADIUS doesn't care about certificate names matching host names.

> and you can’t specify a non matched certificate to be used in NPS.
> 
> I just had a thought that perhaps FR didn’t have permission to read the certificates in the folder but I just checked that and it does: so that is not it.

  If it didn't have permission to read the certs, you would see that in the debug output.

>  I know we have the radtest and eapol_test just wondering if there is a utility for verifying encrypted data FR is sending so I can track down where the issue is as I have pretty much eliminated the client by all available means thus far, which just leaves me one place - FR.

  Or OpenSSL.  Which implements *all* of the TLS stack.  We just implement EAP, and link to / use the TLS bits.

  TBH, I'd try using 3.0.15, which has other fixes over 3.0.13.  And, disable tls 1.2.  See raddb/mods-available/eap in newer versions of the server.

  Alan DeKok.