Public bug reported: Our team is currently using rpc-gssd for NFS shares that are secured with Kerberos. We are using an Active Directory server as our KDC. Something that we are trying out as a potential solution to naming conflicts is the use of a computer name in AD that does not match the machine's local hostname. We have ensured that the appropriate DNS records exist for this alternate hostname.
After using adcli to join the machine to the domain, we get the following principals: root@demo:~# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 [email protected] (arcfour-hmac) 2 [email protected] (aes128-cts-hmac-sha1-96) 2 [email protected] (aes256-cts-hmac-sha1-96) 2 [email protected] (arcfour-hmac) 2 [email protected] (aes128-cts-hmac-sha1-96) 2 [email protected] (aes256-cts-hmac-sha1-96) 2 host/[email protected] (arcfour-hmac) 2 host/[email protected] (aes128-cts-hmac-sha1-96) 2 host/[email protected] (aes256-cts-hmac-sha1-96) 2 host/[email protected] (arcfour-hmac) 2 host/[email protected] (aes128-cts-hmac-sha1-96) 2 host/[email protected] (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (arcfour-hmac) 2 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (arcfour-hmac) 2 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96) Unfortunately, when attempting to mount, rpc.gssd throws the following errors: root@demo:~# rpc.gssd -vvv -f ... handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2' (nfs/clnt44) krb5_use_machine_creds: uid 0 tgtname (null) Full hostname for 'storage.corp.net' is 'storage.corp.net' Full hostname for 'demo.corp.net' is 'demo.corp.net' No key table entry found for [email protected] while getting keytab entry for '[email protected]' No key table entry found for [email protected] while getting keytab entry for '[email protected]' No key table entry found for root/[email protected] while getting keytab entry for 'root/[email protected]' No key table entry found for nfs/[email protected] while getting keytab entry for 'nfs/[email protected]' Success getting keytab entry for 'host/[email protected]' WARNING: Client 'host/[email protected]' not found in Kerberos database while getting initial ticket for principal 'host/[email protected]' using keytab 'FILE :/etc/krb5.keytab' ERROR: No credentials found for connection to server storage.corp.net doing error downcall ... After some brief debugging, we found that when removing the principals that are causing the failure the mount works fine: root@demo:~# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 [email protected] (arcfour-hmac) 2 [email protected] (aes128-cts-hmac-sha1-96) 2 [email protected] (aes256-cts-hmac-sha1-96) 2 [email protected] (arcfour-hmac) 2 [email protected] (aes128-cts-hmac-sha1-96) 2 [email protected] (aes256-cts-hmac-sha1-96) 2 host/[email protected] (arcfour-hmac) 2 host/[email protected] (aes128-cts-hmac-sha1-96) 2 host/[email protected] (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (arcfour-hmac) 2 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (arcfour-hmac) 2 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96) root@demo:~# rpc.gssd -vvv -f ... handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2' (nfs/clnt4f) krb5_use_machine_creds: uid 0 tgtname (null) Full hostname for 'storage.corp.net' is 'storage.corp.net' Full hostname for 'demo.corp.net' is 'demo.corp.net' No key table entry found for [email protected] while getting keytab entry for '[email protected]' Success getting keytab entry for '[email protected]' INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_CORP.NET' are good until 1621320566 INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_CORP.NET' are good until 1621320566 creating tcp client for server storage.corp.net DEBUG: port already set to 2049 creating context with server [email protected] doing downcall: lifetime_rec=36000 [email protected] ... The solution seems straightforward: don't assume because a principal has been found that the principal is sufficient or allow for users to manually specify which principal to use through a command line argument (-P perhaps?) We understand that a split-name configuration like this is an unconventional approach but we feel that this behavior is a bug given that there exists principals in the keytab that can facilitate authentication. ** Affects: nfs-utils (Ubuntu) Importance: Undecided Status: New ** Description changed: Our team is currently using rpc-gssd for NFS shares that are secured with Kerberos. We are using an Active Directory server as our KDC. Something that we are trying out as a potential solution to naming conflicts is the use of a computer name in AD that does not match the machine's local hostname. We have ensured that the appropriate DNS records exist for this alternate hostname. After using adcli to join the machine to the domain, we get the following principals: root@demo:~# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 [email protected] (arcfour-hmac) 2 [email protected] (aes128-cts-hmac-sha1-96) 2 [email protected] (aes256-cts-hmac-sha1-96) 2 [email protected] (arcfour-hmac) 2 [email protected] (aes128-cts-hmac-sha1-96) 2 [email protected] (aes256-cts-hmac-sha1-96) 2 host/[email protected] (arcfour-hmac) 2 host/[email protected] (aes128-cts-hmac-sha1-96) 2 host/[email protected] (aes256-cts-hmac-sha1-96) 2 host/[email protected] (arcfour-hmac) - 2 host/[email protected] (aes128-cts-hmac-sha1-96) - 2 host/[email protected] (aes256-cts-hmac-sha1-96) + 2 host/[email protected] (aes128-cts-hmac-sha1-96) + 2 host/[email protected] (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (arcfour-hmac) 2 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (arcfour-hmac) 2 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96) Unfortunately, when attempting to mount, rpc.gssd throws the following errors: root@demo:~# rpc.gssd -vvv -f ... handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2' (nfs/clnt44) krb5_use_machine_creds: uid 0 tgtname (null) Full hostname for 'storage.corp.net' is 'storage.corp.net' Full hostname for 'demo.corp.net' is 'demo.corp.net' No key table entry found for [email protected] while getting keytab entry for '[email protected]' No key table entry found for [email protected] while getting keytab entry for '[email protected]' No key table entry found for root/[email protected] while getting keytab entry for 'root/[email protected]' No key table entry found for nfs/[email protected] while getting keytab entry for 'nfs/[email protected]' Success getting keytab entry for 'host/[email protected]' WARNING: Client 'host/[email protected]' not found in Kerberos database while getting initial ticket for principal 'host/[email protected]' using keytab 'FILE :/etc/krb5.keytab' ERROR: No credentials found for connection to server storage.corp.net doing error downcall ... After some brief debugging, we found that when removing the principals that are causing the failure the mount works fine: root@demo:~# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 [email protected] (arcfour-hmac) 2 [email protected] (aes128-cts-hmac-sha1-96) 2 [email protected] (aes256-cts-hmac-sha1-96) 2 [email protected] (arcfour-hmac) 2 [email protected] (aes128-cts-hmac-sha1-96) 2 [email protected] (aes256-cts-hmac-sha1-96) 2 host/[email protected] (arcfour-hmac) 2 host/[email protected] (aes128-cts-hmac-sha1-96) 2 host/[email protected] (aes256-cts-hmac-sha1-96) - 2 RestrictedKrbHost/[email protected] (arcfour-hmac) - 2 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96) - 2 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96) + 2 RestrictedKrbHost/[email protected] (arcfour-hmac) + 2 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96) + 2 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (arcfour-hmac) 2 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96) root@demo:~# rpc.gssd -vvv -f ... handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2' (nfs/clnt4f) krb5_use_machine_creds: uid 0 tgtname (null) Full hostname for 'storage.corp.net' is 'storage.corp.net' Full hostname for 'demo.corp.net' is 'demo.corp.net' No key table entry found for [email protected] while getting keytab entry for '[email protected]' - Success getting keytab entry for '[email protected]' + Success getting keytab entry for '[email protected]' INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_CORP.NET' are good until 1621320566 INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_CORP.NET' are good until 1621320566 creating tcp client for server storage.corp.net DEBUG: port already set to 2049 creating context with server [email protected] doing downcall: lifetime_rec=36000 [email protected] ... The solution seems straightforward: don't assume because a principal has been found that the principal is sufficient or allow for users to manually specify which principal to use through a command line argument (-P perhaps?) We understand that a split-name configuration like this is an unconventional approach but we feel that this behavior is a bug given that there exists principals in the keytab that can facilitate - authentication. This is supported by the fact that the error message - states "No credentials found" , which is somewhat misleading. + authentication. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928721 Title: rpc-gssd fails to fallback on unsuccessful principal search To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928721/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
