Thanks again, and I must again apologize for the confusion.
Yes, that shell script was in goodies, but it was written by my developer, so
blame it on a communication error :-) I wasn't clear on which plumbing came
stock, and which he had to build. I see that SQLTOTP handles everything but
provisioning, and he wrote this to handle the provisioning.
So I actually refactored the whole config the way Martin advised: I use
NAS-IP-Address selectors in the <Handler> clauses matched with a SearchFilter.
No need for a custom hook, which also means no conflict with that shell script
hook. More streamlined, and appears to be working correctly so far!
I'd like to add a debug line in:
> PostSearchHook sub { my @hash = $_[4]->get('pager'); \
> my @username = $_[4]->get('sAMAccountName'); \
>
> system('/opt/radiator/radiator/goodies/inserttotp.sh',@username,@hash); \
> return 1 ;}
but the syntax eludes me. I tried:
main::log($main::LOG_DEBUG, "PostSearchHook: perform upsert to
provision user", $p);\
and also
$_[0]->log($main::LOG_DEBUG, "PostSearchHook: perform upsert to
provision user", $p);\
but neither works.
Thanks again in advance! I appreciate the help!
Dave
-----Original Message-----
From: Heikki Vatiainen <[email protected]>
Sent: Tuesday, February 22, 2022 9:11 AM
To: Dave Kitabjian <[email protected]>; [email protected]
Subject: Re: [RADIATOR] Radiator / LDAP / matching on multi-valued field
On 22.2.2022 0.21, Dave Kitabjian wrote:
> Thanks again so much for the reply. Per your one suggestion, I'm considering
> embedding that other hook code at the end (see the 3 lines right before
> "return" of the below snippet).
>
> I also stuck a "return;" right after:
>
> $user->get_check->add_attr('Auth-Type', "Reject:No authorisation group
> found in LDAP for '$dn'");
>
> per your comment: "In this branch you could return directly and let the rest
> of the cases (success cases) exit via insertotp call." In other words, bypass
> the insert when they fail.
That should quickly trigger REJECT from the AuthBy when the check items
are evaluated.
> Based on the comments:
>
> # Replay atack detection is not specified in RFC 6238. Nevertheless
> # AuthSQLTOTP implements replay attack detection by recording the TOTP
> # timestep of the last valid authentication. It will not authenticate
> # a TOTP with the same or earlier timestep as the last recorded
> # timestep.
>
> I'm guessing this inserttotp.sh entry is the one that prevents replay
> attacks? And that we should therefore not execute this when the user fails
> login? If so, then my code changes look good, right?
The failure logic is within AuthBy SQLTOTP. When you look at the SQL
clauses it runs, part of the stored information is the timestamp. In
other words, apart from the token provisioning, AuthBY SQLTOTP contains
all the logic it needs.
Based on the name, I thought inserttotp.sh might set up TOTP parameters
for the user automatically with the first login attempt.
Since inserttotp.sh does not come with Radiator, there's not much more I
can say about what it does.
I recommend storing it in /etc/radiator/ (or in general, the directory
with Radiator config) to make it clear that it doesn't come with the
distribution.
> Then the only question that comes to mind is, your original:
>
> PostSearchHook sub { my @hash = $_[4]->get('pager'); \
> my @username = $_[4]->get('sAMAccountName'); \
>
> system('/opt/radiator/radiator/goodies/inserttotp.sh',@username,@hash); \
> return 1 ;}
>
> that was embedded in the totp.cfg... in that old setup (which I'm not using,
> but humor me, since I'm trying to understand how this works) the insert was
> taking place without checking the outcome of the pass/fail, right?
Yes, I think it run every time when LDAP was queried. With the snippet
below it only runs when authorisation finds a match and doesn't trigger
reject.
Also to clarify its origins: I don't think it comes, or ever has been,
part of our totp.cfg in goodies. Based on the name and its use of LDAP,
I'd think it could be part of your local token provisioning.
> if ( ($nas_ip eq 'X.X.X.X' || $nas_ip eq 'Y.Y.Y.Y') &&
> (List::Util::first { $admin_dn eq $_ } @ldapgroups))
> {
> main::log($main::LOG_DEBUG, "PostSearchHook: matched LDAP group
> '$admin_dn'", $p);
> $user->get_reply->add_attr('Reply-Message', 'You are admin');
> }
> elsif ($nas_ip eq 'Y.Y.Y.Y' &&
> (List::Util::first { $regular_dn eq $_ } @ldapgroups))
> {
> main::log($main::LOG_DEBUG, "PostSearchHook: matched LDAP group
> '$regular_dn'", $p);
> $user->get_reply->add_attr('Reply-Message', 'You are regular');
> }
> else
> {
> # Could also use add_attr to assing a default
> # authorization level.
> $user->get_check->add_attr('Auth-Type', "Reject:No authorisation
> group found in LDAP for '$dn'");
> return;
> }
>
> my @hash = $entry->get('hash');
> my @username = $entry->get('sAMAccountName');
> system('/etc/radiator/inserttotp.sh',@username,@hash);
>
> return;
> }
Thanks,
Heikki
--
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software
CONFIDENTIALITY NOTICE***The information contained in this message may be
privileged, confidential, and protected from disclosure. If the reader of this
message is not the intended recipient, or any employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution, or copying of this communication is strictly
prohibited. If you have received this communication in error, please notify us
immediately by replying to the message and deleting it from your computer.
Thank you.
_______________________________________________
radiator mailing list
[email protected]
https://lists.open.com.au/mailman/listinfo/radiator
