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

[Heikki Vatiainen]

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