AD Auth Question

[Martin, Jeremy]

Allan

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.  

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”. 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 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

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 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.  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.

Again thanks for the time and attention.

Jeremy


> On Jan 1, 2018, at 8:32 AM, Alan Buxey <alan.buxey at gmail.com> wrote:
> 
> hi,
> 
> 
> On 1 January 2018 at 12:38, Martin, Jeremy <jmartin at emcc.edu> wrote:
>> Ok so this is correct the version that gets distributed with RHEL is 3.0.4 which was installed when the system was deployed and was updated to 3.0.13 as that is the current release within the system.  So now I  have two questions based on this and the work that I have put in while continuing to work on this issue:
>> 
>> 1.  Is it common practice to have to destroy the configurations for FR updates?  I would seem this could become an issue to put everything back in the configuration files if we can’t upgrade one from version to the next.  Is there a utility that is included to account for these types of issues so that FR doesn’t need to “redeployed” repeatedly?
> 
> for 2.x to 2.x or 3.x to 3.x no - but for 2.x to 3.x yes, you need to
> start with new config and make your changes to the new config to match
> what the old 2.x did - the same will be true for 4.x
> (from 2.x or from 3.x!)
> 
> note, however, that if you you do a 3.x to 3.x upgrade, there may be
> new features/methods/options etc options that wont be in your old
> config...i always keep a copy of the
> vanilla source configs to use as a reference.  I also avoid, where
> possible, using the default files (apart from the main radiusd.conf
> etc - for the virtual machines, make your own copies,
> change/modify and use those.... then use the default/inner etc as
> reference guides... nicely left in sites-available/ - do the same for
> modules that you need to heavily customise.
> define your OWN policy.d file and use that for local requirements -
> dont adjust the provided ones (they just have useful templates and
> basic things ready for best practice - use those as is :) )
> 
>> 2. Putting in that missing statement, at least for testing, seem to get this moving forward for a bit not all the way.  I was able to get the "radtest -t mschap testuser simplepass 127.0.0.1:18120 0 testing123” to work as well as a eapol_test mschapv2 test to work so at least I can connect to a single directory for the moment but here is the ugly part:  the client seems to stop communicating part way through the process, from reading the available resources it would seem that this can indicate a “trust” issue when the client just stops communicating.  I would agree as this appears to be the case from checking the clients event viewer:
>> 
>> Intel(R) Ethernet Connection I217-LM
>> host/lellis.emcc.edu
>> -
>> -
>> 0
>> 327685
>> Explicit Eap failure received
>> 0
>> 
>> I am assuming that is what is going on here anyways.  So I went back and regenerated a certificate request on the FR server signed it with the appropriate OID for sever authentication, double checked the output to make sure the chain is valid and the extended uses are correct then double checked the configuration files to make sure I was pointing to the new files and tried it again, same result.  So I then went to great effort to export the keys and certificates from my NPS server as I know these are trusted and working as they are currently doing the authentication and assignment for this process and put them on the FR server, same result the client generates the same error client side.
> 
> 
> firstly, you will need the right certs for the job on your RADIUS
> server if it is terminating EAP - and you will need to ensure that the
> client has the relevant/trusted root (and intermediates if you are not
> serving those from the
> FR server)  installed in the relevant place for that client....eg
> machine trusted root store   - this will be the same for any RADIUS
> server you use..its the basics of EAP and RADIUS
> 
> 
>> So at this point I know I have a good working trust, good working certificates and a good working client when used against a known working server.  So this leads me to the question, how do I verify and validate that FR is encrypting data correctly as the client seems to indicate it is not by its behavior.  I could disable client validation to test but this would effect hundreds of computers in production and I don’t think I am willing to take a chance on changing that GPO.
> 
> 
> ?? please explain what you meab - there is no option in EAP to not
> encrypt the data - the data will be, by its TLS nature, encrypted
> between the client and the server that is terminating EAP
> what behaviour on the client are you talking about?
> 
> your debug output shows an EAP conversation that doesnt complete -
> hanging on the challenge repsonse part.
> 
> alan
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html