OnGuard Cardholder Management Techniques

Introduction

OnGuard administrators may manage their cardholder (user) populations manually or automatically.

OnGuard Cardholder Management Techniques

Manual Cardholder Management

  1. Open the OnGuard System Administration application:

    Start -> OnGuard -> System Administration -> [login]

  2. From the menu, select Administration -> Cardholders....
  3. Click the Add button.
  4. Please note: If you know all the person's information: Full name, Person #, UB Card #, and Badge type, it is best to add everything at the time of creating the user. This way you do not need to wait until the next day to add any access levels. If the UB card # (last 8 digits) is added to the 'Badge' tab, access can be given immediately under the 'Access Levels' tab.
  5. Optional: you may assign minimal data for the user and then wait for the system to populate the rest of the record. The 'Last Name' and 'Person #' fields are required. The 'Last Name' field is case-sensitive, so remember to capitalize its first letter. Our cardholder population script will automatically fill in the remainder of the cardholder's personal information from institutional data by 8:45 AM the following day. Then you'll be able to manually assign the cardholder's access levels by following Steps #12-14.
  6. Prepend a 0 (zero) to the cardholder's person number and assign it to the Person # field. This field was designed to hold a 9-digit Social Security Number (SSN) field. Our UB Person Numbers only have 8 digits. We tack a zero onto the front of the 8-digit Person # to make it 9 digits long.
  7. Click the OK button.
  8. If you know the UB card #, click on the 'Badge' tab and click the 'Add' button.
  9. Under the 'Badge' tab, fill in the UB card # (last 8 digits only) to the 'Badge ID' field.
  10. If not able to choose the 'Badge Type' under the previous 'Cardholder' tab (if greyed out), make sure the 'Badge Type' field is chosen in this area.
  11. Click the OK button.
  12. Click on the 'Access Levels' tab. Click on 'Modify' and assign the appropriate access levels. Must click on the door icon to the left of the description. This will add a red check mark to the access level.
  13. Click on the 'Activate Dates...' button if you want to specify a Deactivation Date. There is no need to specify an Activation Date. Access will begin immediately.
  14. Click the OK button twice.
  15. Best practice is to push the DB to the readers to ensure immediate access for the new user. Do so by following these instructions: https://wiki.cse.buffalo.edu/services/content/basis-card-access#Database
  16. Now the person that was added to the DB has immediate access to the door(s) assigned.

Automated Cardholder Management

If you would like to grant access to well-defined sets of cardholders, we can automatically set and renew their access level memberships. Follow this procedure:

  1. Who Gets Access? In Structured Query Language (SQL) or English, define the set of cardholders to whom you're granting access. Examples:
    1. Structured Query Language (SQL). In this example, select a constrained subset of Med School faculty and staff: 
      
SELECT DISTINCT b.principal
FROM ubs_emp.active_employee_directory a
INNER JOIN dce.person_number b ON (a.person_number = b.person_number)
WHERE a.hierarchy like '0812%' AND
      a.appt_type_desc in ('CLASSIFIED','EMERITUS','FACULTY','MEDICAL RESIDENT/FELLOW','PROFESSIONAL','RESEARCH NON - FELLOW','UBF','VAWNYHS - MED RES','VOLUNTEER')
ORDER BY b.principal;
    2. English. Examples: 
      
"All Nursing 601 students"
"All CSE graduate students"
"All OT 599 students in the 'SJC' section"
"All University Police"
"All LIS administrative staff"
  2. Where Do They Get Access? Define the access level(s) to which the cardholders should be granted access. Examples: 
    
'Bell 314'
'CIT - All Doors Always'
'Dental Medicine Fac/Staff-Foster'
'Jacobs 324 7-11pm'
'Allen Hall Campus Police'
  3. Email CSE. Send the populations and access levels (defined in 1. and 2., above) to cse-consult@buffalo.edu.
  4. Confirmation.

    CSE will confirm to you that we added your new rule. We'll add the query to our basis.cards Perl script. The Perl script runs from 08:15 - 08:23 each weekday. It extracts UB institutional data from InfoSource and pushes it into the BASIS database. The script extends active cardholders' BASIS access levels' expiration datetime values by one month. You can tell that the script is extending a cardholder's access level expiration value if her access level expiration date is one month from today, with an expiration time value of about 08:20.

    When cardholders leave UB, they are no longer 'active' in UB institutional data. When a cardholder is no longer active in UB institutional data, our queries fail to select them, so we stop extending their access level expiration datetime values by a month. Thus, departed cardholders automatically lose their access rights one month after they leave UB.