Fix (APAR): WAS_Security_10-30-2003_4.0.7-4.0.6-4.0.5_client_cumulative_Fix Status: Fix Release: 4.0.7,4.0.6,4.0.5 Operating System: All Supersedes Fixes: WAS_Security_01-06-2003_4.0.5-4.0.4_client_cumulative_eFix, WAS_Security_03-17-2003_4.0.5-4.0.4-4.0.3_client_cumulative_Fix, WAS_Security_05-16-2003_4.0.5-4.0.4_client_cumulative_Fix.jar, WAS_Security_06-17-2003_4.0.6-4.0.5-4.0.4_client_cumulative_Fix and WAS_Security_08-15-2003_4.0.6-4.0.5-4.0.4_client_cumulative_Fix as well as any fixes for APARs listed below. CMVC Defect: See APAR list below Byte size of APAR: 1277086 Date: 2003-10-30 Abstract: Security cumulative fix 10/30/2003. Description/symptom of problem: See APAR list below. Directions to apply fix: 1) Create temporary "efix" directory to store the jar file: AIX: /tmp/WebSphere/efix Solaris/Linux: /tmp/WebSphere/efix Windows: c:\temp\WebSphere\efix 2) Copy jar file to the directory 3) Shutdown WebSphere 4) Run the jar file with the following command answering questions/prompts as they appear: java -jar 5) Restart WebSphere 6) The temp directory may be removed but the jar file should be saved. Do not remove any files created and stored in the /WebSphere/AppServer/efix/ directories. These files are required if an efix is to be removed. Directions to remove fix: NOTE: EFIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED. DO NOT REMOVE AN EFIX UNLESS ALL EFIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED. YOU MAY REAPPLY ANY REMOVED EFIX. Example: If your system has efix1, efix2, and efix3 applied in that order and efix2 is to be removed, efix3 must be removed first, efix2 removed, and efix3 re-applied. 1) Change directory to the efix location (/WebSphere/AppServer/efix/). 2) Shutdown WebSphere 3) Run the backup jar file with the following command: java -jar 4) Restart WebSphere Directions to re-apply fix: Follow the instructions for applying an efix. If the backup files still exist (from the previous efix application), you will be prompted to overwrite. Answer "yes" at the overwrite prompts. Additional Information: ------------------------------------------------------------------ The administration server and all application servers and clients which use the Websphere installation directory must be stopped for proper application of this eFix. Included APARS: APAR: PQ68882 Version: 400 Abstract: CANNOT HAVE , AND () IN ADMIN CONSOLE USER NAME Error Description: The customer cannot use user names that contain the comma character , and parentheses () in the DN as admin console users. The trace file contains the error message 'Invalid LDAP user'. Local Fix: There is no workaround for users whose DN contains a comma and parentheses characters. Logically Dependent Apars: Users Affected: WebSphere Application Server security users who has used a comma (, ASII 44) or open parenthese (ASII 40) or close parenthese (ASII 41) in a user's security name. Problem Description: If a user name or attributes in a DN (if LDAP is the user regi stry) contain comma or open parenthese or close parenthese, authorization for the DN may fail. Recommendation: Problem Summary: If user name or attribute in DN (if using LDAP registry) contain comma or open parenthese or close parenthese, user name was improperly truncated as security use those characters as delimiter, which results authorization error. If a Custom Registry is in use, this also applies to names returned by the following methods: List getUsers() List getUsers(String pattern) String getUserDisplayName(String userName) String getUniqueUserId(String userName) List getUniqueUserIds(String uniqueGroupId) String getUserSecurityName(String uniqueUserId) Problem Conclusion: Comma's and parenthesis were used internally as delimeters. The use of parenthesis as delimiters has been removed. Commas are now treated properly by escaping them. A fix for this APAR will be contained in any security cumulative eFix dated after the closure date of this APAR. Test Comments: Circumvention: Temporary Fix: A test fix was provided. Comments: APAR: PQ69188 Version: 400 Abstract: UNEXPECTED LOGIN PROMPT WHEN CLICKING ON ADMIN CONSOLE. Error Description: We set the Security timeout to 300 and the LTPA token timeout to 10mn. When the LTPA Token timeout expired, a popup window is displayed asking us to login again and a message is sent in the tracefile in order to warn us that the credential have expired. We expected this behaviour and we were happy. Then we entered the userid/password, we hit "enter". It seems that we are logged in. . Then we click on the console and we saw a new popup window asking us to login again, but this time without any messages in the tracefile. We entered the userid/password and we were able to go through the websphere topology inside the console. We don't think that prompting the second time when clicking on the console is correct. Steps taken: - wait 10mn - popup window - Login/password (msg in tracefile) and hit enter - hit somewhere in the console and you got a second popup window - Login/password (no msg in tracefile) and hit enter - wait 10mn - popup window - Login/password (msg in tracefile) and hit enter - wait 10mn - popup window - Login/password (msg in tracefile) and hit enter . By "message in tracefile", we mean JSAS0435E and CNTR0019E messages are generated. Local Fix: No workaround is known at this time. Logically Dependent Apars: Users Affected: All WebSphere Application Server users who have enabled securit y and use the Administration Console with the Authentication Mechanism set to LTPA. Problem Description: Admin Console displays unexpected login prompt after login. Recommendation: Problem Summary: When the LTPA Token timeout expired, a login window is displayed to login again and a message is sent in the tracefile in order to warn that the credential have expired. After username and password is entered, the console appears to be logged in. However, when the console is clicked again to access resources, another login windows is displayed. Problem Conclusion: This is caused by the expired credential not being cleaned properly. The expired credential is now being removed after expiration. Test Comments: Circumvention: Temporary Fix: avaliable Comments: APAR: PQ75785 Version: 400 Abstract: 4.0.6 Admin Console re-prompting Customer for log-in Error Description: Problem Description: Customer is at 4.0.6 on Solaris. When they start the Admin Console, it prompts them for log-in (as expected), and the console comes up fine. After 10 minutes (LTPA Token expiration time), customer is re-prompted for log-in. The prompt stays there for 5 minutes (com.ibm.CORBA.loginTim eout) and then disappears. After 10 minutes, another pop-up appears and dis-aapears in 5 minutes, and so on. During the 10 minutes after the pop-up disappears, anyone can walk up to the Console and use it. Customer is concerned about this apparent lack of security. Expected Behavior: After the first log-in prompt and successful log-in, there should not have been any re-prompting. Explanation: When the Client (admin console) successfully logs-in, the Client-side WebSphere runtime creates BasicAuth Credentials for the Client (these never expire) and sends the request to the Server. The Server-side creates LTPA credentials for this client and uses those to authorize the Client. After 10 minutes, these credentials expire and the Server goes back to the Client to ask for valid credentials. At this point, the Client-side is supposed to simply re-use the BasicAuth credentials and send the request back to the client. As long as the userid/password, supplied initially, are still valid, everything should just work fine. However, instead of first checking the BasicAuth information the Client-side has, WebSphere instead re-prompts the Client for a log-in. This is unexpected and a defect. When the login times out and the pop-up disappears, the Client-side then realizes that it already has valid BasicAuth Credentials and uses them. In the end, the result is as expected and as designed. But, the behavior of the pop-up needs to be fixed. Local Fix: none. No functional loss. Logically Dependent Apars: Users Affected: WebSphere Application Server users who have enabled security and are using the LTPA authentication mechanism. Problem Description: Java clients re-prompt for user ID and password after LTPAToken expired. Recommendation: Problem Summary: Java clients, including the Administration Console, may prompt for user ID and password information again after LTPA Token expired. This should not occur since Java clients use a basic authentication credential which does not expire. Problem Conclusion: The server now deletes the session on credential expiration. The client retries once using the existing basic authentication credential if the session was deleted for an expired credential. This prevents the client from re-prompting unless the user or password is no longer valid in the user registry. Test Comments: Circumvention: Temporary Fix: test fix provided. Comments: