Hi, I know this is not your average user request but... We are configuring the scenario described in the attached message that I sent to the list about a month ago... I am implementing most of Hugh's suggestions to that message. I have an LDAP structure like this: o=our organization | +--ou=radiusWholesale | | | +--o=customer1 (customer1 data, including radius servers and secrets) | | | | | +--uid=profile1 (customer1, profile1 data, including port limits) | | | | | +--uid=profile2 (customer1, profile2 data, including port limits) | | | +--o=customer2 (customer2 data, including radius servers and secrets) | | | | | +--uid=profile1 (customer2, profile1 data, including port limits) | | | | | +--uid=profile2 (customer2, profile2 data, including port limits) | | | | | +--uid=profile3 (customer2, profile3 data, including port limits) | | ... ... | +--o=customerN (customerN data, including radius servers and secrets) | | | +--uid=profile1 (customerN, profile1 data, including port limits) | | | +--uid=profile2 (customerN, profile2 data, including port limits) | +--ou=otherStuffNonRelatedToThis... | ... For now on, I have a few "radius wholesale" customers, so I am configuring the handlers by hand. I decide who is the wholesale customer based on the realm of the request. This realm is part of the CustomerX data entry in the LDAP tree. It would be nice to be able to define the <Handler>'s dinamically from the LDAP tree, so, adding a new customer is as simple as adding the corresponding subtree to the LDAP including the realm... I wouldn't care reloading Radiator in order to do this ;-), but it would be great not having to [copy, paste, edit] an old <Handler> and then reloading. What about something like this maybe for Radiator 3.0? (or 9.3?) :-) -- Mariano Absatz El Baby
Hello, I want to do the following: We have our own customers authenticating through LDAP (<AuthBy LDAP2>) and we keep accounting and the on line users in a MySQL database. Now we want to sale access through our NAS to other ISP's (we sell on line wireless access, through a shasta tunneling box). The idea is as follows: we wholesale to the other ISP a bunch of simultaneous connections with different characteristics, for instance: 50 64kbps connections 30 128kbps connections 10 256kbps connections 10 512kbps connections 5 1mbps connections We don't care about the other ISP users and passwords or which kind of connection they give to each user as long as this ISP's users don't exceed the maximum simultaneous connections of each kind. The idea is that the kind of connection be not preconfigured on the user's name or realm, but that the other ISP radius server be able to send it to us in an attribute, so they are able to dynamically assign the connections. That is, if they bought the example above, but have 60 customers for the 64kb connections, they are able to evaluate when the 51st. user is trying to log in and if there is another kind of connection available, they assign that. When we receive the Access-Accept from their radius server we should check this attribute and recodify it into a suitable attribute to send to the shasta (Shasta-Service-Profile), according to a set of rules. The quantities of connections for each customer ISP (we expect to have more than one) should be changeable on line (I would rather use LDAP than SQL, since all our provisioning works with LDAP). Now for the questions: 1) How should I combine <AuthBy Radius> with <AuthBy PORTLIMITCHECK> so I can do the port limit check AFTER I get the Radius Access-Accept. 2) Can I check the limits against something found in an LDAP entry? How? Otherwise, is there other solution? (probably through SQL) 3) We would like to add the accounting packets to our accounting AND ALSO send them to the other ISP. Is it possible, how do we do it? 4) What would be the "correct" attribute to pass info from the other ISP to us saying "accept and use this specific kind of connection"? I've been browsing through the RFC's and Configuration-Token (78) (RFC2869, page 31) seems to be the right choice... am I right? (BTW, it could be added to the next release of the dictionary ;-) TIA. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
