DDM

When configuring DDM, security configuration must be performed on both the source system and the target system. On the source system, the user making the DDM request must have a Server Authentication Entry defined, as shown in Figure 1.

The User Profile parameter defines the user on the source system that is attempting the DDM connection to the target system. The User ID parameter is the user the request will run under on the target system. While this parameter defaults to be the same as the user profile parameter, it does not have to be the same as the user on the source system. In fact, you may not want the users on the source system having a profile on the target system, or you may want them to access the file with a different user's authority. In either case, you name a different profile under which to run the target request. Depending on the configuration on the target system, a password may or may not be required.

Figure 1: To make a DDM request, you must have a server authentication entry on the source system to define the user under which the request will run on the target system. (Click images to enlarge.)



The configuration required on the target system is to determine the level of authentication required. This is done by modifying the target client authentication properties of the DDM server either through iSeries Navigator (choose Network->Servers->TCP/IP, right-click on DDM, and choose Properties) or through the Change DDM TCP/IP Attributes (CHGDDMTCPA) command, as shown in Figure 2.

Figure 2: On the source system, use the CHGDDMTCPA command to change the remote authentication requirements.

Using either interface, you have five choices for specifying what is required on the connection:

• No password is required on the connection.
• A password is not required, but if one is passed, it must be valid.
• A password is required (this is the default).
• An encrypted password is required.
• Authenticate using Kerberos.

The "No password required" option must be used if the profile on the target system does not have a password--that is, if it's defined as PASSWORD(*NONE). However, I don't recommend this setting. Consider this: The ADDSVRAUTE command is *PUBLIC(*USE); that means that any user on the system has access to the command. No authority checking is performed if the User Profile parameter is left at the default value *CURRENT. No authority checking is ever done on the USERID parameter. Therefore, with the target system client authentication set to "no password required," users can run the ADDSVRAUTE command on the source system and specify that their requests run as QSECOFR on the target system. Then, when a user submits a DDM target command, it will run on the target system as QSECOFR. If you insist on using this setting, make sure to secure (set *PUBLIC to *EXCLUDE) the ADDSVRAUTE command so you have some control.

With the "no password required" setting, if a password is passed, the target system ignores it. The "password not required but if passed must be valid" option is not much better than the "no password required" setting; therefore, I don't recommend this setting either.

Requiring a password (which is the value OS/400 defaults to) is a better option. However, this presents a couple of points to consider. First, the user's password on the target system must match the password specified in the server authentication entry. So you have two choices: You can define a password that never changes (not something I recommend, and this practice will not pass any type of formal audit) or you have the challenge of changing the password on the target system and having to remember to manually or programmatically change it in the server authentication entry on the source system. Worst case is that the user making the DDM connection runs as that same user on the target system. Then the source, target, and server authentication entry passwords must all be kept in sync. In addition, the password is sent on the connection in cleartext.

Requiring an encrypted password is an even better option. In this case, before transmitting the password to the target system, the cleartext password from the server authentication entry is encrypted using a method understood by the target system. However, you still have the challenge of keeping passwords in sync. Also, in the cases where the password is sent on the connection, the source system has to retrieve a password from the server authentication entry. This means that the Retain Server Security system value (QRETSVRSEC) must be set to '1' - Retain data. Because any password that is decryptable is less secure than one that isn't, this setting is inherently not completely secure. So, by adding a user's OS/400 password to a server authentication entry, you have inherently made it less secure because the OS/400 password is stored in decryptable form in the server authentication entry.

A side note on the system value QRETSVRSEC: This system value has two values: '0' - Do not retain (the default) and '1' – Retain. Changing the value to '1' means that decryptable passwords are stored in validation lists and server authentication entries. This value does not affect how OS/400 user profile passwords are stored. Prior to V5R2, if you changed the system value from '1' to '0', the decryptable passwords were removed--that is, deleted--from the system. A careless change of this system value could have devastating effects on Web applications as well as various communication connections because the decryptable passwords were gone. Poof! The only way to get them back was to restore the appropriate objects, assuming that you knew which ones they were. Realizing that this was a bit drastic, IBM modified the behavior of what happens when QRETSVRSEC is changed from '1' to '0'. Now, when the value is changed, the decryptable passwords cannot be retrieved, but they still exist. If QRETSVRSEC is changed back to '1', the decryptable passwords are once again available for retrieval. If you really want to get rid of the decryptable passwords, you can run the Clear Server Security (CLRSVRSEC) command, also new in V5R2.

Back to the discussion on DDM...

The answer to not having to keep passwords in sync across multiple systems is to use the Kerberos setting. This is also the most secure setting. In this case, the source system must pass the target system a Kerberos ticket. Using Kerberos for OS/400 authentication will be the topic of a future "Security Patrol" column.

I realize that not everyone wants to or can use Kerberos yet. So let's look at a scenario that doesn't use Kerberos. Take the scenario in which the user on the source system does not have a profile on the target system and the data being accessed on the target system is owned by an application profile that does not have a password (following good security architecture practices). As you investigate your options, you realize that you are going to have to add a server authentication entry for each user making a remote request, and, because you want the database to be accessed using the application owner's authority, it looks like you are going to have to use the "no password required" remote authentication setting. For obvious reasons, neither creating an entry for all users making a remote request nor using the "no password required" setting is at all appealing. After further investigation, you realize that, as part of the remote command function of DDM, you can call a program that is owned by and adopts the application profile's authority. OK, so now you know how to access the data using its owner's authority without actually specifying the data owner on all of the server authentication entries. So what profile do you run as on the target system? I suggest that you consider creating a profile whose sole purpose is to be the user under which the DDM request is made. This user is authorized to a program that is called using the remote command function of the DDM server. This program either adopts its owner, in which case it would be owned by the application-owning profile, or swaps to the application-owning profile, thus allowing access to the data on the target system. (Make sure to set this program to *PUBLIC(*EXCLUDE) and only authorize this specially created user profile.) Create this profile with no special authorities, an initial menu of *SIGNOFF, and no group profile, and then make a very small amount of storage available to it. You should also consider excluding this user from all application libraries and directories except for the one containing the application data being accessed. Examine what is in the application library or directory, because you may want to consider excluding it from other objects if the objects contain sensitive or private data or programs.

With this approach, you still have the issue of keeping the password in the server authentication entries synchronized with the password on the target system. I strongly encourage you to come up with a scheme to change the password of this profile at least once a month. I suggest that each month you generate a new, random password for the source system and then programmatically change all of the corresponding server authentication entries.

DRDA Considerations

When you run DRDA over TCP/IP, it uses the connections provided by DDM. Then, authentication requirements are determined by the target client authentication setting on the target system. The default is to require a user name and password to be sent to the system on which the relational database resides. The user can provide the user ID and password on the SQL CONNECT statement when connecting to the relational database. Or you can use the Add Server Authentication Entry (ADDSVRAUTE) command to define a server authorization entry as described above. If you choose to use the encrypted password option, you must use a client that supports something called "password substitution." This is the technique that allows the server and client to pass the password in a secure fashion. The Java Toolbox and iSeries Access OLE DB Provider are clients known to support password substitution. As of V5R2, DRDA supports Kerberos as an authentication mechanism. Just as it was with DDM, this is the most secure method of authentication.

Your options are limited with DDM and DRDA over TCP/IP. I hope this month's column has provided you with some ideas for securing these connections.

Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has over 12 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..