Hi,
What policies do you have in place for user accounts on your clusters that
(a) Have not logged in ~6 months / never logged in / did not change default passwords
(b) Have logged in and 6 months ago and only have about ~200K (code not too much data) in their HOME spaces
I would love to hear your thoughts!
Our university’s IT Security policies require that users have a current business need, so we request an affirmation from each user annually. Unresponsive accounts are locked, and data are removed after a grace period.
1 Like
Hi schadalapaka,
How this is handled is one of those things, like editors, where there are lots of opinions and no right answers, but I’m willing to toss in an opinion.
W.R.T Accounts, there are some basic features of unix user accounts and unix groups that place some constraints on this, if these features are both understood and accepted as necessary.
- uid, gid, uidNumber and gidNumber are unique.
- uid, gid, uidNumber and gidNumber should never be recycled (opens up the possibility of a new user/group inheriting some legacy access in a permission or ACL or sudoers or… )
The sane way to handle this, then, is to never remove old accounts or groups, just lock them as needed and perhaps change loginShell to /bin/nologin. This is easy for environments where the cluster admin also controls the user/group management and has the nice effect of preserving institutional history. But in environments where there is a central authority for this there may be upstream processes/procedures which do not grasp these two basic premises. It’s actually quite surprising how often people in those central authority positions don’t grasp this and try to reuse these as if the organization will someday have 2^32 users and every uidNumber is precious. Based on current life expectancy and the org size most of us will work in, it’s generally safe to say that dealing with user 2^32-3 will be somebody else’s problem that they’ll solve from a laptop sitting on a climate change enabled oceanfront property in Kansas.
W.R.T. home directories, my preference is to keep a small-ish quota on $HOME, say <= 32 GB, then I really don’t care if someone leaves behind data as it can be easily ignored on pretty much any modern storage. If there really are thousands and thousands of users then probably the budget included enough for matching $HOME storage and if not, the quota can be further reduced to a number that can be lost in the noise of whatever the real storage footprint is.
At least in academic environments, collaborations can span careers and do not necessarily end when someone leaves a position. People tend to boomerang and return as well, so having account/group history and the old $HOME can be a huge benefit to users. It’s also nice when someone says “Fred used to run this from $HOME but he’s gone now, can you help us get this working?” Being able to su - Fred can be a real time-saver.
griznog
1 Like
Student accounts are set to expire 12 months after creation. Then their sponsor or PI has to request the account to be extended. In cases where user are not renewed, after 6 months of inactivity we archive all data and delete the account. We then hold onto the archived data for an additional 18 months.
1 Like