| Summary: | Issues Mounting authenticated NFSv4 using IPA as KDC | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Ryan Yard <ryard> |
| Component: | krb5 | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.7 | CC: | dpal, jplans, kburres, prc, rcritten, ssorce |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-11-07 19:04:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Ryan Yard
2011-12-02 16:50:49 UTC
(In reply to comment #0) > 4.) Configure the keytab on both systems: > > On the server: > ipa service-add nfs/ipa.example.com > ipa service-add nfs/node01.example.com > ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/ipa.example.com -k > /etc/krb5.keytab > > On the client: > ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/ipa.example.com -k > /etc/krb5.keytab If the client command isn't a result of a copy/paste error, then it is incorrect. The client's keytab needs to contain the client's "nfs" keys (as the server's keytab needs to contain the server's "nfs" keys), like so: ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/node01.example.com -k /etc/krb5.keytab (In reply to comment #1) > If the client command isn't a result of a copy/paste error, then it is > incorrect. The client's keytab needs to contain the client's "nfs" keys (as > the server's keytab needs to contain the server's "nfs" keys), like so: > > ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/node01.example.com -k > /etc/krb5.keytab Did this turn out to be a copy/paste error, or were the keytabs being set up improperly? Yes, that was a copy/paster error in the reproduction steps. The issue was able to be resolved by adding the salt type to the keytab, using: ipa-getkeytab -e des-cbc-crc:normal -s ipa.example.com -p nfs/node01.example.com -k /etc/krb5.keytab Salt types can only matter when the key being used is derived from a password, and unless you're using the -P option to be prompted for one, ipa-getkeytab should be forcing the salt type to "none". If you can perform a before/after comparison, please paste in the output of running "klist -k -e" on node01.example.com and 'kadmin.local -q 'getprinc nfs/nfs/node01.example.com' on ipa.example.com. Those are the two places where encryption and salt types are recorded are in the client's keytab and the KDC database, and they should help verify if there's something different going on than what I'm expecting based on the sources. The version information for the ipa-* packages on both systems may be helpful, too. I am no longer testing across RHEL 5->6 major releases. I have convinced my client to build out the solution on RHEL6.2 across the board, so... I no longer have the test environment configured. I am not able to test, I can only provide you with the details of what the resolution was at the time. Thanks, Ryan Unfortunately, that doesn't clarify if running the modified ipa-getkeytab command, where it should have had no effect and warned of this, actually made a meaningful difference. In case that it did, what caused you to run it the first way the first time? Marking as closed due to insufficient data. |