[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: mschap: eapol_test peap/mschap fails
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2019-02-26 22:03:12
Message-ID: 703963F9-6E93-42B7-A6A5-C4E6444C1509 () deployingradius ! com
[Download RAW message or body]

On Feb 26, 2019, at 4:36 PM, Peter Kain <peter.kain@pepperdine.edu> wrote:
> I've been tasked with setting up a freeRADIUS (FR) server in order to
> join eduroam under the following conditions: authentication against
> Active Directory where we have two domains, the realm passed doesn't
> indicate the AD domain, and I can only join one domain "domainA", but
> there's trust between the domains.
> 
> realm = user@uni.edu
> domainA.ad.uni.edu
> domainB.ad.uni.edu
> 
> I've built a CentOS 7 server with FR 3.0.13 and winbind 4.8.3. Joined
> the server to the first domain and I'm able to authenticate users
> against both domains using the ntlm_auth command.

  Then those ntlm_auth commands should work for PEAP, too.

> As a first step, following the posted instructions "Configuring
> Authentication with Active Directory" I edited the mschap to use
> ntlm_auth setting "--domain=domainA".  And I've set radiusd to run as
> root. Using the eapol_test program I'm able to authenticate as userA
> using both "-c ttls-mschap.conf" & "-c peap-mschap.conf" and I'm able
> to authenticate my iPad to our wireless . So far everything works as
> expected when setup for a single domain.

  That's good.

> In order to authenticate to both AD domains I followed a forum posting
> "PEAP and multiple domains" and created two additional domain
> instances for mschap
> in the radius.conf and updated both the default and inner-tunnels.

  That might work.  It might also be too complex.  But whatever...

> raddb/radius.conf
> ...
> modules {

   We don't need to see the configuration files.  The message you get when you join \
the list says this.

> In the "authorize section {"  if mschap isn't commented out then it
> sets  "Auth-Type = mschap".  This seems contrary to the documentation
> within the file. Again running FR 3.0.13.
> 
> Commented out mschap adding "mschap.domainA".  This appears to set
> "Auth-Type = MS-CHAP".  I'm not sure how the "Auth-Type" is determine,
> why one configuration results in "Auth-Type = mschap" and another
> "Auth-Type = MS-CHAP".

  They're just synonyms. 


> Auth-Type MS-CHAP {
> # mschap
> group {
> mschap.domainA {
> reject = 1
> ok = return
> }
> mschap.domainB {
> ok = return

  You really shouldn't do that.  It is *very* bad practice to try to authenticate the \
user, and then if that fails, to try a different authentication method.

  The mschap module does cryptographic calculations.  If the user can't be \
authenticated, it adds an MS-CHAP rejection to the packet.  You then can't \
authenticate the user a second time....

  You should instead figure out which users are which, such as by checking the realm. \
Then for realm A do MSCHAP A, for realm B do MSCHAP B.

> My apologies for not posting the "radius -X" for the failed
> eapol_test. There are restrictions at my site about posting server
> logs, I'm working on it.

  If we don't know what's going wrong, we can't really help you.

> Questions:
> 
> 1)  Does it look like I've made any glaring mistakes or am I on the
> correct path?

  Mostly correct.  But you shouldn't run *two* mschap authentications.  Only one.  \
And, only the *right* one.

> 2) What can I do to make peap/mschap work under this circumstances?

  Since we don't know what's going wrong, I have no idea.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]