Greetings, * Dave Page (dp...@pgadmin.org) wrote: > On Mon, Jan 11, 2021 at 4:50 PM Stephen Frost <sfr...@snowman.net> wrote: > > If you're saying that, when Kerberos is enabled, users will never be > > prompted to provide a password because password-based auth has been > > disabled, then perhaps that's reasonable. I don't know how useful such > > a pgadmin setup would be, but at least it wouldn't be violating one of > > the core values that using Kerberos brings. > > > > If you're saying that this is just disabling password *saving*, then > > that implies that if someone actually wants to use pgadmin to, uh, log > > into a PostgreSQL server which is configured for md5 or SCRAM auth or > > LDAP based auth that the way that'll work is that pgadmin will prompt > > the user for a password, which the user will provide and which will > > then be sent from the client to the pgadmin system in the clear, and > > which pgadmin will turn around and use to log into PG with, right? > > Yes.
Alright, glad I wasn't completely misunderstanding something. > > It's the latter than I'm concerned with because it just wouldn't be > > appropriate for a Kerberized service which is set up to use Kerberos to > > then prompt the user for a password. > > Well you never answered my previous question about that. Why is it > appropriate for an FDW to do that, but not pgAdmin? Or for a user on a > kerberised machine to use a web browser to access a non-kerberised site? Or > frankly pretty much anything outside of a windows domain or kerberos > environment that a user inside the environment might want to use? Pretty sure I didn't say it was appropriate for an FDW to do that, it really isn't, but FDWs are also a side feature of the overall product, not a core component, and you have to be granted specific rights to be able to use an FDW. 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. > 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 don't understand all this push-back. 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. Thanks, Stephen
signature.asc
Description: PGP signature
