Purpose
Active Directory contact objects are interesting for many reasons, but aren’t currently integrated with any UW Technology lifecycle provisioning process. Additionally, existing support for them in MI is currently a manual, one-off process.
The purpose of this document is to get everyone on the same page in terms of background, i.e. assumptions and design considerations, document the highlights of discussion held over time, and hopefully establish a proposal for proceeding with centrally provisioned/managed contacts in MI. Additionally, there may be some consideration for how conceptually contact objects could extend the usefulness of existing IAM services.
Assumptions
Contacts are not security principals, meaning that you can’t login with a contact object.
Design Considerations
While contacts are not security principals, it is important to note that contact objects can have a userPassword value and user certificates.
Because contacts are not security principals, they do not have a samAccountName attribute which must be unique.
From Active Directory’s perspective, a contact object is a person with the full set of possible attributes that come with being a person (~71 attributes), and is also an “exchange” object with the full set of possible attributes (~21 attributes) that come along with that. Additionally, contact objects have around ~17 additional possible attributes related to OCS. So a contact object has a broad set of potential attributes (~100).
Discussion
MI contact use cases:
- Exchange email forwarding (out of Exchange)
- 1a. to edge
- 1b. to external source
- Sharepoint mailing list enablement (i.e. non-Exchange mailing lists) (could intersect with use case #3c & #3d)
- Augment UW Exchange GAL with entities not currently in it
- 3a. UW cloud users
- 3b. S/MIME (external source encrypting to all of us)
- 3c. Non-person UW NetIDs (could intersect with use case #2 & #3d)
- 3d. UW mailing lists external to Exchange (could intersect with use case #2 & #3c)
- Group service members which don’t currently map to an existing user/group
- 4a. Federated users
- 4b. DNS names
- Misc. non-person netids
- OCS
- 6a. OCS config
- 6b. OCS “GAL” presence for non-OCS enabled users
- 6c. OCS interop with other OCS implementations
Use cases #1a and #1b provide a way for Exchange mailboxes and resources to forward email internal to Exchange out of Exchange so that normal SMTP routing happens. These contact objects are not expected to be visible to users, and are considered simply a way of enabling a backroom functionality. These contact objects would get created when a user doesn’t want an Exchange mailbox to receive email, and would be deleted when either the Exchange mailbox is deleted or when the user wants their email to be delivered. There is also a possibillity that a given Exchange user might want to change their forwarding out of Exchange from one destination to another, which might be accomplished via either a contact rename OR a contact deletion and creation. In the short-term lifecycle of these contacts can be managed by requests to the UW Exchange Engineering team, but long-term the lifecycle management of these contacts could be delegated to the UW Exchange subscription, with some additional development. The number of these contacts should be less than the number of UW Exchange mailboxes.
Use case #2 provides a way for Sharepoint users to direct Sharepoint email alerts to an existing mailing list that is not Exchange-based. These contact objects could (and likely would) be visible to users via the Exchange GAL, and users would need some way to provision them when they had a need for them to be present. Over time, these contact objects would have a minimum of changes (mostly just email address changes), with a deletion needed when the external mailing list is deleted. Because these contacts represent external mailing lists, determining who should have the ability to modify/delete them is problematic. One possibility is automatically syncing UW mailman lists, hopefully covering the majority of desired contacts. Then, also allowing self-provisioning of other mailing lists, but requiring that changes to those self-provisioned contacts go to the MI support team. The number of these contacts is dependent on UW Sharepoint use, but is imagined to be less than 1000.
Use case #3 provides a way for additional stuff to be added to the UW Exchange GAL; currently only UW Exchange mailboxes (and resources) and personal UW NetIDs are in the UW Exchange GAL. 3a would allow a contact object representing a mailbox hosted somewhere outside Exchange (but that mailbox might possibly have the same primary smtp address as an existing Exchange mailbox). 3b would allow for a single contact used to provide email encryption on an organization basis. 3c would allow non-personal UW NetIDs to have a presence in the GAL. Use case #3c can be solved other ways; we could instead mail-enable the non-person UW NetIDs as we currently do for personal UW NetIDs. The potential number of non-people is large, so determining some kind of qualification policy is needed. The lifecycle around non-people largely depends on what things qualify. The number of these contacts is dependent on the qualification policy, but could be much larger than 1000.
Use case #4 provides a way for MI group membership to be identical to UW Group Service group membership. Currently the Group Service allows federated users and DNS names as group members, but those don’t correspond to any MI object. This would allow the MI Group Integration agent to represent the actual membership, instead of dropping those members. Lifecycle around these contacts would be dependent on use in the UW Group Service, so could be delegated to the MI Group Integration agent. The number of these contacts depends on UW Group Service usage, but is imagined to be less than 1000.
Use case #5 is a potential way to reduce our security exposure associated with non-person UW NetIDs which have no need to actually login, but do need some way to be represented in a directory service. By allowing certain kinds of UW NetIDs to instead be created as contact objects we reduce our overall security exposure while providing the needed functionality. Lifecycle around these objects would be dependent on changes in the UW NetID system, so might be delegated to the MI UW NetID integration agent (currently fuzzy_kiwi) if some additional support to existing infrastructure was added. The number of these contacts is dependent on which UW NetIDs don’t need a password which is likely more than 1000.
Use case #6 provides a way for OCS to <need OCS engineers to provide info here>.
Proposed Policy and Process
All MI contacts are centrally managed, i.e. there are policies and practices about their lifecycle.
All MI contacts will live under OU=Contacts,DC=netid,DC=washington,DC=edu, unless vendor software requires that they be elsewhere.
Contact names in MI will conform to a c_ naming policy, and considered part of the UW NetID namespace.
A name of the form c_<emailaddress> will be used for most contacts, where <emailaddress> is the destination email address with an underscore (_) substituted for the AT sign (@), e.g. c_barkills_cac.washington.edu. Use cases 3b, 4b, 6a (and possibly 6b) are unlikely to be able to conform to this naming policy, and naming for these use cases will be determined prior to implementing those cases.
Until MI Roadmap feature U20 is realized, contacts:
- for use cases 1a and 1b are permitted and will be manually created, modified, and deleted by the UW Exchange Engineering team
- for use case 2 are permitted and will be manually created, modified, and deleted by the UW Sharepoint Engineering team
Contacts for all other use cases will require further review by the MI Governance team.
Example Use Cases
Nothing yet.
Outcome
Proposed policy was implemented in 2009. Automated contact provisioning is unrealized.