eap-tls on non-domain computers?!

[Elias Pereira]

Thanks Alan, for your help and time!!!

On Mon, Oct 8, 2018 at 12:01 PM Alan DeKok <aland at deployingradius.com>
wrote:

> On Oct 8, 2018, at 8:12 AM, Elias Pereira <empbilly at gmail.com> wrote:
> > In my infra, it works as follows.
>
>   This explanation is better.
>
> > 1. The user downloads the p12 file containing the personal certificate,
> key
> > and CA;
> > 2. I made an automatic installer for windows;
> > 3. The installation of p12 is done via certutil and installs the
> > certificate and CA in the scope of the user;
> >
> > Freeradius check the CN of the certificate, which is the stripped
> username
> > + realm/domain of our AD. Once the verification is done, if it is in the
> > correct group, the redirection is made to the specific vlan.
>
>   So there's no real "AD" validation.  Just that the cert has certain
> fields, with specific values.
>
> > > If the computer has a correct client certificate, then they will be
> >> authenticated via EAP-TLS.
> >
> > In our infra, for computers that are in the domain, yes. Out of domain
> not.
>
>   That is entirely the wrong way to think about it.  And, the source of
> much confusion.
>
>   Users are authenticated with certs via EAP-TLS.  *Also* they have to
> pass authorization checks which you have added on top of EAP-TLS.  Those
> authorization checks do checks against the domain.
>
>   So how do you authenticate non-domain users with EAP-TLS?  Simple: don't
> do the added domain checks.
>
> > Because the certificate is installed in the user scope, after
> > wpa2-enterprise configuration, the authentication in freeradius is based
> on
> > the certificate that was installed for the user in question and belongs
> to
> > the domain. If you install on a computer that is not in the domain, the
> > certificate will not hit the user.
>
>   That is a convoluted and odd way to describe things.  A certificate does
> not "hit" a user.  A certificate is put into a particular certificate store.
>
>   Unclear thinking, and wrong vocabulary makes everything harder.  You
> can't describe the problem accurately, so you can't find a good solution.
>
> > Starting from the same user "test" AD
> >
> > Computer in the domain
> > User "test" of the domain login on the computer, downloads the
> > test at mydomain.tld certificate, installs and in authentication it is
> > verified that the certificate has the CN with the same user name of the
> > computer, ie, the AD user.
>
>   I find that really hard to understand.  It's vague, and not very clear.
>
> > Computer outside the domain
> > Local user "pc-local" login into the computer, downloads the certificate
> > test at mydomain.tld, installs and in authentication it is verified that
> the
> > certificate does not have the CN with the same user name of the computer,
> > ie, it is not the same the AD user.
>
>   I think you're confused as to how EAP-TLS works.
>
>   When the Windows box does EAP-TLS, it does it with the username && cert
> that is configured on the system.  If the user configures his AD username
> and uses the cert he downloaded, then that's what is sent via EAP-TLS.  The
> EAP-TLS communication has *no idea* whether or not the user has been logged
> into the AD domain.
>
>   Stop giving vague descriptions of the problem.  Start being precise.
> WHAT does the user configure on the Windows box?  What is sent in the
> EAP-TLS communication?  etc.
>
>   The other thing here is that you already have all of the information you
> need to solve the problem.  Just *do* the two configurations above, and see
> how the EAP-TLS authentication is different. If they show the same
> User-Name and the same certificate, then that's that.  The authentications
> look the same because they are the same.
>
>   If they show differences, then you can see what the differences are.
> Then, configure FreeRADIUS to look for those differences, and treat them
> differently.
>
>   This process involves running the server in debug mode, and reading the
> output.  It's why we ALWAYS say to run it in debug mode and read the
> output.  It's really the only thing that tells you what's going on.
>
>   And, the debug output is *much* better than a vague description:  "I
> configured stuff on Windows, and now I want FreeRADIUS to do stuff with
> whatever the Windows box sends."
>
>   Vague questions get vague answers.  Good questions get good answers.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html



-- 
Elias Pereira