I'm playing around with CUI generation with FreeRADIUS 2.2.0 and discovered something odd. In policy.conf I've set cui_require_operator_name = 1 and cui_hash_key = "4c2982f2f3b1dc4804994cf386db8c0a34d4ab2a". As you can see it's a 32-character string and it looks like a hash. In radiusd -X output I get this: Ready to process requests. rad_recv: Access-Request packet from host 192.168.126.155 port 1814, id=17, length=113 User-Name = "steve@diamond.ac.uk" User-Password = "testing" NAS-IP-Address = 127.0.0.1 NAS-Port = 0 Message-Authenticator = 0x80a453196d15a8e68ba13642ba725b24 Proxy-State = 0x30 Operator-Name = "1camford.ac.uk" Chargeable-User-Identity = "" Proxy-State = 0x313630 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++? if (!(User-Name =~ /@/)) ?? Evaluating (User-Name =~ /@/) -> TRUE ? Converting !TRUE -> FALSE ++? if (!(User-Name =~ /@/)) -> FALSE ++? if (User-Name =~ /@$/) ? Evaluating (User-Name =~ /@$/) -> FALSE ++? if (User-Name =~ /@$/) -> FALSE ++? if (User-Name =~ /@.+?@/) ? Evaluating (User-Name =~ /@.+?@/) -> FALSE ++? if (User-Name =~ /@.+?@/) -> FALSE ++? if (User-Name =~ /@.+?[^[:alnum:]\\.-]/) ? Evaluating (User-Name =~ /@.+?[^[:alnum:]\\.-]/) -> FALSE ++? if (User-Name =~ /@.+?[^[:alnum:]\\.-]/) -> FALSE ++? if (User-Name =~ /@[\\.-]/) ? Evaluating (User-Name =~ /@[\\.-]/) -> FALSE ++? if (User-Name =~ /@[\\.-]/) -> FALSE ++? if (User-Name =~ /@.+?[\\.-]$/) ? Evaluating (User-Name =~ /@.+?[\\.-]$/) -> FALSE ++? if (User-Name =~ /@.+?[\\.-]$/) -> FALSE ++? if (User-Name =~ /@[^\\.]+$/) ? Evaluating (User-Name =~ /@[^\\.]+$/) -> FALSE ++? if (User-Name =~ /@[^\\.]+$/) -> FALSE ++? if (User-Name =~ /@.+?\\.\\./) ? Evaluating (User-Name =~ /@.+?\\.\\./) -> FALSE ++? if (User-Name =~ /@.+?\\.\\./) -> FALSE ++? if (User-Name =~ /@myabc\\.com$/i) ? Evaluating (User-Name =~ /@myabc\\.com$/i) -> FALSE ++? if (User-Name =~ /@myabc\\.com$/i) -> FALSE ++? if (User-Name =~ /@wlan\\.[[:alnum:]]+\\.[[:alnum:]]+\\.3gppnetwork\\.org$/i) ? Evaluating (User-Name =~ /@wlan\\.[[:alnum:]]+\\.[[:alnum:]]+\\.3gppnetwork\\.org$/i) -> FALSE ++? if (User-Name =~ /@wlan\\.[[:alnum:]]+\\.[[:alnum:]]+\\.3gppnetwork\\.org$/i) -> FALSE ++? if (User-Name =~ /@gmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) ? Evaluating (User-Name =~ /@gmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) -> FALSE ++? if (User-Name =~ /@gmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) -> FALSE ++? if (User-Name =~ /@yahoo\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) ? Evaluating (User-Name =~ /@yahoo\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) -> FALSE ++? if (User-Name =~ /@yahoo\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) -> FALSE ++? if (User-Name =~ /@hotmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) ? Evaluating (User-Name =~ /@hotmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) -> FALSE ++? if (User-Name =~ /@hotmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) -> FALSE ++? if (User-Name =~ /@\\.?ac\\.uk$/i) ? Evaluating (User-Name =~ /@\\.?ac\\.uk$/i) -> FALSE ++? if (User-Name =~ /@\\.?ac\\.uk$/i) -> FALSE ++? if (User-Name =~ /@.+?\\.ax\\.uk$/i) ? Evaluating (User-Name =~ /@.+?\\.ax\\.uk$/i) -> FALSE ++? if (User-Name =~ /@.+?\\.ax\\.uk$/i) -> FALSE ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] Looking up realm "diamond.ac.uk" for User-Name = "steve@diamond.ac.uk" [suffix] Found realm "diamond.ac.uk" [suffix] Adding Stripped-User-Name = "steve" [suffix] Adding Realm = "diamond.ac.uk" [suffix] Authentication realm is LOCAL. ++[suffix] returns ok [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry steve at line 76 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group PAP {...} [pap] login attempt with password "testing" [pap] Using clear text password "testing" [pap] User authenticated successfully ++[pap] returns ok # Executing section post-auth from file /etc/raddb/sites-enabled/default +- entering group post-auth {...} ++- entering policy cui_postauth {...} +++? if (FreeRadius-Proxied-To == 127.0.0.1) (Attribute FreeRadius-Proxied-To was not found) ? Evaluating (FreeRadius-Proxied-To == 127.0.0.1) -> FALSE +++? if (FreeRadius-Proxied-To == 127.0.0.1) -> FALSE +++- entering else else {...} ++++? if (!("%{control:Proxy-To-Realm}") && Chargeable-User-Identity && !(reply:Chargeable-User-Identity) && (Operator-Name || !("${policy.cui_require_operator_name}")) ) expand: %{control:Proxy-To-Realm} -> ?? Evaluating ("%{control:Proxy-To-Realm}") -> FALSE ? Converting !FALSE -> TRUE ? Evaluating (Chargeable-User-Identity ) -> TRUE ?? Evaluating (reply:Chargeable-User-Identity) -> FALSE ? Converting !FALSE -> TRUE ?? Evaluating (Operator-Name ) -> TRUE ??? Skipping ("${policy.cui_require_operator_name}") ++++? if (!("%{control:Proxy-To-Realm}") && Chargeable-User-Identity &&!(reply:Chargeable-User-Identity) && (Operator-Name || !("${policy.cui_require_operator_name}")) ) -> TRUE ++++- entering if (!("%{control:Proxy-To-Realm}") && Chargeable-User-Identity &&!(reply:Chargeable-User-Identity) && (Operator-Name || !("${policy.cui_require_operator_name}")) ) {...} expand: %{md5:4c2982f2f3b1dc4804994cf386db8c0a34d4ab2a%{User-Name}%{%{Operator-Name}:-}} -> +++++[reply] returns noop ++++- if (!("%{control:Proxy-To-Realm}") && Chargeable-User-Identity && !(reply:Chargeable-User-Identity) && (Operator-Name || !("${policy.cui_require_operator_name}")) ) returns noop +++- else else returns noop ++- policy cui_postauth returns noop As you can see, the expand: bit shows an empty value. Then I changed my cui_hash_key to "01234567890abcdef01234567890abcdef" and it did the same. However, when I set cui_hash_key to a hex string that was not 32 characters in length ("abcdef" as an example), or a non-hex string of any length, it works ok. So I'm guessing here that if the cui_hash_key happens to be a string that is a potentially valid MD5 hash, the md5 operator in the CUI generation statement does nothing or barfs. Working fragment: ++++- entering if (!("%{control:Proxy-To-Realm}") && Chargeable-User-Identity &&!(reply:Chargeable-User-Identity) && (Operator-Name || !("${policy.cui_require_operator_name}")) ) {...} expand: %{Operator-Name} -> 1camford.ac.uk expand: abcdef%{User-Name}%{%{Operator-Name}:-} -> abcdefsteve@diamond.ac.uk1camford.ac.uk expand: %{md5:abcdef%{User-Name}%{%{Operator-Name}:-}} -> 330a6f12e7152cb8888ef6aaa30b1aed +++++[reply] returns noop If this is known already, then that's fine (because it means you'll probably fix it in the future). Just thought I'd flag this up. In the meanwhile I've changed my cui_hash_key to something non-hex to avoid this issue. Stefan Paetow Software Engineer +44 1235 778812 Diamond Light Source Ltd. Diamond House, Harwell Science and Innovation Campus Didcot, Oxfordshire, OX11 0DE -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
Hi,
rad_recv: Access-Request packet from host 192.168.126.155 port 1814, id=17, length=113
User-Name = "steve@diamond.ac.uk"
User-Password = "testing"
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Message-Authenticator = 0x80a453196d15a8e68ba13642ba725b24
Proxy-State = 0x30
Operator-Name = "1camford.ac.uk"
this is wrong. please update your config so that you are setting the correct Operator-Name - you seem to have copied some example document verbatim CUI policy has been updated quite a bit - the 3.x has more updates...check the latest 2.2.1 code to see what policy looks like. alan
Hi Alan, No, the operator name was 'correct' for our purposes. This is not a live system, we were using 'camford.ac.uk' as the 'visited site' on our test network. In the real world, it would be the correct operator name. :-) So, if I were to download v2.2.1, would a 32-character hex-string in cui_hash_key work or would it still cause the expand: portion to give me an empty value? Regards Stefan -----Original Message----- From: freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: 10 May 2013 11:00 To: FreeRadius users mailing list Subject: Re: Bug in CUI generation? Is this a known issue? Hi,
rad_recv: Access-Request packet from host 192.168.126.155 port 1814, id=17, length=113
User-Name = "steve@diamond.ac.uk"
User-Password = "testing"
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Message-Authenticator = 0x80a453196d15a8e68ba13642ba725b24
Proxy-State = 0x30
Operator-Name = "1camford.ac.uk"
this is wrong. please update your config so that you are setting the correct Operator-Name - you seem to have copied some example document verbatim CUI policy has been updated quite a bit - the 3.x has more updates...check the latest 2.2.1 code to see what policy looks like. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
Hi, On Fri, May 10, 2013 at 09:49:14AM +0000, stefan.paetow@diamond.ac.uk wrote:
As you can see, the expand: bit shows an empty value. Then I changed my cui_hash_key to "01234567890abcdef01234567890abcdef" and it did the same. However, when I set cui_hash_key to a hex string that was not 32 characters in length ("abcdef" as an example), or a non-hex string of any length, it works ok. So I'm guessing here that if the cui_hash_key happens to be a string that is a potentially valid MD5 hash, the md5 operator in the CUI generation statement does nothing or barfs.
Bug. src/main/xlat.c:1077 has: if (isdigit(l[1])) break; which stops looking for a module_name (e.g. "md5" if the first character after the : is a digit. Fixed in 3.0 (see 4fd62ce9 22 August 2012). Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 10/05/13 12:12, Matthew Newton wrote:
Hi,
On Fri, May 10, 2013 at 09:49:14AM +0000, stefan.paetow@diamond.ac.uk wrote:
As you can see, the expand: bit shows an empty value. Then I changed my cui_hash_key to "01234567890abcdef01234567890abcdef" and it did the same. However, when I set cui_hash_key to a hex string that was not 32 characters in length ("abcdef" as an example), or a non-hex string of any length, it works ok. So I'm guessing here that if the cui_hash_key happens to be a string that is a potentially valid MD5 hash, the md5 operator in the CUI generation statement does nothing or barfs.
Bug. src/main/xlat.c:1077 has:
if (isdigit(l[1])) break;
which stops looking for a module_name (e.g. "md5" if the first character after the : is a digit.
Fixed in 3.0 (see 4fd62ce9 22 August 2012).
I think it's fixed in 2.2 head as well? IIRC leaving a " " after the ":" works fine.
Thank you :-) Regards Stefan -----Original Message----- From: freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org] On Behalf Of Matthew Newton Sent: 10 May 2013 12:13 To: FreeRadius users mailing list Subject: Re: Bug in CUI generation? Is this a known issue? Hi, On Fri, May 10, 2013 at 09:49:14AM +0000, stefan.paetow@diamond.ac.uk wrote:
As you can see, the expand: bit shows an empty value. Then I changed my cui_hash_key to "01234567890abcdef01234567890abcdef" and it did the same. However, when I set cui_hash_key to a hex string that was not 32 characters in length ("abcdef" as an example), or a non-hex string of any length, it works ok. So I'm guessing here that if the cui_hash_key happens to be a string that is a potentially valid MD5 hash, the md5 operator in the CUI generation statement does nothing or barfs.
Bug. src/main/xlat.c:1077 has: if (isdigit(l[1])) break; which stops looking for a module_name (e.g. "md5" if the first character after the : is a digit. Fixed in 3.0 (see 4fd62ce9 22 August 2012). Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
Matthew Newton wrote:
Bug. src/main/xlat.c:1077 has:
if (isdigit(l[1])) break;
which stops looking for a module_name (e.g. "md5" if the first character after the : is a digit.
Yeah... that's hard to fix in 2.x. The code is rich in material plants like. (If you get my drift)
Fixed in 3.0 (see 4fd62ce9 22 August 2012).
And with test cases now! See src/tests/xlat.c Alan DeKok.
Thank you, Alan. :-) Stefan -----Original Message----- From: freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org] On Behalf Of Alan DeKok Sent: 13 May 2013 17:28 To: FreeRadius users mailing list Subject: Re: Bug in CUI generation? Is this a known issue? Matthew Newton wrote:
Bug. src/main/xlat.c:1077 has:
if (isdigit(l[1])) break;
which stops looking for a module_name (e.g. "md5" if the first character after the : is a digit.
Yeah... that's hard to fix in 2.x. The code is rich in material plants like. (If you get my drift)
Fixed in 3.0 (see 4fd62ce9 22 August 2012).
And with test cases now! See src/tests/xlat.c Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Matthew Newton -
Phil Mayers -
stefan.paetow＠diamond.ac.uk