Stupid client tricks

[foonon]

For the most part, with a conventional GSS-PROXY client setup (only using gssproxy-managed ccaches w/no user kinit'ing) the user ccache (KCM:${uid}:N) looks good. I only see one encrypted blob in there.

I'm using kcm, by the way (not ssd-kcm, a 3rd-party vendor's implementation).

For two client programs however, I see strange user ccache behaviour:

1. for the MS SQL client (version 18.1), every time I run "sqlcmd" TWO user ccaches are generated (KCM:12345:1 & KCM:12345:2 the first time, KCM:12345:3 & KCM:12345:4 the next time, etc). The gssproxy ticket cache has the expected service ticket and it does not get replaced with each execution.

2. Every time I execute curl(1), I get a new encrypted blob "ticket" in the existing user ccache. Again, the service tickets look fine in the gssproxy ticket cache.

Has this been seen with other client programs? Are they just misbehaving in some easily understood way? I want to bring this up to the software providers directly, but I would feel a bit better if I could give them a clue about what, if anything, they're doing wrong.

~f

[simo5]

What's the content of those?
Are they using some low level krb function to create new unique ccaches?

[foonon]

I cannot say how they're creating the caches, but these are the results:

SQLCMD - multiple ccaches

$ klist -l
Principal name                 Cache name
--------------                 ----------

$ /opt/mssql-tools18/bin/sqlcmd -S sql_server.realm.com -E
...

$ klist -l
Principal name                 Cache name
--------------                 ----------
tech_user@REALM KCM:201831554:2 (Expired)
tech_user@REALM KCM:201831554:1 (Expired)

$ klist -A
Ticket cache: KCM:201831554:2
Default principal: tech_user@REALM.COM

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

Ticket cache: KCM:201831554:1
Default principal: tech_user@REALM.COM

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

$ /opt/mssql-tools18/bin/sqlcmd -S sql_server.realm.com -E
...

$ klist -l
Principal name                 Cache name
--------------                 ----------
tech_user@REALM KCM:201831554:4 (Expired)
tech_user@REALM KCM:201831554:3 (Expired)
tech_user@REALM KCM:201831554:2 (Expired)
tech_user@REALM KCM:201831554:1 (Expired)

================
CURL - multiple tickets in most recent ccache

$ kdestroy -A
$ curl --negotiate -u : https://webserver.realm.com/
...

$ klist -l
Principal name                 Cache name
--------------                 ----------
tech_user@REALM KCM:201831554:5 (Expired)

$ klist -A
Ticket cache: KCM:201831554:5
Default principal: tech_user@REALM.COM

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

$ curl --negotiate -u : https://webserver.realm.com/
...

$ klist -A
Ticket cache: KCM:201831554:5
Default principal: tech_user@REALM.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:

$ curl --negotiate -u : https://webserver.realm.com/
...

$ klist -A
Ticket cache: KCM:201831554:5
Default principal: tech_user@REALM.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:
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:

$ klist -l
Principal name                 Cache name
--------------                 ----------
tech_user@REALM KCM:201831554:5 (Expired)

[simo5]

Interesting.
I have not seen this before and I cannot easily explain it in terms of pure GSSAPI calls.
However if these applications attempt to perform ccache manipulations there may be various ways to obtain these results, potentially by them testing exclusively file ccaches which are not collections and therefore may not show side-effects of cache manipulations that are present with cache collection types instead.
The KCM service you are using may also be partially responsible here.
Any chance you can test if using sssd-kcm yield s the same or different results?

[foonon]

I'll follow up with the vendors on these.

If I get some time, I'll try setting this up a host with sssd-kcm.

~f