Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Banner Data Active Directory Extensisons

Published in: Technology
  • Be the first to comment

  • Be the first to like this


  1. 1. BanDADEBanner Data Active Directory Extensions Justin Cervero Appalachian State University
  2. 2. Banner is KingActive Directory is the Hand of the King
  3. 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. 4. User SynchronizationHow 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. 5. How do we most efficiently get new user data from Banner into theActive Directory? How do we know when we need to update a usersaccount? How do we ensure that accounts are disabled in a time framethat ensures institutional security?Our answer, LDI Messaging. The Luminis Message Broker can initiate userevents for all of our criteria.Your answer? Oracle Message Broker? Roll your own?REAL TIME SYNCHRONIZATION SOLUTIONS
  6. 6. 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
  7. 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. 8. 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
  9. 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. 10. System Flag andSearch 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. 11. Employee Number vs.Employee IDEmployee Number - Object Employee ID - Object
  12. 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. 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. 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. 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. 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. 17. Pause for time• Beyond here lies the implementation process• Open the floor or cover how you modify the schema?
  18. 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. 19. Implementing the Plan:AD Schema snap-inCreate the attributes
  20. 20. Implementing the Plan:AD Schema snap-inCreate the class
  21. 21. Implementing the Plan:AD Schema snap-inAttach custom attributes to custom auxiliary class Attach auxiliary class to user class
  22. 22. Implementing the Plan:ADSI EditSetting the searchFlags attribute
  23. 23. Implementing the Plan:Using LDP to set attributes
  24. 24. Implementing the Plan:Using LDP to validate securityGeneral User Search Domain Admin Search
  25. 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. 26. Bringing it all togetherSample ScenariosA. 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 userB. 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. 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. 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. 29. Questions? Suggestions?Criticisms? My questions for you.Q&A
  30. 30. Resources•