Loading documents preview...
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 webapplication 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 multivalues, 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 preauthenticated. 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 coexist 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 reactivation 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 reactivation 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