Search Postgresql Archives

Re: Linux Postgres authentication against active directory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > Actually I try to authenticate my Linux Postgres installation 
> > > against Active Directory, I find 3 solution to use:
> > > 
> > > 1) LDAP
> > > 2) Pam and Kerberos
> > > 3) Kerberos alone
> > 
> > (3) is the one I've been using, and it works very well. I've been 
> > working on a HOWTO, but it' snot done yet.
> > 
> > Note that if your clients are on win32, you need at least version 
> > 8.0.2.
> 
> Great to know that someone are able to use this solution, I 
> don't have any client my application is a web (php, java) 
> application with a request for AD (or ldap depend on the 
> customer) users authentication.

The easiest way around that is to authenticate the user to the
webserver, and then use a single account to connect to the database (or
a couple, depending on group membership, or whatever suits your app). 


> > Naturally you will have to recreate the service account in 
> AD with the 
> > proper SPN.
> 
> My fear is that I have misunderstood how kerberes work, I 
> understand that I must to kerberize the postgres application 
> to give it the access to AD, then I need to put a principal 
> to any user that need to authenticate?

No, you do not need to kerberize postgres to access AD. If you want to
"check ad passwords", it's porbably best to use LDAP.

Kerberos is used to achieve *single sign on*. Meaning your app never
sees the password. If this is not what you need, it's overly complex.

Any user who needs to authenticate needs a principal, yes. That's their
normal Windows account. On top of that, every *service* the user should
authenticate *to* also needs a principal - for mutual authentication.

If your client connects to your wbserver only, your webserver needs this
principal. If the clients connects to the database server, the database
server needs it. There is apparantly some way if you use mod_perl to
forward kerberos credentials from the webserver to the database server,
but I don't know any details about that.

But again, if you intend to provide a userid/password box to the user
and then authenticate those credentials, it's going to be a lot easier
to use for example LDAP.

You can, of course, use kerberos between your webserver and the database
server, but that's most likely an overkill as you'll only be able to
access it as a single user anyway (I think).


> This is my principal on the linux box, as you say (I think) I 
> create this principal in uppercase:
> 
> 	ktutil:  rkt /usr/etc/postgresql/krb5.keytab
> 	ktutil:  list
> 	slot KVNO Principal
> 	---- ----
> ---------------------------------------------------------------------
> 	   1    3             POSTGRES/onet003@xxxxxxxxxxx
> 	   2    3             RONZANID/onet003@xxxxxxxxxxx

The postgres keytab only needs the POSTGRES principal. The other is your
user (I assume), and it sohuld not be stored *anywhere* - only
transitent whlie you are logged in.


> May be my problem was related with this compilation line?
> 
> 	checking for library containing com_err... -lkrb5
> 	checking for library containing krb5_encrypt... none required
> 	checking for library containing krb5_sendauth... none required
> 	checking krb5.h usability... yes
> 	checking krb5.h presence... yes
> 	checking for krb5.h... yes
> 	checking for krb5_ticket.enc_part2... yes
> 	checking for krb5_error.text.data... yes
> 
> Particularly I refer to krb5_encrypt and krb5_sendauth.

No, that looks correct. It jus tmeans that they were found in the krb5
library, and no *additional* libraries are needed. If you were missing
the rquired libs, you'd get an error and not just a notice.


> With more debug I received this error when I try to authenticate.
> 
> 	postgres: Bad application version was sent (via 
> sendauth) from krb5_recvauth

That probably indicates that your server has a different principal name
than the client (libpq library).


//Magnus

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux