--On Tuesday, May 12, 2015 7:58 PM +0000 [email protected] wrote: > --On Tuesday, May 12, 2015 1:18 PM +0000 [email protected] 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
