On Thu, Feb 13, 2020 at 10:24 AM Mote, Todd <moter(a)austin.utexas.edu> wrote:
Only using GSSAPI causes the unsigned SASL event.
root@anti-test:~ # ldapsearch -H
ldap://dc01a.ADTEST.domain.com -Y GSSAPI -b ''
-s base
SASL/GSSAPI authentication started
SASL username: ANTI-TEST$(a)ADTEST.domain.com
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
GSS-SPNEGO looks the same, and does not trigger the unsigned event.
root@anti-test:~ # ldapsearch -H
ldap://dc01a.ADTEST.domain.com -Y GSS-SPNEGO -b
'' -s base
SASL/GSS-SPNEGO authentication started
SASL username: ANTI-TEST$(a)ADTEST.domain.com
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
We see the exact same thing on our RHEL7 hosts.
Looking at the packet traces of "-Y GSSAPI" and "-Y GSS-SPNEGO", both
connections issue the query under SASL GSS-API Privacy. But with
GSSAPI, it takes 3 steps to complete the bind request and activate
SASL GSS-API Privacy:
bindRequest(1) "<ROOT>" sasl
bindResponse(1) saslBindInProgress
bindRequest(2) "<ROOT>" sasl
bindResponse(2) saslBindInProgress
bindRequest(3) "<ROOT>" sasl
bindResponse(3) success
SASL GSS-API Privacy: payload (148 bytes)
SASL GSS-API Privacy: payload (160 bytes)
SASL GSS-API Privacy: payload (7 bytes)
With GSS-SPNEGO, it takes only one step:
bindRequest(1) "<ROOT>" sasl
bindResponse(1) success
SASL GSS-API Privacy: payload (148 bytes)
SASL GSS-API Privacy: payload (160 bytes)
SASL GSS-API Privacy: payload (7 bytes)
Our Windows admins confirm that the GSSAPI query triggers this warning:
The following client performed a SASL
(Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting
signing (integrity verification), or performed a simple bind over
a clear text (non-SSL/TLS-encrypted) LDAP connection.
…but the GSS-SPNEGO query does not.
Sumit, in a moment I'll reply just to you, and include the packet
traces.