search

cyrusimap / cyrus-sasl

Other
134 stars 150 forks source link

LDAP passthrough problem #550

Open zjgzxh opened 5 years ago

zjgzxh commented 5 years ago

platform: CentOS Linux release 7.3.1611 (Core) version of SASL: cyrus-sasl-2.1.26

I used Cyrus Sasl 2.1.26 as a LDAP passthrough to external LDAP server on CentOS 7.

I can logon using external LDAP user and password, if I stop external LDAP server, I can still logon which should not, because I did not use cache option of saslauthd.

After investigatin, I found in auth_ldap.c -> auth_ldap function the following line: static LAK *lak = NULL; So the user name and password is cached in this static variable, it contains the bind status is BOUND if a user logon successfully, so if the same user logon, it is not going to contact the external LDAP server since it's already bound, I don't know if it's done on purpose or it's a bug. Please clarify.

Thanks Jerry

zjgzxh commented 5 years ago

Comment received from elliefm on https://github.com/cyrusimap/cyrus-imapd/issues/2604

zjgzxh commented 5 years ago

I also did the test to validate the "LDAP server refused the authentication" case elliefm suggested, it always uses the cached data once it has it. The test is as following:

  1. Logon using external LDAP user and password, the logon is successful.
  2. Change external LDAP user password to new password,
  3. Logon using external LDAP user and old password, the logon is successful, which should be rejected.

Thanks Jerry

zjgzxh commented 5 years ago

Hello, any update on this issue? Thanks

zjgzxh commented 5 years ago

Any update on this issue? Thanks

zjgzxh commented 5 years ago

Can some one look at this issue? Thanks

zjgzxh commented 5 years ago

Hello. Any update on this issue? Thanks

zjgzxh commented 5 years ago

Can some one please look at this issue? Thanks

simo5 commented 4 years ago

The code in lak_auth_bind (and more specifically lak_bind) seem to be explicitly always doing cached authentication. However it looks like this is a truly global variable, so as soon as another user logs in the cached value would be replaced. Not sure what to make of it, but at least a work around could be to perform bogus authentications whenever you want to invalidate a cache ?