radtest passes test, phone connects to WiFi, but laptop does not

[Alan DeKok]

On Nov 2, 2016, at 2:48 PM, Daniel Wruck <daniel.wruck at fbchammond.com> wrote:
> I have FreeRADIUS 3.0.12 set up on an Ubuntu 16.04 box. I believe that I have most everything working (except maybe sql). I have an AD forest with 1 domain (fbcexample.com) and 3 child domains (hac.fbcexample.com, cbs.fbcexample.com, and hac.fbcexample.com). I created 4 named mschap modules so that I could hard code the --domain property in each one.

  That's not a good idea.

> I can successfully rad test from each of my 4 domains against it including group membership.

  Those domains should all be part of one AD forest.  i.e. they are NOT 4 different AD servers.  They are one server, with 4 domains.

> Then I setup a test SSID on my aruba controller.  I can connect via my android phone (with just username & pass), but connecting a laptop to is not working (it appears that it is sending domain as a part of username). It seems that there is more security stuff going on when the laptop connects; maybe I don't have MSCHAPv2 configured right? Something broken in realms?

  The recommendation as always is to start simple, and then once it works, add something else.  Starting with a complex configuration is a guaranteed way to never get it working.

> When the Win 10 x64 laptop connects, radius -X first shows that it is trying to connect via computer name. Then a box pops up asking for username and password with a checkmark for 'Use my Windows user account", I choose and continue. Radius -X shows that several more requests are made and then windows sows 'Can't connect to this network'. Any suggestions on where my problem is?

  Start with a simple configuration.  One domain, and see if it works.  This should be simple:

http://deployingradius.com/documents/configuration/active_directory.html

> I created the CA and server certs and have believe them to be correctly installed. But not sure that this has anything to do with the problem descripted above.

  Probably not.

> Examples of the code that I am running. I included a pastebin for the 3000 lines of radius -X output.
> WORKING RADTEST LINE
> radtest -t mschap daniel.radius  passw0rd 127.0.0.1 0 testing123

  That's a good test.

> 
> ABBREVIATED MSCHAP MODULE
> mschap mschap_fbc {
>        ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --domain=fbcexample --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap_fbc:Challenge}:-00} --nt-response=%{%{mschap_fbc:NT-Response}:-00}  --require-membership-of='fbcexample\\LDAP_WiFi'"
> 
>      . . .
> }

  That's... likely a problem.  It should work, but why hard-code the domain?

> DEFAULT SITE AUTHENICATE SECTION
> authenticate {
>  . . .
> #  MSCHAP authentication.
>        Auth-Type MS-CHAP {
>            mschap_fbc {
>                reject = 2
>             }
>             if (reject){
>                mschap_hac
>                reject = 2
>             }
>             if (reject){
>                mschap_hbs
>                reject = 2
>             }
>             if (reject){
>                mschap_cbs
>                reject = 2
>             }
>        }
>  . . .
> }

  That's a *terrible* idea.  Don't do that.  Ever.  It will destroy your AD servers with traffic.

  AD can't really handle any kind of traffic load.  Maybe a few dozens of packets a second.  Increasing the load by a factor of 4 is bad.

  The simpler solution, and the one everyone else uses, is to just require users to login with their domain.

  Follow the examples from the web site, which have a hard-coded domain.  Then, change the MS-CHAP module configuration to:

       exec ntlm_auth {
                wait = yes
                program = "/path/to/ntlm_auth --request-nt-key --domain=%{mschap:NT-Domain} --username=%{mschap:User-Name} --password=%{User-Password}"
        }

 Which should work.

  The idea is that once you have the domain in the Access-Request, you just pass it to AD.  You don't care what the *value* of the domain is, because AD will do the checking for you.

  That way you have one RADIUS configuration, and it works for 4 domains.

  Your current configuration is slow, complex, and will regularly take down your AD server.

  Alan DeKok.