Re: [RADIATOR] Converting from using a plaintext users file, to using LDAP
Hello Elvind - Yes this is fairly simple to do with multiple AuthBy clauses - in this case with a trailing AuthBy FILE to set the required reply attributes. Depending on how many groups you need, it may be preferable to have a group attribute in each user record rather than use memberOf. In either case you would do something like this: …… AuthByPolicy ContinueWhileAccept AuthBy GROUP # check users and determine group AuthByPolicy ContinueUntilAccept AuthBy LDAP2 ….. /AuthBy AuthBy LDAP2 ….. /AuthBy ….. /AuthBy AuthBy FILE # apply per-group reply attributes ….. /AuthBy ….. hope that helps regards Hugh On 24 Sep 2013, at 23:00, Eivind Olsen eiv...@aminor.no wrote: Hello. I've very recently been given the task of migrating an existing Radiator installation from having its users in a plaintext file (AuthBy FILE), to authenticating against LDAP. This sounds straight forward enough, I'm somewhat familiar with AuthBy LDAP2. Now, what gets me a bit confused is this: the current users textfile has entries with various attributes. Often it's the same attribute for many users, but not always. For example, some have Timetra-Cmd attribute listing read-only commands. Oh, and if possible, I'd prefer to _not_ store these directly in the LDAP (if I can avoid extending the LDAP schema and avoid having to mess up the user provisioning tool, I'd prefer that). What I'd like to accomplish somehow is mapping the various userlevels to group-membership in LDAP. If someone are a member of for example the group timetra-full-admin they'll get a Timetra-Cmd set to one thing ,and if they're a member of timetra-read-only they'll have it set to something else. Makes sense? If I have to store the attribute values directly in LDAP, there's also a high chance that whoever is provisioning users might make a typo of some sorts. In other words: I don't want to extract attribute X from LDAP, and returns its exact value. Oh, and if I can avoid using Perl hooks, that would also be a good thing for me :) One way I've thought might work is having multiple AuthBy LDAP2-blocks chained together, with different searchfilters and replying with specific attributes, similar to this pseudo-code: Auth-block1: if memberOf=timetra-full-admins reply with attr Timetra-Cmd=abcd, otherwise continue to next block Auth-block2: if memberOf=timetra-read-only reply with attr Timetra-Cmd=efgh, otherwise continue to next block ... no more blocks? Reject user. Part of me thinks there's bound to be a better way than this, though. Can anyone lend me a clue? :) Regards Eivind Olsen eiv...@aminor.no ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Hugh Irvine h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Converting from using a plaintext users file, to using LDAP
Hugh Irvine wrote: Yes this is fairly simple to do with multiple AuthBy clauses - in this case with a trailing AuthBy FILE to set the required reply attributes. My plan is to avoid the entire AuthBy FILE, if I can, so whoever is provisioning these users won't have to also edit a file, adding the users to the groups in LDAP should be sufficient. And if we need to make new levels of user access / giving special attributes to some, we'll add a new group and do a small change in radiusd.cfg I'll add the attributes with AddToReply, in the specific AuthBy block, and won't need to use an AuthBy FILE then? Regards Eivind Olsen ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy INTERNAL not sending reply after several AuthBy RADIUS
On 09/24/2013 05:47 PM, Tim Jones wrote: The debug output from the server shows the database being updated and returning ACCEPT, but then never sends out the Access-Accept response packet back to the NAS. Hello Tim, since you run this from ReplyHook returning from the Hook will not wind back to a Handler which would then make sure the reply is passed back to NAS. Take a look at how handlerResult is used e.g., by AuthRADIUS.pm to tell Handler that a reply was received. I have a feeling it is because of setting the $op to IGNORE when forwarding the request, but the RequestHook of AuthBy INTERNAL doesn't pass it as a parameter so I cannot modify its' RadiusResult. When the forwarding was done IGNORE was returned to Handler. Now when reply was received you'd need to invoke Handler to finish the processing. Am I trying to solve this problem the wrong way, or have I forgotten something? I think this comes from the asynchronous processing of requests. If I understood your configuration correctly, calling handlerResult should help. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Converting from using a plaintext users file, to using LDAP
Hello Elvind - Yes your approach will also work - I misunderstood your original question and thought you wanted to retain the AuthBy FILE component. The AuthBy FILE part would only be to hold the group reply attributes, which as you say can also be done with AddToReply in the simple case. regards Hugh On 25 Sep 2013, at 10:11, Eivind Olsen eiv...@aminor.no wrote: Hugh Irvine wrote: Yes this is fairly simple to do with multiple AuthBy clauses - in this case with a trailing AuthBy FILE to set the required reply attributes. My plan is to avoid the entire AuthBy FILE, if I can, so whoever is provisioning these users won't have to also edit a file, adding the users to the groups in LDAP should be sufficient. And if we need to make new levels of user access / giving special attributes to some, we'll add a new group and do a small change in radiusd.cfg I'll add the attributes with AddToReply, in the specific AuthBy block, and won't need to use an AuthBy FILE then? Regards Eivind Olsen -- Hugh Irvine h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Proxy and unknown attribute changes in 4.12.1 patches
Radiator 4.12.1 patches now have changes affecting handling unknown attributes and proxying them. Unknown attributes are now always accepted. A single warning, not error, is logged for each unknown attribute per sender. This will reduce the number of log messages but allows to keep an eye on unknown attributes. The unknown attributes are available with the other attributes. For example: ... Calling-Station-Id = 987654321 NAS-Port-Type = Async User-Password = Q12914213+19130C215145+]15T20425 Unknown-9048-120 = 0002 Unknown-0-93 = an example The first number is the vendor id (0 for IANA and e.g., 9048 for OSC) and the second number is the vendor assigned type. A new global option flag is available for controlling proxying behaviour. When ProxyUnknownAttributes is turned on, unknown attributes sent by clients will be proxied to next hop servers. If the responses from the next hop servers have unknown attributes, these too are returned back to the requesting clients. Attribute names starting with 'Unknown' are now reserved. Any attribute names starting with Unknown are ignored when loading dictionaries and a warning is logged. Please let us know how it goes, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
