On Fri, May 21, 2021, 08:54 Rob Crittenden <rcritten@redhat.com> wrote:
Mark Potter via FreeIPA-users wrote:
> Long story short, we had to redeploy part of our FreeIPA cluster. As far
> as I know I followed all of the proper procedures and everything
> seems to be working from the client side however we are getting a TON of
> these messages in krb5kdc.log
>
> ipa3.example.com <http://ipa3.example.com> krb5kdc[31232](info): TGS_REQ
> (8 etypes {18 17 20 19 16 23 25 26}) 10.6.21.19 <http://10.6.21.19>:
> LOOKING_UP_SERVER: authtime 0,  host/client100.example.com@EXAMPLE.COM
> <mailto:client100.example.com@EXAMPLE.COM> for
> nfs/nfs1.example.com@EXAMPLE.COM <mailto:nfs1.example.com@EXAMPLE.COM>,
> Server not found in Kerberos database
>
> client100.example.com <http://client100.example.com> has working
> forward and reverse DNS entries that resolve from all FreeIPA servers
> and from itself.
>
> nfs1.example.com <http://nfs1.example.com> has working forward and
> reverse entries that resolve from all FreeIPA servers and from itself,
> it is not part of the FreeIPA domain at all, it is still using the
> authentication we are replacing with FreeIPA. It is used for automount
> homedirs in FreeIPA but is not kerberized
>
> All of the clients reporting this error still properly automount
> homedirs and that is the only thing on nfs1.example.com
> <http://nfs1.example.com>. There is another mountpoint, also not
> kerberized, in the automount setup that is not throwing any errors and
> access extremely frequently.
>
> I am happy to provide any logs necessary to track this down.

IIRC the client first looks for nfs/<server> and will fall back to
host/<server>. So create an nfs service principal and use ipa-getkeytab
to add a key to /etc/krb5.conf on the NFS server(s).

rob

The NFS server is not kerberized nor is it part of the FreeIPA environment. It is only referenced in automount. The strange thing the one that's showing up in the errors is not the only one in use. 

We have the following: 

nfs0001 which is a CentOS box serving home directories via autofs and is referenced once

nfs0002 which is a Vast storage system serving multiple mounts via autofs, referenced multiple times and not showing up in the logs

 Here is a full log message for one FreeIPA client with these two repeating:

Jun 01 10:17:03 ipa0001.example.com krb5kdc[31212](info): TGS_REQ (4 etypes {18 17 16 23}) 10.7.24.38: LOOKING_UP_SERVER: authtime 0,  host/node7-24-38.example.com@EXAMPLE.COM for nfs/nfs0001.example.com@EXAMPLE.COM, Server not found in Kerberos database
Jun 01 10:17:03 ipa0001.example.com krb5kdc[31212](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.7.24.38: LOOKING_UP_SERVER: authtime 0,  host/node7-24-38.example.com@EXAMPLE.COM for nfs/nfs0001.example.com@EXAMPLE.COM, Server not found in Kerberos database

These are also showing up, with much less frequency but I do not know if they are related:

Jun 01 10:06:15 ipa0001.example.com krb5kdc[31213](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.7.24.38: NEEDED_PREAUTH: host/node7-24-38.example.com@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Additional pre-authentication required
Jun 01 10:06:15 ipa0001.example.com krb5kdc[31209](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.7.24.38: ISSUE: authtime 1622559975, etypes {rep=18 tkt=18 ses=18}, host/node7-24-38.example.com@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM
Jun 01 10:06:15 ipa0001.example.com krb5kdc[31211](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.7.24.38: ISSUE: authtime 1622559975, etypes {rep=18 tkt=18 ses=18}, host/node7-24-38.example.com@EXAMPLE.COM for ldap/ipa0001.example.com@EXAMPLE.COM

The errors are only appearing on the nfs server that serves home directories, however autofs is working without any issues. We do not intend to kerberize nfs0001 and cannot kerberize the Vast storage system. This was not an issue before we redeployed the FreeIPA servers and have changed nothing related to NFS at all. I can provide any config files or logs that are needed. The biggest issue we have seen due to this is logs filling up on the FreeIPA servers. It does not seem to afffect autofs or authentication at present.