> > My workplace does not have a policy to handle this situation, so I am > > wondering how everyone handles this age-old problem. Any advice? > > > > I can only think of these 2 methods: > > 1) create local users to replace the AD user. > > There no confusion about the person who generated the data long time > > past, and institutional knowledge can be preserved. However, this > > becomes a management headache.
Local users are a bad idea when everything else is in the central authentication system (AD in this case). > > 3) request for the accounts to be locked, not deleted. I think Security > > will scream... Security should not scream (but they probably will), as long as you develop a specific policy and procedure for this. Security has to secure the systems, but they also have to be usable by the end users -- the computers, and their data, are for user to get their work done. > > 2) create a general user to own all these files. Simple solution, at the > > expense of institutional knowledge. I think this starts to get to the right answer. There is more to it than just creating a user, however. - Create a user specifically to own the group files. Either name it by the group, or by the research project if you have multiple projects. Think this through and come up with a general solution that will work for all (or at least most) of your research groups. Make sure that the Security group is part of the team that develops the solution. - Make a policy that all group files will be kept in a well-known place on the file server (not in home directories) and add a regular task to change the ownership of all files in the repository to the group user. - Make sure to document your policies and procedures, and refine them as needed --david _______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
