[RADIATOR] Radiator / LDAP / matching on multi-valued field

[Dave Kitabjian]

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', at username, at 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 <hvn at open.com.au>
Sent: Tuesday, February 22, 2022 9:11 AM
To: Dave Kitabjian <dave at corp.netcarrier.com>; radiator at lists.open.com.au
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', at username, at 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', at username, at 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.