Re: [Courier-imap] Courier-imap LDAP shadowExpire attribute

[David W. <da...@dc...>]

Hi Brian & Tony,

Thanks for your help on this one. "LDAP_FILTER 
(|(shadowExpire=99999)(!(shadowExpire=*)))" works 100%.


Kindest regards
David Wilson
_______________________________
D c D a t a
Tel +27 33 342 7003
Fax +27 33 345 4155
Cell +27 82 4147413
http://www.dcdata.co.za
su...@dc...
Powered by Linux, driven by passion !
_______________________________

----- Original Message ----- 
From: "Brian Candler" <B.C...@po...>
To: "Tony Earnshaw" <to...@bi...>
Cc: "Courier list" <cou...@li...>
Sent: Monday, November 15, 2004 11:10 AM
Subject: Re: [Courier-imap] Courier-imap LDAP shadowExpire attribute


>> So thanks! "p dont think" (Paul of SquirrelMail fame) just slated me off
>> on the maildrop list for getting something wrong to do with Postfix (I
>> embrace Postfix, just as I embrace Openldap). My own opinion is, that
>> it's far better to voice one's ignorance and have one's peers correct
>> one than to shut up.
>
> Hope you didn't think I was slating you off - just putting you right :-)
>
> However, before I post something like "I have tested this" then I like to
> repeat the test, and have the session ready to paste in if necessary.
>
>> This is brilliant stuff. As far as I can see from my slapd log, the
>> LDAP_BINDDN bind is now getting cached for a limited time, which seems
>> to  speed up things enormously. I can't wait for it to become declared
>> stable, so's I dare install it on client sites.
>
> Do you mean LDAP_BINDDN or LDAP_AUTHBIND?
>
> authldap has for a long time held open the search connection if it can,
> except when there is a fatal error (see calls to 'authldapclose'); that's
> the one which is authenticated using LDAP_BINDDN.
>
> If you are using LDAP_AUTHBIND, then a bind is made on a second connection
> to validate the password. With LDAP V3, it *could* hold open the second
> connection and repeatedly bind on this. However, it doesn't do that yet, 
> not
> even in the latest snapshot.
>
> There was a change a while ago to make the default LDAP protocol version 3
> (see LDAP_PROTOCOL_VERSION 3 in the default authldaprc). I guess that 
> might
> change the behaviour of your ldap server somehow.
>
>> What I'd love more than anything is a DEBUG_LOGIN mode, including
>> passwords, whereby login attempts were logged to maillog without all the
>> extraneous shit that DEBUG_LOGIN=2 gives. I have an Internet site
>> (IMAPS/STARTTLS and SquirrelMail https) for which I'm very anxious to
>> report on dictionary login attempts (SquirrelMail's lock_down plugin -
>> for pam_tally-like lockouts - doesn't work well enough in practice).
>
> Remember that in the general case there may be no password available to 
> log
> (if the user is logging in with CRAM authentication). So the best you 
> could
> do is say "someone has tried to log into this account 1000 times today and
> failed", which is IMO a pretty fair way to detect brute force attempts.
>
> Now, at the moment courier-imap does not log the usernames for failed
> logins. I very much want to see that, because after migrating a bunch of
> users from one large server to another, it's the only way to establish
> whether there are particular users or groups of users who are having
> problems. I would think that would be sufficient for you to detect your
> brute-force attacks too, without actually having to see the passwords.
>
> However, if your users are coming in through squirrelmail, ISTM that if 
> you
> want the source IP address information in order to trace these attacks, 
> then
> you need to do the logging in squirrelmail itself. Given that squirrelmail
> is written in PHP, it should be pretty easy to add there.
>
> Handling "special case" logging requirements in courier-imap or 
> authdaemond
> might best be handled by some sort of plugin API - the simplest being the
> ability to exec() an external program whenever a login succeeds or fails,
> although that's not especially efficient.
>
> Note however that you could just modify the 'authcustom' module to do what
> you want, and stick it to the end of the list of auth modules. It will 
> only
> ever be invoked if all the other modules have returned REJECT (because if 
> a
> module returns either ACCEPT or TEMPFAIL, no further modules are called). 
> So
> you know at that point that you have a bad username/password combination, 
> so
> all you need to do is to write your message to stderr and it will appear 
> in
> the log.
>
> I guess the other way to make logging more generic would be to make
> DEBUG_LOGIN a set of flags: 1 = show module internals, 2 = show passwords,
> 4 = whatever. Then you OR them together to get the logging you want. But I
> can't really think of a good use for other flags, so I don't think it's
> warranted yet.
>
> Regards,
>
> Brian.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Courier-imap mailing list
> Cou...@li...
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap