Conditional expression ":-" deprecated?
We have a vendor product that only supports usernames shorter than 64 characters. I used the unlang expression: if ("%{#User-Name:-0}" <= 63) to avoid sending accounting with longer usernames to it, which yielded: server buffered-dpi-esc4 { +- entering group preacct {...} ++? if ("%{#User-Name:-0}" <= 63) WARNING: Deprecated conditional expansion ":-". See "man unlang" for details expand: %{#User-Name:-0} -> 70 ? Evaluating ("%{#User-Name:-0}" <= 63) -> FALSE ++? if ("%{#User-Name:-0}" <= 63) -> FALSE I got the ":-" expression from unlang(5), which doesn't mention that it's deprecated. I used this expression to specify a default length of 0 since unlang(5) states that %{#attr} returns an empty value if attr isn't present, and I wasn't sure how FreeRADIUS would react to a numeric comparison against an unset value. I'm using: if (User-Name && "%{#User-Name}" <= 63) { instead for now, but is the ":-" expression really deprecated, and is there an alternative equivalent? How will FreeRADIUS react to an unset value in a numeric comparison? john -- John Morrissey _o /\ ---- __o jwm@horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
At 12:19 PM 1/23/2010, Alan DeKok wrote:
John Morrissey wrote:
WARNING: Deprecated conditional expansion ":-". See "man unlang" for details
Use %{%{#User-Name}:-0}
Thanks Alan, I have the same (or very similar issue): [files] expand: OU=Enterprise,DC=int,DC=invtitle,DC=com -> OU=Enterprise,DC=int,DC=invtitle,DC=com [files] WARNING: Deprecated conditional expansion ":-". See "man unlang" for details [files] ... expanding second conditional [files] expand: %{User-Name} -> rsteeves Can you by chance point out how I can change the code to not deprecated: users: DEFAULT Huntgroup-Name == Cisco_Huntgroup, Auth-Type:=ntlm_auth, Ldap-Group == "Infrastructure" Service-Type:=NAS-Prompt-User, cisco-avpair:="shell:priv-lvl=15", Reply-Message := "Authorized Users Only" DEFAULT Huntgroup-Name == Cisco_Huntgroup, Auth-Type:=ntlm_auth, Ldap-Group == "HelpDesk" Service-Type:=NAS-Prompt-User, cisco-avpair:="shell:priv-lvl=1", Reply-Message := "Authorized Users Only" DEFAULT Huntgroup-Name == VPN_Huntgroup, Ldap-Group == "VPN_Users" Reply-Message := "Authorized Users Only" but I suspect it's this in the LDAP module: filter = (&(sAMAccountname=%{Stripped-User-Name:-%{User-Name}})(objectClass=person)) Thx. Rick
freeradius@corwyn.net wrote:
I have the same (or very similar issue):
[files] expand: OU=Enterprise,DC=int,DC=invtitle,DC=com -> OU=Enterprise,DC=int,DC=invtitle,DC=com [files] WARNING: Deprecated conditional expansion ":-". See "man unlang" for details
It's in the LDAP module.
but I suspect it's this in the LDAP module: filter = (&(sAMAccountname=%{Stripped-User-Name:-%{User-Name}})(objectClass=person))
Yes. That can be fixed, too. Alan DeKok.
Hi,
but I suspect it's this in the LDAP module: filter = (&(sAMAccountname=%{Stripped-User-Name:-%{User-Name}})(objectClass=person))
(&(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})(objectClass=person)) there have been a few places where these things have been fixed in the default configurations so remove those errors.....though its suprising how many people still run their servers with that error message being flagged...surely you read it and think 'WARNING? must check that out and fix it' ? ..and , in fact, the latest version has that default value fixed. go grab the 2.1.8 source code and check raddb/modules/ldap file... alan
At 06:45 AM 1/24/2010, Alan Buxey wrote:
(&(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})(objectClass=person))
thanks
there have been a few places where these things have been fixed in the default configurations so remove those errors.....though its suprising how many people still run their servers with that error message being flagged...surely you read it and think 'WARNING? must check that out and fix it' ?
Sure do!, and posted the question :-) this is from a recent 2.17 install using the associated docs on the freeradius pages. . . It's the same reason I keep asking about this error: [ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap] user rsteeves authorized to use remote access
..and , in fact, the latest version has that default value fixed. go grab the 2.1.8 source code and check raddb/modules/ldap file...
Thx, will do. One question about that file. Example: # seconds LDAP server has to process the query (server-side # time limit). default: 20 # # LDAP_OPT_TIMELIMIT is set to this value. timelimit = 3 Why does it say the default is 20, and yet actually have the default value set to 3? Rick
Hi,
It's the same reason I keep asking about this error:
[ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap] user rsteeves authorized to use remote access
<shrug> - LDAP was unable to find a useable password for the user in LDAP - for the authentication - but as this is the authorization (authz) stage then not to worry?
Thx, will do. One question about that file. Example:
# seconds LDAP server has to process the query (server-side # time limit). default: 20 # # LDAP_OPT_TIMELIMIT is set to this value. timelimit = 3
Why does it say the default is 20, and yet actually have the default value set to 3?
sshhh. its better you dont know.... ;-) seriously, its probably badly worded. if you DONT define it, then the default value is 20. however, its defined in the config ..but that isnt the 'default' value..the default value is hardcoded...what that '3' is is the current supplied configuration value. in almost all places I know, '20' would be WAYYYYY too long a wait. alan
At 04:26 PM 1/24/2010, Alan Buxey wrote:
It's the same reason I keep asking about this error:
[ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap] user rsteeves authorized to use remote access
<shrug> - LDAP was unable to find a useable password for the user in LDAP - for the authentication - but as this is the authorization (authz) stage then not to worry?
I'd think that, but I have it on good advice to worry about Warning messages ;) Rick
participants (4)
-
Alan Buxey -
Alan DeKok -
freeradius＠corwyn.net -
John Morrissey