Centralizing and Automating the Management of Special Identities (166352352)

7/29/2019 Centralizing and Automating the Management of Special Identities (166352352)

http://slidepdf.com/reader/full/centralizing-and-automating-the-management-of-special-identities-166352352 1/29

1/12/2011

Centralizing and Automating theManagement of Special Identities

C o p y r i g h t U n i v e r s i t y o f M a r y l a n d 2 0 1 0 .

Eric SturdivantSystems Architect, Distributed Computing Systems

Jay ElvoveManager, Distributed Computing Systems

Fran LoPrestiDirector, Technical Services and Support



1/12/2011

Students: 37,000Faculty/Staff: 10,200

250 full-time staff 100 student employees



1/12/2011

● Overview

● Requirements

● What We Built

● What We Learned

● Where We Go From Here

About This Presentation


http://slidepdf.com/reader/full/centralizing-and-automating-the-management-of-special-identities-166352352 4/291/12/2011

Overview

Traditional Identity Management



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)



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



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



1/12/2011

Requirements (Cont.)

● System interfaces must be able to run on multipleplatforms

● Unix, mainframe, Oracle, Cisco, Windows, 3rd party, etc...

● System interfaces must not be allowed to interfere witheach other

● System interfaces should be able to be developed bythe groups that run the system



1/12/2011

What We Built

● SIMS – Special Identity Management System



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



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 specializedfrontends could be developed



1/12/2011

Backend

● Receives requests from the frontends

● Creates individual tasks for the plugins based on rulesin 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



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



1/12/2011


● Allows additional fields in frontend forms to becontrolled 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





1/12/2011



$bloodtype =

$task->extra_data->get_value (-var => 'bloodtype');

if ( $bloodtype eq 'A' ) {

...

} elsif ( $bloodtype eq 'B' ) {

...

}



1/12/2011


● Allows plugin-specific configuration to be specified ona per-ID class basis

plugins {

activedirectory {

# where in the directory to create the object

branch = “OU=Guest Accounts,OU=LIBR,OU=Departments”

}

}



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



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

● Things We Missed● Identities without owners

● Automated renewal with any other action

● Groups

What We Learned



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



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● Administrator

● SQL Server

● Guest

● LDAP● Administrator

● Auth-DN

● Oracle● Administrator

● User

● Application



1/12/2011

Where We Go From Here (Cont.)

● Cisco● Administrator

● Guest Wireless

● VPN Groups

● Mainframe● Administrator

● Application

● UNIX

● Guest

● Application IDs

● Virtual Machines?



1/12/2011

Questions?

???

??

?

?

?

?

Centralizing and Automating the Management of Special Identities (166352352)

Documents

Transcript of Centralizing and Automating the Management of Special Identities (166352352)