(RADIATOR) AuthLDAP2.pm patch
Just found a little bug in AuthLDAP2.pm from Radiator 2.18.2, so I'm supplying a fix. When processing AuthAttrDef request items, if the LDAP attribute was multi-valued (such as objectClass), Radiator would only store the first array value in the RADIUS attribute. This is inconsistent because LDAP doesn't guarantee the order of return values (nor should it). My patch stores all LDAP attribute values into the specified RADIUS attribute in the request as a comma-separated string. (Sorry, no diff): In Radius/AuthLDAP2.pm, I changed line 454: $p-add_attr($attrib, $$vals[0]); to this: $p-add_attr($attrib, (join ',',@$vals)); Carl Litt Network Administrator Execulink Internet === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Digest::MD4 on RedHat???
I am having a problem with Radiator 2.18.2 dying after receiving MS-CHAP autentication requests. Perl complains about not being able to find Digest/MD4.pm, which I can't find anywhere. I'm running RedHat 6.2, so the previous posts concerning Activestate Perl do not apply. Does anyone know of SRPMS that will provide this module? Carl Litt Network Administrator Execulink Internet === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SNMPAgent patch: access restrictions now available
Yes, this is a good idea. I was a little concerned about leaving security up to a community string. Thanks for sharing, Carl Litt Network Administrator Execulink Internet On Wed, 4 Apr 2001, Karl Gaissmaier wrote: Hi all and Mike, I wrote a patch to SNMPAgent to restrict the acces to the Radius SNMP vars, especially to disallow unauthorized resets. You can now spend two separate communities for read-only and read-write and you can define a Managers list for allowed hosts. I would appreciate if the community decides this stuff useful. Please raise your hands if yes so Mike gets perhaps convinced to add this to one of the next patches/releases. I wrote this backward compatible to old config files with Community defined. If you don't define a managers list all hosts has access. The following parameters are new to the SNMPAgent clause: - 6.13.3 Community deprecated but allowed for backward compatibility 6.13.5 ROCommunity SNMP V1 provides a weak method of authenticating SNMP requests, using the "community name". This optional parameter allows you to specify the SNMP V1 community name that will be honored by SNMPAgent for read-only access. Defaults to nothing, you have to define one by yourself. We strongly recommend that you choose a community name and keep it secret. # Use a secret community. ROCommunity mysnmprosecret 6.13.6 RWCommunity This optional parameter allows you to specify the SNMP V1 community name that will be honored by SNMPAgent for read-write access. Knowing this secret you are able to reset Radiator via SNMP. Defaults to nothing. If you don't need resetting via SNMP use only ROCommunity. # only necessary for resetting via SNMP RWCommunity extremelysecure 6.13.7 Managers This optional parameter specifies a list of SNMP managers that have access to SNMPAgent. The value is a list of host names or addresses, separated by white space or comma. You can have any number of Managers lines. Defaults to nothing with all hosts allowed. # allowed SNMP managers Managersfoo.bar.edu 192.168.1.11, noc.rz.uni-ulm.de Managersbaz.bar.com,10.1.1.254 TODO: Documentation should be rewritten by a native speaker :-( Have fun with it. Regards Charly Gaissmaier === 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.
Re: (RADIATOR) DEFAULT User or Profiles with AuthBY LDAP2
I am already using AddToReplyIfNotExist for the standard RADIUS
attributes, but that is not quite suitable for user profiles.
Each of our users has a serviceType which defines which type of service
they pay for. For example, some of these users are what we call
"daytimers" because they are only allowed in off-peak hours. Other
service types have unique reply items to enforce the service policies.
What I want to do is detect from AuthBY LDAP2 that serviceType=DAY
(using a request item), and requery LDAP to retrieve the necessary reply
items (Time, Session-Timeout) from a service template found in a
calculated DN (serviceType=%{serviceType},...o=Top).
I'm pretty sure I know how to configure all of this, except that I can't
find a way to perform the second LDAP query for the service template.
The LDAP2 module requires a userPassword which would never match in a
template. Perhaps a new AuthBy LDAP2 parameter could disable the
password check, allowing additional check/reply items to be applied?
I would like to keep the profiles in LDAP for centralization and
simplified maintenance, but if worse came to worse I suppose I could
have it fall through to a flat 'users' file as documented in
"goodies/profiles.txt". (Does this sound reasonable?)
Thanks,
Carl Litt
Network Administrator
Execulink Internet
On Tue, 3 Apr 2001, Hugh Irvine wrote:
Hello Carl -
Why not just use an AddToReply in the AuthBy clause?
Section 6.16.7 in the Radiator 2.18 reference manual.
hth
Hugh
At 14:20 -0400 01/4/2, Carl Litt wrote:
I am trying to configure a DEFAULT user with AuthBy LDAP2. I want to
to authenticate the Access-Request via LDAP2, then retrieve a DEFAULT user
with LDAP2 which contains the necessary reply items. This is on my
way to using account profiles matched by LDAP request items.
The only problem is that AuthBy LDAP2 always expects to authenticate the
user with a password. The documentation (6.33.9) states that PasswordAttr
or EncryptedPasswordAttr are required in the LDAP configuration. I did
try it without PasswordAttr, but I get an LDAP_PARAM_ERROR. Obviously
this won't let me lookup a DEFAULT user record. I think I remember some
talk of how to do this with other AuthBy methods?
My question is: How can I use LDAP2 to append profiled (or DEFAULT)
reply items to an Access-Accept?
Here is what my config looks like right now:
AuthBy LDAP2
# Authenticate the Access-Request from LDAP
# (This all works fine)
Identifier LDAP-login
...
/AuthBy
AuthBy LDAP2
# Fetch the DEFAULT user's reply items
Identifier LDAP-DEFAULT
...
SearchFilter
((objectclass=radiusAccount)([EMAIL PROTECTED]))
UsernameAttrmailLocalAddress
AuthAttrDef radiusReplyItem,GENERIC,reply
/AuthBy
AuthBy GROUP
Identifier genericLDAP
AuthByPolicyContinueWhileAccept
AuthBy LDAP-login
AuthBy LDAP-DEFAULT
/AuthBy
Thanks,
Carl Litt
Network Administrator
Execulink Internet
===
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.
===
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.
(RADIATOR) DEFAULT User or Profiles with AuthBY LDAP2
I am trying to configure a DEFAULT user with AuthBy LDAP2. I want to to authenticate the Access-Request via LDAP2, then retrieve a DEFAULT user with LDAP2 which contains the necessary reply items. This is on my way to using account profiles matched by LDAP request items. The only problem is that AuthBy LDAP2 always expects to authenticate the user with a password. The documentation (6.33.9) states that PasswordAttr or EncryptedPasswordAttr are required in the LDAP configuration. I did try it without PasswordAttr, but I get an LDAP_PARAM_ERROR. Obviously this won't let me lookup a DEFAULT user record. I think I remember some talk of how to do this with other AuthBy methods? My question is: How can I use LDAP2 to append profiled (or DEFAULT) reply items to an Access-Accept? Here is what my config looks like right now: AuthBy LDAP2 # Authenticate the Access-Request from LDAP # (This all works fine) Identifier LDAP-login ... /AuthBy AuthBy LDAP2 # Fetch the DEFAULT user's reply items Identifier LDAP-DEFAULT ... SearchFilter ((objectclass=radiusAccount)([EMAIL PROTECTED])) UsernameAttrmailLocalAddress AuthAttrDef radiusReplyItem,GENERIC,reply /AuthBy AuthBy GROUP Identifier genericLDAP AuthByPolicyContinueWhileAccept AuthBy LDAP-login AuthBy LDAP-DEFAULT /AuthBy Thanks, Carl Litt Network Administrator Execulink Internet === 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.
(RADIATOR) DEFAULT User or Profiles with AuthBY LDAP2
I am trying to configure a DEFAULT user with AuthBy LDAP2. I want to to authenticate the Access-Request via LDAP2, then retrieve a DEFAULT user with LDAP2 which contains the necessary reply items. This is on my way to using account profiles matched by LDAP request items. The only problem is that AuthBy LDAP2 always expects to authenticate the user with a password. The documentation (6.33.9) states that PasswordAttr or EncryptedPasswordAttr are required in the LDAP configuration. I did try it without PasswordAttr, but I get an LDAP_PARAM_ERROR. Obviously this won't let me lookup a DEFAULT user record. I think I remember some talk of how to do this with other AuthBy methods? My question is: How can I use LDAP2 to append profiled (or DEFAULT) reply items to an Access-Accept? Here is what my config looks like right now: AuthBy LDAP2 # Authenticate the Access-Request from LDAP # (This all works fine) Identifier LDAP-login ... /AuthBy AuthBy LDAP2 # Fetch the DEFAULT user's reply items Identifier LDAP-DEFAULT ... SearchFilter ((objectclass=radiusAccount)([EMAIL PROTECTED])) UsernameAttrmailLocalAddress AuthAttrDef radiusReplyItem,GENERIC,reply /AuthBy AuthBy GROUP Identifier genericLDAP AuthByPolicyContinueWhileAccept AuthBy LDAP-login AuthBy LDAP-DEFAULT /AuthBy Thanks, Carl Litt Network Administrator Execulink Internet === 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.
