University of Colorado Boulder Project Page

University of Colorado Boulder

• If you are reading this line, this document is still incomplete!

Office 365/Exchange

Overview

University of Colorado Boulder presented a lightning talk at 2015 Internet2 Technology Exchange on Grouper and Exchange / Office 365. See slides here (PDF format)

CU Boulder migrated from on-premise Exchange to Office 365 (O365) in June 2015. Here is a quick overview of the Active Directory environment relevant to Exchange and groups:

• The Office of Information Technology's (OIT) Identity and Access Management (IAM) team has the Active Directory (AD) domain and enterprise admin rights
• IAM creates top level OU's for the departments, schools, and colleges and delegates the full administration of these OU's to personnel (OU Admins) within these departments, schools and colleges.
• OIT's Messaging and Collaboration team (M&C) managed the on-premise Exchange infrastructure and the creation of the mail distribution lists.
• Many of the mail distribution lists were being used as security/access groups in AD
• DirSync was going to be used to sync accounts and distribution lists from our AD to the Azure Active Directory which introduced mainly the following issue:
  • Because it is a one-way sync, end users lose the ability to manage their distribution lists using Microsoft's Outlook or Outlook Web Access .

Problem

• Come up with a way to allow end users to continue managing their mail distribution lists without breaking the existing secondary functionality of the distribution lists as security/access groups in AD.
• Membership of the distributions lists could be individual accounts, other distributions lists, or security/access groups within AD. Any solution implementation had to maintain this structure and allow for it to be carried forward in the future.
• Distribution lists in AD could have a "Managed By" attribute refer to the account or group that manages that DL. Any solution implementation had to maintain this feature.

Solution

• At that time, the IAM team has been looking into Grouper and what it could offer in terms of access management solutions for our users.
• The decision was made to deploy Grouper in a phased approach with Phase 1 addressing the Office 365/Exchange mail distribution lists at hand.

• Overall, for our Grouper environment, we opted for not using the PSP that came with Grouper. Instead, we implemented a solution that used a messaging bus from which connectors could be developed to provision to our resources.

  Grouper Setup

  For an overview of our Grouper setup, please refer to slides 3 and 5 of this presentation

Tasks and Details

The details of getting the distribution list management to be managed through Grouper are as follows:

• Created a top-level OU in AD for Grouper
  • This is the OU where any changes made in Grouper for the AD resource would be written to. ie, these are one-way updates from Grouper to AD
  • This OU would have sub-OUs that mirror the stem structure in Grouper for the AD resource
  • An AD service account had been created for Grouper. This account was given NEARLY full permissions on this OU and all of its child objects. The permissions taken away from this account on this OU and its descendant objects were "Delete", "Delete subtree", "Modify Permissions", and "Modify owner"
    
    
• MOVED the mail distribution lists in AD
  
  • Up to this point, all the mail distribution lists had been in a "bushy" structure created within an OU managed by OIT's Messaging and Collaboration team (M&C).
  • The mail distribution list groups from that OU and its sub OUs were MOVED to an OU called "Office365" within the top-level OU created for Grouper. Furthermore, the structure was flattened. ie, there are no sub OU's in the "Office365" OU they were MOVED to.
  • It is very important that the mail distribution list groups get MOVED as opposed to being copied or using any other method. This is so that the objects' SID and GUID do not get changed which could have unintended consequences.

  • Explicit Paths

    Most of our mail distribution list groups were also used as access/security groups. There were instances were some applications may have had explicit paths hardcoded to reference a group. These are almost impossible to identify and would usually break. Luckily for us, there were just a few instances of those and we were notified by the application owners quickly.

• Loaded the mail distribution lists into Grouper
  • Grouper's LDAP Loader couldn't be used in our environment to initially load the distribution list groups from AD for a few reasons mainly the following:
    • Up to this point, AD was still not being used as a source for groups and their memberships. Because some of the mail distribution list groups had other groups in other OUs nested into them, the load would have resulted in inaccurate or incomplete data.
    • There was no way to load the "Managed By" information using the grouper LDAP Loader, as far as we knew.
  • Instead, we developed a perl script that
    
    • Obtained a list of all the mail distribution list groups in the "Office365" OU through an LDAP query
    • For each group, obtained the membership information. If the member was a group, the membership was traversed until all the members are subjects (ie, accounts and not groups)
    • For each group, obtained the "Managed By" information. If it was a group, the membership was traversed until all of them were subjects
    • Generated a file(s) with Grouper gsh commands. The gsh commands consisted of the following:
    1. 1. First, the commands would create all the groups and set the group type to IncludeExclude
       2. For every group, another group will be created and named "groupName_GROUP-ADMINS"  e.g: MyTestGroup1234_GROUP-ADMINS .
       3. For every group, the "groupName_GROUP-ADMINS" group was given the "READ" and "UPDATE" privileges
       4. For every group, the members were added one a time
• Created a "Managed" group type in Grouper