1. Auditing Authentication & Authorization in Banner
Presented by:
Jeff White & Timothy Hollar
From Tennessee Department of Audit

2. Topics Banner overview Authentication to Banner & 3rd Party Apps
Authorization to Banner & 3rd Party Apps

3. Overview of Banner Architecture
Section 1

4. Banner Overview
Higher Education Enterprise Resource Planning (ERP) system.
Original vendor – SunGard Higher Ed
Now supported by Ellucian
Ellucian serves 2,400+ higher education institutions globally
Ellucian was formally known as Sunguard and SCT.
The Tennessee implementation of Banner is supported by the Board of Regents, UT Central office, and Ellucian contractors. Banner is used at almost all higher education schools in Tennessee.
Other ERP systems used at higher learning institutions could include Peoplesoft or SAP IRIS.

5. Banner INB vs SSB Banner INB – Internet Native Banner
The functional user Interface for accounting, human resources, and other administrative staff
Banner SSB – Self Service Banner
The web-based interface to Banner functionality for students & Finance reporting functionality
Banner INB includes an application server and database server. The database and application is tightly integrated. Banner INB is generally only available on campus and preferably only available to employees on campus. Banner INB is a higher risk, with lower availability.
Banner SSB includes a web server along with an application server and database server. Banner SSB is generally available anywhere there is internet. It is a lower risk, with higher availability.

6. List above is not exhaustive!
Banner INB Overview
Includes multiple distinct “systems” or modules:
Finance
Human Resources
Financial Aid
Advancement
List above is not exhaustive!
Forms within each module are usually designated by the first letter of the form name. Each module can be upgraded to different versions. Updates released by Ellucian can sometimes affect all modules and sometimes will be module specific.
Other modules exist, such as Student, as well as other third-party applications can be used to add onto the functionality of Banner or replace an existing module.

7. Banner INB Architecture
Distributed architecture generally includes:
Application Server
Database Server
Job Scheduling Server
Web Server (Luminis)
This is not meant to be a comprehensive list – only the basics
These servers can be placed in one data center, or spread among multiple data centers anywhere in the world. Hence the “distributed” name. We have seen many different configurations of these servers.

8. Banner INB Architecture
JAVA Web Form (in browser)
Application Server
Information by Oracle for Oracle Fusion Middleware Forms Services:
Index:
Oracle Forms:
Other servers may exist, such as a job scheduling server or business warehouse or other applications interfacing with Banner INB.
Oracle Database

9. 3rd Party Applications SciQuest E-Procurement Touchnet U.Commerce
Many available for varied purposes
Common 3rd Party Apps:
SciQuest E-Procurement
Touchnet U.Commerce
Third party applications can either be hosted by the school on their own servers, or hosted by the vendor/service organization. These third-party applications can either replace Banner INB processes or interface with Banner.
Makes it difficult to audit Banner INB with a one-size fits all approach!
Our review of Banner INB authentication and authorization will be primarily related to Banner INB and not third-party applications.

10. Authentication vs. Authorization
Authentication The process of identifying a user – usually by a user name and password
Authorization The function of specifying or granting access rights to resources in information systems
A very important distinction when considering logical access to an application. Authentication and authorization can be handled very differently.
The slide includes a definition of each term.

11. Authentication to Banner & 3rd Party Applications
Section 2

12. Banner User Accounts
When a user connects to Banner, that user also connects to the Oracle database
All Banner INB accounts require individual Oracle database accounts. Banner SSB accounts do not work the same way.
Banner INB authentication & authorization use Oracle database info & processes
Security is configured by granting privileges to a User Profile in Oracle
Banner SSB accounts are stored in a separate database “tablespace.”
A database account is used as an intermediary between the SSB tablespace and the database account (wtaylor).
NOT the same thing as INB/database accounts

13. User Authentication Details
Oracle uses a User Name & Password to identify a user
Stored encrypted in the SYS.USER$ Table
Authentication requires one Oracle privilege: CREATE_SESSION
Note: Oracle 11g uses SHA-1 hashing algorithm along with a “salt” to encrypt database passwords.
Oracle 10g and earlier used a simple MD5/DES hashing algorithm

14. Banner INB Authentication
Step 1
Enter user name/password
Step 2
Oracle checks credentials
Step 3
Oracle checks privileges/security rights:
Default Role(s)
Directly granted privileges
PUBLIC account privileges (granted to everyone)

15. Method 1: Direct Login

16. Banner INB Authentication
Method 1:
Direct Login
Oracle Database Password Profiles
Login to App Server directly via web browser
Method 2:
Web-Facing Portal
Directory Service Password Policies
Login to Luminis web server first, then connect to App Server VS

17. Banner Direct Login Page
Method 1: Direct Login
Banner Direct Login Page
Oracle Credentials
Direct login means that you are provided the URL to the Oracle Fusion login and can access the login page with simply an Oracle username and password.
Banner INB

18. Method 1: Direct Login Example URL:
Uses the internet browser and Oracle Fusion Middleware Forms Service - a Java JRE Plug-in to display the Banner Forms in an Oracle Java Applet
Example URL:
Information from Oracle for Oracle Fusion Middleware Forms Service:

19. Method 2: Web Server(Luminis)
Active Directory Credentials or LDAP
Luminis Web Server Login
Banner Direct Login Page
Oracle Credentials
Web server login, means that you are using some other means of authentication to get to the login page and might also be using a single sign-on method.
Banner INB

20. Method 2: Web Server(Luminis)
Luminis Web Server can use a directory service for user authentication
Login requires directory service credentials
Possible to configure as Single Sign-On or as another layer of network security.
Direct login via Oracle credentials may still be required!

21. Risks with Multiple Methods
All paths to authentication should have proper controls if both methods are used!
Method 1
Example:
Both methods allowed, but only one has password controls & users most frequently connect via this method
There is a risk if one of the methods being used can be circumvented.
Banner INB
Method 2

22. Oracle Password Profiles
DBA_PROFILES
PW Verify Function
“IF” Function for password complexity
V$PARAMETERS includes other security settings such as case sensitivity.
PROFILE
RESOURCE_NAME
RESOURCE
LIMIT
DEFAULT
FAILED_LOGIN_ATTEMPTS
PASSWORD
UNLIMITED
PASSWORD_LIFE_TIME
PASSWORD_REUSE_TIME
PASSWORD_REUSE_MAX
PASSWORD_VERIFY_FUNCTION
NULL
PASSWORD_LOCK_TIME
PASSWORD_GRACE_TIME

23. Active Directory Password Policy

24. Active Directory User Account Control (UAC)
UAC can override other group policy settings
Codes to consider:
Value
Description
512
Enabled Account
544
Enabled, Password Not Required
66048
Enabled, Password Doesn’t Expire
66080
Enabled, Password Doesn’t Expire & Not Required

25. 3rd Party App Authentication
Authentication for each 3rd party application can vary.
Must inquire about how authentication & security are configured.
Also, consider network security such as Virtual Private Networks (VPN)

26. Examples – 3rd Party Apps
SciQuest can be synchronized with Active Directory.
Uses AD credentials for authentication
Touchnet generally uses built-in security and authentication.
Unique login URL for each user
Unique Touchnet user IDs and passwords
Touchnet has its own password controls

27. Take-Away’s for Auditing
Look before you leap!
Identifying relevant control points is key.
Determine the layers of network security
All Banner INB accounts can access the Oracle database directly – increases risk!
Notes:
Gaining an understanding of the “layers” of network security (if there actually are any) can affect the risk posed to the Banner INB application/database.
The Banner INB application and its database are inherently subjected to more risk than a different type of application that is not as “tightly coupled” with its database. For example, all Banner INB users must connect to both the Banner application and the underlying Oracle database when they connect to “Banner INB”. Other applications – such as PeopleSoft which also uses an Oracle database – do not require application users to actually connect to the database itself (but instead, they connect to a web server which communicates with the back-end Oracle database through an application server).
It is important to keep this concept in mind when auditing Banner since a “small” security problem could actually pose a much larger threat to a Banner/Oracle environment than other application/database environments due to the fact that there are many more avenues for accessing the Oracle database, and simply more users at the database level (even if most do not actually connect directly to the database through an SQL prompt routinely). Finally, it is also important for an organization using Banner to attempt to limit and/or monitor access to the Oracle database directly through an SQL prompt (or some other tool such as Putty, etc.) since all “application” users with access in the Banner INB application will have at least some level of privilege at the Oracle database level.

28. Authorization in Banner & 3rd Party Applications
Section 3
Your system administrator has determined that your current activity is providing a level of enjoyment beyond that which is allowed on company time. Your enjoyment will now be disabled. You may continue with this activity, but you may not enjoy it. See your system administrator for more information.

29. Banner Security
Oracle database security structures serve as “building blocks”
Oracle security configuration can either strengthen or undermine security
Database privileges largely determine what a user can or cannot do in Banner
When a user connects to “Banner”, that user also connects to the underlying Oracle database

30. Banner Security Basics
Banner uses “Role-based” security
Banner “Roles” = Oracle Roles
Containers for Oracle system privileges
Can be password-protected
A Banner “Class” is used to group Roles & database objects together in one container

31. Banner Security Basics
Banner CLASS
However, Banner objects can also be directly granted outside of a class; increases risk of security being undermined.
Role
(Oracle Privs.)
OBJECTS
A banner CLASS is like a container that holds groupings of Role-Object grants.
Within a Class, Roles (groupings of Oracle Privileges) are associated with Database objects (this is a broad term that includes Banner “forms” and many other process and programs).

32. Banner Security Basics
BANNER CLASS
Role
Access Level
Banner Object/Form
BAN_DEFAULT_M
Read/Write
FOMPROF
FAAINVE
BAN_DEFAULT_Q
Read Only
GSASECR
Banner Classes are containers for Role/Object assignments
Banner Classes are containers for Role/Object assignments.
Users are assigned to Classes to stream-line security management

33. Banner Security Basics
Users are assigned to Classes to stream-line security management
Banner Class
User
User
User
User
Banner security manuals recommend that security administrators use Banner classes to manage security instead of assigning all Banner INB users privileges and objects directly since this can easily become unwieldy.

34. Oracle roles are used in two different capacities in Banner
Just “Role” with it!
Oracle roles are used in two different capacities in Banner
(1) Banner Classes
When associated with “objects” in a Banner Class
For Navigational Security
“BAN_DEFAULT”
(2) Default Roles
Controls “default” privileges upon login
Oracle security construct
“USR_DEFAULT”
A default role is invoked upon a user’s initial login to the database/Banner if it is NOT password protected (11g).

35. (1) Roles for Banner Classes
Banner roles for Classes & Navigational Security:
BAN_DEFAULT_M*
Full read/write access
BAN_DEFAULT_Q*
Read-only access
*These roles are created upon Banner installation with an encrypted password that no human knows!

36. (2) Banner Default Roles
Banner-created Default Roles
USR_DEFAULT_M
Full read/write access
USR_DEFAULT_Q
Read-only access
USR_DEFAULT_CONNECT
Ability to connect to the database/Banner only; provides no navigational access
*Note – none of these roles are password protected; more on that soon!
Note: The “USR_DEFAULT” roles were created by the Banner vendor to address changes to certain role security functionality that occurred in the transition from Oracle 10g to Oracle 11g database versions.
Oracle 10g: A user granted a password-protected role as DEFAULT would still be granted that role upon logging into the database; the user would NOT need to enter the password to “unlock” the role.
Oracle 11g: A user granted a password-protected role as DEFAULT must enter that role’s password using the “SET ROLE” SQL statement before that role will become active for that user.
Since the “BAN_DEFAULT” roles are password protected with encrypted passwords that no human knows, these roles are essentially useless as default roles and present no risk. The USR_DEFAULT roles were created for the explicit purpose of being used as Default Roles to circumvent this change in the way that Oracle handles default roles. However, these roles do present a potentially greater risk if assigned as a DEFAULT role since they will be “activated” when the user initially logs into the database.

37. Role Details – Oracle System Privileges
USR/BAN_DEFAULT_M
CREATE SESSION
SELECT ANY TABLE
EXECUTE ANY PROCEDURE
SELECT ANY SEQUENCE
UPDATE ANY TABLE
SELECT ANY DICTIONARY
DELETE ANY TABLE
INSERT ANY TABLE
LOCK ANY TABLE
USR/BAN_DEFAULT_Q
CREATE SESSION
SELECT ANY TABLE
USR_DEFAULT_CONNECT
CREATE SESSION
Connect Only
“Read only” Access
Oracle Roles act as containers for Oracle system privileges. Oracle system privileges are some of the basic “building blocks” of security permissions in the Oracle database. Oracle system privileges are pre-defined by Oracle and cannot be changed. Each system privilege allows an assigned user to perform one or more distinct actions in the database.
Below are a few privileges of note:
CREATE SESSION – allows a user to connect to the database, but nothing more.
SELECT ANY TABLE – provides a baseline of “read-only” access
System privileges with the word “ANY” in the name are generally more powerful privileges, and privileges like “UPDATE ANY TABLE” or “SELECT ANY DICTIONARY” should be assigned with care.
These privileges provide full “write” access.

38. Banner Form Authorization
Step 1
Navigate to a Banner form
Step 2
Banner Checks for an Oracle role
E.g. BAN_DEFAULT_M
Step 3
Banner Checks for the “object”
Step 4
Banner Decrypts Oracle Role Password
This “activates” the role’s privileges only for that object
Step 5
Access to object granted based on Role’s privileges
E.g. BAN_DEFAULT_M = full read/write access

39. Banner Security & Default Roles
Banner security manuals recommend that all users be assigned one Default Role
USR_DEFAULT_CONNECT
Assigning powerful roles as “Default” can create security risks
Note: In Oracle 10g, if a user was assigned a default role that was password protected, that role (set as DEFAULT) would be automatically invoked/activated when the user initially logs into their account. However, in Oracle 11g, things changed so that password protected default roles must still be invoked manually with the SET ROLE SQL statement.
This is why Banner introduced the USR_DEFAULT_M, USR_DEFAULT_Q, and USR_DEFAULT_CONNECT roles to be used as default roles. These roles are NOT password protected so that the privileges embedded inside these roles can be activated automatically when a user logs into their account.
The BAN_DEFAULT_M, BAN_DEFAULT_Q, and BAN_DEFAULT_CONNECT roles ARE PASSWORD PROTECTED and thus cannot be used as default roles in an Oracle 11g database. These roles are created within the Oracle database upon the installation of the Banner application. When these roles are created, they are created with a randomly generated password that no human being knows (and the passwords are encrypted). Thus, because these roles are password protected with passwords that no one knows, no human can activate these roles as default roles with the SET ROLE statement.
The implications of this condition are that users assigned BAN_DEFAULT_M, BAN_DEFAULT_Q, or BAN_DEFAULT_CONNECT as Default Roles will NOT have any access to the database or Banner through these roles being assigned as default roles since they are password protected. Thus, there is no risk associated with a user being granted BAN_DEFAULT_M as a default role since the user cannot invoke this role’s privileges.
However, the USR_DEFAULT_M, USR_DEFAULT_Q, and USR_DEFAULT_CONNECT roles are viable to be used as default roles and will grant access to the database for users assigned these roles as default roles since they are NOT password protected.

40. Password Protected Roles
Roles that are Password Protected in Oracle (11g) must be invoked at an SQL prompt, even if assigned as DEFAULT
SET ROLE Statement with the password
No user can manually invoke the BAN_DEFAULT roles because no one knows the system-generated passwords.
Note:
The BANSECR.GUBROLE table contains a listing of all database roles, and the passwords for those roles, that are recognized as usable in the Banner application.
For more information about Oracle roles and passwords, see the following link:
Also, the Banner 8.3 Security Administration Guide has the following (lengthy) explanation of roles and naming conventions that address the topic of passwords for certain roles:
Role Naming Conventions
The roles that can be created, maintained, and used with Banner objects must adhere to
strict naming conventions. First, roles must begin with either BAN_ or USR_. (Only roles
that begin with one of those two prefixes will be visible in the role maintenance tab.)
Roles that begin with the prefix BAN_ will automatically be password-encrypted for use
with a Banner object. Roles that begin with USR_ are not password-encrypted and may be
given to users as default roles. This default role would then define the tables and views the
user can write ad hoc reports against.
The roles to be used with Banner objects must follow one of the following two patterns:
BAN_DEFAULT_something or BAN_objectname_something.
This standard is enforced in the security maintenance form. It is also implemented in the
LOV that displays the roles that can be used with a specific form. The BAN_DEFAULT
roles can be used with all forms while the BAN_objectname roles can be only used with
the specific object. Both BAN_DEFAULT and BAN_objectname roles will be given a
random password when they are created.
Roles that begin with USR_ will not be given a password and must be used as user default
roles, not roles to be associated with Banner objects.

41. Banner Default Role Risks Scenario #1
BAN_DEFAULT_M as a Default Role?
Low Risk!
BAN_DEFAULT roles are password-protected w/ system-generated, encrypted passwords.
Notes:
Since BAN_DEFAULT_M is created with a randomly-generated password that no human knows, end users cannot “activate” this role – meaning there is little to no actual risk associated with the assignment of BAN_DEFAULT_M (or _Q for that matter) as a default role.

42. Banner Default Role Risks Scenario #2
USR_DEFAULT_M as a user’s default role?
Risky!
Grants the user full write access to everything in Banner/Oracle that is not protected within another “schema”
A Schema is “owned” by a database user & has the same name as that user.
A Finance Department user granted USR_DEFAULT_M as a default role would probably have full access to all Finance department data, and the data of all other departments – with some exceptions.
We have seen some organizations use an application called “Spreadsheet Budgeting” that managers/directors primarily used. This Spreadsheet Budgeting application required end users to have “Write” access to the underlying table(s) that the application interacted with. As a means of making the application work smoothly/easily, some organizations have granted their Spreadsheet Budgeting application users a default role of USR_DEFAULT_M so that those users can “fully utilize” the application’s functionality. However, some of these organizations had not even considered the risk of assigning their HR, Finance, or other personnel such high levels of access in Banner.

43. BANSECR & GSASECR
BANSECR = default Banner security administration account
Only BANSECR can access or execute the GSASECR (Security Maintenance) form
“Distributed Security Administrators” can also access GSASECR
Note:
The GSASECR form is “owned” at the database level by the BANSECR account – this can also be understood as the GSASECR form is part of the BANSECR “schema” in the Oracle database. Only the BANSECR account, or other accounts with names that begin with “BANSECR_” may access the GSASECR form even if accounts are granted apparent access to the GSASECR form through Banner classes or direct grants.
Thus, the naming scheme for Banner accounts should be controlled to ensure that no unauthorized users are given “Distributed Security Administration” privileges through the creation of accounts that begin with “BASNSECR_” (the account would still need to be given navigational access to the GSASECR form through Banner class(es) or direct grants of privileges).

44. Authorization in 3rd Party Apps
Depends upon the application!
Example:
Touchnet & SciQuest use internal security structure
Most 3rd Party apps are configurable to some extent.
Gain an understanding of how they are used and what steps are controlled in Banner vs. 3rd party app.
Both SciQuest and Touchnet have internal “security structures” that require the assignment of specific privileges based on a user’s job responsibilities.
In SciQuest, the configurable “workflow” primarily controls the required approvals for a given purchase request, and users must be assigned the ability to approve certain purchase requests based on business rules and needs.
Touchnet generally uses something equivalent to a “role” to assign privileges to end users (i.e. cashiers) but these should likewise be created and assigned based on business rules and users’ job roles.

45. Relevant Data for Audits
Obtain security data for Banner/Oracle
Key Tables Include:
Obtain 3rd Party App security data
May require coordination with the vendor
Table Name
Description
DBA_USERS
Listing of Database Accounts/Status
DBA_ROLE_PRIVS
All database accounts/default roles
GUVUACC
“Object Access by User View” = All Banner Accounts, Classes, Objects, & Roles
Note:
The listing of tables in this slide is not nearly comprehensive for a full information systems audit of all aspects of Banner security and especially Oracle security.

46. Take-Away’s for Auditing
Determine who has access to BANSECR
Evaluate accounts assigned USR_DEFAULT_M or _Q as a Default Role
Evaluate users with access to make changes on other security forms like FOMPROF, Finance Security Maintenance Form
Only the database administrator and/or designated security administrator should have access to (i.e. know the password to) the BANSECR account since this account has full access to the Banner security menus (GSASECR). Additional security administrator accounts can be created, called “Distributed Security” accounts, that begin with “BANSECR_”. Because these accounts have “BASNSECR” at the beginning of the account’s name, these accounts are “authorized” to access the BANSECR schema and the GSASECR (Security) forms. For example, if Tom works as a distributed security administrator for the human resources department, he may be assigned a secondary security administration account called “BANSECR_TOM”.
Most user accounts should not be assigned USR_DEFAULT_M as a default role since it provides high levels of access (i.e. read/write) to most aspects of Banner and the Oracle database – but NOT the GSASECR form which is “owned” by the BANSECR account (the concept of a database schema protects the GSASECR form so that only the BANSECR account can access it).
The FOMPROF, Finance Security Form, is where many Finance module-specific security settings can be configured – both at a global level and for individual Banner INB account. The FOMPROF Form can also be used to configure reporting access in the Banner Finance SSB system. Access to FOMPROF should generally be limited to the Finance department personnel designated/authorized to be responsible for managing security in the Finance department. Generally, the IT department personnel do NOT need to have the ability to make changes on FOMPROF if responsibility for managing the FOMPROF form is delegated to specific personnel in the Finance department.

47. Take-Away’s for Auditing
User Authorization Documentation
Consider how the entity documents user access:
By Role/Object or by Class?
Consider whether specific “access levels” (i.e. classes) are requested and that requests are not for access “like” an existing user.
Note: In Banner, there is a built-in feature whereby the security administrator (i.e. the person(s) with access to the BANSECR account) can create a new Banner account that is a “clone” of an existing account.
Because this feature exists and makes it very convenient to “clone” an existing user’s access to a new user, we have seen some institutions indicate on User Authorization Forms/Requests to provide a new user with access “like” an existing user.
Best practices generally recommend that access level changes for system users be documented and that the specific levels of access are documented – not just a generalized statement to give Person B the same access as Person A. This practice may increase the risk of assigning a user excessive levels of access in the system.

48. Take-Away’s for Auditing
Periodic Review/Reauthorizatioin
Consider auditing how management monitors Banner access:
Review of classes granted to users
Review of terminated user access
Review of objects granted directly to users
Note: In Banner, there is a built-in feature whereby the security administrator (i.e. the person(s) with access to the BANSECR account) can create a new Banner account that is a “clone” of an existing account.
Because this feature exists and makes it very convenient to “clone” an existing user’s access to a new user, we have seen some institutions indicate on User Authorization Forms/Requests to provide a new user with access “like” an existing user.
Best practices generally recommend that access level changes for system users be documented and that the specific levels of access are documented – not just a generalized statement to give Person B the same access as Person A. This practice may increase the risk of assigning a user excessive levels of access in the system.

49. Final Thoughts
Banner & Oracle are “tightly coupled” – creates security enhancements & risks.
Banner security can be bypassed through poor Oracle database security
Third-party applications may require extra audit effort to understand; don’t forget about SOC/SSAE 16 Audit Reports!

50. That’s All Folks! Questions? Jeff White – Jeff.White@cot.tn.gov
Timothy Hollar –