The purpose of Encrypted/Credentials/v1@X-GSSPROXY:

[yghorbal]

Hi,

I've successfully setup GSS-Proxy with NFS client and Constraint Delegation against Active Directory. I think I've understood how things are working but I still miss a couple of bits!
For reference, the config is

[service/nfs-client]
 mechs = krb5
 cred_store = keytab:/etc/krb5.keytab
 cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
 cred_usage = initiate
 allow_any_uid = yes
 impersonate = true
 euid = 0

• The first one is this rather mysterious/surprising Encrypted/Credentials/v1@X-GSSPROXY: ticket(s) that gets added to the users' default kerberos cache:

$ klist
Ticket cache: KCM:1850627282:33793
Default principal: user@SOMEDOMAIN.COM

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

=> What are those for and how do they fit in the grand schema of things?

• The second one is the location of the actual Service Ticket (the one for nfs/nfs.server@SOMEDOMAIN.COM) got on behalf of the user. From KRB5_TRACE logs, I can see many MEMORY: references:

[754] 1713649111.465532: Resolving unique ccache of type MEMORY
[754] 1713649111.465533: Initializing MEMORY:PjKD2SW with default princ user@SOMEDOMAIN.COM
[754] 1713649111.465534: Storing user@SOMEDOMAIN.COM -> HOST$@SOMEDOMAIN.COM in MEMORY:PjKD2SW
[754] 1713649111.465535: Storing user@SOMEDOMAIN.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:PjKD2SW
[754] 1713649111.465536: Storing HOST$@SOMEDOMAIN.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:PjKD2SW
[754] 1713649111.465537: Storing HOST$@SOMEDOMAIN.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/SOMEDOMAIN.COM\@SOMEDOMAIN.COM@X-CACHECONF: in MEMORY:PjKD2SW
[754] 1713649111.465538: Storing HOST$@SOMEDOMAIN.COM -> krbtgt/SOMEDOMAIN.COM@SOMEDOMAIN.COM in MEMORY:PjKD2SW
[...]
[3831] 1713542008.050652: Get cred via TGT krbtgt/SOMEDOMAIN.COM@SOMEDOMAIN.COM after requesting nfs/nfs.server@SOMEDOMAIN.COM (canonicalize on)

I guess that GSS-Proxy is somehow storing some bits in a memory cache. /var/lib/gssproxy/clients/krb5cc_xxxx files get populated thow, but they only host TGT.
=> Is there any reasons why using MEMORY cache? (maybe it's mandatory in impersonation scenario?)

• Last but not least, for Constraint Delegation to actually work against Active Directory env, the first ticket requested for the host for itself on behalf of the user (the s4u2self part) needs to be forwardable in order to be accepted by AD and trigger the s4u2proxy part. Unfortunately, the default configuration of [libdefaults] section of /etc/krb5.conf after domain join through realmd does not have the forwardable set to true.

=> Is there any way for GSS-Proxy to enforce forwardability in the impersonation scenario? (regardless of /etc/krb5.conf setting)