New checkItem from LDAP
jharlan at gwi.net
Tue Aug 30 21:20:19 CEST 2005
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
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?
On Tue, 30 Aug 2005, Alan DeKok wrote:
> Joe H <jharlan at 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
More information about the Freeradius-Users