On 02/05/2013 02:58 PM, Scott Marlowe wrote:
Why are you using LDAP and passing passwords for access to insecure
systems?
We're trying not to. That's kind of my point. Now, I'd love to spend
another few days learning yet another auth mechanism (kerberos) but I
was trying to avoid it.
As it stands now, I followed a couple "step by step" things I found via
google, and all I get is this when trying to use kerberos:
psql: GSSAPI continuation error: Unspecified GSS failure. Minor code
may provide more information
GSSAPI continuation error: Server not found in Kerberos database
Not extremely useful.
Here's what I don't get... If I'm my own user, and I call "kinit", it
sets up my kerberos cache, having obtained it from our AD server.
Presumably, that means kerberos is a service that can forward requests
to another server (AD) if it gets a request that isn't in its local
cache. If it gets a response, that response is added to the local cache
for the next request. If not, I'm missing the benefit of kerberos.
IMO, telling PG to use gss/kerberos should be as simple as turning it
on, so whatever installed handling mechanism is consulted, ala PAM.
Clearly I'm missing something. I'm going to read some docs to figure out
the stack, but I've never seen this particular thing before.
If you can't trust the machines on the other end, no amount of
password mangling is going to help hide the passwords. You have to
move to some other form of authentication or use passwords you don't
care about.
Which was why until now, we've been using passwords that are only valid
in the database, and superusers can only connect via local accounts via
peer auth. And our prod systems *are* locked down much better than the
dev ones, but the dev ones are the concern. People are bound to play
loosey-goosey with the dev servers, and I don't want that to turn into
some ridiculous exploit.
It's obvious I should abandon LDAP. Fine. I tried PAM auth (which is
configured to forward to AD), and that works graet, but has the same
problem. If the user is presented with a PW prompt more than once in a
row, something has failed.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas@xxxxxxxxxxxxxxxx
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
