On Tue, May 28, 2024 at 5:11 AM Jon Gerdes <[email protected]> wrote:

> Dear all
>
> I am trying out various authentication mechanisms on a test box. TOTP
> was a doddle to set up with LDAP to an Active Directory LDAP source. I
> then moved on to RADIUS as a second factor.  I am using PrivacyIDEA to
> drive a FreeRADIUS with which I can use radclient to authenticate
> successfully. I am using a push token, so an app on my phone gets
> pinged to allow or deny an attempt to login.
>
> I am running 1.5.5 and my extensions directory currently has .jars for
> jdbc-postgresql, auth-ldap and auth-radius (and one for branding, that
> fiddles with the login CSS)
>
> If I get my username and AD password correct I get logged in,
> regardless of RADIUS.  If I get my username correct but put rubbish in
> for my password and get RADIUS right, then I get logged in.  So it
> seems I have managed to get myself in a situation where I have two
> forms of auth instead of multi factor auth.
>
> I have just verified this, twice:
>
> Wrong username and wrong password - no access
> Correct username + correct LDAP password causes a prompt on phone ...
> ignore it and I get logged in
> Correct username  + wrong LDAP password, causes a prompt on phone ...
> accept prompt and I get logged in
>
> There doesn't seem to be much logging from the RADIUS extension which
> makes it hard to debug.  I get that there is a license incompatibility
> for the RADIUS plugin - Apache vs GPL.  I have no idea if that is a
> factor.
>
>
No, this is not a factor - just a warning, since Apache and GPL licenses
are incompatible - not from a technical perspective, from a legal
perspective, and the jRADIUS library that is used for RADIUS support is
licensed under a GPL license.

Logging can be bumped up by configuring the logback.xml file:

https://guacamole.apache.org/doc/gug/configuring-guacamole.html#logging-within-the-web-application


> I have set this in guacamole.properties:
>
> extension-priority: branding, radius, postgresql, ldap, *
>
> So my end goal is to fire up the Guacamole login page, enter my AD
> username and password and then get pinged by the app and press the
> accept button.  If any part of that workflow fails, then the session
> should fail.
>
>
The issue you're seeing is because the default behavior for authentication
extensions within Guacamole is that each extension provides an absolute
answer about whether or not a user is allowed to log on - but, also, it's
designed to "stack" the modules such that a user who logs in from one
module (LDAP) can access data stored in another module (JDBC). So, what's
happening in your case, when you log in with your correct LDAP username and
password, is that the LDAP module returns a success, which means that your
user *will* be logged in. Other modules may be tried, as well, which is why
you get the ping on your phone from the RADIUS module, but ultimately the
LDAP extension has succeeded, and so the user will be logged in.

Similarly, when you enter an incorrect LDAP username and password, the LDAP
login fails, BUT the RADIUS module is also tried, so you get the ping on
your phone, you accept the logon, and it succeeds - the authentication from
the RADIUS module succeeds, therefore the login will be successful, even
though LDAP has failed.

The exceptions to this are the extensions which are specifically designed
to be add-ons to other extensions - from an authentication perspective, the
Duo and TOTP modules fall into this category - they are designed to trigger
requirements for additional authentication, so if you are loading the LDAP
and Duo module, you would have to successfully authenticate to BOTH of
those modules.

If you think about it in Boolean logic, most of the authentication modules
are ORd together - you can authenticate to LDAP or RADIUS or JDBC. What you
need is some sort of way to require that the modules are ANDd together -
specifically you're looking for LDAP and RADIUS to succeed for a successful
login, and, for those particular modules, such a configuration does not
exist in Guacamole today.

Perhaps the easiest way for you to resolve this would be to get your RADIUS
authentication to the point where it is doing *all* of the authentication -
the username and password, and then the second factor. I am not familiar
with PrivacyIDEA, but when I wrote the RADIUS module I was using FreeRADIUS
with LinOTP to do multi-factor RADIUS authentication, and the configuration
I had for FreeRADIUS was that it would perform the LDAP authentication,
first, and then trigger the OTP requirements from LinOTP. If you can get
your RADIUS configuration to that point, you can remove the LDAP
authentication extension from Guacamole and only have the RADIUS extension.

If that's not possible for some reason or another, then the only solution
is to make some changes to the Guacamole code - either a way to specify
that more than extension is required for a successful login, or a way to
specify that a particular module (RADIUS) should be used as a second factor
for another module (LDAP), similar to how TOTP and Duo work.

One other word about the RADIUS module - I'm not sure how much longer we'll
be able to keep that extension alive. In addition to license challenges,
the underlying jRADIUS library that we use for the RADIUS client hasn't
been updated in many, many years (approaching 10 years, now, I think).
That's okay since RADIUS hasn't changed much in that time; however, jRADIUS
is one of the only, and certainly the most complete, Java RADIUS library
out there, As we update Guacamole and move on to newer versions of Java, at
some point we're going to lose the ability to use jRADIUS altogether, and
there doesn't seem to be anything to replace it at the moment. SSO
solutions have largely supplanted RADIUS these days. I say all that to
caution that my prognosis for RADIUS support in future versions of
Guacamole, more than a couple of years out, is pretty pessimistic at the
moment.

-Nick

Reply via email to