Single Sign On with Kerberos

Preface

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 automates 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 encryption methods. For authentication with Kerberos, no passwords are sent over the network in plain text. This prevents passwords from being intercepted in the network.

The current version of Kerberos is standardized in RFC1510 (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 applications’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 is the DNS name of the computer on which the application runs

REALM is the name of the Kerberos domain, by convention in upper case

Example of a typical Kerberos principal in BS2000

host/[e-mail]

In BS2000 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 below).

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 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 system.

  The client operating systems must have Kerberos capability:

  • Windows systems offer Kerberos support by default from Windows 2000 ( currently in Windows Server 2016 and 2019 ) 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 (BS2000) 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.

Authentication procedure when starting a $DIALOG connection to BS2000

• The user of a terminal emulation opens the BS2000 dialog as usual.

• BS2000 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 sends a ticket request to the terminal emulation.

  • The latter obtains a ticket from the Key Distribution Center and sends it to BS2000.

  • There the ticket is validated by means of decryption.

  • Finally in BS2000 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 in BS2000 as KTC event.

When the product Job Variables is used, the system job variable $SYSJV.PRINCIPAL contains the name of the principal.

Commands for access control

The commands for 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

Administering the keys in the key table

The secret keys on the BS2000 host are administered in the key table. An entry in the key table consists of the name of the BS2000 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 component SECOS-KRB

The SECOS component SECOS-KRB contains the interface for handling Kerberos authentication in BS2000.

Example

A BS2000 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 for the example below:

Windows server (Domain Controller)

• Windows 2000 or Windows Server 2003 and so on Windows Server 2016 or 2019

Windows clients (PCs of the BS2000 users)

• Windows 2000, Windows XP or Windows 10

• Terminal emulation with support of the terminal protocol for Kerberos in BS2000.

Proceed as follows on the Windows Domain Controller and BS2000:

1. On the Windows Domain Controller

   • Set up a proxy ID on the Domain Controller

     For the BS2000 system Kerberos keys must be stored on the Domain Controller. To permit this a proxy ID is set up on the Domain Controller:

     • From Server Manager start the Local Security Policy tool.
     • Click on the Local Policies and next the Security Options and set encryption types allowed for Kerberos.

     • From Server Manager start the Active Directory Users and Computers 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.

     • Fill in the 'Account' tab.

   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 system.

   • Assign the Kerberos name for the BS2000 system in the Domain Controller

     The proxy ID is in addition assigned the name of a BS2000 system in Kerberos notation using “Account Mapping”. 

     • Enter the following command in the DOS window:

       ktpass -princ host/hostname@NT-DNS-REALM-NAME -mapuser account 

       -pass password -crypto encryption-type -ptype KRB5_NT_PRINCIPAL -out keytab-entry

       The parameters are:

       hostname	DNS name of the BS2000 system
       NT-DNS-REALM-NAME	DNS name of the Active Directory Domain. This name  is a fixed value for every Active Directory Domain
       account	Proxy ID
       password	Password for the proxy ID  (max. 127 characters)
       encryption-type	Specifies the keys that are generated in the keytab entry
       KRB5_NT_PRINCIPAL	Kerberos Principal (as of Windows Server 2003)
       keytab-entry	Output file for keytab entry

     Notes

     • The command is described in the home for Microsoft documentation and learning for developers and technology professionals.. You can find the description on the Internet at https://docs.microsoft.com/en-us/

       type ktpass into the form and click the SEARCH button.

     • In the next step the same password is also specified in BS2000. 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 whenever they wish.

     • Windows and BS2000 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/[e-mail] 
       -mapuser d016ze04 
       -pass betterlongthanshort
       -crypto RC4-HMAC-NT
       -ptype KRB5_NT_PRINCIPAL
       -out keytab-entry
       

     • As on Windows Server , the KDC sends the tickets with a Key Version Number (KVNO). It must be ensured that the corresponding KVNO is also entered in BS2000. Please note the corresponding output of the ktpass
       command.

       .
       .
       .
       Successfully mapped host/d016ze04.mch.fts.net to d016ze04.
       Key created.
       Output keytab to keytab-entry:
       Keytab version: 0x502
       keysize 86 host/[e-mail] ptype 1 
       (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 ...
       

2. In BS2000

   • Set up the Kerberos key in BS2000

     Administartion of the Kerberos keys in BS2000 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@NT-DNS-REALM-NAME' -

     / ,KEY = *PASSWORD('password',KEY-VERSION=<key_version_number>)

     The same values must be specified in the Domain Controller for hostname, NT-DNS-REALM-NAME password and key version number. Please note that, in particular, NT-DNS-REALM-NAME by convention has to be specified in capital letters.

     Example

     /ADD-KEYTAB-ENTRY *STD, 'host/[e-mail]' -

     / ,KEY = *PASSWORD('liebereinbisschenlaenger',KEY-VERSION=3)

     Alternatively the CONVERT-KEYTAB command is available which simplifies the creation of Kerberos keys in BS2000.

     If openFT and a corresponding TRANSFER-ADMISSION are available CONVERT-KEYTAB helps to transfer the output file for the keytab entry ("keytab-entry" in the example above) from the Domain Controller to BS2000 and to automatically convert it into corresponding commands that create the key in BS2000.

     CONVERT-KEYTAB adds the keys of the various encryption types from the keytab file (in case the keytab file was created using the ktpass command and the crypto -all command).

     Example

     /CONVERT-KEYTAB TRANSFER-ADMISSION=getktpass,PARTNER=DOMAINCTL

     The command file CONVKTAB.JCL created by CONVERT-KEYTAB then has to be executed under the user ID of the security administrator.  Therefore this user ID must have the STD-PROCESSING privilege.

   • 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 user ID. For the Single Sign On procedure it makes sense to do without checking the BS2000-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@NT-DNS-REALM-NAME')
     

     The parameters are:

     userid	BS2000 user ID for which Single Sign On is to be introduced.
     windowsaccount	Domain ID of the user who is to be granted access to the BS2000 user ID.
     NT-DNS-REALM-NAME	DNS name of the Active Directory Domain as assigned when the key was set up.

     
     

     Example

     /MODIFY-LOGON-PROTECTION TSOS -
     /  ,NET-DIALOG-ACCESS=*YES -
     /    (PASSWORD-CHECK=*NO,ADD-PRINCIPAL='[e-mail]')
     

     Notes

     • Multiple Windows accounts can have access authorization for a BS2000 user ID.

     • The Windows user ID and the NT-DNS-REALM-NAME are interpreted as wildcard strings.

Supported encryption types

SECOS supports connections with the following encryption types:

• DES-CBC-CRC

• DES-CBC-MD5

• AES128-CTS-HMAC-SHA1-96

• AES256-CTS-HMAC-SHA1-96
• RC4-HMAC (ARCFOUR-HMAC-MD5)
• RC4-HMAC-EXP (ARCFOUR-HMAC-MD5-EXP)