On Mon, 2009-03-16 at 16:13 +0100, Alan DeKok wrote: > Augusto G. Andreollo wrote: > > > > My problem now is getting the return code into the variable, according > > to the LDAP module results. > > It looks like it's working. What's the problem? > > > (and then it goes on to successfuly add the string "rejected" to the > > database. Again, that part is working smoothly). > > So... what's the problem?
The problem is that the "reason" code is wrong, because the IF is matching with "rejected", when it should match "ok", since the bind completed succesfully. rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful <<<< User authenticated OK [ldap1] user u...@university authenticated succesfully +++[ldap1] returns ok ++- policy redundant returns ok ++? if (rejected) ? Evaluating (rejected) -> TRUE <<<< should not match ++? if (rejected) -> TRUE ++- entering if (rejected) {...} +++[control] returns ok ++- if (rejected) returns ok ++ ... skipping elsif for request 0: Preceding "if" was taken ++ ... skipping elsif for request 0: Preceding "if" was taken ++ ... skipping elsif for request 0: Preceding "if" was taken ++ ... skipping else for request 0: Preceding "if" was taken +- entering group post-auth {...} on the database, "reason" should be: - "ok" when request completed ok - "rejected" when the password is wrong - "not found" when the user does not exist on LDAP - "fail" when the module fails for some reason (not reacheable, server down, whatever wrong like that) - "ERROR" otherwise. This is necessary for user support... When user x...@domain.com calls asking why his internet access is being denied, we'd like to know exactly why that happened, so that the User Support people only need to escalate the real problems, not "your password is wrong" problems.. > > Use the first method, not the second. Ok, I've already scraped the first one. My problem is getting the rcode into the variable "reason", defined as ATTRIBUTE reason 3201 string Alan (the other one), proposed: >> if (rejected) { > >are you sure such a return code is available and >comparable in such a way? looks like 'rejected' >got matched...possibly because the check went okay - >a value of 0 - rejected isnt defined...has a value of >0 too? just a guess! I believe this to be the problem, because even when I shuffle around with the order of the IFs, it's always the "rejected" one which matches. Does the "redundant" module passes forward the inner "ldap" module return codes? And again, should it? > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Augusto G. Andreollo CCUEC/DCNET/SREDE Universidade Estadual de Campinas - UNICAMP +55 19 3521-2276 -- "Wit beyond measure is men's greatest treasure." - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html