- Freeradius-Users - lists.freeradius.org

Locked account
by Maurice James 12 Oct '11

12 Oct '11

How do I get freeradius to deny access based on the ldap attribute nsAccountLock = true? <http://g.bfbcs.com/175/pc_Lt%20Loooootz.png> Description: pc_Lt Loooootz

2 1

Trying to solve a Simultaneous-Use problem
by Nataniel Klug 11 Oct '11

11 Oct '11

Hello all, I am trying to solve a problem about Simultaneous-Use, not in the code because its working, but inside my network layout. I have two different NAS the can authenticate the same client for PPPoE, something like this: [ internet ] ---+ NAS01 +--- [ client ] ----| NAS02 |---- So the client can be connected to any of those 2 NAS for different reasons and when I have a problem, like a power surge, in one of the NAS I got the connection stopped because the NAS that turned down is not sending any accounting packets to the radius. Its ok when I use only one NAS but I am using 2 for backup in cases like a power surge or a hard shutdown of the machine. If the simultaneous-use work so the client cannot connect to NAS02 (assuming that NAS01 has been turned down) until NAS01 is powered on and send account-stop to the radius. So, my question is: how can I use Simultaneous-Use in this scenario? Should I make a script that test if the NAS is online every 10 seconds and if not list all clients connect and stop that connections? Should this work? Is there anyone with the same scenario that can share the solution for the problem? -- Descrição: 20110500 - EMAIL-SIGN - CAPADescrição: 20110500 - EMAIL-SIGN - nata

4 8

From inner to outer
by Roland Hedberg 11 Oct '11

11 Oct '11

Hi! I have the following problem. A module I have written uses the inner tunnel User-Name to find information about the user from an outside source. This user information must be returned in the outer tunnel. Is this doable ? I can think of two ways of doing this: 1) The module while running in the inner tunnel context puts the inner User-Name somewhere where the module when running in the outer tunnel context can pick it up and do the external source lookup. 2) Do the external source lookup in the inner tunnel context and then put the found information somewhere where the module while running in the outer tunnel context can find it. I'd prefer the later. -- Roland

3 2

Re: Local Auth if Proxy Auth fails ---OR--- Proxy Auth if Local Auth fails
by "Яцко Эллад Генна дьевич (ngs)" 11 Oct '11

11 Oct '11

Hello! Is it possuble to use another Auth-mechanism if primary Auth failed? The below is what I meant: 1) NAS -> FreeRADIUS: User/Password 2) FreeRADIUS - Does User exist in Local DB? 3) If "yes" - Access-Acept! 4) If "no" - Are any Proxies configured? FreeRADIUS -> Proxy: User/Password 5) Proxy answers, FreeRADIUS translates the answer further to NAS. Kind regards, Ellad Yatsko

3 9

about Simultaneous-Use and Multiple NAS
by Dagia Dorjsuren 10 Oct '11

10 Oct '11

Hello, Anyone advise me for my below problem pls. How to configure simultaneous login count for each NAS? for example : there is one account and 2 NAS like NAS1 and NAS2. That account's total simultaneous login count is 2. So, there is that account's first simultaneous login must be from NAS1 and second simultaneous login must be from NAS2. Thanks,

2 1

Re: Dynamic Attributes Based on NAS Type !
by Alan DeKok 09 Oct '11

09 Oct '11

Stefan A. wrote: > I never talked about sending policies to the NAS. That *was* the subject of conversation. If you're not going to talk about that, start a new thread. > The question was, what would be the recommendation, if the RADIUS client is > a RADIUS Proxy server (..in between the original NAS and my FR...) > In that case, "%{client:nas_type}" won't work, because it would always be > the same (... proxy server....) Uh... the "nas_type" field is whatever you want. Put in "nas_type = proxy" for a proxy server. You can then key off of that, and send *no* NAS-specific attributes back. > Would one use "%{NAS-ID}" instead of "%{client:nas_type}"? No. The NAS-Identifier is created by the NAS, which may be 2-3 hops away from the proxy. Alan DeKok.

2 1

Dynamic Attributes Based on NAS Type !
by Suman Dash 09 Oct '11

09 Oct '11

Hi Everyone ... Currently i am planning to integrate freeradius with different NAS like Chillispot , Cisco etc and enable roaming users so that they can log in from any of the NAS. As the reply items are different with different NAS , i am looking for ideas how to enable a single user to roam and connect from different NAS. In my case i think static reply items are not possible per user wise or per groupwise so my question is what trick can be used to achieve the same. I had not tried anything as i have no clue on the same so some highlights on the approach will be a good starting point for me. Cheers Suman

5 6

Re: Dynamic Attributes Based on NAS Type !
by Alan DeKok 09 Oct '11

09 Oct '11

Stefan A. wrote: > What would you recommend to do, if your client is a proxy server? NAS-ID? No. Don't send policies back. You don't control the NAS. So you have no business sending it NAS-specific policies. > Nice idea, as long as a NAS vendor does not introduce another or additional way(/attribute) to do things in never NAS OS Versions. > In that case you would possible get in trouble if you have both NAS OS versions in your network and feed them with mixed attributes. > Starent did this in the past, where they had a bunch of QoS attributes in one Version and a single Attribute (177) to handle them all at once in never versions. Yes, well, NAS vendors have been known for doing weird things. Hence RFC 6158. Alan DeKok.

2 1

Re: Dynamic Attributes Based on NAS Type !
by Alan DeKok 09 Oct '11

09 Oct '11

Stefan A. wrote: > If you read it ‚one of the ideas of having different virtual servers is > separation of policies for different NASses’ you are right. > > Suman was asking on how to send several NASses into the same policy. The simplest way to do it is to set *generic* policies, and then re-write them in post-auth. For example, define a "Policy-Name" attribute in the dictionary, and set it somewhere in the "authorize" section. Then: post-auth { ... if ("%{client:nas_type}" == "foo") { // map policies for client foo } elsif ("%{client:nas_type}" == "bar") { // map policies for client bar } ... } The underlying issue is that different NAS vendors have defined different attributes for the same functionality. An even simpler solution is to just return all of the VSAs to each NAS. As was said earlier, each NAS will ignore the ones it doesn't understand, and apply the ones it does. Alan DeKok.

3 2

Re: Dynamic Attributes Based on NAS Type !
by Suman Dash 09 Oct '11

09 Oct '11

To be specific , I am concerned about the QoS VSA's . For Example. Mikrotik NAS - Mikrotik-Rate-Limit Chillispot - Chillispot-Max-UP , Chillispot-Max-Down Cisco - Cisco-Policy-UP , Cisco-Policy-Down Now if the user logged from different NAS's the VSA will differ so it is not possible to have a single entry in radgroupreply or radreply pertaining to a kind of NAS. I guess that this is not an out of the box feature in freeradius , instead i need to use some kind of custom script in Post-Auth section which will check the NAS Type and reply out the correct VSA's I am looking for a unique identifier from NAS by which freeradius can understand what type of NAS it is. I tried it and it seems that i have no control on the Access-Request sent by NAS to freeradius. The only idea which currently comes into my mind is to use nas.type value in DB but incase the NAS Type is incorrectly specified reply attributes will go nuts . So any idea if there are any unique identifiers ? Regards Suman On Sat, Oct 8, 2011 at 9:40 PM, Stefan A. <a.freeradius(a)premit.de> wrote: > ** ** > > Suman,**** > > As you did not say anything about the exact attributes, you will send to > the NAC, here is how we do this:**** > > ** ** > > we are also using different NAS and have to reply with different VSAs for > setting up the QOS.**** > > We use the “existence of a specific VSAs” (specified per NAS type) in the > request to select the VSAs to be used in responses.**** > > ** ** > > e.g: if we found the Starent Networks VSA ‘SN-Service-Type’ in the request, > we reply with ‘SN-QOS-Profile’ to set up QoS**** > > This is save, as we won’t see any Starent VSAs in Cisco or Chillispot > NASses.**** > > ** ** > > To make this flexible, we have set up our own VSA to configure users QOS, > which is then translated into the specific reply attributes for the NAS, the > user is currently using.**** > > ** ** > > Regards**** > > Stefan**** > > ** ** > > *From:* freeradius-users-bounces+a.freeradius= > premit.de(a)lists.freeradius.org [mailto: > freeradius-users-bounces+a.freeradius=premit.de(a)lists.freeradius.org] *On > Behalf Of *Suman Dash > *Sent:* Saturday, October 08, 2011 4:40 PM > *To:* FreeRadius users mailing list > *Subject:* Dynamic Attributes Based on NAS Type !**** > > ** ** > > Hi Everyone ... Currently i am planning to integrate freeradius with > different NAS like Chillispot , Cisco etc and enable roaming users so that > they can log in from any of the NAS. > > As the reply items are different with different NAS , i am looking for > ideas how to enable a single user to roam and connect from different NAS. > > In my case i think static reply items are not possible per user wise or per > groupwise so my question is what trick can be used to achieve the same. > > I had not tried anything as i have no clue on the same so some highlights > on the approach will be a good starting point for me. > > Cheers > Suman > > **** > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > >

3 2