Simultaneous EAP-TLS and PEAP-MSCHAPv2 (machine/user authentication)

[Ben Humpert]

So in short you simply want to authenticate with either username / password
OR a certificate.

You can do that with Windows natively, regardless of wired or wireless
connection. However, each client has to be configured. There is no
Plug&Play.

If you don't have a certificate for a given client enable PEAP in the NIC
Authentication settings. If you have a certificate enable "Smartcard or
other certificate". For EAP-TLS FreeRADIUS is already ready to go, just
give it the required certificates, keys, etc.

For PEAP you need to add your users and their passwords to the users file.

The Windows settings are kind of confusing (and sometimes really stupid)
and I can only help you with them (as well as Android/iOS) since I don't
have any Linux or Mac clients.

2015-12-26 18:45 GMT+01:00 Lukas Haase <lukashaase at gmx.at>:

> Hi Ben,
>
> On 2015-12-26 15:55, Ben Humpert wrote:
> > Windows can't do machine authentication and then additionally user
> > authentication. You can do either do machine OR user auth. It is kind of
> > annoying.
>
> This is not what I want anyway. Once again the intended setup:
>
> 1.) Client presents a certificate signed by the CA -> authentication
> should succeed ("machine authentication"). (I thought this would best be
> done via EAP-TLS but not sure)
>
> 2.) If the client does NOT have a client certificate signed by the CA
> installed it should query for username/password ("user authentication")
> exactly as in my current setup. Authentication should succeed via
> PEAP-MSCHAPv2 if correct credentials are presented.
>
> Luke
>
>
>
> > 2015-12-26 15:07 GMT+01:00 Alan DeKok <aland at deployingradius.com>:
> >
> >> On Dec 25, 2015, at 5:42 AM, Lukas Haase <lukashaase at gmx.at> wrote:
> >>> However, I found tons of references and howtos where it is stated that
> >>> (a) installing certificates on the client is optional (b) using a
> server
> >>> certificate signed by an official CA is recommended.
> >>
> >>   The only reason (a) *might* be true is if you believe (b).  Which I
> >> don't.
> >>
> >>   When you allow a public CA for a particular SSID, it means that *any*
> >> certificate issued by that CA will be allowed for that SSID.
> >>
> >>   This isn't what you want.
> >>
> >>   We recommend using a self-signed CA, because it's more secure.  The
> >> people who recommend using public CAs generally don't know what they're
> >> talking about.
> >>
> >>>>  Windows can do machine-level authentication, by automatically
> >> provisioning the certificates.
> >>>
> >>> I cannot find good references to that; do you have a pointer?
> >>
> >>   It's done via Active Directory.  See that documentation.
> >>
> >>>>  For every other system, there is no "machine auth".  There are only
> >> user accounts, and user credentials.
> >>>
> >>> At least I could use a users file containing "machine" accounts with
> >>> long passwords ... but this is again much more difficult than just
> >>> deploying a simple certificate file.
> >>
> >>   Why would you do this in the first place?
> >>
> >>   You can only authenticate once with 802.1X.  Once you're
> authenticated,
> >> you're in the network.  802.1X has no concept of "machine" accounts
> versus
> >> "people" accounts.
> >>
> >>> In that case: Why then sign the client certificate with the server cert
> >>> at all?
> >>
> >>   You don't.  You sign the client certificate with the CA cert.
> >>
> >>>>  You can't do both on the same machine in the same account.
> >>>
> >>> What do you mean by "same account"?
> >>
> >>   Why do you think there are multiple accounts?  Do you think there are
> >> multiple 802.1X authentications?
> >>
> >>   The problem here is that you have certain assumptions about how things
> >> work.  Those assumptions are wrong.  I'm trying to correct them, but
> >> because your assumptions and terminology are wrong, you're not really
> >> understanding my answers.
> >>
> >>> I really can't use anything in parallel with PEAP?
> >>
> >>   You can't authenticate twice in 802.1X.  Once a system is
> authenticated,
> >> it's on the network.
> >>
> >>   i.e. you're asking the wrong questions.
> >>
> >>> As mentioned, in this case too many broken howtos and references out
> >>> there :(
> >>
> >>   I'm saying what you should do.  You can
> >>
> >>   (a) believe it and follow instructions, and get the systems on the
> net,
> >>
> >>   or
> >>
> >>   (b) ignore what I'm saying, keep with whatever ideas you have, and not
> >> get anything done.
> >>
> >>   Pick one.
> >>
> >>> Again ... with machine you mean the client or the RADIUS server?
> >>
> >>   I mean supplicant / laptop / desktop.  Once a system is on the net,
> it's
> >> on the net.
> >>
> >>   How do *you* expect to use EAP-TLS and PEAP at the same time, from the
> >> same machine?
> >>
> >>   Please explain.
> >>
> >>> Per "end user account" I *only* want to use PEAP-MSCHAPv2 (because it
> is
> >>> most widely supported) using login/password information looked up via
> >>> OpenLDAP (this works).
> >>
> >>   Sure.
> >>
> >>> Independently from an "end user account" I would like the
> authentication
> >>> to succeed when the client presents a certificate signed by the server,
> >>> same as it is the case for OpenVPN in PKI mode. I think this can be
> done
> >>> with EAP-TLS.
> >>
> >>   Sure.
> >>
> >>   But... how do you expect EAP-TLS and PEAP to work together?
> >>
> >>   Explain.  In detail.
> >>
> >>> So if FreeRADIUS can't be set up serving EAP-TLS and PEAP-MSCHAPv2 at
> >>> the same time,
> >>
> >>   You're not paying attention.
> >>
> >>   It's not a FreeRADIUS limitation.  It's a limitation of the machine
> >> trying to get on the network, and the network.
> >>
> >>> can't it be configured with virtual servers?
> >>> For example, there is "modules/inner-eap" which contains a separate TLS
> >>> configuration. I though this is the key to the correct configuration.
> >>
> >>   It helps to understand the concepts before trying random solutions.
> >>
> >>>>   It's impossible.  You can only have one 802.1X configuration per end
> >> user account.
> >>>
> >>> What I mean: There are tons of deployments in companies supporting
> which
> >>> present a username/password prompt when connecting to the network but
> >>> connect automatically without a prompt when a certain certificate is
> >>> installed on the system.
> >>
> >>   Sure.  That' s doing *either* PEAP or EAP-TLS.  Only one 802.1X
> >> configuration is active at a time.
> >>
> >>> I've seen that. So I assume this is a very
> >>> common setup which shouldn't be too hard to implement.
> >>
> >>   Authenticating one machine using EAP-TLS and PEAP at the same time is
> >> impossible.
> >>
> >>   FreeRADIUS can authenticate anything.  If one machine does EAP-TLS,
> and
> >> another does PEAP.  That's fine.  If one machine does EAP-TLS, logs off
> of
> >> the network, and then comes back with PEAP, that's fine.
> >>
> >>   Please understand what I'm saying.  You have some kind of assumption
> >> about how the network works.  Those assumptions are wrong.  Because
> those
> >> assumptions are wrong, you're asking the wrong questions.  And not
> >> understanding my answers.
> >>
> >>   It's really quite simple. Configure a system to do:
> >>
> >>   a) PEAP
> >>
> >> or
> >>
> >>   b) EAP-TLS.
> >>
> >>   Pick one.  It will be able to do 802.1X and get on the network.
> >>
> >>   Doing some kind of magical "PEAP and EAP-TLS at the same time" is
> >> impossible.  Stop trying to do it.  You're wasting everyones time.
> >>
> >>   Alan DeKok.
> >>
> >>
> >> -
> >> List info/subscribe/unsubscribe? See
> >> http://www.freeradius.org/list/users.html
> >>
> > -
> > List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
> >
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>