AD Auth Question

[Alan Buxey]

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