- Freeradius-Users - lists.freeradius.org

Update User-Name
by Dale Lloyd 11 Sep '17

11 Sep '17

FreeRADIUS Version 3.0.4 I wish to modify the User-Name attribute in access-requests by appending the realm, but if I do that, FreeRADIUS refuses to proxy the request. I added the following to /etc/raddb/sites-enabled/default: authorize { if("%{User-Name}" !~ /@/) { update request { User-Name := "%{User-Name}(a)uni.ac.uk" Realm := "eduroam" } ... radiusd -X output: Ready to process requests Received Access-Request Id 0 from 10.10.200.254:36488 to 10.10.2.53:1812 length 148 User-Name = 'testuser' NAS-IP-Address = 6.71.67.224 Calling-Station-Id = '00-00-00-00-00-02' Called-Station-Id = '88-15-44-47-43-E0:TEST' Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = 'CONNECT 11Mbps 802.11b' EAP-Message = 0x0200000d01756e697431323334 Message-Authenticator = 0xca24c7b4bfe0fa73b421bc8c9c1e29a5 (0) Received Access-Request packet from host 10.10.200.254 port 36488, id=0, length=148 (0) User-Name = 'testuser' (0) NAS-IP-Address = 6.71.67.224 (0) Calling-Station-Id = '00-00-00-00-00-02' (0) Called-Station-Id = '88-15-44-47-43-E0:TEST' (0) Framed-MTU = 1400 (0) NAS-Port-Type = Wireless-802.11 (0) Connect-Info = 'CONNECT 11Mbps 802.11b' (0) EAP-Message = 0x0200000d01756e697431323334 (0) Message-Authenticator = 0xca24c7b4bfe0fa73b421bc8c9c1e29a5 (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { (0) if ("%{User-Name}" !~ /@/) (0) EXPAND %{User-Name} (0) --> testuser (0) if ("%{User-Name}" !~ /@/) -> TRUE (0) if ("%{User-Name}" !~ /@/) { (0) update request { (0) EXPAND %{User-Name}(a)uni.ac.uk (0) --> testuser(a)uni.ac.uk (0) User-Name := "testuser(a)uni.ac.uk" (0) Realm := 'eduroam' (0) } # update request = noop (0) } # if ("%{User-Name}" !~ /@/) = noop (0) filter_username filter_username { (0) if (!&User-Name) (0) if (!&User-Name) -> FALSE (0) if (&User-Name =~ / /) (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@.*@/ ) (0) if (&User-Name =~ /@.*@/ ) -> FALSE (0) if (&User-Name =~ /\\.\\./ ) (0) if (&User-Name =~ /\\.\\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\\.(.+)$/)) (0) if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\\.$/) (0) if (&User-Name =~ /\\.$/) -> FALSE (0) if (&User-Name =~ /(a)\\./) (0) if (&User-Name =~ /(a)\\./) -> FALSE (0) } # filter_username filter_username = noop (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix : Request already has destination realm set. Ignoring (0) [suffix] = noop (0) eap : Peer sent code Response (2) ID 0 length 13 (0) eap : EAP-Identity reply, returning 'ok' so we can short-circuit the rest of authorize (0) [eap] = ok (0) } # authorize = ok (0) Found Auth-Type = EAP (0) # Executing group from file /etc/raddb/sites-enabled/default (0) authenticate { (0) eap : Identity does not match User-Name, setting from EAP Identity (0) eap : Failed in handler (0) [eap] = invalid (0) } # authenticate = invalid (0) Failed to authenticate the user (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/raddb/sites-enabled/default (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject : EXPAND %{User-Name} (0) attr_filter.access_reject : --> testuser(a)uni.ac.uk (0) attr_filter.access_reject : Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) eap : Identity does not match User-Name, setting from EAP Identity (0) eap : Failed to get handler, probably already removed, not inserting EAP-Failure (0) [eap] = noop (0) remove_reply_message_if_eap remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else else { (0) [noop] = noop (0) } # else else = noop (0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop (0) } # Post-Auth-Type REJECT = updated (0) Delaying response for 1 seconds Waking up in 0.3 seconds. Suggestions greatly appreciated.

4 8

Re: Update User-Name
by Alan Buxey 11 Sep '17

11 Sep '17

No no no Please don't do this. If users have incorrect configuration (missing realm) then those users need to be corrected. If that org lets it's users get online without realm then that is not following best practice but means that those users won't work at other eduroam sites anyway So, not only do you cause confusion (but it works at my home org and place down road but nowhere else - this will then waste other sites time/effort 'we must be doing something wrong as this user can work at another site other than home' ) But you will also be causing other users problems... Those users from elsewhere than that org who also don't have realm set ... Who will, instead of being rejected as they should, will now be proxied to the completely wrong site and end up with misconfiguration or sending their details to wrong place. Just REJECT misconfigured users And check with eduroam UK policy to see if it's been updated yet that eduroam auths MUST have the realm even for local auths ... Otherwise a while can of worms gets opened up. don't create policies just because of a bad neighbor. Get them to fix the system. Contact eduroam UK if required to get channels of communication established. alan On 9 Sep 2017 7:20 pm, "Dale Lloyd" <dale.lloyd(a)gmail.com> wrote: Thank you, Alan, for taking the time to reply. > You should really use 3.0.15. Apologies, I followed the example in the FreeRADIUS Technical Guide and typed "yum install freeradius" and this is the version it installed. I will go back and install 3.0.15 manually. > No... read the debug output. The error is something else. When testing and specifying the full username on the client e.g. 'user(a)uni.ac.uk', everything works. Specifying just the short username on the client 'user' fails. Using a packet capture, I see that the request does not get forwarded as hoped. I read the output of radiusd -X and noticed the EAP error, but I don't know whether it is possible to overcome it? > If they're your users, then you should authenticate them. You don't need to edit the User-Name. You don't need to proxy. > Describe the problem you're trying to solve. We are a small entity next to a big university. The neighbouring university allows its users to connect to eduroam locally without specifying the realm in the username, but this can lead to problems because their users are often not aware that they need to use the full username if they wish to roam. We get many visitors from the university and their perception is that our wireless is broken. I want to make it easier for those visitors to connect to eduroam, because I can't explain to all visitors that they should user their full username. I need to proxy and I think that need to add the realm to the username, otherwise the eduroam NRPS won't know what to do with the request. On 9 September 2017 at 18:03, Alan DeKok <aland(a)deployingradius.com> wrote: > On Sep 9, 2017, at 10:11 AM, Dale Lloyd <dale.lloyd(a)gmail.com> wrote: >> >> FreeRADIUS Version 3.0.4 > > You should really use 3.0.15. > >> I wish to modify the User-Name attribute in access-requests by >> appending the realm, but if I do that, FreeRADIUS refuses to proxy the >> request. > > No... read the debug output. The error is something else. > >> I added the following to /etc/raddb/sites-enabled/default: >> >> authorize { >> >> if("%{User-Name}" !~ /@/) { >> update request { >> User-Name := "%{User-Name}(a)uni.ac.uk" >> Realm := "eduroam" >> } > > The better question is why do you think this is necessary? > > If they're your users, then you should authenticate them. You don't need to edit the User-Name. You don't need to proxy. > > Or, if you do proxy, you can just set Proxy-To-Realm: > > if("%{User-Name}" !~ /@/) { > update control { > Proxy-To-Realm := "my-other-server" > } > > >> radiusd -X output: >> >> (0) # Executing group from file /etc/raddb/sites-enabled/default >> (0) authenticate { >> (0) eap : Identity does not match User-Name, setting from EAP Identity >> (0) eap : Failed in handler >> (0) [eap] = invalid >> (0) } # authenticate = invalid >> (0) Failed to authenticate the user >> (0) Using Post-Auth-Type Reject > > That doesn't say "refused to proxy the request". The message is English, and should be clear. > >> Suggestions greatly appreciated. > > Describe the problem you're trying to solve. Don't ask why your proposed solution doesn't work. > > There are likely many other ways of getting the same result. > > Alan DeKok. > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html

1 0

Re: not able to install FR 3.0.16+git in (pure) Debian 9
by Rui Ribeiro 11 Sep '17

11 Sep '17

> > Message: 2 > Date: Fri, 11 Aug 2017 17:55:12 +0200 > From: Alan DeKok <aland(a)deployingradius.com> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: not able to install FR 3.0.16+git in (pure) Debian 9 > Message-ID: <13B96F99-2D68-4469-9CC1-639938303881(a)deployingradius.com> > Content-Type: text/plain; charset=us-ascii > > On Aug 11, 2017, at 5:50 PM, Rui Ribeiro <ruyrybeyro(a)gmail.com> wrote: > > What is the best way to send patches? > > > > This is the one for including libjson-c3 > > For small things, that's fine. I've pushed a fix. > > Alan DeKok. > > > > Hi again Alan, After this commit, you can already compile for Debian 9, thanks. If you would not mind, I would also propose striking out the HeartBleed check from debian/rules in 3.0.x, to be able to install it on Debian 9. Otherwise, the dependencies are not satisfied, and Debian 9 refuses to install the packages. --- debian/rules.old 2017-08-16 15:19:15.015393327 +0100 +++ debian/rules 2017-08-16 15:19:27.647279581 +0100 @@ -52,13 +52,6 @@ confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) endif -# Add dependency on distribution specific version of openssl that fixes Heartbleed (CVE-2014-0160). -ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes) - SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1f-1ubuntu2)" -else - SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1e-2+deb7u5)" -endif - # Add libsystemd-dev as a Build-Depends to debian/control if it is known to this system ifeq ($(shell apt-cache show libsystemd-dev &>/dev/null && echo yes),yes) CONTROL_BUILDDEPS += libsystemd-dev, -- Regards, -- Rui Ribeiro Senior Linux Architect and Network Administrator ISCTE-IUL https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434

7 21

Using freeradius, the system enters in an infinite loop
by Ricardo Ruiz 10 Sep '17

10 Sep '17

Hello out there, I am using freeradius2 in a raspberry pi3 with last version of LEDE and FreeRADIUS Version 2.2.9, and it happens something really weird, an infinite loop when a user tries to connect from a wifi hotspot. After installing freeradius, I only change 2 things: Add:ricardo Cleartext-Password := “testing”to /etc/freeradius2/users Comment out this# interface = br-lan from /etc/freeradius2/radiusd.conf I test the radius server using:root@LEDE:/etc/freeradius2# echo "User-Name = ricardo, User-Password = testing" | radclient -x 127.0.0.1 auth testing123 And it works:Sending Access-Request of id 28 to 127.0.0.1 port 1812 User-Name = "ricardo" User-Password = "testing"rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=28, length=20 However, when I setup WPA 2 Enterprise in the LEDE router (the same with freeradius server) and a user tries to connect, this infinite loop happens:https://vimeo.com/233192357 No error or warning message when running radiusd -XXXHere the log:https://gist.github.com/Ricardo1980/a5a7047fd0a03a6b10aea3b82f5e7cdf I think it is not related with certificates, because I can see this in the log:Sun Sep 10 14:07:31 2017 : Info: [peap] (other): SSL negotiation finished successfully Apart from that, I have this package installed:freeradius2-democerts And in the iPhone, it says that the expiration date is next year. Do you have any idea or suggestion? Probably it is a small detail but I cannot see it.Thanks a lot for your time.

2 4

Authentication problems with some devices: TLS version too low
by Lars Veldscholte 09 Sep '17

09 Sep '17

Hello everyone, I have problems with authenticating some clients using PEAP-MSCHAP. I've seen two (unrelated) devices having this issue so far: an Android phone and a Windows 7 PC. Other clients do not have this problem. The debug output is: (2) eap: Peer sent packet with method EAP PEAP (25) (2) eap: Calling submodule eap_peap to process data (2) eap_peap: Continuing EAP-TLS (2) eap_peap: Peer indicated complete TLS record size will be 99 bytes (2) eap_peap: Got complete TLS record (99 bytes) (2) eap_peap: [eaptls verify] = length included (2) eap_peap: (other): before SSL initialization (2) eap_peap: TLS_accept: before SSL initialization (2) eap_peap: TLS_accept: before SSL initialization (2) eap_peap: <<< recv TLS 1.2 [length 005e] (2) eap_peap: >>> send TLS 1.0 Alert [length 0002], fatal protocol_version (2) eap_peap: ERROR: TLS Alert write:fatal:protocol version tls: TLS_accept: Error in error (2) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417D18C:SSL routines:tls_process_client_hello:version too low (2) eap_peap: ERROR: System call (I/O) error (-1) (2) eap_peap: ERROR: TLS receive handshake failed during operation (2) eap_peap: ERROR: [eaptls process] = fail (2) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (2) eap: Sending EAP Failure (code 4) ID 230 length 4 (2) eap: Failed in EAP select (2) [eap] = invalid (2) } # authenticate = invalid (2) Failed to authenticate the user I'm not sure if I'm interpreting this correctly, but it seems that the client is trying to talk in TLSv1.2 while FreeRADIUS doesn't support that? I don't know what started this problem. PEAP always worked in the past, until now. The only thing I can think of is that I've recently generated new certificates (old ones were expired). There has also been a FreeRADIUS update (just regular Debian updates, I'm on 3.0.15 now). Could that be related? Thanks in advance for your help, Lars

4 13

Re: not able to install FR 3.0.16+git in (pure) Debian 9
by Arran Cudbard-Bell 09 Sep '17

09 Sep '17

> > On 9 Sep 2017, at 21:30, Fajar A. Nugraha <list(a)fajar.net> wrote: > > On Sat, Sep 9, 2017 at 7:56 PM, Alan DeKok <aland(a)deployingradius.com> wrote: >> On Sep 9, 2017, at 12:11 AM, Fajar A. Nugraha <list(a)fajar.net> wrote: >>> I think the problem arise because users see the debian directory, and >>> expect to build it successfully (i.e. following >>> https://wiki.freeradius.org/building/Debian-and-Ubuntu) But that >>> fails for debian 9. >> >> I can't feel overly responsible for distributions which break application software. >> >> There's really no other way to describe this. They've added patches to Debian after 3.0.15 was released, and those patches break *all* versions of FreeRADIUS. >> >>> IMHO some possible options are: >>> (a) add some instructions (e.g. on >>> https://wiki.freeradius.org/building/Debian-and-Ubuntu) something >>> like 'if you're absolutely sure you're using patched/non-vulnerable >>> versions of openssl, then you can edit these files manually, but don't >>> complain if it's broken", and so on. And point any >>> debian-package-related queries there. OR >> >> I've pushed patches to v3.0.x which should help. I'll see if I can add notes to the wiki. I think there's some confusion here... Those were an adaptation of the fixes that I put into v4.0.x to call the new OpenSSL 1.1.0 API to set min/max TLS versions, they won't affect debian packaging, or alter which security issues FreeRADIUS flags. ...they will however allow users to override the TLS restrictions in Debian 9, which only allowed TLS 1.2 to be used, which was the subject of another thread. I'm working on a new docker build image for Debian 9, after that's done we should be able to look at the packaging issues in v3.0.x on Debian 9. As for discovering packaging issues early, yes there is a the beginnings of a Jenkins based CIT system, that publishes packages for centos7 and ubuntu to packages.networkradius.com. The main issues are that packages aren't pushed for every debian/ubuntu/centos flavour, and there's currently no notifications of when a build fails. >> We'll try to get automated builds set up... right now, we're up to a backlog of ~10-20 systems that people want. It's up, it's just sort of, half finished, and not overly useful in its current form. Not to say it couldn't be useful, it just isn't right now, seeing as it doesn't publish notifications in any form... outside of maybe the jobs triggered by pull requests. Anyway that's an internal discussion. -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

2 1

Freeradius 3.X ldap-userdn
by Bhagwat, Shrikant 08 Sep '17

08 Sep '17

Getting error for LDAP-UserDN Module. Anybody has seen it ? 0) level1_and_duopush : Executing: /idm/idmt_home/srv/radius-mfa-scripts/bin/DuoFactor.pl %{config:modules.ldap.identity} %{config:modules.ldap.password} %{config:modules.ldap.server} %{config:modules.ldap.base_dn} %{check:LDAP-UserDn} %{config:modules.ldap.level-1_kdc} %{config:modules.ldap.logFILEname} %{config:modules.ldap.duo_host} %{config:modules.ldap.duo_ikey} %{config:modules.ldap.duo_skey} push 0) level1_and_duopush : EXPAND modules.ldap.identity (0) level1_and_duopush : --> modules.ldap.identity (0) level1_and_duopush : EXPAND %{config:modules.ldap.identity} (0) level1_and_duopush : --> cn=p-idm-radius,o=services (0) level1_and_duopush : EXPAND modules.ldap.password (0) level1_and_duopush : --> modules.ldap.password (0) level1_and_duopush : EXPAND %{config:modules.ldap.password} (0) level1_and_duopush : --> XXXX (0) level1_and_duopush : EXPAND modules.ldap.server (0) level1_and_duopush : --> modules.ldap.server (0) level1_and_duopush : EXPAND %{config:modules.ldap.server} (0) level1_and_duopush : --> p-idm-dir1.ent.med.umich.edu (0) level1_and_duopush : EXPAND modules.ldap.base_dn (0) level1_and_duopush : --> modules.ldap.base_dn (0) level1_and_duopush : EXPAND %{config:modules.ldap.base_dn} (0) level1_and_duopush : --> dc=umich,dc=edu (0) ERROR: level1_and_duopush : %{check:LDAP-UserDn} (0) ERROR: level1_and_duopush : ^ Unknown module (0) level1_and_duopush : EXPAND modules.ldap.level-1_kdc (0) level1_and_duopush : --> modules.ldap.level-1_kdc (0) level1_and_duopush : EXPAND %{config:modules.ldap.level-1_kdc} (0) level1_and_duopush : --> UMICH.EDU (0) level1_and_duopush : EXPAND modules.ldap.logFILEname (0) level1_and_duopush : --> modules.ldap.logFILEname (0) level1_and_duopush : EXPAND %{config:modules.ldap.logFILEname} (0) level1_and_duopush : --> /idm/idmt_home/srv/radius-mfa-scripts/log/umhspf.log (0) level1_and_duopush : EXPAND modules.ldap.duo_host ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

3 2

Poll of opinions for new keyword
by Arran Cudbard-Bell 08 Sep '17

08 Sep '17

New functionality is being added in v4.0.x to allow new sub-requests to be generated by requests received by the server. The basic format is: <keyword> [virtual-server.]<packet-type> { <sub-request-attr0> := <parent attr0> <sub-request-attr1> += <parent attr1> <sub-request-attrN> += <parent attrN> } There's debate about what <keyword> should be, and whether there should be multiple <keywords> for async - where we split the lifetime of the sub-request from its parent, and synchronous behaviour - where we wait for the sub-request to return before we continue processing. The original keyword was "fork", and has since been changed to "create". Do people have any opinions on what the easiest to infer and most consistent keyword to use here would be? Some other ideas were "spawn", and "child". There's no guarantee that the most popular keyword/idea will be used, but it'll at least inform us of general public opinion :) -Arran

5 10

What output pairs & what are allowed values
by Bhagwat, Shrikant 07 Sep '17

07 Sep '17

In rlm_exec to execute perl script what is wait = yes output = none #input_pairs = request output_pairs = none ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

3 3

freeradius 3.0.15 memory corruption
by petr.linke＠seznam.cz 07 Sep '17

07 Sep '17

Hello, I try to set up freeradius 3.0.15 with MS AD authentication via ntlm_auth from samba. I use default settings, follow freeradius-active-directory- integration-howto. All work correctly for username length up to 5 characters, but when I use username, where the length is more than 5 characters, freeradius terminated due memory corruption. (freeradius v.3.0.15, running on debian Wheezy64). debug for username length more than 5 characters: ... (10) ntdomain: Checking for prefix before "\" (10) ntdomain: No '\' in User-Name = "abcdef", looking up realm NULL (10) ntdomain: No such realm "NULL" (10) [ntdomain] = noop (10) update control { (10) &Proxy-To-Realm := LOCAL (10) } # update control = noop (10) eap: Peer sent EAP Response (code 2) ID 11 length 6 (10) eap: No EAP Start, assuming it's an on-going EAP conversation (10) [eap] = updated (10) [logintime] = noop (10) [pap] = noop (10) } # authorize = updated (10) Found Auth-Type = eap (10) # Executing group from file /etc/freeradius/sites-enabled/inner (10) authenticate { (10) eap: Expiring EAP session with state 0x00b1f6cf01baecde (10) eap: Finished EAP session with state 0x00b1f6cf01baecde (10) eap: Previous EAP request found for state 0x00b1f6cf01baecde, released from the list (10) eap: Peer sent packet with method EAP MSCHAPv2 (26) (10) eap: Calling submodule eap_mschapv2 to process data (10) eap: Sending EAP Success (code 3) ID 11 length 4 (10) eap: Freeing handler (10) [eap] = ok (10) } # authenticate = ok (10) # Executing section post-auth from file /etc/freeradius/sites- enabled/inner (10) post-auth { (10) if (1) { (10) if (1) -> TRUE (10) if (1) { (10) update reply { (10) User-Name !* ANY/lib/x86_64-linux-gnu/libc.so.6(+0x75bb6)[0x7 efef0171bb6] *** glibc detected *** freeradius: free(): invalid next size (fast): 0x 0000000000b61230 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7efef017695c] /usr/lib/x86_64-linux-gnu/libtalloc.so.2(+0x7089)[0x7efef159d089] /usr/lib/x86_64-linux-gnu/libtalloc.so.2(_talloc_free+0x113)[0x7efef15998b3] /usr/lib/freeradius/libfreeradius-radius.so(fr_pair_delete_by_num+0xa6)[0x7 efef2023b56] /usr/lib/freeradius/libfreeradius-server.so(map_to_request+0xacd)[0x7efef 2263c9d] freeradius[0x4278ad] freeradius[0x4272aa] freeradius[0x42752d] freeradius[0x4272aa] freeradius[0x42752d] freeradius(modcall+0x43)[0x4286a3] freeradius(indexed_modcall+0xa5)[0x423205] freeradius(rad_postauth+0x80)[0x4118a0] freeradius(rad_virtual_server+0x3d0)[0x4128f0] /usr/lib/freeradius/rlm_eap_peap.so(eappeap_process+0x772)[0x7efee953c872] /usr/lib/freeradius/rlm_eap_peap.so(+0x1de2)[0x7efee953ade2] /usr/lib/freeradius/rlm_eap.so(+0x3bbb)[0x7efeeab60bbb] /usr/lib/freeradius/rlm_eap.so(eap_method_select+0xc8)[0x7efeeab60e58] /usr/lib/freeradius/rlm_eap.so(+0x2e15)[0x7efeeab5fe15] freeradius[0x4283b2] freeradius[0x4272aa] freeradius[0x42752d] freeradius(modcall+0x43)[0x4286a3] freeradius(indexed_modcall+0xa5)[0x423205] freeradius(rad_authenticate+0x73d)[0x4122bd] freeradius[0x4368ba] freeradius[0x4322ad] freeradius(request_receive+0x337)[0x433f97] freeradius[0x41d5b9] freeradius[0x4316ad] /usr/lib/freeradius/libfreeradius-radius.so(fr_event_loop+0x2d9)[0x7efef2036 c59] freeradius(main+0x6af)[0x410dbf] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7efef011aead] freeradius[0x411105] ======= Memory map: ======== 00400000-00463000 r-xp 00000000 01:01 77414 / usr/sbin/freeradius 00662000-00665000 r--p 00062000 01:01 77414 / usr/sbin/freeradius 00665000-00669000 rw-p 00065000 01:01 77414 / usr/sbin/freeradius 00669000-0066a000 rw-p 00000000 00:00 0 00800000-00b9b000 rw-p 00000000 00:00 0 [heap] ... and now the same situation, username length up to 5 characters: (10) ntdomain: Checking for prefix before "\" (10) ntdomain: No '\' in User-Name = "test2", looking up realm NULL (10) ntdomain: No such realm "NULL" (10) [ntdomain] = noop (10) update control { (10) &Proxy-To-Realm := LOCAL (10) } # update control = noop (10) eap: Peer sent EAP Response (code 2) ID 10 length 64 (10) eap: No EAP Start, assuming it's an on-going EAP conversation (10) [eap] = updated (10) [logintime] = noop (10) [pap] = noop (10) } # authorize = updated (10) Found Auth-Type = eap (10) # Executing group from file /etc/freeradius/sites-enabled/inner (10) authenticate { (10) eap: Expiring EAP session with state 0x3dd92fdb3dd3359e (10) eap: Finished EAP session with state 0x3dd92fdb3dd3359e (10) eap: Previous EAP request found for state 0x3dd92fdb3dd3359e, released from the list (10) eap: Peer sent packet with method EAP MSCHAPv2 (26) (10) eap: Calling submodule eap_mschapv2 to process data (10) eap_mschapv2: # Executing group from file /etc/freeradius/sites- enabled/inner (10) eap_mschapv2: authenticate { (10) mschap: Creating challenge hash with username: test2 (10) mschap: Client is using MS-CHAPv2 (10) mschap: Executing: /usr/local/bin/ntlm_auth --request-nt-key --username =%{mschap:User-Name:-None} --domain=%{%{mschap:NT-Domain}:-TEST.LOCAL} -- challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}: (10) mschap: EXPAND --username=%{mschap:User-Name:-None} (10) mschap: --> --username=test2 ... (12) policy remove_reply_message_if_eap { (12) if (&reply:EAP-Message && &reply:Reply-Message) { (12) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (12) else { (12) [noop] = noop (12) } # else = noop (12) } # policy remove_reply_message_if_eap = noop (12) } # post-auth = ok (12) Sent Access-Accept Id 252 from 10.255.246.120:1812 to 10.255.246.253: 1812 length 0 (12) MS-MPPE-Recv-Key = 0x1f4851b2d1ec7efab075df3b8442ee2f92405e46935f2739 e329efbe06bc0e1e (12) MS-MPPE-Send-Key = 0xe75f33f2f6e0d814306d365d1c2d55da8296b7df034ad29b 762d516c0cc10f7f (12) EAP-Message = 0x030c0004 (12) Message-Authenticator = 0x00000000000000000000000000000000 (12) User-Name = "test2" (12) EAP-Key-Name := 0x1959b11211ec00b494af0aff7ea172e56e202f0fa593dd5f9b 40334b1906ab90534867b6668b5466cce813501306b028a585698afddf1dafb6937c56a41b 6241ff (12) Finished request But when I try radtest with username length more than 5 characters, no problem: ---------------------------------------------------------------------------- ------------------------- radius-test:~# radtest -t mschap abcdef 12345#W 10.255.246.120 1 SharedSecret Sent Access-Request Id 238 from 0.0.0.0:52211 to 10.255.246.120:1812 length 132 User-Name = "abcdef" MS-CHAP-Password = "12345#W" NAS-IP-Address = 10.255.246.120 NAS-Port = 1 Message-Authenticator = 0x00 Cleartext-Password = "12345#W" MS-CHAP-Challenge = 0x838e90923dacd16e MS-CHAP-Response = 0x 0001000000000000000000000000000000000000000000000000ce64b63fc3d55e1391b5f4ac 516373cd10bd09574a21bb8c Received Access-Accept Id 238 from 10.255.246.120:1812 to 0.0.0.0:0 length 37 Than you for any help, Petr Linke

4 12