Thread: question about SSIS
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?
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
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
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
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
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: > 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 > >
"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