On Nov 2, 2016, at 2:48 PM, Daniel Wruck <daniel.wruck@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.