Logging the return code from the ldap authentication to SQL.

[Augusto G. Andreollo]

Ok, updating on my progress:

On Mon, 2009-03-16 at 14:28 -0300, Augusto G. Andreollo wrote:
> 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.
> 
I must've been doing something wrong.. When I erased everything and
retyped it again, it's now returning OK as given.

My problem now is that it only returns correctly when the module returns
OK. If the LDAP returns anything else (fail, rejected, notfound), it
just completely skips over the IFs block and goes straight to Post-Auth.
Is that expected?

The config is as follows:
(on radiusd.conf):
redundant redundant_ldap {
        ldap-server1
        #ldap-server2
}

(on inner-tunnel):
    authenticate {
        Auth-Type LDAP {
            redundant_ldap

            if (fail) {
                update control {
                    reason = "fail"
                }
            }
            elsif (ok) {
                update control {
                    reason = "ok"
                }
            }
            elsif (notfound) {
                update control {
                    reason = "not found"
                }
            }
            elsif (rejected) {
                update control {
                    reason = "rejected"
                }
            }
            else {
                update control {
                    reason = "ERROR"
                }
            }
        }

        Auth-Type PAP {
            pap
        }
    }

    post-auth {
        Post-Auth-Type REJECT {
            reply_log
            redundant_sql
        }
        redundant_sql
        update reply {
            User-Name := "%{request:User-Name}"
        }
        reply_log
    }


On a good user:
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful    <<<< user authenticated ok
[ldap-malibu] user user at university.com authenticated succesfully 
+++[ldap-malibu] returns ok
++- group redundant_ldap returns ok
++? if (fail)
? Evaluating (fail) -> FALSE   <<<< skip "fail"
++? if (fail) -> FALSE
++? elsif (ok)
? Evaluating (ok) -> TRUE      <<<< match "ok"
++? elsif (ok) -> TRUE
++- entering elsif (ok) {...}
+++[control] returns ok
++- elsif (ok) returns ok
++ ... 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 {...}
++- entering group redundant_sql {...}
And then it goes on to insert "ok" on the database.

Now, on a bad user (wrong pass):
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind failed with invalid credentials  <<<< wrong pass
+++[ldap-malibu] returns reject
++- group redundant_ldap returns reject <<<< the group returned a status
Failed to authenticate the user.
} # server unicamp.br-inner-tunnel
Using Post-Auth-Type Reject             <<<<< skips right thru the IFs
+- entering group REJECT {...}
[reply_log] 	expand: /var/log/radius/radacct/%Y%m%d/%H-reply-detail
-> /var/log/radius/radacct/20090316/12-reply-detail
[reply_log] /var/log/radius/radacct/%Y%m%d/%H-reply-detail expands
to /var/log/radius/radacct/20090316/12-reply-detail
[reply_log] 	expand: %t -> Mon Mar 16 12:26:37 2009
++[reply_log] returns ok
++- entering group redundant_sql {...} 
And then it inserts the value on the database as "empty", or simply, ''.

Pretty much the same happens on an inexistent user. The messages are
different, but the result is the exact same.

>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?

>From what I've gathered, the virtual module is returning the status from
the inner ldap modules, so I believe my last question is irrelevant.

Thanks in advance for any suggestion.

-- 
Augusto G. Andreollo
CCUEC/DCNET/SREDE
Universidade Estadual de Campinas - UNICAMP
+55 19 3521-2276
    --  "Wit beyond measure is men's greatest treasure."