Provisioning Group Email

The purpose of this document is to discuss methods of provisioning group e-mail accounts.
At this time only the exchange system supports group email functionality so all discussion of provisioning concerns that system.

Group e-mail functionality is needed to replace one of current uses of departmental PIDs.
The driving force for the replacement is to enhance security. With the new group e-mail functionality, each user will be able to authenticate as him- or herself and not simply as someone who knows the shared password. The new functionality also gives us an opportunity to systematically de-provision access.

• In order for an @vt.edu adddress to be used for group e-mail, a mail account must be created in the Sun ONE and a forward must be set to the Exchange account.
• IRM must have appropriate tools to provision group e-mail accounts.
• An interface may be needed which allows group e-mail administrators to control the people in their group.

• De-provisioning is accomplished by (a) an expiration date and (b) IRM action.

This solution leverages the Registry database to store the e-mail address and forward, while the Active Directory stores the group information.

• IRM would use an AD tool to create the group e-mail account
• IRM would use the DAT to create a group e-mail entry and forward it to the Exchange group e-mail account
• The group e-mail address and forward would be replicated to Sun ONE, where the account would be created

• Group e-mail administrators would use Exchange tools to control the group
• Deprovisioning of group e-mail has not been discussed

• Registry schema design
• Business logic coding
• Web interface
• Replication stream

This solution doesn't fit within the design of the Enterprise Directory, which was conceived to manage people.
Due to this fact we cannot leverage any existing infrastructure for the creation, replication, and maintance of group email data.
Storing a piece of group email data, without the accompanying members, administrators, and other data is very undesirable and could lead to split brain problems.
— dfisher@vt.edu 2005/08/09 11:19

IRM currently has tools in place to manage many aspects of the AD. This toolset (collectively called the MMC (Microsoft Management Console)) allows them to manage users and groups and has been “extended” to provide them with Exchange mailbox management functions as well. In the long term, we have a project in planning to eliminate these tools and build a web interface (tenatively called ADadmin) that will encapsulate the necessary business logic to provide support to multiple stackholders (4help, IRM, DIT) in their interactions with AD. Current OU administrators who have management over their organizational units within the AD also have permissions to manage group membership for groups IRM creates to handle these resource accounts.
— marcd@vt.edu 2005/08/09 14:32

This solution removes the Registry from the picture and relies entirely on an Active Directory interface.

• IRM would use an AD tool to create a group e-mail account
• The group email address and forward would be replicated to Sun ONE, where the account would be created
• Group e-mail administrators would use Exchange tools to control the group
• Deprovisioning of group e-mail has not been discussed

• AD web interface
• Replication from AD to Sun ONE

The work required to create this AD tool is a big question mark.
Only Marc's group can clarify what will be required.
Replication from this AD tool to Sun ONE would not be difficult as it would be identical to what occurs now between the Registry and Sun ONE.
My guess would be the main argument against this solution is that ED owns email addresses.
It is true that ED owns person email addresses, but it doesn't own all the administrative email addresses in iPlanet and there is no compeling reason for it to own group email addresses.
— dfisher@vt.edu 2005/08/09 11:25

Does there need to be a corresponding ID within ED to work with iPlanet? Is there a requirement to have all email seem to come from x@vt.edu? — marcd@vt.edu 2005/08/09 14:32

First off it's not iPlanet, it's Sun ONE. Secondly, in answer to Marc's question above, Yes. There must be an entry in the ED first. This must then be sent through the ED Connector to create an e-mail account on the Sun ONE server (in its LDAP directory). This will create the account which can then be forwarded to the Exchange service where the “group account” will actually reside. —william@vt.edu 2005/08/10 9:38

There is no technical reason that the ED to Sun ONE replication stream has to be used. In fact it would have to be modified in order to support this feature as it was written to create person email accounts. I believe an AD tool can create the account in Sun ONE just as easily as an ED tool. — dfisher@vt.edu 2005/08/10 15:18

This solution adds additional requirements to the ED Groups system for group email.
Since we are leveraging exchange, only groups owned by a VT employee would be allowed to create a group email account.
Policy could dictate whether all group members must be VT employees, but only VT employees would be able to use the group email account.
Non employee members simply couldn't participate.

• IRM would use the DAT to create an ED group or modify an ED group so that it has an email account
• All group data would be contained in ED, so full provisioning could occur in both Sun ONE and AD
• Group administrators would use a portal tool to manage their group members, which would replicate to AD
• Deprovisioning of groups and group email has not been discussed

• ED Groups has been mostly designed, but the requirements have not been finialized and no code has been written
• Portal interface for groups

This solution adds a nice feature to ED Groups, but is the farthest away from implemantation.
Doing group email management outside of exchange may prove very cumbersome, more investigation is required.
— dfisher@vt.edu 2005/08/09 11:39

I would welcome further discussions with the ED group about this synchronization process. Wether its one way or bi-directional I think it would provide a valuable addition to the ED-AD structure providing we handle the merger of the group namespaces correctly.
— marcd@vt.edu 2005/08/09 14:32