I am trying to create a new checkItem using an attribute stored in LDAP. I would like radius to check ldap to see if the attribute exists for a user and if it does, not assign a radiusPoolName. I have a radiusSNSEnable attribute setup in ldap and in the dictionary files as a check item. I have done lots of testing and googling and I have not found a clean solution that works. Below is the entry from my users file: DEFAULT SNS-Enable != "1" USR-Framed_IP_Address_Pool_Name = "BLACKHOLE1", Idle-Timeout := "120", Fall-Through = Yes Correct me if I'm wrong but that should mean, if the SNS-Enable attribute does not equal 1, assign the USR-Framed_IP_Address_Pool_Name and Idle-Timeout. I have SNS-Enable as a checkItem mapped to radiusSNSEnable in the ldap.attrmap. Does anyone have a solution for this? Could it be a processing order problem that I'm seeing? Does it process the users file and then LDAP so it's not checking or assigning the variable properly? If I set radiusSNSEnable as a replyItem I see it in the radius reply so I know it's getting the value. Thanks in advance for anyone that can help.
Joe H <jharlan@gwi.net> wrote:
Correct me if I'm wrong but that should mean, if the SNS-Enable attribute does not equal 1, assign the USR-Framed_IP_Address_Pool_Name and Idle-Timeout. I have SNS-Enable as a checkItem mapped to radiusSNSEnable in the ldap.attrmap.
That should be OK.
Does anyone have a solution for this? Could it be a processing order problem that I'm seeing? Does it process the users file and then LDAP so it's not checking or assigning the variable properly?
It's probably a processing order. To change the order, see the "authorize" section of "radiusd.conf". This information is also printed out in debugging mode. Alan DeKok.
I have changed the order in which the files are processed and it didn't change anything. I can see in the debug that it finds the attributes: rlm_ldap: performing search in ou=people,dc=test,dc=com, with filter (uid=test) rlm_ldap: looking for check items in directory... rlm_ldap: Adding radiusSNSEnable as SNS-Enable, value 0 & op=21 rlm_ldap: looking for reply items in directory... rlm_ldap: Adding radiusSNSEnable as SNS-Enable, value 0 & op=11 but that comes after the: modcall[authorize]: module "suffix" returns noop for request 0 users: Matched entry DEFAULT at line 2 users: Matched entry DEFAULT at line 11 modcall[authorize]: module "files" returns ok for request 0 lines. lines 2 and 11 are other DEFAULT entries in the users file with fall-through set to yes. It skips right over the SNS-Enable checkItem. Anything else anyone can think of to get this working? Thanks. On Tue, 30 Aug 2005, Alan DeKok wrote:
Joe H <jharlan@gwi.net> wrote:
Correct me if I'm wrong but that should mean, if the SNS-Enable attribute does not equal 1, assign the USR-Framed_IP_Address_Pool_Name and Idle-Timeout. I have SNS-Enable as a checkItem mapped to radiusSNSEnable in the ldap.attrmap.
That should be OK.
Does anyone have a solution for this? Could it be a processing order problem that I'm seeing? Does it process the users file and then LDAP so it's not checking or assigning the variable properly?
It's probably a processing order. To change the order, see the "authorize" section of "radiusd.conf".
This information is also printed out in debugging mode.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Joe H <jharlan@gwi.net> wrote:
lines. lines 2 and 11 are other DEFAULT entries in the users file with fall-through set to yes. It skips right over the SNS-Enable checkItem.
Ah. The "users" file isn't set up to do comparisons on check items. So I don't think it will work. Alan DeKok.
Joe H <jharlan@gwi.net> wrote:
lines. lines 2 and 11 are other DEFAULT entries in the users file with fall-through set to yes. It skips right over the SNS-Enable checkItem.
Ah. The "users" file isn't set up to do comparisons on check items.
So I don't think it will work.
Alan DeKok.
That's basically the conclusion I came to, which is why I asked. Is there a way to add another attribute to the ldap module in the radiusd.conf. Something similar to the groupname_attribute? I've found that adding a fake second module to this file and setting groupname_attribute = radiusSNSEnable works if I do something like the following in the users file: DEFAULT sns-test-Ldap-Group != "1" USR-Framed_IP_Address_Pool_Name = "BLACKHOLE1", Idle-Timeout := "120", Fall-Through = Yes where sns-test is my module name. This way works but I think it's messy since I'm creating a module for just one attribute to be called. Plus if I ever need to add new attributes, that's a lot of modules. Thanks.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Joe H