Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1

Hi

On Mon, Jan 11, 2021 at 5:42 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

>
> Accessing systems outside of the Kerberized environment is obviously a
> different situation as you *can't* use the Kerberos credentials- and,
> hopefully, everyone is using password managers and has a distinct and
> different password for every service they do use outside of the
> Kerberized environment. When you're talking about a set of systems
> which live inside of the Kerberized environment, however, it's simply
> not sensible to ask the user to provide their *domain-level* credentials
> which an attacker could use to log in as that user to the entire domain
> and have complete access over their account and that's exactly what is
> likely to end up being the case here because the only way to set this up
> would be Kerberos for pgAdmin and LDAP for PG- at least until delegated
> credentials are implemented.
>

Which is no worse than the current situation - in fact it's arguably better
because there's one less system that isn't Kerberised.

Don't forget, you (as the system administrator) also have the choice of
whether or not to use Kerberos. If you're not happy to have the pgAdmin
authentication be kerberised whilst the database server access is not, then
don't enable Kerberos until phase 2 is complete.

>
> > You basically seem to be saying that once a user logs into something
> using
> > Kerberos, *everything* else they login to from there must also be done
> > using Kerberos - which clearly will not be the case in the vast majority
> of
> > deployments.
>
> Everything else they login to from there in the same Kerberized
> environment absolutely should be done using Kerberos delegated
> credentials. That's the point of Kerberos delegation. Are you modeling
> this approach based on some existing system which accepts Kerberos
> logins but then *doesn't* allow use of delegated credentials to log into
> other Kerberized systems from there? Surely SSH works great with
> delegated credentials, as does any website that uses mod_auth_kerb or
> mod_auth_gss, or IIS..
>
> I sure hope that the vast majority of deployments where pgAdmin is set
> up with Kerberos will be using Kerberos for logging into PG with
> delegated credentials, and further, that we will be *strongly*
> encouraging that as otherwise you might as well use LDAP auth for all of
> it and accept that any compromise of the web server or of PG will result
> in complete compromise of any user's account who accesses the system.
>

I suspect that may not be the case, or at least most people will be working
in mixed environments, e.g. Kerberos on their local network with
non-Kerberised RDS servers for example. This is certainly something I've
seen in the field many times.

>
> I don't understand all this push-back.
>

There are benefits for some users with phase one alone, so I don't see (and
still don't) a need to hold it back. It also potentially allows us to get
feedback on things that don't work as expected earlier, to minimise any
re-work that might be required. Don't forget that pgAdmin releases monthly
(except around EOY for obvious reasons), and incrementally releases and
adds features, unlike PostgreSQL.

>
> The intent is to do the 'phase 2', right? And it hopefully will happen
> in relatively short order, no? At least, I'd think it would make sense,
> while people have developer environments set up and working with
> Kerberos to go ahead and get that part done. All I'm saying is that the
> 'phase 1' part really shouldn't be independently released, or if it is,
> it should be *heavily* caveated that it is strongly discouraged for
> people to run it in an environment where pgadmin and PG are in the same
> Kerberized environment because it's not possible to set that up, with
> just phase 1 done, in a manner which would avoid the pgadmin and PG
> servers seeing the user's password.
>

Phase 2 is scheduled to be done immediately.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: http://www.enterprisedb.com