Kerberos-secured network file shares - practical guide for kerberized NFSv4

| Pekka Helenius | February 12, 2021

Updated: November 9, 2021

Sharing sensitive data in secure manner is important on many critical network environments, and Kerberos security provides much needed security layer for insecure NFSv4 file sharing. This article focuses on setting up, configuring and testing MIT Kerberos V5 + NFSv4 file sharing on Linux environment.

Unlike many blog articles, I take one step further and explain how to set-up such environment with not just two but four individual Linux computers: Combined Kerberos LDAP back-end and user database server, Kerberos KDC & Administration server, NFSv4 server and NFSv4 client.

Foreword

This article compared to other online sources

Many articles focus setting up just combined Kerberos KDC + NFS server and NFS client setup which is far too simple to be used in every day and complex IT environments. Main issue in these articles is that do not clearly distinguish what is actually required for proper setup on individual computers. Understanding what is needed and where in a practical way is crucial for setting up and scaling up a Kerberos environment in real life organizational IT environments.

Common misconceptions

Official Kerberos and NFS documentation can be a burden itself and is quite fragmented. Not only that but there vendor-specific solutions such as Red Hat's FreeIPA implementation and Oracle's partially own implementation exist, as well.

Once you understand basics, you get quite comfortable with the official documentation within weeks. However, we need lower the barrier at first. We need just a simple and pure but yet complete MIT Kerberos V5 and NFSv4 setup guide with understandable and detailed descriptions. We are humans, after all.

Another major issue is a bit suprising one: NFS Utils, a package provided by kernel.org and available on many Linux distributions, does not very clearly distinguish roles and required services on a NFSv4 server and client, nor if these services are needed just for a pure NFSv4 setup.

NFS Utils include everything for NFSv2, NFSv3 and NFSv4 and yet we need only NFSv4. Older NFSv3 is still another popular choice due to its simplicity, not security. Insecure NFSv4 without Kerberos is also a popular choice among people since Kerberos integration seems too difficult (or not worth the effort) for many who are new to Kerberos security concepts.

Help! Too many daemons and service files! I don't know what to do

Yeah, I know the issue. Kerberos is not the simpliest network/server setup you can do. You may be confused because of

mixture of various systemd service files needed, based on a computer role on a network
different NFS versions require different configuration and service file mixtures to ‘get it right’
custom setups random people use
One blogger says something, another says another thing. One uses BSD, another uses RHEL and yet another another OS.
“I found documentation that tells me to do something that I don't have on my setup, or simply tells me to use some random configuration without telling me why. Honestly, I don't know what I actually need on a working MIT Kerberos V5 + NFSv4 setup."

And, then there are articles such as this one: Holy shit is Kerberized NFS cancer! - Rudd-O.com

Hint: rely on official documentation, get proper architectural understanding of required Kerberos & NFSv4 stuff for your setup. Get good source materials for this stuff. Really understand how it all works. This is what I attempt to do in this article. You have not hit the wall yet.

Dealing with contradicting recommendations

As far as I've read, NFSv4 security is still in development. Work-in-progress combined with out-dated or conflicting online sources which do not suit to your needs tend to lead to confusion, frustation and finally you give up.

Let me be clear on this one: Some online guides do not directly fit to your setup. Actually, many of them do not perfectly fit to your setup, so you need to practice and integrate Kerberos into your environment.

What do I really need on my servers? Facts - now!

Some guides are also simply too old and talk about configuration which is not required anymore for kerberized NFSv4 setup. For instance, you may still find conflicting information like the following:

RPC daemons. NFSv4 Server. It is claimed that RPC SVCGSSD (rpc-svcgssd.service) is required on NFSv4 server. This is completely false. It is replaced by GSS Proxy daemon (see section NFS Server), to be precise: gssproxy.service on Systemd-based Linux systems.
NFSv4 Client. On NFSv4 client, rpc-gssd.service is required and gssproxy.service is optional (I recommend it, see Pagure.io website why). This is true. However, rpc-svcgssd.service is never required on NFSv4 client (source: Pagure.io - NFS/GSS Proxy Daemon, see section NFS Client).
- Conclusion: rpc-svcgssd.service or anything related to it is not required on any computer at all.
User and group ID mapping. NFS ID Map service (nfs-idmapd.service) is required on NFSv4 server but not on NFSv4 client. Yet both computers need a proper NFSv4 ID mapping. So how does NFSv4 client do that? Here's the catch: On a client, nfs-idmapd.service is (partially) replaced by Linux kernel internal kernelspace code which calls userspace executable nfsidmap whenever needed. NFSv4 client uses nfs-idmapd.service only as fallback, only and only if nfsidmap executable is not found and not configured in /etc/request-key.conf or in /etc/request-key.d/*.conf file on the NFSv4 client.
- See Red Hat documentation for more information.
Unneeded services. These services are not needed on NFSv4 setup at all, no matter what:
- rpcbind.service, rpc-rquotad.service, nfs-lock.service, rpc-statd.service, rpc-statd-notify.service
Commands. kadmin.local command is for local Kerberos administration directly on Kerberos server. kadmin command is for remote computers which have Kerberos installed and access to Kerberos server administration utility. You can configure remote access in /etc/krb5.conf file and by allowing it in your Kerberos KDC & Administration server + firewall policy.
Systemd service file contents. I will give you contents of several NFS Utils Systemd files for each computer depending on their role on NFSv4/Kerberos network. The official nfs-utils package seems not to have proper configuration for proper Kerberos V5 + NFSv4 setup by default.

Errors, permission issues! Too much frustation. I give up! Yet I say: Do not give up

Some tricky issues can be, yeah, really, really tricky ones. Even if you enable as much logging as possible (rpcdebug and every possible daemon verbose & debug flags: I am looking at you), you may not clearly see what's wrong in your setup. This is because even Linux kernel does not give enough log data for nasty, yet simple misconfigurations, not talking about userspace NFS daemons. Finally you end up only with your erroneous log entries without clear answers why errors occur in the first place.

My best advice: read official documentation, double check your setup. Take a break. Try different approach. Understand what you read, compare to your own setup. Do not only rely on random Google searches or issue tickets on ServerFault.com or Unix.Stackexchange.com. I say you should use those as well, but not at the expense of the official documentation. See also my Additional guides section.

For instance, I debugged one extremely frustating issue four days straight until I found a solution by just carefully reading Oracle Kerberos and GSS-API documentation, and understood I missed two lines of configuration on my NFSv4 server. Once I fixed that, all my day-long problems were gone and everything worked flawlessly.

Getting started

I go through required configuration steps one by one. It is essential you will have all components in place. Setting up kerberized NFSv4 environment is a complex process for beginners and requires components such as DNS, NTP and Kerberos back-end database which can be full projects only themselves for a sysadmin. However, once you get over these obstacles, and understand key Kerberos concepts, it gets easier to extend your knowledge and troubleshoot issues independently on your own.

This article completely excludes Kerberos KDC server slave (replication) configuration. The article focuses on Linux environment and does not cover BSD.

Prerequisites

I assume you have following hardware & OS resources available:

A. Time synchronization: Valid NTP server available (remote or local)
B. Centralized domain names: Valid local DNS server
1. NFSv4 user + Kerberos principal back-end server role: Linux computer or VM
2. NFSv4 client role: Linux computer or VM
3. NFSv4 server role: Linux computer or VM
4. Kerberos KDC role: Linux computer or VM

You can always combine roles of, for example, servers 1. and 4., if ever needed or preferred. Do as you like.

DNS and NTP servers. You need a DNS server and reliable time synchronization (NTP) for all computers. Usually NTP servers are located at WAN area unless you want to setup your own local trustworthy NTP server.

As expected, all computers must be networked. All computers should have a firewall software installed for the sake of basic network security (ufw, iptables, firewalld or any other solution you prefer).

Architectural overview

MIT Kerberos V5 + NFSv4 architectural overview is pretty simple. However, it is important to classify and distinguish role of each computer on this setup. One working model example is as follows:

Kerberized NFSv4 architecture (Kerberos logo by MIT)

IMAGE: Pekka Helenius

Kerberos KDC stores service, user and computer related principals in a back-end database as shown.
- Supported databases are DB2, LMDB and LDAP (OpenLDAP/Windows AD)
- See also: MIT Kerberos Documentation - Database types
Since Kerberos security is partially dependent on exact timestamps, all Kerberos-related computers need a stable and trustworthy NTP server connections.
DNS server is needed for centralized management of Kerberos-related computers in a local network, and optionally for special Kerberos server DNS record lookups. See DNS server configuration below for details.

NFSv4 user mapping

Key notions, referring to the image above:

NFSv4 server and NFSv4 client form together a common NFSv4 ID Map domain and have mutually equivalent user and group name database. Names, not UIDs or GIDs. The catch is explained in the examples below.
- Note that NFSv4 ID Map domain doesn't have to be same than your DNS domain or Kerberos REALM name. NFSv4 ID Map domain is and independent entity and it is used purely to detect whether NFSv4 computers are related to each other. The following example explains this better:

If NFSv4 domains domain.1 and domain.2 are used, then the following is true for NFSv4 user mapping:

--------------------
Example 1:

NFSv4 client domain and user: foo@domain.1 (user UID: 3450; user@domain.1)
NFSv4 server domain and user: foo@domain.1 (user UID: 5501; user@domain.1)

User mapping: NFSv4 client <-> NFSv4 server
-> success
Reason: domains match, user is found on both client and server. At first, server recognizes that the domain matches, after which user and group names are searched from a user & group database defined by NFSv4 server's /etc/idmapd.conf. Client's nfsidmap process does the same. The process is mutual between the client & the server.

--------------------
Example 2:

NFSv4 client domain and user: foo@domain.1 (UID: 3450; user@domain.1)
NFSv4 server domain and user: foo@domain.2 (UID: 5501; user@domain.2)

User mapping: NFSv4 client <-> NFSv4 server
-> failure
Reason: domains mismatch. Simple as that. No matter whether user or group names match or not.

This simple example demonstrates that domain name used in /etc/idmapd.conf on both NFSv4 client and server must match, and also that NFSv4 domain name has nothing to do with the actual server DNS domain or REALM/domain settings used in Kerberos configuration.

NOTE: The NFSv4 user mapping examples above are, of course, simplified ones. In real life, simple lookups by kerberized NFSv4 server are not enough because user authentication and authorization are also based on proper GSSAPI (Generic Security Service Application Program Interface) configuration.

Practically, this means that a user name must be recognizable from Kerberos principal name, otherwise a user is authenticated as nobody, and you will get a lot of permission denied errors and such. To counter that issue, NFSv4 server's /etc/krb5.conf file is configured in a way as shown in NFSv4 server Kerberos configuration section below.

Configuration

All computers

Linux kernel configuration requirements

In this section, you may need to re-compile Linux kernel on/for your target computers with the described configurations enabled.

I assume you know how to compile Linux kernel. If you do not, please refer to online materials and your Linux distribution official manual and compile process steps.

I recommend enabling the following kernel configurations.

You can check these with command zcat /proc/config.gz | grep <config_name>

Please keep in mind I have not actually distinguished which is needed for NFSv4 server and client, so if you want to adapt your kernel specifically for these computers, you need to do check what is needed and what is not by yourself. I prefer flexibility since enabling all flags does not add too much overhead to a Linux kernel image file.

About provided Systemd files

This article provides Systemd file content recommendations. However, always practice critical thinking, and adapt the content to your Kerberos environment. In general, feel free to customize Systemd files as needed so they fit into your specific environment.

As a side note, I always recommend using overrides like this for critical system daemons:

# /etc/systemd/system/krb5-kadmind.service.d/override.conf
------------------------------
[Service]
Restart=always
# Restart=on-failure
RestartSec=10

This override ensures a daemon will restart if it fails, for instance, due to a not-yet-started dependency service. It also ensures the service daemon is started if it fails for some other reason during computer runtime. There is a risk for endless loop and manual intervention requirement if the daemon fails to start again and again. For advanced Systemd service topology and analysis, use commands such as systemctl list-dependencies --reverse <service-file>, and do not forget checking dmesg output, too.

Kerberos back-end and NFSv4 user database server

This article mostly assumes that you have a working LDAP setup and it is running already in your network environment.

In this article, we use OpenLDAP for LDAP Kerberos back-end database. As said, the database is required by Kerberos KDC for storing user, machine and service principals.

For basic OpenLDAP server configuration, see the following links:

For Kerberos, you need to ìnclude kerberos.schema in OpenLDAP's /etc/openldap/slapd.conf file. It is usually provided by Kerberos package and may locate at /usr/share/doc/krb5/examples/kerberos.schema. It is recommended to copy this file into /etc/openldap/schema/. Consider converting this file to LDIF format by using a tool such as schema2ldif.

Refer to your Linux distribution package manager and utilities to find out exact kerberos.schema file location.

For proper Kerberos + OpenLDAP back-end setup, see article Ubuntu.com - Kerberos with OpenLDAP backend.

Host information

hostname	IPv4 address	name on local network
`ldapserver-1`	172.20.0.8/24	ldapserver-1.mydomain.com

OpenLDAP Database configuration

NOTE: This section does not describe how to populate LDAP back-end database with Kerberos objects or attributes. See Kerberos configuration - Kerberos database generation steps for LDAP for details. For Kerberos LDAP setup, you need to use Kerberos utility kdb5_ldap_util on Kerberos KDC & Administration server.

Kerberos principal database (container) structure in LDAP database is:

Each Kerberos principal, listed on Required/recommended KDC Principals section, have LDAP entries like:

Depending on your setup, your LDAP users may have additional Kerberos attributes such as:

How do I create NFSv4 LDAP attributes, optionally needed by NFS idmapd.conf files on NFSv4 client/server?

Create new LDAP .schema files with proper attribute definitions. Include your new attributes to a proper LDAP object type (in our case: LDAP user object). Additionally, include .schema files into your OpenLDAP configuration (slapd.conf) file.

If needed, convert .schema files into .ldif format. Use schema2ldif conversion utility for it.

LDAP attributes NFSv4UserName & NFSv4GroupName, might be, for instance:

> nfsv4.schema

attributetype ( 2.16.840.1.113730.3.1.500
    NAME 'NFSv4UserName'
    DESC 'RFC2798: preferred name to be used for NFSv4 user name'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

attributetype ( 2.16.840.1.113730.3.1.501
    NAME 'NFSv4GroupName'
    DESC 'RFC2798: preferred name to be used for NFSv4 group name'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

Be aware that I don't use proper SYNTAX field values above for the new LDAP attributes.

Firewall configuration

This section does not cover A) configuration for specific firewall implementation B) advanced firewall policy.

Allowed ports for LDAP database connections are:

Default Port	Layer-4 Protocol	Application Protocol	Direction	Encryption	Required
389	TCP	ldap	Inbound	No	No, if port 636 used
636	TCP	ldaps	Inbound	Yes	No, if port 389 used

Encrypted connections are always a preferred choise if available. Refer to additional firewall manual or instructions for adding these rules. For ldaps configuration, generate proper certificate files with openssl for OpenLDAP. See man 5 ldap.conf (section TLS OPTIONS) and do proper certificate configurations for nfs-idmapd (man 5 idmapd.conf) + Kerberos configuration files and wherever LDAP connections are used.

Required Systemd process files

These Systemd processes should be run on ldapserver-1:

Systemd file	Description
`iptables.service`/`ufw.service` …	IPv4 Packet Filtering Framework/Uncomplicated firewall …
`slapd.service`	OpenLDAP server daemon

DNS server

If you use ISC BIND 9 as your DNS server, see Arch Wiki - BIND and other online documentation for proper configuration. Depending on your setup, other DNS servers can also be used, such as Microsoft DNS Server.

Host information

hostname	IPv4 address	name on local network
`dnsserver-1`	172.20.0.9/24	dnsserver-1.mydomain.com

This article assumes that you have a working DNS setup is running already where you can populate additional DNS records to.

Kerberos SRV records are not mandatory. They can be optionally be used if proper Kerberos server entries have not been defined in /etc/krb5.conf files on each Kerberos-related computer.

If you have defined dns_lookup_realm, dns_lookup_kdc or any other DNS settings instead of direct kdc, admin_server, kpasswd_server or such in your /etc/krb5.conf on all hosts, you need to define Kerberos SRV records in you DNS server zone file, as shown below. It is quite obvious these hosts must absolutely use your local DNS server configured in their /etc/resolv.conf resolver configuration file (or by systemd-resolved.service; /etc/systemd/resolved.conf).

A records (and CNAME records if you use them) are strongly recommended for a local Kerberos network environment. Set up your Kerberos computers to use your DNS server as a primary DNS server for name lookups. PTR records are not required.

Firewall configuration

This section does not cover A) configuration for specific firewall implementation B) advanced firewall policy.

Allowed ports are as follows:

Default Port	Layer-4 Protocol	Application Protocol	Direction	Encryption	Required
53	UDP	`dns`	Inbound	No	Yes, by other network hosts
53	TCP	`dns`	Inbound	No	Yes, by other network hosts`*`

* This port is usually used when packet size exceeds UDP single-packet limits.

•
Kerberos KDC & Administration server

This server uses MIT Kerberos V5 implementation.

•
Host information

hostname	IPv4 address	name on local network
`kerberosserver-1`	172.20.0.10/24	kerberosserver-1.mydomain.com

•
Kerberos compilation parameters

It is recommended MIT Kerberos packages are compiled with the following configuration parameters on the Kerberos KDC & Administration server.

•
Kerberos KDC LDAP configuration

This section covers minimal LDAP back-end settings for proper TLS certificate usage on the Kerberos KDC & Administration server.

•
Kerberos configuration

This section covers crucial configuration files required by the Kerberos KDC & Administration server.

NOTE: You must have properly configured DNS and LDAP servers now. Before proceeding, make sure you have properly configured etc/krb5.conf, /var/lib/krb5kdc/kdc.conf and related files as shown above. After having configured these files, you should restart Kerberos KDC and Administration server: sudo systemctl restart krb5-kdc krb5-kadmind

Once you have properly configured basic LDAP back-end for your Kerberos KDC & Administration server, populate the back-end database with Kerberos principal data (example command given below):

> /var/lib/krb5kdc/kdc.conf (root.root -rw-r----- 0640)
------------------------------
# See also: man 5 kdc.conf

#[kdcdefaults]

[realms]
        MYDOMAIN.COM = {

                # Default is 88
                kdc_listen = 88
                kdc_tcp_listen = 88

                # Default is 464
                kpasswd_listen = 464
                kpasswd_port = 464

                # Default is 749
                # NOTE: allow TCP 749 inbound in firewall
                # for remote Kerberos administration server (kadmin command) access
                kadmind_listen = 749
                kadmind_port = 749

                forwardable = false
                proxiable = false
                database_module = openldap_ldapconf
                acl_file = /etc/krb5kdc/kadm5.acl

                # Maximum ticket life time until ticket must be renewed
                max_life = 12h 0m 0s

                # 1 year
                max_renewable_life = 365d 0h 0m 0s

                master_key_type    = aes256-cts-hmac-sha1-96
                supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal
        }

[logging]
        kdc          = SYSLOG:NOTICE
        admin_server = SYSLOG:NOTICE
        default      = SYSLOG:NOTICE

[dbdefaults]
        ldap_kerberos_container_dn = cn=krbContainer,ou=kerberos,dc=mydomain,dc=com

[dbmodules]
        openldap_ldapconf = {
                db_library = kldap

                # If either of these is false, then the ldap_kdc_dn needs to
                # have write access
                disable_last_success = true
                disable_lockout  = true

                # This LDAP object needs to have read rights on
                # the realm container, principal container and realm sub-trees
                #
                ldap_kdc_dn = "uid=kdc-service,ou=kerberos,dc=mydomain,dc=com"

                # This LDAP object needs to have read and write rights on
                # the realm container, principal container and realm sub-trees
                #
                ldap_kadmind_dn = "uid=kadmin-service,ou=kerberos,dc=mydomain,dc=com"

                ldap_service_password_file = /etc/krb5kdc/ldap_service.keyfile
                ldap_servers = ldaps://ldapserver-1.mydomain.com/
                ldap_conns_per_server = 20

        }

•
Required/recommended KDC Principals

We use kadmin.local command to access local Kerberos Administration Server. We run it as root since the tool requires read & write access to root-owned system Kerberos keytab file /etc/krb5.keytab.

NOTE: Adding, listing, editing or deleting Kerberos principals require properly configured and fully functional Kerberos principal back-end database connection. In this article, we use a dedicated OpenLDAP server for back-end database purposes.

Additional basic information about key kadmin.local commands are given in Useful commands and hints section in this article.

•
Keytab configuration

NOTE: Kerberos KDC server uses its back-end principal database to authenticate principals offered by Kerberos clients.

•
Firewall configuration

This section does not cover A) configuration for specific firewall implementation B) advanced firewall policy.

Allowed ports are as follows:

Default Port	Layer-4 Protocol	Application Protocol	Direction	Encryption	Required
88	TCP	`kerberos`	Inbound	Yes	Yes, by NFSv4 client
464	TCP	`kpasswd`	Inbound	Yes	Optional, for remote `kpasswd` command
749	TCP	`kerberos-adm`	Inbound	Yes	Optional, for remote `kadmin` command

Encrypted connections are always a preferred choise if available. Refer to additional firewall manual or instructions for adding these rules.

•
Required Systemd processes

These Systemd processes should be run on kerberosserver-1:

Systemd file	Description
`iptables.service`/`ufw.service` …	IPv4 Packet Filtering Framework/Uncomplicated firewall …
`krb5-kdc.service`	MIT Kerberos V5 Key Distribution Center
`krb5-kadmind.service`	MIT Kerberos V5 Administration Server

•
Systemd files configuration

•
NFSv4 server

•
Host information

hostname	IPv4 address	name on local network
`nfsserver-1`	172.20.0.11/24	nfsserver-1.mydomain.com

•
NFS Utils compilation parameters

•
NFS configuration

> /etc/idmapd.conf (root.root -rw-r----- 0640)
------------------------------
# Ref: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/system_design_guide/mounting-nfs-shares_system-design-guide
#
# Only the NFSv4 server uses rpc.idmapd, which is started by the nfs-idmapd service.
# The NFSv4 client uses the keyring-based nfsidmap utility, which is called by the kernel
# on-demand to perform ID mapping. If there is a problem with nfsidmap, the client falls back to using rpc.idmapd.

# This is file is used by nfsidmap on NFSv4 clients
# and by nfs-idmapd.service (rpd.idmapd) on NFSv4 servers

# On clients, nfsidmap executable is automatically called by kernel.
# It is not a daemon.
# See also: /etc/request.key.d/, /etc/request.key.conf
# and pipefs (userspace NFS FS communication channel with kernel)

[General]

# Verbosity = 3

####################
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.

# Domain name here has nothing to do with the actual server domain or
# domain settings used in Kerberos configuration.

Domain = mydomain.com

####################
# In multi-domain environments, some NFS servers will append the identity
# management domain to the owner and owner_group in lieu of a true NFSv4
# domain.  This option can facilitate lookups in such environments.  If
# set to a value other than "none", the nsswitch  plugin will first pass
# the name to the password/group lookup function without stripping the
# domain off.  If that mapping fails then the plugin will try again using
# the old method (comparing the domain in the string to the Domain value,
# stripping it if it matches, and passing the resulting short name to the
# lookup function).  Valid values are "user", "group", "both", and
# "none".  The default is "none".
#No-Strip = none

####################
# Winbind has a quirk whereby doing a group lookup in UPN format
# (e.g. staff@americas.example.com) will cause the group to be
# displayed prefixed with the full domain in uppercase
# (e.g. AMERICAS.EXAMPLE.COM\staff) instead of in the familiar netbios
# name format (e.g. AMERICAS\staff).  Setting this option to true
# causes the name to be reformatted before passing it to the group
# lookup function in order to work around this.  This setting is
# ignored unless No-Strip is set to either "both" or "group".
# The default is "false".
#Reformat-Group = false

####################
# The following is a comma-separated list of Kerberos realm
# names that should be considered to be equivalent to the
# local realm, such that <user>@REALM.A can be assumed to
# be the same user as <user>@REALM.B
# If not specified, the default local realm is the domain name,
# which defaults to the host's DNS domain name,
# translated to upper-case.
# Note that if this value is specified, the local realm name
# must be included in the list!
Local-Realms = MYDOMAIN.COM

# Cache expiration in seconds
Cache-Expiration = 60

Pipefs-Directory = /var/lib/nfs/rpc_pipefs

[Mapping]

Nobody-User = nobody
Nobody-Group = nobody

[Translation]

####################
# Translation Method is an comma-separated, ordered list of
# translation methods that can be used.  Distributed methods
# include "nsswitch", "umich_ldap", and "static".  Each method
# is a dynamically loadable plugin library.
# New methods may be defined and inserted in the list.
# The default is "nsswitch".
#
# sss method requires sssd.service daemon and proper SSSD configuration
# on this host.
#
Method = nsswitch,static

####################
# NOTE: Enable for Kerberos v5
# Optional.  This is a comma-separated, ordered list of
# translation methods to be used for translating GSS
# authenticated names to ids.
# If this option is omitted, the same methods as those
# specified in "Method" are used.
#
# sss method requires sssd.service daemon and proper SSSD configuration
# on this host.
#
GSS-Methods = nsswitch,static

#-------------------------------------------------------------------#
# The following are used only for the "static" Translation Method.
#-------------------------------------------------------------------#
[Static]

# A "static" list of GSS-Authenticated names to
# local user name mappings

#someuser@REALM = localuser

#-------------------------------------------------------------------#
# The following are used only for the "umich_ldap" Translation Method.
#-------------------------------------------------------------------#

[UMICH_SCHEMA]

# server information (REQUIRED)
LDAP_server  = ldapserver-1.mydomain.com

# 389 for ldap, 636 for ldaps
#LDAP_port    = 636

# the default search base (REQUIRED)
LDAP_base    = ou=<my-ldap-users>,dc=mydomain,dc=com

LDAP_user_dn = uid=<my-ldap-privileged-bind-user (with read access to people & group bases)>,dc=mydomain,dc=com
LDAP_passwd  = <ldap-bind-user-password-in-ldap-database>

#-----------------------------------------------------------#
# The remaining options have defaults (as shown)
# and are therefore not required.
#-----------------------------------------------------------#

# whether or not to perform canonicalization on the
# name given as LDAP_server
#LDAP_canonicalize_name = true

# absolute search base for (people) accounts
LDAP_people_base = ou=<my-nfsv4-ldap-users-container>,dc=mydomain,dc=com

# absolute search base for groups
LDAP_group_base  = ou=<my-nfsv4-ldap-users-container>,dc=mydomain,dc=com

# Whether to follow ldap referrals
LDAP_follow_referrals = true

# Set to true to enable SSL - anything else is not enabled
#LDAP_use_ssl = true

# Controls the LDAP server certificate validation behavior
# It can take the same values as ldap.conf(5)'s TLS_REQCERT
# tunable
#LDAP_tls_reqcert = "hard"

# Location of CA certificate, mandatory if LDAP_tls_reqcert
# is not set to "never"
#LDAP_ca_cert = <path-to ldap.cert.pem>

# SASL mechanism to use while binding to LDAP
#LDAP_sasl_mech = <SASL mech>

# SASL realm to be used for SASL auth
#LDAP_sasl_realm = <SASL realm>

# Authentication identity to be used for SASL auth
#LDAP_sasl_authcid = <SASL authcid>

# Authorization identity for SASL auth
#LDAP_sasl_authzid = <SASL authzid>

# Cyrus SASL security properties
#LDAP_sasl_secprops = <secprops>

# Specifies whether the LDAP server hostname should be canonicalised.
# If set to yes LDAP lib with do a reverse hostname lookup.
# If this is not set the LDAP library's default will be used.
#LDAP_sasl_canonicalize <yes | no>

# Specifies the kerberos ticket cache to be used
#LDAP_sasl_krb5_ccname = <kerberos ticket cache>

# Objectclass mapping information

# Mapping for the person (account) object class
NFSv4_person_objectclass = inetOrgPerson

# Mapping for the nfsv4name attribute the person object (Your Linux LDAP user)
NFSv4_name_attr = <my-ldap-attribute-for-nfsv4-username. Example: NFSv4UserName>

# Mapping for the UID number
NFSv4_uid_attr = uidNumber

# Mapping for the GSSAPI Principal name
GSS_principal_attr = krbPrincipalName

# Mapping for the account name attribute (usually uid)
# The value for this attribute must match the value of
# the group member attribute - NFSv4_member_attr
NFSv4_acctname_attr = uid

# Mapping for the group object class
NFSv4_group_objectclass = posixGroup

# Mapping for the GID attribute
NFSv4_gid_attr = gidNumber

# Mapping for LDAP user's Group NFSv4 name
NFSv4_group_attr = <my-ldap-attribute-for-nfsv4-group. Example: NFSv4GroupName>

# Mapping for the Group member attribute (usually memberUID)
# The value of this attribute must match the value of NFSv4_acctname_attr
NFSv4_member_attr = memberUid

•
GSSProxy configuration

•
Kerberos configuration

> /etc/krb5.conf (root.root -rw------- 0600)
------------------------------
# This NFSv4 server never directly talks to Kerberos KDC server. Therefore, we do not define kdc or any other Kerberos servers here.
#
# This file is mainly used to A) define default REALM and B) how to convert principal names so that our NFSv4 server can understand how
# to deal with them when it determines to which local user a requested principal belongs to.
#
# Keytab file(s) on this server is used only by GSSProxy service which talks to GGSProxy & RPC-GSSD on NFSv4 clients.
# The clients talk directly to KDC.
#
# As explained on Stack Overflow:
# A service that uses Kerberos for authentication NEVER talks to the KDC.
# All it ever does is use its secret key (keytab) to decrypt blobs that are presented by the user.
# This is done by GSSProxy service on this computer.

[libdefaults]
        default_realm = MYDOMAIN.COM

[realms]
        MYDOMAIN.COM = {

                # GSS-API (GSSProxy; Kerberos) principal & NFSv4/Unix UID translation on NFSv4 server
                #
                # NOTE: This is required on NFS server when GSSProxy service is used. We need to tell
                # NFS server to map users such as foo/admin@MYDOMAIN.COM to local user foo, so we strip
                # of admin part from the Kerberos principal.
                # Without this configuration, users are likely to be mapped to nobody, i.e. NFS server
                # doesn't know who is the user it should provide access to network shares.
                # This configuration is used on KDC as well, but not required on NFS client /etc/krb5.conf file.
                #
                # See also:
                #
                # https://docs.oracle.com/cd/E19120-01/open.solaris/819-3321/ezlsz/index.html
                # https://docs.oracle.com/cd/E19120-01/open.solaris/819-3321/fabaf/index.html
                # https://docs.oracle.com/cd/E19120-01/open.solaris/819-3321/setup-148/index.html
                # https://docs.oracle.com/cd/E19120-01/open.solaris/819-3321/setup-97/index.html
                #
                # Principals such as 'foo/admin@MYDOMAIN.COM' where 'foo' is a local user
                auth_to_local   = RULE:[2:$1;$2](^.*;admin$)s/;admin$//

                # Principals such as 'foo/systemuser@MYDOMAIN.COM' where 'foo' is a local user
                auth_to_local   = RULE:[2:$1;$2](^.*;systemuser$)s/;systemuser$//

                # Principals such as 'foo@MYDOMAIN.COM' where 'foo' is a local user
                auth_to_local   = DEFAULT
        }

•
Firewall configuration

This section does not cover A) configuration for specific firewall implementation B) advanced firewall policy.

Allowed ports are as follows:

Default Port	Layer-4 Protocol	Application Protocol	Direction	Encryption	Required
2049	TCP	`nfs`	Inbound	No`*`	Yes, by NFSv4 client

* Unless Kerberos encryption scheme used, as explained in this article.

Encrypted connections are always a preferred choise if available. Refer to additional firewall manual or instructions for adding these rules.

•
Keytab configuration

•
Required Systemd processes

These Systemd processes should be run on nfsserver-1:

Systemd file	Description
`iptables.service`/`ufw.service` …	IPv4 Packet Filtering Framework/Uncomplicated firewall …
`auth-rpcgss-module.service`	Kernel Module supporting RPCSEC_GSS
`gssproxy.service`	GSSAPI Proxy Daemon
`proc-fs-nfsd.mount`	NFSD configuration filesystem
`nfs-idmapd.service`	NFSv4 ID-name mapping service
`nfs-mountd.service`	NFS Mount Daemon
`nfsdcld.service`	NFSv4 Client Tracking Daemon
`nfs-server.service`	NFS server and services
`nslcd.service` OR `sssd.service`	Naming services LDAP client daemon // System Security Services Daemon

•
Systemd files configuration

•
Miscellaneous

•
NFSv4 client

•
Host information

hostname	IPv4 address	name on local network
`nfsclient-1`	172.20.0.20/24	nfsclient-1.mydomain.com

•
NFS Utils compilation parameters

•
NFS configuration

> /etc/idmapd.conf (root.root -rw-r----- 0640)
------------------------------
# Ref: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/system_design_guide/mounting-nfs-shares_system-design-guide

# Only the NFSv4 server uses rpc.idmapd, which is started by the nfs-idmapd service.
# The NFSv4 client uses the keyring-based nfsidmap utility, which is called by the kernel
# on-demand to perform ID mapping. If there is a problem with nfsidmap, the client falls back to using rpc.idmapd.

# This is file is used by nfsidmap on NFSv4 clients
# and by nfs-idmapd.service (rpd.idmapd) on NFSv4 servers

# On clients, nfsidmap executable is automatically called by kernel.
# It is not a daemon.
# See also: /etc/request.key.d/, /etc/request.key.conf
# and pipefs (userspace NFS FS communication channel with kernel)

[General]

# Verbosity = 3

####################
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.

# Domain name here has nothing to do with the actual server domain or
# domain settings used in Kerberos configuration.

Domain = mydomain.com

####################
# In multi-domain environments, some NFS servers will append the identity
# management domain to the owner and owner_group in lieu of a true NFSv4
# domain.  This option can facilitate lookups in such environments.  If
# set to a value other than "none", the nsswitch  plugin will first pass
# the name to the password/group lookup function without stripping the
# domain off.  If that mapping fails then the plugin will try again using
# the old method (comparing the domain in the string to the Domain value,
# stripping it if it matches, and passing the resulting short name to the
# lookup function).  Valid values are "user", "group", "both", and
# "none".  The default is "none".
#No-Strip = none

####################
# Winbind has a quirk whereby doing a group lookup in UPN format
# (e.g. staff@americas.example.com) will cause the group to be
# displayed prefixed with the full domain in uppercase
# (e.g. AMERICAS.EXAMPLE.COM\staff) instead of in the familiar netbios
# name format (e.g. AMERICAS\staff).  Setting this option to true
# causes the name to be reformatted before passing it to the group
# lookup function in order to work around this.  This setting is
# ignored unless No-Strip is set to either "both" or "group".
# The default is "false".
#Reformat-Group = false

####################
# The following is a comma-separated list of Kerberos realm
# names that should be considered to be equivalent to the
# local realm, such that <user>@REALM.A can be assumed to
# be the same user as <user>@REALM.B
# If not specified, the default local realm is the domain name,
# which defaults to the host's DNS domain name,
# translated to upper-case.
# Note that if this value is specified, the local realm name
# must be included in the list!
Local-Realms = MYDOMAIN.COM

# Cache expiration in seconds
Cache-Expiration = 60

Pipefs-Directory = /var/lib/nfs/rpc_pipefs

[Mapping]

Nobody-User = nobody
Nobody-Group = nobody

[Translation]

####################
# Translation Method is an comma-separated, ordered list of
# translation methods that can be used.  Distributed methods
# include "nsswitch", "umich_ldap", and "static".  Each method
# is a dynamically loadable plugin library.
# New methods may be defined and inserted in the list.
# The default is "nsswitch".

# sss method requires sssd.service daemon and proper SSSD configuration
# on this host.

Method = nsswitch,static

####################
# NOTE: Enable for Kerberos v5
# Optional.  This is a comma-separated, ordered list of
# translation methods to be used for translating GSS
# authenticated names to ids.
# If this option is omitted, the same methods as those
# specified in "Method" are used.

# sss method requires sssd.service daemon and proper SSSD configuration
# on this host.

GSS-Methods = nsswitch,static

#-------------------------------------------------------------------#
# The following are used only for the "static" Translation Method.
#-------------------------------------------------------------------#
[Static]

# A "static" list of GSS-Authenticated names to
# local user name mappings

#someuser@REALM = localuser

#-------------------------------------------------------------------#
# The following are used only for the "umich_ldap" Translation Method.
#-------------------------------------------------------------------#

[UMICH_SCHEMA]

# server information (REQUIRED)
LDAP_server  = ldapserver-1.mydomain.com

# 389 for ldap, 636 for ldaps
#LDAP_port    = 636

# the default search base (REQUIRED)
LDAP_base    = ou=<my-ldap-users>,dc=mydomain,dc=com

LDAP_user_dn = uid=<my-ldap-privileged-bind-user (with read access to people & group bases)>,dc=mydomain,dc=com
LDAP_passwd  = <ldap-bind-user-password-in-ldap-database>

#-----------------------------------------------------------#
# The remaining options have defaults (as shown)
# and are therefore not required.
#-----------------------------------------------------------#

# whether or not to perform canonicalization on the
# name given as LDAP_server
#LDAP_canonicalize_name = true

# absolute search base for (people) accounts
LDAP_people_base = ou=<my-nfsv4-ldap-users-container>,dc=mydomain,dc=com

# absolute search base for groups
LDAP_group_base  = ou=<my-nfsv4-ldap-users-container>,dc=mydomain,dc=com

# Whether to follow ldap referrals
LDAP_follow_referrals = true

# Set to true to enable SSL - anything else is not enabled
#LDAP_use_ssl = true

# Controls the LDAP server certificate validation behavior
# It can take the same values as ldap.conf(5)'s TLS_REQCERT
# tunable
#LDAP_tls_reqcert = "hard"

# Location of CA certificate, mandatory if LDAP_tls_reqcert
# is not set to "never"
#LDAP_ca_cert = <path-to ldap.cert.pem>

# SASL mechanism to use while binding to LDAP
#LDAP_sasl_mech = <SASL mech>

# SASL realm to be used for SASL auth
#LDAP_sasl_realm = <SASL realm>

# Authentication identity to be used for SASL auth
#LDAP_sasl_authcid = <SASL authcid>

# Authorization identity for SASL auth
#LDAP_sasl_authzid = <SASL authzid>

# Cyrus SASL security properties
#LDAP_sasl_secprops = <secprops>

# Specifies whether the LDAP server hostname should be canonicalised.
# If set to yes LDAP lib with do a reverse hostname lookup.
# If this is not set the LDAP library's default will be used.
#LDAP_sasl_canonicalize <yes | no>

# Specifies the kerberos ticket cache to be used
#LDAP_sasl_krb5_ccname = <kerberos ticket cache>

# Objectclass mapping information

# Mapping for the person (account) object class
NFSv4_person_objectclass = inetOrgPerson

# Mapping for the nfsv4name attribute the person object (Your Linux LDAP user)
NFSv4_name_attr = <my-ldap-attribute-for-nfsv4-username. Example: NFSv4UserName>

# Mapping for the UID number
NFSv4_uid_attr = uidNumber

# Mapping for the GSSAPI Principal name
GSS_principal_attr = krbPrincipalName

# Mapping for the account name attribute (usually uid)
# The value for this attribute must match the value of
# the group member attribute - NFSv4_member_attr
NFSv4_acctname_attr = uid

# Mapping for the group object class
NFSv4_group_objectclass = posixGroup

# Mapping for the GID attribute
NFSv4_gid_attr = gidNumber

# Mapping for LDAP user's Group NFSv4 name
NFSv4_group_attr = <my-ldap-attribute-for-nfsv4-group. Example: NFSv4GroupName>

# Mapping for the Group member attribute (usually memberUID)
# The value of this attribute must match the value of NFSv4_acctname_attr
NFSv4_member_attr = memberUid

> /etc/hosts (optional)
------------------------------
172.20.0.10 kerberosserver-1.mydomain.com
172.20.0.11 nfsserver-1.mydomain.com

•
GSSProxy configuration

> /etc/gssproxy/99-nfs-client.conf (root.root -rw-r--r-- 0644)
------------------------------
[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/tmp/gssproxy/clients/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%u.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0

For entry details, see Pagure.io - GSSProxy (NFS) and man 5 gssproxy.conf

How does this all work?

According to my testing, GSSProxy requests user Kerberos principal only and only when user exciplitly asks permission to access Kerberos-protected NFSv4 shares. At that time, GSSProxy uses Kerberos user keytab file, defined by variable cred_store = client_keytab:/ ... %U.keytab entry. GSSProxy obtains a Kerberos session ticket for the user, and stores it as a user-specific ticket cache file, known as credentials cache (ccache). Path of this cache file is defined by cred_store = ccache:FILE: ... krb5cc_%U entry.

Distinguish ccache location

Due to how GSSProxy works internally, it is essential that GSSProxy's credential cache (ccache) path does not directly point to the same ticket cache location as defined in client's Kerberos /etc/krb5.conf file by variable default_ccache_name (if not defined, the default Kerberos ticket cache location is /tmp/).

You are still able to use subfolders such as /tmp/gssproxy/... for GSSProxy's ccache, but not the exact default_ccache_name path. Reason for this is: when you boot a NFS client computer, your NFSv4 shares may be defined to be auto-mounted in /etc/fstab (I assume: as root user). GSSProxy generates two credential cache files: one for itself, and one for actual user NFS access request. Now, if you access NFSv4 shares as root user, you may encounter weird issues as shown below.

For instance, if GSSProxy's ccache path (on Kerberos-configured NFSv4 client) points to /tmp/gssproxy/clients/, then the files being generated for root user are as follows:

> klist -c /tmp/krb5cc_0:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/nfsclient-1.mydomain.com@MYDOMAIN.COM

Valid starting     Expires            Service principal
01/01/70 02:00:00  01/01/70 02:00:00  Encrypted/Credentials/v1@X-GSSPROXY:

> klist -c /tmp/gssproxy/clients/krb5cc_0:

Ticket cache: FILE:/tmp/gssproxy/clients/krb5cc_0
Default principal: host/nfsclient-1.mydomain.com@MYDOMAIN.COM

Valid starting     Expires            Service principal
02/05/21 10:26:39  02/05/21 22:26:39  krbtgt/MYDOMAIN.COM@MYDOMAIN.COM
02/05/21 10:26:40  02/05/21 22:26:39  nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM

These files are automatically generated when mount access to NFSv4 shares is requested by a user with UID 0. If same ticket cache paths used, they overlap, and as a consequence, these temporary cache files would overwrite each other, ultimately leading to NFSv4 access permission denials and weird issues.

I hope this makes you understand why it is crucial to use a non-default Kerberos ticket cache path for GSSProxy.

> /etc/tmpfiles.d/gssproxy.conf (root.root -rw-r--r-- 0644)
------------------------------
d /tmp/gssproxy/clients/ 0755 root root - -

NOTE: systemd-tmpfiles-setup.service must be enabled for tmpfiles.d contents to take effect on a host! Usually it is enabled by default.

•
Kerberos configuration

•
Firewall configuration

This section does not cover A) configuration for specific firewall implementation B) advanced firewall policy.

Allowed ports are as follows:

Default Port	Layer-4 Protocol	Application Protocol	Direction	Encryption	Required
88	TCP	`kerberos`	Outbound	Yes	Yes, by Kerberos KDC
2049	TCP	`nfs`	Outbound	No`*`	Yes, by NFSv4 server

* Unless Kerberos encryption scheme used, as explained in this article.

Encrypted connections are always a preferred choise if available. Refer to additional firewall manual or instructions for adding these rules.

•
Keytab configuration

•
Required Systemd processes

These Systemd processes should be run on nfsclient-1:

Systemd file	Description
`iptables.service`/`ufw.service` …	IPv4 Packet Filtering Framework/Uncomplicated firewall …
`auth-rpcgss-module.service`	Kernel Module supporting RPCSEC_GSS
`gssproxy.service`	GSSAPI Proxy Daemon (optional)
`rpc-gssd.service`	RPC security service for NFS client
`nslcd.service` OR `sssd.service`	Naming services LDAP client daemon // System Security Services Daemon
`nfs-client.target`	NFS client services

•
Systemd files configuration

•
Miscellaneous

Useful commands and hints

Foreword

Use secure methologies when you are doing something with keytab files. For instance, transferring keytab files via network must be done either with scp command or with a secure, remote access to Kerberos Administration server (Kerberos clients: command kadmin, when kdc is defined in client's /etc/krb5.conf file).

Kerberos principals

kadmin.local command is used on Kerberos KDC & Administration server.

kadmin command is used on any non-KDC host that has /etc/krb5.conf with proper kdc configuration (or alternative, you have defined KDC in your DNS server's SRV records).

When adding keytab entries on a non-KDC host, it may be recommended to use kadmin command if your firewall and security policy allows it. kadmin is more convinient than using kadmin.local but less secure than transferring generated keytab entries directly from KDC to another host via a secured connection.

In the examples below, kadmin.local command is used. If executed on a non-KDC host, use kadmin instead.

Generating principals

Service/computer principal (no password) example:

> sudo kadmin.local
kadmin.local: addprinc -randkey host/nfsclient-1@MYDOMAIN.COM

User principal (with password) example:

> sudo kadmin.local
kadmin.local: addprinc defaultuser/admin@MYDOMAIN.COM
No policy specified for defaultuser/admin@MYDOMAIN.COM; defaulting to no policy
Enter password for principal "defaultuser/admin@MYDOMAIN.COM":

Keys generated by these commands reflect your settings in Kerberos configuration files.

Adding principals to /etc/krb5.keytab on current host

> sudo kadmin.local
kadmin.local: delprinc defaultuser/admin@MYDOMAIN.COM

Additional Kerberos Administration Server commands

See:

> sudo kadmin.local
kadmin.local: ?

Requesting a new ticket and access to the NFSv4 service

Requesting a TGT is the first step you need as a user when attempting to access Kerberos protected NFSv4 volume on a NFSv4 client.

You request TGT as and for the current user, so do not use sudo with kinit command. The same rule applies when you destroy your current Kerberos session ticket with command kdestroy. You request the TGT for your current Linux LDAP user.

For instance, requesting TGT as logged in LDAP user defaultuser on a properly configured Kerberos client (both NFSv4 server & client are Kerberos clients in our case) could be done as follows:

[defaultuser@nfsclient-1] kinit -V -S nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM defaultuser/admin@MYDOMAIN.COM
Using default cache: /tmp/krb5cc_1000
Using principal: defaultuser/admin@MYDOMAIN.COM
Password for defaultuser/admin@MYDOMAIN.COM:
Authenticated to Kerberos v5

where

defaultuser/admin@MYDOMAIN.COM refers to Kerberos principal defaultuser/admin@MYDOMAIN.COM
nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM refers to NFSv4 service principal we are requesting with parameter -S for defaultuser/admin@MYDOMAIN.COM
Both user & service principals exist and are stored on your Kerberos KDC server.
Additionally, your LDAP server database user ldapuser must have previously explained Kerberos LDAP attributes defined in its LDAP user object.
Password is a password for your user principal you have defined with Kerberos Administrative Server tool kadmin or kadmin.local.

Issue: Password incorrect while getting initial credentials

Although you have supplied proper credentials, you may still get this message on a Kerberos client.

kinit: Password incorrect while getting initial credentials

Occasionally, I have had this issue and resolved it by resetting the password for this specific principal in Kerberos Administrative Server tool kadmin / kadmin.local. So, reset the password for user principal defaultuser/admin@MYDOMAIN.COM and try again.

> sudo kadmin.local
kadmin.local: change_password defaultuser/admin@MYDOMAIN.COM
Enter password for principal defaultuser/admin@MYDOMAIN.COM:
Re-enter password for principal defaultuser/admin@MYDOMAIN.COM:
Password for defaultuser/admin@MYDOMAIN.COM changed.
kadmin.local:

From Kerberos kadmin documentation: This command requires the changepw privilege, or that the principal running the program is the same as the principal being changed.

Root cause of this issue can be a corrupted file or Kerberos principal data, although I may be wrong.

Ticket cache location on a Kerberos client

Once you have successfully received a session ticket from your Kerberos KDC, it is stored in a cache folder on the Kerberos client computer. It is /tmp by default. This folder acts as your client's Kerberos ticket cache. The default ticket name syntax is krb5cc_<UID> for an user. Machine tickets are stored in the same manner with file name syntax krb5ccmachine_MYDOMAIN.COM.

Custom ticket cache location

To use a custom ticket cache location on a Kerberos client, configure Kerberos client configuration file /etc/krb5.conf:

[libdefaults]
  default_ccache_name = FILE:/tmp/krb5cc_%{uid}

For proper details, see: man 5 krb5.conf

Your software may also implement a variable which defines Kerberos ticket cache location on a Kerberos client for this specific software.

GSSProxy:

Custom ticket cache location for GSSProxy on NFSv4 server & client is defined in a configuration file /etc/gssproxy/*.conf by variable cred_store = ccache:FILE:<folder>/krb5cc_%U

You may change %U (user ID) variable to %u (user name) for your needs
- See also: man 5 gssproxy.conf

How do I view my Kerberos ticket content?

For current user, just use klist command.

On a properly configured NFSv4 computer which uses gssproxy.service and defines Kerberos ticket cache location as shown above, sample ticket cache file content (with NFSv4 service) for LDAP Linux user with UID 1000 could be as follows:

[ldapuser@nfsclient-1] klist -c /tmp/gssproxy/clients/krb5cc_1000

Ticket cache: FILE:/tmp/gssproxy/clients/krb5cc_1000
Default principal: host/nfsclient-1@MYDOMAIN.COM

Valid starting     Expires            Service principal
02/05/21 10:26:39  02/05/21 22:26:39  krbtgt/MYDOMAIN.COM@MYDOMAIN.COM
02/05/21 10:26:40  02/05/21 22:26:39  nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM

Ticket renewal

A simple command to renew a Kerberos ticket for current user:

kinit -R

More complex renewal requests can also be made, like:

kinit -V -R -S nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM ldapuser/systemuser@MYDOMAIN.COM

NOTE: Renewal is usually not needed if you use sssd.service or GSSProxy with auto-renewal configuration.

Be aware that renewal has time limit dictated by your Kerberos KDC server after which user must request a new, fresh session (TGT) ticket.

Deleting my current Kerberos ticket cache

Simply issue command

kdestroy

as the current user.

Adding keytab principal entries on Kerberos clients

Basically, we talk about both NFSv4 server and NFSv4 client which both have also a Kerberos client role. This method is useful in situations where

Kerberos Administation Server can not be accessed with Kerberos client command kadmin, i.e. the Administation Server has local access only.
You can obtain required KVNO number and symmetric key data from Kerberos KDC.

These commands are meant to be run on Kerberos clients. They modify existing keytabs in-place.

Systems & services: with known KVNO number and a symmetric key

This section describes a situation where Kerberos administrator wants to add new entry to a keytab file with known principal name, KVNO number, encryption type and encryption key.

> sudo ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: addent -k <kvno_number> -p <my_principal> -key -e <encryption_type>
> Key for <my_principal> (hex): <hex_number_without_0x_prefix>
ktutil: wkt /tmp/krb5.keytab
ktutil: exit
> mv /tmp/krb5.keytab /etc/krb5.keytab
> ls -l /etc/krb5.keytab
-rw------- 1 root root 646 Feb  4 22:04 /etc/krb5.keytab

where

Parameter	Description
`<kvno_number>`	KVNO number in referring keytab file (for instance, an entry in KDC server `/etc/krb5.keytab` file)
`<my_principal>`	Principal in referring keytab file (for instance, an entry in KDC server `/etc/krb5.keytab` file)
`<encryption_type>`	Principal encryption type in referring keytab file (for instance, an entry in KDC server `/etc/krb5.keytab` file). Use `addent` ktutil command for each encryption type, if multiple entries defined for a principal.

Example:

...
ktutil: addent -k 3 -p nfs/nfsclient-1@MYDOMAIN.COM -key -e aes256-cts-hmac-sha1-96
> Key for <my_principal> (hex): b064c4ac8562e27587ec15ed583d53ca62697984ff7d0661b71ece12cc478ea7

ktutil: addent -k 3 -p nfs/nfsclient-1@MYDOMAIN.COM -key -e aes128-cts-hmac-sha1-96
> Key for <my_principal> (hex): 68f27b9fd818cd30659fbb2de12aa56f
...

Passwordless non-interactive user authentication

…by using known KVNO number and password for principal.

Adding user principal with a supplied password to a keytab file is very useful if you need to request a ticket granting ticket (TGT) from Kerberos KDC without an interactive password prompt each time you type kinit command.

However, when requesting TGT, shell command should have syntax kinit userwithnopasswordprompt/users@MYDOMAIN.com (with additional parameters you prefer).

Automatic authentication is useful for user scripts and for other automation purposes where access to services is wanted without any user interaction.

> sudo ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: addent -k <kvno_number> -p <my_principal> -password -e <encryption_type>
> Password for <my_principal>: [enter your password]
ktutil: wkt /tmp/krb5.keytab
ktutil: exit
> mv /tmp/krb5.keytab /etc/krb5.keytab
> ls -l /etc/krb5.keytab
-rw------- 1 root root 646 Feb  4 22:04 /etc/krb5.keytab

Example:

ktutil: addent -k 4 -p userwithnopasswordprompt/users@MYDOMAIN.com -password -e aes256-cts-hmac-sha1-96

You don't need this principal entry in KDC's /etc/krb5.keytab file.

Use a proper keytab file for your needs.

Other ktutil commands with descriptions

See

> sudo ktutil
ktutil: ?

Troubleshooting

Foreword

If you encounter issues during configuration, always refer to your server logs, online documentation and as the last straw, sites such as Serverfault.com and Unix.Stackexchange.com. As I said earlier, even logs may not give you enough information so it is important you understand Kerberos basics such as ticket renewal times, symmetric key encryption, how to check current user service ticket and so on. Understanding these and your Kerberos infrastructure in general helps you out when you are debugging any Kerberos/NFSv4 issues.

For common Kerberos issues, see Kerberos Administration Guide - Release 1.19 - MIT, section TROUBLESHOOTING.

The following sections explain most common NFSv4 + Kerberos related issues.

Permission denied when mounting a Kerberos secured volume

mount.nfs: trying text-based options 'sec=krb5p,timeo=900,retrans=5,vers=4.2,addr=172.20.0.11,clientaddr=172.20.0.20'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'sec=krb5p,timeo=900,retrans=5,vers=4,minorversion=1,addr=172.20.0.11,clientaddr=172.20.0.20'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'sec=krb5p,timeo=900,retrans=5,vers=4,addr=172.20.0.11,clientaddr=172.20.0.20'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting nfsserver-1.mydomain.com:/srv/nfs_sec/

Looks familiar? Some hints:

Check keytab entry KVNOs and symmetric keys match on Kerberos KDC & Administration server and on NFSv4 computers clients + server keytab file contents.
Have you requested a ticket granting ticket (kinit)?
Remember, Kerberos has extremely strict policy to time fluctuations. So, on each kerberized computer, check output of date command. To set correct time, enable NTP client service (Systemd: timedatectl (SNTP), ntp, openNTPD, chrony or other ntp client daemon). You can manually set time with command syntax sudo date --set='8 JAN 2021 22:44:12'

There is something odd I have noticed about KVNOs: kvno number listed in the keytab file may not be the actual KVNO Kerberos uses. I have encountered this issue at least once. Reason for this behavior is unknown, likely a bug in the implementation or some underlying feature I am not aware of. To get the actual KVNO number, do the following on a Kerberos client:

kvno -k /etc/krb5.keytab nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM

On the NFSv4 server & client, check output of gssproxy.service process. Do you see any error messages?

sudo journalctl -xe -u gssproxy.service

cannot access XX: Key expired or cannot open directory: Key has expired

Very common and simple issue. You need to either renew your Kerberos service ticket or request it in the first place with command kinit. You can destroy current Kerberos session ticket with kdestroy command.

Permission denied on already mounted NFSv4 volume

You may encounter this issue if you do not have a Kerberos session ticket (TGT) for the current user. This session ticket must have service principal entry for the NFSv4 service (for instance: nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM). Simply request a TGT with kinit command and ensure the ticket does have NFSv4 service, as shown in How do I view my Kerberos ticket content? section.

How to recover from mount failures

At first, attempt sudo mount -a. As an additional and controversial note, after a failed mount operation, it may be necessary to restart rpc-gssd.service on NFSv4 client, as further mount requests may not be passed correctly to the NFSv4 server.

Common debugging

Linux kernel RPC calls

Basically, we enable RPC debugging with rpcdebug command, as shown below. This is useful for debugging NFSv4 server and NFSv4 client.

> for i in nfs nfsd rpc; do sudo rpcdebug -m $i -s all; done
> sudo journalctl -f

Disabling RPC debugging can be done as follows:

> for i in nfs nfsd rpc; do sudo rpcdebug -m $i -c; done

FAQ

How does Kerberos work?

The basic principle is as shown in the following picture.

Kerberos authentication & authorization process (Kerberos logo by MIT)

IMAGE: Pekka Helenius

NOTE: Be aware there are different terms used, depending on the online source material you refer to. Additionally, different articles explain the process in varying detail.

NOTE: If this text gives you headaches, you find alternative articles below.

NOTE: Be aware that the following text reflects my best understanding of the subject. Please let me know if there is any misleading information. Thanks!

By executing kinit on a Kerberos client, there happens a lot of stuff under hood.

In the following example…

Kerberos realm is MYDOMAIN.COM
user principal defaultuser/admin@MYDOMAIN.COM is used on nfsclient-1.mydomain.com
NFSv4 client & Kerberos client computer is nfsclient-1.mydomain.com
- principal reference: host/nfsclient-1@MYDOMAIN.COM
  - has this principal in a local krb5.keytab file
NFSv4 server software is installed on nfsserver-1.mydomain.com which is in the role of a Kerberos client and NFSv4 server
- service principal reference: nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM
  - has this principal in a local krb5.keytab file
Kerberos server software is installed on kerberosserver-1.mydomain.com
- no principals in a local krb5.keytab file
- has all mentioned principals in a Kerberos OpenLDAP back-end database on OpenLDAP server ldapserver-1.mydomain.com
DNS name resolution & NTP time synchronization must work for these kerberized hosts. DNS & NTP services must be accessible. DNS queries must give valid answers to the kerberized hosts. DNS server must have valid A & PTR record entries for kerberized hosts (forward & reverse lookup zones).

The process

Computer & user authentication:

We do a Kerberos authentication request. The client computer sends the user principal name (defaultuser/admin@MYDOMAIN.COM) to Kerberos server's AS component (Authentication Service) without encryption.

At first, the Kerberos server's AS component checks if the user principal name is found in the Kerberos server's back-end database. If found, the Kerberos server's AS component generates a one-way hash by hashing password for the found user principal. The client computer's principal (host/nfsclient-1@MYDOMAIN.COM) is also validated.

The Kerberos server's AS component then sends a generated server session key (already encrypted with a new secret) and Ticket Granting Ticket (TGT) to the client computer. The Ticket Granting Ticket is encrypted with a secret key of Kerberos server's TGS (Ticket Granting Service) component, unknown to any other parties, including the client computer & NFSv4 server computer.

The client must decrypt the session key with its own secret in order to authenticate against the Kerberos AS component. After successful decryption, the client is authenticated. The server session key is used for further communication with the Kerberos server's TGS component.

The server session key & Ticket Granting Ticket data contents are as follows:

Message	client computer session key	Ticket Granting Ticket
Data	timestamp	client computer ID
	key data	client computer network (IP) address
		ticket lifetime (validity period)
		server session key data

Authorization to the service:

When requesting permission to use a Kerberos protected service, the client computer sends the encrypted Ticket Granting Ticket along with the service's ID (nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM) to the Kerberos server's TGS component.

The client computer also sends a client authenticator message, encrypted with the server session key it received earlier from The Kerberos server's AS component.

client authenticator message data contents are as follows:

Message	client authenticator message
Data	timestamp
	client ID

Kerberos server's TGS component decrypts the received Ticket Granting Ticket data with its own TGS secret key.

As the decrypted Ticket Granting Ticket data includes the client ID and the client computer session key, the Kerberos server's TGS component is able to decrypt the received client authenticator message and furthermore compares if the two client IDs match: one within the client authenticator message and one within the decrypted TGT data. This way the Kerberos server's TGS component can also validate the client in addition to AS.

If the client IDs match, the Kerberos server's TGS component sends a service session key and a service ticket to the client. The service ticket is encrypted with a service's secret key, used by the service principal (nfs/nfsserver-1.mydomain.com@MYDOMAIN.COM).

service ticket data contents are as follows:

Message	service ticket
Data	client ID
	client computer network (IP) address
	ticket lifetime (validity period)
	service session key data

Once the NFSv4/Kerberos client has received the encrypted service ticket and the service session key from the Kerberos server's TGS component, it authenticates itself to the service (SS; Service Server), our NFSv4 server. The service is NFSv4 server in our case, and the Service Server is our NFSv4 server.

The client sends a new service authenticator message (which is encrypted with the service session key) and the service ticket (which is encrypted with service's secret key) to the Service Server.

service authenticator message data contents are as follows:

Message	service authenticator message
Data	timestamp
	client ID

The Service Server uses its own secret key to decrypt the received service ticket in order to extract service session key from it. After that, the Service Server decrypts the service authenticator message with the extracted service session key data.

The Service Server checks whether client IDs obtained from the service ticket and the service authenticator message match each other. If they do, the Service Server sends timestamp found in client's authenticator message in an encrypted form back to the client. The timestamp is encrypted with the service session key.

As the client receives the encrypted timestamp from the Service Server, it decrypts it with the service session key it already has obtained earlier. The client computer validates the timestamp. If the validation passes, the client can trust the Service Server and therefore, can finally start further communication with the Service Server.

Sources:

Kerberos: recommended documentation, insights and advanced configuration

For common Kerberos configuration, I strongly recommend the following documentation and man pages such as man 5 krb5.conf, man 5 kdc.conf and man 5 gssproxy.conf. It gives you far better understanding of Kerberos and helps you improve your skills further on. Also check out:

Relation between krb5.conf and kdc.conf

On any Kerberos KDC on a domain, krb5.conf and kdc.conf will be merged into a single configuration profile (on Kerberos KDC server).

Although you can use duplicate settings for some settings (such as ticket life times) in both files, I strongly encourage using only a single place where you define something. It keeps your configuration clean, simple and organized.

Obviously, kdc.conf does not have any role on Kerberos clients but you still need a briefly configured krb5.conf on the clients, as well.

For Kerberos clients, only krb5.conf should be configured. For conflicting settings between a Kerberos client and the Kerberos KDC server, it's up to the Kerberos KDC server which policy is accepted on the realm in the end. For instance, Kerberos client can have maximum ticket renewal time of 48 hours in its /etc/krb5.conf but the Kerberos KDC server may enforce 24 maximum renewal time in its combined /etc/krb5.conf and /var/lib/krb5kdc/kdc.conf configuration. Same logic applies to used encryption types and such. Clients do not give orders here, a valid Kerberos server does it.

User principals

Do I need Kerberos principal records for each user in Kerberos back-end database such as in LDAP?

Yes, you need. However, I want to distinguish something here with an example.

Strictly speaking, for NFSv4 to work, you don't need nested Kerberos objects in LDAP records such as in uid=foouser,ou=Users,dc=mydomain,dc=com. However, you must have a LDAP record for your Kerberos principal such as for foouser@MYDOMAIN.COM. This record is located and stored in Kerberos LDAP container, as you have defined in your Kerberos KDC server's /var/lib/krb5kdc/kdc.conf file.

You may also use principal format such as foouser/systemuser@MYDOMAIN.COM as long as you have proper GSSAPI auth_to_local regex configuration defined in NFSv4 server's /etc/krb5.conf file, as described earlier in this article.

Security

Good and compherensive explanations are given in Kerberos Administration Guide - Release 1.19 - MIT, section referrals are shown below. I make short references to key points although there are a lot of good stuff in the linked PDF file, so I strongly recommend reading it.

KDC security policy

Section: 1.1.1 Installing KDC

“It is best to install and run KDCs on secured and dedicated hardware with limited access. If your KDC is also a file server, FTP server, Web server, or even just a client machine, someone who obtained root access through a security hole in any of those areas could potentially gain access to the Kerberos database.”

I strongly encourage running Kerberos KDCs in internal and strictly restricted scope in your hardened internal LAN/VLAN network segment. NEVER run KDC or related sensitive services in your DMZ zones. Consider using unprivileged ports (> 1024) for any Kerberos server processes instead of default privileged ports 88, 464 and 749.

Keytab security policy

Section: 1.1.3 UNIX Application Servers - The keytab file

“The keytab file is a potential point of entry for a break-in, and if compromised, would allow unrestricted access to its host. The keytab file should be readable only by root, and should exist only on the machine's local disk. The file should not be part of any backup of the machine, unless access to the backup data is secured as tightly as access to the machine's root password.”

Securing Kerberos computers

Section: 1.1.3 UNIX Application Servers - Some advice about secure hosts

“Kerberos V5 can protect your host from certain types of break-ins, but is is possible to install Kerberos V5 and still leave your host vulnerable to attack. Obviously an installation guide is not the place to try to include an exhaustive list of countermeasures for every possible attack, but it is worth noting some of the larger holes and how to close them.”

“We recommend that backups of secure machines exclude the keytab file. If this is not possible, the backups should at least be done locally, rather than over a network, and the backup tapes should be physically secured.”

Mutually validating Kerberos KDC and clients

I recommend reading the linked official documentation for PKINIT or SPAKE configuration setup.

PKINIT certificates

Section: PKINIT CONFIGURATION

“PKINIT is a preauthentication mechanism for Kerberos 5 which uses X.509 certificates to authenticate the KDC to clients and vice versa. PKINIT can also be used to enable anonymity support, allowing clients to communicate securely with the KDC or with application servers without authenticating as a particular client principal.”

Protection against password dictionary attacks

Password dictionary attacks are concern of principals which use passwords for authentication (principal generated without -randkey parameter is kadmin console). These attacks are not concern of principals generated with -randkey (random key) parameter.

I strongly recommend reading section ADDRESSING DICTIONARY ATTACK RISKS in the referred documentation as well as the following SPAKE section:

Section: SPAKE PREAUTHENTICATION

“SPAKE preauthentication uses public key cryptography techniques to protect against password dictionary attacks. Unlike PKINIT, it does not require any additional infrastructure such as certificates; it simply needs to be turned on. Using SPAKE preauthentication may modestly increase the CPU and network load on the KDC.”

Common security policy

Practice and apply common security policy to your network and host-specific policy. Also consider using SELinux and/or AppArmor or similar solutions for additional security. Practice the best mandatory access control policies in general.

Cyber attacks against Kerberos

Different attack types against Kerberos. You find more about the practical approach of these attacks by checking the URL links on each attack type.

Attack name	Description
DCShadow attack	An attack where attackers gain enough access inside a network to set up their own fake Domain Controller and to use it in further infiltration
Credential stuffing (Brute force)	Automated, continued attempts to guess a password
Encryption downgrade with Skeleton Key Malware	A malware that can bypass Kerberos on a Windows Domain Controller with a master password, but the attacker must have administrative access
Golden ticket	A ticket that grants a user domain administration access
Kerberos KDC Spoofing (link 1; link 2)	Kerberos Key Distribution Center (KDC) server spoofing. Note: `Microsoft Kerberos v5 domain login in Windows 2000 is not vulnerable to this attack`
Pass-the-ticket	The process of forging a session key and presenting that forgery to the resource as credentials
Silver ticket	A forged ticket that grants access to a service
Kerberoasting Attack (Active Directory) (link 1; link 2)	An attacker captures TGT ticket from client computer's memory and cracks the service credential hash offline by using a password cracking tool

Additional sources:

Kerberos Authentication Explained - Varonis.com

You find more Kerberos exploits on exploit-db.com - Exploit Database by searching Kerberos.

Tools such as MetaSploit-Framework include mimikatz module which has Kerberos and Windows Domain Controller attacks as illustrated in the following picture:

Metasploit Framework: available Kerberos and Windows Domain Controller attack modules (some found modules are irrelevant)

IMAGE: Pekka Helenius

Kerberos critique

Many people find Kerberos difficult to set up or maintain. Others say it's a security framework remnant of yesterday. Usually people tend to be frustated by the lack of good documentation and unnecessary complexity involved. Critique:

Firstyear's blog-a-log: Kerberos - why the world moved on

You may ask yourself,

“Do I really have to set up the whole Kerberos infrastructure just for secure file sharing?”

Well, it depends how much security you or your organization wants or requires.

stunnel + NFS

stunnel wrapper is a lot less complex to set up than full Kerberos environment. However…

I once tested stunnel for plain-text NFS (v4 shares. Although my configuration was valid, I had NFS connection stability issues (dropped connections) and weird connectivity issues so I abandoned the approach. You may try stunnel but based on my experience, I don't recommend it for NFS shares. I don't know how it works with Samba or with other NFS versions, though.

Samba shares

Samba shares can only utilize unencrypted LDAP connections for now.

SMB 3.0 protocol will support encryption but as of August 2021, its implementation status is still in progress (see wiki.samba.org - SMB3 kernel status).

So, Samba can't replace Kerberos now.

Basic guide to set up an unencrypted Samba share on Linux: Arch Wiki - Samba.

SSHFS

To-be-written

Additional guides

Conclusions

Setting up a properly working Kerberos environment is a project with many requirements. You need server infrastructure with a working network, good security policy for both hosts themselves but for network topology, as well. Instead of physical computer hosts, virtual machines or containerized solutions may be sufficient for you, or maybe you want to use them even in your production environment.

As Kerberos has many dynamic parts, and the configuration can be done in many ways, there is no a single correct way to set it up. Some basic principles are covered and practiced in this article but you need to understand Kerberos scales up to many, many other services than just NFSv4. In addition, a Kerberos setup can have more encryption schemes and slave/replication mechanisms which are not well covered in this article.

Kerberos is a work horse behind Windows Active Directory, can independently be used in pure Linux environments, or in mixed environment with all Windows/Mac/Linux hosts present. Mixed Kerberos environments is also a topic not covered in this article.

Goal of this article is give you a practical setup that works but actually understanding the logic and extend your knowledge is up to you. I have provided multiple links in this article in different sections to help you out. This is not enough since you need to understand how to plan and configure proper network and security policy, as well. You may have requirements which are not covered in this article. In the end, it is up to your knowledge, technical understanding and goals which is the solution for your kerberized environment.

As my last words I say this: do not even attempt to adapt Kerberos/GSSAPI everywhere. Although some experts consider Kerberos an outdated protocol, it still has its place on many computer networks. Kerberos does not scale to modern cloud solutions where SAML/SAML2, OAuth and such methods have a preference but it still works on securing local network infrastructure when used wisely and practical scope in mind.

Kerberos-secured network file shares - practical guide for kerberized NFSv4

Table of Contents

Foreword

This article compared to other online sources

Common misconceptions

Help! Too many daemons and service files! I don't know what to do

Dealing with contradicting recommendations

What do I really need on my servers? Facts - now!

Errors, permission issues! Too much frustation. I give up! Yet I say: Do not give up

Getting started

Prerequisites

Architectural overview

NFSv4 user mapping

Configuration

All computers

Linux kernel configuration requirements

About provided Systemd files

Kerberos back-end and NFSv4 user database server

Host information

OpenLDAP Database configuration

How do I create NFSv4 LDAP attributes, optionally needed by NFS idmapd.conf files on NFSv4 client/server?

Firewall configuration

Required Systemd process files

DNS server

Host information

Kerberos-related DNS records

Firewall configuration

•Kerberos KDC & Administration server

•Host information

•Kerberos compilation parameters

•Kerberos KDC LDAP configuration

•Kerberos configuration

•Required/recommended KDC Principals

•Keytab configuration

•Firewall configuration

•Required Systemd processes

•Systemd files configuration

•NFSv4 server

•Host information

•NFS Utils compilation parameters

•NFS configuration

•GSSProxy configuration

•Kerberos configuration

•Firewall configuration

•Keytab configuration

•Required Systemd processes

•Systemd files configuration

•Miscellaneous

•NFSv4 client

•Host information

•NFS Utils compilation parameters

•NFS configuration

•GSSProxy configuration

•Kerberos configuration

•Firewall configuration

•Keytab configuration

•Required Systemd processes

•Systemd files configuration

•Miscellaneous

Useful commands and hints

Foreword

Kerberos principals

Generating principals

Adding principals to /etc/krb5.keytab on current host

Additional Kerberos Administration Server commands

Requesting a new ticket and access to the NFSv4 service

Issue: Password incorrect while getting initial credentials

Ticket cache location on a Kerberos client

Custom ticket cache location

How do I view my Kerberos ticket content?

Ticket renewal

Deleting my current Kerberos ticket cache

Adding keytab principal entries on Kerberos clients

Systems & services: with known KVNO number and a symmetric key

Passwordless non-interactive user authentication

Other ktutil commands with descriptions

Troubleshooting

Foreword

Permission denied when mounting a Kerberos secured volume

cannot access XX: Key expired or cannot open directory: Key has expired

•
Kerberos KDC & Administration server

•
Host information

•
Kerberos compilation parameters

•
Kerberos KDC LDAP configuration

•
Kerberos configuration

•
Required/recommended KDC Principals

•
Keytab configuration

•
Firewall configuration

•
Required Systemd processes

•
Systemd files configuration

•
NFSv4 server

•
Host information

•
NFS Utils compilation parameters

•
NFS configuration

•
GSSProxy configuration

•
Kerberos configuration

•
Firewall configuration

•
Keytab configuration

•
Required Systemd processes

•
Systemd files configuration

•
Miscellaneous

•
NFSv4 client

•
Host information

•
NFS Utils compilation parameters

•
NFS configuration

•
GSSProxy configuration

•
Kerberos configuration

•
Firewall configuration

•
Keytab configuration

•
Required Systemd processes

•
Systemd files configuration

•
Miscellaneous