Enhancing Collaboration by Extending the Groups Directory Infrastructure James Cramton Brown 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 3 rd 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 Groups Registry User Group Sync SIS User Registry Account Provisioning Course Kerberos AD Exchange E-Directory Provisioning Software WebCT iTunes LDAP Registry LDAP Authentication LDAP Network LDAP Alumni Relay LDAP SMTP Relay LDAP Mail Relay LDAP Directory Bulk Mail WebAuth Group Course Feed Grouper Feed Course Feed LDAP Feed Manually Provision Groups Alum SQL Base Group WebGroupie UI Effective Group

Proposed System Landscape Groups Registry User Registry Account Provisioning User Kerberos AD Exchange E-Directory WebCT iTunes LDAP Registry LDAP Authentication LDAP Network LDAP Alumni Relay LDAP SMTP Relay LDAP Mail Relay LDAP Directory Bulk Mail WebAuth User, Group, and Course BRU Group Sync SIS Provisioning Software Grouper Feed Course Feed LDAP Feed Alum SQL 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 3 rd party services –Potential productivity drain as departments reinvent the wheel with or without IT expertise –Potential waste of money as departments purchase 3 rd 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 Groups Registry User Group Sync SIS User Registry Account Provisioning Course Kerberos AD Exchange E-Directory Provisioning Software WebCT iTunes LDAP Registry LDAP Authentication LDAP Network LDAP Alumni Relay LDAP SMTP Relay LDAP Mail Relay LDAP Directory Bulk Mail WebAuth Group Course Feed Grouper Feed Course Feed LDAP Feed Manually Provision Groups Alum SQL Base Group WebGroupie UI Effective Group

Proposed System Landscape Groups Registry User Registry Account Provisioning User Kerberos AD Exchange E-Directory WebCT iTunes LDAP Registry LDAP Authentication LDAP Network LDAP Alumni Relay LDAP SMTP Relay LDAP Mail Relay LDAP Directory Bulk Mail WebAuth User, Group, and Course BRU Group Sync SIS Provisioning Software Grouper Feed Course Feed LDAP Feed Alum SQL Base Group Group Mgmt UI Effective Group

Set Arithmetic Modeling Kerberos AD Exchange E-Directory LDAP x 7 User CourseGroup Bulk Mail WebAuth WebCT Current Design Kerberos User CourseGroup Proposed Design AD Exchange E-Directory LDAP x 7 Bulk Mail WebAuth WebCT 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 ApplicationReal TimeIs X in Group AList all of X’s GroupsList all members of Group A NACYX WebAuthYX Bulk MailTBDxx WebCTNCourses iTunesYx ConfluenceYxx AD/ExchangeN NDSN ShibbolethY? Video on DemandY?? Campus CalendarsY?

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 ParentChildCount COURSEADMIN2512 SISADMIN2498 COURSE [Courses, each represented once]2450 SIS [Courses, each represented once]2448 EABHRDEPT269 COMMUNITYAPPLICANT107 EABAPPLICANT107 COMMUNITYSTUDENT86 EABDORM74 EABSTUDENT67 COMMUNITYEMPLOYEE64 COMMUNITYDORM43 EABACADDEPT42 EABEMPLOYEE30 COMMUNITYAFFIL25 EABAFFIL22