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.
This solution leverages the Registry database to store the e-mail address and forward, while the Active Directory stores the group information.
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.
— firstname.lastname@example.org 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.
— email@example.com 2005/08/09 14:32
This solution removes the Registry from the picture and relies entirely on an Active Directory interface.
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.
— firstname.lastname@example.org 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 email@example.com? — firstname.lastname@example.org 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. —email@example.com 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. — firstname.lastname@example.org 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.
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.
— email@example.com 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.
— firstname.lastname@example.org 2005/08/09 14:32