Welcome to the course: T24 Introduction to SMS

Security Management System R16 1

 Here is the agenda for this course

Security Management System R16 2

 The objectives of this course are:
- To understand SMS in T24
- To define the User in T24
- To configure the User as Individuals and as Groups
- To set Permissions based on User Roles
And finally to discover how to administer User Profiles

Security Management System R16 3

 We will start by understanding SMS in T24

Security Management System R16 4

 Why does the Security Management System need to be a part of T24?
Irrespective of where you work today, you have a role to play in your
organisation. You can perform certain functions, and you are restricted from
performing others. In a bank, there are different job profiles that an
employee can have. For example, one can be a Teller or a Loan Manager.
Now should a Teller be able to disburse a loan? Will certain employees even
be allowed access to T24?

The software that the bank uses must be able to control who can gain
access to the data and what an employee can and cannot do once logged
in. You are going to learn how this is done in T24.

Security Management System R16 5

 There are many aspects to security which you as an overseer of the banks
data has to ensure, is adequately provided for. Authentication and
authorization are two of those security aspects Authentication is the
process of verifying the credentials of the user to gain access to the web-
application i.e., T24. This evidence is supplied as a login id and password by
the user. Authorization follows authentication. It checks whether the
authenticated user has the sufficient privileges to access the specific
application and the data accessed through the application.

Security Management System R16 6

 Three authentication options are provided for both online access to T24 by
a customer as well as internal access to T24 by a bank employee

1) Authentication handled by T24 - SMS

2) Authentication takes place using standard Web/App Server

functionality with no change to T24 . Web Application Servers come
with their default authentication mechanisms like BASIC, DIGEST etc.

3) Authentication takes place using proprietary mechanisms (e.g.

external authentication servers). Authentication servers are
servers that provide an additional strong authentication service
to users. The web application servers authenticate to such a server,
and receive cryptographic tickets(biometric data, fingerprint, digital
signature etc). These tickets are then exchanged with one another to
verify identity. ActivIdentity and RSA are third party authentication

Security Management System R16 7

 servers which provide Customer Identity protection and access
solutions

Security Management System R16 ‹#›

 T24 doesn’t stop with just validating the user and their password, the validation
process continues even after a user logs in successfully. Any function that a user
tries to perform is tracked. The user can only proceed if they have the necessary
permissions. Before the bank allows all users to log in and use T24, it must decide
on their user privileges in the system.
When a user tries to access or amend a record in any application, T24 verifies if
the user has the privilege to do so. Verifications include whether the user has
access to the respective functions and applications. Here, the user will encounter
T24 SMS for the second time.
To validate a record created, the user will click on the Validate button. The T24
application may reference various static tables of data to complete the record.
The user does not need to have implicit permission to do so. This is not part of
T24 SMS. On Commit the record is stored in the unauthorised file.
Every record in T24 must be authorised. When a user tries to authorise a record,
T24 must check to see if the user has the authorise permission for the
application. A User will not be allowed to authorise the record with insufficient
permissions.
Once the record is authorised, the record moves to the authorised file.
Static information, such as accounting entries, could be updated at this stage.
Close of Business is the process which does not need any user intervention and
hence no SMS check is required. The user administering COB must have the
relevant SMS setting for COB related applications.
SMS comes into the picture even if you want to execute an enquiry in T24. In
other words, even though you only want to view data, you must have the
necessary permissions to do so.

Security Management System R16 8

 We will see how to define user profile, we will start with an overview

Security Management System R16 9

 Authentication is the process of verifying the credentials of the user to gain
access to T24. This evidence is supplied as a login id and password by the
user.
To log into T24, a user needs to input a valid sign on name and password,
which are both masked when typed.
T24 validates the sign on name and password entered. If the data entered is
valid, the user is allowed to access the system or an error message is
displayed.
This verification is the first instance where the T24 SMS activity happens.
The login details are stored in an application called USER which T24 uses for
user authentication. A user profile needs to be created using this
application to enable access to theT24 system.

Security Management System R16 10

 Authorisation in T24 is performed at 5 levels. Verification for sufficient
privileges is done first at an Entity level – i.e., Whether the user logged into
a Branch has the required rights to perform the requested operation in that
Branch. Verification is also done at the time of access to applications (e.g.
FT, MM), versions and enquiries – i.e., whether the user has the rights to
access the requested application, specific version or enquiry. If the
application is accessible, then an authorisation check is run to see if the
function is allowed for the specific application and user(e.g. allow Input and
Display only and not ‘A’ function for the user). You may also define the field
values that can be accessed (e.g. allow access to only records with amount
< 10,000). Logging can be specified, from simply, recording sign on/off times
to recording every access the user makes.

Security Management System R16 11

 The Inputter is the person who inputs the data into the fields of a record.
This user must have access to the Input function.
The Authoriser is the person who checks the record and authorises it. This
user must have access to the Authorise function.
The error message displayed at the bottom of this screen shot will be
displayed if the same user tries to both input and authorise the same
record.
The Comma version of an application enables the same user to create and
authorise the record at the same time
For example, by entering ACCOUNT, I F3 in the Command line, a new
Account will be created. Commit will authorise the record.

Security Management System R16 12

 Any person who wants to access or key in data into T24 must have a user
profile. T24 User profiles are created in the USER application.
The USER profile will contain details about the User. Details will include:
Identification data such as the user’s name, Branch and Department
Access times which tell us when the User is allowed and when the User is
prohibited to access the system.
Permitted activity which tells us what the user is allowed to perform in the
system and which applications can be accessed.

Security Management System R16 13

 We will now see how identification happens

Security Management System R16 14

 To create a record in T24, you need to input all the mandatory fields and then get the record
authorized.
To create a user in T24, you will need to create a record in the USER application. You will now
learn how to create a simple USER profile. To create a user record, type USER and the ID of the
record you want to create in the command line.
USER ID and the USER NAME can be the same but the SIGN ON NAME has to be different from
the USER ID.
The ID can be alphanumeric.
The USER NAME contains the full name of the user.
The SIGN ON NAME will be used to sign into T24. Again, this has to be different from the ID.
The PASSWORD is part of the user profile. It is encrypted at the database level and is not
displayed as part of the record in the USER application.
CLASSIFICATION can be internal or external. Internal indicates that the User is an employee of
the bank using T24. External classification is now obsolete.
The LANGUAGE selected in the language field will dictate the language of objects like user
messages, instructions and help text. If no selection is made, then English will default. The
language codes are pre-defined in the LANGUAGE table. T24 supports up to 12 languages. These
can be expanded to 99 using EB.DICTIONARY.
T24 allows the user to access multiple companies as it supports MULTI COMPANY set up.
COMPANY CODE specifies the companies to which the user has access. The first company code
specified here will be the default company to which the user will be logged into. The companies
defined in a T24 installation can be found in the COMPANY application. The keyword ALL can be
used to give access to all companies.
All users must belong to a department in the Bank. Department Codes must be predefined in the
static table DEPT.ACCT.OFFICER. The purpose of this table is to identify each Department and
Account Officer in the bank by means of a code.
DEPARTMENT CODE specifies the department to which the user belongs.

Security Management System R16 15

 We will learn about the Permitted Use of Time concept

Security Management System R16 16

 It is advisable in any software to force the user to change their password
periodically. This is to minimize the possibility of fraud from happening
because of using the same password for extended periods. T24 allows the
user to specify the password validity date and the frequency of when to
change the password.
The PASSWORD VALIDITY field specifies the next date on which the User
must change his Password and the subsequent frequency of change after
that. The Next Change Date entered, must be greater than today's date and
not more than 6 months from today. The date until which the password is
valid is followed by the frequency of change.
Let’s interpret the data found in the Password Validity field on the screen
shot presented. The current password will be valid until October 1, 2012.
On that date, the user will be prompted to change his password. M06
stands for every six months. 01 stands for the first day of the month. The
next change date after this would be April 1, 2013.

Security Management System R16 17

 There are fields on the USER application that control the validity of the user
profile. The validity period is controlled by the following fields.
The START DATE PROFILE is the date from which the profile of the user will
be active. The User will be able to login into T24 from this date onwards.
This field takes the server date and not the T24 date. The date entered in
this field should not be less than today’s server date.
The END DATE PROFILE is the date until which the user profile is active. The
user will not be able to login into T24 after this date.
If a user has access to T24, would the bank want to give him 24 hour access
to the system? Maybe not, in most cases the working hours of the bank will
determine when a user will be allowed to use the system. The fields Start
Time and End Time control the time span in a day when the user can log in
to T24.
The START TIME is based on the 24 hour clock.
The END TIME is based on the 24 hour clock as well. Irrespective of the time
specified here, if the user is logged in to the system, he will be allowed to
continue accessing T24. However, once logged off, the user will not be
allowed to login after the time specified in this field.
The start time and end time fields form a multi-value set, enabling multiple

Security Management System R16 18

 periods of time to be defined per day.

Security Management System R16 ‹#›

 A Bank may decide to not permit its users to login to the system outside of its
working hours. It may even limit the user’s access to specific time periods for
specific days of the week. These restrictions can be made using the following
associated multi value set.
The ALLOWED DAYS field is used to restrict the access to T24 to particular days of
the week. You can choose a number from the drop down list which contains
values from one to seven. Each number represents a day of the week starting
from Monday. The numbering is such that One is for Monday, Two is for Tuesday
and so on.
The DAY STart TIME field indicates the start time of the user’s access to T24 on a
particular day.
The DAY END TIME field indicates the end time of the user’s access to T24 on a
particular day.
The example displayed in this screenshot tells us that the User can access T24 on
Monday from 08:00 to 12:00, will have no access between 12:00 to 13:00 in the
afternoon and then have access from 13:00 to 17:00 in the afternoon
This User has no access at all on Tuesdays.
On Wednesdays this User can access T24 from 08:00 to 12:00 and 13:00 to 17:00
This user would not have access to T24 on any other day of the week besides
Mondays and Wednesdays.
If anything is specified on Allowed Days fields then the system ignores the times
specified on START.TIME and END.TIME. The Allowed Days fields take
precedence.

Security Management System R16 19

 There are times when a User working in T24 might leave his computer
unattended. He might forget to log out of T24 and simply walk away from his
machine. No other user should be allowed to take over the machine and work
with someone else's User profile. For these types of scenarios, T24 supports the
concept of a Time Out period. The Administrator can specify the number of
minutes which the user can be inactive without actually working on the system. If
this time limit lapses for the user, then he is automatically signed off from T24.
This is done as a safety precaution
The TIME OUT MINUTES field specifies the maximum time in minutes during
which the User may be inactive without being Signed Off automatically. Once this
time limit is reached the user is not allowed to perform any other action. The
user is forced to login again to perform any action in T24. The Maximum value
that can be set in this field is 999 minutes.
Most systems that require a user name and password, have a check on the
number of times that a user can incorrectly type in a password. After exceeding
the number of attempts the account is locked. The user is then forced to reset his
password. T24 also supports this functionality. It allows the administrator to
define how many unsuccessful sign on attempts a user can have before the
system locks his account. This helps to safe guard the profile from hackers.
The ATTEMPTS field allows only one numeric character for input. The maximum
number of attempts that can be set is 9.

Security Management System R16 20

 We will now see the permitted activities

Security Management System R16 21

 For all Users, we can specify what can be accessed and performed in T24 at
four levels. These four levels are
• COMPANY
• APPLICATION & VERSION
• FUNCTION
• FIELD
The COMPANY RESTRiction field contains a valid company code. This is used
to specify a Company in which we want to set access rights for a User. This
company should be defined as part of the COMPANY CODE field. “ALL” will
allow the user access for all companies listed in the COMPANY.CODE field.
The APPLICATION field can contain a valid application name which the User
can access. ALL.PG implies that the user will have access to all applications
in T24 in the company specified in the field COMPANY RESTRiction

Security Management System R16 22

 A VERSION is the T24 screen which can be accessed. The Application specified in the Application field can
only be accessed via this Version in this Company.
The FUNCTION field is where we list the valid functions that the user can PERFORM in this Company.
Typing ALL in this field will give access to all the functions in T24. When the record is committed it will
display the values as indicated in the screen shot.
‘A’ is a function which allows the user to authorize a record.
‘2’ is used to indicate second level authorisation. For a User to authorize a record in INA2 Status, a value of
2 needs to be set in the FUNCTION field of their USER profile.
‘B’ is used for moving Backwards. This function is not available in Browser, but is available in Classic
‘C’ is a function which allows the user to copy a record.
‘D’ is a function which allows the user to delete a record which is not yet authorized. Take note that a live
record cannot be deleted.
‘E’ function allows the user to list the unauthorized records.
‘F’ is used for moving Forwards. This function is not available in Browser, but is available in Classic.
‘H’ function is used to move a record from history to live file. This is also known as History Restore.
‘I’ function allows the user to input or edit a record in an application.
‘L’ function is used to list live records
‘P’ is used for printing
‘R’ is used to reverse a record. Once a record is authorised it cannot be deleted. It can only be reversed.
‘S’ allows the user to view the records.
‘V’ is a special function which is supported only by some applications in T24. It is used to produce some
extra information and also performs some extra actions. V function is known as verify function
‘Q’ stands for Audit Review. It is a special function reserved for Auditors. The Q function does not appear
by default. If required, it must be added separately.

Security Management System R16 23

 Could you set a more refined restriction for a User? Imagine restricting a user based on data
values from the records that the user is going to try to access. Is this possible in T24?
The answer is Yes.
This type of restriction can be achieved by using the fields from COMPANY.RESTR to DATA.TO.
These fields form a multi value set. The field COMPANY.RESTR can have the company code
which the user will be allowed to access.
The APPLICATION field will hold the name of the application which can be accessed by the user.
The FUNCTION field will hold the function which the user can perform in the specified
application.
FIELD NO is used to specify the field from the application which will be used for comparison.
There is a special way to specify this field name. That is by using the syntax ‘Application Name’
followed by the ‘Greater than’ sign and then the ’Field Name’
The DATA COMPARISON field must contain a valid operand that you wish to use for the
comparison. The different operands available are
EQ, which stands for Equal To. This operand can also be used to specify a range of values.
GE stands for Greater than or Equal To
GT stands for Greater than
LE stands for Less than or Equal To
LT stands for Less than
NE stands for Not Equal To
LK stands for Like
And UL stands for Unlike
The DATA FROM & DATA TO fields are used to indicate the actual Values of the data for
comparison. In the screen shot displayed, the Field No is based on SECTOR. Therefore in DATA
TO we are comparing to SECTOR 1000. If the SECTOR of the CUSTOMER is not equal to 1000
then this User would not be able to access the Customer record.

Security Management System R16 24

 The Application field is used to specify which application the User can
access. By specifying ALL.PG in this field, the user will have access to all
applications in T24 in that Company. The Functions with which the User can
access these applications are mentioned in the FUNCTION field. There are
two ways to setup the system when using the ALL.PG functionality.
The first method is the standard method. It is also known as the exclusive
method.
The second method is the non-standard method, also known as the
inclusive method. More about this on the next screen.

Security Management System R16 25

 Let us start by understanding the standard mode. This is also known as the
exclusive mode. Under this setup, the field ALL.PG.INC on the SPF is either
blank or set to NO. How does the system behave under this setup?
In the first screen shot displayed, we have a User that has ALL.PG. The
functions are defined in the second screen shot within the Function field.
That is how the first set of multi-values is setup. On the second set of multi-
values, we have ACCOUNT in the application field where the Functions are
only I A S D.
This implies that for all applications, the user has all functions, but for the
ACCOUNT application, the user only has I A S D functions. Because
ACCOUNT is specified separately its functions override the functions on the
first multi value set.

Security Management System R16 26

 We will now learn about the non-standard mode. This is also known as the
inclusive mode. Under this setup the field ALL.PG.INC on the SPF is set to
YES. The system will now behave differently.
In the screen shot displayed, we have a User that has ALL.PG and functions
P L S are defined. That is how the first set of multi-values is setup. On the
second set of multi-values, we have ACCOUNT in the application field but
only I A D functions. This implies that for all applications the user has P L S
functions, but for the ACCOUNT application, the user has P L S plus I A D
functions. Any application specified separately will have its own functions
plus the functions specified on the ALL.PG multi-value set. This is why it is
called the inclusive mode.

Security Management System R16 27

 In T24, there is a provision to assign Menus to Users based on their role or
job profile. We can create separate Menus for different groups of Users
based on what they are required to do.
The INIT APPLICATION field is used to assign a specific Menu to a User. This
is the Menu the User will see when he signs on to T24. The ID of the Menu
is prefixed by a question mark. If left blank, then Menu number one is
allocated to the User. Menu number one is the default Model Bank Menu.

Security Management System R16 28

 The CLEAR.SCREEN field is only used by the CUI Interface and it is a
mandatory field.
When this field is set to ‘YES’, the screen will be cleared after a transaction
is committed.
If this field is set to ‘NO’, then the record will still display on the screen after
a transaction is committed

Security Management System R16 29

 The next section covers activity logging

Security Management System R16 30

 All actions performed by a user may or may not be logged. PROTOCOL is the
file in T24 which stores the activity logging information of a user. We can
decide on the level of logging required for a User. If you want to record all
the actions performed by the user, the following fields would have to be set
to YES.
The first field is SIGN ON OFF LOG. If set to YES, the user’s sign on and sign
off details will be logged.
If yes is selected for SECURITY MGMT L., T24 will log when the user
accesses the PASSWORD (Used to change companies), PASSWORD.RESET,
and USER files of T24 SMS
If YES is selected for APPLICATION LOG, then details of applications that the
user uses are logged.
When YES is selected for FUNCTION ID LOG, the system will log the
functions and the IDs used by the user.
Take note that even when these settings are all set to NO, any unsuccessful
attempts are always logged. This file is updated by T24 and therefore
records can only be viewed and not edited.

Security Management System R16 31

 Sample of protocol logs of an enquiry and transaction performed by the
User through Browser.

To log the enquiries that a user executes, the APPLICATION.LOG in the USER
profile must be set to yes. When an enquiry is executed with selection
criteria, the remark field is updated with the remark
ENQUIRY.SELECTION.DETAILS and the selection criteria information is
captured in the fields Selection Field, Operand and Value. For a successful
transaction, the remark field is updated with
TRANSACTION.SUCCESSFUL.COMMIT. The PW Activity Transaction ID is also
logged for PW transactions.

The company specific COB job EB.CLEAR.FILES clears these logs based on
the Company ID field.

Security Management System R16 32

 The field Txn.Commit.Log is useful when all static changes performed by the
user across all applications during a business day has to be recorded and
reported through an enquiry. This does not require the application or
function fields to be set, but logs ‘all’ transactions to PROTOCOL on commit.
“TRANSACTION.COMMIT” is written into the remark field in PROTOCOL.
The Curr No value is appended to the transaction ID reference, to identify
which version of the record is amended.

Security Management System R16 33

 The enquiry USER.ACTIVITY.REPORT takes information from PROTOCOL to
display a specific user activity. USER.ACTIVITY.REPORT.ALL displays the
report for all users.

Security Management System R16 34

 The ATTEMPTS SINCE field indicates the number of unsuccessful attempts
to SIGN.ON since the last successful SIGN.ON. It is displayed on the SIGN.ON
screen.
The DATE.LAST.SIGN.ON indicates the date that this User last Signed On
successfully. It is displayed on the SIGN.ON Screen.
This date is the actual date on which the User Signed On. This is the server
date and not the T24 date
The TIME.LAST.SIGN.ON indicates the time at which this User last Signed On
successfully. It is displayed on the SIGN.ON Screen.
PASSW CHANGE DATE: Indicates the date on which the password was last
changed.

Security Management System R16 35

 And now we will see the User Attributes

Security Management System R16 36

 INPUT.DAY.MONTH is used to indicate how the user prefers to enter dates
into T24. Does he start with the Day followed by the Month or the Month
followed by the day? There is normally a preference which is dependent on
the Country where the User is situated.

Security Management System R16 37

 The AMOUNT.FORMAT field specifies the separators to be used when
formatting amounts. This applies for amounts in Enquiries, reports and
screen displays. The amount separator can be a comma, full stop or
apostrophe. The decimal separator can only be a comma or a full stop.
Input into the Amount Format field is restricted to a two character pair. An
example is displayed in the screen shot, which is ,.
The first value, which is a comma, is the separator used for, say, amounts of
millions and thousands. The second value, which is a period, is used as a
decimal separator.

Security Management System R16 38

 The PRINTER For Rpts field contains the name of a T24 printer to which
reports will be spooled and printed. Printer names specified in other report
generation specific applications take priority over this. The Printer is set up
using the application PRINTER.ID in T24.
The field Printer For P Func contains the name of a T24 printer to which
reports will be spooled and printed when the user uses the function P to
print.
GB USER.ADDR is the address that will be printed on the report banner
page. This only applies for reports generated during the Close of Business
run. Each multi-value represents one line on the banner. A maximum of
three lines can be used. If left blank then the delivery point from the
DEPT.ACCT.OFFICER file is used.
RPT TO RECEIVE contains the name of the reports this user is to receive
from the over-night batch run. This must be a valid entry on the
REPORT.CONTROL file.
RPT.COPIES is the number of copies this user should receive.

Security Management System R16 39

 The ATTRIBUTES field can be used to set attributes for a User. These control how the User behaves in T24.
It can be used to control access to certain functionalities. We will now look at these briefly.
Branch Manager is only used under Branch Resilience to allow the administrator to Switch Users from
Central Server to Branch Server and vice versa.
COMMAND.LINE will state if the user is allowed the use of the command line in T24 Browser.
COMMIT.DETAILS Displays a list all the files that are updated after a User commits a transaction. This can
be used as a diagnostic tool when trouble shooting.
DEV.STUDIO is reserved for future use.
ENQUIRY.INDEX allows access to the enquiry index
EXPLORER allows the user to use the Application explorers
LOCK.DEACTIVATION prevents USER access to the User Deactivation listed in the Tools dropdown list.
LOCK.DESIGNERS prevents USER access to the Designer Tools dropdown list.
LOCK.MISC.ITEMS will bring up a Security Violation when the User Abbreviations Toolbar, Enquiry and
Report lists are used.
Regarding LOCK.PREFERENCES , if the user is given this option then the ‘User Preferences’ option under
the ‘Tools’ menu on the Desktop toolbar will be disabled. This will prevent the user from gaining access to
various Desktop settings including file locations and some system administrative functions.
NO.ENQUIRY.EXPORT is where T24 can allow the user to export Enquiry data from T24. As an example,
the export can be to the user’s desktop. If this value is set to Prevent the USER from Exporting Enquiry
data from an Enquiry screen, then the icon will be dimmed and non-reactive.
Regarding PREAUTHENTICATED – Any requests coming into T24 via Browser will be treated as pre-
authenticated. The SOURCE.TYPE in the OFS.SOURCE record should be set to SESSION. Only sign on name
authentication will be carried out.
REALTIMEENQUIRY Allows the use of real time enquiries for this user. When signing onto T24, Browser
will create another session for use by the real time enquiries. This does use an additional database license,
but not an additional T24 license.
The SUPER.USER will have access to all of the features just mentioned, and for all future functionality with
the exception of REALTIMEENQUIRY.

Security Management System R16 40

 Let’s go through a workshop on creating a User profile for yourself.

Security Management System R16 41

 This next chapter will cover the definition of user group and Roles

Security Management System R16 42

 What happens when a particular set of privileges is to be set for a group of
users? This might be required because they belong to the same
department.
Would you set the privileges separately for every single User’s profile?
Would you like to create set of privileges once and apply it to the relevant
users?

Security Management System R16 43

 SMS Groups can be created in the application USER.SMS.GROUP. The ID can
be any alphanumeric text.
GB DESCRIPTION is a mandatory field that is used to capture the description
of the record.
APPLICATION is a Multi Value Field which is used to input all the
applications which this user group has access to.
The FUNCTION field is used to capture the functions allowed for this group
of users.
TEMP.FUNCTION is used to allow additional functions to a user for a
temporary period of time. The START.DATE and END.DATE can be specified
here.
You will notice that most of the fields in USER.SMS.GROUP are also
available in the USER application. The only difference is that here we are
setting them for a group of users instead of a single User. You will also
notice that there is no Company restriction field in this application. This is
because the users who belong to the group might be in different branches.
The Branch which the user belongs to will still be set at individual User
profile level.

Security Management System R16 44

 In this screen shot, we see a USER.SMS.GROUP for Relationship Managers.
They can launch Enquiry and access Customer Application but with a
further SMS restriction to customer records who belong to Sector Equals
1000
You would need to identify the users who are relationship managers. The
Users REL.MGR.A and REL.MGR.B have the SMS group called CRMGroup
added to their profile.
APPLICATION is the field we use to attach the USER.SMS.GROUP which the
user belongs to. The syntax requires us to prefix the group name with an
‘@’ sign.
A user can be given other permissions that are outside of the group. To
achieve this we simply multi-value the relevant fields and specify what is
needed.
All actions performed by REL.MGR.A in T24 on login are subject to the SMS
permissions/restrictions in the CRMGroup as well as the additional
permissions/restrictions specified in the User record.

Security Management System R16 45

 With the demand for Identity servers increasing, Roles became another
mechanism that T24 uses to authorize users. Each user belongs to one or
many roles. There are two steps to set up roles 1) Within an organization,
roles are created for various job functions. The permissions to perform
certain operations are assigned to specific roles. The roles and their
permissions are defined in EB.USER.ROLES. The SMS permissions can be
assigned directly (Eg AdminRole) or a USER.SMS.GROUP id can be used
prefixed by @(CRMRole) or a combination of both(TellerRole).
2) System users are then assigned particular roles, and through those role
assignments acquire the permissions to perform particular functions. Users
are not assigned permissions directly, but only acquire them through their
role (or roles). Management of individual user rights becomes a matter of
simply assigning appropriate roles to the user's account. This simplifies
common operations, such as adding a user, or changing a user's
department.
In the screenshot shown, MULTIUSER.A has AdminRole, CRMRole and
TellerRole rights in BNK, where as can only play CRM role in EU1.
MULTIUSER.B is assigned the AdminRole in all companies to which the user
has access.
EB.USER.ROLES facilitates assigning multiple roles to the same user as well

Security Management System R16 46 46

 as same role can be assigned to multiple users at one go. One user can also
be given different roles in the companies to which he has access.
Role.Company.Restr and User.Roles fields are mandatory input when
assigning roles.

Security Management System R16 ‹#›

 Log into T24 as MULTIUSER.A. The first role mentioned in the USER
application is the default role assigned to the user on logging in –
AdminRole in the eg given. Click on the Tools option to view the list of roles
assigned to the logged in user. To switch to another role, the user needs to
click on the desired role in this list. On switching companies, the user is
automatically assigned the default role for the company. All User actions in
T24 will be subject to the SMS restrictions attached to the current active
Role. For eg, when MULTIUSER.A switches from BNK to EU1, the default
role assigned to the user is CRMRole. FT transactions are disallowed in
CRMRole and therefore the error message is displayed appropriately.

Security Management System R16 47 47

 USER.SMS.GROUP id and/or individual SMS permissions can be assigned to USER or
EB.USER.ROLES id can be mapped to USER

Both SMS restrictions (with / without using USER.SMS.GROUP) and EB.USER.ROLES cannot co-
exist in USER.

USER.SMS.GROUP id can be specified in EB.USER.ROLES.

Security Management System R16 48 48

 Each user can be assigned multiple roles.

Each user can have different roles in different companies.

For a user with multiple roles, the first role defined in USER, is the default role assigned on
authentication.

Security Management System R16 49 49

Security Management System R16 50 50
 [Hint: Use COMPANY.CREATE from classic to create additional companies if
required]

Security Management System R16 51 51

 In this last chapter we will explain the User administration in T24. Password
will be the first concept

Security Management System R16 52

 T24 passwords must conform to the following minimum requirements.
• The minimum length is 6 characters.
• The maximum length is 16 characters.
• The last 3 passwords cannot be reused when changing passwords.
• Any character can only be repeated once in the password. This means
that no character can appear more than twice anywhere in the password.
At the first sign on and whenever a password is changed, T24 will prompt
the User to type in the new password and then to confirm it.

Security Management System R16 53

 For some clients the default password minimum requirements are not
complex enough. Their security policies require more complex criteria for
passwords.
T24 has provision for setting up complex passwords. This will overrule the
default minimum requirement for T24.
There are certain fields on the SPF where complex password criteria can be
setup. We will look at these shortly.
Note that any changes made on the SPF pertaining to passwords will affect
all the users on the system. So, one must take due care before making any
amendments especially on the Live system.

Security Management System R16 54

 The following fields on the SPF can be used to control passwords.
PASS.MIN.LENTH is used to setup a new minimum length for all passwords.
This cannot be shorter than 6 or greater than 16
PASS.UPPER.ALPHA is used to specify the number of uppercase alpha
characters required in the password.
PASS.LOWER.ALPHA is used to specify the required number of lowercase
alpha characters.
PASS.NUMERIC is used to specify the number of numeric characters
required.
PASS.OTHER is used to indicate any other special characters that must be
included in the password. Here it is not the number of characters that is
required. The actual special characters must be indicated here. For example
if the password requires a question mark and an exclamation mark then we
must input those symbols into this field.
PWD.REPETITION is used to specify the number of previous passwords that
cannot be re-used when setting a new password. This value cannot be less
than 3.
Note that the combination of all the mentioned controls cannot be less the
6 or greater than 16 characters. This default minimum and maximum

Security Management System R16 55

 number of characters still has to be respected.

Security Management System R16 ‹#›

 Earlier, T24 used a proprietary one way hash algorithm to store passwords.
This hash mechanism has been replaced to enable the use of a standard
encryption or hashing algorithms that are generally accepted in the
industry. The system can be setup for using a locally developed algorithm
for password encryption. Now, the client has the option of by-passing the
built-in security for user-login that is provided by T24. This can be achieved
by attaching the algorithm to the SPF application.
The fields PASSWD.ROLLOVER.FR(equency) and ENCRYPTION.ALGORIT are
used to enable this functionality.
The field ENCRYPTION.ALGORIT is used to attach the JAVA routine that was
written to encrypt the password. This routine should be pre-defined in
EB.API. If this is done, then the system will skip the standard T24 password
encryption mechanism and follow the user-defined encryption method
written in the routine. If this field is left blank, then the standard T24
password encryption will take place.
The PASSWD.ROLLOVER.FR(equency) field is a field containing the
password rollover frequency. This is used to re-encrypt the password with
new security settings at the specified frequency. This field can only be
updated if the ENCRYPTION.ALGORIT field is not blank.

Security Management System R16 56

 We will now see how to rest a password

Security Management System R16 57

 Users periodically forget their passwords and try to log in with incorrect
ones. After a certain number of incorrect attempts T24 locks them out of
the system. Their user profiles are then essentially de-activated. The only
way the user can login again is if they have their password re-enabled or
reset by the administrator.
To reset or re-enable a user profile the administrator will use the
PASSWORD.RESET application.

Security Management System R16 58

 If a user exceeds the number of password attempts or if the user forgets their password, we can
reset using the following fields:
The ID to PASSWORD.RESET can be any alpha-numeric text.
When a user is locked out of T24 there are two scenarios that can occur.
The first scenario is when a user is locked out and has completely forgotten his password. The
only resolution is to reset the password so that the user can enter a new one.
In this case, the field USER.PW.ATTEMPT is used to reset the user. The ID entered is the USER.
After this, the user can login again with any password of his choice.
The second scenario is when a user has been locked out after exceeding his attempts but after,
remembers his password. Here the administrator must just clear the number of attempts so that
the user can use his existing password to login.
The USER.ATTEMPT field is used to reset the number of password attempts after the account is
locked. The maximum number of password attempts is specified in the application USER.
What if an administrator wants to re-activate a user profile before the end of the de-activation
period? You can achieve this by using the following field.
The field USER.DEACT.PERD specifies the ID of the user for whom the security administrator
wants to re-activate before the end of the de-activation period.
When a password is reset using the USER.PW.ATTEMPT field the password is cleared. The user
can then login with any password of their choice. For some clients this is not secure enough.
They prefer for the administrator to set a one time password and to inform the user of the new
password. The system expires this new password and prompts the user to enter a new one of his
choice at the next sign on. The following fields are used for this purpose.
The User Reset field has the ID of a user whose password is to be reset.
The User Password field will contain the new one time password. This password will be expired
when the user logs in and thus will be forced to change it.

Security Management System R16 59

 We will now cover the LDAP Setup in User Profile

Security Management System R16 60

 Most large organisations have user names and passwords for accessing the
network and for accessing Outlook. The same network user name and
password can be used to access the users Outlook account. Is it possible to
extend this user name and password to log into T24 as well? If so, how?
This is possible in T24 using the Ldap Id and Ldap Dn fields. These fields
are used to configure the Temenos Connector to use LDAP as part of the
authentication mechanism. It is most widely used as part of a corporate
single sign on mechanism. The advantage of this system is that the T24
username and password are never known outside of the T24 server. Ldap
Dn becomes a mandatory field once Ldap Id is entered.
Note: LDAP is an acronym for Light Access Directory Protocol

Security Management System R16 61

 And now, we will see how to Deactivate and Reactivate a User Profile

Security Management System R16 62

 Suppose a user is going to be away from work for an extended period. In
T24 it is possible for a user to de-activate his user profile for a selected
period. This could be done to ensure no-one uses his user profile while he is
away. A user profile that has been de-activated cannot be used until the re-
activation date.
What if the user has to come back to work before the reactivation date?
He will not be able to log into T24 as his account would still be deactivated.
The only way to login would be to contact the administrator to re-activate
his user profile. The administrator would do this using the
PASSWORD.RESET application.

Security Management System R16 63

 A user can de-activate their own profile by using the Tools hyperlink, from
where they select ‘My Profile’ and then ‘De-Activate Profile’.
Once the De-Activate Profile tab is launched, the de-activation and re-
activation dates need to be supplied.
The De-Activation Date is the date that the user wants the de-activation to
start. This date can be the current date or a future date.
The Re-Activation Date is the date on which the profile is to be re-activated.

Security Management System R16 64

 On viewing the USER Profile that has been de-activated we can see that the
deactivation period has been recorded.

Security Management System R16 65

 By using the PASSWORD.RESET application, a de-activated profile can be
manually re-activated before the reactivation date. We specify the USER ID
in the field User.Deact.Perd and make sure the User.Type field is set to INT,
which means Internal User Profile.
This has to done by the administrator. The end user cannot perform this
function by himself as his profile would be de-activated.

Security Management System R16 66

 1) Which application control privileges of a user? USER
2) Which application is used to create a group for users? USER.SMS.GROUP
3) How do you link the USER.SMS.GROUP to the User Profile? You should
include the USER.SMS.GROUP ID preceded by @ sign, in the field
APPLICATION of USER
4) How do you de-activate a user profile? The User can de-activate their
own profile using the option available in the ‘Tools’ icon of the T24 Browser
screen
5) What is the value you would give in the field Application to give the user
access to all the applications? ALL.PG
6) Where is the logging information stored in T24? In the PROTOCOL file

Security Management System R16 67

 This is what we learnt in this course

Security Management System R16 68

Security Management System R16 69