Freeradius-Users Digest, Vol 145, Issue 48

Mohamad Yazdian m.programer at gmail.com
Tue May 23 10:04:40 CEST 2017


Hi everyone
I have problem width the update reply.
I check the total acctinputocted for the user and flag
the Mikrotik-Xmit-Limit attribute.
When I set the ip address for the module my pppoe user on mikrotik get this
ip address successfuly but when I use the framed-pool and set the ip-pool
name in mikrotik the clinet can not get the  ip from the ip-pool.
please help me to fix this problem

wifi_Limit2{
reject = 1
}
if(reject){
update reply{
Mikrotik-Rate-Limit := "256K/256K" # <----This line is work fine
                                Framed-IP-Address := "1.1.1.2"      #
<----This line is work fine
Framed-Pool := "Expire"                # <----This line isn't work
}
}



On Tue, May 23, 2017 at 10:59 AM, Mohamad Yazdian <m.programer at gmail.com>
wrote:

> Hi everyone
> I have problem width the update reply.
> I check the total acctinputocted for the user and flag
> the Mikrotik-Xmit-Limit attribute.
> When I set the ip address for the module my pppoe user on mikrotik get
> this ip address successfuly but when I use the framed-pool and set the
> ip-pool name in mikrotik the clinet can not get the  ip from the ip-pool.
> please help me to fix this problem
>
> On Tue, May 23, 2017 at 1:41 AM, <freeradius-users-request@
> lists.freeradius.org> wrote:
>
>> Send Freeradius-Users mailing list submissions to
>>         freeradius-users at lists.freeradius.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://lists.freeradius.org/mailman/listinfo/freeradius-users
>> or, via email, send a message with subject or body 'help' to
>>         freeradius-users-request at lists.freeradius.org
>>
>> You can reach the person managing the list at
>>         freeradius-users-owner at lists.freeradius.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Freeradius-Users digest..."
>>
>>
>> Today's Topics:
>>
>>    1. is there a way to identify the very first ACCESS-REQUEST
>>       (Michael Hocke)
>>    2. Re: is there a way to identify the very first ACCESS-REQUEST
>>       (Matthew Newton)
>>    3. Re: Freeradius Multiple Disjoint Ad Domains (Arnab Roy)
>>    4. Re: is there a way to identify the very first ACCESS-REQUEST
>>       (Michael Hocke)
>>    5. Re: is there a way to identify the very first ACCESS-REQUEST
>>       (Matthew Newton)
>>    6. Re: is there a way to identify the very first ACCESS-REQUEST
>>       (Michael Hocke)
>>    7. Re: Freeradius with multiotp - but otp-pin is in username
>>       (blaster at vorsicht-bissig.de)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 22 May 2017 13:04:59 -0400
>> From: Michael Hocke <mh103 at nyu.edu>
>> To: FreeRadius users mailing list
>>         <freeradius-users at lists.freeradius.org>
>> Subject: is there a way to identify the very first ACCESS-REQUEST
>> Message-ID: <D71F1F39-81F6-4417-8782-FCC16E6A82A8 at nyu.edu>
>> Content-Type: text/plain; charset=us-ascii
>>
>>
>> Hi there,
>>
>> I want to improve our logging and want to keep track of authentication
>> attempts that do not complete. I was thinking of logging the very first
>> ACCESS-REQUEST and then later on the result. Is there a good way to
>> identify the very first ACCESS-REQUEST from the client with unlang? Maybe
>> by checking the contents of the session-state list or some such? Any ideas?
>>
>> Thanks!
>>
>> - Michael
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 22 May 2017 19:20:52 +0100
>> From: Matthew Newton <matthew at newtoncomputing.co.uk>
>> To: FreeRadius users mailing list
>>         <freeradius-users at lists.freeradius.org>
>> Subject: Re: is there a way to identify the very first ACCESS-REQUEST
>> Message-ID: <20170522182052.GA7565 at elk.newtoncomputing.co.uk>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Mon, May 22, 2017 at 01:04:59PM -0400, Michael Hocke wrote:
>> > I want to improve our logging and want to keep track of
>> > authentication attempts that do not complete. I was thinking of
>> > logging the very first ACCESS-REQUEST and then later on the
>> > result. Is there a good way to identify the very first
>> > ACCESS-REQUEST from the client with unlang? Maybe by checking
>> > the contents of the session-state list or some such? Any ideas?
>>
>> I look to see if it's an EAP identity. Which works OK if you're
>> doing EAP.
>>
>>   if (&EAP-Message =~ /^0x02......01/) {
>>     detail
>>   }
>>   eap
>>
>> --
>> Matthew
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 22 May 2017 21:09:58 +0200
>> From: "Arnab Roy" <arnabroy at mail.com>
>> To: freeradius-users at lists.freeradius.org, "Matthew Newton"
>>         <mcn4 at leicester.ac.uk>
>> Subject: Re: Freeradius Multiple Disjoint Ad Domains
>> Message-ID:
>>         <trinity-82f81d62-20d5-41b0-964a-3ed7ccdc55aa-1495480198798@
>> 3capp-mailcom-lxa14>
>>
>> Content-Type: text/plain; charset="UTF-8"
>>
>>    Hi Matthew,
>>
>>    Sorry I am back with this one. After digging through tons of samba
>>    source I have finally managed to reach a stage where Winbind is now
>>    running completely separately so just need to sort out ntlm_auth.
>>    Looking through the source code I stumbled upon the following file in
>>    nsswitch and saw your name as the author :) hope its the same Matthew
>>    :)
>>
>>    nsswitch/wb_common.c
>>
>>    Now previously it seems like it was possible to set the Winbind Socket
>>    directory via an environment variable (
>>    http://samba.2283325.n4.nabble.com/NTLM-Authentication-
>> against-multiple
>>    -domain-comtrollers-td3024825.html )
>>
>>    This seems to have gone now looking at the code
>>
>>    static const char *winbindd_socket_dir(void)
>>    {
>>            if (nss_wrapper_enabled()) {
>>                    const char *env_dir;
>>                    env_dir = getenv("SELFTEST_WINBINDD_SOCKET_DIR");
>>                    if (env_dir != NULL) {
>>                            return env_dir;
>>                    }
>>            }
>>            return WINBINDD_SOCKET_DIR;
>>    }
>>
>>    Can you see any issues if I changed this to return a custom environment
>>    variable instead ? Also from a FR perspective I am considering
>>    chrooting ntlm_auth ?
>>
>>    Your help is much appreciated.
>>
>>    Many Thanks
>>    Arnab
>>
>>
>>
>>    Sent: Monday, May 22, 2017 at 12:37 PM
>>    From: "Matthew Newton" <mcn4 at leicester.ac.uk>
>>    To: "FreeRadius users mailing list"
>>    <freeradius-users at lists.freeradius.org>
>>    Subject: Re: Freeradius Multiple Disjoint Ad Domains
>>    On Mon, May 22, 2017 at 01:27:53PM +0200, Arnab Roy wrote:
>>    > The problem seems to be ntlm_auth doesnt see that the winbindd
>>    > privileged pipe and winbindd socket is running in a custom directory.
>>    IIRC ntlm_auth connects to winbindd using the /tmp/.winbindd/pipe
>>    pipe, and then queries winbindd over that pipe what the location of
>>    the priv pipe is.
>>    So if you've got two winbindds both with /tmp/.winbindd/pipe, only
>>    one of those is going to work.
>>    Assuming the two copies of Samba were compiled with different
>>    locations then it might work. I'd be inclined to strace all the
>>    things and see what's really happening.
>>    I'd expect that if you built Samba and installed in /opt/samba1/
>>    and /opt/samba2/ and then ran /opt/samba1/ntlm_auth and
>>    /opt/samba2/ntlm_auth that the locations would probably be
>>    separate and all would be OK.
>>    But running two copies of Samba on the same box is hardly a
>>    standard setup, so you're likely to be on your own.
>>    Or you could just proxy the RADIUS request to a separate VM with
>>    another instance of Samba on it and save the unusual setup.
>>    Matthew
>>    --
>>    Matthew Newton, Ph.D. <mcn4 at leicester.ac.uk>
>>    Systems Specialist, Infrastructure Services,
>>    I.T. Services, University of Leicester, Leicester LE1 7RH, United
>>    Kingdom
>>    For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>
>>    -
>>    List info/subscribe/unsubscribe? See
>>    [1]http://www.freeradius.org/list/users.html
>>
>> References
>>
>>    1. http://www.freeradius.org/list/users.html
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Mon, 22 May 2017 15:32:00 -0400
>> From: Michael Hocke <mh103 at nyu.edu>
>> To: FreeRadius users mailing list
>>         <freeradius-users at lists.freeradius.org>
>> Subject: Re: is there a way to identify the very first ACCESS-REQUEST
>> Message-ID: <7D716BE5-D12E-4512-9BC0-480DFFE36E8C at nyu.edu>
>> Content-Type: text/plain; charset=utf-8
>>
>>
>> > On May 22, 2017, at 2:20 PM, Matthew Newton <
>> matthew at newtoncomputing.co.uk> wrote:
>> >
>> > On Mon, May 22, 2017 at 01:04:59PM -0400, Michael Hocke wrote:
>> >> I want to improve our logging and want to keep track of
>> >> authentication attempts that do not complete. I was thinking of
>> >> logging the very first ACCESS-REQUEST and then later on the
>> >> result. Is there a good way to identify the very first
>> >> ACCESS-REQUEST from the client with unlang? Maybe by checking
>> >> the contents of the session-state list or some such? Any ideas?
>> >
>> > I look to see if it's an EAP identity. Which works OK if you're
>> > doing EAP.
>> >
>> >  if (&EAP-Message =~ /^0x02......01/) {
>> >    detail
>> >  }
>> >  eap
>>
>> That looks good. I’ll give it a try. Follow-up question: is there a way
>> to get a hold of the request number from within unlang? I don’t think I see
>> it anywhere in the source code but I want to ask anyway. If not, is this
>> something planned for a future release or is there a better way to
>> correlate different log lines to the same request?
>>
>> Thanks again!
>>
>> - Michael
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Mon, 22 May 2017 20:49:43 +0100
>> From: Matthew Newton <matthew at newtoncomputing.co.uk>
>> To: FreeRadius users mailing list
>>         <freeradius-users at lists.freeradius.org>
>> Subject: Re: is there a way to identify the very first ACCESS-REQUEST
>> Message-ID:
>>         <9A9A26CD-35F6-4FA8-9A42-A8BA75D37D64 at newtoncomputing.co.uk>
>> Content-Type: text/plain; charset=utf-8
>>
>> On 22 May 2017 20:32:00 BST, Michael Hocke <mh103 at nyu.edu> wrote:
>> >That looks good. I’ll give it a try. Follow-up question: is there a way
>> >to get a hold of the request number from within unlang? I don’t think I
>> >see it anywhere in the source code but I want to ask anyway.
>>
>> http://wiki.freeradius.org/config/run_time_variables
>>
>> %n, in v3 onwards.
>>
>>
>>
>> --
>> Matthew
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Mon, 22 May 2017 16:00:18 -0400
>> From: Michael Hocke <mh103 at nyu.edu>
>> To: FreeRadius users mailing list
>>         <freeradius-users at lists.freeradius.org>
>> Subject: Re: is there a way to identify the very first ACCESS-REQUEST
>> Message-ID: <1ECD6BA4-C805-450E-8241-49C446CCB483 at nyu.edu>
>> Content-Type: text/plain; charset=utf-8
>>
>>
>> > On May 22, 2017, at 3:49 PM, Matthew Newton <
>> matthew at newtoncomputing.co.uk> wrote:
>> >
>> > On 22 May 2017 20:32:00 BST, Michael Hocke <mh103 at nyu.edu> wrote:
>> >> That looks good. I’ll give it a try. Follow-up question: is there a way
>> >> to get a hold of the request number from within unlang? I don’t think I
>> >> see it anywhere in the source code but I want to ask anyway.
>> >
>> > http://wiki.freeradius.org/config/run_time_variables
>> >
>> > %n, in v3 onwards.
>>
>> Awesome. Thank you very much.
>>
>> - Michael
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Tue, 23 May 2017 00:41:36 +0200
>> From: blaster at vorsicht-bissig.de
>> To: freeradius-users at lists.freeradius.org
>> Subject: Re: Freeradius with multiotp - but otp-pin is in username
>> Message-ID: <0fef0540-59bd-4b62-bd6f-adb1b1856e27 at gmx.at>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Hello,
>>
>> I put the policy on the top of the authorize section and it works as
>> intendet.
>> Thank you very much, Alan DeKok for your advice!
>>
>> Best regards
>> Gerald
>>
>>
>> On 22.05.2017 14:30, Alan DeKok wrote:
>> > On May 21, 2017, at 6:53 PM, blaster at vorsicht-bissig.de wrote:
>> >>    i'm trying to setup FreeRADIUS Version 3.0.13 with multiotp BUT I
>> want
>> >>    to enter the information like this:
>> >>    "{Username}:{OTP-PIN}"   ==> f.e. "dani:955825"   (username in users
>> >>    file)
>> >>    "{Password}"                      ==> f.e. "blabla"  (password in
>> users
>> >>    file)
>> >    That's a little unusual, but it should work, mostly.
>> >
>> >    But most people appoint the OTP to the password, not to the
>> User-Name.
>> >
>> >>    I think this could be a way, to get some devices to work with 2
>> factor,
>> >>    which are not build for it.
>> >>    I successfully get an ok from multiotp, by regex'ing "{OTP-PIN}"
>> >>    from "{Username}:{OTP-PIN}",
>> >>    but PAP is failing, because I can't get PAP to look for "{Username}"
>> >>    (f.e. "dani").
>> >>    It always tries to look for "{Username}:{OTP-PIN}" (f.e.
>> "dani:955825")
>> >>    in the authentication-section.
>> >    Because the default configuration looks up users by the contents of
>> the User-Name attribute.
>> >
>> >    Sine you've modified the User-Name to contain the OTP key, that
>> won't work.
>> >
>> >>    It would be nice if you could point me in the right direction.
>> >>    My apologies, if this question was already asked, and I didn't find
>> it.
>> >>    Best regards
>> >>    Gerald
>> >>    remark - begin
>> >>    ------------
>> >>    I successfully did it with
>> >>    "{Username} "                  ==> f.e. "dani" (username in users
>> file)
>> >>    "{Password}{OTP-PIN}"     ==> f.e. "blabla955825"  (password in
>> users
>> >>    file)
>> >    Which is what most people use.
>> >
>> >>    But I think the
>> >>    "{Username}"
>> >>    "{Password}{OTP-PIN}"
>> >>    way, fails when it comes to MSCHAP (with ActiveDirectory), because
>> >>    Freeradius compares only password hashes and not plaintext, so it
>> can't
>> >>    recongnise what's the OTP-PIN and what's the password.
>> >    Yes.
>> >
>> >>    --------------
>> >>    remark - end
>> >>    /usr/local/etc/raddb/users
>> >>    ####
>> >>    "dani"        Cleartext-Password := "blabla", MS-CHAP-Use-NTLM-Auth
>> :=
>> >>    0
>> >>    ####
>> >>    /usr/local/etc/dictionary
>> >>    ####
>> >>    ATTRIBUTE       User-OTP                3000    string
>> >    You don't need that.
>> >
>> >>    ATTRIBUTE       User-Password-TMP       3001    string
>> >>    ####
>> >>    /usr/local/etc/raddb# cat policy.d/pol_usernamemultiotp
>> >>    #####
>> >>    pol_usernamemultiotp.authorize {
>> >>            if ( &User-Name =~ /^(.*)(\:)([0-9]{6})$/) {
>> >>                    update request {
>> >>                            User-Password-TMP := "%{User-Password}"
>> >>                            User-OTP := "%{3}"
>> >>                            User-Password := "%{User-OTP}"
>> >    This isn't necessary.
>> >
>> >>                            User-Name := "%{1}"
>> >    You probably shouldn't re-write the User-Name.  Leave it alone.
>> >
>> >>                            Stripped-User-Name := "%{1}"
>> >    If Stripped-User-Name exists, the server uses it for lookups instead
>> of User-Name.  So all you need to do is set Stripped-User-Name correctly.
>> >
>> >>    #####
>> >>    radiusd -X output - begin
>> >    Reading it carefully helps... the messages are useful.
>> >
>> >>    #####
>> >>    Ready to process requests
>> >>    (0) Received Access-Request Id 192 from 127.0.0.1:56491 to
>> >>    127.0.0.1:1842 length 81
>> >>    (0)   User-Name = "dani:955825"
>> >>    (0)   User-Password = "blabla"
>> >>    (0)   NAS-IP-Address = 127.0.0.1
>> >>    (0)   NAS-Port = 100
>> >>    (0)   Message-Authenticator = 0x0cc5e28430dea113b6b4fde2d1537388
>> >    That's the Access-Request...
>> >
>> >>    (0) custom_otp: Searching for user in group "vlan10"
>> >>    rlm_ldap (ldap): Closing connection (0): Hit idle_timeout, was idle
>> for
>> >>    76 seconds
>> >>    rlm_ldap (ldap): Closing connection (1): Hit idle_timeout, was idle
>> for
>> >>    76 seconds
>> >>    rlm_ldap (ldap): Closing connection (2): Hit idle_timeout, was idle
>> for
>> >>    76 seconds
>> >>    rlm_ldap (ldap): You probably need to lower "min"
>> >>    rlm_ldap (ldap): Closing connection (3): Hit idle_timeout, was idle
>> for
>> >>    76 seconds
>> >>    rlm_ldap (ldap): You probably need to lower "min"
>> >>    rlm_ldap (ldap): Closing connection (4): Hit idle_timeout, was idle
>> for
>> >>    76 seconds
>> >>    rlm_ldap (ldap): You probably need to lower "min"
>> >    Pay attention to those messages.  Either increase "idle_timeout", or
>> lower "min".
>> >
>> >>    (0) custom_otp: EXPAND
>> >>    (samaccountname=%{%{Stripped-User-Name}:-%{User-Name}})
>> >>    (0) custom_otp:    --> (samaccountname=dani:955825)
>> >>    (0) custom_otp: Search returned no results
>> >    Note that it's looking up the User-Name attribute.  i.e. the name
>> *before* any edits.
>> >
>> >>    rlm_ldap (ldap): Released connection (6)
>> >>    (0)     [ldap] = notfound
>> >>    (0)     [expiration] = noop
>> >>    (0)     [logintime] = noop
>> >>    (0)     policy pol_usernamemultiotp.authorize {
>> >    And AFTER you look up User-Name (the one with the OTP), you run the
>> policy to fix the User-Name.
>> >
>> >    i.e. you have this reversed.
>> >
>> >   The solution is to put the re-write at the TOP of the "authorize"
>> section. That way, the Stripped-User-Name attribute is seen by all modules.
>> >
>> >    And the policy you created is too complicated.  Just do this:
>> >
>> >       if ( &User-Name =~ /^(.*):([0-9]{6})$/) {
>> >               update request {
>> >                       Stripped-User-Name := "%{1}"
>> >                       User-OTP := "%{2}"
>> >               }
>> >       }
>> >
>> >    i..e. you don't need a "tmp" password. You don't need to re-write
>> the password.  You don't need to match (:) in the regex.  Just matching :
>> is good enough.
>> >
>> >    Alan DeKok.
>> >
>> >
>> > -
>> > List info/subscribe/unsubscribe? See http://www.freeradius.org/list
>> /users.html
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list
>> /users.html
>>
>> ------------------------------
>>
>> End of Freeradius-Users Digest, Vol 145, Issue 48
>> *************************************************
>>
>
>


More information about the Freeradius-Users mailing list