BanDADE

Banner Data Active Directory ExtensionsJustin Cervero

Appalachian State University

Banner is KingActive Directory is the Hand of the King

Objectives

• Create as near a real time connection between Banner and the Active Directory as possible for user account creation, updates, and deactivation

• Improve audit processes and automated user management

• Attempt to reduce system complexity

User Synchronization

Sample Export

How we’ve been doing it:• Scheduled Banner data

dumps• Different exports for

different groups• Scheduled tasks to

process data files• Process every banner user

and every AD user every time• CPU intense on both the

export and the merge• More users, longer

process time• Limited frequency

REAL TIME SYNCHRONIZATION SOLUTIONS

How do we most efficiently get new user data from Banner into the Active Directory? How do we know when we need to update a users account? How do we ensure that accounts are disabled in a time frame that ensures institutional security?

Our answer, LDI Messaging. The Luminis Message Broker can initiate user events for all of our criteria.

Your answer? Oracle Message Broker? Roll your own?

LDI/LMB OverviewMessage Example • The message broker can be

configured to fire events on specified criteria

• Messages can contain user account information and/or user membership information

• Messages are delivered by HTTP post with optional authentication

• Messages can be directed to multiple systems concurrently

• The LMB reads the HTTP response and handles queuing in outage situations

• Message content can be customized, but isn’t currently recommended by the vendor

Message Consumption:The LDI Listener• Domain joined IIS web server• .Net HTTP Handler

– Remove page/service processing overhead

• Application pools runs as a privileged account• Returns HTTP 200 if post is complete

– Processing of the message is independent from receiving the message

• Separate thread for every message received

• One to one user processing vs. batch processing of all users

LDI Pitfalls and theAD Rabbit Hole• Vendor says don’t customize the message, but

the message doesn’t have everything we need• Threaded model means that message may

potentially be processed out of order• Coordinating the message properly means

relying on a variety of ID information in Banner, Luminis, Campus Standards, and Active Directory: PIDM, Sourced ID, Banner ID, & Username

System Complexity vs.Schema Complexity• We need access to more information but we

want to avoid involving more systems– Take advantage of the capabilities of the AD

• Schema mods are not to be taken lightly– One way street/no take backs– Potential overhead– Security considerations– Do existing attributes meet your needs?• Employee Number vs. Employee ID

System Flag and Search Flag Attributes• Dependent upon Domain Functional Level• Customized use of system flagged attribute is not

advised– “You cannot mark a base schema attribute as confidential”– Base schema attributes are designated by the System Flag

attribute value 0x10

• 8th bit (dec 128/0x80) of the Search Flag attribute is the Confidential Flag (03 SP1+)– Prevents attribute from read/write by non-Domain Admins

Employee Number vs.Employee IDEmployee Number - Object Employee ID - Object

Not enough attributes to go around? Time to extend the AD Schema

– Required Privileges – Schema Admin• Not default for Domain Admin, is for Enterprise Admin

– Required Tools• OID generator• Active Directory Schema snap-in, ADSI Edit, LDP

– Available on Domain Controllers or as part of RSAT

– Careful Planning– Understanding Performance Impact

• Object size considerations– Storage requirements– Replication and network conditions– Consider custom enumerations

– Careful Documentation – especially for enumerations

OID: Schema Object Identifier

• Required on all AD objects• Unique to every attribute– Prefix unique to your organization– Suffix unique to custom objects within your organization

• <Org OID>.1.X – Classes• <Org OID>.2.X – Attributes

• Generated with MS provided VBS– Can also be purchased from ANSI– Do *NOT* just make one up

• Very important in multi domain forests

Classes and Attributes

• There are three types of classes in the AD– Abstract, Structural, and Auxiliary– Only structural classes can be instantiated– Auxiliary classes are attached to other classes– For our purposes, we make use of one auxiliary class

• All classes have attributes• Attributes also have attributes

– systemFlags & searchFlags

• Attributes are strongly typed• Attribute and Class names are just as important as unique

OIDs

Our plan

• Banner ID in Employee Number attribute of User object- unicode string

• Auxiliary Class– appstatePerson <OID>.1.1

• Three custom attributes– appstatePidm integer

<OID>.2.1– appstateSourcedID unicode string

<OID>.2.2– appstateProcessFlags enumeration <OID>.2.3

• All attributes set to ‘confidential’

appstateProcessFlags

• Some MS tools are ‘enumeration aware’– Custom enumerations will not be displayed the same way as built in

enumerations• Special MS LDAP filters – Same way you filter for active/inactive

– 1.2.840.113556.1.4.803 LDAP_MATCHING_RULE_BIT_AND– 1.2.840.113556.1.4.804 LDAP_MATCHING_RULE_BIT_OR

• Document, document, document

ACCOUNT_ACTIVATED 1 0x1 Set upon first password change after account creation. Enables account reactivation by subsequent processes. Permanent once enabled.

KEEP_DISABLED 2 0x2 Set or cleared by either user audit process of domain administrators. Prevents account being enabled by automated process. (ie. Password change on deactivated student re-enables account until next audit job)

NO_PRUNE 4 0x4 Prevent account from being pruned during audit process. Domain administrator use only.

NO_DISABLE 8 0x8 Prevent account from being disabled by audit process. Domain administrator use only.

Pause for time

• Beyond here lies the implementation process

• Open the floor or cover how you modify the schema?

Implementing the Plan

• There are a number of tools provided by MS that can be used to modify the schema– Ntdsutil, ldifde, csvde, ADSI/VBS scripting, LDP, Active

Directory Schema snap-in, ADSI Edit…

• We used a combination– AD Schema snap-in to create our class and attributes– ADSI Edit to alter searchFlags attributes– LDP to manually associate users with our Aux class

• Association is done by setting any attribute in the class

Implementing the Plan:AD Schema snap-inCreate the attributes

Implementing the Plan:AD Schema snap-inCreate the class

Implementing the Plan:AD Schema snap-inAttach custom attributes to custom auxiliary class Attach auxiliary class to user class

Implementing the Plan:ADSI EditSetting the searchFlags attribute

Implementing the Plan:Using LDP to set attributes

Implementing the Plan:Using LDP to validate securityGeneral User Search Domain Admin Search

Phasing Changes Into Prod

• Alter current user creation process to begin setting custom fields

• Backfill current users with new attributes• Modify update process to rely on newly available

data• Start processing LDI messages in test mode• Compare LDI Listener logs against current process• Enable updates of prod AD via LDI– Retain current process for auditing, but reduce frequency

Bringing it all togetherSample ScenariosA. HR/Registrar creates user in Banner

1. LDI Message sent to Listener2. Listener request more data from Banner3. AD account created with BannerID,

PIDM, SourcedID and appstateProcessFlags set, initial state is disabled

4. User changes their password for the first time – AD account enabled, bit 1 of the appstateProcessFlags set

B. HR/Registrar changes user’s username1. LDI Message sent to Listener2. User identified by Sourced ID3. Account username updated

C. User registration status changes1. User drops all classes2. LDI Message sent to Listener3. AD account disabled4. User re-adds classes5. LDI Message sent to Listener6. AD account status determined by

appstateProcessFlags bit 1

D. Unexpected HR Event1. HR deactivates user2. LDI Message sent to Listener3. Account deactivated4. Domain Admin notified of special

account termination 5. Sets bit 4 of appstateProcessFlags6. appstateProcessFlags value prevents

account from being pruned

Review of Objectives

• Create as near a real time connection between Banner and the Active Directory as possible– LDI Messaging/Listener allow us to have provisioned AD accounts within

seconds of creation in Banner bringing us inline with other enterprise systems– Active Directory controlled system access is revoked in a time frame that

better protects us from potentially malicious users• Improve audit processes and automated user management

– Custom attributes allow us more accurately track and apply changes to users while giving Domain Admins greater control over automated processes

• Attempt to reduce system complexity– Successful, with caveats– We’ve reduced system/process complexity by increasing schema and code

complexity. Fewer systems are involved or required but institutional knowledge is more important

Roadmap

• Potential for LDI Messages to be processed out of order– Extend schema to hold last processed message?

May provide a side benefit in process auditing.– Create message queue on Listener?

• Index Sourced ID in AD to improve process performance?

• Consume ‘Membership’ messages for rights assignment

Q & A

Questions?Suggestions?

Criticisms?My questions for you.

Resources

• http://www1.appstate.edu/~cerverojj