1. 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

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

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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. SIMS Flow
1/12/2011

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

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

20. 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

21. 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

22. 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

23. 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

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

25. 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

26. 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

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

28. 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

29. Questions? ? ? ? ? ? ? ? ? ?
1/12/2011