On Mon, Feb 26, 2024 at 12:38 PM Alexey Tikhonov atikhono@redhat.com wrote:

On Fri, Feb 23, 2024 at 12:06 PM John Doe jdoe53851@gmail.com wrote:

...

Hello

I'm wondering if there's any way to access the informational message about password expiration given upon login when using cached credentials? When having pam_verbosity = 2 in sssd.conf, the following informational message is given; "Authenticated with cached credentials, your cached password will expire at Sat Apr 20 15:41:18 2024"

Now I know I can calculate the time for expiration myself by checking the 'offline_credentials_expiration' value in sssd.conf and add that to the timestamp for cache entry last update time reported by 'sudo sssctl user-show $USER' but both of these require root access. I need to get the expiration timestamp as a regular user.

The reason for this is that we do have a large number of external developers who are all given laptops with the company Linux image applied, having them log in using their Active Directory credentials. They do have VPN access but the nature of the projects they're working on they seldom need to be connected to our network :-( I was thinking I could create a little script/application that notifies them a few days ahead of password expiration to remind them to connect to the VPN.

I was thinking of 'sss_cache' as that can run as a regular user but that can't give me the timestamp :-( Worst case, I can perhaps write somethinh in python, but that depends of the availability of APIs and maybe that still will require root access.

Hi,

cache files (content of `/var/lib/sss/db/`) are typically owned either by root:root or by sssd:sssd and aren't readable by others.

So it doesn't matter if it's a 3rd party script or an existing tool (sssctl, sss_cache) - it will require privileges anyway (you can set CAP_DAC_READ file capability on your executable, if you don't want to run it under "full" root).

*sorry, `CAP_DAC_OVERRIDE`, of course.

On Fri, Feb 23, 2024 at 12:06 PM John Doe jdoe53851@gmail.com wrote:

Now I know I can calculate the time for expiration myself by checking the 'offline_credentials_expiration' value in sssd.conf and add that to the timestamp for cache entry last update time reported by 'sudo sssctl user-show $USER'

Are you certain of that?

In my testing, the timestamps shown by "sssctl user-show $USER" would change if sssd was in an online state and refreshed the user object from AD; no authentication was required. And while it is probably the case that if sssd was online for any significant period of time, the user probably authenticated during that time (e.g., unlocking a screen saver would count) and thus the cached password expiration was updated, you cannot necessarily assume that.

My conclusion was that while sssd (obviously) has code paths to look up the cached password expiration, they are reached only through the PAM stack. There is no generic way (e.g., via sssctl) to discover what credentials are cached within sssd, or when those credentials expire.

Similarly, there appears to be no way to list all Kerberos credentials stored in KCM. If you suspect a specific user has credentials, you can setpriv(1) to that user and run klist(1), but there is no generic way to enumerate all credentials.

I was thinking of 'sss_cache' as that can run as a regular user but that can't give me the timestamp :-(

At least for Kerberos credentials, I once threw together a proof-of-concept script that used the Samba tdbdump utility to dump /var/lib/sss/secrets/secrets.ldb and rummage through the output,

As great as sssd is, its opacity about its cached information is frustrating to system administrators. We shouldn’t need to resort to third-party data dumping tools to get useful information out of sssd. Thus, I would really love to see the following sssctl commands:

* cred-show Information about cached user credentials * kcm-show Information about cached KCM credentials

The "sssctl cred-show" command would produce a table of all cached user credentials, where the first column is the user@DOMAIN who owns the credentials, and the second column is the expiration time of credential expressed as time_t (seconds since epoch).

The "sssctl kcm-show" command would product a similar table, with four columns: the owning user, the credential cache name, the credential, and the expiration time expressed as time_t.

On Mon, Feb 26, 2024 at 6:40 AM Alexey Tikhonov atikhono@redhat.com wrote:

*sorry, `CAP_DAC_OVERRIDE`, of course.

CAP_DAC_READ_SEARCH would be better, as unlike CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH does not bypass file *write* permission checks.

But even still, this is arguably a flawed approach, as depending on how this is implemented, you might wind up exposing the complete contents of the /var/lib/sss/secrets/secrets.ldb file to ordinary users. Among other things, that would allow theft of KCM credentials, and harvesting any/all cached credentials for nefarious purposes (e.g. offline password cracking).

The best long-term approach would be for sssctl to add commands that permit enumeration of cached credentials (and cached KCM credentials). From there, any number of scripting solutions are possible.