Using the Windows Security Exit

This section provides an overview of Windows security exits and discusses how to:

  • Customize PSUSER.DLL.

  • Implement a customized PSUSER.DLL.

Almost all end users will access PeopleSoft applications by using a browser, so you may not need to implement any client-side Windows exits. However, you can provide this functionality, perhaps for developers.

The Windows client-side exits are:

  • PsGetTuxConnectInfo(): Used only for three-tier Microsoft Windows workstations running PeopleSoft Application Designer or Query, for example.

  • PsGetLogonInfo(): Used for Microsoft Windows workstations in both a two-tier and three-tier environment.

Use these functions to create a customized PSUSER.DLL. These exits are used primarily for the PeopleTools Development Environment, PeopleSoft Query users, or PeopleSoft Tree Manager users. Unless you intend to deploy PeopleSoft applications to Microsoft Windows workstations, these exits are seldom used.

PsGetLogonInfo was used for the Microsoft Windows Client in previous releases to fill in the signon screen programmatically without displaying it to the user.

With the three-tier Microsoft Windows Client signon you can also bypass the PeopleSoft Signon window by modifying the PsGetLogonInfo() function as with the two-tier connection. But because you are connecting to the database through Tuxedo, there are some other authorizations that need to occur.

Image: Microsoft Windows Client three-tier signon exits

This diagram shows the Microsoft Windows Client three-tier signon exits.

Microsoft Windows Client three-tier signon exits

The required authorizations are as follows:

  1. The PsGetLogonInfo function must specify APPSERV as the szDBType parameter to bypass the PeopleSoft Signon dialog box.

  2. To connect to the Tuxedo application server, the PsGetTuxConnectInfo function retrieves authentication information from directory server.

  3. If the authentication information is valid, Tuxedo allows connection.

  4. Tuxedo must connect to the database server.

    The application server verifies the authentication information passed by the PsGetTuxConnectInfo function.

  5. If the authentication is successful, the user is connected to PeopleTools.

Image: Two-tier Microsoft Windows Client signon using PsGetLogonInfo

The following diagram illustrates the results produced by customizing the PSUSER.DLL PsGetLogonInfo function to bypass the PeopleSoft Signon dialog box.

Two-tier Microsoft Windows Client signon using PsGetLogonInfo

In this case, the sequence of events is as follows:

  1. From the workstation the user runs PSTOOLS.EXE. PSTOOLS.EXE calls the PSUSER.DLL.

  2. The PsGetLogonInfo function supplies user signon information.

    If information is validated by the RDBMS, the user is connected as User ID or Connect ID, and then after the security profile is retrieved and validated the user is connected as Access ID.

  3. If the signon information is valid, the PeopleSoft system connects the user to the specified PeopleTool.

If your site has implemented a security system external to the PeopleSoft system, you can use that external system to validate your Microsoft Windows Client PeopleSoft users, also. This is done through the user exit (PSUSER.DLL), which also enables you to specify your own encryption for use in encrypting passwords.

To enable these options, you must modify several procedures in the PSUSER.C, and recompile to create a new PSUSER.DLL. Then you must install the new DLL file wherever users run the PeopleSoft executable files, such as <PS_HOME> on the file server.

In this section, we discuss the security functions that we provide and how you can tailor them for use in your own system. To successfully complete any customizations with these functions, you must be familiar with the C programming language.


The PsGetLogonInfo function is always called when the PeopleSoft system is started. If you’re already controlling which users can access the PeopleSoft applications—through a custom security solution—you may want to use this function to let those users start the PeopleSoft system directly without being prompted for PeopleSoft signon information. This function can also be overridden to provide information to the three-tier exit, PSGetTuxConnectInfo.

As delivered, PsGetLogonInfo returns a FALSE value and is ignored. However, if it returns a TRUE value, the PeopleSoft signon dialog box is bypassed and the information that you’ve coded into the function is used as the signon parameters.

You’ll find this function in your PS_HOME\src\PSUSER\PSUSER.C file. The code initially looks like this:

* Function:     PsGetLogonInfo                                         *
*                                                                      *
* Description:  Sample routine to get logon information.               *
*                                                                      *
* Returns:      TRUE if logon information returned                     *
*               FALSE to ignore                                        *


/*--------------- BEGIN SAMPLE CODE -----------------

// ask for user input only when it is the first signon
if (!lpPsLogInfo->bSubsequentSignon)
    // test auto logon
    strcpy(lpPsLogInfo->szDBChange, "NO");
    strcpy(lpPsLogInfo->szDBType, "DB2");
    strcpy(lpPsLogInfo->szDBName, "C9442A");
    strcpy(lpPsLogInfo->szServerLogonSec, "NO");
    strcpy(lpPsLogInfo->szOprId, "C944201");
    strcpy(lpPsLogInfo->szOprPswd, "C944201");

------------------ END SAMPLE CODE ----------------*/



To activate the automated signon feature, you must comment out the “false” return and uncomment the “true” return line. The return value is historical and ignored. The user exit bypasses the screen only if it receives enough information.

Then you must code the appropriate logic to fill in the values for the parameters to the PSGetLogonInfo routine. If you provide all of the appropriate field values, the system proceeds directly to your default initial window specified in the PeopleSoft Configuration Manager Startup tab. Your procedure might look something like this:

/* test auto logon */
//strcpy(lpPsLogInfo->szDBChange, "NO");
strcpy(lpPsLogInfo->szDBType, "ORACLE");
strcpy(lpPsLogInfo->szDBName, "PSORADB");
strcpy(lpPsLogInfo->szServerLogonSec, "NO");
strcpy(lpPsLogInfo->szOprId, "MGR2");
strcpy(lpPsLogInfo->szOprPswd, "password");


Note: If any required signon parameters are omitted, the signon screen appears and the missing values are set by default to the settings found in the registry. One way to control whether the signon dialog displays is to have PSUSER.DLL provide (or not provide) the user's password.

All parameters except bSubsequentSignon, which is Boolean, are of the data type CHAR and are defined as follows:

Parameter Name

Description and Values


An initial or subsequent signon. Values are:

FALSE: Initial signon. User just started the PeopleSoft system.

TRUE: Subsequent signon. User probably selected an item from the Go menu in the Development Environment (PSIDE.EXE).


Change database name or type. Values are:

TYPE: Allow to change type and name.

YES: Allow to change name only.

NO: Do not allow change to either.


Database type. Values are:

DB2: DB2 z/OS through Centura Gateway.

DB2ODBC: DB2 z/OS through ODBC.


MICROSFT: Microsoft SQL Server.

ORACLE: Oracle Server.

APPSERV: Application Server.


Database name or application server name. 


The Change Password feature. Values are:

YES: enabled.

NO: disabled.


User ID.


User password.


When operating in three-tier mode, PsGetTuxConnectInfo is called after PsGetLogonInfo and just before connecting to Tuxedo. Use this function to pass authentication data (key) to the server. Use this to either supplement or replace PeopleSoft’s standard authentication process.

You’ll find this function in your PS_HOME\src\PSUSER\PSUSER.C file. The delivered code looks like this:

* Function:     PsGetTuxConnectInfo                                    *
*                                                                      *
* Description:  This function is called from PeopleTools just prior to *
*               connecting to Tuxedo.  The PeopleTools client sends    *
*               the data in *ppData to the PeopleSoft Tuxedo           *
*               authentication service (PSAUTH), where it can be used  *
*               as an alternative or supplement to the default         *
*               PeopleTools authentication (see PsTuxAuthExit in       *
*               pssite.c).                                             *
*                                                                      *
* TO DO:        Add logic to obtain client authentication information. *
*               An example might be NT or DCE signon information.      *
*                                                                      *
* Returns:      TRUE if logon information returned                     *
*               FALSE to ignore                                        *


/*------------------------ BEGIN SAMPLE CODE ---------------------------

// set the auth information size and allocate space for auth information
pExtAuth->nLen = 25;
pExtAuth->pData = (unsigned char *) malloc(pExtAuth->nLen);

// set your authentication string
memcpy(pExtAuth->pData, "NATHAN HORNE\0\0PEOPLESOFT\0", pExtAuth->nLen);


--------------------------- END SAMPLE CODE --------------------------*/



To rebuild and implement PSUSER.DLL:

  1. Compile PSUSER.C and create PSUSER.DLL.

    To do this for Windows platforms, run NMAKE while in the PS_HOME\src\PSUSER\WINX86 directory. You must use a Microsoft Visual C++ 6.x compiler.

    On UNIX, run the shell script in pshome\src\psuser.

    The resulting file, PSUSER.DLL, is used by PeopleTools (PSTOOLS.EXE), and the Windows COBOL interfaces. For Windows NT, you must copy this file into your COBOL directory.

  2. Distribute PSUSER.DLL to workstations.

If your workstations run the PeopleSoft executable files from a common file server, you must ensure that your new PSUSER.DLL is copied to that file server. If any of your workstations run the PeopleSoft executable files locally, PSUSER.DLL must be distributed to such workstations.