Re: BUG #9337: SSPI/GSSAPI with mismatched user names
От | Brian Crowell |
---|---|
Тема | Re: BUG #9337: SSPI/GSSAPI with mismatched user names |
Дата | |
Msg-id | CAAQkdDrsovd6HWoUniSFBJEqdccM4nEJmWiOVRceDhO3a+_cmg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #9337: SSPI/GSSAPI with mismatched user names (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #9337: SSPI/GSSAPI with mismatched user names
|
Список | pgsql-bugs |
On Mon, Feb 24, 2014 at 6:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Um. I spoke imprecisely, I see. The objection to involving a Kerberos > server in determining the username is not solely about the cycles > involved; it's that it requires identifying a specific Kerberos server > to do it. Don't we lose multi-realm support if we have to know the > server's password in advance of examining pg_hba.conf? Not as far as I know. For GSSAPI, the server determines which password to use based on the ticket, which includes the server's principal name, and it looks it up in its own key file (PG's krb_server_keyfile option). (For SSPI, I don't think you can use multiple passwords; if coming from another domain, you'd need Active Directory's assistance to cross the domain correctly.) I also went back and checked, and the server does not have to contact a Kerberos server to authenticate the client or determine its user name. So long as the ticket is encrypted with the correct password (Postgres's password), Postgres can decrypt it and know who the client is and that they're really who they say they are. The picture on this page will help: http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fintroductiontokerberosauthentication.htm Steps 1 and 2 in that graph are the client authenticating to the KDC. Step 3 is the client telling the KDC it wants to talk to a Postgres server, and it gives Postgres's principal name (such as "POSTGRES/mymachine.realm.com@REALM.COM"). In step 4, the KDC returns a ticket encrypted with Postgres's password. In step 5, Postgres receives the client's ticket, and decrypts it with its own password. If it decrypts properly and checks out, Postgres knows it's legit, because only the KDC should know Postgres's password. Inside will be the user's name. > I looked at our docs again and notice that there is no authentication > server specification option for the GSSAPI auth method. I guess that > that information is buried within the "server key file" or someplace; > this goes beyond my knowledge of Kerberos internals I fear. I do see > that there isn't any visible specification of a server password either, > so even absent the multi-realm issue it's not clear to me that what > you propose is practical for code outside the Kerberos libraries. Yes, the password is in the key file. Since this request has turned out to be a little more complicated than I thought, I'd like to volunteer to research it further and maybe bring it along. It's not part of my job duties right now, so I'll have to come back and visit it later, but so far I don't see anything obvious that would make it unfeasible. The GSSAPI/Kerberos case looks the easiest. SSPI/Negotiate will be harder because that requires passing data back and forth; you couldn't finish in one packet. Interesting problem. --Brian
В списке pgsql-bugs по дате отправления:
Следующее
От: Patrick WegeДата:
Сообщение: Re: BUG #9308: The application failed to initialize properly