I think this is a known bug: Item IC31516
APAR Identifier ...... IC31516 Last Changed..02/02/22 PASSWORDACCESS GENERATE DOES NOT WORK IF ENCRYPTION OF THE PASSWORD CAUSES A ZERO BYTE TO BE PART OF THE PASSWORD. Symptom ...... IN INCORROUT Status ........... CLOSED PER Severity ................... 2 Date Closed ......... 01/09/06 Component .......... 5698TSMCL Duplicate of ........ Reported Release ......... 42N Fixed Release ............ 999 Component Name TIVOLI STR MGR Special Notice Current Target Date ..01/12/30 Flags SCP ................... UNIX Platform ............ UNIX Status Detail: Not Available PE PTF List: PTF List: Release 42N : PTF not available yet Release 42A : PTF not available yet Release 42H : PTF not available yet Release 42S : PTF not available yet Release 42L : PTF not available yet Release 42X : PTF not available yet Release 42T : PTF not available yet Parent APAR: Child APAR list: ERROR DESCRIPTION: Whe using passwordaccess generate, a password record is formed for writing to the tsm.pwd file. The password record consists of the userid, servername, nodename, and the encrypted password. All parts of the password record are written as a sring and the encrypted password will fail to be written correctly if the string contains a 0-byte within it. for example if the encrypted password string is: "D8 D6 BD 00 94 26 CB 11 7F" when it is written to the password record, it is truncated at the 0-byte to "D8 D6 BD" and is thus incorrect within the tsm.pwd. This problem will only occur with passwordaccess generate and the password encryption scheme results in a 0 symbol within it. Since the password is incorrect in the tsm.pwd file, the user will be prompted for the password even if it was already set using passwordaccess generate. . This problem also applies to the Netware user id and associated password, which can be saved in the tsm.pwd file if the option "nwpwfile yes" is specified in the dsm.opt file. LOCAL FIX: Use a different nodename and/or password so the encryption scheme will generate a different encryption string that does not contain an 0 within it. PROBLEM SUMMARY: **************************************************************** *USERS AFFECTED: Novell Netware client, UNIX client * **************************************************************** *PROBLEM DESCRIPTION: PASSWORDACCESS generate: incorrect * * writing to the password file * **************************************************************** PROBLEM CONCLUSION: The problem was related with an incorrect way of the password record writing. It should be written as the binary data rather than the string.On Netware client the problem can occur both for TSM and Netware (TSA) passwords. TEMPORARY FIX: Try to use another TSM/TSA password or another node/NW user id. -----Original Message----- From: Keith Kwiatek [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 2:50 PM To: [EMAIL PROTECTED] Subject: TSM Linux scheduler fails authentication when a certain VALID password is used!? Hello, I have a Red Hat Linux 7.2 TSM client v 4.2.1 which seems to have a problem with a certain VALID password. I do a "set password" on the command line, and enter old/new password. It accepts the new password fine. I exit from the command line. I start the scheduler. I restart the command line and then do a "q sched".... and it asks for a nodename, I enter one, and it completes the q sched fine. I enter q sched again and it asks for the nodename again, in fact every time I do a q sched, it asks for the nodename. When the scheduler begins backing up at night, I get an authentication failure. The dsm.sys file is fine. The behaviour goes away if I simply change the password to anything but the particular string of alpha-numeric characters. When I set the password to the particular password string again, the odd behaviour comes back. For security reasons, I can't provide the password that is causing the problem..... Any ideas? Keith
