question about SSIS

Started by Konstantin Izmailovalmost 17 years ago7 messagesgeneral
Jump to latest
#1Konstantin Izmailov
kizmailov@gmail.com

I've asked a few people at pgcon2009 about the issue of connecting users
differently: some in SSIS mode, some - with password. This is still an
issue: if server is configured for SSIS, there is no way to connect with
password. It appears that the solution of the issue is to introduce
connection string parameter, e.g. "integrated_security=ssis", so client has
control on how to login to server. Any thoughts?

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Konstantin Izmailov (#1)
Re: question about SSIS

Konstantin Izmailov <kizmailov@gmail.com> writes:

I've asked a few people at pgcon2009 about the issue of connecting users
differently: some in SSIS mode, some - with password. This is still an
issue: if server is configured for SSIS, there is no way to connect with
password.

Huh? The server decides which auth method to use, not the client.

regards, tom lane

#3Magnus Hagander
magnus@hagander.net
In reply to: Tom Lane (#2)
Re: question about SSIS

Tom Lane wrote:

Konstantin Izmailov <kizmailov@gmail.com> writes:

I've asked a few people at pgcon2009 about the issue of connecting users
differently: some in SSIS mode, some - with password. This is still an
issue: if server is configured for SSIS, there is no way to connect with
password.

Huh? The server decides which auth method to use, not the client.

I think this is exactly what Konstantin is complaining about.

In his scenario, different clients connecting from the same subnet (so
they can't use different pg_hba lines) need to use different
authentication methods. (IIRC, this is an environment coming from
Microsoft SQL Server which does support this)

I think what he's asking for is the ability for a line in the server to
allow multiple authentication methods, and then for the client to be
able to specify which one of these it uses.

Konstantin, can you confirm that this was your scenario? You explained
it to me last night, but that was several beers into the evening...

//Magnus

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Magnus Hagander (#3)
Re: question about SSIS

Magnus Hagander <magnus@hagander.net> writes:

In his scenario, different clients connecting from the same subnet (so
they can't use different pg_hba lines) need to use different
authentication methods. (IIRC, this is an environment coming from
Microsoft SQL Server which does support this)

Perhaps he could use the user name or database name to distinguish
them in pg_hba.conf?

I think what he's asking for is the ability for a line in the server to
allow multiple authentication methods, and then for the client to be
able to specify which one of these it uses.

There's no way we could implement that without a protocol change,
and it doesn't seem worth it to me. The idea that the client gets
to choose seems like a bad idea from a security standpoint anyhow...

regards, tom lane

#5Joshua D. Drake
jd@commandprompt.com
In reply to: Tom Lane (#4)
Re: question about SSIS

On Fri, 2009-05-22 at 15:24 -0400, Tom Lane wrote:

I think what he's asking for is the ability for a line in the server to
allow multiple authentication methods, and then for the client to be
able to specify which one of these it uses.

There's no way we could implement that without a protocol change,
and it doesn't seem worth it to me. The idea that the client gets
to choose seems like a bad idea from a security standpoint anyhow...

Wouldn't this be solved just by having fall through authentication?

Sincerely,

Joshua D. Drake
--
PostgreSQL - XMPP: jdrake@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

#6Konstantin Izmailov
kizmailov@gmail.com
In reply to: Magnus Hagander (#3)
Re: question about SSIS

Yes, it is correct. Issue appers not significant at first glance.
However, if you take into account users who are trying to migrate
their apps from MSSQL or Oracle and not willing to rewrite their apps
(relying on the OLEDB driver), you discover that it is not that small
issue. The driver just cannot provide required modes due to DB
limitation.

On May 22, 2009, at 3:18 PM, Magnus Hagander <magnus@hagander.net>
wrote:

Show quoted text

Tom Lane wrote:

Konstantin Izmailov <kizmailov@gmail.com> writes:

I've asked a few people at pgcon2009 about the issue of connecting
users
differently: some in SSIS mode, some - with password. This is
still an
issue: if server is configured for SSIS, there is no way to
connect with
password.

Huh? The server decides which auth method to use, not the client.

I think this is exactly what Konstantin is complaining about.

In his scenario, different clients connecting from the same subnet (so
they can't use different pg_hba lines) need to use different
authentication methods. (IIRC, this is an environment coming from
Microsoft SQL Server which does support this)

I think what he's asking for is the ability for a line in the server
to
allow multiple authentication methods, and then for the client to be
able to specify which one of these it uses.

Konstantin, can you confirm that this was your scenario? You explained
it to me last night, but that was several beers into the evening...

//Magnus

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Joshua D. Drake (#5)
Re: question about SSIS

"Joshua D. Drake" <jd@commandprompt.com> writes:

On Fri, 2009-05-22 at 15:24 -0400, Tom Lane wrote:

There's no way we could implement that without a protocol change,
and it doesn't seem worth it to me. The idea that the client gets
to choose seems like a bad idea from a security standpoint anyhow...

Wouldn't this be solved just by having fall through authentication?

It's still a protocol change --- right now, clients have no reason
to expect that failing on the first auth challenge will lead to
another challenge of a different type, or indeed lead to anything
at all except disconnection. I think libpq, for example, just drops
the connection on its own authority if asked for a password it can't
provide.

regards, tom lane