Comment 11 for bug 1984073

Revision history for this message
rdratlos (rdratlos) wrote :

And here's the output after applying proposed patches using the same configuration as above:

$ automount -f -v -d

Starting automounter version 5.1.8, master map auto.master
using kernel protocol version 5.05
reading ldap master auto.master
parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto.master".
parse_server_string: lookup(ldap): mapname auto.master
parse_ldap_config: lookup(ldap): ldap authentication configured with the following options:
parse_ldap_config: lookup(ldap): use_tls: 0, tls_required: 0, auth_required: 2, sasl_mech: GSSAPI
parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client principal: <email address hidden> credential cache: /tmp/krb5cc_0
do_init: parse(sun): init gathered global options: (null)
find_server: trying server uri ldap://dc.example.com
init_ldap_connection: lookup(ldap): ldap_initialize( ldap://dc.example.com )
do_bind: lookup(ldap): auth_required: 2, sasl_mech GSSAPI
sasl_do_kinit: initializing kerberos ticket: client principal <email address hidden>
sasl_do_kinit: calling krb5_parse_name on client principal <email address hidden>
sasl_do_kinit: Using tgs name <email address hidden>
sasl_do_kinit: Kerberos authentication was successful!
do_bind: Attempting sasl bind with mechanism GSSAPI
do_bind: SASL username: <email address hidden>
do_bind: SASL authcid: root
do_bind: SASL SSF: 256
do_bind: sasl bind with mechanism GSSAPI succeeded
get_query_dn: lookup(ldap): check search base list
get_query_dn: lookup(ldap): found search base under ou=automount,dc=example,dc=com
get_query_dn: lookup(ldap): found query dn CN=auto.master,OU=automount,DC=example,DC=com
connected to uri ldap://dc.example.com
lookup_read_master: lookup(ldap): searching for "(objectclass=nisObject)" under "CN=auto.master,OU=automount,DC=example,DC=com"
lookup_read_master: lookup(ldap): examining entries
validate_string_len: lookup(ldap): string /pub encoded as /pub
validate_string_len: lookup(ldap): string /- encoded as /-
validate_string_len: lookup(ldap): string /home/EXAMPLE encoded as /home/EXAMPLE
[...]

And the wireshark captures:

Samba AD DC -> autofs client
Lightweight Directory Access Protocol
    LDAPMessage bindResponse(4) success
        messageID: 4
        protocolOp: bindResponse (1)
            bindResponse
                resultCode: success (0)
                matchedDN:
                errorMessage:
                serverSaslCreds: <MISSING>
        [Response To: 1447]
        [Time: 0.005311676 seconds]

autofs client -> Samba AD DC (now encrypted)
Lightweight Directory Access Protocol
    SASL Buffer Length: 136
    SASL Buffer
        GSS-API Generic Security Service Application Program Interface
            krb5_blob: 050406ff00000000000000002da879344a0f22794518372365ed920eaf4acbd7baf4a271…
                krb5_tok_id: KRB_TOKEN_CFX_WRAP (0x0405)
                krb5_cfx_flags: 0x06, AcceptorSubkey, Sealed
                krb5_filler: ff
                krb5_cfx_ec: 0
                krb5_cfx_rrc: 0
                krb5_cfx_seq: 766015796
                krb5_sgn_cksum: 4a0f22794518372365ed920eaf4acbd7baf4a271868731dda6b1d01c87805f539b36d9a7…
        GSS-API Encrypted payload: 0a0f7fd4441995390a20f1a67d0186d92457d6096fb05f941b48bc31a7082638407798a0…

Traffic of the complete LDAP session is now encrypted, which is what Samba AD DC requires.