[Date Prev][Date Next]
On Tue, 29 May 2007 14:25:32 -0700
Quanah Gibson-Mount <email@example.com> wrote:
> I'm working on a patch to add LDAP SASL support to Postfix 2.4 (I made one
> for 2.2/2.3 a long time ago), and this time I want it to be accepted
> upstream, so I'm working on what they feel the issues are.
> Right now, they
> (a) always want LDAP_SASL_QUIET enabled (makes perfect sense to me)
> (b) want the SASL mechanism to be a list of mechanisms the client supports,
> that should be tried when connecting to the server.
> I think (b) is rather non-sensical, given the configurations are rather
> different between things like DIGEST-MD5, EXTERNAL, and GSSAPI just to
> start, but...
> I assume to support this I should use the ldap_sasl_interactive_bind_s
> function, which takes as a parameter a list of mechanisms, if I'm reading
> it right. The question to me comes up with mixing LDAP_SASL_QUIET in,
> because part of the routine involved with multiple mechansisms seems to
> want interaction with the client.
> My assumption is that if I use ldap_sasl_interactive_bind_s, with
> LDAP_SASL_QUIET, and pass in a list of mechanisms, the client will just use
> the first mechanism in its list. Is that correct?
I don't know about ldap_sasl_interactive_bind_s but we use
ldap_sasl_bind_s with GSSAPI tokens directly and it's worked very well
for us. You'll need an RFC 2222 routine to walk through the wrapping and
unwrapping during bind but it's not too bad and cuts out a lot of mystery.
We also use a custom Sockbuf_IO handler installed with ber_sockbuf_ctrl
to do the wrapping/unwrapping but I think we did that just to eliminate
the cyrus dependency.
Anyway, if you're interested I can give you a more detailed outline.
Michael B Allen
PHP Active Directory Kerberos SSO