Centralizing and Automating the Management of Special Identities Eric Sturdivant Systems Architect, Distributed Computing Systems Jay Elvove Manager, Distributed Computing Systems Fran LoPresti Director, Technical Services and Support 1/12/2011

Students: 37,000 Faculty/Staff: 10,200 250 full-time staff 100 student employees 1/12/2011

About This Presentation Overview Requirements What We Built What We Learned Where We Go From Here 1/12/2011

Overview Traditional Identity Management Deals with real people Accounts are created when they being their relationship w/university and destroyed when the end it Managed by HR people or registrar Less systems involved (only ldap, unix, kerberos, ad) 1/12/2011

What are “Special” Identities? Anything but a real person's regular account Examples include: Mailing lists, Shared mailboxes, etc... Root/Administrator accounts Application IDs (Database, LDAP, etc...) Guest accounts Calendar resources 1/12/2011

Special Identities vs. Regular Identities Wider variety of systems involved Typically no user accounts in Oracle, or on a network switch Almost always created manually Deleted manually (if at all) Almost always created manually - if you are lucky you have scripts to at least Ensure consistency - automation is a big win here Deletion is a problem Have to hope someone remembers to tell an admin to do the delete 1/12/2011

Problems Migrating systems Is this still in use? Who owns this (who do I contact?) Security That person hasn't worked here in 5 years! Lack of Automation - migrating systems Need to make changes to accounts, can't find anyone to contact (ocal to exchange) - Security - floating contractor accounts or extra “admin' Accounts for people no longer affliiated with The university. (audit findings) Talk about nts radius acl and student and audit - lack of automation leads to lack of consistency 1/12/2011

Requirements Need at least one real university person to “own” them Need to be renewed Consistent namespace Centralized management Workflow Some requests may need approval Some identity classes should restrict who may use them - Create a list of special identity types and look for things in common - Need to be renewed - this is fundamental. Without renewal (and Automatic expiration/deletion) you don't Get the full benefit of the system - both “needs to be renewed” and “at least one owner” have exceptions. - reserved ids (vulgar) probably don't need Renewal - library guest accounts don't have owners 1/12/2011

Requirements (Cont.) System interfaces must be able to run on multiple platforms Unix, mainframe, Oracle, Cisco, Windows, 3rd party, etc... System interfaces must not be allowed to interfere with each other System interfaces should be able to be developed by the groups that run the system 1/12/2011

What We Built SIMS – Special Identity Management System Talk about backend identity storage (ldap) - could be anything (AD, database, etc...) Talk about database structure (task queue, logs, extra_data) Plugins are interfaces into various systems - run privileged 1/12/2011

SIMS Flow 1/12/2011

Be As Flexible As Possible Multiple “frontends” supported As much placed in configuration files as possible System knowledge isolated in “plugins” Plugin and Frontend API via SOAP Huge variety of platforms and languages Arbitrary “extra data” fields with each request var/value pairs allows future expansion Give example of extra_data usage Library-guest Ldap groups Calendar resources 1/12/2011

Push vs. Pull Push Requires a webserver for each plugin (SOAP) Requires handling of plugin down (retry) No delay in processing Pull Simple SOAP client to implement plugin Plugins poll on their own schedule (15 seconds, 1 hour, etc...) Processing is delayed 1/12/2011

Frontends The means by which users submit requests Create, rename, renew, reset password, delete, modify Typically a common web interface, but specialized frontends could be developed Talk about frontend Cas for authentication Clustered webapp Provides ways to search identities, view stats, etc... administrator resets log viewing, etc.. 1/12/2011

Backend Receives requests from the frontends Creates individual tasks for the plugins based on rules in the class configuration file E.g. create sturdiva/root Create entry in LDAP Create account/password in Kerberos Create entry in UNIX passwd file Presents tasks to plugins 1/12/2011

Backend Validation Checks for owner validity Notifies other owners when one separates from university Notifies identity class administrators when no owners are left Checks for required number of owners Disables accounts past their expiration date Deletes accounts past their expiration date Checks for stale tasks Done via cronjobs Mail notification to owners or id class administrators when various events happen 1/12/2011

Identity Class Configuration Files Implement rules and requirements Required plugins Naming conventions Authorized users Account lifetime Granularity of renewal and expiration Workflow approval process Allow building new identity classes simply by creating a new configuration file For example, math guest accounts last 90 days, but Physics ones are only 30 days. Simply copying the config file and changing the lifetime parameter gets you there. 1/12/2011

Identity Class Configuration Files Allows additional fields in frontend forms to be controlled via config file and passed to plugins validation { # fields required for a create action create { required { bloodtype = “Blood Type” haircolor = “Hair Color” } optional { height = “Height” 1/12/2011

Identity Class Configuration Files Allows additional fields in frontend forms to be controlled via config file and passed to plugins 1/12/2011

Identity Class Configuration Files Allows additional fields in frontend forms to be controlled via config file and passed to plugins $bloodtype = $task->extra_data->get_value (-var => 'bloodtype'); if ( $bloodtype eq 'A' ) { ... } elsif ( $bloodtype eq 'B' ) { } This allows end user controlled data to be passed to the plugins to make decisions 1/12/2011

Identity Class Configuration Files Allows plugin-specific configuration to be specified on a per-ID class basis plugins { activedirectory { # where in the directory to create the object branch = “OU=Guest Accounts,OU=LIBR,OU=Departments” } This allows administrator controlled data to be passed to the plugins (never changes, unlike extra_data shown earlier) 1/12/2011

Plugins Implement system interface LDAP, Kerberos, UNIX, Active Directory, Oracle, Exchange, etc... Typically only 5 functions create, delete, enable, disable, rename reset password, modify API with backend is simple take_tasks set_task_state add_log_message Can be course or fine (e.g. one large plugin for all of exchange, or one for mailing lists, one for calendar resources, etc...) 1/12/2011

Benefits of Flexibility Created library guest account system in a few days Tracks staff member who issued the account Used extra data fields to track the ID information of the guest id_type, id_issuer, id_number Created LDAP groups in an afternoon Used extra data fields to manage group membership add_member, rem_member 1/12/2011

What We Learned Things We Missed Identities without owners Automated renewal with any other action Groups 1/12/2011

What We Learned (Cont.) Keep the plugin development curve as low as possible Allows the unit closest to the system to write/own them There are always exceptions Library-guest no owners needs fast processing time Reserved IDs no expiration/renewal Plugin development This means good documentation and examples A fully functional plugin example or template with “fill in create code here” makes it easier 1/12/2011

Where We Are UNIX root (296 accounts, 157 expired and removed) Library guest (8,000 accounts) Calendar room (440 accounts) LDAP Group 1/12/2011

Where We Go From Here Active Directory LDAP Oracle Administrator SQL Server Guest LDAP Auth-DN Oracle User Application 1/12/2011

Where We Go From Here (Cont.) Cisco Administrator Guest Wireless VPN Groups Mainframe Application UNIX Guest Application IDs Virtual Machines? Talk about vm process 1/12/2011

Questions? ? ? ? ? ? ? ? ? ? 1/12/2011