OK, that makes sense. I thought all communication was happening between
the client and the PF server, and then the PF server (RADIUS) was then
establishing a separate connection to defer to the other server rather than
just tunnelling the connection.
OK, well... I had originally setup a separate RADIUS server because it
looks like the PF RADIUS instance is linked to the PF database. The
problem with that, is that I don't see a way to establish the NT Hash on
the passwords. I'd at least rather not store them plain-text. So I was
left with using either plaintext or setting up a separate server for
handling credentials.
Thanks,
Joshua Nathan
Level 3 IT Support and Development
Black Forest Academy
+49 (0) 7626-9161-630
On Mon, Apr 11, 2016 at 7:18 PM, Louis Munro <[email protected]> wrote:
> Hi Nathan,
>
> On Apr 11, 2016, at 10:21 , Nathan, Josh <[email protected]> wrote
>
>
> As a side note, I am actually forwarding credentials to another radius
> server to actually handle the authentication, as you'll see in the logs. I
> did bold within the RADIUS logs where it is showing the default SSL cert
> even though I have replaced the references to it in the eap.conf file with
> new certs that actually have legitimate information.
>
>
> Pretty big side note actually.
>
> If you are proxying authentication somewhere else, the certificate you are
> seeing is coming from that server, not the PacketFence one.
> Think about it: the cert comes from wherever the TLS tunnel terminates,
> not anywhere else along the way.
>
>
>
> While that certification reference bothers me, it still looks like the
> eapol_test is actually successful. Am I wrong?
>
>
> Yes and no.
> It looks to me like the server accepted the authentication but
> eapol_rejected the reply because of a mismatch in the MPPE keys.
>
> Note that the FreeRADIUS debugging output is not going to allow you to see
> what is going on between the supplicant and the radius server where the
> request is proxied.
> That data is encrypted between the supplicant and the (proxied-to) radius
> server.
>
> So your certificate issues cannot be resolved by editing eap.conf on the
> PacketFence server.
> Have a look a the config of the other server.
>
> Or, you could just authenticate from the PacketFence server ;-)
>
> Regards,
> --
> Louis Munro
> [email protected] :: www.inverse.ca
> +1.514.447.4918 x125 :: +1 (866) 353-6153 x125
> Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (
> www.packetfence.org)
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
> gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
> _______________________________________________
> PacketFence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
