[RADIATOR] ERR: Bad attribute=value pair
Hi, I've configured the following lines in an AuthBy LDAP2 block: # store the users mobile phone number in the 'mobile' attribute, # his mail address in the 'mail' attribute and # his group memberships in the 'memberof' attribute. # The 'mobile' or 'mail' attribute is copied by the hook into the # Callback-Number attribute depending on the group membership AuthAttrDef mobile,GENERIC,request AuthAttrDef mail,GENERIC,request AuthAttrDef memberof,GENERIC,request This results in error messages in the log: Tue Jul 16 08:49:46 2013: ERR: Bad attribute=value pair: n...@fqdn.org Tue Jul 16 08:49:46 2013: ERR: Bad attribute=value pair: +4312345678 Is this because mobile and mail are not in the dictionary? Why isn't the error also thrown for memberof? -- Best regards, Alexander Hartmaier T-Systems Austria GesmbH TSS Security Services Network Security Monitoring Engineer phone: +43(0)57057-4320 fax: +43(0)57057-954320 *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ERR: Bad attribute=value pair
On 07/16/2013 12:03 PM, Alexander Hartmaier wrote: AuthAttrDef mobile,GENERIC,request AuthAttrDef mail,GENERIC,request AuthAttrDef memberof,GENERIC,request This results in error messages in the log: Tue Jul 16 08:49:46 2013: ERR: Bad attribute=value pair: n...@fqdn.org Tue Jul 16 08:49:46 2013: ERR: Bad attribute=value pair: +4312345678 GENERIC expects the values fetched from LDAP to be in 'AttributeName=value' format. Maybe this would work better: AuthAttrDef mobile,mobile,request AuthAttrDef mail,mail,request AuthAttrDef memberof,memberof,request Is this because mobile and mail are not in the dictionary? No. Dictionary is only required if the attribute and its value need to be packed in the network transfer format. That is, numbers instead of attribute names etc. Why isn't the error also thrown for memberof? Most likely because the memberof LDAP attribute value is in CN=... format. When attribute is added in the request, CN is taken as the attribute name and the rest (...) as the value. 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] documentation typo at 13.1.33 DefineFormattedGlobalVarsystem
On 07/15/2013 05:18 PM, Karl Gaissmaier wrote: there is a missing whitespace in the documentation: Hello Charly, this will be fixed in the next ref.pdf. DefineFormattedGlobalVar system mysystem 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] ERR: Bad attribute=value pair
On 2013-07-16 16:46, Heikki Vatiainen wrote: On 07/16/2013 12:03 PM, Alexander Hartmaier wrote: AuthAttrDef mobile,GENERIC,request AuthAttrDef mail,GENERIC,request AuthAttrDef memberof,GENERIC,request This results in error messages in the log: Tue Jul 16 08:49:46 2013: ERR: Bad attribute=value pair: n...@fqdn.org Tue Jul 16 08:49:46 2013: ERR: Bad attribute=value pair: +4312345678 GENERIC expects the values fetched from LDAP to be in 'AttributeName=value' format. Maybe this would work better: AuthAttrDef mobile,mobile,request AuthAttrDef mail,mail,request AuthAttrDef memberof,memberof,request Thanks, that did the trick! Is this because mobile and mail are not in the dictionary? No. Dictionary is only required if the attribute and its value need to be packed in the network transfer format. That is, numbers instead of attribute names etc. Makes sense. Why isn't the error also thrown for memberof? Most likely because the memberof LDAP attribute value is in CN=... format. When attribute is added in the request, CN is taken as the attribute name and the rest (...) as the value. Yeah, I guess it's even memberof=CN=,memberof=CN= and therefore worked as well. Thanks, Heikki *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] proxying POD reply packets
On 07/13/2013 08:20 PM, Michael wrote: So, my complicated config determines what device the request needs to go to and sends, and then it converts the POD and COA packets to accounting packets using scripting, then sends to my accounting handler and that POD/COA request is logged. Ok, so that's where the 'Accounting rejected' log entry in your first message came from. The default processing in Radiator will proxy back both ACKed and NAKed messages. The latter will be logged as a failed message with 'Change-Filter-Request rejected: thereason', but it will be proxied back just like an ACKed reply. However, rejected accounting messages are dropped. The RADIUS spec does not specify how to reject accounting messages, so there's no Accounting-Rejected message type to send back. You get drops instead. 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] proxying POD reply packets
On 16/07/13 04:24 PM, Heikki Vatiainen wrote: On 07/13/2013 08:20 PM, Michael wrote: So, my complicated config determines what device the request needs to go to and sends, and then it converts the POD and COA packets to accounting packets using scripting, then sends to my accounting handler and that POD/COA request is logged. Ok, so that's where the 'Accounting rejected' log entry in your first message came from. The default processing in Radiator will proxy back both ACKed and NAKed messages. The latter will be logged as a failed message with 'Change-Filter-Request rejected: thereason', but it will be proxied back just like an ACKed reply. However, rejected accounting messages are dropped. The RADIUS spec does not specify how to reject accounting messages, so there's no Accounting-Rejected message type to send back. You get drops instead. Thanks, Heikki hmm so, are you saying radiator after proxying out my POD/COA requests, and after i then convert the packet to an accounting packet and log it, radiator is actually expecting that the POD/COA reply coming back is actually an accounting reply and does not relay it to the radpwtst? ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
