Enhancing Collaboration by

Extending the Groups Directory Infrastructure

James CramtonBrown University

Why We are Here• De-duplication without all the facts

– Software in central business system identifies individuals on SSN– Provisioning software in IT identifies individuals on First Name, Last

Name, DOB– William Charles Smith and William Kenneth Smith, with same DOB

applied– Provisioning software flags Kenneth as a duplicate, does not provision

him– Turns out they are twins with same first and last name!– Solution: write an exclusion list for skipping provisioning duplicate

check

• Need for greater group specificity– Clinical faculty in medical school irate because he is not granted

system access– Turns out clinical faculty are grouped with various affiliates in registry– Solution: continue with current initiative to identify & enforce better

policy

Starting Point: Brown Grouper

• 1990s: Brown Grouper developed to manage groups and ACLs

• Dated web interface allows experienced administrator to include or exclude group members from base group

• 11,000 groups stored in home-brewed text file format– 5,000 base course groups from SIS feed for 2,500 Courses (read only)– 5,000 modifiable course groups for 2,500 courses (read/write)– 1000 demographic groups support limited group logic

• Active Directory and Novell groups manually provisioned

• Major exposure to Hit by a Bus Syndrome– One administrator and the one person responsible for mailing labels know the

data – No personal groups (unless you know who to ask)– No index of group data—what groups exist? (unless you know who to ask)

Brown’s Provisioning System

• Text feeds from multiple systems consumed by provisioning software– Brown Grouper– University mainframe (BRU)– Student Info System (SIS)

• Provisioning handled by Perl scripts and some 3rd party connectors

• Object-based Perl code is modular, but biz logic is embedded in code

• SunOne LDAP registry is main repository for provisioned data

• Registry replicates users to AD, eDirectory, and other SunOnes servers

• WebAuth and bulk mail query Brown Grouper directly• Course membership and primary affiliation are the only

group info in registry; they are attributes on the Person object

Current System Landscape

BRU GroupsRegistry

Use

r

Gro

up S

ync

SIS

UserRegistry

Acc

ount

Pro

visi

onin

g

Cou

rse

KerberosAD

ExchangeE-Directory

Pro

visi

onin

gS

oftw

are

WebCTiTunes

LDAP Registry

LDAP AuthenticationLDAP Network

LDAP Alumni RelayLDAP SMTP RelayLDAP Mail Relay

LDAP Directory

Bulk MailWebAuthG

roup

Course Feed

Grouper Feed

Course Feed

LDAP Feed

Man

uall

yP

rovi

sion

Gro

upsAlum

SQL

Base Group

WebGroupie UI

Effective Group

Proposed System Landscape

Groups Registry

UserRegistry

Acc

ount

Pro

visi

onin

g

Use

r Kerberos

ADExchange

E-Directory

WebCTiTunes

LDAP Registry

LDAP AuthenticationLDAP Network

LDAP Alumni RelayLDAP SMTP RelayLDAP Mail Relay

LDAP Directory

Bulk MailWebAuth

Use

r, G

roup

, and

Cou

rse

BRU

Gro

up S

ync

SIS

Pro

visi

onin

gS

oftw

are

Grouper Feed

Course Feed

LDAP Feed

AlumSQL

Base Group

Group Mgmt UI

Effective Group

Motivations• Stakeholders want:

– More control of groups (delegation of some groups)– Less control of groups (centralized definitions of other groups)– Ability to extend base groups (include and exclude members)– More group visibility (expose more existing groups to

applications)– More groups (add student activities, personal groups, etc.)

• Limit administrative overhead– Contain Help Desk administrative burden– Delegate some group administration to some departments– Eliminate duplication of effort in manually provisioned groups

(AD and Novell)

• Support wider range of policy decisions– Remove technical limitations on business policy– Increase granularity of rules– Use centralized ACLs to enforce rules in application layer

Requirements• Provide a single system image of group definitions

– Store more granular group definitions in LDAP– Automatically provision groups into Active Directory and eDirectory

• Support multiple types of groups– Increase granularity of group definitions available to application layer

(highly nested schema)– Technically not particularly challenging– Business rules for establishing ACL and affiliation hierarchy is tricky

• Continue to support expectation of highly customizable groups– Automatically provisioned (base groups)– Provisioned and tuned (effective groups)– Manually provisioned (centralized, not ad hoc)

• Expanded granularity will require delegation– Improve usability of group management tool—both interface and

concepts– Scope includes group definitions, membership, and ACLs

• Implement with minimal service disruption– Support current applications– Provide framework for support of future applications

Policy Issues • The technical decisions are relatively easy • Explaining issues to stakeholders is more

challenging• Reaching consensus takes time and

collective education• Policy & business practice questions abound

– We can do great things. But should we? Will it be used?– How do we provide visibility without compromising sensitive info?– What are the organizational expectations of privacy &

accessibility?– Who will be managing group data? With what tools? With what

skills?– Need to communicate the new capabilities and policies

• Limiting scope is essential– Impact core infrastructure, not applications in HR, Registrar, etc.– Justify any increased administrative overhead– Privilege management scheduled to follow policy decision process

Cultural Considerations• Historically, computer services have been highly customizable

– Courses have multiple membership list—for better or worse• Course registration• Course mailing list• WebCT registration

– Groups will be created & membership modified to meet most any need• If students and faculty can’t get what they ‘need,’ they will

use 3rd party services– Potential productivity drain as departments reinvent the wheel with or without IT

expertise– Potential waste of money as departments purchase 3rd party products & services– Potential security risk in unapproved systems– So, IT provides peripheral authentication and authorization services (Napster, wiki,

etc.)• Extremely open campus policies, with exceptions

– Student groups want to know when related group meets to avoid schedule conflict– Some group membership must be known only to group – Some group membership must be known only to another group – Some groups existence must be hidden from community view

• Technology capabilities currently limiting business innovation• Highly vulnerable to the Hit by a Bus syndrome

Strategic Approach• Identify requirements• Define scope of change• Design proposed system• Implement prototype• Revise design as needed• Implement and validate additive infrastructure• Phased rollout of applications

– Pilot– Roll-out– Next…

• Follow up with delegated applications (AD/Exchange/eDirectory)

• Consider next generation features as subsequent projects

Phased Implementation• Implement

infrastructure–LDAP schema changes–Provisioning software changes–Management interface changes

• Tier 1 applications (enhance existing services)–Network Access Control Lists

• VPN, Wifi, other ACLs• Network Device ACLs

–WebAuth (http[s] authn & authz) –Bulk Mail

• Morning Mail Groups • Replace Majordomo (with

Sympa?)–WebCT Course Provisioning–iTunes provisioning

• Tier 2 applications (delegated services)–Wiki authn & authz via LDAP Groups–Exchange/AD group provisioning–Novell eDirectory group provisioning

• Tier 3 applications (proposed services)–Shibboleth–Video on Demand–Campus Calendars–Personal Groups–Privilege management–Guest, alumni IDs and ACLs

Analysis Techniques• Interview stakeholders• Understand current and proposed system• Set arithmetic diagrams for conceptualizing

scope• Research and create lists of LDAP group

queries– Current – Anticipated– Analyze impact on performance and schema

• Understand scope of current group infrastructure– Summarize to understand big picture– Review detail to identify the exceptions

Current System Landscape

BRU GroupsRegistry

Use

r

Gro

up S

ync

SIS

UserRegistry

Acc

ount

Pro

visi

onin

g

Cou

rse

KerberosAD

ExchangeE-Directory

Pro

visi

onin

gS

oftw

are

WebCTiTunes

LDAP Registry

LDAP AuthenticationLDAP Network

LDAP Alumni RelayLDAP SMTP RelayLDAP Mail Relay

LDAP Directory

Bulk MailWebAuthG

roup

Course Feed

Grouper Feed

Course Feed

LDAP Feed

Man

uall

yP

rovi

sion

Gro

upsAlum

SQL

Base Group

WebGroupie UI

Effective Group

Proposed System Landscape

Groups Registry

UserRegistry

Acc

ount

Pro

visi

onin

g

Use

r Kerberos

ADExchange

E-Directory

WebCTiTunes

LDAP Registry

LDAP AuthenticationLDAP Network

LDAP Alumni RelayLDAP SMTP RelayLDAP Mail Relay

LDAP Directory

Bulk MailWebAuth

Use

r, G

roup

, and

Cou

rse

BRU

Gro

up S

ync

SIS

Pro

visi

onin

gS

oftw

are

Grouper Feed

Course Feed

LDAP Feed

AlumSQL

Base Group

Group Mgmt UI

Effective Group

Set Arithmetic Modeling

KerberosADExchangeE-DirectoryLDAP x 7

User

Course Group

Bulk MailWebAuth

WebCT

Current Design

Kerberos

User

Course Group

Proposed Design

ADExchangeE-DirectoryLDAP x 7Bulk MailWebAuthWebCT

Via Course Feed

Via Brown Grouper

List Anticipated LDAP Queries

• Summarize query types by application• Optimize schema according to common query types• Real time vs. batch can influence decisions

Application Real Time Is X in Group A List all of X’s Groups List all members of Group A

NAC Y X

WebAuth Y X

Bulk Mail TBD x x

WebCT N Courses

iTunes Y x

Confluence Y x x

AD/Exchange N

NDS N

Shibboleth Y ?

Video on Demand Y? ?

Campus Calendars Y?

Current Group Summary• 10,000 course groups• 1,000 other groups• Redundancy is

merited by historical precedent

• Schema depth: 4 levels

• Deepest nested subgroup membership much deeper

Parent Child Count

COURSE ADMIN 2512

SIS ADMIN 2498

COURSE[Courses, each

represented once] 2450

SIS[Courses, each

represented once] 2448

EAB HRDEPT 269

COMMUNITY APPLICANT 107

EAB APPLICANT 107

COMMUNITY STUDENT 86

EAB DORM 74

EAB STUDENT 67

COMMUNITY EMPLOYEE 64

COMMUNITY DORM 43

EAB ACADDEPT 42

EAB EMPLOYEE 30

COMMUNITY AFFIL 25

EAB AFFIL 22