The new IBM i 7.2 release brings several security-related enhancements. Two of them are the ability to use SSO from an IBM i green screen to a remote Telnet or FTP server that also supports Kerberos.
TELNET
If you are already using SSO on both the Telnet client and the Telnet server systems, there is nothing more to do in the way of configuration. To use Kerberos to authenticate from the Telnet client to the Telnet server, you merely need to code an additional parameter with the Telnet command. Here’s an example:
TELNET RMTSYS(<remote system hostname or ‘address’>) RMTUSER(*KERBEROS)
Of course, in order for this to work you have to have a non-expired ticket-granting-ticket (TGT) in your local Kerberos credentials cache. If you used Kerberos authentication to get to the system from which you are starting Telnet, then you already have one of these.
It is possible that your TGT will expire. This should only happen if you use Kerberos authentication to access the initial IBM i system and leave that session open for a relatively long period of time. If your TGT does expire, you can either open another session (using Kerberos authentication) or you can use the Add Kerberos Ticket (ADDKRBTKT) CL command:
ADDKRBTKT PRINCIPAL(‘<your windows userID>’’)
PASSWORD(‘<your windows pwd>’)
or the Kerberos Initialization (kinit) Qshell command which looks something like this:
kinit <your windows userID>
to refresh an existing TGT or to create a TGT in your local Kerberos credentials cache.
The Telnet client requests a Kerberos service ticket (ST) for service principal KRBSVR400/rmtsys.your.realm.com@MYCO.COM. Assuming you have already configured the local and remote systems to participate in the YOUR.REALM.COM Windows domain (i.e. Kerberos realm), then this service principal is already defined in Active Directory (AD) and in the keytab files on both the local and remote systems.
FTP
There’s a bit more configuration work in order to use Kerberos authentication with the FTP client compared to doing so with the Telnet client.
The FTP client requests a Kerberos service ticket (ST) for service principal FTP/rmtsys.com@MYCO.COM. Even if you have already configured both the local and remote systems to participate in your Windows domain, the basic initialization process does not include creating the FTP service principal in AD or in the keytab files on your local and remote systems.
Creating the FTP service principal in AD requires you to create a Windows user account (you can use a computer account, but that takes a bit more effort and isn’t covered in this article), and run the KTPASS command with the appropriate parameters for the system that will be the remote ftp server. If both systems may be used as FTP servers, you need to do the active directory setup for each of them.
The easiest way to accomplish this might be to copy the entries for the KRBSVR400 service principal from the original batch file created when you first configured SSO for the system(s) that will act as an FTP server.
You will also need to add the FTP service principal to the Kerberos keytab file on each IBM i system that you intend to use as an FTP server. You can do this with the Add Kerberos Keytab Entry (ADDKRBKTE) CL command which would look something like this:
ADDKRBKTE PRINCIPAL(‘ftp/rmtsys.myco.com’ MYCO.COM) PASSWORD(somethinggood)
or you can use the keytab command from Qshell which would look like this:
keytab add ftp/rmtsys.myco.com@MYCO.COM –p somethinggood
The configuration steps only need to be done once for each system that you will use as an FTP server.
Once you have the configuration completed, then using Kerberos with FTP is just as easy as using it with Telnet. However, the FTP client command uses a different parameter to indicate that Kerberos authentication should be used to authenticate to the FTP server. Here’s an example of the STRTCPFTP CL command:
FTP RMTSYS(*INTNETADR) INTNETADR(‘1.2.3.4’)
SECCNN(*KERBEROS)
As you can see, using Kerberos authentication with either the Telnet or the FTP client is pretty easy. Code one additional parameter and that’s it. FTP requires some additional Kerberos configuration in AD and on each system that you intend to use as an FTP server; but this only takes a couple of minutes and needs to be done only once.
It’s encouraging to see IBM continue to SSO-enable applications. As always, if you need assistance with any SSO issue, feel free to reach out to me.
