> -----Original Message-----
> From:
> [email protected]
>
> [mailto:[email protected]
> illa.org] On Behalf Of Nelson Bolyard
> Sent: Monday, April 27, 2009 6:34 AM
> To: [email protected]
> Subject: Re: SASL authentication
>
> Does maxssf disable the use of SSL?
By default, maxssf is set to 56 when sasl binding is in use. So yes, it
disables SSL encryption. That is why SSL only works when maxssf is set to zero.
> I wonder if this could be another manifestation of failure to
> specify the client's identity to libSSL (that is, to name a
> client session cache to be used with each connection).
You used the word "another", so does it mean you have come across the similar
scenario before?
> If a process is trying to act as multiple client identities,
> and doesn't identify each of those identities separately to
> libSSL through a call to SSL_SetSockPeerID, then libSSL will
> attempt to use a single common SSL session for all of them.
>
> Perhaps this leads to failures with the following scenario:
>
> - identity 1 establishes an SSL session with the server and
> binds his identity to it with SASL.
> - identity 2 connects to the same server, and reuses the SSL
> session established by identity 1. Things fail because of
> the identity mismatch.
> - identity 2 retries, creating a new session, bound to
> identity 2, and succeeds.
> - identity 1 connects to that server, reusing the session of
> identity 2, ... etc.
>
> Is that the behavior described as "ping pong style" ?
Yes, your description is the same as the problem observed here.
But a question: You mentioned "identity". Is it referring to the
username/credential associated with a user? If it is, then some problem here.
The "ping pong" style is visible even with the same user in multiple binding
tries:
===================================================
<apManager> (Tue Apr 14 2009 17:54:24.215)
<p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:54:24.382)
<p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 0
......
<apManager> (Tue Apr 14 2009 17:54:24.390)
<p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:54:24.395)
<p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 81
<apManager> (Tue Apr 14 2009 17:54:24.395)
<p7800,t3078957984,aba_ldap_interface.c,1671>
ERROR>> LDAP BIND: Value of ldap failure status and text 81 Can't contact
LDAP server
......
<apManager> (Tue Apr 14 2009 17:54:40.943)
<p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:54:41.030)
<p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 0
......
<apManager> (Tue Apr 14 2009 17:54:41.038)
<p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:54:41.043)
<p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 81
<apManager> (Tue Apr 14 2009 17:54:41.043)
<p7800,t3078957984,aba_ldap_interface.c,1671>
ERROR>> LDAP BIND: Value of ldap failure status and text 81 Can't contact
LDAP server
......
<apManager> (Tue Apr 14 2009 17:54:57.444)
<p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:55:00.450)
<p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 0
......
<apManager> (Tue Apr 14 2009 17:55:00.458)
<p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:55:00.463)
<p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 81
<apManager> (Tue Apr 14 2009 17:55:00.463)
<p7800,t3078957984,aba_ldap_interface.c,1671>
ERROR>> LDAP BIND: Value of ldap failure status and text 81 Can't contact
LDAP server
===================================================
All this happens with the same user over multiple tries. On the other hand, if
your identity means something other than the user, then your analysis should be
correct. By the way, is there any way for me to prove what you described with
logs?
Could you come up with some kind of fix? I can convey the fix to OS team to
help me build a new MozLDAP library, and I will test the fix with the new
library.
Thanks a lot,
Xu Qiang
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap
