--On Tuesday, May 12, 2015 7:58 PM +0000 quanah@zimbra.com wrote:
--On Tuesday, May 12, 2015 1:18 PM +0000 hyc@symas.com wrote:
Works as designed. The Bind op itself didn't provide any security, so it contributed 0 to the session's ssf. The preceding StartTLS request actually established a security layer, and it correctly logs the ssf from that.
I think overall the design is problematic. "ssf" is generally supposed to indicate the overall security of the connection, regardless of the step. Perhaps for 2.5 and later, we could modify the logging line to be something more like:
May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=256
So that the overall SSF of the connection is reflected, and we're indicating that specifically the BIND op added nothing to SSF.
This would be useful for ldapi:/// connections as well, as there are zero ssf indicators logged at all outside of the bind op:
May 12 02:30:19 ldap01 slapd[33839]: conn=169357 fd=85 ACCEPT from PATH=/opt/zimbra/data/ldap/state/run/ldapi (PATH=/opt/zimbra/data/ldap/state/run/ldapi) May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 RESULT tag=97 err=0 text=
Even though I have:
olcLocalSSF: 128
in my config DB
I.e., I think it would be better to show:
May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=128
in this case.
Per Howard:
we should update the SASL Bind log to use bind_ssf= as well
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration