Recommended Client Access Security Settings for Microsoft® Windows® Services

Resolving The Problem

Programs that run as Microsoft Windows NT, Windows 2000, Windows XP, or Windows 2003 services may use Client Access Express functions such as ODBC. These programs include products such a Microsoft Internet Information Server (IIS) and some versions of Seagate Crystal Reports. When Client Access is used in this environment, system administrators may want to review Client Access security settings. Some of these settings are appropriate for desktop users but may not be appropriate for a program running as a Microsoft Windows service.

Background

Client Access Express allows an optional default user to be defined. This is the user profile used for an IBM OS/400 connection when no user profile is specified.

V4R5 Client Access Express caches passwords for each user profile that successfully logs on to the operating system. The successful logon could be through the Client Access sign-on prompt or through an API call (such as an ODBC connect). The cached password is used any time a user profile is specified (or a default user profile exists) but no password is provided.

Note: APAR SA90525 changed this behavior. V5R1 Client Access Express does not cache passwords if there is no sign-on information setting configured. If the system definition is created by Client Access Express ODBC, the sign-on information setting is not configured and no password caching is performed.

The Client Access sign on information is specific to the Windows NT/2000 sign on session for the user. The password cache is cleared when the user signs off. A process that runs in the security context of one Windows NT user can not access the security information for another Windows NT user. A Windows NT service running under a specific Windows NT profile can access the security information for that Windows NT profile when the same user is also signed on the desktop.

Preventing the Use of a Default User ID and Cached Password Sign-On

V5R1 and later ODBC
Starting with V5R1, no special action is required. Do not use cwbcfg /s option. If the system was upgraded from a previous release, delete the registry key HKEY_USERS\.DEFAULT\Software\IBM\Client Access Express\CurrentVersion\Environments to remove any old settings. Any attempt to connect to a system with a zero length or null user ID or password will fail.

V4R5 ODBC
To prevent a successful sign on when no user and no password is supplied, a default user must not be defined. There is no default user defined in the context of the service as long as you have not run cwbcfg /s with the [/uid userid] option or attempted direct editing of the registry.

The ODBC system datasource connection options should be set to Prompt every time or Use default user ID, prompt as needed with no user ID specified. Use Operations Navigator default can also be specified as long as you did not define a default user.

Another option is to have the application program screen for zero length user profiles. The application forces each user to enter a user profile and password. The application validates the information entered and rejects a zero length user profile name. The validation is done before calling the Client Access sign-on function.

Preventing the Use of a Cached Password Sign-On

V5R1 and later ODBC
As with default user, in V5R1 no special action is required. Do not use cwbcfg /s option. If the system was upgraded from a previous release, delete the registry key HKEY_USERS\.DEFAULT\Software\IBM\Client Access Express\CurrentVersion\Environments to remove any old settings. Any attempt to connect to a system with a zero length or null user ID or password will fail.

V4R5 ODBC
With Windows NT services, many different operating system users may go through the same server. V4R5 of Client Access caches the password for each user after a successful logon. In this environment, you should prevent an end-user from gaining access to the system by specifying or guessing a valid operating system user profile (with a previously cached password) and a zero length password. For example:
User1 logs on with user profile = "User1", password="pwd1".
User 2 gains access to the server and specifies user profile = "User1", password = "". User2 is logged on to the OS/400 as User 1 using the existing cached password.

The following methods to prevent this:

o	The application forces a password to be entered. In this technique, the application forces each user to enter a user profile and password. The application validates the information entered and rejects a zero length password. The validation is done before calling the Client Access sign on function.
o	Revoke the write authority for the Windows NT/2000 profile to the Client Access registry hive. Client Access requires write authority to the HKEY_USERS\<user>\Software\IBM\Client Access Express\CurrentVersion\Volatile section of the registry to save the password. Granting read only access to the hive prevents password caching.

Normally, only the Windows ID that the service runs under must be configured. However, both IIS and other Windows NT services can switch the authority context to the Windows NT user being serviced. In these cases, each Windows NT/2000 account must be configured or added to the proper group. In the default configuration of Windows 2000, the Users group already has read only authority; therefore, you may be able to skip the following procedure.

1.	At a Windows command line run: cwbcfg /host <mysystem> /s where <mysystem> is your system name or system TCP/IP address. This creates the Client Access hive if it does not already exist.
2.	Run regedt32. Note: This is not regedit.
3.	Navigate to the key HKEY_USERS\.DEFAULT\Software\IBM\Client Access Express\CurrentVersion
4.	Select the menu option Security, Permissions. This shows the Registry Key Permissions dialog.
5.	Configure the security settings so that the Windows NT/2000 accounts have read but not write nor create authority.
6.	Click OK. You are returned to the Registry Key Permissions dialog.
7.	In Windows NT 4, check the Replace Permission on Existing Subkeys checkbox. In Windows 2000, click the Advanced button, and check Reset permissions on all child objects and enable propagation of inheritable permissions.
8.	Click OK, and exit regedt32.

Create a Windows NT/2000 Account for the Service

Keep in mind that Client Access uses a desktop user's settings (including password cache) if the ID the Windows service runs under is the same as the current desktop user. To prevent any unintended sharing, create an ID that is used exclusively with the service. You may want to revoke the right to log on locally for this Windows account.

Prevent ODBC Prompting

If the application uses the ODBC SQLConnect API (or you are not sure) apply the fix for APAR SA91323 to prevent unwanted application hangs due to prompting. Note that you must follow the instructions in the APAR text to enable the feature.