Kerberos: Single Sign On for BS2000

Kerberos: Single Sign On for BS2000 Issue April 2011 Pages 6 Overview A Single Sign On system (SSO system) is a system which permits an automatic and convenient, i.e. nonrecurring, logon to various resources in heterogeneous networks. After a one-off identification and authentication it automates all subsequent logons by a user in the network. Metaphorically spoken an SSO system is a user s master key providing immediate access to all applications he needs. Kerberos is a standardized network authentication protocol which is commonly used on many platforms as SSO system-enabler. In BS2000/OSD, SECOS supports the Single Sign On procedure with Kerberos as of version V5.0. Contents Using Single Sign On 2 Kerberos concept 2 Kerberos principal 2 Prerequisites for using Kerberos 2 Administering the keys in the key table 3 BS2000/OSD component SECOS-KRB 3 Kerberos Authentication during connection establishment to $DIALOG 3 Kerberos Authentication during connection establishment to OMNIS-MENU 3 Kerberos Authentication during connection establishment to openutm 3 4

Description Paper Issue: April 2011 Kerberos for BS2000 Page 2 / 6 Using Single Sign On In modern, complex working environments, users often need access to multiple applications which may also be located on different computers. Consequently, they often have to use different user IDs and passwords. Different applications may also impose different rules with which these user IDs and passwords must comply. In addition, it is often necessary to change different passwords at differing intervals. All this means more administration work. This affects not only users but also user administrators who have to reset forgotten passwords and re-enable user IDs that have been locked because the password has expired. This increased administrative work can be avoided through the use of a Single Sign On system (SSO system). An SSO system is a system which permits an automatic and convenient logon to network resources in heterogeneous networks. After a one-off identification and authentication which can also be performed by means of a chip card an SSO system obviates the need for all subsequent logons by the user in the network. Kerberos concept Kerberos is a standardized network authentication protocol which was developed at the Massachusetts Institute of Technology (MIT). It is a security system based on cryptographical methods. For authentication with Kerberos, no passwords or other confidential data are sent over the network in plain text. This prevents passwords from being intercepted in the network. The current version of Kerberos (V5) is standardized in RFC1510 (RFC=Request for Comments). The standards themselves are defined by the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG). Comprehensive information on the RFCs is available on the home page of the IETF: http://www.ietf.org/rfc/ Kerberos works with symmetrical encryption, in other words all keys are present at two locations, at the site of the key owner (principal) and at the KDC (Key Distribution Center). A key is derived from a principal s password. Kerberos principal The Kerberos principal has a unique name which can consist of any number of components. SECOS supports up to 1800 bytes for the principal name. The components are separated from each other by the component separator /'. The last component is the realm, which is separated from the other components by the realm separator @. The name of an application s principal generally comprises three components: application, instance and realm. The format of a typical Kerberos V5 principal name is: Application/Instance@REALM where Application is the host for the application $DIALOG or the name of the application Instance REALM is the name of the computer on which the application runs according to the Domain Name Service (DNS) is the name of the Kerberos domain, by convention in upper case In case you need an example of a typical Kerberos principal in BS2000/OSD you should consult the address given in the footer. In BS2000/OSD the name of the principal must be added to the key table with the SECOS command /ADD-KEYTAB-ENTRY. The administrator of the Windows Domain Controller must set up a service account for the client (for information see also the example on page 4). Prerequisites for using Kerberos KDC An existing KDC is required, for example the Domain Controller (PDC) of Windows 2000, which supports this functionality. Client If a connection request to BS2000/OSD is issued on the client PC via terminal emulation, the terminal emulation has the task of obtaining a valid ticket and forwarding this to the BS2000/OSD system. The client operating systems must have Kerberos capability: Windows systems offer Kerberos support by default from Windows 2000 (in other words also in Windows XP and Windows Server 2003) in the SSPI libraries. The SSPI calls are already possible with Windows 95 and better. GSSAPI libraries are freely available for UNIX systems and are also integrated into some operating systems (for example Solaris as of Sun OS 5.8). The C bindings of GSSAPI are standardized (RFC 2744). The terminal emulation must support authentication with Kerberos. For details, please contact the manufacturer of your terminal emulation. Server The server (here BS2000/OSD) must recognize that the connection has Kerberos capability. For this purpose the client (for example the terminal emulation) must log on as DSS9763 (device type X 4F ) when the connection is established.

Description Paper Issue: April 2011 Kerberos for BS2000 Page 3 / 6 Administering the keys in the key table The secret keys on the BS2000/OSD host are administered in the key table. An entry in the key table consists of the name of the BS2000/OSD system as entered in the KDC (Key Distribution Center), and multiple keys which are derived from the specified keyword and the system name using a cryptographical procedure. The following commands administer the key table: /ADD-KEYTAB-ENTRY /MODIFY-KEYTAB-ENTRY /REMOVE-KEYTAB-ENTRY /SHOW-KEYTAB-ENTRY BS2000/OSD component SECOS-KRB The SECOS component SECOS-KRB contains the interface for handling Kerberos authentication in BS2000/OSD. Kerberos authentication during application access in BS2000/OSD Following components support Kerberos authentication: Connection to (from SECOS V5.0) Connection to OMNIS/OMNIS-MENU (from OMNIS V8.4 / OMNIS-MENU V3.4) Connection to openutm (from openutm V5.3A) Kerberos Authentication during connection establishment to $DIALOG Commands for access control The commands for agreeing on access control for an ID have been extended by the Kerberos principals in the access class NET-DIALOG-ACCESS. It is thus possible to define which principals are permitted access to this user ID and whether a password is required to obtain access. The commands involved are: /SET-LOGON-PROTECTION /MODIFY-LOGON-PROTECTION /SHOW-LOGON-PROTECTION Authentication procedure when starting a $DIALOG connection to BS2000/OSD The user of a terminal emulation opens the BS2000 dialog as usual. BS2000/OSD sends a LOGON request to the emulation. The user enters the /SET-LOGON-PARAMETERS command with job name, user ID, account number and, if required, other operands, but without a password. Invisibly for the user, the following activities are then performed: BS2000/OSD sends a ticket request to the terminal emulation. The latter obtains a ticket from the Key Distribution Center and sends it to BS2000/OSD. There the ticket is decrypted and validated. Finally in BS2000/OSD a check is made to see whether the user of the ticket who is identified as Kerberos principal has access to the user ID specified in the /SET-LOGON-PARAMETERS command. Depending on the result of this, check access is granted or rejected. The result of authentication is stored in a SAT record (SAT=Security Audit Trail) in BS2000/OSD. When the product JV (BS2000/OSD) as of V14.0A is used, the system job variable $SYSJV.PRINCIPAL contains the name of the principal. Kerberos Authentication during connection establishment to OMNIS-MENU OMNISKD instruction The instruction for defining OMNIS-MENU users has been extended by the Kerberos principals. It is thus possible to define which principals are permitted access to this OMNIS-MENUuser and whether a password is required to obtain access. The command involved is: DECLARE-USER Kerberos Authentication during connection establishment to openutm KDCDEF control instructions The KDCDEF control instructions for agreeing on access control for an UTM user have been extended by the Kerberos principals. It is thus possible to define which principals are permitted access to this UTM user and whether a password is required to obtain access. The control instructions involved are: DEFAULT LTERM MAX USER KDCS calls Access control using Kerberos can also be done by UTM user programs. KDCS calls haven been extended to supply user programs with Kerberos information Calls involved are: INIT INFO

Description Paper Issue: April 2011 Kerberos for BS2000 Page 4 / 6 A BS2000/OSD user ID is to be included in a Single Sign On procedure on the basis of a Windows domain ID so that a user logged on under Windows need not enter a password with the /SET-LOGON-PARAMETERS commands. The following prerequisites for the software configuration apply to the example below: On BS2000 BS2000/OSD-BC as of V6.0 SECOS as of V5.0 Windows server (Domain Controller) Windows as of 2000 Windows clients (PCs of the BS2000 users) Windows as of XP Terminal emulation with support of the terminal protocol for Kerberos in BS2000/OSD. Proceed as follows on the Windows Domain Controller and BS2000/OSD: On the Windows Domain Controller Set up a proxy ID on the Domain Controller For the BS2000/OSD system Kerberos keys must be stored on the Domain Controller. To permit this a proxy ID is set up on the Domain Controller: Start the Active Directory Management Tool. Click on the Users folder with the right-hand mouse button and select the function New User. Enter the name of the user ID. Save the user ID. The name of the user ID is freely selectable. It makes sense to select a name which indicates its use as a placeholder for a BS2000/OSD system. Assign the Kerberos name for the BS2000/OSD system in the Domain Controller The proxy ID is in addition assigned the name of a BS2000/OSD system in Kerberos notation using Account Mapping. Enter the following command in the DOS window: ktpass -princ host/hostname@ -mapuser account -pass password -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out keytab-entry hostname account password DNS name of the BS2000/OSD system DNS name of the Active Directory Domain. This name is a fixed value for every Active Directory Domain. Proxy ID Password for the proxy ID (max. 127 characters) RC4-HMAC-NT Encryption type (Windows Server as of 2003) KRB5_NT_PRINCIPAL Kerberos Principal (Windows Server as of 2003) keytab-entry Output file for keytab entry Notes The command ktpass is described in the English Microsoft Knowledge Base. You can find the description on the Internet at http://support.microsoft.com. Click on Search the Knowledge Base and complete the form as follows: Search for... : ktpass Search Type: Title Only In the next step the same password is also specified in BS2000/OSD. Make sure you use a good password which other people cannot guess. People who know this password and have programming experience can identify themselves to BS2000/OSD whenever they wish. Windows and BS2000/OSD use different character encoding (ASCII and EBCDIC). Country-specific character sets can also be installed on both systems. Consequently use only characters from the international character set, for example no umlauts. It is better to choose a somewhat lengthy word to make it more difficult to guess, for example: ktpass -princ host/d016ze04.mch.ts.fujitsu.net@ts.fujitsu.net -mapuser d016ze04 -pass betterlongthanshort -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out keytab-entry From Windows Server 2003 encryption type RC4-HMAC-NT should be used to ensure inoperability with all connected systems. From Windows Server 2003 the KDC sends the tickets with a Key Version Number (KVNO). Make sure that the same value for KVNO is specified in BS2000/OSD. Check the corresponding output of ktpass command.

Description Paper Issue: April 2011 Kerberos for BS2000 Page 5 / 6 Successfully mapped host/d016ze04.mch.ts.fujitsu.net to d016ze04. Key created. Output keytab to keytab-entry: Keytab version: 0x502 keysize 46 host/d016ze04.mch.ts.fujitsu.net@ts.fujitsu.net ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype etype 0x17 (RC4-HMAC) In BS2000/OSD Set up the Kerberos key in BS2000/OSD Administration of the Kerberos keys in BS2000/OSD is the task of the security administrator (by default the user ID SYSPRIV). The command to do this is: /ADD-KEYTAB-ENTRY *STD('host/hostname@' - /,KEY = *PASSWORD('password',KEY-VERSION='key version number') The same values must be specified in the Domain Controller for hostname,, password and key version number. Please notice that has to be specified by convention in upper case. /ADD-KEYTAB-ENTRY *STD('host/d016ze04.mch.ts.fujtsu.net@ts.fujitsu.NET' - /,KEY = *PASSWORD('betterlongthanshort',KEY-VERSION=3) From SECOS V5.3 a new SDF command CONVERT-KEYTAB is available which simplifies the creation of a Kerberos key in BS2000/OSD. If openft is available and an appropriate TRANSFER-ADMISSION is set CONVERT-KEYTAB supports the transmission of the keytab output file (in example above keytab-entry from the Domain Controller to BS2000/OSD as well as an automatic conversion to the corresponding commands for adding a key in BS2000/OSD. : /CONVERT-KEYTAB TRANSFER-ADMISSION=getktpass,PARTNER=DOMAINCTL CONVERT-KEYTAB builds a file named CONVKTAB.JCL. This file hast o be executed under the user-id of the security administrator. For this action the user-id of the security administrator has to be supplied with the privilege STD-PROCESSING. Release the user ID for the Windows domain ID In the last step the Windows IDs which have access authorization are defined for a BS2000/OSD user ID. For the Single Sign On procedure it makes sense to do without checking the BS2000/OSD-specific password. The command which the user administrator must enter is: /MODIFY-LOGON-PROTECTION userid - /,NET-DIALOG-ACCESS=*YES - / (PASSWORD-CHECK=*NO - /,ADD-PRINCIPAL='windowsaccount@' - / ) Userid Windowsaccount BS2000/OSD user ID for which Single Sign On with Kerberos is to be introduced. Domain ID of the user who is to be granted access to the BS2000/OSD user ID. DNS name of the Active Directory Domain as assigned when the key was set up. /MODIFY-LOGON-PROTECTION TSOS - /,NET-DIALOG-ACCESS=*YES - / (PASSWORD-CHECK=*NO,ADD-PRINCIPAL='MCHHMUSTERMANN@ts.fujitsu.NET') Notes Multiple Windows accounts can have access authorization for a BS2000/OSD user ID. The Windows user ID and the are interpreted as wildcard strings. In a similar way Kerberos principals can be for access control of OMNIS-MENU. An OMNIS-MENU administrator has to specify this OMNISKD instruction: DECLARE-USER =userid, - PRINCIPAL='windowsaccount@', -

Description Paper Issue: April 2011 Kerberos for BS2000 Page 6 / 6 userid windowsaccount OMNIS-MENU user ID for which Single Sign On with Kerberos is to be introduced. Domain ID of the user who is to be granted access to the OMNIS-MENU user ID. DNS name of the Active Directory Domain as assigned when the key was set up. DECLARE-USER ==HMUSTERMANN, - PRINCIPAL=' MCHHMUSTERMANN@ts.fujitsu.NET', - If Kerberos authentication is requested for access control of openutm and access control has to be done by openutm an UTM administrator has to use this KDCDEF control instruction: USER userid, - PRINCIPAL='windowsaccount@', - userid windowsaccount UTM user ID for which Single Sign On with Kerberos is to be introduced. Domain ID of the user who is to be granted access to the UTM user ID. DNS name of the Active Directory Domain as assigned when the key was set up. USER HMUSTERMANN, - PRINCIPAL=' MCHHMUSTERMANN@ts.fujitsu.NET', - If Kerberos authentication is requested for access control of openutm and access control has to be done by an user program the responsible UTM administrator has to use this KDCDEF control instruction for enabling Kerberos dialogue during communication of a client with a LTERM or TPOOL, e.g.: LTERM ltermname, - KERBEROS-DIALOG=YES, - ltermname Name of a LTERM partner, for which a Kerberos dialogue is enabled during communication with a client. LTERM LT0123456, - KERBEROS-DIALOG=YES, - To get the Kerberos ticket information an UTM program has to implement this KDCS call: INFO CD All rights reserved, including intellectual property rights. Technical data subject to modifications and delivery subject to availability. Any liability that the data and illustrations are complete, actual or correct is excluded. Designations may be trademarks and/or copyrights of the respective manufacturer, the use of which by third parties for their own purposes may infringe the rights of such owner. For further information see ts.fujitsu.com/terms_of_use.html Published by department: Andreas Ginzkey Phone: ++49 89 3222 2715 andreas.ginzkey@ts.fujitsu.com ts.fujitsu.com Extranet extranet.ts.fujitsu.com Copyright Fujitsu Technology Solutions GmbH 2011