Proposed Patch - LDAPS support for servers on port 636 w/o TLS
От | stephen layland |
---|---|
Тема | Proposed Patch - LDAPS support for servers on port 636 w/o TLS |
Дата | |
Msg-id | 20080426010240.GS5734@68k.org обсуждение исходный текст |
Ответы |
Re: Proposed Patch - LDAPS support for servers on port 636 w/o TLS
("Brendan Jurd" <direvus@gmail.com>)
Re: Proposed Patch - LDAPS support for servers on port 636 w/o TLS (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hey Postgres Hackers, this is my first time here, so... hi! I've written a quick patch against the head branch (8.4DEV, but it also works with 8.1.3 sources) to fix LDAP authentication support to work with LDAPS servers that do not need start TLS. I'd be interested to hear your opinions on this. Quick overview: The OpenLDAP recommended LDAPS configuration (as of OpenLDAP2.4?) is to have a regular (unencrypted) LDAP server listeningonstandard port 389. Encryption will begin when the clientissues a STARTTLS request ala SMTPS. Some older LDAP servers may not support TLS and instead have theSSL enabled ldap server listening on the ldaps port (usually636). While I agree it's probably not worth it to support older'unrecommended' setups, many organizations are slow on theuptakeof recommended practices (mine is one of them :) ). Allowing PostgreSQL to work with these organization's setupsoutof the box helps us pitch the db to organizations easier,especially those possibly overly paranoid about security. My solution was to create a boolean config variable calledldap_use_start_tls which the user can toggle whether or notstarttls is necessary. The default is to use start tls and the recommended configuration. I also updated the documentationandcleaned up the prefix/suffix/basedn interface so it's a bitmore intuitive to the user (i.e. - the basednsetting isactually used, what they do are explained in the docs, etc.)Some people actually found that using an authuri of: ldaps://ldap.example.org/junk;cn=;,dc=example,dc=com worked. I think a more intuitive form would be: ldaps://ldap.example.org/dc=example,dc=com;cn= though this can be debated. If any of you are interested in this, feel free to check out the patch located here: http://rockpunk.org/ldaps-postgres_8.4DEV.patchhttp://rockpunk.org/ldaps-postgres_8.4DEV.patch.asc Please note that this patch does not implement ldaps for Albe Laurenz' code that allows config to pull from LDAP via pg_service.conf, though it should be easy to do. I have tested this patch on the following configurations: Client OS: RHEL4 Database:Postgres 8.1.3 sourcesPostgres 8.4DEV (cvs HEAD branch as of Apr 24) libldap client:OpenLDAP version 2.2.12 (latest for RHEL4 subscriptions)OpenLDAP version 2.3.39 (stable) libldap server:OpenLDAP slapd version 2.2.x? on CentOS 4 or 5. (<-- no access) Thanks a bunch, -Steve (rockpunk @ #postgresql) -- *------------------------* // ste\/e || 0x158f7a45 // *------------------------* live now. die later.
В списке pgsql-hackers по дате отправления: