[Bug 1928721] [NEW] rpc-gssd fails to fallback on unsuccessful principal search
Jack Polk
1928721 at bugs.launchpad.net
Mon May 17 20:58:35 UTC 2021
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 at demo:~# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 CORP-DEMO$@CORP.NET (arcfour-hmac)
2 CORP-DEMO$@CORP.NET (aes128-cts-hmac-sha1-96)
2 CORP-DEMO$@CORP.NET (aes256-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (arcfour-hmac)
2 demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (arcfour-hmac)
2 host/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 host/demo.corp.net at CORP.NET (arcfour-hmac)
2 host/demo.corp.edu at CORP.NET (aes128-cts-hmac-sha1-96)
2 host/demo.corp.edu at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/CORP-DEMO at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
Unfortunately, when attempting to mount, rpc.gssd throws the following
errors:
root at 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 demo$@CORP.NET while getting keytab entry for 'demo$@CORP.NET'
No key table entry found for DEMO$@CORP.NET while getting keytab entry for 'DEMO$@CORP.NET'
No key table entry found for root/demo.corp.net at CORP.NET while getting keytab entry for 'root/demo.corp.net at CORP.NET'
No key table entry found for nfs/demo.corp.net at CORP.NET while getting keytab entry for 'nfs/demo.corp.net at CORP.NET'
Success getting keytab entry for 'host/demo.corp.net at CORP.NET'
WARNING: Client 'host/demo.corp.net at CORP.NET' not found in Kerberos database while getting initial ticket for principal 'host/demo.corp.net at CORP.NET' 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 at demo:~# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 CORP-DEMO$@CORP.NET (arcfour-hmac)
2 CORP-DEMO$@CORP.NET (aes128-cts-hmac-sha1-96)
2 CORP-DEMO$@CORP.NET (aes256-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (arcfour-hmac)
2 demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (arcfour-hmac)
2 host/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/DEMO at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
root at 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 demo$@CORP.NET while getting keytab entry for 'demo$@CORP.NET'
Success getting keytab entry for 'CORP-DEMO$@CORP.NET'
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 nfs at storage.corp.net
doing downcall: lifetime_rec=36000 acceptor=nfs at storage.corp.net
...
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 at demo:~# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 CORP-DEMO$@CORP.NET (arcfour-hmac)
2 CORP-DEMO$@CORP.NET (aes128-cts-hmac-sha1-96)
2 CORP-DEMO$@CORP.NET (aes256-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (arcfour-hmac)
2 demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (arcfour-hmac)
2 host/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 host/demo.corp.net at CORP.NET (arcfour-hmac)
- 2 host/demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
- 2 host/demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
+ 2 host/demo.corp.edu at CORP.NET (aes128-cts-hmac-sha1-96)
+ 2 host/demo.corp.edu at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/CORP-DEMO at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
Unfortunately, when attempting to mount, rpc.gssd throws the following
errors:
root at 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 demo$@CORP.NET while getting keytab entry for 'demo$@CORP.NET'
No key table entry found for DEMO$@CORP.NET while getting keytab entry for 'DEMO$@CORP.NET'
No key table entry found for root/demo.corp.net at CORP.NET while getting keytab entry for 'root/demo.corp.net at CORP.NET'
No key table entry found for nfs/demo.corp.net at CORP.NET while getting keytab entry for 'nfs/demo.corp.net at CORP.NET'
Success getting keytab entry for 'host/demo.corp.net at CORP.NET'
WARNING: Client 'host/demo.corp.net at CORP.NET' not found in Kerberos database while getting initial ticket for principal 'host/demo.corp.net at CORP.NET' 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 at demo:~# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 CORP-DEMO$@CORP.NET (arcfour-hmac)
2 CORP-DEMO$@CORP.NET (aes128-cts-hmac-sha1-96)
2 CORP-DEMO$@CORP.NET (aes256-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (arcfour-hmac)
2 demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (arcfour-hmac)
2 host/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
- 2 RestrictedKrbHost/CORP-DEMO at CORP.NET (arcfour-hmac)
- 2 RestrictedKrbHost/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
- 2 RestrictedKrbHost/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
+ 2 RestrictedKrbHost/DEMO at CORP.NET (arcfour-hmac)
+ 2 RestrictedKrbHost/DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
+ 2 RestrictedKrbHost/DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
root at 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 demo$@CORP.NET while getting keytab entry for 'demo$@CORP.NET'
- Success getting keytab entry for 'DEMO$@CORP.NET'
+ Success getting keytab entry for 'CORP-DEMO$@CORP.NET'
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 nfs at storage.corp.net
doing downcall: lifetime_rec=36000 acceptor=nfs at storage.corp.net
...
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
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1928721
Title:
rpc-gssd fails to fallback on unsuccessful principal search
Status in nfs-utils package in Ubuntu:
New
Bug description:
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 at demo:~# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 CORP-DEMO$@CORP.NET (arcfour-hmac)
2 CORP-DEMO$@CORP.NET (aes128-cts-hmac-sha1-96)
2 CORP-DEMO$@CORP.NET (aes256-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (arcfour-hmac)
2 demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (arcfour-hmac)
2 host/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 host/demo.corp.net at CORP.NET (arcfour-hmac)
2 host/demo.corp.edu at CORP.NET (aes128-cts-hmac-sha1-96)
2 host/demo.corp.edu at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/CORP-DEMO at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
Unfortunately, when attempting to mount, rpc.gssd throws the following
errors:
root at 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 demo$@CORP.NET while getting keytab entry for 'demo$@CORP.NET'
No key table entry found for DEMO$@CORP.NET while getting keytab entry for 'DEMO$@CORP.NET'
No key table entry found for root/demo.corp.net at CORP.NET while getting keytab entry for 'root/demo.corp.net at CORP.NET'
No key table entry found for nfs/demo.corp.net at CORP.NET while getting keytab entry for 'nfs/demo.corp.net at CORP.NET'
Success getting keytab entry for 'host/demo.corp.net at CORP.NET'
WARNING: Client 'host/demo.corp.net at CORP.NET' not found in Kerberos database while getting initial ticket for principal 'host/demo.corp.net at CORP.NET' 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 at demo:~# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 CORP-DEMO$@CORP.NET (arcfour-hmac)
2 CORP-DEMO$@CORP.NET (aes128-cts-hmac-sha1-96)
2 CORP-DEMO$@CORP.NET (aes256-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (arcfour-hmac)
2 demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (arcfour-hmac)
2 host/CORP-DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 host/CORP-DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/DEMO at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/DEMO at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/DEMO at CORP.NET (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (arcfour-hmac)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/demo.corp.net at CORP.NET (aes256-cts-hmac-sha1-96)
root at 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 demo$@CORP.NET while getting keytab entry for 'demo$@CORP.NET'
Success getting keytab entry for 'CORP-DEMO$@CORP.NET'
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 nfs at storage.corp.net
doing downcall: lifetime_rec=36000 acceptor=nfs at storage.corp.net
...
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928721/+subscriptions
More information about the foundations-bugs
mailing list