Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I work at a university, where we have staff members who can also teach as an adjunct faculty member. We issue an account for the individual based on their name, so Joe Smith would get smithj@domain.edu. and it is up to them to sort through their mail for staff content versus adjunct content.

HR wants these individuals to have 2 accounts, one for their staff work and one for their adjunct work so the two are completely separated. One reason being that if the staff role is terminated for any reason, they shouldn't have access to their staff content, but could still continue in their adjunct role. Using the previous "Joe Smith" example they would keep their smithj@domain.edu account for staff work, and get the next iteration of our naming scheme as an additional smithjo@domain.edu for their adjunct account.

I don't want to do this for a number of reasons:

  1. From a security perspective, I'd like 1 user to have 1 account
  2. It takes an extra email account license (we are using Zimbra)
  3. It's confusing to have two accounts that map to the same person for different roles
  4. In any case, the user has that content, and can do whatever they want with it: forward to their other account, save it to disk, whatever. So if HR has dreams of keeping any staff-only information from a user when their staff employment is terminated that is a pointless battle

Some options we have thought of:

  1. Create an alias and set up a persona in Zimbra - This solves the licensing issue and everything is in the same account, but is not separate in that if their staff employment is terminated they would still have access to all that stuff.
  2. Different domains - having user@domain.edu and user@adjunct.domain.edu - This is still as crappy as the 2 account solution, now they are just spread across 2 domains

Has anyone else experienced a similar situation, and if so how did you deal with it?

share|improve this question

2 Answers 2

up vote 3 down vote accepted

I don't see anything wrong with the HR plan. It makes sense to me to keep the emails separated by role. If the additional licensing cost is approved then my opinion would be to go with it.

You have a point about a user accessing email sent to one role from the other role, but I think the point is to take appropriate steps to keep the roles distinct and unique, not to close any and every possible loophole that exists. If that were the case then you'd have a lot more work to do, and not just regarding email.

share|improve this answer
    
I certainly see their point, and they give me real world examples of why it is a pain for them every month or so. I may just have to work with multiple accounts, and to Ward's point just say "this is a one-hit-wonder solution for adjunct and staff roles only" :) –  Alex Jul 8 '11 at 13:27
    
I don't really like it as an answer, but I think I'm left with little choice. We are really only talking about a handful of people in both roles, so the licensing is really a pretty small issue. –  Alex Jul 13 '11 at 22:00

I agree with your point #4 - trying to limit people's access to emails after the fact is an exercise in futility.

Setting up email addresses that are both personal (which is what you've got with your smithj@ addresses) and role-based seems like a logistical nightmare: will you have to have things like: alex_smith_adjucnt_prof@domain.edu and alex_smith_research_assist@domain.edu? What about people who are promoted, or otherwise change their roles: alex_smith_assistant_prof@domain.edu gets tenure and has to change to alex_smith_prof@domain.edu?

share|improve this answer
    
This is one nightmare situation I am thinking of :) I am primarily interested in the staff vs adjunct roles, but really there are a whole lot more, and once we open that option it will always be "why don't we just do it like we do with adjunct accounts. –  Alex Jul 8 '11 at 13:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.