Banner Data Active Directory Extensisons

1. BanDADE
Banner Data Active Directory Extensions
Justin Cervero
Appalachian State University

2. Banner is King
Active Directory is the Hand of the King

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

4. User Synchronization
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
Sample Export

5. 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?
REAL TIME SYNCHRONIZATION SOLUTIONS

6. LDI/LMB Overview
Message 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

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

8. LDI Pitfalls and the
AD 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

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

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

11. Employee Number vs.
Employee ID
Employee Number - Object Employee ID - Object

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

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

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

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

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

17. Pause for time
• Beyond here lies the implementation process
• Open the floor or cover how you modify the
schema?

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

19. Implementing the Plan:
AD Schema snap-in
Create the attributes

20. Implementing the Plan:
AD Schema snap-in
Create the class

21. Implementing the Plan:
AD Schema snap-in
Attach custom attributes to custom auxiliary class Attach auxiliary class to user class

22. Implementing the Plan:
ADSI Edit
Setting the searchFlags attribute

23. Implementing the Plan:
Using LDP to set attributes

24. Implementing the Plan:
Using LDP to validate security
General User Search Domain Admin Search

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

26. Bringing it all together
Sample Scenarios
A. HR/Registrar creates user in Banner C. User registration status changes
1. LDI Message sent to Listener 1. User drops all classes
2. Listener request more data from Banner 2. LDI Message sent to Listener
3. AD account created with BannerID, 3. AD account disabled
PIDM, SourcedID and 4. User re-adds classes
appstateProcessFlags set, initial state is 5. LDI Message sent to Listener
disabled
6. AD account status determined by
4. User changes their password for the first appstateProcessFlags bit 1
time – AD account enabled, bit 1 of the
appstateProcessFlags set D. Unexpected HR Event
1. HR deactivates user
B. HR/Registrar changes user’s username 2. LDI Message sent to Listener
1. LDI Message sent to Listener 3. Account deactivated
2. User identified by Sourced ID 4. Domain Admin notified of special
account termination
3. Account username updated
5. Sets bit 4 of appstateProcessFlags
6. appstateProcessFlags value prevents
account from being pruned

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

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

29. Questions?
Suggestions?
Criticisms?
My questions for you.
Q&A

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