[ale] Security best practice - Remove or disable user accounts?

[Forsaken]

The reasons that have already been stated are all good, and I'll add  
to it with something that comes from my own experience.

As a web hosting company, we see alot of legacy installs with software  
running as a particular user, and it's dependant on their UID, crontab  
and such, and the other users have their own UID's instead of  
jiggering with the passwd file to give them the same UID. In cases  
like that, we can't really remove the user without breaking stuff. So  
in those cases, we add some stuff before the password in the shadow  
file and make damned sure that the users authorized_keys file has been  
blanked. That way none of the users data is lost and we can still su  
to the account if needed if needed for anything.

What's really annoying is when the user has access to the phpmyadmin  
install and the company uses the same username and password for their  
apps that they use to administer the databases.

On Aug 7, 2008, at 12:32 PM, Jeff Lightner wrote:

> At a former job the policy was to disable rather than remove user  
> accounts.
>
>
> However, on checking for “best practices” I don’t find any  
> indication why this should be and find several references to  
> removing them completely.
>
> Does anyone know of a best practice that explains why disabling  
> would be preferable to removing?
>
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or  
> confidential information and is for the sole use of the intended  
> recipient(s). If you are not the intended recipient, any disclosure,  
> copying, distribution, or use of the contents of this information is  
> prohibited and may be unlawful. If you have received this electronic  
> transmission in error, please reply immediately to the sender that  
> you have received the message in error, and delete it. Thank you.
> ----------------------------------
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20080807/d45f1595/attachment.html