[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd-{ldap,meta} && authentication

>> Pierangelo Masarati wrote:
>>>>This works exactly as planed when slapd is using a 'bdb' backend, but
>>>>not 'ldap' (or 'meta' for that matter).
>>>>What am I missing? Note that I don't want _ANY_ rewriting
>>>>or anything. The 'meta' slapd should match exactly the master...
>>>>I'll be trying 'overlay' later to have the cache 'on file', but
>>>>currently that gives me errors, so I'll stick to one problem at
>>>>the time...
>>>>I've been trying to check the mail archives but that doesn't
>>>>show me ANYTHING that have to do with _authentication_, only
>>> Exactly.  You cannot perform SASL bind with back-ldap.  You're supposed
>>> to
>>> use simple auth.  If you use HEAD code, you can have the proxy bind
>>> with
>>> SASL to the remote server, and eventually proxyAuthz your local
>>> identity
>>> (see idassert-* in HEAD's slapd-ldap(5)).  Note that proxying SASL auth
>>> might be impossible, and at least mechanism dependent (as far as I
>>> understand of SASL).
>> This is not completely true. back-ldap does support sasl-regexp mapping,
>> or it did the last time I worked with it. It will not be able to proxy
>> any credentials, true. But for mechs like EXTERNAL and GSSAPI that is
>> not necessary and this setup *should* work, and has worked for me in the
>> past. If it does not now, this is a bug that should be filed in ITS.
>> I note the original poster is using back-meta, and I have never tested
>> sasl-regexp with back-meta. It very well may never have worked. But
>> certainly back-ldap did.
> I only tried with back-ldap with mechs containing the credentials
> (MD5, essentially), and they don't work, as expected.  That's what
> I was referring to when speaking about mech dependent.  I never
> tried with EXTERNAL or GSSAPI, so I can't speak about that.  I see
> that everything about authz-regexp should work with back-ldap
> (there's much about that in test028/test029) but the fact the
> original poster fails when regexping from authz internal DN form to
> actual user form seems to indicate that there's something SASL
> related in that conversion.  I think at this point he should try
> with back-ldap (even without proxy caching) and produce a full log
> of the authz-regexp portion.

I have to correct myself; SASL bind works like a charm with the idassert
stuff even with DIGEST-MD5; only, idassert-mode needs to be set to "none",
i.e. the proxy administrative identity must be used instead of asserting
that of the client's, because that identity must have read access to the
client's credentials stored in the remote DB.  This might not be what one
wants to do, though.

I have no idea of what's going to happen with GSSAPI or EXTERNAL.


Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497