On 21/10/15 15:54, Rich Megginson wrote:
On 10/21/2015 01:00 AM, Mitja Mihelič wrote:
> On 20/10/15 15:57, Mark Reynolds wrote:
>> On 10/20/2015 09:37 AM, Mitja Mihelič wrote:
>>> We are using using nsAccountLock=true to lock user accounts. We
>>> also have dovecot authenticating users against the 389DS.
>>> If we set nsAccountLock=true, then we get
>>> Oct 20 14:39:30 SERVER dovecot: auth: Error:
>>> ldap(USERNAME,193.X.Y.Z,<aaaaaaaaaaaaaaaa>): ldap_bind() failed:
>>> Server is unwilling to perform
>>> Oct 20 14:39:31 SERVER dovecot: auth:
>>> ldap(USERNAME,193.X.Y.Z,<aaaaaaaaaaaaaaaa>): Falling back to
>>> expired data from cache
>>> Dovecot thinks the server is not working properly so it reads login
>>> info from its cache and authentication succeeds.
>>> Can I set 389DS to return a different response?
>>> Something that says: "User is locked" or "Authentication
>> The server is returning an LDAP Error 53 (unwilling to perform) with
>> a message that states its locked ("Account inactivated. Contact
>> system administrator."), but dovecot is not returning this text to
>> its client - its only returning the error code(with the ldap
>> description of that error code).
> Thank you for the explanations.
> Looking at the LDAP error codes, would it not be more accurate if it
> returned 49/533 ACCOUNT_DISABLED ?
Yes, if 389 were AD.
What error code would make Dovecot think that the account is disabled?
Unfortunately I cannot provide an answer to this question. To date there
was no reply on the dovecot list to our query.
I see. I was under the impression the listed
codes were protocol
specific, not implementation specific. Thank you.
> Kind regards, Mitja
>>> Kind regards, Mitja
>> 389 users mailing list
> 389 users mailing list
389 users mailing list