Re: [Courier-imap] patch to dynamically modifying LDAP_FILTER on ip-basis and other stuff

[Brian C. <B.C...@po...>]

On Sun, Jul 02, 2006 at 11:17:36AM +0200, Tony Earnshaw wrote:
> I call a failover server a physical server in sync with a master that 
> will automatically take over from the master if the master should fail 
> in any sense, physically or programmatically. Clustered servers would be 
> an example.

OK - so presumably it also takes over the master's IP address. In that case
it's completely transparent to the client. Right? Whereas "fallback" is up
to the client to contact explicitly if it fails to talk to the master?

> >According to the courier-authlib docs, with LDAP_URI this should still 
> >work,
> >except you have to separate the URIs with commas. Does it not? Perhaps you
> >could detail what behaviour you have observed, and how this differs from 
> >the
> >behaviour you would like to see?
> 
> I didn't know this, I can't find it in the authlib LDAP-relevant docs; 
> I'm at home today with only one test server, so I can't try it in 
> practice. But adding a second LDAP listener wit a comma delimiter in 
> authldaprc doesn't at least cause it to barf (LDAP_URI 
> ldapi://%2fvar%2frun%2fslapd%2fldapi/, ldap://tru.leerlingen). I'll try 
> it out in practice on the Courier server when I'm at work again.

By "docs" I actually meant just the comments and example in authldaprc:

##NAME: LOCATION:1
#
# Location of your LDAP server(s). If you have multiple LDAP servers,
# you can list them separated by commas and spaces, and they will be tried in
# turn.
#

LDAP_URI                ldaps://ldap.example.com, ldaps://backup.example.com

It's worth a try. You probably want to set the timeout pretty low (say 5
seconds). However, since authldap is 'sticky', that is, it holds open a
persistent connection to the back-end server, then even if the first few
authentications fail while authldap is trying to connect to the master, once
it has successfully connected to the backup everything should run nicely
from then onwards.

> >>It has to support
> >>multiple lookup fields (not just two as authlib does).
> >
> >That comment I don't understand at all; nor do I understand the earlier
> >comment about "dual (as opposed to multiple) filters per record"
> 
> For example 
> ((uid=%u)(&(accountstatus=active)(objectClass=inetMailRecipient)))

OK. I believe what you've written there is not syntactically correct LDAP
filter, but
(&(uid=%u)(accountstatus=active)(objectClass=inetMailRecipient))
would be valid (if %u is substituted with the username, of course), as would
(&(uid=%u)(&(accountstatus=active)(objectClass=inetMailRecipient)))

The first is an AND with three operands; the second is an AND with two
operands, the second of which is an AND with two operands.

> >A filter is a filter. If you want to filter on multiple conditions, you can
> >use '|(..)(..)'. Are you saying you want to search with filter 1, and if
> >that search returns zero entries, try again with filter 2?
> 
> I want to AND, not OR. authldap barfs if I try 
> &(accountstatus=active)(objectClass=inetMailRecipient). By "barfs" I 
> mean I get the dreaded "OPERATION NOT PERMITTED" response.

Hmm. Well let's be more precise. I am guessing what you mean is you are
setting

LDAP_FILTER	&(accountstatus=active)(objectClass=inetMailRecipient)

Is that correct? Now, I believe the filter constructed by Courier will be

(&LDAP_FILTER(mail=%u))
giving
(&&(accountstatus=active)(objectClass=inetMailRecipient)(mail=%u))

which is invalid. However if you add an extra level of parentheses, i.e.

LDAP_FILTER	(&(accountstatus=active)(objectClass=inetMailRecipient))

then it should work, as you should get

(&(&(accountstatus=active)(objectClass=inetMailRecipient))(mail=%u))

Now, IIRC, the filter specification sent over the LDAP protocol is actually
ASN.1 encoded; this means it's up to the *client* library to fully parse the
filter string and turn it into ASN.1. In turn, this means that if you
provide an invalid filter string, the client will barf and not even send
anything to the server.

I'm guessing this is what the 'operation not permitted' error is reporting.
(However, does authldap log the filter string it has built, before trying to
send it to the server? If not, it would be a good thing for it to do)

If the last LDAP_FILTER above doesn't work for you, then we'll need to debug
further.

If this does work: well perhaps it would be easier if courier-authlib added
the extra parentheses for you, or the documentation should make it clearer
that your own subexpression needs to be enclosed in parentheses, but the
code is fine.

> >"Multiple lookup fields (not just two)" doesn't mean anything to me either.
> 
> s/field/attribute'. In which objectClass is also counted as an attribute.

OK, so you just mean that you want to be able to construct a filter which
matches on multiple attributes. Hopefully the above will work for you.

Regards,

Brian.