On 10/22/2009 01:44 AM, David Parter wrote: >>> 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
Yeah, both of you are giving me food for thought. We are already segregating each research group into their own groups. Shared files for each group is in a common folder on the file server, forced guid to the group. So, I think we are on the right track. Maybe I will try to convince management to have a legacy-user account for each group. That is an easier argument than persuading Security, I think. Security at $WORK is a checklist group... Thanks! Regards, Junhao _______________________________________________ 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/
