Re: Logging the return code from the ldap authentication to SQL.
Alan DeKok al...@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging the return code from the ldap authentication to SQL.
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging the return code from the ldap authentication to SQL.
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. smime.p7s Description: S/MIME cryptographic signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging the return code from the ldap authentication to SQL.
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging the return code from the ldap authentication to SQL.
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging the return code from the ldap authentication to SQL.
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging the return code from the ldap authentication to SQL.
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) - TRUEshould 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 3201string
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
Re: Logging the return code from the ldap authentication to SQL.
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 u...@university.com authenticated succesfully
+++[ldap-malibu] returns ok
++- group redundant_ldap returns ok
++? if (fail)
? Evaluating (fail) - FALSEskip 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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
