Logging the return code from the ldap authentication to SQL.
Hello all. I have the need to log the return code from the LDAP authentication to our database (I'm adding it to the postauth table scheme). I've already modified the database scheme (ok), the attribute map, to create a new attribute called "reason" (ok) and the insert queries (ok). All of this is working fine, including the complete authentication, all the way thru Access-Accept and Accounting. My problem now is getting the return code into the variable, according to the LDAP module results. I've made two attempts so far, and neither gave me too much success: First, with a series of IFs and ELSIFs: authenticate { Auth-Type LDAP { redundant { ldap1 ldap2 } if (rejected) { update control { reason = "rejected" } } elsif (fail) { update control { reason = "fail" } } elsif (notfound) { update control { reason = "not found" } } elsif (ok) { update control { reason = "ok" } } else { update control { reason = "ERROR" } } } } Which gives: rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful [ldap1] user user@university authenticated succesfully +++[ldap1] returns ok ++- policy redundant returns ok ++? if (rejected) ? Evaluating (rejected) -> TRUE ++? 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 {...} (and then it goes on to successfuly add the string "rejected" to the database. Again, that part is working smoothly). My second attempt was with a switch statement, as follows: authenticate { Auth-Type LDAP { redundant { ldap1 ldap2 } switch "%{control:rcode}" { case ok { update control { reason = "ok" } } case rejected { update control { reason = "rejected" } } case notfound { update control { reason = "notfound" } } case fail { update control { reason = "fail" } } case { update control { reason = "ERROR" } } } } } Which gives me the following (Again, I've skipped what I believe to be unneeded): rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful [ldap1] user user@university.com authenticated succesfully +++[ldap1] returns ok ++- policy redundant returns ok expand: %{control:rcode} -> ++- entering switch %{control:rcode} {...} +++- entering case {...} ++++[control] returns ok +++- case returns ok ++- switch %{control:rcode} returns ok +- entering group post-auth {...} And then goes to successfully write "ERROR" the database. (to save room, i've already tried encasing the case options in quotes, as 'rejected', 'ok', etc.. that gives me the exact same results. So does putting it on double quotes, as "ok", "rejected", etc..) So, any ideas? btw: $ radiusd -v radiusd: FreeRADIUS Version 2.1.3, for host i386-portbld-freebsd7.0, built on Jan 9 2009 at 07:02:31 -- Augusto G. Andreollo CCUEC/DCNET/SREDE Universidade Estadual de Campinas - UNICAMP +55 19 3521-2276 -- "Wit beyond measure is men's greatest treasure."
Augusto G. Andreollo wrote:
I have the need to log the return code from the LDAP authentication to our database (I'm adding it to the postauth table scheme).
I wouldn't suggest doing that for EVERY packet. Why do you think it's necessary?
I've already modified the database scheme (ok), the attribute map, to create a new attribute called "reason" (ok) and the insert queries (ok). All of this is working fine, including the complete authentication, all the way thru Access-Accept and Accounting.
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?
My second attempt was with a switch statement, as follows:
authenticate { Auth-Type LDAP { redundant { ldap1 ldap2 }
switch "%{control:rcode}" {
Umm... there is no "control:rcode" attribute.
expand: %{control:rcode} -> ++- entering switch %{control:rcode} {...} +++- entering case {...}
See? No "control:rcode".
(to save room, i've already tried encasing the case options in quotes, as 'rejected', 'ok', etc.. that gives me the exact same results. So does putting it on double quotes, as "ok", "rejected", etc..)
So, any ideas?
Use the first method, not the second. Alan DeKok.
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@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@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."
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@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."
Augusto G. Andreollo wrote:
I must've been doing something wrong.. When I erased everything and retyped it again, it's now returning OK as given.
Weird... OK
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?
Yes. In normal processing, failure means STOP. Don't keep bugging other modules with a request that failed. Alan DeKok.
On Tue, 2009-03-17 at 10:11 +0100, Alan DeKok wrote:
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?
Yes.
In normal processing, failure means STOP. Don't keep bugging other modules with a request that failed.
Hmm.. thing is, the post-auth sql query is already being processed, to log the Access-Reject.. Is there any other way I could extract the rejection reason from the LDAP module, to add to this query? Thanks -- Augusto G. Andreollo CCUEC/DCNET/SREDE Universidade Estadual de Campinas - UNICAMP +55 19 3521-2276 -- "Wit beyond measure is men's greatest treasure."
Augusto G. Andreollo wrote:
Hmm.. thing is, the post-auth sql query is already being processed, to log the Access-Reject..
Yes.. I know. But the return code from the LDAP module in the *authorize* section is lost by then.
Is there any other way I could extract the rejection reason from the LDAP module, to add to this query?
It's not in the LDAP module. See src/main/modcall.c for the code that handles calling modules, and the return codes. If you really need this functionality, send a patch. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Augusto G. Andreollo wrote:
Hmm.. thing is, the post-auth sql query is already being processed, to log the Access-Reject..
Yes.. I know. But the return code from the LDAP module in the *authorize* section is lost by then.
Is there any other way I could extract the rejection reason from the LDAP module, to add to this query?
It's not in the LDAP module.
See src/main/modcall.c for the code that handles calling modules, and the return codes. If you really need this functionality, send a patch.
I did. It's bitrotting in your bug database; currently offline so obviously I cannot pull out a linky. It make xlat module failure aware, it's an intrusive patch but works for us and gives us LDAP failover support cleanly. Same goes for bug #544, to provide the ldap DN when needed[1]. :( If you look back in your personal INBOX (if you go back that far) to Sept 1st 2008 you will see this patch being referred to. All my patches live on my dumper space: http://stuff.digriz.org.uk/freeradius/ Cheers [1] it pains me this patch is not there, the LDAP maintainer seems AWOL and no one will touch it <insert grumble/> -- Alexander Clouter .sigmonster says: Marriage is the waste-paper basket of the emotions.
Hi,
if (rejected) {
are you sure sucha 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!
switch "%{control:rcode}" {
nice: but likewise, do you know the value of %{control:rcode} to act the case against? looks like it didnt match any of your triggers and so defaulted to ERROR. alan
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alexander Clouter -
Augusto G. Andreollo