eap-tls on non-domain computers?!

[Alan DeKok]

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.