Expiring Users at a Future Date

Get Help
1

Greetings,
Before OOD, when users used to ssh to our cluster, we (the admins) could automatically set a future expiration date for our users (i.e. sudo chage -E 2024-01-31 ). I noticed that expiring users like that on both the login and compute nodes will no longer prevent our users from accessing that cluster via OOD once their account is expired. Is there an OOD built-in command or some set it and forget it process, that allows us to have the user account deactivated at a future date? The OOD is configured to authenticate users via a smart card:
auth:

  • ‘AuthType CAS’
  • ‘Require valid-user’
  • ‘CASScope /’
2

The short answer is no - this is likely a CAS issue.

Seems like you need to expire the LDAP user so that CAS no longer authenticates them. (IDK if sudo chage -E 2024-01-31 reaches into LDAP).

Or maybe apply the same expiration on the web node too? I’m not familiar with chag beyond just reading the man page, but I would suggest expiring folks in the LDAP layer instead if you can.

3

Thank you for the quick reply. We don’t have that kind of access to LDAP. Expiring the users that way on the login (also the web node) doesn’t prevent users from accessing the cluster. I’m sure that Apache has access control, but I’m not familiar with it, or if it’s even possible to set it for a future date without some sort of a script…

4

I’m not super sure how to achieve this without reaching out to your CAS team as well.

apache can disable access - but likely only based off of some CAS return field. Seems like you can use Require cas-attribute if you have an attribute available that distinguishes these users.

@tdockendorf you have any other advise on this?

5

When you expire someone, if you change their shell to something you configure with nginx-stage, you could deny access:

[tdockendorf@web02 ~]$ grep -i shell /etc/ood/config/nginx_stage.yml
# Restrict starting up per-user NGINX process as user with this shell.
#disabled_shell: '/access/denied'

OSC used to use this before we moved to Keycloak and Keycloak will check LDAP attributes to know if someone is enabled/disabled.

So if you change their shell to like /sbin/nologin and configure nginx-stage with that, you could prevent access in OnDemand.

1 Like
6

I guess we could use the at command to disable the shell of a user in a future date, and uncomment the disabled_shell line from that configuration file. It’s worth the try. Thanks

7

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.