Logging the return code from the ldap authentication to SQL.

[Augusto G. Andreollo]

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 user at 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 XYZ at 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."